java的Random居然是假随机

故事背景

今天合作方K反馈没有收到微信解约信息,我感觉大概是系统报错了,或者是连接超时之类的错误,结果一排查发现这个解约消息回调到合作方B了......我记得逻辑是根据签约号查询数据库的签约信息,签约信息有渠道号,根据渠道去通知到对应的url请求,怎么会弄混了呢,百思不得其解。

问题排查

首先是看有多少数据是这种情况,通过查日志和数据库都确认了只有这一条数据发送到错误的渠道,对业务影响不大。然后仔细看代码逻辑发现了蹊跷的地方,查询渠道的时候居然是通过序列号去查询,不是通过协议号,下面是序列号的生成规则。

一开始我只是以为刚好这么巧,在同一个时间戳+同一个随机数刚好冲突了,上线了快半年,一天可能有上万的签约记录,只出现了一次。

我跟兄弟说这个事情后,他说听说Random是伪随机数,后面证实了确实如此,传入了种子后,得到的数字都是一样的...

当创建Random的实例对象时,没有指定种子,系统会以当前时间戳作为种子,产生随机数。当指定种子后,两次产生的随机数序列就会一样了。

所以这个随机数不管传不传种子,如果是时间戳一样,random的数字肯定是一样的.....怪不得说他是伪随机,大概的算法就是根据时间戳做一个计算处理。

方案处理

其实在这个业务中处理还挺简单的,不用这个"唯一"序列号做查询条件,使用有唯一索引的订单号作为查询条件就解决了。另外除了数据库唯一索引校验,还有其他几种分布式id生成方式。

1、UUID

缺点:字段太长占用空间,无序性,插入数据库时可能导致页分裂,降低写入效率。一般不推荐使用

2、redis分布式id

优点:性能较高,ID持续递增

缺点:依赖redis,redis挂了服务会异常

我们服务有用过redis这种生成方式

3、雪花算法

雪花算法是由时间戳 + 数据中心ID + 机器ID + 序列号组成。如果时间戳一样,就会在本地保存一个序列号,依次递增。

优点:本地生成,无网络开销。

缺点:时钟回拨问题:机器时钟不同步可能导致ID重复。

其实我们也算是半个雪花算法,我们用的是时间戳+random随机数,只不过时间戳跟random随机数是绑定关系,时间戳一样,random随机数就不随机了- -

4、Leaf(号段模式)

美团开源的分布式ID服务,批量从数据库获取号段(如1-1000),内存分配。

优点:高吞吐:减少数据库访问频率。

缺点:需等待新号段获取,存在短暂阻塞风险。

我们也用过这种号段方式,不过是用的redis版本。

总结

random是个伪随机数,不能跟时间戳共用。一般可以用时间戳+redis分布式id,或者时间戳+mysql的号段方式比较好~

相关推荐
martinzh2 小时前
Spring AI 项目介绍
后端
前端付豪2 小时前
20、用 Python + API 打造终端天气预报工具(支持城市查询、天气图标、美化输出🧊
后端·python
爱学习的小学渣2 小时前
关系型数据库
后端
武子康2 小时前
大数据-33 HBase 整体架构 HMaster HRegion
大数据·后端·hbase
前端付豪2 小时前
19、用 Python + OpenAI 构建一个命令行 AI 问答助手
后端·python
凌览2 小时前
斩获 27k Star,一款开源的网站统计工具
前端·javascript·后端
全栈凯哥2 小时前
02.SpringBoot常用Utils工具类详解
java·spring boot·后端
狂师2 小时前
啥是AI Agent!2025年值得推荐入坑AI Agent的五大工具框架!(新手科普篇)
人工智能·后端·程序员
星辰大海的精灵2 小时前
使用Docker和Kubernetes部署机器学习模型
人工智能·后端·架构
MikeWe2 小时前
C++宏的解析:从基础语法到实战场景
后端