特稿 >

行业洞察 >

支撑百亿级应用的 NewSQL——TiDB 在同程旅游的应用

支撑百亿级应用的 NewSQL——TiDB 在同程旅游的应用

Xtecher原创 丨 行业洞察

29558
4249

2018-04-13

PingCAP

Xtecher特稿作者

关注

           

项目背景

初次接触 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(github.com/pingcap/tisp),后续计划引入 TiSpark 来对数据进行实时分析、实时数仓等工作的尝试,让技术对业务产生更大的价值。


作者:瞿锴,同程网资深 DBA 。



打开微信“扫一扫”,打开网页后点击屏幕右上角分享按钮

账号登录

重置密码

还没有账号?立即注册>

账号注册

已有账号?立即登录>注册企业会员

重置密码

返回

绑定手机