【分布式篇】什么是分布式ID？分布式ID常见解决方案有哪些？

分布式ID

什么是分布式ID

在分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了

个人理解：分布式系统下，在分库分表之后唯一识别ID

分布式ID需要满足的需求

基本需求：

• 全局唯一 ：ID 的全局唯一性肯定是首先要满足的！
• 高性能 ： 分布式 ID 的生成速度要快，对本地资源消耗要小。（生成速度快）
• 高可用 ：生成分布式 ID 的服务要保证可用性无限接近于 100%。（服务禁止挂掉！！）
• 方便易用 ：拿来即用，使用方便，快速接入！（代码方便写）

其他需求

• 安全 ：ID 中不包含敏感信息（如用户）。
• 有序递增 ：如果要把 ID 存放在数据库的话，ID 的有序性可以提升数据库写入速度。并且，很多时候 ，我们还很有可能会直接通过 ID 来进行排序。
• 有具体的业务含义 ：生成的 ID 如果能有具体的业务含义，可以让定位问题以及开发更透明化（通过 ID 就能确定是哪个业务）。
• 独立部署 ：也就是分布式系统单独有一个发号器服务，专门用来生成分布式 ID。这样就生成 ID 的服务可以和业务相关的服务解耦。不过，这样同样带来了网络调用消耗增加的问题。总的来说，如果需要用到分布式 ID 的场景比较多的话，独立部署的发号器服务还是很有必要的。（保证高可用）

分布式 ID 常见解决方案

原文地址：JavaGuide 分布式 ID 常见解决方案

从以下三个维度去分析

1. 数据库维度

基于数据库主键自增实现

CREATE TABLE `sequence_id` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `stub` char(10) NOT NULL DEFAULT '',
  PRIMARY KEY (`id`),
  UNIQUE KEY `stub` (`stub`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

优点 ：

实现起来比较简单、ID 有序递增、存储消耗空间小

缺点 ：

支持的并发量不大、存在数据库单点问题（使用主从模式来提高可用性）

基于数据库的号段模式实现（重要，Leaf和Tinyid框架基于这个模式）

批量获取，然后存在在内存里面，需要用到的时候，直接从内存里面拿就可以了

号：ID号，段：一段一段的取

CREATE TABLE `sequence_id_generator` (
  `id` int(10) NOT NULL,
  `current_max_id` bigint(20) NOT NULL COMMENT '当前最大id',
  `step` int(10) NOT NULL COMMENT '号段的长度',
  `version` int(20) NOT NULL COMMENT '版本号',
  `biz_type`    int(20) NOT NULL COMMENT '业务类型',
   PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

• current_max_id 字段和step字段主要用于获取批量 ID，获取的批量 id 为： current_max_id ~ current_max_id+step。
• version 字段主要用于解决并发问题（乐观锁）,biz_type 主要用于表示业务类型。

相比于数据库主键自增的方式，数据库的号段模式对于数据库的访问次数更少，数据库压力更小。另外，为了避免单点问题，你可以从使用主从模式来提高可用性。

优点 ：

• ID 有序递增、存储消耗空间小
• 对于数据库的访问次数更少，数据库压力更小

缺点 ：

存在数据库单点问题（使用主从模式来提高可用性）

基于Redis集群实现

使用incr命令保证原子性地递增ID

127.0.0.1:6379> set sequence_id_biz_type 1
OK
127.0.0.1:6379> incr sequence_id_biz_type
(integer) 2
127.0.0.1:6379> get sequence_id_biz_type
"2"

优点 ：

性能不错并且生成的 ID 是有序递增的

缺点 ：

存在单点问题，所以要做成Redis集群

2. 算法维度

UUID

比如使用 UUID 作为 MySQL 数据库主键的时候就非常不合适：

• 数据库主键要尽量越短越好，而 UUID 的消耗的存储空间比较大（32 个字符串，128 位）。
• UUID 是无顺序的，InnoDB 引擎下，数据库主键的无序性会严重影响数据库性能。

优点 ：

生成速度比较快、简单易用

缺点 ：

• 存储消耗空间大（32 个字符串，128 位）
• 不安全（基于 MAC 地址生成 UUID 的算法会造成 MAC 地址泄露)、无序（非自增）、没有具体业务含义
• 需要解决重复 ID 问题（当机器时间不对的情况下，可能导致会产生重复 ID）

雪花算法

优点 ：

• 生成速度比较快、生成的 ID 有序递增、比较灵活（可以对 Snowflake 算法进行简单的改造比如加入业务 ID）
• 有很多基于 Snowflake 算法的开源实现比如美团 的 Leaf、百度的 UidGenerator，并且这些开源实现对原有的 Snowflake 算法进行了优化。

缺点 ：

需要解决重复 ID 问题（依赖时间，当机器时间不对的情况下，可能导致会产生重复 ID）。

3. 开源框架维度

UidGenerator(百度)

UidGenerator 是百度开源的一款**基于 Snowflake(雪花算法)**的唯一 ID 生成器。

Leaf(美团，世界上没有两片相同的树叶)

Leaf 提供了 号段模式 和 Snowflake(雪花算法) 这两种模式来生成分布式 ID。

Tinyid(滴滴)

Tinyid 是滴滴开源的一款基于数据库号段模式的唯一 ID 生成器。