故事背景
今天合作方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的号段方式比较好~