序言
2016年双11早已成功落大幕，在百亿B2C网络流量的压制下，集团资料库整体整体表现轻松。轻松整体表现的另一面，暗藏着资料库项目组对技术的执著崇尚。这是两个甚么样的项目组，他们到底做了甚么，是甚么支持着双11这一全民欢庆的位数无数次冲破？本栏以两个见证者的视角来给大家掀开双11另一面，腾讯资料库项目组的谜样盖头。
买卖查阅强化
在2014年双11时，买卖的AliSQL秒级查阅量早已到了两个天量。虽然当日买卖控制系统一切相对平稳，但买卖的资料库相关人士有感于这位数另一面暗藏的风险。
为了保证买卖控制系统下一年的稳定，资料库项目组在2015年花了大批的天数，深入细致了解销售业务特征，分析每一次查阅SQL，最终工业生产在强化器中转化成PK_Access的强化计划。
当2015年双11来临时性，买卖的秒级查阅量再度达到两个最大值，这迪阿尔库掌控当中。PK_Access强化计划让买卖库的查阅潜能提高了27%，RT下降48%。
光鲜亮丽统计数据的另一面，不只是两个资料库优化计划的结论，更多的是买卖销售业务控制系统一大堆Marival了大批的天数剖析USB并确认TNUMBERGM共振频率的结论。这里有这么两个统计数据，2015年买卖控制系统的对内开闭应急总共有125个。回想不到买卖老师的一句话，“如果明年还需要这样，我的确疯了”。销售业务老师的话让他们深思，控制系统潜能的提高 无法建立在销售业务缺位的基础上。
再度返回pk_access的计划，买卖的查阅在目前的条件下，早已努力做到了最优化，server层的sql_parse是困局点，但是在sql的方式下，没有办法提高更多了。那么能无法将sql_parse也省去呢？这个时候他们想不到了被人忘却的MySQL应用程序，InnoDB memcached plugin。
由于应用程序本身的使用场景偏少，且自身的功能缺位，一直并未广泛使用。换句话说，这是一块未被开发的沃土。从原理上证明这是两个有效计划之后，资料库项目组马上集中精力，说干就干。最终修复bug 15个，新功能开发6个，才满足了买卖的基本查询。测试中发现，在完整买卖场景下，memcached plugin和SQL的对比结论来看，memcached plugin qps可以达到42万，SQL才能达到12万，qps提高了接近4倍。在单SQL场景下，买卖单条查阅USB的rt下降约30%。在相同网络流量的引流测试中，通过memcached plugin查阅，应用load 4.8，cpu 45%；通过sql查阅，应用load 13，cpu 72%。通过各个维度的比较，memcached plugin带来的收益远远超出每个人的预期。
就在刚刚落幕的2016年双11，买卖控制系统秒级查阅量冲破千万，再度刷新秒级查阅量，也是资料库项目组第两个秒级破千万的控制系统。这一次的增长可谓是“爆炸式”的。
从今年买卖资料库运行情况来看：
1、资料库不扩容，整体压力翻翻，并且仍有一定的余量。
2、销售业务降级应急大幅减少，努力做到对销售业务无损。
3、买卖应用服务器扩容大幅减少。销售业务访问数据库从SQLUSB切换到MemcachedUSB之后，还带来的两个显著强化就是应用服务器的CPU开销大幅降低，这也导致最终需要扩容的应用服务器数量大幅减少。
库存中心扣减潜能提高
热点库存，相信无论是有多年双11备战经验的技术老师，还是资深的剁手党，对这个名词都不会感到陌生。因为每年双11，总有那么些爆款商品特别热销，大家的抢购热情异常高涨，这几年双11，小米/华为手机、优衣库衣服等，都曾经加入过这个热点商品的家族当中。其实，热点商品是一直存在的，但是热点商品带来的问题，他们是2012年底2013年初才真正意识到的。
从那时起，2013、2014、2015、2016，每一年他们在AliSQL内核层面针对此问题都有强化，强化单Key（单商品）的秒级扣减潜能。但是，只有今年，他们将此问题努力做到了技术上的极致，未来可以预见的几年内，库存热点问题，将从双11备战中消失。
2013年，2014年和2015年，库存中心随着AliSQL版本升级和硬件升级，轻轻松松渡过了双11的技术大考，AliSQL的单行扣减潜能，从原生MySQL的每秒500笔，提高到了2015年的每秒5000笔。
轻松并不等于放松，阿里人绝对不会满足现状，如何才能继续提高单行扣减性能？答案是批处理！他们认真思考了2013年做的强化，它们都有两个共同点，就是在串行的基础上进行的，而且早已努力做到极致。于是他们想不到了是否可以通过批处理来提高吞吐。2016年经过半年的闭关开发测试，“史诗级怪兽”补丁hotspot横空出世；
通过添加两条流水线轮流提交，并且使用group commit，在双11来临之前的一次测试，他们成功的将单行热点扣减潜能提高到了10万，有20倍以上的提高，并且可实现自动的热点识别，不影响非热点商品的正常扣减。在跟库存应用完成对接之后，几次全链路压测，AliSQL的热点处理潜能甚至远高于下游的处理潜能。
2016年双11，资料库使用新版本的补丁相对平稳运行。按照双11实际的整体表现来看，未来几年内，库存热点问题将彻底告别双11的历史舞台。
资料库大中台全面升级
资料库最重要的是统计数据和SQL，统计数据表示结论，SQL表示过程，两者缺一不可。
在2011年初，资料库第一代监控体系tianji成型，其中包含了基于定量收集网络包的SQL采集工具MyAWR，标志着第一代资料库SQL采集体系正式形成。这种方式是通过TCPDUMP抓取1万个网络包，然后将抓取到的网络包解析成SQL语句，最后算出单位天数内的SQL数，反推出某天数段内的整体SQL情况，用公式表达为：
每分钟SQL数 = 每万个网络包的SQL数 * 60秒 / 每万个网络包的耗时
这种方式存在两个非常大的弊端，就是准确度的问题。But better than nothing。这种方式一直持续到2013年。
2014年至2015年，资料库项目组自研MySQL应用程序DAM（DataBase Activity Monitor），用于记录资料库的执行事件，从安全方面来对资料库异常活动进行监测和审计。但后面由于资源和使用的问题，DAM项目失败，继续沿用着MyAWR。
2016年，倔强的他们再度提出全量SQL采集的目标，并且要求双11当日也能采集，采集内容不仅只是SQL文本，还需要了每一条SQL的运行天数、扫描行数等关键信息。换句话描述，就是要求资料库以INFO级别打印资料库日志。这是一次史无前例的挑战。设想一下，当两个资料库在1万/秒的请求压力下，还要1万/秒的输出日志，这无论对磁盘和资料库本身都是非常苛刻的要求。
这一次项目组内高度合作，有项目组保证高性能的全量SQL输出，有项目组保证高效的全量采集，有项目组保证海量存储，有项目组保证精准分析和使用。最终完成了第二代全量SQL采集控制系统。
在ODPS上，他们可以进行全面的SQL分析计算，如10分钟内有多少用户连续下单等问题。在AliRocks上，他们可以精准的给出SQL直方图，如TOP SQL问题。
2016年双11当日，他们打开了集团买卖核心集群的全量SQL采集功能。当日全量SQL输出对资料库仅有5%不到的影响，并且实时计算最大值处理速度为每秒千万级别，SQL信息，为今后留下了一笔宝贵的财富。
今天，基于全量采集的SQL信息，他们的CloudDBA不仅将全部SQL流水存储做离线分析，双11当日他们还通过实时计算分析出SQL实时性能统计数据。有了这些基础统计数据只是开始，后面他们会基于这些基础统计数据借助统计数据挖掘和机器学习等手段，帮助用户更多维度地理解销售业务统计数据趋势，提供主动的异常发现/诊断，资源预估等更丰富的资料库服务。 帮助用户不仅能够通过CloudDBA自助地诊断和强化自己的资料库，还能够通过CloudDBA更好地理解销售业务如何使用资料库以及如何用好资料库。
同样在双11负责传输海量统计数据的中台另一重要基础设施，就是DRC（Data Replication Center）。DRC负责解析增量资料库日志，分发给大统计数据、搜索和应用，同时负责异地多活统计数据同步。随着实时统计数据计算销售业务的增长，DRC任务数增长迅速，今年DRC集群架构做了重大冲破，能够单集群支撑数万个数据同步进程，对内自动化接入API响应天数减半，通过akka框架使得集群容灾速度得到极大提高，通过合并两个Region（地区）的集群和自动负载均衡降低整体运营成本，以更低的成本和更高的稳定性支撑了更大的双11最大值压力。
在性能上，DRC解析核心做了很大的技术强化，同时在同步链路上通过bucket冲突算法强化和热点合并技术提高了最大值同步潜能，在分发链路通过连接池化技术，使得单个解析存储进程可以同时分发给上千个下游用户，对销售业务快速接入和低成本共享统计数据通道的潜能打下坚实的基础。DRC支撑了异地多活下，多个异地机房间的统计数据亚秒级同步，在双11这样的最大值压力下，依然保证了500ms以内的资料库端到端同步延时。
2016年DRC除了在性能和规模支撑潜能得到提高，他们还在统计数据质量上精益求精，今年DRC全面开启了行校验做统计数据同步，支持统计数据加密传输。对于上游统计数据源的变化努力做到了自动化联动，包括资料库的迁移和拆分，使得订阅实时统计数据的下游销售业务完全无需感知。DRC在队列存储上开放了完整的SQL查阅潜能，使得下游用户可以通过SQL很快查到1条记录，在DRC通道里是否存在，快速定位统计数据质量问题。同时这个潜能支持了部分用户做统计数据对账和灵活轻量的增量报表，拓展了DRC的服务潜能。可以预见，DRC在未来将给销售业务带来更多超越预期的价值。
总结
以上几个例子仅仅只是腾讯资料库项目组在今年双11中众多强化中的几个，同样还有很多优秀的内容无法一一为大家道来。正如开篇提到的一样，资料库项目组是两个有崇尚的项目组，面对技术，他们崇尚极致，面对未知，他们勇于挑战。
2016年双11早已过去，但是资料库项目组早已放下了过去取得种种成绩，准备重新出发了，2017年，AliSQL5.7、AliSQL X-Cluster （基于三副本Paxos/Raft协议的AliSQL）、AliRocks （基于RocksDB存储引擎的AliSQL分支）、Ceph On AliSQL（存储计算分离）、DBPaas，CloudDBA等等每一件事都早已在路上，而且样样极具挑战。
他们是谁
1. 他们是腾讯集团基础架构事业群-资料库技术项目组，他们项目组维护着阿里巴巴集团、蚂蚁金服、菜鸟网络所有的资料库，是整个大阿里系，坚强的存储中台。
2. 他们是腾讯集团谜样的MySQL分支——AliSQL的开发者，传说中的AliSQL拥有者远超原生MySQL的性能，并且有着为腾讯B2C、金融销售业务场景量身定制的强化。
3. 他们为整个腾讯集团的异地多活提供底层基础架构——DRC。DRC提供超远距离（中美超过10,000公里），超低延时（中美同步延时小于500ms）的资料库同步订阅服务。
4. 他们致力于将腾讯的优秀技术和沉淀，通过云产品的形式提供给广大公有云的用户，如DTS——统计数据传输，DMS——统计数据管理，CloudDBA——用户身边的资料库专家。
海到无边天作岸，山登绝顶我为峰，如果正在阅读的你热衷新事物，崇尚极致，敢于挑战，那么就不要犹豫，赶快加入他们。
本文节选自《不一样的技术创新》-腾讯双11技术电子书！10万余字纯干货，8个领域27篇文章，涵盖基础设施、存储、中间件、云计算、销售业务架构、大统计数据、认知计算与人工智能、交互技术及安全等技术领域！
立即扫码阅读全本！
