共计 4018 个字符，预计需要花费 11 分钟才能阅读完成。
一年一度的双十一又双叒叕来了，给技术人最好的礼物就是大促技术指南！而通过这些年的倒退，大促早已不仅仅局限于电商行业，当初各行各业其实都会采纳相似形式做经营流动，汽车界有 818，电商有 618、11.11 等等，各种各样的大促场景，对包含数据库在内的根底软件提出了很多新挑战，同时也积攒了诸多最佳实际。
在双十一到来前，PingCAP 与汽车之家、易车网、京东、中通等用户开展一系列深入探讨，心愿为大家揭秘逐年飙升的销量背地暗藏着什么样的技术难题？用什么技术架构能力安稳地扛住流量洪峰？
点击此处观看残缺采访参加互动，有机会取得 TiDB 定制周边！
大促中，大家买买买后最期盼的事件就是收到快递。成立于 2002 年的中通快递，是一家以快递为主体，以国内、快运、云仓、商业、冷链、金融、智能、星联、传媒为辅的综合物流服务品牌。2020 年，中通实现业务量 170 亿件，市场占有份额达到 20.4%。
整个快递的生命周期、转运周期能够用五个字来概括——收、发、到、派、签：
而撑持整个快递生命周期的平台就是中通大数据平台 。中通从离线到实时的数据兼容再到数仓，有着一套比较完善的大数据平台体系。ETL 建模也会依靠该大数据平台，最终通过大数据平台对外提供数据利用的反对以及基于离线 OLAP 剖析的反对，整个数据建模的频率能够反对到半小时级别。在这个欠缺的大数据平台根底上，中通开始更多地思考 如何加强实时多维分析能力。
中通与 TiDB 的结缘是在 2017 年调研分库分表场景时开始的。过后中通分库分表白到 16000 张表，业务上曾经无奈再持续扩大上来。2018 年底，中通开始测试 TiDB 2.0，次要关注的是大数据量的存储，以及剖析性能。2019 年年初，中通上线了生产利用的反对。目前生产上稳固的版本是 TiDB 3.0.14。2020 年底，中通开始测试 TiFlash，指标冀望有两点：一是进步时效，二是升高硬件应用状况。
1.0 时代——满足需要
1.0 是 满足需要 的时代，业务需要次要蕴含以下几点：
- 业务倒退十分快，数据量十分大，每笔订单更新有 5-6 次，操作有峰值；
- 做过调研的技术计划，很难撑持多维分析的需要；
- 业务方对数据分析的周期要求比拟长；
- 对剖析时效要求也很高；
- 单机性能瓶颈，包含单点故障、危险高，这些也是在业务上不能忍耐的；
- 除此之外，QPS 也很高，利用要求毫秒级响应。
技术需要方面，中通须要买通多个业务场景 + 多个业务指标；须要 强统一的分布式事务 ，在原有业务模式下切换的代价很小；还须要 对整个剖析计算工程化 ，下线原来的存储过程；可能 反对高并发的读写、更新 ；可能反对 在线的保护 ，保障单点的故障对业务是没有影响；同时，还要 与现有的大数据技术生态紧密结合在一起 ，做到分钟级的统计分析；最初是中通始终在摸索的，即要建设 100 + 列以上的大宽表， 基于这张宽表，要做到多维度的查问剖析 。
目前 TiDB 在中通利用的一些落地场景
时效零碎利用场景
其中，时效零碎是中通原有的一套零碎，当初曾经进行了重构。这套零碎原来的存储和计算次要是依赖 Oracle 设计的，计算依赖存储过程。这套架构也比较简单，一边是音讯的接入，一边是负载。
随着业务体量的增长，这一套架构的性能曾经逐步呈现瓶颈。在对这套零碎进行架构降级时，中通把整个存储迁徙到 TiDB 上，整个计算迁徙到 TiSpark。音讯接入依赖于 Spark Link，通过音讯队列最终到 TiDB。TiSpark 会提供分钟级的一些计算，轻度汇总会到 Hive，中度汇总会到 MySQL。基于 Hive，通过 Presto 对外提供利用的服务。相较原来关系型数据库的分表，无论是 OLTP 还是 OLAP 都极大地升高了开发的工作量，并且和现有的大数据生态技术栈相交融。
1.0 时代中通的数据库系统架构
迁徙带来的收益有很多：第一是容量的增长，原来的数据中心有三倍的充裕，已有零碎数据存储周期减少到三倍以上；第二，在可扩展性方面，反对在线横向扩大，运维能够随时高低计算和存储节点，利用的感知很小；第三，满足了高性能的 OLTP 业务需要，查问性能虽略有升高的，然而合乎业务需要；第四，数据库单点压力没有了，OLTP 和 OLAP 实现“拆散”，互不烦扰；第五，反对了更多维度的剖析需要；第六，整体架构看起来比原来更清晰，可维护性加强，零碎的可扩展性也加强了许多。
大宽表利用场景
另一个场景是中通始终在做的宽表的建设与摸索。其实之前中通测过很多零碎，包含 Hbase、Kudu。Kudu 的写入性能还是很不错的，然而其社区活跃度在国内个别。同时，中通应用 impala 作为 OLAP 查问引擎，但支流应用的是 Presto，兼容性有待思考，也很难满足所有业务场景需要。此外，中通的业务个性要求零碎可能疾速地计算剖析几十亿的数据，并能同步到离线的集群里与 T+1 数据做交融，还要能提供给数据产品和数据服务直连拉取明细数据。最初是海量数据的解决，中通有很多音讯源的接入，须要针对每一票进行全链路路由和时效的预测，定位到每一票的转运环节，数据量很大，对时效的要求也很高。
中通的大宽表建设
目前，宽表曾经建设有 150 多个字段。数据来源于 10 多个 Topic。次要的我的项目接入是通过 Flink 和 Spark，买通了各个业务产生的数据，汇总到 TiDB 造成业务宽表。额定一部分，依赖于 TiSpark，从业务宽表输入剖析后果，同步 3 亿条数据到 Hive。此外，还提供了十分钟级别的实时数据建设和离线 T+1 的整合。
中通目前的集群规模在应用过程中，中通也遇到了一些问题，总结起来就是 质变引起量变。第一，热点问题。索引热点在目前状况下体现较为突出，因为中通的业务量规模非常大，操作存在顶峰，在大时候该热点问题体现特地显著。第二，内存碎片化问题。在之前的低版本里，在稳固运行了一段时间后，因为有业务个性和大量的更新和删除，导致内存碎片化比较严重，这个在反馈给了 TiDB 后，曾经修复了这个问题。第三，着重介绍一个参数——TiFlash 读取 index 的参数。通过测试，当读取的数据量 / 总数据量大于 1/10 的时候，倡议该参数敞开。为什么这么说？因为 Test 数可能会变少，然而单位 Test 过渡的工夫会变长。
运维监控
应用 TiDB 后会发现它的监控指标特地丰盛，应用了风行的 Prometheus + Grafana，多而全。之前，中通因为在反对线上业务的同时，还会有开发人员来查数据，遇到了 SQL 把 TiKV Server 拉挂的状况。针对这个问题以及监控的问题，中通进行了一些开发定制。第一，兼容线上非凡帐号的慢 SQL，会主动杀掉，并告诉到相应的利用负责人。第二，中通开发了反对 Spark SQL 去查问 TiDB 的工具，并发和安全性在开发的过程中失去一些保障。此外，中通还会把一些额定的外围指标，接入到自研的监控体系。外围的告警会电话告诉到相干的值班人员。
去年双十一期间，中通订单量冲破 8.2 亿，整个业务规模冲破 7.6 亿，双十一当天的 QPS 峰值达到 35 万 +。整个双十一期间，数据的更新体量达到了数千亿级别，整个集群上运行的 TiSpark 工作是 100 多个，反对的在线利用 7 个。整个剖析的时效在 10 分钟以下达到了 98%，整个剖析的数据周期达到 7-15 天。
2.0 时代——HTAP 晋升
2.0 时代的次要特点是 HTAP 的晋升 。中通利用 HTAP 次要来自于业务方需要的降级：
基于业务方的需要，中通在 2.0 时代进行了一次架构再降级。首先，引入了 TiFlash 和 TiCDC 。这带来的收益其实是加强了时效，局部剖析进入了分钟级级别，升高了 Spark 集群资源的应用状况。
2.0 时代中通的数据系统架构
下图是 TiSpark 和 TiFlash 的比照，中通线上有两套集群，一个基于 3.0，一个基于 5.0。简略地比照一下 3.0 和 5.0 的状况：3.0 次要的剖析是基于 TiSpark，5.0 是基于 TiFlash。目前 3.0 集群有 137 个物理节点，5.0 有 97 个节点。整个运行的周期中，3.0 是 5 – 15 分钟，基于 5.0 的 TiFlash 曾经做到 1-2 分钟，整个 TiKV 的负载升高是比拟显著的。另外，在 3.0 上 Spark 的资源大略有 60 台，而在 5.0 上，线上的加上在测试的，大略有 10 台就足够了。
在整个测试周期中，生产的集群是 3.0，4.0 的测试周期其实是十分短的。在测试时，业务的场景有一些维表 Join 的状况，过后 4.0 对 MPP 没有反对，对一些函数的反对可能也不是那么欠缺，测试后果不是很现实。对 HTAP 的测试次要是在 5.0 阶段，5.0 曾经反对 MPP，对函数的反对也越来越丰盛。目前中通生产上利用的版本是 TiDB 5.1。
上图右侧是整个 5.0 集群在 618 期间的负载状况。在刚刚完结的 618 中，5.0 上线的一些工作曾经在反对 618 挪动端的大促看板。中通有 6 个外围的指标是基于 TiFlash 计算的。集群响应整体安稳，报表达到了分钟级以内的时效。整体的数据体量在 40 亿 – 50 亿 +，报表剖析数据达到 10 亿 +。
3.0 时代——展望未来
- 第一是监控。提到监控，因为中通的集群比拟大，所以面临的问题和遇到的问题可能会多一点。大集群的实例多，指标加载慢，排查问题的效率得不到保障。监控尽管很全，然而出了问题的时候无奈疾速定位到问题；
- 第二是解决 执行打算 偶发不准的问题。这种偶发不准有时候会影响到一些线上的负载相互影响，拉高集群的指标，导致业务相互影响。
- 第三是实现 主动清理。目前中通数据的清理是通过本人写成 SQL 清理的，然而过期数据清理比拟麻烦。心愿之后能够反对旧数据主动 TTL。
- 第四，随着 5.0 列式存储 的引入，中通打算把 TiSpark 的工作逐步全副切到 TiFlash 下面，冀望达成进步时效和升高硬件老本的指标。
大促对于企业而言，除了反对业务翻新，也是一次对本身技术架构的大练兵和全链路演练。通过大促的极致考验，企业的 IT 架构、组织流程、人才技能都取得了大幅晋升。而在大促中的教训和思考，也会减速企业日常的业务翻新节奏，晋升技术驱动的翻新效率，打造增长新引擎。
