跨大陆边界的 TiDB 分布式设置

Question

我们计划在欧洲和澳大利亚使用 TiDB 进行分布式设置。

有人对这种分布式设置有一些经验吗？

Answer 1

TiDB 开发者在这里。

根据您的描述，您的场景是远距离跨数据中心场景。在这种情况下，您需要了解在这种部署中，您的读写延迟将在很大程度上取决于数据中心之间的延迟。

更合理的部署方式是，如果你的工作负载主要在欧洲，同时又需要强一致性和高可用，那么你可以选择欧洲的两个 IDC 和澳大利亚的一个 IDC 来部署 TiDB，你的应用应该部署在欧洲。因为对于 TiDB 来说，一次写入需要大部分副本都写入成功。在这种情况下，写入延迟为：

latency = min(latency(IDC1, IDC2), latency(IDC2, IDC3), latency(IDC1, IDC3)） 

以下是针对不同场景的一些部署建议和比较：

1. 3-DC部署解决方案

TiDB、TiKV 和 PD 分布在 3 个 DC 中。

优点：
所有副本分布在 3 个 DC 中。即使一个 DC 宕机，另外 2 个 DC 也会在合理的时间内（大多数情况下在 20 秒内）发起 Leader 选举并恢复服务，并且不会丢失任何数据。有关详细信息，请参见下图：

缺点：
性能受到网络延迟的极大限制。
对于写入，所有数据都必须复制到至少 2 个 DC。由于 TiDB 使用 2 阶段提交进行写入，因此写入延迟至少是两个 DC 之间网络延迟的两倍。
如果 leader 与发出读取请求的 TiDB 节点不在同一个 DC，读取性能也会受到影响。
每个 TiDB 事务都需要从 PD 领导者那里获取 TimeStamp Oracle (TSO)。所以如果 TiDB 和 PD leader 不在同一个 DC 中，事务的性能也会受到网络延迟的影响，因为每个有写请求的事务都必须获得两次 TSO。

优化：
如果不是三个 DC 都需要为应用程序提供服务，可以将所有请求分派到一个 DC，并配置调度策略，将所有 TiKV Region Leader 和 PD Leader 迁移到同一个 DC，就像我们在下面的测试。这样，无论是获取 TSO 还是读取 TiKV Regions 都不会受到 DC 之间网络延迟的影响。如果这个 DC 宕机了，会在其他存活的 DC 中自动选举出 PD Leader 和 Region Leader，你只需要将请求切换到仍然在线的 DC 上。

2。 2城3-DC部署解决方案
该方案与之前的3-DC部署方案类似，可以认为是基于业务场景的优化。不同的是，同城内的2个DC之间的距离很短，因此延迟非常低。在这种情况下，我们可以将请求分派到同城的两个 DC，并将 TiKV leader 和 PD leader 配置在同城的两个 DC。

与3-DC部署相比，2城3-DC部署具有以下优势：

1. 更好的写入性能
2. 更好地利用资源，因为 2 个 DC 可以为应用程序提供服务。
3. 即使一台 DC 宕机，TiDB 集群依然可用，不会丢失任何数据。

但缺点是，如果同城内的 2 个 DC 宕机，其概率高于 2 个城市的 2 个 DC 宕机的概率，TiDB 集群将不可用，部分数据会丢失。丢失。

3。 2-DC+Binlog同步部署方案

2-DC+Binlog同步类似于MySQL Master-Slave方案。 2 个完整的 TiDB 集群（每一个完整的 TiDB 集群包括 TiDB、PD 和 TiKV）部署在 2 个 DC 中，一个作为 Master，一个作为 Slave。正常情况下，Master DC处理所有请求，写入Master DC的数据通过Binlog异步写入Slave DC。

如果Master DC宕机，请求可以切换到slave集群。与 MySQL 类似，一些数据可能会丢失。但与 MySQL 不同的是，该方案可以保证同一个 DC 内的高可用：如果 DC 内部分节点宕机，不会影响在线业务，不需要人工操作，因为集群会自动重新选举 leader提供服务。

我们的部分生产用户也采用2-DC多源方案，即：

1. 应用程序请求被分离并分派到 2 个 DC。
2. 每个 DC 有 1 个集群，每个集群有两个数据库：一个主数据库用于服务部分应用程序请求，一个从数据库作为另一个 DC 主数据库的备份。写入Master数据库的数据通过Binlog同步到另一个DC的Slave数据库，形成备份循环。

请注意，2-DC+Binlog同步方案，数据通过Binlog异步复制。如果 2 个 DC 之间的网络延迟太高，Slave 集群中的数据将远远落后于 Master 集群。如果 Master 集群宕机，会丢失部分数据，不能保证 5 分钟内丢失数据。

HA和DR的整体分析

对于3-DC部署方案和3-DC in 2 city方案，我们可以保证集群会自动恢复，不需要人为干预，并且即使3个DC中的任何一个发生数据都保持强一致性向下。所有调度策略都是为了调整性能，但可用性是第一要务，而不是在中断时的性能。

对于2-DC+Binlog同步方案，我们可以保证集群会自动恢复，不需要人为干预，即使Master集群中的任何一个节点宕机也能保证数据的强一致性。当整个 Master 集群宕机时，需要手动切换到 Slave，并且会丢失一些数据。丢失的数据量取决于网络延迟和网络状况。

关于如何实现高性能的建议

如前所述，在 3-DC 场景中，网络延迟对性能非常关键。由于高延迟，一个事务（10读1写）需要100毫秒，单线程只能达到10TPS。

此表是我们 Sysbench 测试的结果（3 个 IDC、2 个美国西部和 1 个美国东部）：

| threads |     tps |      qps |
|--------:|--------:|---------:|
|       1 |    9.43 |   122.64 |
|       4 |   36.38 |   472.95 |
|      16 |  134.57 |  1749.39 |
|      64 |  517.66 |  6729.55 |
|     256 | 1767.68 | 22979.87 |
|     512 | 2307.36 | 29995.71 |
|    1024 | 2406.29 | 31281.71 |
|    2048 | 2256.27 | 29331.45 |

相比之前推荐的将 TiKV Region Leader 调度在一个 DC 内的部署，PD Leader 的优先级通过pd-ctl member leader_priority pd1 2 设置，将 PD Leader 设置在 TiKV Region Leader 的同一个 DC ，避免了获取 TSO 带来的过高的网络延迟。

基于此，我们得出结论，如果您想要更多的 TPS，您应该在您的应用程序中使用更多的并发。

我们推荐以下解决方案：

1. 添加更多具有相同配置的 TiDB 实例以进行进一步测试，以利用 TiDB 的可扩展性。
2. 为避免跨 DC 事务提交请求导致的性能损失，请考虑将每个事务的工作负载从 10 reads + 1 write 更改为 100 reads + 10 writes 以获得更高的 QPS。

关于HA的问题，答案是Leader的DC出现故障时不需要人工操作。这是因为即使领导者的 DC 发生故障并且领导者被锁定在一个 DC 中，大多数副本仍然存在，并且由于 Raft 共识算法而在失败后会选举新的领导者。这个过程是自动的，不需要人工干预。该服务仍然可用，不会受到影响，只是性能略有下降。