一、存储架构与 Raft 日志管理
TiKV 以 RocksDB 引擎为核心，构建分层存储架构支撑 Raft 协议高效运行，每个节点部署两个独立 RocksDB 实例，实现功能与性能的精准拆分。
raftdb 专注于 Raft 日志存储，采用顺序写入机制最大化日志追加效率。为保障数据隔离性，每个 Region 对应独立的 Raft 日志流，通过逻辑分区避免不同 Region 日志相互干扰，确保日志操作的独立性与安全性。
kvdb 承担用户数据与元信息存储职责，内部划分四个功能明确的 Column Family：
- raft 列族：存储 Region 关键元数据，包括副本分布情况、状态机版本等核心信息。为降低 IO 消耗，采用低频率更新策略，仅在元数据发生实质性变更时触发写入操作。
- lock 列族：负责分布式事务锁管理，创新性结合内存锁表与持久化存储。内存锁表实现锁的快速获取与释放，持久化存储则保障锁状态不丢失，兼顾事务并发效率与数据安全性。
- write 列族：记录事务提交信息，依托 MVCC（多版本并发控制）机制构建版本链。该设计支持高效的历史版本查询，满足事务回溯与数据一致性校验需求。
- default 列族：存储用户实际业务数据，通过自定义 Key 编码规则优化 Region 内数据局部性，减少跨 Region 数据访问，提升查询效率。
在日志持久化环节，TiKV 采用双阶段提交策略：首先将日志写入 raftdb 的 WAL（预写日志），确保日志不丢失；随后异步将日志提交至 kvdb，实现日志与数据存储的 IO 路径分离，在保障数据一致性的同时，显著提升系统并发吞吐能力。
二、Raft 状态机核心工作流程
2.1 Leader 选举与心跳机制
TiKV 对 Raft 选举流程进行针对性优化，提升选举可靠性与集群稳定性：
- 预投票机制：候选节点发起正式选举前，先向集群内其他节点发送预投票请求。只有获得多数节点支持，才会启动正式选举，有效避免因网络分区导致的无效 Leader 产生，减少集群震荡。
- 动态心跳超时：摒弃固定心跳间隔模式，根据集群负载动态调整心跳周期（默认基础间隔为 2s）。当节点从故障中恢复时，可快速触发选举流程，缩短集群不可用时间，提升服务连续性。
- Leader 优先级调度：PD（Placement Driver）实时监控节点健康状态，生成节点健康度评分。选举过程中优先选择低负载、高可用的节点作为 Leader 候选，实现集群负载均衡，避免单点压力过大。
2.2 日志复制与提交
为提升日志复制效率，TiKV 采用流水线优化策略，核心设计包括：
- 并行发送机制：Leader 节点将日志条目分批处理，通过 gRPC 流式接口并行发送至各 Follower 节点。该方式大幅减少网络往返时间（RTT）开销，提升日志同步速度。
- 乱序确认策略：Follower 节点采用异步写入模式，允许对日志条目进行乱序确认。同时，通过日志索引连续性校验机制，确保最终所有节点日志序列一致，保障数据一致性。
- 批量提交优化：当多数节点确认某一日志索引后，Leader 触发批量提交指令，将连续的日志区间一次性应用到状态机，减少状态机更新次数，提升整体处理效率。
2.3 成员变更与配置切换
TiKV 基于 Joint Consensus 算法实现安全可靠的成员变更，具体流程如下：
- 两阶段配置切换：成员变更时，先将集群切换至新旧配置共存的中间状态。待新配置在集群内稳定运行后，再完全切换至新配置，彻底避免因配置变更引发的脑裂风险。
- 自动节点驱逐：对于长时间无响应的故障节点，Leader 会自动发起配置变更提案，将其移出集群。同时，PD 监测到副本缺失后，触发副本补充流程，维持集群副本数量稳定，保障数据可靠性。
三、Multi-Raft 机制实现
3.1 Region 与 Raft Group 管理
TiKV 通过动态化、精细化的管理策略，优化 Region 与 Raft Group 运行效率：
- 动态分裂策略：当 Region 数据量超过阈值（默认 512MB）时，自动触发 Split 操作生成子 Region。分裂点选择基于 Key 分布热点检测技术，避开高频访问的 Key 区间，防止分裂后产生大范围查询，保障查询性能。
- 共享线程池调度：所有 Raft Group 共享全局线程池，通过优先级队列对不同 Region 的 IO 请求进行调度。其中，Leader 转移、配置变更等关键系统操作被赋予更高优先级，确保核心功能优先执行。
- 局部性优化设计：将同一物理节点上的多个 Region 副本分配至不同磁盘路径，并结合 NUMA（非统一内存访问）绑定技术，减少跨 CPU 核心的内存访问延迟，提升数据读写效率。
3.2 跨 Region 事务协调
为解决跨 Region 事务的效率与一致性问题，TiKV 设计了多层级协调机制：
- 事务路由缓存：TiDB Server 维护 Region 路由表，在事务执行前，将涉及的 Key 预先映射到目标 Region，大幅减少向 PD 查询元数据的次数，降低事务准备阶段耗时。
- 并行提案提交：跨 Region 事务被拆分为多个单 Region 提案，通过并行方式提交。依托 2PC（两阶段提交）协议保障事务原子性：各参与 Region 独立执行 Prepare 阶段，完成后由事务协调者统一触发 Commit 操作，提升事务整体执行速度。
四、性能优化关键技术
4.1 日志存储优化
TiKV 从存储引擎与快照机制两方面入手，优化日志存储性能：
- Raft Engine 替代方案：新一代 Raft Engine 采用 LSM-tree（日志结构合并树）优化结构，相比原生 RocksDB 减少 50% 的写放大效应。通过将日志索引与数据块分离存储，实现日志的快速检索，提升日志操作效率。
- 异步快照生成：由后台独立线程定期生成增量快照，避免影响前台业务处理。采用 zstd 压缩算法，将快照体积压缩至原始数据的 30%，降低存储占用；快照传输过程中引入分块校验机制，支持断点续传，提升快照同步可靠性与效率。
4.2 网络传输优化
针对网络传输瓶颈，TiKV 设计多项优化技术，减少数据传输开销：
- Batch Pipeline 机制：将多个日志条目合并为单个网络包发送，数据包头部携带元数据，描述包内日志条目的区间信息。接收方通过并行解析技术，同时处理包内多个日志条目，提升网络传输与数据处理的并行度。
- 零拷贝传输：日志数据在内存中始终保持序列化格式，网络层直接传输原始字节数据，无需经过序列化与反序列化过程，大幅减少 CPU 资源消耗，提升数据传输速度。
五、容错与恢复机制
5.1 故障检测与恢复
TiKV 构建自适应故障处理机制，快速检测并恢复故障节点：
- 自适应心跳检测：Follower 节点实时计算 Leader 心跳的平均间隔，将超时阈值设定为 3 倍平均间隔。若在阈值时间内未收到 Leader 心跳，立即触发新的选举流程，快速恢复集群 leadership。
- 快速数据修复：宕机节点重启后，优先向 Leader 拉取缺失的日志条目，而非直接同步全量快照，减少数据传输量。同时，通过 Log GC（日志垃圾回收）机制，清理已提交且不再需要的日志，释放存储空间。
5.2 脑裂防护
为防止集群出现脑裂问题，TiKV 设计双重防护机制：
- 租约机制：Leader 节点在心跳包中携带租约有效期（通常为 10 个心跳周期）。Follower 节点在租约有效期内，会拒绝其他候选节点的选举请求，确保同一时间段内只有一个合法 Leader。
- epoch 校验机制：每次集群配置变更时，epoch（版本号）自动递增。节点处理请求时，会校验请求中的 epoch 与本地存储的 epoch 是否一致，拒绝基于过期配置的提案，避免因配置不一致引发的数据冲突。
六、与 PD 协同工作机制
TiKV 与 PD 形成双层共识体系，通过高效协同实现集群全局优化：PD 自身基于 Raft 协议维护集群元数据，与 TiKV 构建紧密的协同工作机制：
- 负载反馈闭环：TiKV 节点定期向 PD 上报 Region 负载指标，包括 QPS（每秒查询率）、磁盘利用率、网络带宽占用等。PD 基于这些数据构建全局负载视图，生成精准的调度指令，指导 TiKV 进行负载调整。
- 热点疏散策略：PD 实时监测各 Region Leader 的请求处理量，当某 Region Leader 处理请求超过阈值（如 10 万 QPS）时，立即触发 Leader 迁移流程，将其迁移至低负载节点，缓解热点 Region 压力，保障集群整体性能稳定。
- 副本均衡算法：PD 基于 CRUSH（可控哈希下的一致复制）算法，将 Region 副本分散部署在不同故障域（如不同机架、不同机房），提升集群容错能力。同时，考虑节点硬件差异（如 SSD 与 HDD 混合部署场景），为不同类型的节点分配适配的 Region 副本，最大化硬件资源利用率。