您的位置:首页 > 业界新闻

移动互联网实战--社交游戏的排行榜设计和实现(2)

2014-08-20 00:50 477 查看
前言:
  游戏领域, 特别是移动端的社交类游戏, 排行榜成为了一种增强体验交互, 提高用户粘性的大法宝. 这边讲述在不同用户规模下, 游戏服务化/游戏平台化趋势下, 如何去设计和实现游戏排名榜. 本文侧重讲解Nosql在游戏排名榜中的作用. 小编(mumuxinfei)对这块认识较浅, 所述观点不代表主流(工业界)做法, 望能抛砖引玉.

秉承:
  上一篇文章, 详见: 社交游戏的排行榜设计和实现(1)

进阶篇:
  随着数据量/并发量的上涨, Mysql集群也呈现了一些疲态.
  (1). 数据库分库分表后, 表间的join事实上失去了意义. 要join的表数据在不同的库中.
  (2). 数据库的读写性能很容易达到上限.
  如何破解:
  我们先回过头来看些表定义以及使用
  表tb_score使用user_id访问score得分,其实user_id相当于key, score相当于value. 因此可借助Nosql的持久化key/value系统去实现,redis/mongodb/leveldb/hbase, 这样无论在读写速度上, 还是在应用扩展性上,都获得了很大的提升.
  表tb_friend借助user_id来获取friend_id列表, 其本质相当于user_id为key, list<friend_id>为value, 而key对应value列表, 可借助redis(数据结构服务器),也可借助sorted key/value db系统. 这边我们选用sorted key/value db, 因其数据按key的顺序存储.
  sorted key/value db的特点是:
  (1) 支持key的前缀查找
  (2) 支持批量/范围查询
  我们可以如下好友列表的key/value格式

key => user_id:friend_id
value => score


  评注:
  key=>user_id:friend_id表示friend_id为user_id的好友.
  那我们好友列表的查询, 就演变为前缀为"user_id"的范围查询.
  系统演变: 关系型数据库mysql转化为Nosql系统.
  


缓存篇:
   分布式缓存, 永远是互联网界的狗皮膏药, 无论什么疼痛, 贴一下总有疗效. 缓存的引入也是见血封喉, 效果非常显著, 不过需要注意数据一致性问题. 不过互联网能忍受弱事务性/弱数据一致性(C), 而强调可用性和可扩展性(AP). 移动端游戏, 其实也是类似的执行策略(除了和钱相关的业务). 常用的缓存有memcache/redis, 这些都是hash型散列的内存缓存.
  简单的采用Key/Value, 而不采用redis的key/sort-list的方式.
  value为json格式的列表:

json格式的内容 [{'user_id' : 'score'}, {'user_id' : 'score'}, {...}]


  排名相对静止, 因此缓存系统能挡掉大部分的数据读.

  但是引入缓存以后,数据的一致性,如何去保证?
  模拟如下应用场景:
  1). 好友破了新的记录
  2). 新增/删除好友关系
  这些情况发生后, 会更新好友的排行榜. 需要更新缓存, 使得缓存和后端服务的持久数据保持一致.
  那么如何去实现?
  这边谈谈常见的三种思路
  1). 同步更新: 当好友添加/删除以后, 主动删除排行榜缓存. 而用户的分数创新高后, 主动遍历好友列表,通知删除相应的缓存.
  2). 异步更新: 当好友添加/删除, 或者用户分数创新高, 其投递一个事件到一个队列中, 有队列消费者做这个耗时的同步操作.
  3). 缓存定期删除: 设定缓存key的有效期ttl, 不关注好友添加/删除, 得分更新事件的发生, 允许数据的一致有一定的延迟.
  这三种方案的优缺点, 可以对比如下:

实时性操作代价扩展性
同步更新最好有副作用,嵌入好友添加/删除代码逻辑中, 响应变大不好, 将来的好友添加/删除逻辑会越发的臃肿
异步更新一般影响小好, 引入队列, 可以由不同消费端做不同的处理
缓存定期删除一般几乎无影响---
  评注: 通知排行版更新是个重操作,比较耗时, 同步操作会影响响应时间.
  对于游戏而言, 如果排行榜不是实时排名, 采用方案2/3, 都是可接受的. 对于方案3, 这种没心没肺的做法, 其实最简单有效了(个人观点).

服务/平台化
  当一个社交类App演化为一个平台时, 好友模块和游戏模块就自然分开了, 其数据库/Nosql系统逻辑上不在一块了,比如微信App, 其内部肯定把各类服务做了拆分, 其数据是彼此隔离的. 在这种服务/平台化的演进下, 好友特定的游戏排行榜, 又该如何破?
  我们假定如下的服务, 其交互流程如下.
  GameService/FriendService模块
  


  评注:好友更新事件主动触发Game模块, 代价也特别大(如之上所述). 同时也需要Friend模块添加相关的逻辑代码,这使得模块之间紧耦合了.
  借助队列, 采用异步的方式来实现. 这相当于在模块之间采用了观察者(Observer)模式, 事件的触发者只要简单的投递事件于(topic模式)队列中. 然后由需要关注该事件的服务模块主动去订阅它. 新模式转化为如下:
  


  评注: 通过队列异步化事件, 采用订阅的方式, 来实现解耦.
  服务平台化后, 这种做法, 在工业界常常被采用.

后记:
  本来只想写一篇文章, 关于社区游戏排行榜的设计的. 但发现内容有些长, 于是就拆分成了两篇, 里面的内容简单的涉及了一些, 并没有具体展开. 小编(mumuxinfei)对这块还是入门尚浅, 如果有什么不足, 希望能指正.
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐