【SNS专题】大型SNS类游戏服务器架构
SNS类型的游戏一般有以下的特点：
（1）所有的玩家角色可能存在交互
SNS类型的游戏一个玩家角色会找他的好友或者其他任何一个毫无关系的玩家角色进行某种逻辑上的互动。
（2）这类游戏玩家角色一般是看不见的
（3）玩家角色在线或离线状态比较模糊
在线的玩家角色可以主动找不在线玩家进行交互。如去某个没上线的好友菜园偷菜，去攻打不在线的玩家角色的城池。
（4）交互频率较低，数据量小。
根据上面的主要特点，这类游戏后台要设计成唯一一个的大世界，而角色之间无须相互可见，实现这个大世界后台就有存在的可能。实际的商业项目中，可以采用下面的架构。
一般前面的节点往后主动连接。
connsvr有可能是webserver，也有可能是自定义协议的tcpsvr；他采用某种hash映射的方式，将client(网页或桌面程序)请求的消息包转发给某个logicsvr。
logicsvr和上面转发hash映射机制对应的方式的作分布式部署。
dispatchsvr的功能是转发logicsvr之间的消息包，一般的游戏只要一台就够了。
dbproxy是访问DBMS的代理。
另外说明一下，服务器之间建议用tcp通信，这样可以借助tcp拥塞控制的机制做应用层的流量控制。
举个简单例子，来说明一下某个游戏逻辑的流程。就拿偷菜来说，client1上的玩家A想偷好友B的菜。
（1）A根据某种负载均衡机制（DNS轮询就可以了）向某个connsvr发请求包，connsvr将请求包转发到A所在的logicsvr上。
（2）A所在的logicsvr，做一些基本验证，如B是否是A的好友等，处理偷菜逻辑；如果B也在这台logicsvr上，那就直接处理B的被偷逻辑；否则就通过dispatchsvr将消息包转发到B所在的logicsvr。
（3）B所在的logicsvr收到消息，处理完被偷逻辑后，就将结果通过A连接的connsvr返回给A的client。
大部分SNS类型的游戏会附加很多小游戏，不管哪些小游戏，建议用一些独立的进程实现。像邀请一些好友一起做某种游戏之类的小游戏可以在上面的架构里加入封闭式性质的进程。
小游戏logicsvr和原来的logicsvr有本质的不同，前者只须局部的玩家角色数据，而后者的数据要求是全局性的。
小游戏的游戏结结果往往要在主游戏中较及时的反映出来，比如得到某些物品，经验级别有变化了之类。大体流程一般这样：
（1）多个角色进入到小游戏中时，要从各自的主logicsvr中拉取最新数据。
（2）小游戏完成后，要将游戏结果保存到各自的主logicsvr，再退出，返回到主logicsvr[来源：GameRes.com]。