携程数据库(携程大数据报告)

前言

携程从2014年左右开始全面使用MySQL数据库。随着业务的增长，数据的激增，单机实例的瓶颈逐渐显现，比如单个表的行数太多，导致历史数据查询耗时，单个数据库容量太大，导致磁盘空不足。针对这些问题，我们采取了很多措施，比如横向拆分子数据库和子表，一主多从的读写分离，升级硬件SSD，增加前端Redis缓存等。，但同时也使得整个业务层架构更加复杂，无法实现透明性和灵活性，于是我们开始将目光转向分布式数据库来解决这些痛点。

近年来，受Spanner &的启发，基于CAP理论、Paxos和Raft协议作为工程实现的分布式数据库蓬勃发展。从硅谷的CockroachDB到中国制造的TiDB，他们在社区里产生了巨大的影响。携程也从社区活跃度、用户规模、易用性等方面对这些产品做了研究，最终选择了国内的TiDB。

TiDB是一个开源的NewSQL数据库，支持混合事务和分析处理(HTAP)工作负载，兼容大部分MySQL语法，提供横向可伸缩性、强一致性和高可用性。主要由PingCAP公司开发和支持，在Apache 2.0下授权。2018年11月，我们启动了TiDB的POC，以及与携程现有运维平台的整合。2019年1月，第一个上线应用正式连接。最初的目标是确保数据库的可用性并存储足够的关系数据。随着TiDB的快速迭代，越来越多的功能进入社区，比如HATP功能，让我们不局限于原来的目标，开始新的探索。本文将介绍携程业务场景下TiDB的运维实践，希望对读者有所帮助和参考。

一、架构

携程内部为期一年的机房级故障演练，代号“流浪地球”，验证了IDC级容错。我们将TiDB的三个副本分布在三个数据中心，保证单个中心故障时对外服务不受影响，数据一致性不受影响。我们还在tidb-server层实现了自动活跃度检测和自动故障转移，使RPO等于0，RTO小于30S。

我们先了解一下TiDB的整体架构(如图1-1)，然后结合携程的场景进行部署。

图1-1 TiDB的整体架构图图1-1 Tidb整体架构图

从TiDB的架构图可以看出，得益于PD和TiKV两个组件都是通过Raft实现数据容灾的，它们原生提供了多IDC部署能力。与Google Spanner的原子钟方案不同，TiDB采用的是PD进行单点全球统一时间服务的时间戳方案。TiDB中的每笔交易都需要从PD负责人处获得TSO。当TiDB和PD leader不在同一个数据中心时，其上运行的事务会受到网络延迟的影响。目前携程的跨IDC时延在0.5-2 ms之间，是可以接受的时延范围。在配置三个数据中心的时候，需要为对应的TiKV和PD标签配置规则，这样PD在调度区域的副本的时候，会根据标签属性在每个机房拥有满满的数据量。具体配置示例如图1-2所示:

图1-2 TiDB在携程的部署架构和配置图1-2携程旅行网Tidb部署架构和配置

这种部署架构的优势:

所有数据的副本分布在三个数据中心，具备IDC级别的高可用和容灾能力任何一个数据中心失效后，不会产生任何数据丢失 (RPO = 0)任何一个数据中心失效后，其他两个数据中心会自动发起 leader election，并在合理长的时间内（通常情况 20s 以内）自动恢复服务二、应用场景

TiDB已经应用到携程的很多业务场景，包括风控、社区、营销、搜索、酒店等。下面是两个典型的用例——CDP平台的国际业务和酒店结算业务。

2.1国际商务CDP平台

因为出行数据来源广泛，包括自身数据和外部数据；数据的形式也非常多样，包括结构化数据、半结构化数据和非结构化数据。数据处理的形式包括离线数据处理和在线数据处理。因此为国际业务搭建了CDP平台，对这些数据进行处理，形成业务系统、运营、市场需要的可理解的数据和标签。详情请看上一篇文章:携程国际业务动态实时标签处理平台实践。

TiDB主要负责存储业务的持久标签和内部SOA调用的查询服务。可以分为UID等维度的基本信息查询，订单订阅基本信息的OLTP查询，EDM\Marketing等人群的OLAP查询。整个CDP平台的架构如图2-1所示:

图2-1 CDP平台架构图图2-1 CDP平台架构图

具体数据处理:数据批处理引擎(如Spark)将所有历史数据转换后，批量写入数据持久化存储引擎(TiDB)，增量数据服务应用以消息的形式发送到Kafka或QMQ消息队列，经实时DAG处理后持久化到存储引擎(TiDB)。

持久标签访问主要有两种情况。一种是与现有CRM系统对接，根据业务特点，将符合条件的业务数据在线圈出。这种场景下，查询条件不固定，返回的结果集由筛选条件决定，对数据存储引擎的数据计算和处理能力要求很高，也就是我们在数据处理领域经常提到的OLAP场景。另一种场景是线上业务根据前端传入的业务标签相关的唯一标识符查询是否满足特定的业务需求，或者返回指定的特征值满足业务处理的需要，要求毫秒级响应，对应OLTP场景。

由于标签的多样性，有查询记录的字段多达60个，查询条件是60个字段的随机组合。不可能通过传统数据库层的索引来提高查询效率。经典的方案是将OLTP从OLAP中分离出来，但是数据会存储在多个副本中，多个数据源的数据一致性是一个很大的挑战。

对于这个场景，我们启动了TiDB的TiFlash，这是TiDB HTAP的关键组件，它是TiKV的扩展，提供了良好的隔离和强大的一致性。存储副本通过Raft学习者协议异步复制，但快照隔离的一致性隔离级别是通过Raft校对索引和读取时的MVCC获得的。TiFlash MPP模式如图2-2所示。

图2-2 TiDB MPP模式图2-2 TiDB MPP模式

该架构解决了HTAP场景隔离和列与内存同步的问题，开放后几个典型查询性能得到提升:

升级TiFlash MPP，20s-->:1s

set @ @ session . tidb _ allow _ MPP = 1；

set @ @ session . tidb _ enforce _ MPP = 0；

夹子t闪光柱，16.9秒->:2.8秒

set @ @ session . tidb _ allow _ MPP = 1；

set @ @ session . tidb _ enforce _ MPP = 0；

set session tidb _ isolation _ read _ engines = ' tidb，t flash '；

2.2酒店结算业务

携程的酒店结算业务有6T的全库，单个服务器存储6T全数据是很大的挑战。常规的方法是通过子数据库和子表的方式来减少实例数据的数量和压力，但是子数据库和子表的维度很难确定，从酒店维度或者供应商维度都无法避免跨片查询，给程序的开发带来了很大的困难，而且大部分查询都是聚合操作，所以我们尝试迁移到TiDB。

目前最大的表存储了28亿条数据，读写已经完全切换到TiDB。具体使用的部署方式类似于上一节提到的国际业务CDP平台，同时还开启了TiDB的TiFlash，以加快查询性能。具体表现如图2-3所示:

图2-3 酒店结算性能监控图2-3酒店结算绩效监控

三。实践中的一些问题3.1参数不合理导致的性能问题

分布式数据库不同于传统的单机数据库。通常情况下，MySQL在遇到性能问题时可以快速定位，这些问题是由网络抖动、SQL的索引丢失或请求激增等原因造成的。但是分布式的TiDB组件很多，每个组件之间的网络通信、某个组件的资源不足、复杂的SQL都可能是导致性能问题的原因。目前官方提供了问题图，方便根据不同场景尽快定位原因。这里给出一个具体案例，总结一个典型问题的故障排除思路。

国际商务集群使用官方默认配置集群在线测试时，发现写入时间高达秒，耗时波动较大。从应用端进行监控(纵坐标单位为毫秒)，如图3-1所示:

图3-1 IBA写入响应监控图3-1 IBA写响应监控

根据Pingcap的引导图，发现调度器命令持续时间约等于事务的预写时间(纵坐标单位为秒)，说明调度器-worker不足。如图3-2所示:

图3-2 scheduler command duration的时间图3-2调度程序命令持续时间的时间

所以我们做了以下调整:

scheduler-worker-pool-size：16 --> 40 （默认值为4，最小值为1，最大不能超过TiKV节点的CPU核数）scheduler-pending-write-threshold: "100MB" --> 1024MB （写入数据队列的最大值，超过该值之后对于新的写入 TiKV 会返回 Server Is Busy 错误）

调整后，从应用端进行监控(纵坐标单位为毫秒)，如图3-3所示。红色箭头是参数调整的时间点:

图3-3 IBA写入响应监控图3-3 IBA写响应监控

总结:默认配置不是最佳配置，需要根据服务器硬件和使用场景不断调试，最终固化为每个集群甚至所有集群的最佳实践配置；根据PingCAP提供的问题图谱，我们会逐步定位具体哪个组件和方面有瓶颈。同时，我们正在进一步开发一个一键定位工具，可以更快地定位性能瓶颈。

3.2发行引起的自加问题

对于具有自添加列的表，如果不强制分配自添加列，insert语句将报告主键冲突:

错误SQL: insert into `XXX _ table` (`id，` name `，` tag `，` comment `，` creator `)值(？, ?, ?, ?, ?)

错误内容:com . MySQL . JDBC . exceptions . JDBC 4 . MySQL integritytraintviolationexception:key的重复条目175190 & # 39；初级& # 39；。

在PingCAP的官方文档上，有如下介绍:

在TiDB中，自增列只保证自增和唯一性，不保证连续分配。目前TiDB采用的是批量分配ID的方式，所以如果数据同时插入多个TiDB，分配的自增ID会不连续。TiDB实现自增ID的原理是tidb-server的每个实例缓存一段ID值进行分配(目前会缓存30000个ID)，然后当这一段用完了再取下一段。假设集群中有tidb-server的两个实例A和B(cache[1，30000] A的自增id和cache [30001，60000] B的自增ID)，依次执行以下操作:客户端将ID设置为1的语句插入T值(1，1)到B中，执行成功。将Insert语句insert into t (c) (1)发送给客户端A，该语句中没有id的指定值，因此将由A分配，目前A缓存了[1，30000]的ID，因此将分配1作为自增ID的值，并将本地计数器增加1。此时数据库中已经存在id为1的数据，最终返回重复错误的错误。

通过这个介绍，我们知道自增主键的冲突是由于自增主键的显式插入引起的。

结论:分布式数据库预分配表的自增列，自增主键的显式插入会导致tidb-server上的计数器混乱，造成数据写入错误。在开发规范中，我们明确要求TiDB不允许显式插入自增主键。

3.3更改字段是否为空导致默认值异常。

如下表所示，我们的字段从int升级到bigint。

创建表` test `( ` id ` int)；

alter table ' test ' add ' col 1 ' int(11)null default & # 39；0'；

alter table ' test ' add ' col 2 ' int(11)null default & # 39；0'；

alter table ' test ' change ' col 1 `` col 1 ' bigint(20)null default & # 39；0'；

alter table ` test ` change ` col 2 ` ` col 2 ` bigint(20)null default & # 39；0'；

我们发现默认值0不合适，所以执行下面的语句将默认值调整为null。

alter table ' test ' change ' col 1 `` col 1 ' bigint(20)null；

alter table ' test ' change ' col 2 `` col 2 ' bigint(20)null & # 39；；

此时，我们插入一段数据:insert into test(id)values(1)；

惊人的发现，col1和col2的值还是0。这不符合我们的预期。经过一系列的重现测试和在社区论坛的搜索，我们发现这个问题是已知的。TiDB 4.0.9和更高版本中修复了https://github.com/pingcap/tidb/pull/20491.错误。

结论:成熟的社区论坛是TiDB日常运维、快速排障的利器。借助各种技术探索和社区论坛的交流分享，学习优质内容，获取前沿知识，快速定位和解决问题。

四、监控与告警

对于分布式数据库的运行和维护来说，监控和报警是一个非常核心的环节。冒烟现象或不规范现象需要及时发现并解决，避免问题恶化。准确的监测和及时的预警可以帮助运维人员准确定位问题，快速解决故障。TiDB使用开源时间序列数据库Prometheus作为监测和绩效指标的信息存储方案，使用Grafana作为显示的可视化组件。在此基础上，我们进一步整合。

4.1 TiDB监控市场

TiDB原生提供prometheus+Grafana性能市场，数据非常丰富，但数据分散在单独的集群中，无法提供全局视角。我们通过prometheus原生开发了监控端口9201的适配器，将性能数据转发到携程统一监控平台，构建了自己的监控市场。如图4-1所示:

图4-1 整合后的TiDB监控大盘图4-1集成TiDB监控市场

4.2三份监控

TiDB通过raft协议使用三份以上的副本来保证数据的一致性。当大多数拷贝丢失或关闭时，这部分数据处于不可用状态。是否存在缺失拷贝或异常拷贝状态需要特别注意。所以我们会巡视拷贝的数量和状态，保证长时间不缺拷贝。一旦发现副本丢失，可以增加副本的调度线程，一定要及时解决副本丢失问题。区域对等体的监控如图4-2所示:

图4-2 三副本监控图4-2三份监控

4.3磁盘容量监控

TiDB存储的数据量巨大，需要特别注意机器磁盘剩余可用空的情况，避免写满磁盘导致不必要的失败。对于磁盘监控，我们的阈值是物理磁盘的80%。一旦磁盘使用容量超过阈值，我们就需要安排添加机器来进行容量扩展。与MySQL在相同情况下复杂的拆分方法相比，TiDB的处理方法更加简单高效。磁盘监控报警如图4-3所示:

图4-3 TiDB磁盘监控图4-3 TiDB磁盘监控

4.4配置标准化检查

TiDB集群的配置文件参数和系统参数很多，不同实例的配置项也不一样，集群的容量经常会有放大缩小的情况。因此，我们要求更改前后的集群配置必须严格按照标准配置进行调整。只要达到配置标准，集群的规范运行就有很大程度的保证。标准化监控报警如图4-4所示:

图4-4 配置标准化的监控告警图4-4配置标准化监控警报

4.5性能警报

有时会出现流量突然增加或瞬间性能峰值。这时候就需要注意性能报警了。METRICS_SCHEMA是基于Prometheus中TiDB的监控指标的一组视图。有了基本的性能数据，我们只需要根据性能阈值及时报警、分析和处理即可。

五、周边工具

除了监控和报警，我们还开发了一系列的外围工具，为TiDB的运行和维护带来了极大的方便。这些外围工具主要包括:

5.1连接现有的数据外设工具。

现有的数据外设工具主要包括:数据库发布(DDL)、在线数据查询、在线数据修改、与现有大数据流程的通信。这些支持MySQL的工具还可以支持TiDB，解决了MySQL迁移TiDB的后顾之忧，让曾经使用MySQL的开发人员和测试人员能够方便流畅地切换到TiDB。

5.2 TiDB部署工具

TiDB集群实例有很多角色，集群部署不同于传统的单机。需要单独开发一套部署工具，包括集群在线流程、集群离线流程、扩展收缩实例、集群版本升级等。

5.3 TiDB闪回工具

有时候开发人员和测试人员误操作数据，可以使用数据闪回工具进行回滚。我们在TiDB binlog的帮助下开发了闪回工具，反转了binlog的内容，生成了用于TiDB数据恢复的数据恢复SQL。

六、未来规划

6.1一键故障分析

分布式数据库不同于独立的数据库。TiDB的组件很多，可以调整的参数有几百个。各个组件之间的网络通信、某个组件的资源不足、SQL的复杂性都可能导致性能问题。后续计划将实现TiDB诊断的自动化和智能化。目前通过修改TiDB服务器的源代码，已经完成了TiDB的全链路SQL收集和分析，这将是未来故障一键分析的基础。

6.2基于HDD的硬盘测试

TiDB的所有优化都是基于SSD的，高性能意味着高成本。我们还是会面临一个场景，数据量比较大，但是写和查询很少，响应要求不高。目前，我们已经完成了基于HDD硬盘的测试。所选机器配置了12个10T HDD硬盘，12个TiKV实例部署在一台机器上。这种架构已经在小范围内应用。

6.3双中心自适应同步方案同城同步

DR Auto-Sync正处于高速迭代的周期中，后续版本将有一系列高可用性和容灾能力的增强。从5.3.0开始，我们将支持双中心对等部署，从而获得快速恢复多个副本的能力。我们也在关注它。

【作者简介】陆军，携程数据库专家，主要负责分布式数据库的运维及研究；Keira，高级数据库工程师，主要负责MySQL和TiDB运维；携程大数据架构开发容军，专注于线下和实时的大数据产品和技术。