转载:http://blog.csdn.net/stanjiang2010/article/details/6954445
最近在作公司的一个Social Game的项目服务器架构设计，与之前做过的MMORPG（简称RPG）相比，差别还是较为明显的，现总结一二，以供分享！
（一）协议通信
1）Socail Game为了快速开发，在通信协议的选择上均会选择http作为底层通信协议，这样选择的好处大致有：
1、方便客户端编程：http为一应一答的同步模型；
2、可以选择成熟的开源http服务器，如：apache、nginx；
2）RPG选择的是基于socket的TCP通信，这是由游戏本身的特点所决定的，如：聊天、多人视野、服务器主动通知事件等需求
（二）游戏逻辑服务器的承受能力
1）RPG的游戏逻辑服务器（地图服务器）所能承载的最高在线（PCU）是在3000-5000不等；
2）Social Game由于没有RPG复杂的移动、战斗、视野管理等需求，逻辑服务器承受的在线一般都是比较高的，如：10000-30000不等
（三）游戏逻辑服务器的Cache和回写机制
1）RPG的游戏逻辑服务器一般都需要Cache玩家数据，并且采取定时回写的策略，如根据数据重要程度分别作5min-15min不等的定时回写；
2）Social Game的游戏逻辑服务器一般都无需Cache玩家数据，玩家的每次请求都是即时读即时写（这样会涉及到另外一个问题，即DB读写的性能问题，见下一条）；
（四）DB存储模型的选择
1）RPG存储服务器常用的还是MySQL+innodb，中间还由业务自己写一个Cache代理服务器，以Cache热点数据；
2）Social Game则会选用TC、MemCached等所谓Key-Value全内存数据存储，有实力的公司会自己实现一个类似这种机制的存储系统，它可以无源，也可以是有源，并且还可以选择用MySQL作数据落地，毕竟MySQL作为互联网业务DB的成熟解决方案，已毋庸置疑；
（注：我们公司是选择自己开发基于key-value机制的全内存DB，现网测试的数据是平均1KB的数据可以分别达到5w左右的读/写，还是很牛X的了）
（五）交互数据的一致性
1）在SNS Game中，会经常出现同一个玩家在某一个时刻同时被多个好友访问和修改数据的情况，这时就需要保证，每次数据的更新都是正常有序进行的，而不能被写脏数据。一般地，都会使用一个类似全局锁服务的设计来解决这个问题；
2）RPG不会存在这样的问题，类似的需求是：玩家可能会跨地图服务器，即所谓的跳线或跨服，这个问题的通常解决方案是服务器重新作一次下线、重登录的处理，当然，玩家是感觉不到的；
（六）IDC部署
1）RPG一般是分区分服部署；
2）Social Game则是全区全服部署；