游戏排行榜算法设计实现比较

　　之前在音乐作过一些实时投票，积分排名；单曲、专辑等排行榜；游戏中也有相似的战斗力排行；SNS的游戏又有好友排行等，对于此类的排行算法在此作个总结。

　　需求背景：

　　查看前top N的排名用户

　　查看本身的排名

　　用户积分变动后，排名及时更新

　　方案一：

　　利用MySQL来实现，存放一张用户积分表user_score，结构以下：

　　取前top N，本身的排名均可以经过简单的sql语句搞定。

　　算法简单，利用sql的功能，不须要其余复杂逻辑，对于数据量比较少、性能要求不高，可使用。可是对于海量数据，性能是没法接受的。

　　方案二：积分排名数组实现

　　若有1百万用户进行排名，就用一个大小为1，000，000的数组表示积分和排名的对应关系，其中rank[ s ]表示积分s所对应的排名。初始化时，rank数组能够由user_score表在O(n)的复杂度内计算而来。用户排名的查询和更新基于这个数组来进行。查询积分s所对应的排名直接返回rank[ s ]便可，复杂度为O(1)；当用户积分从s变为s+n，只须要把rank[ s ]到rank[s+n-1]这n个元素的值增长1便可，复杂度为O(n)。

　方案三：用GCC的pb_ds库中有assoc_container来进行实现。

　　参考以下：tree_order_statistics.cc

　　存取效率均可以达到O(log(n))，不足就是程序重启后数据会丢失。

　　方案四：本身实现排序树

　　大体实现思路以下：

　　咱们能够把[0, 1,000,000)做为一级区间；再把一级区间分为两个2级区间[0, 500,000), [500,000, 1,000,000)，而后把二级区间二分为4个3级区间[0, 250,000), [250,000, 500,000), [500,000, 750,000), [750,000, 1,000,000)，依此类推，最终咱们会获得1,000,000个21级区间[0,1), [1,2) … [999,999, 1,000,000)。这其实是把区间组织成了一种平衡二叉树结构，根结点表明一级区间，每一个非叶子结点有两个子结点，左子结点表明低分区间，右子结点表明高分区间。树形分区结构须要在更新时保持一种不变量，非叶子结点的count值老是等于其左右子结点的count值之和。

　　之后，每次用户积分有变化所须要更新的区间数量和积分变化量有关系，积分变化越小更新的区间层次越低。整体上，每次所须要更新的区间数量是用户积分变量的log(n)级别的，也就是说若是用户积分一次变化在百万级，更新区间的数量在二十这个级别。在这种树形分区积分表的辅助下查询积分为s的用户排名，其实是一个在区间树上由上至下、由粗到细一步步明确s所在位置的过程。好比，对于积分499,000，咱们用一个初值为0的排名变量来作累加；首先，它属于1级区间的左子树[0, 500,000)，那么该用户排名应该在右子树[500,000, 1,000,000)的用户数count以后，咱们把该count值累加到该用户排名变量，进入下一级区间；其次，它属于3级区间的[250,000, 500,000)，这是2级区间的右子树，因此不用累加count到排名变量，直接进入下一级区间；再次，它属于4级区间的…；直到最后咱们把用户积分精肯定位在21级区间[499,000, 499,001)，整个累加过程完成，得出排名！

　　虽然，本算法的更新和查询都涉及到若干个操做，但若是咱们为区间的from_score和to_score创建索引，这些操做都是基于键的查询和更新，不会产生表扫描，所以效率更高。另外，本算法并不依赖于关系数据模型和SQL运算，能够轻易地改造为NoSQL等其余存储方式，而基于键的操做也很容易引入缓存机制进一步优化性能。进一步，咱们能够估算一下树形区间的数目大约为2,000,000，考虑每一个结点的大小，整个结构只占用几十M空间。因此，咱们彻底能够在内存创建区间树结构，并经过user_score表在O(n)的时间内初始化区间树，而后排名的查询和更新操做均可以在内存进行。通常来说，一样的算法，从数据库到内存算法的性能提高经常能够达到10^5以上；所以，本算法能够达到很是高的性能。

　　算法特色

　　优势：结构稳定，不受积分分布影响；每次查询或更新的复杂度为积分最大值的O(log(n))级别，且与用户规模无关，能够应对海量规模；不依赖于SQL，容易改造为NoSQL或内存数据结构。

　　缺点：算法相对更复杂。

　　方案五：skiplist的实现

　　实现方案四的时候，发现代码比较复杂，调试起来特别不方便。游戏这边有个同事也实现了个，代码地址：http: //km.oa.com/articles/show/158740

　　因而就想到的跳表，发现用这个实现起来比较简单；用hashmap来存储具体的对象；用skiplist用来排序。也能够简单的用一个map和set来实现。Map内面存具体对象，set用来排序。

　　关于skip list这里简单介绍下：skip list是链表的一种特殊形式，对链表的一种优化；保证INSERT和REMOVE操做是O(logn)，而通用链表的复杂度为O(n);

　　优势：实现较简单，效率基本上O(log(N))

　　缺点：当达到亿级别时的数据时，性能会急剧降低

　　方案六：基于redis的 sort set的实现

　　后来看redis发现redis的zset天生是用来作排行榜的、好友列表, 去重, 历史记录等业务需求。接口使用很是简单。接口很是丰富，基本上须要的实现都能知足，说明以下：

　　ZAdd/ZRem是O(log(N))，ZRangeByScore/ZRemRangeByScore是O(log(N)+M)，N是Set大小，M是结果/操做元素的个数。

　　ZSET的实现用到了两个数据结构：hash table 和 skip list(跳跃表)，其中hash table是具体使用redis中的dict来实现的，主要是为了保证查询效率为O(1) ，而skip list(跳跃表)主要是保证元素有序并可以保证INSERT和REMOVE操做是O(logn)的复杂度。

　　音乐如今的通用投票排名系统就是基于redis来实现的，运行还不错。

　　优势：基于redis开发，速度快；使用redis相关特性

　　缺点：当达到亿级别时的数据时，性能会急剧降低

来实现排行榜的方法不少，能够根据本身的具体需求，参考选用。