云计算架构下CloudTiDB的技术奥秘

1、    云计算架构下cloudtidb的技术奥秘    近日，国内云计算服务商ucloud与国内开源分布式newsol数据库tidb团队pingcap正式达成合作，双方联手在ucloud全球数据中心推出了新一代tidb的云端版本-cloud tidb。作为一款定位于cloud-native的数据库，目前tidb在云整合上已取得了阶段性进展。cloud tidb产品在ucloud平台正式开启公测，tidb弹性伸缩特性在cloud提供的基础设施支持下得到了淋漓尽致地体现。在感受云数据库魅力的同时，让我们来探索下tidb与cloud背后的技术秘密。一、tidb

2、与传统单机关系型数据库的区别首先，从tidb的架构说起。tidb作为一款开源的分布式数据库产品，具有多副本，能够根据业务需求非常方便地进行弹性伸缩，并且扩缩容期间对上层业务无影响。tidb的主体架构包含三个模块，对应githuh上pingcap组织下的三个开源项目（tidb/tikv/pd）：1） tidb主要是负责sql的解析器和优化器，它相当于计算执行层，同时也负责客户端接人和交互；2） tikv是一套分布式的kev-value存储引擎，它承担整个数据库的存储层，数据水平扩展和多副本高可用特性都在这一层实现；3） pd相当于分布式数据库的大脑，一方面负责收集和维护数据在各个tikv节点的分

3、布情况，另一方面pd承担调度器的角色，根据数据分布状况以及各个存储节点的负载来采取合适的调度策略，维持整个系统的平衡与稳定。上述三个模块中的每个角色都是一个多节点组成的集群，所以最终tidb的架构如图1所示。由此可见，分布式系统本身的复杂性不仅导致人工部署和运维成本较高，而且容易出错。传统的自动化部署运维t具（如puppet/chef/saltstack/ansihle等），由于缺乏状态管理，在节点出现问题时不能及时自动完成故障转移，需要人工干预，有些则需要写大量dsl甚至与shell脚本一起混合使用，可移植性较差，维护成本比较高。在云时代，容器成为应用分发部署的基本单位，谷歌基于内部使用数十

4、年的容器编排系统borg经验，推出的开源容器编排系统kuhernetes就成为当前容器编排技术的主流。二、tidb与kubernetes的深度整合作为cloud native datahase，tidb选择拥抱容器技术，并与kuhernetes进行深度整合，使其可以非常方便地基于kuhernetes完成數据库白动化管理。甚至可以说kuhernetes项目是为cloud而生，利用云平台iaas层提供的api可以很方便地与云进行整合。这样只要让tidb与kuhernetes结合得更好，进而就能实现其与各个云平台的整合，使tidb在云上的快速部署和高效运维成为现实。1.kubernetes简介kuh

5、ernetes最早是作为一个纯粹的容器编排系统而诞生，用户部署好kuhernetes集群之后，直接使用其内置的各种功能部署应用服务。由于这个paas平台使用起来非常便利，吸引了很多用户，不同用户也提出了各种不同需求，有些特性需求kuhernetes可直接在其核心代码里实现，但有些特性并不适合合并到主程序中。为了满足这类需求，kubernetes开放出一些api供用户自己扩展，实现自身需求。当前kuhernetes已经升级到1.8版本，内部api变得越来越开放，使其更像是一个跑在云上的操作系统。用户可以把它当作一套云的sdk或framework来使用，而且可以很方便地开发组件来扩展满足自身业务需

6、求，对有状态服务的支持就是一个代表性实例。在最早期，kuhernetes项目只支持无状态服务（ stateless service）来管理，无状态服务通过replicationcontroller定义多个副本，由kuhernetes调度器来决定在不同节点上启动多个pod，实现负载均衡和故障转移。对于无状态服务，多个副本对应的pod是等价的，所以当节点出现故障时，在新节点上启动一个pod与失效的pod是等价的，不会涉及状态迁移问题，因而管理非常简单。2.有状态服务stateful service不过，对于有状态服务（stateful service），由于需要将数据持久化到磁盘，使得不同pod之

7、间不能再认为成等价，也就不能再像无状态服务那样随意地进行调度迁移。kuhernetes l.3版本提出petset的概念，用来管理有状态服务并在1.5版本中将其更名为statefulset。statefuiset明确定义了一组pod中的每个身份，启动和升级都按特定顺序来操作。另外，使用持久化卷存储（persistentvolume）来作为存储数据的载体，当节点失效pod需要迁移时，对应的pv通过umount/mount方式跟着一起迁移到新节点，或者直接使用分布式文件系统作pv底层存储，使pod在迁移后仍然能访问到之前的数据。同时，pod在发生迁移时，其网络身份（例如ip地址）是会发生变化的，很

8、多分布式系统不能接受这种情况，所以statef'uiset在迁移pod时可以通过绑定域名的方式来保证pod在集群中网络身份不发生变化。然而，现实中一些分布式系统更为复杂，statefulset也显得捉襟见肘。举例来说，某些分布式系统的节点在加入集群或下线时，还需要做些额外的注册和清理操作，或者在滚动升级时，要考量版本兼容性等问题。基于上述原因，coreos公司提出了operator概念，并实现了etcd-operator和prometheus-operator来管理etcd和prometheus这样复杂的分布式系统。用户可以开发自己的operator，在kuhernetes之上实现白定

9、义的controller，将有状态服务领域中特定的运维知识编码进去，从而实现对特定分布式系统的管理。同时，operator本身也是跑在kuhernetes中的一个pod（deployment），对kubernetes系统并无危害。3.tidb多组件支持针对tidb这种复杂的分布式服务，我们开发了tidh-operator等一系列组件，来管理tidb集群实例在kubernetes平台上的创建、销毁、扩容、缩容、滚动升级和故障转移等运维操作。同时，在上层封装了一个tidh-cloud-manager组件，提供restful接口，实现了与云平台的控制台打通功能。这就完成了一个dbaas（数据库即服务

10、）架构的基本形态。由于tidb对磁盘1/0有比较高的要求，通过pv挂载网络盘，会有明显的性能损耗。另外，tikv本身维护了数据多副本，这点和分布式文件系统的多副本是有重复的，所以要给pod上挂载本地磁盘，并且在kuhernetes上把local pv管理起来，作为一种特定资源来维护。kuhernetes方长期以来一直没有提供local pv支持，本地存储只支持hostpath和emptydir两种方式。其中，hostpath的生命周期是脱离kuhernetes管理的，使用hostpath的pod销毁后，里面的数据是不会被自动清理，下次再挂载pod就会造成多余的数据。而emptydir更像是一个

11、临时磁盘，在pod重建时会被清理重置，不能成为持久化pv来使用。为此，我们开发了一个tidh-volume-manager组件，用于管理kuhernetes集群中每台物理主机上的本地磁盘，并且将其变成一种特殊的pv资源。结合operator在部署tidb节点时会参考local pv资源的情况，来选择特定节点进行部署，分配一个空的localpv和pod绑定。而当pod销毁时，会根据具体情况决定是否结束local pv的生命周期，释放掉的local pv在经历一个gc周期后，被tidh-volume-managerl回收，清理其盘上数据等待再次被分配使用。将这些组件整合起来，就形成了上图描述的cl

12、oudtidb总体架构（图2）。在kubenete s管理的集群上，通过tidb-operator等组件针对性的调配和使用集群资源，从而实现tidb集群实例的生命周期管理。通过这种方式实tidb分布式数据库和云平台的整合。三、cloud tidb的关键特性和实现细节1.自动化运维数据库产品上云的一个先决条件是能实现自动化的运维管理，因为在云端靠人t运维几乎是不现实的。第一步，用kubernetes将云平台的主机资源管理起来，组成一个大资源池；第二步，再通過tidh-opeartor及tidb-cloud-manager等组件，来自动化完成tidb实例的一键部署、扩容缩容、在线滚动升级、自动故障

13、转移等运维操作。集群创建。tidb包含tidh、tikv和pd三大核心组件，每个服务又都是一个多节点的分布式结构，服务和服务之间的启动顺序也存在依赖关系。此外，pd节点的创建和加入集群方式与etcd类似，是需要先创建一个单节点的initial集群，后加入的节点需要用特殊的加入方式，启动命令上也有差别。有一些操作完成后还需要调用api进行通知。kuhernetes自身提供的statefuiset很难应付这种复杂部署，所以需要tidb-operator中实现特定controller来完成这一系列操作。同时，结合kuhernete se强大的调度功能，合理规划和分配整个集群资源，尽量让新部署的tid

14、b实例节点在集群中均匀分布，最终通过lb给对应的租户使用。在线升级也类似。由于tikv/pd的pod挂载是本地存储，并不能像云平台提供的块存储或网络文件系统那样可以随意挂载。如果tikv/pd迁移到其他节点，相当于数据目录也被清空，所以必须保证tikv/pd的pod在升级完成后仍然能够调度在原地，这也是要由tidh-operator的controller来保证。tidb的数据副本之间由raft算法来保证一致性，当集群中某一个节点暂时断开，可以不影响整个服务，所以在集群升级过程中，必须严格按照服务的依赖关系，再依次对pod进行升级。当节点出现故障时，同样是由于挂载本地数据盘的原因，也不能像sta

15、tefulset那样直接把pod迁移走。当tidb operator检测到节点失效，首先要等一段时间，以确认节点不会再恢复了，再开始迁移恢复的操作。首先，调度选择一个新节点启动一个pod，然后通知tidb将失效节点放弃掉，并将新启的pod加入集群。后面会由tidb的pd模块来完成数据副本数恢复以及数据往新节点上迁移，从而重新维持集群内数据平衡。以上仅列举了tidb几种典型的运维操作流程，实际生产上运维还有很多情况需要考虑，这些都以程序的方式在tidb-operator里实现。借助kuhernetes和tidh-operator来代替人t，高效地完成tidb数据库在云平台上的复杂运维管理。2.动

16、态扩缩容弹性水平伸缩是tidb数据库最主要的特性之一。在大数据时代，人们对数据存储的需求快速膨胀，有时用户很难预估自己业务规模的增长速度，如果采用传统存储方案，可能很快发现存储容量达到了瓶颈，然后不得不停机来做迁移和扩容。如果使用cloud tidb的方案，这个过程就非常简单，只需在cloud控制台上修改一下tidb的节点数量，就能快速完成扩容操作，期间还不会影响业务的正常服务。那么，在cloud后台，同样借助kuhernetes和tidh-operator的能力来完成tidb增减节点操作。kubernetes本身的运作是基于一种reconcile机制，简单来说就是当用户提交一个新请求，比如期

17、望集群里跑5个tikv节点，而目前正在跑的只有3个，那么reconcile机制就会发现这个差异，先由kuhernetes调度器根据集群整体资源情况，并结合tidb节点分配的亲和性原则和资源隔离原则来分配节点。另外，很重要一点是选择有空闲local pv的机器来创建pod并进行挂载，最终通过tidh-operator将2个节点加入tidb集群。缩容的过程也类似。假如数据库存储的总数据量变少，需要减少节点以节省成本，首先用户通过云控制台向后端提交请求，在一个reconciling周期内发现差异，tidb-operator的controller开始通知tidb集群执行节点下线的操作。安全下线可能是比

18、较长的过程，因为需要由pd模块将下线节点的数据搬移到其他节点，期间集群都可以正常服务。当下线完成，这些tikv变成tomhstone状态，而tidb-operator也会通知kuhernetes销毁这些pod，并且由tidh-volume -manager来回收local pv。3.资源隔离资源隔离也是云上用户关心的一个问题。尤其是数据库这类应用，不同租户的数据库实例，甚至一个租户的多套数据库实例，都在kubernetes管理集群上，相互间会不会有资源争抢问题？某个实例执行高负载计算任务时，cpu、内存、1/0等会不会对同台机器上部署的其他实例产生影响？其实，容器本身就是资源隔离的一个解决方案

19、，容器底层是llnux内核提供的cgroups技术，用于限制容器内的cpu、内存以及io等资源的使用，并通过namespace技术实现隔离。而kuhernetes作为容器编排系统，能根据集群中各个节点的资源状况，选择最优策略来调度容器。同时，tidh-operator会根据tidb自身特性和约束来综合决策tidb节点的调度分配。例如，当一个kuhernetes集群横跨多个可用区，用户申请创建一个tidb集群，那么首先根据高可用性原则，将存储节点尽量分配到不同可用区，并给tikv打上标签。那么同一个可用区内也尽量不把多个tikv部署到相同的物理节点上，以保证集群资源最大化利用。此外，每个loca

20、l pv也是一块独立磁盘，每个tikv的pod分别挂载不同的盘，所以1/0上也是完全隔离。kuhernetes还可以配置pod之间的亲和性（affinity）和反亲和性（anti-affinit）t）。例如，在tikv和tidb之间，可以通过亲和性使其调度到网络延时较小的节点上，提高网络传输效率。tikv之間借助反亲和性，使其分散部署到不同主机、机架和可用区上，降低因硬件或机房故障而导致的数据丢失风险。上面解释了容器层的隔离，也可以看做是物理层的隔离。再来看数据层的隔离，tidb的调度体系也有所考虑，比如一个大的tidb集群，节点分布在很多台主机，跨越多个机架、可用区，那么用户可以定义name

21、space，这是一个逻辑概念，不同业务的数据库和表放置在不同的namespace，再通过配置name space、tikv节点以及区域的对应关系，由pd模块来进行调度，从而实现不同业务数据在物理上的隔离。4.高可用性tidb作为一个分布式数据库，本身就具有高可用性，每个核心组件都可以独立地扩缩容。任意一个模块在部署多份副本时，如果有一个挂掉，整体仍然可以正常对外提供服务，这是由raft协议保证的。但是，如果对数据库节点的调度不加任何限制，包含一份数据的多个副本的节点可能会被调度到同一台主机。这时如果主机发生故障，就会同时失去多个本，一个raft分组内失去多数派节点就会导致整个集群处于不可用状态，因此tidh-operator在调度tikv节点时需要避免出现这种情况。另外，tidb支持基于标签的数据调度，能给不同tikv实例加上描述物理信息的标签。例如，地域（region）、口用区（az）、