--- title: 支撑百亿级应用的 NewSQL——TiDB 在同程旅游的应用 author: ['瞿锴'] date: 2018-04-12 summary: 在同程内部，目前共有数套 TiDB 集群，部署服务器数量近百台，总数据量数十 TB。其中最大的一个集群 10 多个数据节点，近十 TB 数据，数据量过百亿，平均 QPS 在 5000，高峰 QPS 过万。 tags: ['互联网'] category: case url: /case/user-case-tongcheng/ weight: 18 logo: /images/blog-cn/customers/tongcheng-logo.png customer: 同程网 customerCategory: 电商 --- >作者：瞿锴，同程网资深 DBA。 ## 项目背景 初次接触 TiDB，是通过同程网首席架构师王晓波先生的分享，当时同程网正在使开发和数据库全面往开源方向转型，由于业务需要，很多在线业务数据量和访问量都非常的大，而 MySQL 无法满足大数据量下的复杂查询需求，为了使数据库分片对开发透明，同程自研了 DBrouter。但分片后的合并、实时汇总统计及全量数据的监控仍然是困扰我们的一个难点。一直没有特别好的办法解决。 ## 急速增长的业务 2016 年国庆前，同程的票务项目（微信九宫格中的火车票、机票等票务业务背后是同程在提供）由于流量激增，订单库压力越来越大，同时相关业务需求也在增加，开发不断的在订单库上新增各种查询，例如为了及时定位异常而增加的限定各类条件的分钟级订单量监控（每分钟执行根据不同的条件进行汇总的订单量）。这样的功能越来越多，同时订单库总大小数 T 左右。对此，公司内部决定将票务订单库进行分片来降低单库压力，应对即将到来的国庆高峰订单爆发。 ## 引入 TiDB 经过评估，发现公司自研的分片可以满足绝大多数的查询需求，但是部分复杂条件的查询将会影响整个分片集群的性能，少量的全片扫描 SQL 经常会占用 80% 以上的 IO 资源，导致其他的查询性能下降。这时，刚好我们的首席架构师提议，使用 TiDB 试试，经过中间件组和 DBA 组的配合测试，我们尝试将 TiDB 作为所有数据的集合库提供复杂查询，分片集群则提供简单查询，同时由于 TiDB 高度兼容 MySQL 的连接协议，我们基于平凯星辰提供的数据同步工具 Syncer 进行了二次开发，可以自定义库名和表名（后来同 TiDB 工程师交流，他们最新的 Wormhole & Syncer 也都已经支持了自定义选项），同时新增了同步状态监控，如 TPS、延迟等，如果出现异常，会通过微信告警。从 MySQL 将数据实时同步到 TiDB 来确保数据的一致。 确定方案后，我们连夜安排压测同事和开发同事协作，紧急测试，发现这套分片集群 + TiDB 的方案能够满足我们的功能和性能方面的需求，于是迅速调整了该项目的架构，我们将数千个 MySQL 分片汇总到一个 TiDB 集群，保障了 2016 年国庆的高峰平稳渡过。当时的流量达到了我们平时流量的 2 倍，然而并没有出现异常。 该实时同步查询系统架构如下所示： ![1-structure](media/user-case-tongcheng/1.png) 在该项目实施成功后，我们加深了对于 TiDB 的使用。并根据平凯星辰的建议和协助部署了各类监控。 ![2-grafana-tidb](media/user-case-tongcheng/2.png) ![3-grafana-tikv](media/user-case-tongcheng/3.png) 同时，为了更好的关注数据库的情况，第一时间发现异常，我们将 TiDB 的异常报警接入了公司的监控系统和自愈系统。当发生异常的时候，监控系统会第一时间发现，然后自愈系统会依据提前制定的愈合逻辑处理对应异常，在第一时间恢复应用的可用。 ## 更大规模的使用 业务上线以后，我们很快又迁移了机票业务实时同步业务到 TiDB。至本文截稿时，在同程内部，目前共有数套 TiDB 集群，部署服务器数量近百台，总数据量数十 TB。其中最大的一个集群 10 多个数据节点，近十 TB 数据，数据量过百亿，支撑了每天过亿的访问，并提供千万级别的数据监控服务，平均 QPS 在 5000，高峰 QPS 过万。 同时，由于 TiDB 的易用性（高度兼容 MySQL 协议和标准的 SQL 语法），我们目前已将 TiDB 作为一个很重要的数据库部署方案，在项目启动时就会考虑是否可以在初期就开始使用。在持续一年多的使用中，我们与平凯星辰工程师一直保持着沟通和交流，互相之间也经常会进行一些技术和使用方面的沟通。目前最新版的 TiDB 我们也积极与平凯星辰一起进行测试和问题反馈，他们也非常及时的给予我们反馈并很快的 fix 掉一些 BUG。 ## 展望 现在公司内部越来越多的开发在联系 DBA 咨询 TiDB 的信息，我们给他们的反馈就是：这是一个高度兼容 MySQL 协议和语法的数据库，非常简单易用，基本上看下相关文档就可以上手。你们在用的时候就可以当它就是一个 MySQL 来使用，只是它能存放的数据量远远超过 MySQL。而对于 DBA 来讲，这就是一个自带高可用和可动态扩容的数据库，对外是个 MySQL，对内是个分布式数据库。业务侧的开发人员基本没有学习成本，DBA 维护起来也和 MySQL 有很多相似点，系统生态非常好。 可以预见，随着项目继续以及新项目建设，TiDB 的实例数和机器数又会继续以较快的速度增长，目前线上用的版本还不是最新的版本，正在做升级到 1.05 的准备工作。我们预计 2018 年底，TiDB 的集群数很快就会有 20 套，机器数数百台，这给开发和运维都带来了一定的挑战。如果我们仍然按照目前的方式建设和运维 TiDB 集群，可能就要面临增加相关人力的处境。我们一直在寻找多 TiDB 集群的便捷管理方案，这时一篇文章引起了我们的注意——[《Cloud+TiDB 技术解读》](https://mp.weixin.qq.com/s/znT1jIbMhBcWldlBIkrkpQ)。我们迅速和 TiDB 工程师取得联系，了解到 TiDB 最新的 DBaaS 方案基于 K8S 来自动管理和调度多个 TiDB 实例，这和我们目前大量 docker 化业务和数据库的战略方向是一致的。通过 TiDB-Operator 使可以自动化部署和管理 TiDB 及周边工具，自动化部署这些应用以及使后端获得故障转移能力，这样可以大大降低运维成本，同时提供丰富的接口方便后续对其进行扩展。 ![4-tidb-dbaas](media/user-case-tongcheng/4.png) 我们计划 2018 年开始和平凯星辰合作尝试引入 TiDB DBaaS 方案。 另外，我们通过同平凯星辰工程师的深度交流，了解到了 TiDB 的子项目 [TiSpark](https://github.com/pingcap/tispark)，后续计划引入 TiSpark 来对数据进行实时分析、实时数仓等工作的尝试，让技术对业务产生更大的价值。