DCDB让秒杀更从容、购物更狂欢

摘要：众所周知，“光棍节”是西方文化席卷中国后的产物。现如今，“光棍节”华丽地演绎了屌丝大逆袭，成为家喻户晓的购物狂欢节。面对巨大的购买流量，电商企业如何应对支付洪峰？DCDB稳健的架构、优异的性能、独到的热点更新技术，不仅可让核心交易系统数据库从容面对秒杀及巨量订单交易等场景，而且可有效降低成本。

分布式数据库DCDB，腾讯内部代号”TDSQL”，是解决类似于电商、O2O的订单交易、购买支付场景的利器。

为什么说DCDB最适用于电商、02O等业务呢？众所周知，电商等互联网模式和碎片化的行为，无异给核心交易数据库带来巨大的挑战。即使是某些银行高大上的业务系统，其平均TPS约在10000，常规峰值约1倍；而在互联网场景中，任何智能设备都是交易终端，加上电商等经常出现限时抢购、秒杀等运营活动，无论哪种活动，从数据库角度就都意味着短时间并发和请求总量都远高于正常水平。在类似“双十一”这样的购物狂欢节中，电商系统若不做好措施，结果就是花钱推广，反而砸掉自己招牌。通过总结，互联网场景的交易系统数据库可能经常遭遇以下情况：

（1）峰值超过正常值数倍的业务请求。 （2）秒杀等场景将带来大量的线程影响性能。 （3）故障是常态，如何确保故障数据不错不丢，且不影响全局。 （4）性价比是业务重要考量点。

峰值超过正常值20倍以上的请求洪峰： 以腾讯米大师为例，系统对接了腾讯内外十余万业务的支付交易。这些业务会不定期发布营销运营活动，如电商大促、春节红包、国庆献礼、游戏推广等。在2016全年出现了30多次均值5倍的请求洪峰， 有5次甚至超20倍。下图为近期某业务做午间大促，导致整个平台请求量猛增1倍（蓝线是上一日对比数据，红线是当日数据）。

类似问题也是电商等业务常见场景，而米大师的经验是，除了通过架构将支付系统按场景、业务、流量进行解耦，利用云的弹性（和云的冗余资源池），在活动时快速自动的部署业务服务器。并区分业务单元域（SET）部署，前置调度，做分流和异常隔离和缓存外，采用支持水平拆分的分布式架构的数据库。

因为数据库本身无法像逻辑层一样做隔离请求，而将几张大表水平拆分（分表）。能够让数据库可以随时横向扩展，因此平时只需要在性能方面预留一定冗余，确保偶发性小峰值并不影响整个数据库性能。如果遇到可预见的超高峰值，例如年度大促、春节活动等，由业务部门决定是否进行水平扩容。当然，分布式数据库的原来使得水平扩容十分简单，而且通过自动再均衡方案，扩容可以仅影响集群中的少数节点，而其他节点可以在扩容时仍然正常运行不会受到影响。

热点更新技术，从容应对秒杀等场景： “秒杀”场景下，大量的用户在极短的时间内请求少量商品。在数据库中，一个商品是一行存储，所以秒杀会导致大量的线程来竞争InnoDB行锁，当并发度越高时等待的线程也会越多，导致TPS下降RT上升。这会导致什么问题呢？要么秒杀时，抢购一个商品但整个平台出故障；要么就出现100个库存卖出去105个等各类异常。 当然，业内也有一些从数据库层面的解决方案，例如：把热点商品放到单独的热点库中；通过缓存系统（如Redis/消息队列等）缓存热点请求；或让业务层将lastmodifytime修改的多条SQL合并减少update。 而DCDB的热点更新功能，是通过一个全局HASH表存储有INSERT/UPDATE请求的热点对象，制定热点SQL请求过来时，先查找HASH表中有无对应的热点对象，有就获取lock，会被阻塞；没有该热点对象，那么创建该热点对象的方式进行。这种方案通过简单扩展SQL语法和参数，使得业务不改变架构，仅需修改几行SQL的情况下，便可以快速应对秒杀等场景（原理如下图）。当然，配合缓存使用，可以进一步为业务提高性能，减少击穿的概率

根据测试，我们发现应用和不应用的热点更新技术会的效果差异非常明显（测试数据如下图）。

故障是常态，重要的是如何应对故障： 如果业务是规模比较大，那么无论是网络、硬件、软件或人为的故障都是难以避免。因此，数据库系统必须做到以下几点，才能尽可能小的影响业务

• 只有保障数据强一致了才能保证故障切换的时候数据不错不丢。
• 故障能不能影响全局，且尽量做到业务无感知。
• 支持同城双活、两地三中心等架构
• 立体组合的监控系统，能快速判断故障，定位问题。
• 必须要有风险控制策略等措施保证数据安全

而腾讯分布式数据库DCDB发展了13年，早已默认数据强同步复制，任何节点故障，只要是已应答均可保证数据不错不丢。也可设置多种同步方案，不同的业务数据库采用不同复制策略以求在业务逻辑和数据一致性之间平衡。

DCDB的分布式架构允许任意节点故障，并不会影响全局，且每个从节点都可用做只读访问。在某些仅软件故障的场景， DCDB的保持连接技术，可用软件故障，确保逻辑层（TProxy）和数据库连接不断开，且自动重发失败请求。此时业务是来说，感受就是某个请求时间稍长；即使是数据库事务，或自动回滚，或直接报错，数据不会错乱的。

由于DCDB的设计之初就是应用于腾讯内部金融支付类业务，因此同城双活、年底三中心对其来说早已成熟，常用方案如下图：

通过对系统从硬到软、从模块到流程、从系统升级到常规运维的立体化监控，并结合 “自愈”能力，可让99%常见故障自动解决，仅1%的故障需要人工干预，自动化的流程极大提高了故障修复响应效率。

当然，DCDB也是腾讯首个将完整的信息安全要求和风控体系做到整个数据库系统中的产品之一。包括业务和运维系统，我们提供恶意打击、稽核、实时风控等能力；在数据库层面，也提供了安全审核平台，数据库防火墙等一系列安全能力。

此外，成本控制是互联网企业成功的要素之一，如果是采用商业数据库，先互联网这种体量成本将是天价。而采用基于开源协议的分布式数据架构DCDB和腾讯云服务，按需使用且无高昂的license费用，将极大的节省业务使用数据库成本。

目前，作为支撑了腾讯内外超过100亿以账户，200亿以上的交易流水和海量的虚拟交易的数据库，腾讯云分布式数据库DCDB已经广泛应用在银行、保险、理财、电商、O2O等核心系统中。