专栏名称: 狗厂
目录
相关文章推荐
51好读  ›  专栏  ›  狗厂

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

狗厂  · 掘金  ·  · 2018-04-13 05:23

正文

项目背景

初次接触 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 过万。







请到「今天看啥」查看全文