Daly 2012-11-30 14:14 发表评论

     游戏逻辑大部分情况下需要保证状态数据的强一致性，基于过期的数据进行处理会得到错误的结果（分布式数据一致性的工程问题见文末的参考资料）。举个有点蹩脚的例子，假设client先后发出reqA, reqB两个请求，reqA是换武器，reqB是发起攻击，变量v是攻击输出量（dps）。reqB在reqA之后发出，攻击理应是按穿上武器后的dps数值来计算的。但多进程情况下，却有可能reqB先于reqA处理（比如A进程很忙），这时reqB的逻辑会基于还没穿上装备时的变量v来计算结果。下面分别讨论几种解决数据一致性问题的方案。

     适合于单机多进程或多线程的模式。

     优点：数据只有一份，可以保证强一致性。

     缺点：进程无法扩展到多台服务器；

          需要加锁，加锁相当于把处理串行化，还是有可能被某一个较忙的进程卡住。如果精心设计和划分数据，减少锁的粒度可以提高性能，但细粒度的锁（设计成类似MySQL的行级锁），在涉及多个玩家数据的交互逻辑时，稍有不慎又容易导致死锁。随手写一个：

        假设进程A和B同样执行以下类似的逻辑

         foreach( user in mapA) {

              lock(user);

              lock(user‘s friend);

              do_something();

              unlock(user's friend);

              unlock(user_id);

         }

         由于遍历的是map, 进程A和B中的user顺序有可能交叉, 假设交叉的两个user互为friend，就可能死锁了。
         参考资料[4]采用了这种模式的方案。

      把状态数据根据游戏逻辑进行划分，比如变量v只由A读写, 变量w只由B读写。假如A逻辑需要用到w，则通过异步请求B获取w。

      优点：保证强一致性；数据只有一份，无需进程间复制更新。

      缺点：异步请求增加了响应时间(嗯，又从并行变成了串行); 异步写起来的代码有点ugly，到处是callback, 回来要检查上下文，不然又是诡异bug.

      适用范围：如果状态数据能比较好的划分（即绝大多数情况下，某个数据只会在某个进程的逻辑中用到），用这种方案比较适合，因为简单。比如玩家位置只由AOI进程管理，玩家好友由聊天进程管理。

      这是完全的分布式设计。每个进程有自己版本的状态数据，进程间可互相同步更新, 状态数据v分别在A,B都有一份。互相update时，根据版本信息进行merge。 

      这种方案不能保证强一致性，而且merge时会有可能发生冲突，需要逻辑开发者仲裁这种冲突（比如按时间先后）。不同于互联网应用，游戏需要较强的数据一致性和实时性，这种方案比较复杂且不太可控。

      这个是对模式二的一个扩展，某个状态数据还是只由一个进程进行写操作，但其他进程会维持一份cache进行读操作，比如变量v由进程A管理，v的更新会同步到进程B，进程B逻辑如果要用到v,直接读自己的cache就可以了。对于变量v

     特点：这种方式也是不能保证强一致性，只能保证最终一致性。作为模式二的补充，有些数据不需要保证更新时序，根据过期数据进行处理也可以接受(这个是代价，需要权衡玩家体验），可以采取这种方式。而对于不能接受的，走模式二。某些需求reqA，reqB虽然先后发出，如果respA还没反馈回来的话，即使逻辑上reqB先于reqA处理，在玩家体验上也是可以接受的。比如reqA穿装备, 然后reqB攻击，但是respA还没返回，客户端还是看作是没穿上装备，这时候按照老的属性计算攻击值是可接受的。广域网几百毫秒的延迟，reqB要晚于reqA + respA这种概率很小了，如果真的发生，服务器已经很卡了。
    又比如聊天进程，reqA离开场景，然后reqB发聊天消息往当前场景频道，需要知道当前场景的玩家列表(假设场景玩家列表在AOI进程管理)，如果reqB先到达聊天进程,拿到旧的场景玩家列表, 那么这个广播就不准确了。这种不一致性的代价可以忍受的话就没问题(在这个聊天栏例子，在跳场景的瞬间发错人了也可以忍），实际情况，进程间通信几个毫秒，发生这种处理时序反转的几率其实非常小了。

综上，如果要设计多进程结构，个人比较推崇模式四。这时又引申出几个问题：状态数据如何合理划分？何时更新？同步给谁？

     有些功能很好划分。比如聊天进程，状态数据只与好友列表有关，这个需求可以忍受过期数据，好友关系由主进程修改，同步到聊天进程。玩家position, 由AOI进程管理，修改同步到主进程，主进程几乎没有需要用到position的逻辑。

    但有些数据就可能很纠结，比如背包数据。玩家交易，在线奖励，战斗都需要修改背包物品数据，而且必须保证强一致性，否则就可能出现丢失或物品复制，该由谁做这个数据的管理者呢？如果AOI进程管理，物品使用效果可以马上生效，但是交易和在线奖励也需要验证背包物品，这些逻辑也放到AOI进程么，如果放，则又牵扯出更多的变量，如果不放，则需要退化成模式2的异步请求。如果放主进程，则使用物品后产生的效果不能立刻同步到AOI进程。可以经过仔细对比，AOI与背包数据交互的频率远高于主进程，于是背包数据可由AOI进程管理。

     两种选择：一有修改立马发送更新给其他进程；队列buffer住所有更新，定时送出去（比如每2秒同步一次）；既然是无法保证强一致性，后者性能容易优化些。比如AOI进程中的位置信息变化很频繁，但主进程对位置实时性不敏感（比如只用于持久化，掉线重上后的位置恢复），则更新间隔可以长一些，否则会有频繁而大量的位置数据更新；定时更新也利于同步间隔内数据修改的合并，减少同步量。

     某类数据有修改时，需要通知哪些进程，意味着要维持一个映射表。可以在编码阶段，在数据定义时静态写死某类数据要通知哪一类功能进程； 也可以在运行期设计成pub-sub模式(或者叫observer模式), 动态增删订阅者。笔者觉得前者可控一点，因为进程要用到哪些数据，在编码阶段是可以清楚规划的，根据这个原则把数据划分成一个个模块，比如玩家数据分为基本角色属性，avatar, 位置/朝向, 好友数据....  然后决定归属。

    多进程可以提升系统并发规模，但同时有各种异步调用和数据一致性问题，带来的代价就是bug的风险增加(尤其团队水平不能保证个个都很高的情况下，一个菜鸟程序员就够受了，还很难跟踪），开发难度增大。这个需要仔细profile和实验确定瓶颈在哪，真的跑满CPU或者卡IO才有必要分出去，想当然的把模块拆分很多进程，设计看上去很优雅也很牛逼，往往是麻烦的开始 ——> 开发效率降低，出bug意味着啥？加班，加班，深夜运维的夺命追魂call... ...

参考资料

[1] 当webgame邂逅erlang.  明朝网络的庆亮。 http://www.slideshare.net/qingliangcn/webgameerlang-8241397#btnNext

[2] 陈杰谈网游服务器后端技术.  西山居陈杰的ppt, 讲多进程架构下的寻路算法 http://timyang.net/architecture/game-backend/

[3] nosql ecosystem. 13节讲述分布式系统的数据一致性问题
[4] 结构化数据的共享内存, 云风 http://blog.codingnow.com/2011/12/dev_note_6.html

Daly 2012-08-05 17:01 发表评论

Daly 2012-07-17 09:45 发表评论

     void *(*__malloc_hook)(size_t size, const void *caller);

     缺点：依赖GNU编译工具链;  容易死循环(想利用原有malloc，要参考例子中，把原__malloc_hook变量保存起来使用，并恢复现场)

Daly 2012-07-02 13:01 发表评论

目前典型硬盘的顺序写入速度大约是60MB/s , 而寻道时间在5~8ms (200次/秒)。可以看到硬盘IO的主要瓶颈在于磁头寻道，也就是随机写。在linux开发服(非虚拟机，Xeon 3.0G 4核/16G内存)上做了一个benchmark。

顺序写50MB: 700ms

写5000个文件，每个10KB(共50MB): 12秒

        10000次随机写，每次1KB(共10MB): 21秒
   2. 游戏数据都是K-V数据，关系查询需求极少；k-v数据的update很频繁(实测是每玩家每5秒一次修改)
   3. MMORPG单服的玩家同时在线数量是10K级别, 这个数量级可以有效估算binlog的规模，使得方案可行。

Daly 2012-07-01 18:05 发表评论

Daly 2010-06-18 16:15 发表评论

Daly 2010-06-18 13:38 发表评论

Daly 2010-06-18 12:27 发表评论

Daly 2010-05-26 20:44 发表评论

Daly 2010-05-02 00:02 发表评论