移动互联网实战--社交游戏的排行榜设计和实现(2)
前言:
游戏领域, 特别是移动端的社交类游戏, 排行榜成为了一种增强体验交互, 提高用户粘性的大法宝. 这边讲述在不同用户规模下, 游戏服务化/游戏平台化趋势下, 如何去设计和实现游戏排名榜. 本文侧重讲解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)对这块还是入门尚浅, 如果有什么不足, 希望能指正.
