> 本文是写作规划，不是可发布正文。拆解对象：TiKV 7.x/8.x（Region / Multi-Raft / raftstore / MVCC key）为主线；PD 为调度与 TSO；TiFlash 以 Raft Learner 列存副本收束 HTAP；CockroachDB 作对照一篇，OceanBase 仅边…

本文总结了分布式KV系统的选型决策树，涵盖etcd、FoundationDB、TiKV等的适用场景与机制，强调了严格可串行化、事务处理和存储解耦等关键概念，并指出了高冲突负载下OCC重试的可接受性等开放问题。

本文介绍了TiDB集群的四个核心组件及其功能：TiDB负责SQL解析和请求路由，TiKV处理分布式事务和数据存储，PD管理元数据和调度，TiFlash提供列存分析副本。理解各组件的独立性和复杂性有助于排查性能问题。接下来将深入探讨TiKV的具体实现与机制。

TiKV 将 Percolator 的锁、数据和写入三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。通过时间戳的位反转实现 Key 编码规则，确保查询时优先返回最新版本。TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性，区别于 RocksDB 的单机快照机制。这三种 CF 共同维护同一逻辑数据，需联合管理。

TiKV 将集群数据视为全局有序的 Key-Value 大表，按 Key 切分为多个 Region。每个 Region 代表一个连续的 Key 区间，RegionEpoch 通过两个字段管理版本，确保请求有效性。每个 Region 由多个 Peer 组成 Raft 组，只有 Leader 处理读写请求。PD 负责均衡 Region 和 Leader 的分布，以提升容错能力和性能。

TiKV 采用 Multi-Raft 模型，每个 Region 独立维护 Raft 日志，支持高并发写入，解决了单 Raft 组的吞吐限制。跨 Region 事务的复杂度增加，需要额外协议保证原子性。TiKV 通过 raftstore 线程池管理状态机，优化性能，并引入 Hibernate Region 减少空闲状态开销，实现高效的分布式存储。

TiKV 的写请求经历四个阶段：propose、append、commit 和 apply。commit 阶段确保日志被多数副本持久化，但不代表数据已写入 RocksDB。apply 阶段负责实际写入。TiKV 通过异步设计提高性能，确保协议推进与状态机执行分离，优化写入效率。

TiKV 通过 Raft Snapshot 解决副本落后问题，允许副本直接从 Leader 同步，避免日志重放开销。日志 GC 定期清理不再需要的日志，确保副本正常追赶。TiKV 支持 Voter、Learner 和 Witness 三种副本形态，以提高系统容错能力和存储效率。

PD（Placement Driver）作为TiKV的调度中心，通过心跳机制收集集群状态，生成调度建议（Operator），并发送给Region Leader。调度过程异步，Leader可选择执行或跳过建议。PD使用Store心跳提供宏观视图，Region心跳提供精确位置。调度的基本单元是Operator，主要目标是负载均衡和副本管理，决策受限于放置规则和调度限制，以确保系统稳定性。

本文讨论了TiKV的动态分区策略，重点在于Region的分裂与合并机制。TiKV通过静态大小和key数量、负载（Load Base Split）两条管线判断何时分裂，分裂过程通过BatchSplit命令修改元数据，不涉及数据复制。合并需先对齐副本，经过PrepareMerge和CommitMerge两个阶段。PD的hot-region-scheduler与TiKV的Load Base Split相辅相成，解决热点问题。

本文讨论了TiDB中的时间戳分配服务TSO（Timestamp Oracle），其核心在于确保全局事务的严格顺序。TSO通过46位物理时间和18位逻辑计数器组合成64位时间戳，由PD leader负责分配，以确保单调性和故障恢复。通过批量请求机制，多个事务可以共享一次网络往返，从而降低延迟。

本文探讨了TiKV如何实现Percolator论文中的data/lock/write模型，分析了TiKV在编码、Prewrite/Commit过程中的调整，包括Rollback记录、短值优化和Lock类型写记录。TiKV将Prewrite的原子性单位从单行事务改为Region的Raft提交，并通过Async Commit和1PC优化减少延迟，满足在线事务的性能需求，展示了TiKV在生产环境中的应用与论文模型的差异。

TiKV 的悲观锁默认使用内存路径以减少加锁延迟，但在非计划的 Leader 切换时可能会丢失锁。锁的 TTL 动态调整，长事务依赖心跳续期。死锁检测采用集中式方案，Leader 切换时清空历史依赖，存在漏检风险。TiKV 的锁机制与传统数据库相似，需纠正对其“无锁”的误解。

TiKV的Coprocessor通过将计算下推到本地执行，优化了数据查询性能。它执行TiDB编译的DAG请求，支持表扫描、过滤和聚合等操作，但不支持跨Region的连接。Coprocessor的批量执行提高了CPU效率，并通过资源控制避免影响在线事务。

本文讨论了TiDB中SQL处理的关键步骤，重点介绍了如何将SQL请求路由到具体的Region。TiDB通过distsql模块将逻辑key范围映射到物理Region，并生成Coprocessor任务。文章还探讨了Region路由中的错误处理机制和重试策略，以及不同下推协议（Cop、BatchCop、MPP）的路由差异。最后，强调了优化器选择与路由层之间的独立性，以及点查与范围扫描的效率差异。

TiFlash通过Raft Learner角色接收TiKV日志，实现行存到列存的转换，保持物理隔离和强一致性。其存储引擎DeltaTree分为Delta和Stable两层，优化写入和读取性能。TiFlash的读路径通过ReadIndex确认复制进度，确保数据一致性。存算分离架构允许独立扩展存储和计算资源，提升查询效率。

本文讨论了TiFlash中的safe-ts机制，确保数据读取的一致性和可见性。safe-ts是一个时间戳，表示所有提交的事务已在TiFlash副本上完成。可见时延通常在亚秒级，由日志复制、应用和锁解析等因素决定。TiDB与TiFlash结合实现了准实时的快照一致性，而非最终一致性。文章还探讨了故障场景下的新鲜度退化及主动接受陈旧数据的选项。

本文对比了TiKV与CockroachDB的架构差异。两者均基于Raft协议，但在角色划分、事务提交协议和部署形态上有所不同。CockroachDB引入了Leaseholder角色，采用Parallel Commits优化事务提交，而TiKV使用Percolator模型。TiKV的默认隔离级别为快照隔离，CockroachDB为可串行化。TiKV为分离式组件，CockroachDB为单进程一体化，运维和扩展方式各异。

本文讨论了TiKV/PD/TiFlash的常见故障及其排查方法，包括Region过多、热点、TSO抖动、锁冲突和apply积压。每种故障都有相应的信号源和根因链，提供了排查框架和具体处理方向。强调信号与机制的关系，建议根据官方文档调整参数。

本文总结了TiKV/HTAP系列的核心内容，包括选型决策树、站内阅读地图及学术谱系。读者可以理解如何选择合适的KV存储，特别是在数据规模、分布式事务和新鲜度要求方面。系列共18篇，探讨了从Region切分到Multi-Raft复制的各个环节，并指出了当前的开放问题，如千万级Region的运维上限和跨Region的可观测性。