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等核心系统中。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏人称T客

云也能“跨界”?用SaaS来管理本地部署

编译 | Fliex 私有化的本地部署模式总是承诺会比云部署模式具有更好的安全、管理和绩效,但是很多公司却并不愿意使用本地部署模式因为这样会增加更多成本,比如需...

3458
来自专栏喔家ArchiSelf

IoT云服务连接性的方式

物联网(IoT)的开发者可以选择很多方法来创建与物联网云服务的连接,每一个都有不同的优劣权衡。 怎么知道哪个选择是较好的呢?

424
来自专栏数据和云

遇见未来 | PostgreSQL:一匹即将发力的黑马

在2017年的DB-Engine的年度数据库榜单上,PostgreSQL以其超过其他341个受监控数据库管理系统的受欢迎程度居于榜首,被评为年度DBMS。其总体...

3956
来自专栏沃趣科技

降低保险行业TCO成本最好的方式是……

时至今日,“虚拟化”,“云”等名词早已耳熟能详,其提供的特性:将服务器物理资源抽象成逻辑资源,可以将一台服务器变成几台甚至上百台虚拟服务器;将CPU、内存、磁盘...

1065
来自专栏SDNLAB

全方位解读BigSwitch Cloud Fabric

本文由美国ESG实验室评析使用戴尔开放式网络以太网交换机对Big Switch Network的Big Cloud Fabric(BCF)进行的实际操作测试,重...

27413
来自专栏CSDN技术头条

58同城沈剑:好的架构源于不停地衍变,而非设计

对很多创业公司而言,随着业务增长,网站的流量也会经历不同的阶段。从十万流量到一百万流量,再从一百万流量跨越到一千万甚至上亿的流量,网站的架构需要经历哪些变化?在...

2057
来自专栏SDNLAB

Docker实现跨AWS,GCP和Azure的Kubernetes部署

Docker公司为蓬勃发展的容器生态系统提供了一个中心构建模块,现在它希望帮助企业在多云环境中更好地管理该生态系统。

793
来自专栏SDNLAB

摆脱厂商锁定之战,继白盒之后的又一热词——通用客户端设备(uCPE)!

1558
来自专栏云计算D1net

云备份与云存储你该了解的6个方面

2010年之前,绝大多数公司都认为公共云尚未完全成熟,还 不放心将其作为企业数据的主要存储、备份地,但2010年之后,随着巨头们的加速布局,以及大数据的大热,“...

3167
来自专栏SDNLAB

NFV在运营商网络三大用武之地

尽管NFV是一个非常理想的模式,但是如何将NFV逐渐在运营网中引入进来,才是最重要、最需要思考的问题。其实很多运营商都已经开始实践在运营商网络中引用NFV架构。...

34410

扫码关注云+社区