大型SNS类游戏服务器架构

sea_bug

作者：herm_lib
博客：O1高地

　　SNS类型的游戏和RPG类的网游有一些不同的特点，而这些特点会导致这类游戏的后台架构和RPG网游的后台架构存在一些区别。

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。

iicup

不错！！！！！！！！！！！！

kissorange

  不要误导别人，这样的框架太复杂了，纸上谈兵是没用的。

gantleman

恰恰相反，这样的框架图和介绍太简单了
真要把一种游戏架构说清楚，怎么也的3本以上的大部头。
架构这东西不在大方向，说的再宏伟
最后死的原因很可能就是几个细节实现不了。

kissorange: Re: 大型SNS类游戏服务器架构


  不要误导别人，这样的框架太复杂了，纸上谈兵是没用的。

fanchy

[em20]
我觉得此文纯属闭门造车，SNS 要是设计成这样必失败！
普通的SNS游戏是基于Http的web模型，直接WebServer + Memcache + Db，你前边分析的SNS游戏特点还是很准确的，由于用户的数据有可能被任意好友访问，没有下线概念，所以需要将大量的用户数据缓存到Memcache（也不会太大，因为单个玩家数据量有限），WebServer是无状态的，client通过域名访问WebServer（nginx+php），php 直接操作memcache，操作memcache的时候需要使用memcache的add语义加锁，SNS游戏是轻量级的，你的创意必须很快的搞出来，不然其他公司也许正在搞相同创意的游戏呢，看看市面上的SNS游戏，同质化已经很严重了，SNS游戏一定是基于成熟的Web框架的，快速、低成本的开发游戏。当然现在已经有基于实时在线的SNS游戏，其架构参考普通的WebGame，只是SNS游戏不需要LoginServer，因为平台已经替游戏完成了登陆服务。

daemon.huang

楼上说的应该是那种简单的webgame的游戏。本文这个架构适合那种MMO又有SNS交互的游戏。这种游戏有MMOG的任务，道具和成就等元素，同时又离线交互逻辑。dbproxy这块会针对不同类型的数据和数据本身的特点采用不同的缓存策略，比如全缓存或者淘汰缓存甚至不缓存。设计系统还是要根据业务特点来做，做到灵活善变。

daemon.huang

因为产生楼上的误会，我把题目改得清晰一些。这种SNS不是指那种简单的webgame。

大型MMO-SNS类游戏服务器架构
http://blog.csdn.net/herm_lib/article/details/6381872

欢迎拍砖。