雪花id重复 查重
2022-12-22阅读(248)
问：雪花算法之【线上订单号重复了？一招搞定它！】
- 答：公司老的系统原先采用的时间戳生成订单号，导致了如下情形
打断一下：大家知道怎么查系统某项重复的数据吧
不得了，这样重复岂不是一单成功三方回调导致另一单也成功了。
多个服务怎么保证生成的订单号唯一呢？
先上code
以上是采用snowflake算法生成分布式唯一ID
41-bit的时间可以表示 （1L<<41）/(1000L360024*365)=69 年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。
这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示 2^12 个ID，理论上snowflake方案的QPS约为 409.6w/s ，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。
这种方式的优缺点是：
优点：
缺点：
一般来说，采用这种方案就解决了。
还有诸如，mysql的 auto_increment策略，redis的INCR，zookeeper的单一节点修改版本号递增，以及zookeeper的持久顺序节点。
问：修改redis zset的score为64位整形以支持雪花ID算法
- 答：关于雪花ID算法的介绍有很多文章，就不画蛇添足了，当然雪花ID算法也有一个问题是时间回拨的问题，这个可以参考以下两个链接去了解：
但是我们把这个64位的ID保存到redis的zset的时候，却面临一个zset的score溢出问题，原因是score是64位double类型（float64），关于这个问题有开发人员提出过解决办法，详见： 和 .
他们解决办法的相同点就是把雪花ID变成52位（float64的整数位精度是52位）以期不会溢出，但是这也势必导致ID的范围变小，比如他们的业务就是保存15天的消息，这样的修改并不是一个满足复杂业务场景的实现，20年和21年断断续续修改redis server的源码将score的类型从float64改为int64位，并且同步修改php redis和go redis的client接口实现，因用于公司新兴业务，未经公司同意尚未能公开源码，实际上也不难修改啊
问：雪花算法与Mysql自增的优缺点
- 答：雪花算法与Mysql自增的优缺点分别是：
雪花算法优点是：
1、不会重复。
2、有序，不会造成空间浪费和胡乱插入影响性能。
3、生成很快特别是比UUid快得多。
4、相比UUid更小。
缺点是：时间回拨造成错乱。
Mysql自增的优点是：
1、存储空间小。
2、插入和查询性能高。
缺点是：
1、int的范围可能不够大。
2、当要做数据迁移的时候，会很麻烦，主键容易冲突。
3、id自增，自身的业务增长情况很容易被别人掌握。
4、自增在高并发的情况下性能不好。
生成id的代码是：
自增和UUid差异的原因是：mysql数据库一般我们会采用支持事务的Innodb，在Innodb中，采用的是B+数索引。Innodb的存储结构，是聚簇索引。对于聚簇索引顺序主键和随机主键的对效率的影响很大。
自增是顺序主键存储，查找和插入都很方便（插入会按顺序插到前一个的后面），但UUid是无序的，通过计算获得的hashcode也会是无序的（是按照hashcode选择存储位置）。
所以对于他的查找效率很低，而且因为他是无序的，他的插入有可能会插到前面的数据中，会造成很多其他的操作，很影响性能或者很多存储空间因为没有顺序的存储而被空缺浪费。
