MVCC（多版本并发控制）是一种通过维护数据多版本实现高并发访问的数据库技术，其核心在于通过版本链和快照机制解决读写冲突。

​1. 基本定义

MVCC（Multi-Version Concurrency Control）通过为数据行维护多个历史版本，允许读写操作并行执行，防止传统锁机制导致的资源争用，每个事务基于一致性快照读取数据，确保事务隔离性（如防止脏读、不可重复读）。

2. 解决的问题

• ​读写冲突：读操作基于历史快照，写操作生成新版本，二者互不阻塞
• ​事务隔离性：在RC（读已提交）和RR（可重复读）隔离级别下，通过快照机制防止脏读、不可重复读及部分幻读
• ​高并发性能：减少锁竞争，提升吞吐量

3. 实现原理

以 etcd实现 mvcc 为例，etcd 实现 MVCC（多版本并发控制）的核心原理是通过维护数据的多版本历史记录，结合内存索引与持久化存储的协同工作，实现高并发读写隔离与历史版本追溯。

具体来说， etcd 的 MVCC 实现通过 ​内存索引（TreeIndex）​ 与 ​持久化存储（BoltDB）​ 的协同，以全局 Revision 为逻辑时钟，管理多版本数据。

​​TreeIndex（内存索引）​
​作用：在内存中维护用户 key 与版本号的映射关系，支持高效的范围查询和版本遍历。
​数据结构：使用 B-tree 结构存储 KeyIndex，每个 KeyIndex 包含：
Key：用户定义的键名（如 /foo/bar）。
Modified Revision：最后一次修改的全局版本号（Revision）。
Generations：记录键的生命周期，每个生命周期包含创建版本号（Created Revision）和多次修改的版本号列表（Rev）。
​生命周期管理：
键被删除后重新创建时，会生成新的 Generation，防止历史版本混淆。例如：
text
Generation 1: 创建（rev=100）→ 修改（rev=101）→ 删除（rev=102）
Generation 2: 重新创建（rev=200）→ 修改（rev=201）
​BoltDB（持久化存储）​
​作用：存储所有版本的实际数据，通过全局单调递增的 Revision 组织数据。
​存储结构：
​Key：格式为 Revision{Main}_{Sub}（如 1000_0），其中：
Main：全局事务 ID，每次写操作递增 1。
Sub：同一事务内的操作编号（默认为 0，批量操作时递增）。
​Value：存储 mvccpb.KeyValue 结构体，包含：

type KeyValue struct {
    Key            []byte  // 用户键名
    Value          []byte  // 用户值
    CreateRevision int64   // 创建时的 Revision
    ModRevision    int64   // 最后一次修改的 Revision
    Version        int64   // 生命周期内的修改次数
    Lease          int64   // 关联的租约 ID
}

版本号（Revision）的核心作用
​全局逻辑时钟
每个写操作（Put/Delete）会生成全局递增的 Main Revision，作为数据版本的时间戳。
例如，键 /a 的创建和修改可能对应 Main Revision=100 和 200，形成版本链。
​事务内子版本号
同一事务中的多个操作通过 Sub Revision 区分。例如，一个事务内连续写入两个键，可能生成 Revision{100_0} 和 Revision{100_1}。

4. MVCC 应用场景

​高并发OLTP系统
如电商、金融交易等场景，支持大量并发读写，通过快照读降低锁竞争。
​读多写少场景
如报表分析、内容管理系统（CMS），读操作基于历史快照，不影响写操作。
​分布式数据库与云服务
多租户架构下，MVCC可隔离不同用户事务，保障数据一致性。
​实时数据同步
通过快照读实现数据复制（如MySQL主从同步），防止锁阻塞

5. MVCC的优缺点

​优势
​高性能：读写操作无锁竞争，提升并发能力。
​数据一致性：事务基于快照隔离，防止脏读和不可重复读。
​灵活性：支持不同隔离级别，适应多种业务需求。
​局限性
​存储开销：维护多版本需占用额外空间，长事务可能导致Undo Log膨胀。
​幻读未彻底解决：RR级别下快照读无法完全防止幻读，需结合锁机制。
​复杂性：版本链管理、Read View生成规则增加系统复杂度