设计目标
? 支持大用户
? 支持多排行榜
方案一（暂不述）
统一排行榜/成就系统。为众多游戏提供排行榜和成就系统。很多游戏平台提供对应的API。
方案二
游戏单独内置排行榜。API的设计建议参考方案一的方式，后续可以方便的升级改造成方案一。
瓶颈1：排序计算需求
问难题原因：排行榜，需要进行排序，如果不断的进行排序，计算资源将被耗尽。如果完全排序采用定时进行，那么势必会导致玩家无法即时看到自己的排名，特别是针对进入排行后的玩家无法带来很好的刺激。后续有必要的情况下可以自己优化排序算法。
解决方案：不同刷新频率
月，周，日，半天，五分钟；
1分钟+触发+评估（假实时）：
触发1：当有玩家请求查看排行榜
触发2：待处理数据队列达设定上限（通常1000）
评估：超出热显示范围的数据进入评估体现，给出一个粗略的排名
注意：评估体系用在所有刷新频率的排行榜上。
瓶颈2：大数据
问题原因：大数据
众多的角色如果真的都参与排序，假设注册角色10万，那么针对10万级别的数据进行排序，先不考虑计算能力，磁盘的IO瓶颈和内存的大小瓶颈直接导致一次排序需要的时长超过秒级；如果加上排序周期设置太短，就会变得在不断的排序，结果就是导致计算资源和IO资源耗尽。
解决方案：减少排序数据
在设计需求上通常查看的也就是前100或者200，所以超出范围外的采用评估体系。玩家在200以外的情况，这个时候，就可以采用简单的评估数据给他一个排名。如何更好的设计评估体系，后续介绍。
瓶颈3：资源竞争（计算资源/内存资源/IO资源）
问题原因：多任务操作系统
操作系统给每个进程/线程分配的计算需求是可以设定的。为了避免一个就弄成过多的消耗。当然我们正常情况下，也没必要设置进程的优先级。
解决方案：单进程
采用独立的进程来实现提供此项服务。使用内存数据避免使用磁盘IO。
瓶颈4：频繁提交
问题原因：程序实现
游戏代码，在玩家排行榜依赖的数值发生改变后，马上进行提交，导致了众多无效的数据提交。
解决方案：定期提交+下限设定
在玩家没有查看排行榜请求的时候，游戏服务器采用定期（5分钟一次）提交给排行榜服务器，提交前进行下限数据比较，超过下限设定的才进入提交数据包（*注意：这个提交数据包可以打包，不要一个小包一个小包发送）。当有角色查看排行榜请求的时候，触发提交操作，并在排行榜服务器上进行一次排序操作。
实现注意点
1）CPU占用
采用单独的进程来实现排行榜，半天以上的排行榜可以共享一个进程。1分钟+触发的榜单可以采用单独的一个进程。
2）计算数据减少
在线角色在提交数据后，和排行榜的最后一名比较，如果小于值，那么直接丢弃。如果进入榜单，将此数据压入待处理队列。
3）评估体系
就是超出200（设定值）榜单范围外，到底是多少名次，并不是真实的数据，而是根据预设的排名区间需要的值，进行范围估值。例如1000名需要1000点，2000名需要2000点，如果玩家是1500点，那么就直接估计为1500名，而不是跟其他角色进行真实排序，也许实际上我们1000~1500之间没有一个角色，他的排名应该是1000，甚至有可能是800。
这个评估体系，最好建立学习模型，可以进行自动动态更新。
4）关于多线程
排行榜这种进程，不要使用多线程来实现，因为产生的socket的连接数量是小的，来自我们自己的游戏服务器。所以windows下直接采用select模型就可以了。
综述
服务器系统的设计，尽量的简单化、单一化。这样带来的好处就是整个程序的规模小，代码量小，BUG修正、维护升级改造等工作都变得简单和容易控制。
排行榜和成就系统，拥有较高的通用普遍性，在人力资源和时间许可上尽量采用方案一的设计来实现。
排序的算法优略，非常有效的提高排序速度。建议采用跳跃式比较方式+下限比较剔除方式组合。而不是直接使用冒泡法排序。
其他
如有不明白，或者发现其中的错误，可以QQ：447483932联系；或者电子邮件。如果有更好的建议或者想法也欢迎及时交流。