0

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

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

4

1 回答 1

4

TiDB 开发者在这里。

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

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

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

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

1. 3-DC部署方案

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

3-DC 部署架构

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

3-DC 部署的灾难恢复

缺点：
性能受到网络延迟的极大限制。
对于写入，所有数据都必须复制到至少 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 上。

读取性能优化的 3-DC 部署

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

2个城市的3DC

与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主从方案。2 个完整的 TiDB 集群（每一个完整的 TiDB 集群包括 TiDB、PD 和 TiKV）部署在 2 个 DC 中，一个作为 Master，一个作为 Slave。正常情况下，Master DC处理所有请求，写入Master DC的数据通过Binlog异步写入Slave DC。

2-DC 2 城市部署中的数据同步

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

2-DC 作为相互备份部署

我们的一些生产用户也采用了 2-DC 多源解决方案，这意味着：

  1. 应用程序请求被分离并分派到 2 个 DC。
  2. 每个 DC 有 1 个集群，每个集群有两个数据库：一个 Master 数据库服务于部分应用程序请求，一个 Slave 数据库作为另一个 DC 的 Master 数据库的备份。写入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中的任何一个出现故障，数据也具有强一致性。所有的调度策略都是为了调整性能，但可用性是最重要的 1 优先级，而不是在中断时的性能。

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

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

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

此表是我们的 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 2PD 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 共识算法而在失败后会选举新的领导者。这个过程是自动的，不需要人工干预。该服务仍然可用，不会受到影响，只是性能略有下降。

于 2019-01-26T06:04:03.043 回答