1.ID生成系统的需求
1.全局唯一性：不能出现重复的ID，最基本的要求；
2.趋势递增：MySQL InnoDB引擎使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应尽量使用有序的主键保证写入性能；
3.单调递增：保证下一个ID一定大于上一个ID；
4.信息安全：如果ID是连续递增的，恶意用户就可以很容易的窥见订单号的规则，从而猜出下一个订单号，如果是竞争对手，就可以直接知道我们一天的订单量。所以在某些场景下，需要ID无规则；
第3、4两个需求是互斥的，无法同时满足
其他要求：
同时，在大型分布式网站架构中，除了需要满足ID生成自身的需求外，还需要ID生成系统可用性极高。想象以下，如果ID生成系统瘫痪，那么整个业务无法进行下去，那将是一次灾难。因此，总结ID生成系统还需要满足如下的需求：
1.高可用，可用性达到5个9或4个9；
2.高QPS，性能不能太差，否则容易造成线程堵塞；
3.平均延迟和TP999(保证99.9%的请求都能成功的最低延迟)延迟都要尽可能低；
2.分布式系统唯一ID生成策略
2.1 数据库自增长序列或字段
1. 数据库自增长序列或字段
最常见的方式。利用数据库，全数据库唯一。
优点：
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.2 基于redis的分布式ID生成器
当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。
这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。
1. 可以用Redis的原子操作 INCR和INCRBY来实现
Redis Incr 命令将 key 中储存的数字值增一，如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。
Redis Incrby 命令将 key 中储存的数字加上指定的增量值，如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。
2. 可以利用redis的lua脚本执行功能，在每个节点上通过lua脚本生成唯一ID
Redis从2.6版本开始引入对Lua脚本的支持，通过在服务器中嵌入Lua环境，Redis客户端可以使用Lua脚本，直接在服务端原子的执行多个Redis命令。
源码：https://github.com/hengyunabc/redis-id-generator
可以使用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）需要编码和配置的工作量比较大
2.3 Twitter:SnowFlake雪花算法
Twitter的雪花算法实现（Java）
2.4 百度开源分布式Id生成器uid-generator
源码：https://github.com/baidu/uid-generator
2.5 Leaf：美团分布式ID生成服务开源
源码：https://github.com/Meituan-Dianping/Leaf
参考：
扫一扫
154
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
