共计 2864 个字符，预计需要花费 8 分钟才能阅读完成。
导语 ：一年一度的双十一又双叒叕来了，给技术人最好的礼物就是 大促技术指南！而通过这些年的倒退，大促早已不仅仅局限于电商行业，当初各行各业其实都会采纳相似形式做经营流动，汽车界有 818，电商有 618、11.11 等等，各种各样的大促场景，对包含数据库在内的根底软件提出了很多新挑战，同时也积攒了诸多最佳实际。
在双十一到来前，PingCAP 与汽车之家、易车网、京东、中通等用户开展一系列深入探讨，心愿为大家揭秘逐年飙升的销量背地暗藏着什么样的技术难题？用什么技术架构能力安稳地扛住流量洪峰？
汽车界的“大促”狂欢节
成立于 2000 年的易车，是国内最早一批汽车互联网平台企业之一，为汽车用户提供业余、丰盛的互联网资讯服务，晋升用户在选车、购车、用车和换车过程中的全程体验。
在往年“818”期间，易车与浙江卫视联合推出了一台综合汽车工艺秀、明星歌舞上演和明星综艺秀的车界“春晚”——“易车超级 818 汽车狂欢夜”。在为汽车用户带来视听盛宴、购车福利的同时，晚会还推出超 150 台半价车的超值福利，观众可边看晚会边抢 5 折售卖的好车，同时还有购车红包、抵扣券、车款直降等多重优惠，失去实实在在的购车福利。截至晚会完结，全平台观看直播人次达 2.24 亿，取得线上订单 4.39 万，累计成交额（GMV）64.2 亿元。
易车的大促首秀
在易车的 818 狂欢节中，数据库的利用场景有很多，其中实时数据看板是次要的利用业务之一。看板能够实时展现易车 818 购车节的专题、流动、流量、线索、互动等数据体现，是大数据平台的整体数据输入。
因为易车的这场汽车狂欢夜是台网互动的直播流动，摇一摇（红包、半价车、易车币）和主会场分会场直播节目的投票都是用户参与度最高、数据流量最大的环节。在整个流动过程中，不仅要求数据库可能存储海量数据，同时还要求可能应答高并发、低提早等场景需要。这里的数据库不仅会作为数据存储的介质，还会作为实时计算的数据源头，配合流量数据，实现秒级数据实时播报。
数据库和 Flink 是整个零碎中十分重要的两个组件，Flink 的数据起源包含数据库和业务流量数据，所以数据库不仅要满足数据秒级实时推送，还要反对 Flink 高并发的读写申请。
易车数据库负责人田震坦言，易车往年是第一次做大促，没有太多教训，量也不好预估，很多需要都是在最初才提出。为了保险起见，DBA 团队在设计大促计划时做了降级计划，但谁都不心愿真的施行降级，这对用户的体验太不敌对。所以整个 DBA 团队将次要精力放在压测上，并依照平时的两个数量级（100 倍）来布局数据库压测计划。
一开始，易车思考的首选数据库仍然是 MySQL。但在压测过程中，为了保障计算结果的实时性，实时工作会频繁对数据库进行大批量数据写入，MySQL 主从提早高，极其状况下引起的 MySQL 主从切换，切换工夫过长，导致数据库呈现短暂不可用状态。同时，实时工作会继续写入大量数据，引起磁盘爆满。在争分夺秒的直播过程中这必定是无奈容忍的。
在形势急切下，田震想到了 TiDB。
“在游泳中学游泳”TiDB 临危受命
实际上，田震很早就接触过 TiDB，那时候他一度认为 TiDB 是一款海内产品，理解 TiDB 次要也是从海内社区开始的。但出于审慎的起因，田震心愿将产品钻研透彻再正式上线。本次大促给了单方单干一个完满的契机，他形容这一过程就像是“在游泳中学游泳”。
TiDB 社区的技术支持给了易车 DBA 们十分重要的帮忙，从七月正式立项，仅用了不到一个月工夫就实现了选型、方案设计、压测、上线部署，并在“818”中有惊无险地将大促流量安稳承载过去。
818 汽车狂欢数据看板业务架构图
在整个 818 流动中，TiDB 被用作 818 汽车狂欢节数据看板的外围数据库。易车筹备了两套 TiDB 集群，和实时计算的主备计划一一对应。业务研发通过双写的形式把数据同时写入两个集群，一部分业务的查问连贯集群 1，另一部分业务的查问连贯集群 2，当其中一个集群呈现问题，利用端就会切换到另外一个集群。两个 TiDB 集群都是部署了 3 个 TiDB Server、3 个 PD Server、6 个 TiKV 节点、2 个 TiFlash 节点。此外，还筹备了 4 台机器做扩容免得数据量暴涨集群支撑不了。
最终，易车 818 汽车狂欢节期间数据量达到了平时的 10 倍以上，在直播最初蔡徐坤出场时，数据库流量更是间接翻了四倍，差点启用当时筹备好兜底用的一键扩容计划。在整个过程中，818 汽车狂欢数据看板业务 SQL 999 始终管制在 8ms 以内，SQL 99 在 3ms 左右，QPS 达到 62k。
红包摇一摇业务架构图
同时，TiDB 也作为容灾计划被利用在红包摇一摇业务中，防止因为业务流量暴涨引起 MySQL 不可用的状况。一旦产生不可用，业务方能够间接将数据库切换到 TiDB。TiDB 在整个业务中须要作为数据源、实时计算维表和实时计算结果存储引擎三个角色。TiDB 通过 TiCDC 将数据实时推送到 Kafka 中，为了保障 TiCDC 稳固高效，易车为 TiDB 中的每个库创立了一个 TiCDC 工作，将数据实时推送到指定 Kafka 中，而后 Flink 负责将同一个 TOPIC 中的属于不同库表的数据进行解析，分流到库表对应的 TOPIC 中，提供给实时计算业务应用。实时计算工作生产 Kafka 中的 TiDB 数据进行业务逻辑计算，同时还须要从 TiDB 中查问对应的维度数据，最终将计算结果再输入到 TiDB 中。
高速增长的挑战：技术栈对立
大促的极限场景总能发现一些平时留神不到的问题，在易车的高速倒退中，很多业务为了疾速迭代、迅速上线，引入了十分多的技术栈，如 Lambda、Kappa 等大数据架构，Kylin、Druid、Clickhouse 等实时数仓等等。但易车 DBA 团队却只有 6 集体，治理如此多的技术栈无疑是一个很大的挑战。
对立技术栈成为易车 DBA 团队的最佳抉择，借着这次大促的机会，易车心愿用 TiDB 上线取代 Kylin、Druid、Clickhouse，简化技术栈，DBA 团队也能将注意力放回专职工作上。
TiDB 的 HTAP 架构是一个混合了交易型事务和剖析解决的交融架构，因为都是在同一个架构、同一套数据中，解决了易车实时数仓数据流提早的问题。数据不必再从 OLTP 数据库复制进去，通过漫长的 ETL 荡涤等过程进入剖析工具。
而 TiDB 对 MySQL 的完满兼容，对 DBA 和开发者意味着不须要做什么扭转，只有会 SQL 就能应用。在以往利用 Hadoop 或 Spark 时，因为学习老本比拟高，对应用造成了肯定壁垒。
经此一役，易车的业务方对 TiDB 平添了许多期待与信赖。将来，易车的广告、媒体平台、网站、投放数据、广告成果都心愿可能实时看到，田震心愿借用 TiDB 笼罩易车整个混合技术栈的场景，与其余数据流进行买通，这些都须要 TiDB HTAP 对实时数仓进行反对。
大促对于企业而言，除了反对业务翻新，也是一次对本身技术架构的大练兵和全链路演练。通过大促的极致考验，企业的 IT 架构、组织流程、人才技能都取得了大幅晋升。而在大促中的教训和思考，也会减速企业日常的业务翻新节奏，晋升技术驱动的翻新效率，打造增长新引擎。
