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

?

?

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

?

?

近日，国内云计算服务商UCloud与国内开源分布式NewSOL数据库TiDB团队PingCAP正式达成合作，双方联手在UCloud全球数据中心推出了新一代TiDB的云端版本-CloudTiDB。

作为一款定位于Cloud-native的数据库，目前TiDB在云整合上已取得了阶段性进展。CloudTiDB产品在UCloud平台正式开启公测，TiDB弹性伸缩特性在Cloud提供的基础设施支持下得到了淋漓尽致地体现。在感受云数据库魅力的同时，让我们来探索—下TiDB与Cloud背后的技术秘密。

一、TiDB与传统单机关系型数据库的区别

首先，从TiDB的架构说起。TiDB作为一款开源的分布式数据库产品，具有多副本，能够根据业务需求非常方便地进行弹性伸缩，并且扩缩容期间对上层业务无影响。

TiDB的主体架构包含三个模块，对应Githuh上PingCAP组织下的三个开源项目（TiDB/TiKV/PD）：

1）TiDB主要是负责SQL的解析器和优化器，它相当于计算执行层，同时也负责客户端接人和交互；

2）TiKV是一套分布式的Kev-Value存储引擎，它承担整个数据库的存储层，数据水平扩展和多副本高可用特性都在这一层实现；

3）PD相当于分布式数据库的大脑，一方面负责收集和维护数据在各个TiKV节点的分布情况，另一方面PD承担调度器的角色，根据数据分布状况以及各个存储节点的负载来采取合适的调度策略，维持整个系统的平衡与稳定。

上述三个模块中的每个角色都是一个多节点组成的集群，所以最终TiDB的架构如图1所示。

由此可见，分布式系统本身的复杂性不仅导致人工部署和运维成本较高，而且容易出错。传统的自动化部署运维T具（如Puppet/Chef/SaltStack/Ansihle等），由于缺乏状态管理，在节点出现问题时不能及时自动完成故障转移，需要人工干预，有些则需要写大量DSL甚至与Shell脚本一起混合使用，可移植性较差，维护成本比较高。

在云时代，容器成为应用分发部署的基本单位，谷歌基于内部使用数十年的容器编排系统Borg经验，推出的开源容器编排系统Kuhernetes就成为当前容器编排技术的主流。

二、TiDB与Kubernetes的深度整合

作为CloudNativeDatahase，TiDB选择拥抱容器技术，并与Kuhernetes进行深度整合，使其可以非常方便地基于Kuhernetes完成數据库白动化管理。甚至可以说Kuhernetes项目是为Cloud而生，利用云平台IaaS层提供的API可以很方便地与云进行整合。这样只要让TiDB与Kuhernetes结合得更好，进而就能实现其与各个云平台的整合，使TiDB在云上的快速部署和高效运维成为现实。

1.Kubernetes简介

Kuhernetes最早是作为一个纯粹的容器编排系统而诞生，用户部署好Kuhernetes集群之后，直接使用其内置的各种功能部署应用服务。由于这个PaaS平台使用起来非常便利，吸引了很多用户，不同用户也提出了各种不同需求，有些特性需求Kuhernetes可直接在其核心代码里实现，但有些特性并不适合合并到主程序中。

为了满足这类需求，Kubernetes开放出一些API供用户自己扩展，实现自身需求。当前Kuhernetes已经升级到1.8版本，内部API变得越来越开放，使其更像是一个跑在云上的操作系统。用户可以把它当作一套云的SDK或Framework来使用，而且可以很方便地开发组件来扩展满足自身业务需求，对有状态服务的支持就是一个代表性实例。

在最早期，Kuhernetes项目只支持无状态服务（StatelessService）来管理，无状态服务通过ReplicationController定义多个副本，由Kuhernetes调度器来决定在不同节点上启动多个Pod，实现负载均衡和故障转移。对于无状态服务，多个副本对应的Pod是等价的，所以当节点出现故障时，在新节点上启动一个Pod与失效的Pod是等价的，不会涉及状态迁移问题，因而管理非常简单。

2.有状态服务StatefulService

不过，对于有状态服务（StatefulService），由于需要将数据持久化到磁盘，使得不同Pod之间不能再认为成等价，也就不能再像无状态服务那样随意地进行调度迁移。Kuhernetesl.3版本提出PetSet的概念，用来管理有状态服务并在1.5版本中将其更名为StatefulSet。

StatefuISet明确定义了一组Pod中的每个身份，启动和升级都按特定顺序来操作。另外，使用持久化卷存储（PersistentVolume）来作为存储数据的载体，当节点失效Pod需要迁移时，对应的