redis多维度排序实现

 

基于redis非关系型缓存数据库的多维度阅读排行榜实现。

 

 

 

本发明属于JAVA语言集成redis缓存数据库解决在阅读系统中多维度分析客户排行的榜单排行名问题。

 

1. 背景技术（字数：500以上）

    定义：

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。 

zset(sorted set --有序集合)在数据排行的应用：

redis有序集合也是集合类型的一部分，所以它保留了集合中元素不能重复的特性，但是不同的是，有序集合给每个元素多设置了一个分数，利用该分数作为排序的依据。

有序集合可以利用分数进行从小到大的排序。虽然有序集合的成员是唯一的,但是分数(score)却可以重复。比如在阅读系统中，用户的编号是唯一的，但是阅读时长却是可以一样的，redis可以利用有序集合存储用户阅读时长快速做阅读排名功能。

 

4、发明目的或要解决的技术问题（字数：200以上）

本发明的目的就是要解决在阅读系统中对用户阅读行为数据的各种统计榜单中既能按照不同维度进行快速准确排序，又不用全表便利缓存以解决榜单数据相同情况下的排名不能满足业务需求的问题。

业务场景：

要求：统计用户每天上报的阅读时长数据，在活动截止日按照榜单的先后排名派发相应奖品。（用户时长相同的情况下以时长上报的先后顺序决定最后排名。）需要满足实时查询个人排行信息和分页查询总榜排名信息。

redis有序集合现有弊端：

当zsort的score相同的情况下，redis是以key的字典序进行排名的，因此不能满足业务场景需求。

现有实现方案：

存储两个缓存key.(key1用zsort集合存储用来进行阅读时长的排行信息，key2用hash来存储用户的编号和上报时长信息)，当每次查询用户排行榜单是需要全部遍历zsort集合当遇到score相同时需要遍历key2的数据来获取用户的上报时间出现进行二次排序。以满足业务需求。

现有方案弊端：

数据开销太大，存储空间浪费。前端响应慢，失去了缓存数据库引以为傲的速度优势。

  

 

5、技术方案

针对现有实现方案的弊端，本发明的核心目的就是要解决数据开销大，存储大大浪费，响应速度慢三个问题。

因此本发明的核心思路就是利用现有的redis原生zsort集合原理来实现基于阅读时长和阅读上报时间的多维度阅读榜单排行问题。

通过阅读redis源码和JAVA数据类型的了解发现，zsort集合的key需要唯一的标识而阅读系统用户的唯一标识是用户编码如果再加上时间这个变量就无法定位到具体用户，因此在key上进行改造的方案是不可行的。那唯一的可行方案就是改造现有的score属性，尝试将阅读时长+上报时间点作为score进行排列发现在阅读时长相同的情况下后上报的score反而大于先上报的用户，因此也行不通。可是一个排行榜是有时效性的。

1：取排行活动结束的时间点的时间戳为 Long endtime=1595001599999(活动持续两个月);

2: 取每次上报阅读时长的时间戳  Long updatetime=1589987574133;

3: 计算活动结束时间戳和上报时间戳的差值

Long betwwUpdateTime=1595001599999-1589987574133=5014025866;

4:  计算 int num=betwwUpdateTime位数;

5:  设上报时长为 Long updatescore,将scoretime转换为num(10)位的字符串，不足前面补0。

6： 设zsort的value为

Long score=Long.valueOf(updatescore.toString()+scoretimeStr);

通过以上六个步骤的score转换最终的value为后面10位数代表上报时间的先后顺序的大小映射值.（上报早的取值越大），前面位数代表真正的阅读时间，因此在阅读时长相等的情况下会比较上报的时间先后顺序。因此达到了不修改一行代码即满足了业务需求，并且规避了现有方案所有的弊端。

 

注：在相同的毫秒数上报的阅读时长相等的情况下，该方案还是会按照key的字典序进行排列，这个在技术上是无法规避的，只能在业务层面解决！