唯一ID生成方案
2020-11-13 本文已影响0人
轻轻敲醒沉睡的心灵
系统唯一ID是我们在设计一个系统的时候常常会遇见的问题，也常常为这个问题而纠结。生成ID的方法有很多，适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。
一般业务中ID
1. 数据库自增长序列或字段
最常见的方式。利用数据库，全数据库唯一。
- 优点
- 简单，代码方便，性能可以接受。
- 数字ID天然排序，对分页或者需要排序的结果很有帮助。
- 缺点
- 不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
- 在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
- 在性能达不到要求的情况下，比较难于扩展。
- 如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
- 分表分库的时候会有麻烦。
- 优化方案
- 针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。
2. UUID
见 UUID的介绍。可以利用数据库也可以利用程序生成，一般来说全球唯一。
# mysql利用sql生成UUID，如下：
SELECT UUID();
SELECT REPLACE(UUID(), '-', '');
- 优点
- 简单，代码方便。
- 生成ID性能非常好，基本不会有性能问题。
- 全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。
- 缺点
- 没有排序，无法保证趋势递增。
- UUID往往是使用字符串存储，查询的效率比较低。
- 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
- 传输数据量大。
- 不可读。
3. 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进行累加。
- 优点：
- 不依赖于数据库，灵活方便，且性能优于数据库。
- 数字ID天然排序，对分页或者需要排序的结果很有帮助。
- 缺点：
- 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
- 需要编码和配置的工作量比较大。
4. 雪花算法（Snowflake）
参考文章Snowflake-雪花算法
- 优点：
- 高性能高可用：生成时不依赖于数据库，完全在内存中生成。
- 容量大：每秒中能生成数百万的自增ID。
- ID自增：存入数据库中，索引效率高。
- 缺点：
- 依赖与系统时间的一致性，如果系统时间被回调，或者改变，可能会造成id冲突或者重复。
实际中我们的机房并没有那么多，我们可以改进改算法，将10bit的机器id优化成业务表或者和我们系统相关的业务。
5. 百度 uid-generator
具体说明，参考项目GitHub地址
6. 美团-Leaf
具体参考
7. 滴滴-Tinyid
具体参考：tiny简介
