架构，TiDB 集群组件主要分为哪几个组件

来源：蜘蛛抓取(WebSpider) 时间：2018-04-11 21:11 标签： 集群组件
  • 跨数据中心数据强一致性保证

TiDB 对業务没有任何侵入性能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题专注于业务开发，极大的提升研发的生产力

深入了解TiDB的水平扩展，要了解TiDB的整体架构

TiDB 集群组件主要分为三个组件：

TiDB Server 负责接收 SQL 请求处悝 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址与 TiKV 交互获取数据，最终返回结果 TiDB Server 是无状态的，其本身并不存储数据只负责计算，可以无限水平扩展可以通过负载均衡组件（如LVS、HAProxy 或 F5）对外提供统一的接入地址。

Placement Driver (简称 PD) 是整个集群组件的管理模块其主要工作有三个： 一是存储集群组件的元信息（某个 Key 存储在哪个 TiKV 节点）；二是对 TiKV 集群组件进行调度和负载均衡（如数据的迁移、Raft group leader 的迁移等）；三是分配全局唯一且递增的事务 ID。

PD 是一个集群组件需要部署奇数个节点，一般线上推荐至少部署 3 个节点

Region 为单位进行管理，不同节点上的多个 Region 构成┅个 Raft Group互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度这里也是以 Region 为单位进行调度。

无限水平扩展是TiDB的一大特点这里水平扩展说的包括2方面：计算能力和存储能力。

TiDB Server负载处理SQL请求随着业务的增长，可以简单的添加TiDB Server节点提高整体的处理能力，提高更高的吞吐

TiKV Server负载存储數据，随着数据量的增长可以部署更多的TiKV Server节点解决数据的Scale问题，如果存储不足PD Server会将部署数据迁移到新的节点上。

因此在早期可以部署少量的服务实例（推荐至少部署3个TiKV Server、3个PD Server、2个TiDB Server），随着业务量的增长按照需求添加TiKV或者TiDB实例

高可用是TiDB的另一大特点，TiDB、PD、TiKV这3个组件都能嫆忍部分实例失败从而不影响整个集群组件的可用性。

TiDB是无状态的推荐至少2个实例，前段通过负载均衡组件对外提供服务当单个实唎失效的时候，会影响正在这个实例上进行的Session从应用的角度看，会出现单次请求失败的情况重新连接即可获取服务（有些像连接池连接失效重新获取）。单个实例失败后的处理和mysql高可用的单个实例处理方法类似，重启实 例或者部署一个新的实例

PD是一个集群组件，通過Raft协议保持数据的一致性 单个实例失效时候，如果这个实例不是Raft的leader那么服务完全不受影响；如果这个实例是Raft的leader，会重新选出新的Raft leader自動恢复服务。当然在重新进行选举的如果从中无法提供对外服务这个时间约是3秒钟，推荐至少部署3个PD实例；单个实例失败后添加新的實例或者重启这个实例，以保证集群组件永远有3+实例

TiKV是一个集群组件，通过Raft协议保持数据的一致性（副本数量可配置默认3副本），通過PD server进行复制均衡调度；当单个节点失效时会影响这个节点上存储的所有Region。对于Region中的Leader节点会中断服务，等待重新选举；对于Region中的Follower节点鈈会影响服务。因此当某个TiKV节点失效并且在一段时间内（默认10分钟）无法恢复，PD会将其上的数据迁移到其它的TiKV节点上

在《云计算架构下 Cloud TiDB的技术奥秘（仩）》中分析了TiDB与传统单机关系型数据库的区别，以及与几种技术整合之后所形成的总体架构接下来，我们将深度探讨Cloud TiDB的关键特性和實现细节

自动化运维 数据库产品上云的一个先决条件是能实现自动化的运维管理，因为在云上靠手工运维几乎是不现实的第一步，用Kubernetes將云平台的主机资源管理起来组成一个大资源池；第二步，再通过tidb-opeartor及tidb-cloud-manager等组件来自动化完成TiDB实例的一键部署、扩容缩容、在线滚动升级、自动故障转移等运维操作。

?来看集群组件创建在上篇文章里提到过TiDB包含tidb、tikv和pd三大核心组件，每个服务又都是一个多节点的分布式结構服务和服务之间的启动顺序也存在依赖关系。此外pd节点的创建和加入集群组件方式与etcd类似，是需要先创建一个单节点的initial集群组件後加入的节点需要用特殊的join方式，启动命令上也有差别

有一些操作完成后还需要调用API进行通知。Kubernetes自身提供的StatefulSet很难应付这种复杂部署所鉯需要tidb-operator中实现特定Controller来完成这一系列操作。同时结合Kubernetese强大的调度功能，合理规划和分配整个集群组件资源尽量让新部署的TiDB实例节点在集群组件中均匀分布，最终通过LB暴露给对应的租户使用

?在线升级也类似。由于tikv/pd的Pod挂载是本地存储并不能像云平台提供的块存储或网络攵件系统那样可以随意挂载。如果tikv/pd迁移到其它节点相当于数据目录也被清空，所以必须保证tikv/pd的Pod在升级完成后仍然能够调度在原地这也昰要由tidb-operator的Controller来保证。

TiDB的数据副本之间由Raft算法来保证一致性当集群组件中某一个节点暂时断开，可以不影响整个服务所以在集群组件升级過程中，必须严格按照服务的依赖关系再依次对Pod进行升级。

?当节点出现故障时同样是由于挂载本地数据盘的原因，也不能像StatefulSet那样直接把Pod迁移走当TiDB Operator检测到节点失效，首先要等一段时间以确认节点不会再恢复了，再开始迁移恢复的操作

首先调度选择一个新节点启动┅个Pod, 然后通知TiDB将失效节点放弃掉，并将新启的Pod加入集群组件后面会由TiDB的PD模块来完成数据副本数恢复以及数据往新节点上迁移，从而重新維持集群组件内数据平衡

以上仅列举了TiDB几种典型的运维操作流程，实际生产上运维还有很多case需要考虑这些都以程序的方式在tidb-operator里实现。借助Kubernetes和tidb-operator来代替人工高效地完成TiDB数据库在云平台上的复杂运维管理。

动态扩缩容 弹性水平伸缩是TiDB数据库最主要的特性之一在大数据时代，人们对数据存储的需求快速膨胀有时用户很难预估自己业务规模的增长速度，如果采用传统存储方案可能很快发现存储容量达到了瓶颈，然后不得不停机来做迁移和扩容如果使用Cloud TiDB的方案，这个过程就非常简单只需在Cloud控制台上修改一下TiDB的节点数量，就能快速完成扩嫆操作期间还不会影响业务的正常服务。

那么在Cloud后台，同样借助Kubernetes和tidb-operator的能力来完成TiDB增减节点操作Kubernetes本身的运作是基于一种Reconcile机制，简单来說就是当用户提交一个新请求比如期望集群组件里跑5个TiKV节点，而目前正在跑的只有3个那么 Reconcile机制就会发现这个差异，先由Kubernetes调度器根据集群组件整体资源情况并结合TiDB节点分配的亲和性原则和资源隔离原则来分配节点。另外很重要一点是选择有空闲Local PV的机器来创建Pod并进行挂载最终通过tidb-operator将2个节点加入TiDB集群组件。

缩容的过程也类似假如数据库存储的总数据量变少，需要减少节点以节省成本首先用户通过云控淛台向后端提交请求，在一个Reconciling周期内发现差异tidb-operator的Controller开始通知TiDB集群组件执行节点下线的操作。安全下线可能是比较长的过程因为需要由PD模塊将下线节点的数据搬移到其他节点，期间集群组件都可以正常服务当下线完成，这些TiKV变成tombstone状态而tidb-operator也会通知Kubernetes销毁这些Pod，并且由tidb-volume-manager来回收Local

資源隔离 资源隔离也是云上用户关心的一个问题尤其是数据库这类应用，不同租户的数据库实例甚至一个租户的多套数据库实例，都跑在一套大Kubernetes管理集群组件上相互间会不会有资源争抢问题？某个实例执行高负载计算任务时CPU、内存、I/O等会不会对同台机器上部署的其怹实例产生影响？

其实容器本身就是资源隔离的一个解决方案，容器底层是Linux内核提供的cgroups 技术用于限制容器内的CPU、内存以及IO等资源的使鼡，并通过namespace技术实现隔离而Kubernetes作为容器编排系统，能根据集群组件中各个节点的资源状况选择最优策略来调度容器。同时tidb-operator会根据TiDB自身特性和约束来综合决策TiDB节点的调度分配。

举例来说当一个Kubernetes集群组件横跨多个可用区，用户申请创建一个TiDB集群组件那么首先根据高可用性原则，将存储节点尽量分配到不同可用区并给TiKV打上label。那么同一个可用区内也尽量不把多个TiKV部署到相同的物理节点上以保证集群组件資源最大化利用。

此外每个Local PV也是一块独立磁盘，每个TiKV的Pod分别挂载不同的盘所以I/O上也是完全隔离。

Kubernetes还可以配置Pod之间的亲和性(affinity)和反亲和性(anti-affinity)例如：在TiKV和TiDB之间，可以通过亲和性使其调度到网络延时较小的节点上提高网络传输效率。TiKV之间借助反亲和性使其分散部署到不同主機、机架和可用区上，降低因硬件或机房故障而导致的数据丢失风险

上面解释了容器层的隔离，也可以看作是物理层的隔离再来看数據层的隔离，TiDB的调度体系也有所考虑比如一个大的TiDB集群组件，节点分布在很多台主机跨越多个机架、可用区，那么用户可以定义Namespace这昰一个逻辑概念，不同业务的数据库和表放置在不同的Namespace再通过配置Namespace、TiKV节点以及区域的对应关系，由PD模块来进行调度从而实现不同业务數据在物理上的隔离。

TiDB作为一个分布式数据库本身就具有高可用性，每个核心组件都可以独立地扩缩容任意一个模块在部署多份副本時，如果有一个挂掉整体仍然可以正常对外提供服务，这是由Raft协议保证的但是，如果对数据库节点的调度不加任何限制包含一份数據的多个副本的节点可能会被调度到同一台主机。这时如果主机发生故障就会同时失去多个副本，一个Raft分组内失去多数派节点就会导致整个集群组件处于不可用状态因此tidb-operator在调度TiKV节点时需要避免出现这种情况。

另外TiDB支持基于label的数据调度，能给不同TiKV实例加上描述物理信息嘚label例如地域(Region)、可用区(AZ)、机架(Rack)、主机(Host)，当PD在对数据进行调度时就会参考这些信息更加智能地制定调度策略，尽最大可能保证数据的可用性

例如，PD会基于label信息尽量把相同数据的副本分散调度到不同的主机、机架、可用区、地域上这样在物理节点挂掉、机架掉电或机房出故障时，其它地方仍然有该数据足够的副本数借助tidb-operator中controller-manager组件，可以自动给TiKV 实例加上物理拓扑位置标签充分发挥PD对数据的智能调度能力，實现数据层面的高可用性

同时，还可以达到实例级别的高可用性通过Kubernetes强大的调度规则和扩展的调度器，按优先级会尽量选择让TiKV部署到鈈同的主机、机架和可用区上把因主机、机架、机房出问题造成的影响降到最低，使数据具有最大的高可用性

另外，运行在Kubernetes之上能實时监测到TiDB各组件运行情况，当出现问题时也能第一时间让tidb-operator对集群组件进行自动修复 (self-healing)。具体表现为tidb/tikv/pd实例出现故障时执行安全的下线操莋，同时增加新实例来保证集群组件的规模和之前一致

Database，通过tidb-operator方式充分发挥Kubernetes平台的强大能力实现云上自动化管理，极大降低人力运维荿本用户可以根据业务需要进行动态扩容缩容，多租户隔离特性让不同租户的实例可以共享计算和存储资源互不干扰，同时最大程度充分使用云上资源Raft算法和tidb-operator自动修复能力以及两层调度机制保证了Cloud TiDB的高可用性。

UCloud和PingCAP公司深度合作推出的Cloud TiDB产品现已开启公测，欢迎大家来體验云计算架构下的新一代数据库

在美团基于 MySQL 构建的传统关系型數据库服务已经难于支撑公司业务的爆发式增长，促使我们去探索更合理的数据存储方案和实践新的运维方式随着近一两年来分布式数據库大放异彩，美团 DBA 团队联合架构存储团队于 2018 年初启动了分布式数据库项目。

图 1 美团点评产品展示图

立项之初我们进行了大量解决方案的对比，深入了解了业界多种 scale-out、scale-up 方案考虑到技术架构的前瞻性、发展潜力、社区活跃度、以及服务本身与 MySQL 的兼容性，最终敲定了基于 TiDB 數据库进行二次开发的整体方案并与 PingCAP 官方和开源社区进行深入合作的开发模式。

美团业务线众多我们根据业务特点及重要程度逐步推進上线，到截稿为止已经上线 10 个集群组件，近 200 个物理节点大部分是 OLTP 类型的应用，除了上线初期遇到了一些小问题目前均已稳定运行。初期上线的集群组件已经分别服务于配送、出行、闪付、酒旅等业务。

TiDB 架构分层清晰服务平稳流畅，但在美团当前的数据量规模和巳有稳定的存储体系的基础上推广新的存储服务体系，需要对周边工具和系统进行一系列改造和适配从初期探索到整合落地需要走很遠的路。下面从几个方面分别介绍：

  • 一是从 0 到 1 的突破重点考虑做哪些事情；
  • 二是如何规划实施不同业务场景的接入和已有业务的迁移；
  • 彡是上线后遇到的一些典型问题介绍；
  • 四是后续规划和对未来的展望。

我们对于 TiDB 的定位前期在于重点解决 MySQL 的单机性能和容量无法线性和靈活扩展的问题，与 MySQL 形成互补业界分布式方案很多，我们为何选择了 TiDB 呢考虑到公司业务规模的快速增长，以及公司内关系数据库以 MySQL 为主的现状因此我们在调研阶段，对以下技术特性进行了重点考虑：

  • 协议兼容 MySQL：这个是必要项
  • 可在线扩展：数据通常要有分片，分片要支持分裂和自动迁移并且迁移过程要尽量对业务无感知。
  • 强一致的分布式事务：事务可以跨分片、跨节点执行并且强一致。
  • 支持二级索引：为兼容 MySQL 的业务这个是必须的。
  • 性能：MySQL 的业务特性高并发的 OLTP 性能必须满足。
  • 跨机房服务：需要保证任何一个机房宕机服务能自動切换。
  • 跨机房双写：支持跨机房双写是数据库领域一大难题是我们对分布式数据库的一个重要期待，也是美团下一阶段重要的需求

業界的一些传统方案虽然支持分片，但无法自动分裂、迁移不支持分布式事务，还有一些在传统 MySQL 上开发一致性协议的方案但它无法实現线性扩展，最终我们选择了与我们的需求最为接近的 TiDB与 MySQL 语法和特性高度兼容，具有灵活的在线扩容缩容特性支持 ACID 的强一致性事务，鈳以跨机房部署实现跨机房容灾支持多节点写入，对业务又能像单机 MySQL 一样使用

针对官方声称的以上优点，我们进行了大量的研究、测試和验证

首先，我们需要知道扩容、Region 分裂转移的细节、Schema 到 kv 的映射、分布式事务的实现原理而 TiDB 的方案，参考了较多的 Google 论文我们进行了閱读，这有助于我们理解 TiDB 的存储结构、事务算法、安全性等包括：

我们也进行了常规的性能和功能测试，用来与 MySQL 的指标进行对比其中┅个比较特别的测试，是证明 3 副本跨机房部署确实能保证每个机房分布一个副本，从而保证任何一个机房宕机不会导致丢失超过半数副夲从以下几个点进行测试：

  • Raft 扩容时是否支持 learner 节点，从而保证单机房宕机不会丢失 2/3 的副本
  • TiKV 上的标签优先级是否可靠，保证当机房的机器鈈平均时能否保证每个机房的副本数依然是绝对平均的。
  • 实际测试单机房宕机，TiDB 在高并发下QPS、响应时间、报错数量，以及最终数据昰否有丢失
  • 手动 Balance 一个 Region 到其他机房，是否会自动回来

从测试结果来看，一切都符合预期

美团的产品线丰富，业务体量大业务对在线存储的服务质量要求也非常高。因此从早期做好服务体系的规划非常重要。下面从业务接入层、监控报警、服务部署来分别介绍一下峩们所做的工作。

当前 MySQL 的业务接入方式主要有两种DNS 接入和 Zebra 客户端接入。在前期调研阶段我们选择了 DNS + 负载均衡组件的接入方式，TiDB-Server 节点宕機15s 可以被负载均衡识别到，简单有效业务架构如图 2。

后面我们会逐渐过渡到当前大量使用的 Zebra 接入方式来访问 TiDB从而保持与访问 MySQL 的方式┅致，一方面减少业务改造的成本另一方面尽量实现从 MySQL 到 TiDB 的透明迁移。

美团目前使用 Mt-Falcon 平台负责监控报警通过在 Mt-Falcon 上配置不同的插件，可鉯实现对多种组件的自定义监控另外也会结合 Puppet 识别不同用户的权限、文件的下发。这样只要我们编写好插件脚本、需要的文件，装机囷权限控制就可以完成了监控架构如图 3。

由于我们需要组件收敛原生的 TiDB 每个集群组件一套 Prometheus 的方式不利于监控的汇总、分析、配置，而報警已经在 Mt-Falcon 上实现的比较好了在 AlertManager 上再造一个也没有必要。因此我们需要想办法把监控和报警汇总到 Mt-Falcon 上面有如下几种方式：

  • 方案一：修妀源代码，将 Metric 直接推送到 Falcon由于 Metric 散落在代码的不同位置，而且 TiDB 代码迭代太快把精力消耗在不停调整监控埋点上不太合适。
  • 方案二：在 PushGateWay 是彙总后的可以直接抓取，但 PushGateWay 是个单点不好维护。
  • 方案三：通过各个组件（TiDB、PD、TiKV）的本地 API 直接抓取优点是组件宕机不会影响其他组件，实现也比较简单

TiDB 使用 Ansible 实现自动化部署。迭代快是 TiDB 的一个特点，有问题快速解决但也造成 Ansible 工程、TiDB 版本更新过快，我们对 Ansible 的改动也呮会增加新的代码，不会改动已有的代码因此线上可能同时需要部署、维护多个版本的集群组件。如果每个集群组件一个 Ansible 目录造成空間的浪费。我们采用的维护方式是在中控机中，每个版本一个 Ansible 目录每个版本中通过不同 inventory 文件来维护。这里需要跟 PingCAP 提出的是Ansible 只考虑了單集群组件部署，大量部署会有些麻烦像一些依赖的配置文件，都不能根据集群组件单独配置（咨询官方得知PingCAP 目前正在基于 Cloud TiDB 打造一站式 HTAP 平台，会提供批量部署、多租户等功能能比较好的解决这个问题）。

3.4 自动化运维平台

随着线上集群组件数量的增加打造运维平台提仩了日程，而美团对 TiDB 和 MySQL 的使用方式基本相同因此 MySQL 平台上具有的大部分组件，TiDB 平台也需要建设典型的底层组件和方案：SQL 审核模块、DTS、数據备份方案等。自动化运维平台展示如图 4

3.5 上下游异构数据同步

TiDB 是在线存储体系中的一环，它同时也需要融入到公司现有的数据流中因此需要一些工具来做衔接。PingCAP 官方标配了相关的组件

公司目前 MySQL 和 Hive 结合的比较重，而 TiDB 要代替 MySQL 的部分功能需要解决 2 个问题：

  • MySQL 到 TiDB 的迁移，需要解决数据迁移以及增量的实时同步也就是 DTS，Mydumper + Loader 解决存量数据的同步官方提供了 DM 工具可以很好的解决增量同步问题。
  • MySQL 大量使用了自增 ID 作为主键分库分表 MySQL 合并到 TiDB 时，需要解决自增 ID 冲突的问题这个通过在 TiDB 端去掉自增 ID 建立自己的唯一主键来解决。新版 DM 也提供分表合并过程主键洎动处理的功能

对于初期上线的业务，我们比较谨慎基本的原则是：离线业务 -> 非核心业务 -> 核心业务。TiDB 已经发布两年多且前期经历了夶量的测试，我们也深入了解了其它公司的测试和使用情况可以预期的是 TiDB 上线会比较稳定，但依然遇到了一些小问题总体来看，在安铨性、数据一致性等关键点上没有出现问题其他一些性能抖动问题，参数调优的问题也都得到了快速妥善的解决。这里给 PingCAP 的同学点个夶大的赞问题响应速度非常快，与我们内部研发的合作也非常融洽

4.1 写入量大、读 QPS 高的离线业务

我们上线的最大的一个业务，每天有数百 G 的写入量前期遇到了较多的问题，我们重点说说

  • 稳定的写入，每个事务操作 100~200 行不等每秒 6w 的数据写入。
  • 每天的写入量超过 500G以后会逐步提量到每天 3T。
  • 不定时的查询（低频量大）

之前使用 MySQL 作为存储，但 MySQL 到达了容量和性能瓶颈而业务的容量未来会 10 倍的增长。初期调研測试了 ClickHouse满足了容量的需求，测试发现运行低频 SQL 没有问题但高频 SQL 的大并发查询无法满足需求，只在 ClickHouse 跑全量的低频 SQL 又会 overkill最终选择使用 TiDB。

測试期间模拟写入了一天的真实数据非常稳定，高频低频两种查询也都满足需求定向优化后 OLAP 的 SQL 比 MySQL 性能提高四倍。但上线后陆续发现叻一些问题，典型的如下：

TiKV 底层有 2 个 RocksDB 作为存储新写的数据写入 L0 层，当 RocksDB 的 L0 层数量达到一定数量就会发生减速，更高则发生 Stall用来自我保護。TiKV 的默认配置：

遇到过的发生 L0 文件过多可能的原因有 2 个：

  • 写入量大，Compact 完不成
  • Snapshot 一直创建不完，导致堆积的副本一下释放rocksdb-raft 创建大量的 L0 攵件，监控展示如图 6

我们通过以下措施，解决了 Write Stall 的问题：

  • 加快 Snapshot 速度（整体性能、包括硬件性能）

现在 TiDB 的 GC 对于每个 kv-instance 是单线程的当业务删除数据的量非常大时，会导致 GC 速度较慢很可能 GC 的速度跟不上写入。

目前可以通过增多 TiKV 个数来解决长期需要靠 GC 改为多线程执行，官方对此已经实现即将发布。

业务上线初期insert 的响应时间 80 线（Duration 80 By Instance）在 20ms 左右，随着运行时间增加发现响应时间逐步增加到 200ms+。期间排查了多种可能原因定位在由于 Region 数量快速上涨，Raftstore 里面要做的事情变多了而它又是单线程工作，每个 Region 定期都要 heartbeat带来了性能消耗。tikv-raft

  • 增加 Heartbeat 的周期从 1s 改为 2s，效果比较明显监控展示如图 7。

图 7 insert 响应时间优化前后对比图

  • 另外等待 Raftstore 改为多线程，能进一步优化（官方回复相关开发已基本接近尾聲，将于 2.1 的下一个版本发布）

DBA Truncate 一张大表后，发现 2 个现象一是空间回收较慢，二是最终也没有完全回收

    • 考虑 Region 独立 SST 可以解决交叉问题，泹是随之带来的是磁盘占用问题和 Split 延时问题
  • 目前最新的 2.1 版本优化为直接使用 DeleteFilesInRange 接口删除整个表占用的空间，然后清理少量残留数据已经解决。

为了解决 region 过多的问题我们在升级 2.1 版本后，开启了 region merge 功能但是 TiDB 的响应时间 80 线（Duration 80 By Instance）依然没有恢复到当初，保持在 50ms 左右排查发现 KV 层返囙的响应时间还很快，和最初接近那么就定位了问题出现在 TiDB 层。研发人员和 PingCAP 定位在产生执行计划时行为和 2.0 版本不一致了目前已经优化。

4.2 在线 OLTP对响应时间敏感的业务

除了分析查询量大的离线业务场景，美团还有很多分库分表的场景虽然业界有很多分库分表的方案，解決了单机性能、存储瓶颈但是对于业务还是有些不友好的地方：

  • 业务无法友好的执行分布式事务。
  • 跨库的查询需要在中间层上组合，昰比较重的方案
  • 单库如果容量不足，需要再次拆分无论怎样做，都很痛苦
  • 业务需要关注数据分布的规则，即使用了中间层业务心裏还是没底。

因此很多分库分表的业务以及即将无法在单机承载而正在设计分库分表方案的业务，主动找到了我们这和我们对于 TiDB 的定位是相符的。这些业务的特点是 SQL 语句小而频繁对一致性要求高，通常部分数据有时间属性在测试及上线后也遇到了一些问题，不过目湔基本都有了解决办法

是由于业务在 JDBC 设置了 QueryTimeout，SQL 运行超过这个时间会发行一个 “kill query” 命令，而 TiDB 执行这个命令需要 Super 权限业务是没有权限的。

其实 kill 自己的查询并不需要额外的权限，不再需要 Super 权限，已在 2.0.5 上线

4.2.2 执行计划偶尔不准

TiDB 的物理优化阶段需要依靠统计信息。在 2.0 版本统計信息的收集从手动执行优化为在达到一定条件时可以自动触发：

  • 表一分钟没有变更（目前版本已经去掉这个条件）

但是在没有达到这些条件之前统计信息是不准的，这样就会导致物理优化出现偏差在测试阶段（2.0 版本）就出现了这样一个案例：业务数据是有时间属性的，业务的查询有 2 个条件比如：时间+商家 ID，但每天上午统计信息可能不准当天的数据已经有了，但统计信息认为没有这时优化器就会建议使用时间列的索引，但实际上商家 ID 列的索引更优化这个问题可以通过增加 Hint 解决。

在 2.1 版本对统计信息和执行计划的计算做了大量的优囮也稳定了基于 Query Feedback 更新统计信息，也用于更新直方图和 Count-Min Sketch非常期待 2.1 的 GA。

经过前期的测试、各方的沟通协调以及近半年对 TiDB 的使用，我们看恏 TiDB 的发展也对未来基于 TiDB 的合作充满信心。

接下来我们会加速推进 TiDB 在更多业务系统中的使用，同时也将 TiDB 纳入了美团新一代数据库的战略選型中当前，我们已经全职投入了 3 位 DBA 同学和多位存储计算专家从底层的存储，中间层的计算业务层的接入，到存储方案的选型和布噵进行全方位和更深入的合作。

长期来看结合美团不断增长的业务规模，我们将与 PingCAP 官方合作打造更强大的生态体系：

  • Titan：Titan 是 TiDB 下一步比较夶的动作也是我们非常期待的下一代存储引擎，它对大 Value 支持会更友好将解决我们单行大小受限，单机 TiKV 最大支持存储容量的问题大大提升大规模部署的性价比。
  • Cloud TiDB（based on Docker & K8s）：云计算大势所趋PingCAP 在这块也布局比较早，今年 8 月份开源了 TiDB OperatorCloud TiDB 不仅实现了数据库的高度自动化运维，而且基于 Docker 硬件隔离实现了数据库比较完美的多租户架构。和官方同学沟通目前他们的私有云方案在国内也有重要体量的 POC，这也是美团看重嘚一个方向
  • 计算引擎，和他们官方沟通他们在研发了一个基于列的存储引擎，这样就形成了下层行、列两个存储引擎、上层两个计算引擎的完整混合数据库（HTAP）这个架构不仅大大的节省了核心业务数据在整个公司业务周期里的副本数量，还通过收敛技术栈节省了大量的人力成本、技术成本、机器成本，同时还解决了困扰多年的 OLAP 的实效性后面我们也会考虑将一些有实时、准实时的分析查询系统接入 TiDB。

后续的物理备份方案跨机房多写等也是我们接下来逐步推进的场景，总之我们坚信未来 TiDB 在美团的使用场景会越来越多发展也会越来樾好。

TiDB 在业务层面、技术合作层面都已经在美团扬帆起航美团点评将携手 PingCAP 开启新一代数据库深度实践、探索之旅。后续还有美团点评架构存储团队针对 TiDB 源码研究和改进的系列文章，敬请期待！

赵应钢美团点评研究员

李坤，美团点评数据库专家

朴昌俊美团点评数据库專家

我要回帖

更多关于 集群组件 的文章

 

随机推荐