idgenerator 会重复吗_终极版：分布式唯一ID的几种生成方案

在业务开发中，大量场景需要唯一ID来进行标识：用户需要唯一身份标识、商品需要唯一标识、消息需要唯一标识、事件需要唯一标识等，都需要全局唯一ID，尤其是复杂的分布式业务场景中全局唯一ID更为重要。

那么，分布式唯一ID有哪些特性或要求呢？

① 唯一性：生成的ID全局唯一，在特定范围内冲突概率极小。

② 有序性：生成的ID按某种规则有序，便于数据库插入及排序。

③ 可用性：可保证高并发下的可用性, 确保任何时候都能正确的生成ID。

④ 自主性：分布式环境下不依赖中心认证即可自行生成ID。

⑤ 安全性：不暴露系统和业务的信息, 如：订单数,用户数等。

分布式唯一ID有哪些生成方法呢？

总的来说，大概有三大类方法，分别是：数据库自增ID、UUID生成、snowflake雪花算法。

下面分别说下这三大类及其优化方案：

一、数据库自增ID

核心思想：使用数据库的id自增策略(如: Mysql的auto_increment)。

优点：

① 简单，天然有序。

缺点：

① 并发性不好。

② 数据库写压力大。

③ 数据库故障后不可使用。

④ 存在数量泄露风险。

针对以上缺点，有以下几种优化方案：

数据库水平拆分，设置不同的初始值和相同的自增步长

核心思想：将数据库进行水平拆分，每个数据库设置不同的初始值和相同的自增步长。

如图所示，可保证每台数据库生成的ID是不冲突的，但这种固定步长的方式也会带来扩容的问题，很容易想到当扩容时会出现无ID初始值可分的窘境，解决方案有：

① 根据扩容考虑决定步长。

② 增加其他位标记区分扩容。

这其实都是在需求与方案间的权衡，根据需求来选择最适合的方式。

2. 批量缓存自增ID

核心思想：如果使用单台机器做ID生成，可以避免固定步长带来的扩容问题(方案1的缺点)。

具体做法是：每次批量生成一批ID给不同的机器去慢慢消费，这样数据库的压力也会减小到N分之一，且故障后可坚持一段时间。

如图所示，但这种做法的缺点是服务器重启、单点故障会造成ID不连续。

还是那句话，没有最好的方案，只有最适合的方案。

3. Redis生成ID

核心思想：Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的。

优点：

① 不依赖于数据库，灵活方便，且性能优于数据库。

② 数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点ÿ