java批量⽣成订单号_⼀⽂搞定分布式系统ID⽣成⽅案
系统唯⼀ID是我们在设计⼀个系统的时候常常会遇见的问题，也常常为这个问题⽽纠结。⽣成ID的⽅法有很多，适应不同的场景、需求以及性能要求。所以有些⽐较复杂的系统会有多个ID⽣成的策略。下⾯就介绍⼀些常见的ID⽣成策略。 倒挂器最常见的⽅式。利⽤数据库，全数据库唯⼀。
优点：
1)简单，代码⽅便，性能可以接受。
2)数字ID天然排序，对分页或者需要排序的结果很有帮助。 缺点：
1)不同数据库语法和实现不同，数据库迁移的时候或多数据库版本⽀持的时候需要处理。
标定2)在单个数据库或读写分离或⼀主多从的情况下，只有⼀个主库可以⽣成。有单点故障的风险。
3)在性能达不到要求的情况下，⽐较难于扩展。
4)如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
5)分表分库的时候会有⿇烦。
优化⽅案：
粉碎机器人1)针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不⼀样，步长⼀样，可以是Master的个数。⽐如：Master1 ⽣成的是 1，4，7，10，Master2⽣成的是2,5,8,11 Master3⽣成的是 3,6,9,12。这样就可以有效⽣成集中的唯⼀ID，也可以⼤⼤降低ID⽣成数据库操作的负载。
2. UUID
微型显示器常见的⽅式。可以利⽤数据库也可以利⽤程序⽣成，⼀般来说全球唯⼀。
优点：
1)简单，代码⽅便。
2)⽣成ID性能⾮常好，基本不会有性能问题。
3)全球唯⼀，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。
缺点：
1)没有排序，⽆法保证趋势递增。
2)UUID往往是使⽤字符串存储，查询的效率⽐较低。
3)存储空间⽐较⼤，如果是海量数据库，就需要考虑存储量的问题。
4)传输数据量⼤
5)不可读。
3. UUID的变种
1)为了解决UUID不可读，可以使⽤UUID to Int64的⽅法。及
2)为了解决UUID⽆序的问题，NHibernate在其主键⽣成⽅式中提供了Comb算法(combined guid/timestamp)。保留GUID的10个字节，⽤另6个字节表⽰GUID⽣成的时间(DateTime)。
⽤上⾯的算法测试⼀下，得到如下的结果：作为⽐较，前⾯3个是使⽤COMB算法得出的结果，最后12个字符串是时间序(统⼀毫秒⽣成的3个UUID)，过段时间如果再次⽣成，则12个字符串会⽐图⽰的要⼤。后⾯3个是直接⽣成的GUID。
如果想把时间序放在前⾯，可以⽣成后改变12个字符串的位置，也可以修改算法类的最后两个Array.Copy。
4. Redis⽣成ID
当使⽤数据库来⽣成ID性能不够要求的时候，我们可以尝试使⽤Redis来⽣成ID。这主要依赖于Redis是单线程的，所以也可以⽤⽣成全局
唯⼀的ID。可以⽤Redis的原⼦操作 INCR和INCRBY来实现。
可以使⽤Redis集来获取更⾼的吞吐量。假如⼀个集中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5。各个Redis⽣成的ID为：
A：1,6,11,16,21
B：2,7,12,17,22
C：3,8,13,18,23
D：4,9,14,19,24
木纤维袜子E：5,10,15,20,25
立式烤箱这个，随便负载到哪个机确定好，未来很难做修改。但是3-5台服务器基本能够满⾜器上，都可以获得不同的ID。但是步长和初始值⼀定需
要事先需要了。使⽤Redis集也可以⽅式单点故障的问题。
另外，⽐较适合使⽤Redis来⽣成每天从0开始的流⽔号。⽐如订单号=⽇期+当⽇⾃增长号。可以每天在Redis中⽣成⼀个Key，使⽤INCR
进⾏累加。
优点：
1)不依赖于数据库，灵活⽅便，且性能优于数据库。
2)数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：
1)如果系统中没有Redis，还需要引⼊新的组件，增加系统复杂度。
2)需要编码和配置的⼯作量⽐较⼤。
5. Twitter的snowflake算法
C#代码如下：
/// /// From: github/twitter/snowflake /// An object that generates IDs. /// This is broken into a separate class in case /// we ever want to s 测试代码如下：
private static void TestIdWorker() { HashSet set = new HashSet(); IdWorker idWorker1 = new IdWorker(0, 0); IdWorker idWorker2
snowflake算法可以根据⾃⾝项⽬的需要进⾏⼀定的修改。⽐如估算未来的数据中⼼个数，每个数据中
⼼的机器数以及统⼀毫秒可以能的并
发数来调整在算法中所需要的bit数。
优点：
1)不依赖于数据库，灵活⽅便，且性能优于数据库。
2)ID按照时间在单机上是递增的。
缺点：
1)在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。
6. 利⽤zookeeper⽣成唯⼀ID
zookeeper主要通过其znode数据版本来⽣成序列号，可以⽣成32位和64位的数据版本号，客户端可以使⽤这个版本号来作为唯⼀的序列号。很少会使⽤zookeeper来⽣成唯⼀ID。主要是由于需要依赖zookeeper，并且是多步调⽤API，如果在竞争较⼤的情况下，需要考虑使⽤分布式锁。因此，性能在⾼并发的分布式环境下，也不甚理想。
7. MongoDB的ObjectId
MongoDB的ObjectId和snowflake算法类似。它设计成轻量型的，不同的机器都能⽤全局唯⼀的同种⽅法⽅便地⽣成它。MongoDB 从⼀开始就设计⽤来作为分布式数据库，处理多个节点是⼀个核⼼要求。使其在分⽚环境中要容易⽣成得多。
其格式如下：
前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5 个字节组合起来，提供了秒级别的唯⼀性。由于时间戳在前，这意味着ObjectId ⼤致会按照插⼊的顺序排列。这对于某些⽅⾯很有⽤，如将其作为索引提⾼效率。这4 个字节也隐含了⽂档创建的时间。绝⼤多数客户端类库都会公开⼀个⽅法从ObjectId 获取这个信息。接下来的3 字节是所在主机的唯⼀标识符。通常是机器主机名
的散列值。这样就可以确保不同主机⽣成不同的ObjectId，不产⽣冲突。为了确保在同⼀台机器上并发的多个进程产⽣的ObjectId 是唯⼀的，接下来的两字节来⾃产⽣ObjectId 的进程标识符(PID)。前9 字节保证了同⼀秒钟不同机器不同进程产⽣的ObjectId 是唯⼀的。后3 字节就是⼀个⾃动增加的计数器，确保相同进程同⼀秒产⽣的ObjectId 也是不⼀样的。同⼀秒钟最多允许每个进程拥有2563(16 777 216)个不同的ObjectId。
对了，在这⾥说⼀下，我⽬前是在职Java开发，如果你现在正在学习Java，了解Java，渴望成为⼀名合格的Java开发⼯程师，在⼊门学习Java的过程当中缺乏基础⼊门的视频教程，可以关注并私信我：01。获取。我这⾥有最新的Java基础全套视频教程。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议