技术深度：数据与存储

适用范围：后端工程师、架构师、DBA、SRE，以及需要做出数据库选型与幂等设计决策的技术管理者。适用于关系型/NoSQL/NewSQL 数据库选型、索引与事务优化、分布式数据架构设计，以及支付、消息队列、微服务链路等幂等性实现场景。

更新摘要（v2 · 2026-08 更新）：

• 结构化升级为 6 节骨架（导言 / 核心方法论 / 关键流程 / 工具与实战 / 常见误区 / 进阶延展）
• 为全部 Mermaid 图补充 --- title: ... --- frontmatter，并在每张图后追加文字解读
• 整合 MySQL 9.x、PostgreSQL 17/18、TiDB、pgvector 等 2025-2026 最新数据
• 将原"综合参考资料"融入"进阶延展"，形成统一延伸阅读入口

1. 导言

1.1 Why：数据与存储为何是技术深度的核心

数据是软件系统的核心资产，而数据库与幂等性则是保障数据正确性的两大支柱。数据库提供了数据的持久化存储、一致性查询与并发控制机制；幂等性则确保在不可靠的网络与分布式环境下，重复操作不会破坏数据的一致性。两者在工程实践中紧密关联：数据库的唯一索引是幂等去重的基础设施，事务隔离级别与锁机制是幂等实现的底层保障，而分布式数据库架构中的 Saga 模式更要求每一步补偿操作都必须幂等。

1.2 What：本文覆盖的两大主题

• 第一篇：数据库知识——从数据库选型、核心技术原理（索引、事务、锁、MVCC）、分布式架构到工程实践与趋势展望，系统梳理数据库领域的核心知识体系
• 第二篇：幂等性设计与实现——从幂等性的数学定义出发，深入幂等令牌、唯一性保证、去重机制等核心原理，覆盖分布式系统中的幂等实现方案与工程实践

1.3 数据库技术演进

数据库技术经历了从层次模型、网状模型到关系模型的范式跃迁。1970 年 Edgar F. Codd 发表《A Relational Model of Data for Large Shared Data Banks》，奠定了关系型数据库的理论基础。此后数十年，数据库系统沿以下脉络持续演进：

1.4 2025 年数据库生态全景

当前数据库生态呈现多模融合、云原生化、AI 驱动三大趋势：

• 关系型数据库仍是核心生产负载的主力，MySQL 8.x/9.x 与 PostgreSQL 17/18 持续增强分析能力与分布式特性
• 文档型数据库（MongoDB 8.0、DocumentDB）在内容管理、IoT 场景保持优势
• 时序数据库（TimescaleDB、InfluxDB 3.0、TDengine）随可观测性与 IoT 爆发而增长
• 向量数据库（Milvus 2.x、Weaviate、Qdrant）因 LLM/RAG 应用成为新热点
• 云原生数据库（Aurora、PolarDB、AlloyDB）以 Serverless 形态降低运维复杂度
• 嵌入式数据库（SQLite、DuckDB、libSQL）在边缘计算与本地分析场景崛起

1.5 幂等性的重要性

幂等性在现代软件架构中至关重要，其核心价值体现在：

1. 容错性：网络不可靠环境下，客户端可安全重试而不产生副作用
2. 一致性：分布式系统中防止重复操作导致的数据不一致
3. API 契约：RESTful API 规范中，幂等性是 HTTP 方法语义的核心组成部分
4. 运维安全：手动重试、自动故障转移、消息重投递等场景下保障系统正确性

2. 核心方法论

2.1 数据库选型决策框架

2.1.1 选型维度

数据库选型应从以下维度进行系统性评估：

2.1.2 选型决策树

决策树以"数据结构是否固定"为第一分流点，结构固定走关系型路径，结构灵活走 NoSQL 路径。关系型路径再根据"强一致性事务"与"水平扩展"需求进一步细分到 MySQL、PostgreSQL 或 NewSQL。NoSQL 路径则按数据类型直接映射到文档、键值、图、向量、宽列等专用数据库。

2.1.3 MySQL vs PostgreSQL：2025 年对比

选型建议：

• 选择 MySQL：团队有丰富 MySQL 运维经验、读密集型场景、需要成熟的主从复制生态、使用 Percona/XtraBackup 等工具链
• 选择 PostgreSQL：需要复杂查询与分析、地理空间处理、JSONB 深度使用、向量检索（AI 应用）、细粒度权限控制
• 核心原则：团队对技术的驾驭能力 > 技术本身的纸面优势；数据库迁移成本极高，选型需审慎

2.2 索引核心原理

2.2.1 B+Tree 索引

B+Tree 是关系型数据库最常用的索引结构，其核心特性：

• 非叶子节点仅存储键值，叶子节点存储完整数据（或指向数据的指针）
• 叶子节点通过双向链表连接，支持高效范围扫描
• 树高度通常为 3–4 层，可支撑千万级数据量的点查

B+Tree 的叶子节点双向链表是实现范围查询的关键：一旦定位到范围起点，即可沿链表顺序扫描，无需回溯到根节点。这种结构使得 B+Tree 同时擅长等值查询与范围查询。

2.2.2 索引类型对比

2.2.3 索引选择性

索引选择性（Selectivity）= 不同值数量 / 总行数，选择性越高索引效率越好。经验法则：选择性 < 0.1 的列不适合单独建索引。

2.3 事务与隔离级别

2.3.1 ACID 原则

2.3.2 隔离级别与并发异常

图中清晰展示了隔离级别从低到高逐步阻止并发异常的过程：Read Uncommitted 不阻止任何异常，Read Committed 阻止脏读，Repeatable Read 额外阻止不可重复读，Serializable 阻止全部三类异常。

关键差异：MySQL InnoDB 在 RR 级别通过 Next-Key Lock（记录锁 + 间隙锁）在一定程度上阻止幻读；PostgreSQL 的 RR 级别基于 MVCC 快照隔离实现，能避免幻读（提供比 SQL 标准更严格的保证），其 SERIALIZABLE 级别再通过 SSI（可串行化快照隔离）进一步防止写偏斜异常。InnoDB 的默认隔离级别为 REPEATABLE READ。

2.4 锁机制

锁体系以"乐观/悲观"为顶层分类：乐观锁假设冲突概率低，提交时检测；悲观锁假设冲突概率高，操作前加锁。悲观锁再细分为共享锁、排他锁、意向锁及各种行级锁。

乐观锁 vs 悲观锁：

InnoDB 锁兼容矩阵：

2.5 MVCC 多版本并发控制

MVCC 是现代关系型数据库实现高并发读写的核心机制，使读操作不阻塞写操作、写操作不阻塞读操作。

时序图展示了 MVCC 的核心机制：T1 在 T2 提交前读取数据时，通过 Read View 判断新版本不可见，沿 roll_ptr 找到旧版本返回 balance=5000。这种"快照读"使得读操作无需加锁即可获得一致性视图。

MySQL vs PostgreSQL MVCC 差异：

2.6 幂等性核心概念

2.6.1 定义

幂等性（Idempotency）是指一个操作在任意多次执行后所产生的系统状态与副作用，均与一次执行完全相同。数学形式化表达：

$$f(f(x)) = f(x), \quad \forall x$$

该定义涵盖两个维度：

2.6.2 语义范畴与语法保证

幂等是一个语义范畴（Semantic Category）对行为结果的定义——它描述的是"结果应该怎样"，而非"代码应该怎么写"。将语义目标转化为语法保证（Syntactic Guarantee）需要严谨的工程设计：通过幂等令牌、唯一性约束、去重机制等规则确保语义达成。

2.6.3 幂等性分类

强幂等 vs 弱幂等：

自然幂等 vs 设计幂等：

• 自然幂等（Natural Idempotency）：操作本身具有幂等语义，无需额外机制保证（如 abs(x)、x = 5、HTTP GET）
• 设计幂等（Designed Idempotency）：操作本身非幂等，需通过工程手段实现（如 balance -= 100、消息发送）

2.6.4 HTTP 语义中的幂等

RFC 9110 对 HTTP 方法的幂等性有明确定义：

关键区分：HTTP 幂等性是服务器端语义承诺，而非协议层强制保证。开发者需自行在服务端实现幂等逻辑。

3. 关键流程

3.1 分布式数据库架构演进

架构演进遵循"先垂直后水平"的路径：单机到主从解决读扩展与高可用，垂直分库解决业务耦合，水平分片解决单库容量瓶颈，NewSQL 则在保持 SQL 兼容性的同时提供原生分布式能力。

3.2 读写分离

读写分离通过主节点处理写操作、从节点处理读操作，实现读能力的水平扩展。

代理层负责将读请求路由到从节点、写请求路由到主节点，并对应用透明。复制模式的选择决定了一致性与性能的权衡。

复制模式对比：

主从延迟应对策略：

1. 强制走主库：对一致性要求高的读请求直接路由到主节点
2. 等待复制位点的同步复制：使用 WAIT_FOR_EXECUTED_GTID_SET() 等待从库追上
3. 中间件路由控制：在 Proxy 层实现读写分离 + 一致性路由策略

3.3 分库分表

当单表数据量超过千万级或单库 QPS 达到瓶颈时，需进行水平拆分。

分片键选择原则：高基数、查询覆盖（80% 以上查询条件包含分片键）、避免热点。

常见分片中间件：

3.4 NewSQL 分布式数据库

TiDB 架构采用存算分离设计：TiDB Server 负责 SQL 解析与执行，PD 负责调度与元数据管理，TiKV 提供行存储，TiFlash 提供列存储实现 HTAP。

3.5 幂等令牌机制

幂等令牌是客户端与服务端识别同一请求（或同一请求的多次重试）的唯一标识。

时序图展示了幂等令牌的三条分支：新令牌走完整业务流程，处理中令牌返回冲突，已完成令牌返回缓存响应。这种设计确保同一请求无论被提交多少次，业务逻辑只执行一次。

令牌生成协议要点：

• 令牌由客户端生成，确保重试时携带相同令牌
• 令牌需具备全局唯一性（跨客户端、跨时间）
• 令牌的生命周期需与业务语义绑定，而非与单次 HTTP 请求绑定

3.6 唯一性保证与去重

服务端通过数据库唯一索引确保同一幂等令牌对应的业务操作仅被执行一次。

为什么读检查（Read-then-Write）不可靠：

图中展示了 Check-then-Act 竞争条件：两个并发请求均读到"不存在"后各自插入，导致重复。唯一索引通过数据库的原子性约束从根本上解决此问题。

去重机制对比：

推荐方案：先做后判 + 唯一索引，将并发控制交由数据库事务保证。

3.7 请求状态机

状态机定义了幂等请求的完整生命周期：PROCESSING 是中间态，SUCCESS 和 FAILURE 是终态。SUCCESS 状态的重试直接返回缓存响应，FAILURE 状态允许重新处理，PROCESSING 持续中的重试返回冲突。

3.8 分布式幂等架构总览

架构图展示了幂等机制的完整分层：客户端 SDK 负责令牌生成与重试，API 网关负责令牌校验与限流，幂等中间件负责令牌注册与状态管理（Redis 缓存 + PostgreSQL 持久化），业务服务专注于核心逻辑。这种分层设计使幂等能力可复用、可治理。

4. 工具与实战

4.1 现代数据库特性

4.1.1 MySQL 8.0+ / 9.x 新特性

4.1.2 PostgreSQL 17/18 新特性

4.1.3 向量数据库与 AI 应用

大语言模型（LLM）的兴起催生了向量数据库需求，核心场景为 RAG（Retrieval-Augmented Generation） 架构中的语义检索。

RAG 架构分为离线索引与在线查询两条链路：离线将文档语料通过 Embedding 模型转换为向量并入库，在线将用户查询同样向量化后在向量数据库中检索 Top-K 相似结果，作为 LLM 的上下文增强生成回答。

向量索引算法对比：

pgvector 实战：

-- 启用扩展
CREATE EXTENSION vector;

-- 创建带向量列的表
CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding VECTOR(1536)
);

-- 创建 HNSW 索引
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops);

-- 语义相似度查询
SELECT id, content,
       1 - (embedding <=> '[0.01, 0.02, ...]'::vector) AS similarity
FROM documents
ORDER BY embedding <=> '[0.01, 0.02, ...]'::vector
LIMIT 10;

4.2 索引优化实战

4.2.1 EXPLAIN 执行计划分析

EXPLAIN ANALYZE
SELECT o.order_id, o.total_amount, u.name
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'PAID' AND o.created_at > '2025-01-01';

关键指标解读：

4.2.2 索引优化策略

最左前缀原则：

-- 索引: idx_abc (a, b, c)
-- ✅ 命中: WHERE a = 1
-- ✅ 命中: WHERE a = 1 AND b = 2
-- ✅ 命中: WHERE a = 1 AND b = 2 AND c = 3
-- ❌ 不命中: WHERE b = 2 AND c = 3
-- ⚠️ 部分命中: WHERE a = 1 AND c = 3（仅用到 a）

覆盖索引：索引包含查询所需的所有列，避免回表。

-- 覆盖索引优化
CREATE INDEX idx_user_status_created
    ON orders (user_id, status, created_at, order_id);

-- 查询可直接从索引获取数据，无需回表
SELECT order_id, created_at
FROM orders
WHERE user_id = 1001 AND status = 'PAID';

索引下推（ICP, Index Condition Pushdown）：MySQL 5.6+ 在存储引擎层过滤索引条件，减少回表次数。

4.3 事务设计模式

4.3.1 事务性 Outbox 模式

解决事务内包含不可逆操作（如消息发送）的一致性问题：

Outbox 模式将消息写入与业务操作放在同一事务中，确保"要么都成功，要么都失败"。Relay 线程异步轮询 Outbox 表并发送消息，实现最终一致性。

4.3.2 Saga 模式

长事务拆分为多个本地事务，通过补偿操作实现最终一致性：

Saga 模式中每一步都有对应的补偿操作，任一步骤失败时按逆序执行已完成步骤的补偿。补偿操作必须幂等，因为可能因超时重试而被多次执行。

4.4 分布式唯一 ID 生成

4.5 分布式锁

4.5.1 Redis RedLock 算法

RedLock 通过多个独立 Redis 实例实现分布式互斥，需获得多数派（N/2+1）锁才算获取成功。

RedLock 争议与注意事项：

• Martin Kleppmann 指出 RedLock 在时钟跳变、进程暂停等场景下可能不安全
• Antirez 的反驳：多数场景下 RedLock 足够可靠，但需理解其边界
• 建议：对正确性要求极高的场景（如金融），优先使用基于 Raft/Paxos 共识的分布式锁服务（如 etcd、ZooKeeper、Consul）

4.5.2 基于 etcd 的分布式锁

etcd 基于 Raft 共识协议提供强一致性分布式锁，天然避免 RedLock 的时钟依赖问题：

import etcd3

def acquire_idempotent_lock(key: str, ttl: int = 10) -> bool:
    client = etcd3.client()
    lock = client.lock(f"idempotent:{key}", ttl=ttl)
    acquired = lock.acquire(timeout=5)
    if acquired:
        try:
            execute_business_logic(key)
        finally:
            lock.release()
    return acquired

4.6 事件溯源 + CQRS

事件溯源（Event Sourcing）与 CQRS（Command Query Responsibility Segregation）为幂等提供了一种根本性的架构保障。

事件溯源通过 APPEND ONLY 的事件存储与命令去重检查，从根本上保证同一命令只被处理一次。投影构建读模型，进程管理器编排 Saga，查询服务对外提供查询能力。

4.7 支付场景幂等实现

CREATE TABLE payment_transaction (
    id               BIGINT PRIMARY KEY AUTO_INCREMENT,
    idempotency_key  VARCHAR(128) NOT NULL UNIQUE,
    merchant_id      VARCHAR(64) NOT NULL,
    amount           DECIMAL(12, 2) NOT NULL,
    currency         CHAR(3) NOT NULL DEFAULT 'CNY',
    status           ENUM('PROCESSING', 'SUCCESS', 'FAILURE', 'REFUNDED') NOT NULL,
    channel          VARCHAR(32) NOT NULL,
    channel_tx_id    VARCHAR(128),
    created_at       TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at       TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_merchant (merchant_id),
    INDEX idx_status (status)
);

public class PaymentService {

    private final PaymentTransactionRepository txRepo;
    private final PaymentChannelClient channelClient;

    public PaymentResult process(PaymentRequest request) {
        String idempotencyKey = request.getIdempotencyKey();

        PaymentTransaction existingTx = txRepo.findByIdempotencyKey(idempotencyKey);
        if (existingTx != null) {
            return handleExistingTransaction(existingTx);
        }

        PaymentTransaction tx = new PaymentTransaction();
        tx.setIdempotencyKey(idempotencyKey);
        tx.setAmount(request.getAmount());
        tx.setStatus(TransactionStatus.PROCESSING);

        try {
            txRepo.save(tx);
        } catch (DuplicateKeyException e) {
            PaymentTransaction concurrentTx = txRepo.findByIdempotencyKey(idempotencyKey);
            return handleExistingTransaction(concurrentTx);
        }

        try {
            ChannelResponse response = channelClient.charge(
                request.getChannel(), request.getAmount(), idempotencyKey
            );
            tx.setStatus(TransactionStatus.SUCCESS);
            tx.setChannelTxId(response.getTransactionId());
            txRepo.update(tx);
            return PaymentResult.success(tx);
        } catch (ChannelException e) {
            tx.setStatus(TransactionStatus.FAILURE);
            txRepo.update(tx);
            return PaymentResult.failure(e.getMessage());
        }
    }

    private PaymentResult handleExistingTransaction(PaymentTransaction tx) {
        return switch (tx.getStatus()) {
            case SUCCESS -> PaymentResult.success(tx);
            case FAILURE -> PaymentResult.failure("Previous attempt failed, retry allowed");
            case PROCESSING -> PaymentResult.conflict("Request is being processed");
            default -> PaymentResult.failure("Unknown status");
        };
    }
}

4.8 消息队列幂等实现

消费者幂等策略通过"去重记录写入 + 业务执行"在同一事务中完成，确保消息不丢失、不重复处理。

4.9 微服务链路中的多层幂等

多层幂等设计原则：

1. 令牌传递与派生：下游服务的幂等令牌由上游令牌 + 下游操作标识确定性派生（如 HMAC(K1, "service-B-operation")）
2. 每层独立去重：每个服务维护自身的幂等记录，不依赖上游或下游的去重能力
3. 响应缓存：每层缓存已完成的响应，重试时直接返回
4. 超时与补偿：任一层超时后，上游需根据下游状态决定重试或补偿

4.10 连接池配置

4.11 慢查询诊断

常用诊断工具：

4.12 唯一索引与 NULL 值陷阱

唯一索引保证列（或列组合）值的唯一性，但与 NULL 组合时存在语义陷阱：

问题：SQL 标准中 NULL != NULL，因此 (X=1, Y=NULL) 与 (X=1, Y=NULL) 被视为不同行，唯一约束不生效。

-- MySQL: 允许多条 (1, NULL)，唯一约束不阻止
CREATE TABLE orders (
    order_id INT PRIMARY KEY,
    user_id INT NOT NULL,
    coupon_code VARCHAR(32) NULL,
    UNIQUE KEY uk_user_coupon (user_id, coupon_code)
);

-- 插入以下数据均成功（不符合业务预期）
INSERT INTO orders VALUES (1, 100, NULL);
INSERT INTO orders VALUES (2, 100, NULL);  -- 预期失败，实际成功

解决方案：

-- 方案1：使用 Sentinel 值替代 NULL
ALTER TABLE orders MODIFY coupon_code VARCHAR(32) NOT NULL DEFAULT '';

-- 方案2：PostgreSQL 可使用部分索引（Partial Index）
CREATE UNIQUE INDEX uk_user_coupon ON orders (user_id, coupon_code)
    WHERE coupon_code IS NOT NULL;

5. 常见误区

5.1 数据库常见陷阱

5.2 事务常见误用模式

5.3 幂等常见陷阱

陷阱 1：令牌生成时机错误

❌ 错误：在重试时重新生成令牌
   请求1: POST /pay { idempotency_key: "abc" }  → 超时
   请求2: POST /pay { idempotency_key: "def" }  → 重复扣款

✅ 正确：令牌在首次请求时生成，重试复用同一令牌
   请求1: POST /pay { idempotency_key: "abc" }  → 超时
   请求2: POST /pay { idempotency_key: "abc" }  → 幂等命中

陷阱 2：令牌被误删

数据库回滚（Rollback）可能导致已使用的令牌被删除，客户端无法感知该请求已被处理，从而生成新令牌重新提交。

解决方案：将幂等记录存储在独立于业务表的数据源中，或使用独立事务写入幂等记录。

陷阱 3：竞争条件（Race Condition）

读检查（Check-before-Act）模式在并发场景下不可靠：

❌ 错误模式：
   if (!exists(key)) {        // 并发请求均通过此检查
       insert(key, data);     // 多个请求均插入成功
   }

✅ 正确模式：
   try {
       insert(key, data);     // 依赖唯一索引，重复插入抛异常
   } catch (DuplicateKeyException e) {
       return query(key);     // 幂等命中，返回已有结果
   }

陷阱 4：PROCESSING 状态无超时处理

请求处于 PROCESSING 状态时，若服务崩溃，令牌将永久锁定。

解决方案：为 PROCESSING 状态设置超时阈值，超时后允许重新处理或标记为 FAILURE。

陷阱 5：多层幂等漏洞

调用链中任一服务未实现幂等，整体幂等性即被破坏。需确保链路上所有服务均独立实现幂等机制。

陷阱 6：幂等令牌与业务操作不在同一事务

❌ 错误：
   1. INSERT idempotency_record (key, PROCESSING)   -- 事务1
   2. 执行业务逻辑                                    -- 事务2
   3. UPDATE idempotency_record SET status=SUCCESS   -- 事务1

   若步骤2失败但步骤1已提交，令牌状态为 PROCESSING，后续重试可能被拒绝

✅ 正确：
   将幂等记录与业务操作放在同一事务中，或使用补偿机制清理 PROCESSING 状态

5.4 人为错误防护

6. 进阶延展

6.1 云原生数据库

云原生数据库以存算分离为核心架构，实现存储与计算的独立弹性伸缩：

• AWS Aurora：日志即数据库（Log is Database），计算节点共享分布式存储
• 阿里云 PolarDB：基于 Shared-Storage 的存算分离，支持 Serverless 弹性
• Google AlloyDB：PostgreSQL 兼容，列存加速分析查询
• Azure Database：Flexible Server 模式，自动扩缩容

6.2 Serverless 数据库

Serverless 数据库按实际使用量计费，自动扩缩容至零，适用于间歇性工作负载：

6.3 AI + 数据库

• 向量检索：pgvector、Milvus、Weaviate 成为 LLM 应用的基础设施
• AI 驱动优化：数据库内置 AI 优化器（如 PostgreSQL 的 pg_qualstats + 自动索引建议）
• 自然语言查询：Text-to-SQL（如 Snowflake Cortex、Databricks AI Functions）
• 自治数据库：Oracle Autonomous Database、AWS Aurora 自适应优化
• AI 辅助诊断：基于 ML 的异常检测与根因分析

6.4 云原生环境下的幂等

Kubernetes 环境对幂等提出新的挑战与机遇：

Kubernetes Operator 幂等模式：Kubernetes 的声明式 API 模型要求 Controller 的 Reconcile 逻辑必须幂等——无论 Reconcile 被触发多少次，最终状态都应与期望状态一致。

6.5 Serverless 环境下的幂等挑战

Serverless 架构（AWS Lambda、Azure Functions）的幂等面临特殊问题：冷启动、事件源重试、超时限制。

AWS Lambda 幂等方案：AWS 提供 DynamoDB Conditional Write 作为 Serverless 幂等的标准方案。

6.6 AI 辅助幂等检测

2025-2026 年，AI 辅助工具在幂等性领域开始发挥重要作用：

• 静态分析：基于 LLM 的代码审查工具可自动识别非幂等的数据库操作模式
• 测试生成：AI 可自动生成并发重试测试用例，验证幂等实现的正确性
• 架构审查：AI 分析微服务调用链，识别链路中的幂等漏洞
• 混沌工程集成：AI 驱动的混沌测试自动注入网络超时与重试，验证系统幂等韧性

6.7 幂等即服务（Idempotency as a Service）

越来越多的云平台和中间件开始提供内置幂等支持：

• Stripe：API 原生支持 Idempotency-Key 请求头
• AWS：DynamoDB Conditional Writes + TTL 原生支持幂等模式
• Kafka：Producer 端幂等（enable.idempotence=true）保证 Exactly-Once 语义
• 数据库：PostgreSQL 的 INSERT ... ON CONFLICT DO NOTHING 原生幂等写入

6.8 其他趋势

6.9 延伸阅读

1. RFC 9110: HTTP Semantics. IETF, 2022. §9.2.2 Idempotent Methods
2. Kleppmann, M. Designing Data-Intensive Applications. O'Reilly, 2017. Chapter 9: Consistency and Consensus
3. Richardson, C. Microservices Patterns. Manning, 2018. Chapter 4: Managing Transactions with Sagas
4. AWS Architecture Blog: Making retries safe with idempotent APIs, 2023
5. Stripe API Reference: Idempotent Requests, 2024
6. Antirez. Is Redlock safe? Redis Blog, 2016
7. Kleppmann, M. How to do distributed locking (RedLock critique), 2016
8. ULID Specification: https://github.com/ulid/spec
9. Snowflake: A Networked Service for Generating Unique IDs, Twitter Engineering Blog, 2010
10. Vernon, V. Implementing Domain-Driven Design. Addison-Wesley, 2013. Chapter 8: Event Sourcing
11. Uber Engineering: How We Saved 70K Cores Across 30 Mission-Critical Services
12. MySQL 8.0 Reference Manual
13. MySQL 9.x Release Notes
14. PostgreSQL 17 Release Notes
15. PostgreSQL 18 Beta Release Notes
16. TiDB Documentation
17. CockroachDB Documentation
18. pgvector: Open-source vector similarity search for Postgres
19. Milvus Documentation
20. Database Internals: A Deep Dive into How Distributed Data Systems Work — Alex Petrov

本文档系统梳理了数据库与幂等性两大技术主题，适用于后端工程师、架构师与技术管理者。建议结合实际业务场景进行选型与设计实践。