再接再厉，前文说了任务系统的设计思路，不知道别人能不能看明白，为了锻炼一下表达能力，还是应该多画图，尤其是动态图。一图胜千言，尤其是讲数据结构和算法的时候，简直是没图没真相。不过画的太细就顾此失彼，画的太粗又达不到效果，像北京地铁图一样的示意图就是良好表达的典范。
之所以把竞技场和排行榜拿出来说，主要是因为这个系统涉及到了所有玩家的状态，还涉及到了开服和重启服务器的初始化。一般的系统功能只不过是单个玩家的数据管理，顶多与服务器的公共数据关联一下，而在做这个系统的时候感觉到了明显的不同。先简单描述一下需求：玩家20级开启竞技场，把伙伴添加到队伍中，到竞技场中挑战排名在自己前面一个范围内的三个玩家，胜利的话交换排名。玩家初始排名10万名，排行榜初始有20个机器人，排行榜可以容纳10万个玩家的排名。
这个需求显然是有问题的，策划只是从游戏的表现给出了一个描述，所以程序员还得把这个要求变成真正的需求。
1）关于排行榜的大小。排行榜的大小不可能达到10万(刚开始设计的是100万)，但是排名却有10万的范围，所以这个排行榜是稀疏的，其中的假数据就是用机器人模拟的玩家。而模拟玩家的机器人也并不存在于排行榜中，只有在玩家挑战排行榜的时候才会通过刷新挑战目标的规则生成出来。竞技场的目的是让玩家实现pvp，所以刚开始挑战竞技场的时候，挑战机器人基本上都会胜利，这样玩家排名越靠前则挑战到真实玩家的概率越大。
2）关于玩家的数据存储。无论玩家是否在线，他在排行榜中都是可见的，可以被其他玩家挑战，并且在下次上线的时候能够看到战斗记录和重放战斗过程。这么一来，所有玩家的数据必须在服务器启动的时候就加载，至少要加载“开启了竞技场的玩家”的“队伍数据”和“主角数据”。这几块数据原来是存放在玩家信息表中的，为了初始化排行榜，必须查询满足条件的玩家数据分成几个步骤加载，实际做出来之后发现加载过程复杂而且低效。我发现如果单独建立一个排行榜表，把所有已经在排行榜中有排名的玩家“被挑战时需要的信息”存放在这个表里，只要一次查询就完成加载。果然是结构决定功能，当结构不适合做功能的时候必须要调整结构。调整的结果是，把“以玩家为中心”的存储方式，改成了“以排行榜为中心”的存储格式。使用排行榜表的另一个好处是，如果把玩家的排名放到排行榜中，那么无论玩家是否在线，我只需要更新排行榜中的排名，当玩家上线的时候到排行榜中得到自己的最新排名即可。嗯...还记得排行榜初始的时候有20个机器人么，只要把他们看成永远的离线玩家就行了。
3）关于玩家的排名同步。由于存在大量的玩家同时挑战排行榜，所以难免出现A和B同时挑战C的情况，这时候本着先到先得的原则，如果A已经挑战了C导致C的排名变化，那么B挑战C的时候会失败。当然更人性化的做法应该是告诉玩家“小伙伴你来晚了，C的位置已经被A取代，是否挑战A”之类。如果是挑战了机器人玩家，就让挑战者替换机器人的排名就行了。
4）开服和重启服务器。开服的时候排行榜表是空的，只有20个机器人玩家，这时候我们可以从配表初始化这些机器人并且插入到数据库中。如果重启服务器，则只从数据库初始化排行榜，这样可以保证排行榜的初始化方式只有一种生效，避免发生错误。这种思路也适用于设计接口，我要完成一个功能，你就给我一个唯一的接口，实在不行，也要明确的区分两个接口的用途，这样可以最大程度的避免混乱。
本文无图，等我状态好的时候再画一个补上。(玩家挑战排行榜的过程比较适合画动态图)