当前位置：首页 > news >正文

分布式id

news 2025/9/18 15:08:39

好的，面试官。关于 TDDL（Taobao Distributed Data Layer）中 Sequence 实现分布式 ID 的机制，我来为您详细说明。

TDDL 本身是一个数据库访问中间件，主要负责 SQL 路由、读写分离、分库分表等功能。它并不直接提供类似 Snowflake 或 UUID 的分布式 ID 生成服务，而是通过集成和管理 数据库端的 Sequence 表 来实现全局唯一、有序的 ID 分配。

其核心实现原理可以概括为：“集中式 Sequence 表 + 客户端预取缓存”。

一、核心架构与流程

创建 Sequence 表

在一个中心化的数据库（通常是主库或专门的 ID 库）中创建一张 Sequence 表，例如：

CREATE TABLE sequence_table (name VARCHAR(64) PRIMARY KEY,  -- Sequence 名称，如 'user_id_seq'current_value BIGINT NOT NULL, -- 当前已分配的最大值increment_by INT NOT NULL,     -- 每次递增步长（通常为1）cache_size INT NOT NULL        -- 预取缓存大小
);

初始化一条记录：

INSERT INTO sequence_table (name, current_value, increment_by, cache_size) 
VALUES ('user_id_seq', 1, 1, 100);

客户端（TDDL）获取 ID 段（Step 1：数据库交互）
- 当应用首次请求 ID 时，TDDL 会向数据库发起一次更新操作，原子性地获取一个 ID 区间：
```
UPDATE sequence_table 
SET current_value = current_value + cache_size 
WHERE name = 'user_id_seq';SELECT current_value - cache_size AS min_id, current_value AS max_id 
FROM sequence_table 
WHERE name = 'user_id_seq';
```
- 这个操作是原子的，确保了即使多个 TDDL 实例并发请求，也能获得不重叠的 ID 区间。
客户端缓存 ID 段（Step 2：本地分配）
- TDDL 将获取到的区间（如 min_id=1001, max_id=1100）缓存在内存中。
- 后续的应用请求 ID 时，TDDL 直接从本地缓存中按序分配（如 1001, 1002, ..., 1100），无需访问数据库，性能极高。
自动预取下一段（Step 3：异步填充）
- 当本地缓存的 ID 即将用完（例如还剩 10%），TDDL 会异步地再次执行 UPDATE...SELECT 操作，获取下一个区间并填充到本地缓存。
- 这样保证了 ID 的持续供应，避免阻塞。

二、关键设计与优势

特性	实现方式	优势
全局唯一性	数据库 `UPDATE` 操作保证原子性	多实例并发下 ID 不重复
高可用	Sequence 表可部署在高可用数据库集群（如 RDS 主备）	单点故障风险低
高性能	客户端缓存 + 批量获取	大部分请求无数据库开销
单调递增	基于数据库自增逻辑	满足业务对有序 ID 的需求（如分页）
可扩展	支持多个 Sequence 名（`name` 字段）	不同业务可独立分配

三、潜在问题与应对

数据库成为瓶颈？
- 应对：通过增大 cache_size（如 1000），显著降低数据库压力。即使每秒百万级 ID 请求，数据库每秒只需处理几百次更新。
缓存失效导致 ID 跳跃？
- 如果应用重启，未用完的缓存 ID 段会丢失，导致 ID 不连续（跳跃）。
- 应对：这是典型的时间换性能的权衡。业务通常可接受“不连续但唯一”，若严格要求连续，需牺牲性能（每次请求都查库）。
数据库宕机？
- Sequence 表不可用时，无法获取新 ID 段。
- 应对：依赖数据库的高可用架构（如主备切换、容灾）。

四、与其他方案对比

方案	原理	优点	缺点
TDDL Sequence	DB 表 + 客户端缓存	简单、有序、易维护	依赖 DB，ID 可能跳跃
Snowflake	时间戳 + 机器码 + 序号	完全去中心化，高性能	ID 过长，依赖时钟同步
Redis INCR	Redis 原子自增	简单、高性能	依赖 Redis，单点风险
UUID	随机生成	完全去中心化	无序，过长，不易读