轉載: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則是全區全服部署；