社交游戏的排行榜设计和实现进阶篇：Nosql系统

前言:

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

秉承:

进阶篇:

随着数据量/并发量的上涨， 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为value， 而key对应value列表， 可借助redis(数据结构服务器)，也可借助sorted key/value db系统。 这边我们选用sorted key/value db， 因其数据按key的顺序存储。

sorted key/value db的特点是:

(1) 支持key的前缀查找

(2) 支持批量/范围查询

我们可以如下好友列表的key/value格式
 

1. key => user_id:friend_id
2. 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格式的列表:
 

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

复制代码

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

但是引入缓存以后，数据的一致性，如何去保证？

模拟如下应用场景:

1)好友破了新的记录

2)新增/删除好友关系

这些情况发生后， 会更新好友的排行榜。 需要更新缓存， 使得缓存和后端服务的持久数据保持一致。

那么如何去实现？？

这边谈谈常见的三种思路

1)同步更新: 当好友添加/删除以后， 主动删除排行榜缓存。 而用户的分数创新高后， 主动遍历好友列表，通知删除相应的缓存。

2)异步更新: 当好友添加/删除， 或者用户分数创新高， 其投递一个事件到一个队列中， 有队列消费者做这个耗时的同步操作。

3)缓存定期删除: 设定缓存key的有效期ttl， 不关注好友添加/删除， 得分更新事件的发生， 允许数据的一致有一定的延迟。？

这三种方案的优缺点， 可以对比如下:
 

评注：通知排行版更新是个重操作，比较耗时， 同步操作会影响响应时间。

对于游戏而言， 如果排行榜不是实时排名， 采用方案2/3， 都是可接受的。？对于方案3， 这种没心没肺的做法， 其实最简单有效了(个人观点)。

服务/平台化

当一个社交类App演化为一个平台时， 好友模块和游戏模块QQ账号买卖就自然分开了， 其数据库/Nosql系统逻辑上不在一块了，比如微信App， 其内部肯定把各类服务做了拆分，其数据是彼此隔离的。 在这种服务/平台化的演进下， 好友特定的游戏排行榜， 又该如何破？

我们假定如下的服务， 其交互流程如下。

GameService/FriendService模块

评注：好友更新事件主动触发Game模块， 代价也特别大(如之上所述)。 同时也需要Friend模块添加相关的逻辑代码，这使得模块之间紧耦合了。

借助队列， 采用异步的方式来实现。 这相当于在模块之间采用了观察者(Observer)模式， 事件的触发者只要简单的投递事件于(topic模式)队列中。 然后由需要关注该事件的服务模块主动去订阅它。 新模式转化为如下:
 

评注: 通过队列异步化事件， 采用订阅的方式， 来实现解耦。

服务平台化后， 这种做法， 在工业界常常被采用。

后记:

本来只想写一篇文章， 关于社区游戏排行榜的设计的。 但发现内容有些长， 于是就拆分成了两篇， 里面的内容简单的涉及了一些， 并没有具体展开。 小编(mumuxinfei)对这块还是入门尚浅， 如果有什么不足， 希望能指正。