使用Redis Zset来处理活动常用排行榜（精确排行）

严格的排行榜

一个严格的排行榜，必须要满足每个人的排序都是有实际意义的，简单来说就是即使两个人的分数一样，那么也要分出先后来。
活动周期在92天以内的话，那么我们就可以使用200w加活动结束时间作为数字A来保证排行榜的顺序正确

在很大的活动中，比如奖项很大，第10名和第11名，可能奖金的额度相差了几万、几千。这个时候我们在做处理的时候就要小心了。我们要维护一个公平的排行榜。为了满足这样一个排行榜，我们需要在score的后面添加一个时间戳相关的系数。举个例子：

用户a 100 分 14:00 最后加分
用户b 100 分 14:20 最后加分

那么按照排行榜的规定来算，用户a要排在用户b之前。
但是我们在进行排行的时候，不能将时间直接加到分数后面，否则就排序反了，这个时候我们要用一个足够大的数A来减去时间戳，并且要保证位数在整个活动期间不变。

首先我们要理解一个redis的排序，redis的zset中的score值为double类型，精度只有16位，事实上在存储9999999999999999 16位整数的时候，会变为17位的10000000000000000，超过17位会变为科学计数法1e+17。

在活动中，我们要保证用户的分数不能丢失，所以必须保证在16位以内，一个用户最多的粉丝是5000w如果一个活动期间能保证所有的用户给他刷分，那么可能是亿级别的，但是实际上按照之前的活动量来看，最多能到千万级别。

这个时候我们按照1亿来算，长度要保证在9位，然后剩下的排重用的时间戳的精度，要保证在7位，也就是说我们要保证整个活动期间足够大的数减去时间戳的开始时间和结束时间都是7位数。

首先保证数字A-结束时间为一个7位数 ，那么我们要给这个结束时间+1000000 （一百万） 得到数字A，这样能最低限度保证活动结束之前时间戳系数的位数不变为7位数。
然后我们要保证数字A-活动开始时间也是一个七位数，也就是说开始时间和结束时间之间的跨度只能是900w，一旦超过900w，那么数字A减去开始时间就会得到一个8位数。

但是100w是一个临界点，我们100w和结束时间相加得到数字A，可能会因为活动结束时间的延长导致效果变成了为结束时间+99w 得到数字A，这个时候，活动最后结束的分数系数的位数就变为了6位，这简直就是个灾难。

所以我们将100w扩大为200w，这样相应的就给活动的结束时间增加了（100w/3600/24 = 11）天的时间。但是得到的效果将 活动的跨度周期减小到了800w秒，也就是（8000000/86400=92）天。所以说，如果活动周期在92天以内的话，那么我们就可以使用200w加活动结束时间作为数字A来保证排行榜的顺序正确。