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