improve player data loader

2015-07-26 刘太华 更多博文 » 博客 » GitHub »

queue game

原文链接 https://liutaihua.github.io/2015/07/26/improve-player-data-loader.html
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。


玩家数据的loader优化

由于历史原因, 最早的时候玩家数据是在2个独立的服务进程中都存在, 游戏场景服务A, 和游戏数据逻辑服务B, A中的数据来自于B, A服务会根据某些逻辑, 触发数据回存, 将数据回存到B, 达到数据一致性要求, 但是随着游戏过程中, 会积累资源比如金币之类的, 这个积累的数据暂时只会存在场景服务A中,后面的运营过程中证明, 这种数据分两份的做法, 是个非常大的坑, 有很多理论上的机会导致数据不一致, 丢数据的问题。

运营过程中优化过几次A--> B的数据回存操作, 绝大部分数据已经不再做临时数据了, 比如拾取一个物品, 直接拾取操作从B服务走, 场景服务A只需要在请求完成时得到一份通知,重新从B拉去最新的背包数据。

游戏中很多类似通知场景服务A做数据更新的操作, 可以叫做dataloader, 问题在于loader是一个同步的阻塞的操作, 由于场景服务的逻辑是一个单线程的服务, 所有战斗, 游戏中的每侦都中这个线程内进行的, 连续多个玩家的dataloader操作,可能会因为B-->A的数据延迟, 造成线程阻塞, 无论是多人场景, 还是单人单world场景, 如果线程阻塞了, 会导致其他玩家有感觉, 延迟严重的, 玩家打怪, 放技能, 本应该事实反馈的伤害数字, 会因为其他玩家的Loader而出现卡顿, 延迟.

所以决定把loader操作做异步化, 异步之后的缺点是, 如果异步线程稍慢, 会导致玩家在某个操作后, 延迟一点才看到自己界面上的金币等资源的变化, 但是这些资源并不是直接的战斗数值, 因此基本是完全不影响体感的。

异步化的过程比较简单, 做过两版:

1, 完全异步, 发起的loader, 直接boost:bind 把player的this指针带给异步方法, 放入线程队列中, 这个方法完全异步了player的 data loader操作, 但是异步线程和主线程在共享这一个player指针, 无论怎么做, 都会存在一个理论上的操作空指针的可能, 比如主线程里玩家已经离线, 就清楚了player对象, 造成异步线程player已经不存在了, 当然可以在异步里判断player的存在在做操作, 但是过于繁琐, 对每个player的操作都事先判断下. 或者是主线程不直接做删除, 而是把需要删除的player, 放入一个deleter 线程,设定一个标记位来决定是否删除. 但是改动略大。

2,就是已经采用的方法, 半异步化。 因为这个 data loader最耗时的其实是从B --> A过程中的一次socket连接开销和数据传输开销, 只需要把这一个子步骤放入异步线程即可, 数据获取全部完成之后, 绑定回调函数, 再放入主线程, 主线程会在world的每侦被Pop一次, 得到执行。 那么整个过程是:

reqLoadData --> generateLoader(attach a callback: onDataLoaded()) --> put it to threading queue --> Got all data in threading --> bind the callback(onDataLoaded(*data)) --> put callback to main threading --> execute the callback at Update done.

经过测试, 开了100个机器人, 每隔50ms做数据dataload操作, 同战斗场景内玩家杀怪, 不再有卡顿延迟, 体感得到优化。.