副本管理

我们为 TiKV 选择了基于范围的分片。选择适当的分片策略后，我们需要将其与高可用性复制解决方案结合起来。不同的复制解决方案可以实现不同级别的可用性和一致性。许多中间件解决方案仅实现了分片策略，却没有在每个分片上指定数据复制解决方案。示例包括 Redis 中间件 twemproxy 和 Codis，以及 MySQL 中间件 Cobar。这些中间件解决方案仅在中间层实现路由，而没有考虑底层每个存储节点上的复制解决方案。

但是，此复制解决方案对于大型存储系统非常重要。通常，支持弹性可伸缩性更改的系统中的分片数量以及这些分片的分布也会改变。系统会自动平衡负载，横向扩展或横向扩展。如果有大量数据和大量分片，则几乎不可能手动维护主从关系，从故障中恢复等等。因此，选择高度自动化，高可用性的解决方案非常重要。

在 TiKV 中，每个分片称为一个 Region，因为我们需要支持扫描，并且存储的数据通常具有关系表架构，所以我们希望同一表的数据尽可能地接近。TiKV 中的每个区域都使用 Raft 算法来确保多个物理节点上的数据安全性和高可用性。

几个开源 Raft 实现，包括 etcd，LogCabin，raft-rs 和 Consul，都只是单个 Raft 组的实现，不能用于存储大量数据因此，这些实现的主要用例是配置管理毕竟，单个 Raft 组中参与的节点越多，性能越差如果无法水平添加物理节点，则系统无法扩展。