这期内容当中小编将会给大家带来有关redis SortedSet结构score字段丢失精度问题解决办法是什么，文章内容丰富且以专业的角度为大家分析和叙述，阅读完这篇文章希望大家可以有所收获。

成都创新互联公司技术团队10年来致力于为客户提供成都网站设计、做网站、成都外贸网站建设公司、成都品牌网站建设、网络营销推广、搜索引擎SEO优化等服务。经过多年发展，公司拥有经验丰富的技术团队，先后服务、推广了上1000家网站，包括各类中小企业、企事单位、高校等机构单位。

一、问题现象

项目中采用Redis SortedSet存储用户的离线消息，score值存储的msgid（消息ID）。msgid采用snowflake算法生成，按照时间有序。

生成的msgid有18位十进制整数，例如 215857550229364736

我们发现数值很接近的msgid，在redis中无法通过score进行区分。

举个列子，在redis中tzset结构里存入如下几条数据  

ZADD tzset 215857497028812800 test1

ZADD tzset 215857540511162369 test2

ZADD tzset 215857550229364736 test3

ZADD tzset 215857550229364737 test4

查询看一下结果 

我们发现score值采用科学计数法表示，test3,test4两个元素的score值显示是一样的。

使用score=215857550229364736 执行查询，结果如下图 

使用215857550229364736查询，结果score为215857550229364737的test4也被查出来了

用215857550229364739去查，竟然也能查出来 

这一现象给我们的系统功能带了困扰，会影响到消息同步TimeLine的精确性（参看《基于TimeLine模型的消息同步机制》）。

二、问题原因

查询相关资料发现Sorted Sets中的Score是double类型，我们的msgid是long类型。问题是long转换为double时，丢失精度。

1、snowflake算法简介

消息ID采用snowflake算法，采用64位二进制整数。二进制具体位数含义如下图。

1位，不用。二进制中最高位为1的都是负数，但是我们生成的id都使用正数，所以这个最高位固定是0

41位，用来记录时间戳（毫秒）。

如果只用来表示正整数（计算机中正数包含0），可以表示的数值范围是：0 至 2⁴¹−1，减1是因为可表示的数值范围是从0开始算的，而不是1。

也就是说41位可以表示2⁴¹−1个毫秒的值，转化成单位年则是(2⁴¹−1)/(1000∗60∗60∗24∗365)=69年

10位，用来记录工作机器id。

可以部署在1024个节点，包括5位datacenterId和5位workerId

12位，序列号，用来记录同毫秒内产生的不同id。

12位（bit）可以表示的最大正整数是4095，即可以用0、1、2、3、....4095这4096个数字，来表示同一机器同一时间截（毫秒)内产生的4096个ID序号

2、doublel数据结构

double数据的结构如下图 

3、问题定位

63bit（去掉符号位）的数转换为52bit的数，从某一位开始进行了四舍五入，导致精度下降。所以215857550229364736、215857550229364737、215857550229364739三个数据被转换为double类型后，计算机认为是相同的数。

三、解决办法

问题找到了，怎么解决呢？

id生成策略要保证整个系统生命周期类所有ID唯一，设计一个52bit的ID生成器保证ID唯一难度较大。

Redis的score数据类型更是修改不了

用52bit来表示63bit的数据一定会丢失信息，长整型long默认转换为double的方式丢失的信息会影响到业务，能不能结合业务特点自定义一种转换（映射）方式，答案是肯定的。

有以下几种想法

1、因为Redis缓存的消息最多保存15天（假设）或者最多保存多少条。能不能截去41位时间戳的部分高位，确保Redis缓存时间周期内时间戳长度够用就行呢？计算了一下长度 log(15*24*60*60*1000)=30.2，大约30位二进制数即可在现有规则下表示15天时间。所以将41位时间戳的前11位屏蔽掉，可以节约11位二进制信息。这样63bit刚好能用52bit来表示。

然而这个方式有个致命问题，当15天时间周期到了后，时间戳会变得特别小（新的周期），这导致上一个周期后边的数据Score值大于新周期。消息顺序混乱了，会导致拉离线丢消息，这不能接受！

2、去掉10bit工作机id和序列号的最高位bit。

去掉这11bit，不会对消息的顺序造成影响，但是可能造成score数值冲突（相同）。分析一下score冲突的可能性。

（1）12bit序列号能表示4096个数。去掉最高位，能表示2048个数。所以单个msgid生成节点（dispatch模块）每毫秒，每个用户要超过2048条消息，才可能出现score重复。这个基本不可能发生。

（2）去掉10bit工作机id号，需要同一毫秒，同一用户在不同的dispatch节点都接收到消息，score才可能冲突。即使出现这种情况，由于12位序列号我们做了模128的随机分布（解决分库问题），即使出现同一毫秒不同disptch生成同一用户msgid的情况下，score冲突的概率还要除以 128*128。这个概率非常低。

（3）即使出现了score冲突（两条消息有相同score），最多造成拉取离线消息多拉取相同score的消息（本来一次拉取10条离线，结果可能拉到11条），对业务也没有影响。

因此采用去掉10bit工作机id和序列号的最高位bit将63bit（不含符号位）的msgid转换成52bit的score对业务上没有影响。同时解决了redis sorted set丢失精度的问题。 

因此采用去掉10bit工作机id和序列号的最高位bit将63bit（不含符号位）的msgid转换成52bit的score对业务上没有影响。同时解决了redis sorted set丢失精度的问题。

上述就是小编为大家分享的Redis SortedSet结构score字段丢失精度问题解决办法是什么了，如果刚好有类似的疑惑，不妨参照上述分析进行理解。如果想知道更多相关知识，欢迎关注创新互联行业资讯频道。

本文题目：RedisSortedSet结构score字段丢失精度问题解决办法是什么
文章起源：http://chengdu.cdxwcx.cn/article/jdsghh.html