共计 2725 个字符，预计需要花费 7 分钟才能阅读完成。
随着新冠病毒疫情的缓解和管制，寰球旅游业逐步开始从新复苏。尤其在一些度假胜地，游客数量曾经复原到疫情前的程度。
携程作为寰球当先的一站式旅行平台，旗下领有携程旅行网、去哪儿网、Skyscanner 等品牌。携程旅行网向超过 9000 万会员提供酒店预订、酒店点评及特价酒店查问、机票预订、飞机票查问、时刻表、票价查问、航班查问等服务。
随着业务量迅速增长，携程须要更麻利的技术架构来满足一直激增的并发与数据量，一个稳固、牢靠，能够随业务增长一直扩大的数据库对于携程来说显得尤其重要。作为海内外在线游览行业的翘楚，携程也曾面临着数据库带来的技术挑战。
原 MySQL 架构痛点与挑战
携程创建于 1999 年，最后抉择应用 SQL Server 数据库，在整体数据库技术栈中占比达到 99%。2012 年初，携程开始逐渐关注开源技术，尤其是 MySQL，不过该阶段 MySQL 应用占比依然很低，只有 10% 左右。从 2014 至 2019 年，携程开始加深 MySQL 的利用，并因为业务状态产生了变动，携程开始从 SQL Server 转型到 MySQL，对 MySQL 进行了深入研究，包含内核补丁、全自动故障诊断等。
携程的利用部署在两个或多个 IDC 中，数据库也对等部署在每个 IDC 中。MySQL 部署形式采纳 HA 节点，即主备节点，在同一机房部署，另一节点在不同 IDC 部署，这种形式保障了 HA 切换速度和数据的容灾。比方遇到单机房故障或者整个机房宕机，能够迅速把第二节点启动起来。携程在主备切换和第二切换时做了很多自动化工作，但这种架构也有显著毛病，因为利用的无状态化，数据库的切换会造成业务的短暂中断，因为数据库只有一个主节点。
在扩大形式方面，携程没有采纳中间件的形式，而是采纳客户端实现分片规定。客户端在上线时会确定分片规定，比方 64。再依据 ID 应用取模运算定位到某个分片，这样能够更不便地进行扩大。当业务减少时实例数量从 1 变成 N，当负载下降时也能够缩回来。
然而这种扩大形式对 DBA 运维来说还有一些挑战，随着 DBA 越来越多，聚合会比拟艰难，业务代码也变得复杂。
分布式数据库选型
2018 年，随着携程业务的疾速倒退，底层架构须要反对弹性扩大，特地是在季节性高峰期（例如春运火车票抢票等）。分布式数据库因为具备 DB 级弹性、疾速扩大和混合负载（HTAP）等劣势，更适宜业务的倒退，携程开始思考引入分布式数据库，并进行调研选型。携程次要从以下几个维度考量分布式数据库：
- 性能：均衡性能和老本，抉择通用机型，不应用高端存储或机器，并要求响应稳固；
- 运维与社区：学习老本适中，运维复杂度低，产品需开源且社区沉闷；
- 老本：一方面，业务研发须要学习应用 SQL，特地是 MySQL 协定；另一方面，运维团队心愿产品不要过于简单，易于保护；
- 扩展性：分布式数据库须要具备疾速的扩大能力，扩缩容对业务影响小。
携程 TiDB 部署模式
2018 年，携程开始正式引入 TiDB。思考到 TiDB 的架构和携程的 IDC 环境，携程将 TiDB 别离部署在三个 IDC 机房（IDC1、IDC2、IDC3）中，遵循同时部署的规范。TiKV、TiDB 和 PD 均匀分布在三个 IDC 机房中，业务流量能够本地感知到每个机房的 TiDB Server，在单机房故障时能够主动重启到其它机房。因为客户端对 TiDB 进行了探活与感知，单个 TiDB 服务器故障时客户端能够从新定向。
TiDB 在酒店和度假结算场景的利用
携程作为一个大型的在线游览平台，其酒店和度假结算场景下须要解决大量的交易数据。携程原 MySQL 架构次要采纳分片（sharding）的扩大形式，对于酒店和度假结算这类业务来说，分片会变得十分艰难。最后的计划是把 SQL Server 上的数据一成不变导入到 MySQL 中，但测试后发现性能不佳，扩展性也受限。如果采纳分片形式部署，不管从酒店的维度、供应商的维度或者是用户维度，都很难抉择适合的分片键（sharding key），这种形式也对业务代码侵入性比拟大。
TiDB 的分布式架构能够将数据扩散存储在多个节点上，实现数据的程度扩大，进步零碎的承载能力。因而，携程最终抉择了 TiDB，将酒店和度假结算业务从 SQL server 迁徙到 TiDB 上，总数据量规模达到 8TB，并受到了开发人员的统一好评，满足了性能和扩展性的诸多要求，同时升高了运维老本，可能更好地反对携程业务的倒退。
TiDB 在海量数据场景中的利用
携程的海量数据场景波及到大量数据存储。原架构中因为单机存储限度，扩大必须通过 sharding 形式实现。但该解决方案对于一些业务而言过于简单，例如在 IBU 海内业务部数据，单表数据曾经超过 300 亿。利用 TiDB 能够大幅提高查问性能，实现大量数据的高效存储。TiDB 的行列混存架构（TiFlash 和 MPP 技术），使得携程局部查问性能有了 20 倍晋升；在信息安全源数据标记数据时，单表数据也超过了 60 亿行，读写的响应工夫都达到毫秒级，单天聚合查问秒级返回。
除了应用 TiDB，携程还在应用其存储层 TiKV。引入 TiKV 是因为携程当初的业务有一些简略的 KV 存储需要，携程在应用的产品有 Redis 和 Hbase，然而 Hbase 的性能相比于 Redis 比拟差，而 Redis 则存在数据不统一的危险，比方网络抖动、中断等。携程有一些业务有强统一 KV 需要，例如近期引入的酒店勾销政策我的项目，Redis 尽管能满足业务需要，但没有强统一性能。综合考量之后，携程抉择了 TiKV 解决上述挑战。TiKV 的部署与 TiDB 相似，也是在三个机房散布部署，利用能够感知到每个机房的 PD，并且 PD 也在三个机房别离部署。该架构能够确保如果呈现机房级故障，或是单 PD 故障，运维团队都能够做到平滑切换。
TiDB 在携程的全球化使用
随着携程近年来开始走向海内，海内业务出现迅猛增长趋势。携程也将国内成熟的数据库技术间接用于海内。目前，TiDB 在携程的国内和海内业务是离开部署的，海内利用复用了国内的 schema 和代码，监控告警形式也与国内保持一致，部署形式也是雷同的。
携程引入 TiDB 并实现了一系列外部生态整合，包含公布零碎（如表构造公布、索引公布）、数据批改和查问等。因为 TiDB 和 MySQL 采纳了雷同的协定，整合过程绝对简略平滑：
- TiDB 原生反对 Prometheus + Grafana，提供了丰盛的诊断数据，能够依据 TiDB 故障诊断手册疾速定位问题。
- 因为 Grafana 的数据在每个集群上独自散布，携程通过 prometheus 源生 remote write 转发性能数据到携程对立监控平台，以便在监控平台上进行性能告警和大盘监控。
目前 TiDB 稳固利用于携程的国内、海内各业务场景中，借助 TiDB HTAP 能力，携程大幅提高了查问性能，实现海量数据的高效存储。