http://www.cppblog.com/jaxe/archive/2010/04/22/113255.html
1、 游戏世界由很多个游戏对象组成（游戏角色、物品、NPC、技能等）；
2、 一个游戏对象的有效数据主要存放在客户端、游戏服务器和持久性数据库中；
3、 游戏对象的处理可划分为与位置有关的和与位置无关的，如公会处理、物品处理等主要行为可以看作是与位置无关的处理，而NPC（AI）、战斗、移动这类的主要行为可以看成是与位置有关的。
4、 从客户端的角度来看，游戏行为可分为四类动作：
a) 来自服务器端的动作，如另外一个玩家跳起来。
b) 本地动作。仅仅发生在本地客户端的动作，不需要与服务器端或其他客户端通讯。
c) 先执行后验证的可撤销的动作。客户端先执行，再提交服务器端验证，验证不成功通知客户端将执行的动作撤销。比如玩家控制的游戏角色执行移动处理。
d) 严格服务器端验证的动作。客户端执行动作前必须经过服务器端验证后才能执行。如交易行为、攻击其他玩家/NPC。
5、 客户端和服务器，服务器进程之间的相互的通信从逻辑上看就是就是向RemoteObject 发起的远程过程调用（RPC），RPC主要有两种类型：
a) 通知(Notify)。只通知对方，而不关心和需要对方返回结果。
b) 请求(Request)。向对方发起请求，对方处理请求后返回结果，发起请求和返回结果这个过程可以是同步或异步。游戏服务器中绝大部分RPC请求都是异步的。
6、 响应延迟主要是由于网络带宽和服务器处理效率引起的。应尽可能的通过一些技巧来隐藏和减少玩家的响应延迟。但不是所有的最新消息都能立刻发送出去（或接收处理到），因此，要在服务器端采用优先队列来减少重要消息的响应时间。延迟也会由客户端产生，如收到消息后的对消息的处理速度。
7、 服务器负载，除了升级硬件设备外，可以通过一些方式来提高服务器负载。
a) 保证足够的网络带宽。
b) 分布式运算，合理的集群式架构。
c) 游戏策划从游戏内容上避免设计高并发，高消耗的游戏行为。
8、 从服务器的可伸缩性，稳定性和高效率方面来考虑，要试着避免所有事情都在一个地方处理，尽量让系统分布式运行，但是过多的划分功能到不同的进程/机器上运行，又会带来数据的大量同步的问题。因此可以将游戏对象的处理主要划分为与位置无关和有关两种。像公会，玩家信息，物品信息，组队，拍卖等等这类与位置无关的但是占用CPU资源较少的处理可以尽可能的放在一个进程中，避免进程间对象同步，而像NPC，寻路，AOI运算，战斗处理等与位置有关的，处理过程中特别关心对象坐标位置的、运算量特别大的，但是进程间对象同步较少的，都可以单独划分成多个进程。
每类进程服务的功能尽量单一。负责路由的就尽量只负责网络包转发，而不再承担其他繁重的任务，负责游戏处理的就尽量让网络包流向简单。
大规模应用服务器（不只包含游戏服务器）是否成功主要看架构师对问题的解构能力。
问题是什么？
问题的边界在哪里？
功能粒度划分多细？
解决这些问题都需要经验。