30天完成数据库替换 顶住10倍流量压力，易车是如何做到的？

Posted 2021-12-10 TiDB_PingCAP

导语：一年一度的双十一又双叒叕来了，给技术人最好的礼物就是大促技术指南！ 而经过这些年的发展，大促早已不仅仅局限于电商行业，现在各行各业其实都会采用类似方式做运营活动，汽车界有 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 架构、组织流程、人才技能都获得了大幅提升。而在大促中的经验和思考，也会加速企业日常的业务创新节奏，提升技术驱动的创新效率，打造增长新引擎。