文/mumuxinfei

　　前言:

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

　　秉承:

　　上一篇文章, 详见: 社交游戏的排行榜设计和实现：mysql数据库的应用

　　进阶篇:

　　随着数据量/并发量的上涨， 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格式
 

1. key => user_id:friend_id
   
2. value => score

　　缓存篇：

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

　　简单的采用Key/Value， 而不采用redis的key/sort-list的方式。

　　value为json格式的列表:

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

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

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

　　服务/平台化

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

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

　　GameService/FriendService模块


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

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

　　后记:

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

锐亚教育，游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛