美文网首页
再说说数据同步

再说说数据同步

作者: fooboo | 来源:发表于2018-09-15 10:33 被阅读28次

    这几天在做拍卖的功能,大致是一些人通过某种社交关系,参加某种玩法,获得的物品道具什么的不能直接添加到玩家背包中,而是间接通过竞价获得。物品上架有一定的时效性和初始价格,然后大家一起竞价,每次竞价都是在原来基础之上提高百分多少,竞价成功的会获得物品,并且“那些人”会平均获得一些收益,当然系统也会扣除点手续费什么的。

    这种场景需求是不是跟咱们平时一些购物网站竞拍抢购秒杀类似?包括其他游戏中也有。那如果合理设计方案,是需要考虑很多问题。

    我这边会大概描述下游戏方案中一些场景和对应合适的处理方法,后面看是否有额外时间也会从网络上参考些秒杀之类的设计方案作为延伸,当然游戏中的复杂性不高,数据的准确性和实时性没有后者高。

    在游戏中,因为是在一个服中,而且这边的设计并不是分布式的,最终所有的请求都汇集到一个service那边,串行化处理,并发量不大,最坏情况是全服人都在线(预估五千人),每秒狂点竞价按钮(不考虑客户端做按钮次数限制),在服务器那边根本不是问题。如果是那种网站秒杀,如果架构设计的有问题,大并发请求立马压垮后台服务器或者造成雪崩等严重问题,服务不可用。

    下面开始谈谈游戏中的思考方案,这也是我在工作中所想的,当然方案并不是那么完美,折中策划需求和程序这边实现情况。

    先说超时处理,因为每件竞价品的超时时间都一样,所以先到先超时,那么就可以避免一个一个比较有没有超时,直接跟第一个比较,没超时break,否则再处理下一个,这是最简单的。当然有些场景用复杂的数据结构比如堆结构,或者算出下次超时时间距离现在多久,然后sleep这段时间后唤醒,避免每次for比较,这里每个拍卖品都需要个超时时间字段。

    有一种优化方案是,不检查是否超时,比如原来每秒tick检查一次,现在改为可以在程序重新启动的时候统一处理掉超时的拍卖品,然后在有玩家拉取数据时处理下是否超时,在竞价或者购买时处理下单件拍卖品是否超时,剩下的哪怕超时先不管,延长处理超时,且不用每秒检查所有物品。但另一个问题是,如果频繁拉去拍卖数据,可能造成多次遍历,可以结合上面的方案避免。还有一种是如果没有人拉取数据或者竞价购买行为(超时由行为触发或者重启),那么超时数据堆积在内存和DB中,需要等下次程序重启时再处理,这里可以降低频次,改为每小时处理一次。当然这里一般处理为客户端分页拉取,比如有一百条记录,每十条一页,那么客户端第一次拉取时带上Page为一的请求然后把结果发给他并且告知总页数,这样决定客户端接下来的行为。

    如果延迟处理超时那么会带来数据的不一致,客户端看到的已经超时,被移走,服务器还在,需要下一次拉取的时候再处理,这里问题不大,只要客户端超时处理以服务器的物品超时时间走定时器即可,以服务器数据为准。这里涉及到网络包的优化和计算量的优化。

    下面以例子分别讨论数据的一致性。

    比如有两个客户端A和B同时请求拍卖物品数据,假设有itemA和itemB两个拍卖品,这样两者看到的是一样的数据,此时如果A参与竞价,那么怎么做到更新A和B的数据呢?怎么确定是否要更新到B那边呢?如何增量更新呢?

    这块在以前的文章中说明过,当时写的背包增量更新。有变化时,只把变化的物品关键数据同步下去,其他不变的不同步,客户端点开背包时不用请求背包数据,相当于数据流的推。

    但是这里不一样,因为拍卖数据不同于玩家数据,总不能拍卖数据有变化就同步给每一个在线玩家吧?这个流量浪费了。那怎么做到上面说的几个问题呢?

    由于服务端不会保存客户端当前的操作状态,不关心客户端是否打开拍卖界面。所以当拍卖数据有变化时,可以暂时不用通知客户端,也做不到。由客户端自己处理,即如果客户端打开界面,可以定时请求下,带上上一次的更新时间,服务器收到请求后,把上一次更新时间和所有拍卖品最后更新时间对比,如果有更新,则只发更新的拍卖品的相关字段,比如最新竞价,竞价人等,其他没变化的不更新,这样做到了增量更新,这里尽量减少网络流量,当然如果拍卖品很多,比如几千个,其实也可以把有更新的移到一边,这样遍历的时候,只对有更新的遍历比较等。

    这里还有一个问题是,当A拉取拍卖数据时,在定时更新前,B进行了竞价,比如拍卖品x的初始竞价为100,A看到的是100,B是110,这里A再竞价时,是有问题的,这里可以参考下乐观锁的实现,但并不需要这么复杂,直接在A竞价的时候,带上看到的100,然后服务器会比较,如果有变化不相等,则增量刷新。再者,这里的竞价只会增长,所以只使用新值和旧值比较即可,不存在ABA这种问题,业务上不需要再加数据版本号的方面。

    后面有时间会写些购物网站拍卖系统的一些想法,之前看过一些实现方案。

    这款游戏被腾讯独代了,需要写技术文档需要评审,很多问题在当时开发过程中没有考虑全面,虽然知道什么单点问题,雪崩,可靠性,服务降级,网络,扩容,服务器数据库承载能力,缓存等,但是每一项都做好确实不容易,这块在慢慢完善,需要思考的问题较多。

    希望做好。

    请假回家喝喜酒。

    相关文章

      网友评论

          本文标题:再说说数据同步

          本文链接:https://www.haomeiwen.com/subject/bpsggftx.html