分布式id

原创

mb5861ee280b600 2021-09-07 15:59:27 博主文章分类：分布式杂项 ©著作权

文章标签 分布式id 分布式数据库 redis 自增 文章分类 代码人生

©著作权归作者所有：来自51CTO博客作者mb5861ee280b600的原创作品，请联系作者获取转载授权，否则将追究法律责任

分布式id要考虑的问题

全局唯一
高可用：确保任何时候都能正确生成id
高性能：id生成响应要快、低延时，否则反倒会成为业务瓶颈
简单易用：在设计和实现上要尽可能的简单，拿来即用
是否需要是有序递增、需要包含日期时间等特殊部分：具体看业务场景

常见实现方案

uuid
数据库主键自增
号段模式
Redis
雪花算法snowflake

uuid

标准格式：以-将36个字符分为5段，xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，包含

当前日期时间
时钟序列
全局唯一的IEEE机器识别号。如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

//根据需要去除-
String uuid = UUID.randomUUID().toString().replaceAll("-", "");

优点

本地生成，没有网络通信消耗，id生成性能高，没有高可用风险
简单易用

缺点

数据库主见字段长度越短越好，uuid长度太长，如果作为数据库主键、索引，查询效率低；在InnoDB引擎下，uuid的无序性会导致数据位置频繁变动，不易存储，存储、查询对数据库性能消耗较大，严重影响性能。
不能表示具体的业务含义
无序，不满足递增需求
uuid中可能包含了mac地址，有mac地址泄露的风险

uuid一般用于生成文件名。

数据库主键自增

优点

实现简单、性能可以接受
有序递增

缺点

数据库常见架构是一主多从+读写分离，生成自增ID是写请求，主库故障时不能生成id，有单点故障风险，可用性低；主库的写性能决定id的生成性能，性能不高。
不同数据库实现方式不同，数据库迁移时需要额外处理。
分库分表时会有麻烦。

优化方案：双（多）主模式集群

id字段需要设置初始值、步长。

eg. 主库1的id初始值是1，主库2的id初始值是2，步长都是2，则主库1生成的id是1、3、5、7、9…，主库2生成的id是2、4、6、8、10…

优点

提升了可用性、解决了主库单点故障问题
多个主库，提升了生成id的性能

缺点

后续扩容麻烦，增加主库节点时需要修改其他主库的初始值、步长设置

号段模式

数据表 id_generator

字段	描述
id	这张表的主键字段
biz_type	业务类型
max_id	已使用的号段区间的最大值
step	步长，即号段中id的数量
version	版本号，用于实现乐观锁，更新此表时使用

初始记录示例

1 1 0 2000 0

1这种类型的业务申请号段时

-- 先查询此种业务类型已使用的最大id、步长、版本号，此次要申请的号段是（max_id，max_id+step）。
-- 0、2000 =》(0，0+2000】
select max_id, step, version from id_generator where biz_type=1;

-- 再更新此种业务类型对应的记录，version保证并发下的整个申请操作的原子性
update id_generator set max_id=#{max_id+step}, version=version+1 where biz_type=1 and version=#{version};