支撑百亿级应用的 NewSQL

https://zhuanlan.zhihu.com/newsql/

项目背景
初次接触 TiDB，是通过同程网首席架构师王晓波先生的分享，当时同程网正在使开发和数据库全面往开源方向转型，由于业务需要，很多在线业务数据量和访问量都非常的大，而 MySQL 无法满足大数据量下的复杂查询需求，为了使数据库分片对开发透明，同程自研了 DBrouter 。但分片后的合并、实时汇总统计及全量数据的监控仍然是困扰我们的一个难点。一直没有特别好的办法解决。

急速增长的业务
2016 年国庆前，同程的票务项目（微信九宫格中的火车票、机票等票务业务背后是同程在提供）由于流量激增，订单库压力越来越大，同时相关业务需求也在增加，开发不断的在订单库上新增各种查询，例如为了及时定位异常而增加的限定各类条件的分钟级订单量监控（每分钟执行根据不同的条件进行汇总的订单量）。这样的功能越来越多，同时订单库总大小数 T 左右。对此，公司内部决定将票务订单库进行分片来降低单库压力，应对即将到来的国庆高峰订单爆发。

引入 TiDB
经过评估，发现公司自研的分片可以满足绝大多数的查询需求，但是部分复杂条件的查询将会影响整个分片集群的性能，少量的全片扫描 SQL 经常会占用 80% 以上的 IO 资源，导致其他的查询性能下降。这时，刚好我们的首席架构师提议，使用 TiDB 试试，经过中间件组和 DBA 组的配合测试，我们尝试将 TiDB 作为所有数据的集合库提供复杂查询，分片集群则提供简单查询，同时由于 TiDB 高度兼容 MySQL 的连接协议，我们基于 PingCAP 提供的数据同步工具 Syncer 进行了二次开发，可以自定义库名和表名（后来同 TiDB 工程师交流，他们最新的 Wormhole & Syncer 也都已经支持了自定义选项），同时新增了同步状态监控，如 TPS、延迟等，如果出现异常，会通过微信告警。从 MySQL 将数据实时同步到 TiDB 来确保数据的一致。

确定方案后，我们连夜安排压测同事和开发同事协作，紧急测试，发现这套分片集群+TiDB 的方案能够满足我们的功能和性能方面的需求，于是迅速调整了该项目的架构，我们将数千个 MySQL 分片汇总到一个 TiDB 集群，保障了 2016 年国庆的高峰平稳渡过。当时的流量达到了我们平时流量的 2 倍，然而并没有出现异常。

该实时同步查询系统架构如下所示：

图 1：系统架构图
在该项目实施成功后，我们加深了对于 TiDB 的使用。并根据 PingCAP 的建议和协助部署了各类监控。

图 2：Grafana 监控面板 - TiDB

图 3：Grafana 监控面板 - TiKV
同时，为了更好的关注数据库的情况，第一时间发现异常，我们将 TiDB 的异常报警接入了公司的监控系统和自愈系统。当发生异常的时候，监控系统会第一时间发现，然后自愈系统会依据提前制定的愈合逻辑处理对应异常，在第一时间恢复应用的可用。

更大规模的使用
业务上线以后，我们很快又迁移了机票业务实时同步业务到 TiDB。至本文截稿时，在同程内部，目前共有数套 TiDB 集群，部署服务器数量近百台，总数据量数十 TB。其中最大的一个集群 10 多个数据节点，近十 TB 数据，数据量过百亿，支撑了每天过亿的访问，并提供千万级别的数据监控服务，平均 QPS 在 5000，高峰 QPS 过万。

同时，由于 TiDB 的易用性（高度兼容 MySQL 协议和标准的 SQL 语法），我们目前已将 TiDB 作为一个很重要的数据库部署方案，在项目启动时就会考虑是否可以在初期就开始使用。在持续一年多的使用中，我们与 PingCAP 工程师一直保持着沟通和交流，互相之间也经常会进行一些技术和使用方面的沟通。目前最新版的 TiDB 我们也积极与 PingCAP 一起进行测试和问题反馈，他们也非常及时的给予我们反馈并很快的 fix 掉一些 BUG。

展望
现在公司内部越来越多的开发在联系 DBA 咨询 TiDB 的信息，我们给他们的反馈就是：这是一个高度兼容 MySQL 协议和语法的数据库，非常简单易用，基本上看下相关文档就可以上手。你们在用的时候就可以当它就是一个 MySQL 来使用，只是它能存放的数据量远远超过 MySQL。而对于 DBA 来讲，这就是一个自带高可用和可动态扩容的数据库，对外是个 MySQL，对内是个分布式数据库。业务侧的开发人员基本没有学习成本，DBA 维护起来也和 MySQL 有很多相似点，系统生态非常好。

可以预见，随着项目继续以及新项目建设，TiDB 的实例数和机器数又会继续以较快的速度增长，目前线上用的版本还不是最新的版本，正在做升级到 1.05 的准备工作。我们预计 2018 年底，TiDB 的集群数很快就会有 20 套，机器数数百台，这给开发和运维都带来了一定的挑战。如果我们仍然按照目前的方式建设和运维 TiDB 集群，可能就要面临增加相关人力的处境。我们一直在寻找多 TiDB 集群的便捷管理方案，这时一篇文章引起了我们的注意——《Cloud+TiDB 技术解读》。我们迅速和 TiDB 工程师取得联系，了解到 TiDB 最新的 DBaaS 方案基于 K8S 来自动管理和调度多个 TiDB 实例，这和我们目前大量 docker 化业务和数据库的战略方向是一致的。通过 TiDB-Operator 使可以自动化部署和管理 TiDB 及周边工具，自动化部署这些应用以及使后端获得故障转移能力，这样可以大大降低运维成本，同时提供丰富的接口方便后续对其进行扩展。

图 4：TiDB DBaaS 方案

我们计划 2018 年开始和 PingCAP 合作尝试引入 TiDB DBaaS 方案。

另外，我们通过同 PingCAP 工程师的深度交流，了解到了 TiDB 的子项目 TiSpark（https://github.com/pingcap/tispark），后续计划引入 TiSpark 来对数据进行实时分析、实时数仓等工作的尝试，让技术对业务产生更大的价值。