物理服务器和云服务器有什么区别

物理服务器是指独立服务器，也就是物理上的单独服务器，物理服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似。

云服务器是虚拟物理服务器，它是基于云计算服务的，云服务器是在一组集群服务器上虚拟出多个类似独立服务器的部分，集群中每个服务器上都有云服务器的一个镜像，从而大大提高了虚拟服务器的安全稳定性，除非所有的集群内服务器全部出现问题，云服务器才会无法访问。

物理服务器与云服务器的差异主要表现在以下几个方面：

1、物理服务器的使用者可以完全独享整台机器的配置和性能。而云服务器是基于海量物理服务器集群构建的云端虚拟资源池，根据在线需求，从资源池中调度分配资源。

2、物理服务器的稳定性则与机器硬件、机房稳定性有关。而云服务器是由集群服务器共同虚拟出来的部分，因此除非该集群内所有服务器都出现问题，云服务器才有可能无法访问，有较好稳定性。

3、物理服务器的资源量和性能，相比云服务器拥有更高的优势。而云服务器在资源的管理和使用方面，更加灵活。

物理主机：是相对于虚拟机而言的对实体计算机的称呼。物理机是实际的硬件环境，可以说是在实际硬件环境上的主机虚拟主机：则是在屋里主机上模拟出来的 其硬件都是软件虚拟出来的 比较常用的是vmware（含ESXI和VM） Citrix和微软 普通用户常用的也就是vm物理服务器：同理物理主机 虚拟服务器类似于阿里云这些 他们的主机都是硬件配置机器强大的 一台物理服务器上可以虚拟出N台虚拟服务器

目录

一、前言

二、TiDB 集群核心组件可用性概览

1. TiDB Server 的可用性

三、Multi-Raft 集群的可用性限制

1. Raft 简介

2. Raft Group 副本数的选择

3. PD 是单一 Raft Group

4. TiKV 是 Multi-Raft 系统

5. Multi-Raft 集群的可用性限制

四、规划 TiKV Label 以提升 TiKV 集群的可用性

1. TiKV Label 简介

2. Label 相关的 PD 调度策略解读

3. TiKV Label 的规划

4. 使用 Label 的注意事项

五、典型两地三中心跨中心高可用多活容灾备配置

1. 物理服务器主机配置

2. 服务器，机柜，机房，网络要求

3. 两地三中心集群的扩容策略

分布式系统的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务。单点的硬件和网络等都是不可靠的，想要提高硬件的可靠性需要付出大量的成本，因此分布式系统往往通过软件来实现对于硬件的容错，通过软件来保证整体系统的高可靠性。

TiDB 集群中包含了串-并联系统，表决系统等，相对于一般的分布式系统更为复杂，TiDB 中所保存的数据的可用性由诸多因素控制，通过本篇文章的介绍，您可以了解到怎样在给定的资源下设计部署架构以尽可能地提高数据的可用性。

在 TiDB 集群的三个核心组件 PD，TiKV，TiDB 中，PD 和 TiKV 都采用 Raft 协议实现持久化数据的容灾以及自动的故障转移，有关 PD 和 TiKV 的可用性的详细解读，请参见第三章的内容。

TiDB Server 组件不涉及数据的持久化，因此 TiDB 被设计成了无状态的，TiDB 进程可以在任意位置被启动，多个 TiDB 之间的关系是对等的，并发的事务通过同一台 TiDB 发送给集群和通过多台 TiDB 发送给集群所表现的行为完全一致。单一 TiDB 的故障只会影响这个 TiDB 上当前的连接，对其他 TiDB 上的连接没有任何影响。

根据用户最佳实践，在 TiDB 之上一般会部署负载均衡器（F5，LVS，HAproxy，Nginx 等），因此负载均衡器所连接的 TiDB 越多，其整体可用性就越高，其整体所能承载的并发请求数量也越多。

在使用负载均衡器的场景下，建议使用的负载均衡算法为 least connection，当某个 TiDB 发生故障依然会导致当时连接到该 TiDB 上的请求失败，负载均衡器识别到 TiDB 的故障之后，将不再向此 TiDB 建立新的连接，而是将新的连接建立到可用的 TiDB 上，以此来实现整体的高可用。

Raft 是一种分布式一致性算法，在 TiDB 集群的多种组件中，PD 和 TiKV 都通过 Raft 实现了数据的容灾。Raft 的灾难恢复能力通过如下机制实现：

Raft 算法本身以及 TiDB 中的 Raft 实现都没有限制一个 Raft Group 的副本数，这个副本数可以为任意正整数，当副本数为 n 的时候，一个 Raft Group 的可靠性如下：

我们一般建议将 Raft Group 的副本数设置为奇数，其原因如下：

在一般的非关键业务场景下，建议将副本数选为 3；而在关键业务中建议将副本数选为 5。

遵循 Raft 可靠性的特点，放到现实场景中：

PD 集群只包含一个 Raft Group，即 PD 集群中 PD 服务的个数决定了 PD 的副本数，3 PD 节点集群的 PD 副本数为 3，5 PD 节点集群的 PD 副本数为 5。

由上一段落中 Raft 原理可知，一个 Raft Group 的容灾能力随节点数增加而加强，在一般的非关键业务场景下，建议部署 3 个 PD；建议在关键业务中部署 5 个 PD。

TiKV 是一个 Key-Value 存储系统，它是一个巨大的 Map，TiKV 提供有序遍历方法。下图展示了 region 以 3 副本模式存储在 4 台 TiKV 节点上的数据分布，TiKV 中的数据被切分成了 5 份 —— region 1~5，每个 region 的 3 个副本构成了一个 Raft Group，集群中共有 5 个 Raft Group，因此 TiKV 是 Multi-Raft 系统。

如上图所展示，虽然这个集群当前有 4 个 TiKV 实例，但一个 region 的 3 个副本只会被调度到其中 3 个 TiKV 上，也就是说 region 的副本数与 TiKV 实例数量无关，即使将上图的集群扩容到 1000 个 TiKV 实例，它也仍然是一个 3 副本的集群。

前面说到 3 副本的 Raft Group 只能容忍 1 副本故障，当上图的集群被扩容到 1000 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障，2 个 TiKV 实例的故障可能会导致某些 region 丢失多个副本，整个集群的数据也不再完整，访问到这些 region 上的数据的 SQL 请求将会失败。

而 1000 个 TiKV 中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 集群在逐步扩容中，其可用性是逐渐降低的。

TiKV Label 用于描述 TiKV 的位置信息，在 inventory.ini 中，其写法如下：

上面案例中规划了 4 层位置信息的 Label，Label 信息会随着 deploy.yml 或 rolling_update.yml 操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 region 副本的最优调度。用户可以根据自己的需要来定制 Label 名称，以及 Label 层级（注意层级有先后顺序），但需要注意 PD 会根据它读到的 Label 名称（含层级关系）去匹配 TiKV 的位置信息，如果 PD 读到的 TiKV Label 信息与 PD 中设置的 Label 名称不匹配的话，就不会按用户设定的方式进行副本调度。Label 名称的设置方法如下，在初次启动集群时，PD 会读取 inventory.ini 中的设置：

非初次启动的集群，需要使用 pd-ctl 工具进行 Label 名称设置：

从本质上来说，Label 系统是一种 PD 对 region 副本（replica）的隔离调度策略。

PD 首先读取到集群的 region 副本数信息*，假定副本数为 5。PD 将所有 TiKV 汇报给它的 Label 信息进行汇总（以本章第 1 小节的 TiKV 集群为例），PD 构建了整个 TiKV 集群的拓扑，其逻辑如下图所示：

PD 识别到第一层 Label - dc 有 3 个不同的值，无法在本层实现 5 副本的隔离。PD 进而判断第二层 Label - zone，本层有 z1~z5 这 5 个 zone，可以实现 5 副本的隔离调度，PD 会将各个 region 的 5 个副本依次调度到 z1~z5 中，因此 z1~z5 各自所对应的 4 个 TiKV 所承载的 region 数量总和应完全一致。此时，PD 的常规调度策略，如 balance-region，hot-region 等 region 相关的 scheduler 将严格遵守 Label 的隔离策略进行调度，在带有 z1~z5 Label 信息的 TiKV 尚在的情况下不会将同一个 region 的多个副本调度到同一个 zone 中。如图，图中将 TiKV 按照 zone 做 4 个一组隔离开了，一个 region 的一个副本只会在本 zone 的 4 个 TiKV 之间调度。

PD 天生不会将同一个 region 的多个副本调度到同一个 TiKV 实例上，增加 Label 信息后，PD 不会将同一个 region 的多个副本调度到同一个 host 上，以避免单台服务器的宕机导致丢失多个副本。

当带有某一个 zone Label 的 TiKV 全部故障时，如图中所有带有 z5 Label 的几个 TiKV 实例 kv252-1，kv252-2，kv253-1，kv253-2 同时故障时，集群会进入缺失一个副本的状态，在达到 TiKV 最大离线时间的设置值（max-store-down-time，默认值 30min）之后，PD 便开始在其他 4 个 zone 中补全所有缺失副本的 region，同时遵循上面一段所提到的约束，在为 region1 补全副本时，PD 会避开所有包含 region1 的服务器（本例中的 host）h208，h210，h414，h416 所涉及的 8 个 TiKV 实例，而在另外 8 个 TiKV 实例中挑选一个进行副本补全调度。

*副本数设置方法如下，以 5 副本为例：

Label 登记的是 TiKV 的物理位置信息，PD 根据 TiKV 的物理位置进行最优调度，其目的是在具有相近物理位置的 TiKV 上只放置一个副本，以尽可能的提高 TiKV 集群的可用性。举个例子，假设某一时刻集群中一定要有两个 TiKV 同时发生故障，那么你一定不想它们上面存储着一个 region 的两个副本，而通过合理规划让同时故障的两个 TiKV 出现在同一个隔离区的概率变高，TiKV 集群的整体可用性也就越高。因此 Label 规划要与 TiKV 物理位置规划一起进行，两者是相辅相成的。

举例而言，机房可能会由于电源故障，空调故障，网络故障，火灾，自然灾害等原因而整体不可用；机柜可能由于交换机故障，UPS 故障，消防喷淋等原因而整体不可用；服务器可能由于常见的内存等故障而宕机。通过妥善的 Label 规划，使 region 调度按物理位置进行隔离，可以有效地降低一个区域故障造成的整体影响。

物理位置的层级结构一般为机房，机柜，服务器，在大型基础设施中还会在机房与机柜之间多一个楼层信息。设计 Label 层级结构的最佳实践是基于物理层级结构再加上一层逻辑层级，该逻辑层级专门用于控制保持与集群副本数一致，在本案例中，zone 就是逻辑层级，该层级的值在集群搭建初期与 rack 保持一一对应，用于控制副本的隔离。而不直接采用 dc，rack，host 三层 Label 结构的原因是考虑到将来可能发生 rack 的扩容（假设新扩容的 rack 编号是 r6，r7，r8，r9，r10），这个扩容会导致 rack 数变多，当多个 TiKV 实例同时发生故障时，这些故障的 TiKV 出现在在多个 rack 上的概率也会增加，也就是会将第三章提到的 Multi-Raft 集群的可用性随节点数增加而下降问题再次引入到集群中。而通过使用逻辑层级 zone 保持与副本数一致可以将多个故障的 TiKV 出现在不同的隔离区（本例中的 zone）的概率降至最低，将来扩容 rack 也可以充分的利用到更多的 rack 的物理隔离来提高可用性。

在使用了 Label 隔离的集群中，存在以下限制：

规划了 Label 的集群再扩容时需要对每个隔离区进行容量一致的扩容，在本章的案例中，隔离区为 dc 和 rack 标示的位置，因此需要对每种 dc+rack 组合的区域进行容量一致的扩容，比如将要扩容 5 台 TiKV 服务器，其分配方法如下：

zone1=>dc1:rack1 增加一台 TiKV

zone2=>dc1:rack2 增加一台 TiKV

zone3=>dc2:rack1 增加一台 TiKV

zone4=>dc2:rack2 增加一台 TiKV

zone5=>dc3:rack1 增加一台 TiKV**

---