超大实时排行榜的解决方案

标题是个噱头,这里只说积分数据全部装载到内存

 

首先,玩家的积分什么的有单独的表存储,这里不谈序列化,语言是C++

假定score是double,id是int64

然后计算空间需求,这里假设实现了专用无税收的内存适配器
32位进程大地址,每个节点32字节,4G的进程可以放下1.34亿的数据,去掉进程本身的边角,1.2亿
64位进程,每个节点48字节,1亿数据需要4.47G内存,根据需要自己给服务器加内存吧...

然后就没有然后了...

就是这么简单粗暴的把所有积分塞进内存

查询第k名玩家的id
查询积分n可以排多少名

好吧,存在的问题是,更新略恶心,用积分做k,存在相同积分时候,equal_range后遍历找到对应id,erase后重新insert吧

序列化什么的,可以考虑内存映射文件+对应内存适配器来搞定 

 

 

然后说说容器本身!

 

自己码的sorted_set类,可随机访问的kv容器,std::multimap风格,允许重复key

operator[]操作不明确下标访问或是key-value查询,所以没有实现

内部二叉树结构,除了parent,left,right之外,只有一个SBT需要的size域,4个指针大小

随机访问迭代器,可以+/-/+=/-=操作,可以两个迭代器相减求距离

这里的rank从0开始,并没有给出select函数,而是参考std::vector使用at随机访问

各种接口的复杂度不超过O(log2n),参考陈启峰的size balanced tree

实测4千万数据,可以达到每秒百万查,作为一般的游戏行业,算是足够了

树结构还算平衡,顺序/乱序插入的时间开销是std::multimap的1.2倍左右,这里请教是不是我实现有问题?

 

 

 

最后念叨点题外的!

 

说起来个人比较懒...

最初是我的俄罗斯方块AI里面的需求,对有序的std::vector不断归并,std::merge成了性能瓶颈!

之后考虑节AI内部本身就是一个个节点,直接建立二叉树来排序效果应该不错,但是AI内部节点都是百万级别!

于是直接用std::map的问题就是new的时候会有税收,而且本身就是AI节点,所以参考std::map源码直接搞了个一个不去new节点,直接把外部节点挂在树上的容器!还没有clear开销!

似乎就是这样了,然而后来听说size balanced tree比red black tree性能还好,然后改造起来也不麻烦!索性顺手加上那个神maintain来测试一下性能~

结果实测,比红黑树稍慢,也可能是我的实现有问题?没有达到陈启峰说的超越红黑树,不过也算是一个数量级~

最终俄罗斯方块AI还是用了红黑树...

------分割线------

群里某人问:"SortedList相当于C++里的啥容器？"

于是我就把之前的外挂节点的容器拿来重构...

暂时叫sorted_set,跟redis的Z系列很像,同npm的sorted-set(内部跳表实现)

相比其他的rank tree实现,附加域没有任何浪费什么的太漂亮了

 

本文3个目的

1.安利一下size balanced tree
2.找高人看看我的实现有什么问题
3.抛砖引玉

 

最后传送门

转载于:https://www.cnblogs.com/304321141/p/4898509.html