RedisSortedSet结构score字段丢失精度问题解决办法是什么
这期内容当中小编将会给大家带来有关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 至 241−1,减1是因为可表示的数值范围是从0开始算的,而不是1。
也就是说41位可以表示241−1个毫秒的值,转化成单位年则是(241−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://pwwzsj.com/article/jdsghh.html