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

什么是幂等

news 2025/7/10 12:54:35

1. 主键原则：设计不带业务意义的主键

定义：主键是数据库表中用于唯一标识每一行记录的字段（或字段组合）。设计不带业务意义的主键（如自增ID、UUID），意味着主键的值与业务逻辑无关，仅用于技术层面的标识。
核心原则：
1. 无业务意义：主键的值不应反映业务含义（例如，订单号、用户邮箱等）。
  - 原因：如果主键是业务相关的字段（如订单号），当业务规则变化时，主键可能需要修改，这会破坏数据的稳定性和外键关联。
2. 唯一约束：主键必须保证全局唯一性，且不允许空值（NOT NULL）。
  - 作用：确保每条记录在表中是唯一的，避免数据冗余和查询歧义。
3. 稳定性：主键值一旦生成，应尽量避免更新。
  - 原因：主键变更可能导致依赖它的外键约束失效，甚至引发数据一致性问题。

示例：

CREATE TABLE orders (order_id INT AUTO_INCREMENT PRIMARY KEY, -- 自增主键（无业务意义）customer_id INT,order_number VARCHAR(20) UNIQUE, -- 唯一约束（与业务相关）...
);

order_id 是技术主键（无业务意义），而 order_number 是业务字段（需通过唯一约束保证唯一性）。

2. 幂等性（Idempotency）是什么意思？

定义：幂等性是指对同一操作执行多次，其结果与执行一次的效果相同。
- 数学定义：若函数 $ f(x) $ 满足 $ f(f(x)) = f(x) $，则称该函数是幂等的。
- 在数据库中的含义：无论操作（如插入、更新）执行多少次，最终的数据状态只改变一次，避免重复操作导致的副作用。
典型场景：
- 接口重试：网络波动导致请求失败后重试，需确保重复请求不会重复扣款或生成重复订单。
- 消息队列：消息可能被重复消费，需保证重复消费不会破坏数据一致性。
- 分布式系统：多个节点可能并发处理同一请求，需防止数据冲突。
数据库中如何实现幂等性？
1. 唯一约束（Unique Constraint）
  - 通过主键或唯一索引限制字段的唯一性，防止重复插入。
  - 示例：订单号设置为唯一约束，重复提交同一订单号时，数据库会抛出异常。
```
CREATE TABLE orders (order_id INT PRIMARY KEY,order_number VARCHAR(20) UNIQUE
);
```
2. 乐观锁（Optimistic Locking）
  - 在表中添加版本号（version）字段，每次更新时检查版本号是否一致。
  - 示例：更新用户余额时，先检查当前版本号，若不一致则拒绝操作。
```
UPDATE users 
SET balance = balance - 100, version = version + 1 
WHERE user_id = 1 AND version = 5;
```
3. 请求序列号（Token/幂等Key）
  - 客户端生成唯一请求ID，服务端记录已处理的请求ID，重复请求直接返回结果。
  - 示例：支付接口使用 request_id 防止重复扣款。
```
CREATE TABLE idempotency_keys (request_id VARCHAR(36) PRIMARY KEY,created_at TIMESTAMP
);
```
4. 防重表
  - 单独维护一个幂等性表，记录已处理的业务键（如订单号）。
  - 示例：插入订单前，先检查防重表是否存在相同业务键。
```
BEGIN TRANSACTION;
INSERT INTO idempotency_table (business_key) VALUES ('order_123');
INSERT INTO orders (order_id, business_key) VALUES (1, 'order_123');
COMMIT;
```

3. 主键原则与幂等性的关系

主键的唯一性是幂等性的基础：
主键的唯一约束直接防止了重复数据的插入，是实现幂等性的最简单方式之一。
幂等性需要结合业务逻辑：
单纯依赖主键可能不足以应对复杂场景（如更新操作），需结合乐观锁、请求序列号等机制。
设计建议：
1. 技术主键 + 唯一约束：
  使用无业务意义的技术主键（如自增ID），并通过唯一约束保障业务字段的唯一性。
2. 幂等性表分离：
  对高频幂等性需求的场景（如支付），单独维护幂等性表，避免污染业务表。
3. 事务一致性：
  幂等性操作（如插入防重表和业务表）需放在同一事务中，确保原子性。