大促场景下热点数据写(库存扣减)技术难题买球软件推荐的解决方案 -买球官网平台

《大促场景下热点数据写(库存扣减)技术难题买球软件推荐的解决方案》

 

已经很久没有足够的时间让自己安静下来撰写一篇技术文章,确实近年来,大部分都花在了工作和2017年的新作品上。今天难得自己给自己打了瓶100ml的鸡血,出一篇前段时间针对交易系统大促场景下热点数据写优化的相关案例。当然,不同的企业有不同的买球软件推荐的解决方案和实现,但是万变不离其宗,还是那句话,对于大型网站而言,其架构一定是简单和清晰的,而不是炫技般的复杂化,毕竟解决问题采用最直接的方式直击要害才是最见效的,否则事情只会变得越来越糟

 

在大部分情况下,商品库存都是直接在关系型数据库中进行扣减,那么在限时抢购活动正式开始后,那些单价比平时更给力、更具吸引力的热卖商品大家肯定都会积极踊跃的参与抢购,这必然会产生大量针对数据库同一行记录的并发更新操作。因此数据库为了保证原子性,innodb引擎缺省会对同一行数据记录进行加锁,把前端的并发请求变成串行操作来确保数据更新时的一致性。

 

一、在rdbms中扣减商品库存

先来看看如果是直接在数据库中扣减库存,应该如何避免商品超卖呢?在生产环境中我们可以通过乐观锁机制来避免这个问题,所谓乐观锁,简单来说,就是在item表中建立一个version字段。假设某一个热卖商品的实际库存为n,处于性能考虑对于查询库存操作是不建议加for update的,那么在并发场景下,必然会导致多个用户拿到的stock和version都一样。因此当第1个用户成功扣减商品库存后,则需要将item表中的version加1,这样一来,当第2个用户扣减库存时,由于version不匹配,那么为了提升库存扣减的成功率,可以适当进行重试,如果库存不足,则说明商品已经售罄,反之扣减库存后version继续加1。关于在数据库中使用乐观锁扣减库存的伪代码,如下所示:

 

public void teststock(int num) {
if (version不一致时的重试次数阈值) {
    select stock,version from item where item_id=1;
if (如果查询的指定商品存在) {
if (判断stock是否够扣减) {
             update item set version=version 1,stock=stock-1 where 
                          item_id=1 and version="  version  ";
if (扣减库存失败) {
/* version不一致时开始尝试重试 */
teststock(--num);
} else {
logger.info("扣减库存成功");
}
} else {
logger.warn("指定商品已售罄");
}
}
}
}

 

如果系统前端不配合做限流消峰等处理,随意放任大量的并发更新请求直接在数据库中扣减同一热卖商品的库存数据,这将会导致线程之间相互竞争innodb的行锁,由于数据库中针对同一行数据的更新操作是串行执行的,那么某一个线程在未释放锁之前,其余的线程将会全部阻塞在队列中等待拿锁,并发越高时,等待的线程也就会越多,这会严重影响数据库的tps,从而导致rt线性上升,最终可能引发系统出现雪崩。

 

二、在redis中扣减库存
innodb的行锁特性其实是一把利与弊都同样明显的双刃剑,在保证一致性的同时却降低了可用性,那么究竟应该如何保证大并发更新热点数据不会导致数据库沦为瓶颈这其实是秒杀、抢购场景下最核心的技术难题之一。可以尝试将热卖商品的库存扣减操作转移至数据库外,由于redis的读/写能力要远胜过任何类型的关系型数据库,因此在redis中实现库存扣减将会是一个不错的替代方案,这样一来,数据库中存储的商品库存可以理解为实际库存,而redis中存储的商品库存则为实时库存。

 

在redis中扣减热卖商品的库存,或许有同学会有疑问,redis如何保证一致性呢?如何才能做到不超卖和少买呢?答案就是redis提供的watch命令来实现乐观锁,和基于mysql的乐观锁机制一样,并发环境下,通过watch命令对目标key进行标记后,当事务提交时,如果监控到目标key对应的值已经发生了改变,那么也就则意味着版本号发生了改变,因此这一次的事务提交操作就失败,如图1所示:

图1 利用redis乐观锁扣减商品库存 

 

redis中扣减热卖商品的库存主要是出于以下2个目的:

1、首先是为了避免在rdbms中,多线程之间相互竞争innodb引擎的行锁导致rt上升,tps下降,最终引发雪崩的问题;

2、其次是能够利用redis与生俱来的高效读/写能力来提升系统的整体吞吐量。

 

三、利用“分裂”技巧巧妙地提升库存扣减成功率

这里跟大家分享一个笔者公司的业务场景,由于特务特点,我们整点的限时抢购往往是爆款 大库存(几万至十几万不等的库存数),我们都知道限时抢购的峰值其实就是秒杀,并且还伴随的大库存。相对于普通的秒杀场景而言,由于库存并不多,如果上游系统配合交易系统做好扩容、限流保护、隔离(业务隔离、数据隔离,以及系统隔离)、动静分离、localcache等措施,秒杀场景下就能够将绝大多数流量挡在系统上游,让用户流量像漏斗模型一样逐层减少,让流量始终保持在系统可处理的容量范围之内。

 

由于“变态”的业务特点,业务系统除了要承受亿级流量的冲击,交易系统还要想办法提升下单时的库存扣减成功率,这对于我们来说确实是一次挑战,因为在生产环境中,一次的不小心,将会带来灾难性的后果。我们都知道架构的意义是有序的对系统进行重构,不断减少系统的“熵”,让其不断进步,但架构调整的失误,将会是不可逆的,尤其是那些成熟且用户规模较大的网站。

 

我们都知道,秒杀活动开始后,能够抢购到心仪的产品,是非常不容的一件事情,因为在同一个单位时间内,除了你之外,还有别的用户也在下单,那么针对同一个爆款的watch碰撞概率将会被无情放大,成功率自然降低。如果是小库存,直接返回商品已经售罄即可,但是多大十几万的库存,让用户看得到,买不到,心里痒痒的似乎不太友好,并且运营策略上也希望能够快速消完这些库存好制造噱头。

 

你不用指望能够利用某一种数据库就能够即提升吞吐量又提升成功率,首先你需要搞明白的是,这是一个实打实的单点问题,要保证一致性,就必然会牺牲成功率,这个矛盾点,该怎么解决呢?我们目前采用的做法是在redis中,将某一个sku的key,拆分成n个对应的subkeys,库存服务在扣减库存的时候,通过轮询路由策略路由到不同的subkey上来降低watch碰撞概率,达到大幅度提升下单成功率的目的,如图2所示:

图2 将parentkey分裂为n个subkeys

 

分裂的概念相信大家都已经清楚了,接下来笔者再跟大家分享关于分裂操作的具体细节和一些注意事项。支撑分裂操作的主要由2部分构成,首先是嵌入在库存服务中的路由组件,其次是分裂管理服务,路由组件的任务很简单,订阅配置中心的分裂规则,然后轮询路由到不同的subkeys上做扣减即可。而分裂管理服务则相对复杂,parentkey的分裂操作就由它负责,并且它还需要处理一些相关的库存聚合(subkeys库存聚合)和下拉(重新划分库存给subkeys)任务。

 

分裂了,必然需要对分裂信息进行管理,比如:运营后台对某一个parentkey进行大库存扣减、调整某一个parentkey的分裂数量,以及删除某一个parentkey的分裂规则。这些操作全都包含着以下2个动作:
1、库存聚合(subkeys库存聚合),并将subkey库存设置为0;
2、然后将聚合后的库存归还给目标parentkey;

 

由于聚合和归还并不在同一个事物中,如果因为某些原因导致执行异常,那就悲剧了。比如聚合库存的时候成功了,这时subkeys的库存已经被设置为0,用户是无法正常下单的,但还库存给parentkey这个动作失败了,将会导致商品少卖,所以需要依靠以下2点来尽量保证商品不少卖:
1、业务上增大redis的重试次数;
2、如果redis故障,告警后人工介入归还库存;

 

为什么要区分普通用户扣减库存和运营后台扣减库存?因为这是2个截然不同的概念,因为用户扣减库存,往往会受限于业务(比如限制1个用户1次能够购买的商品数量),但运营后台则不同,有时候可能因为人为原因导致库存设超,因此需要扣减大量的库存,但是如果扣减的库存数量大于每一个subkey持有的有效库存数,则无法完成扣减操作,所以针对运营后台的扣减我们提供有单独的扣减方法,首先会聚合subkeys的库存并将subkey持有的库存数设置为0,将扣减后的库存还给parentkey,再等待重新下拉分配库存给subkeys。在此大家需要注意,如果一个商品特别爆,用户并发越大,聚合再分配的时间窗口期就会越长。

 

有时候,subkeys之间的库存数可能存在不均匀的情况,那么当某一个subkey持有的库存被扣减完,且无回流库存以便下拉重新分配时,只要路由到这个subkey的库存扣减动作都会是失败的,用户就会存在看得到,买不到的不友好体验,因此可以在路由组件上做动作,当某一个subkey的库存已经消完后,本地需要做剔除动作,下次不路由到这个subkey上。

 

最后给大家一点建议,如果parentkey的分裂数量越多,库存扣减的成功率就会越大,当然分裂数量也不是越多越好,一般来说一个parentkey分裂为10-20个subkey就够了,相对以前已经拥有了10-20倍的下单扣减成功率提升。

转发前,请询问我,3q!

2
0
评论 共 1 条 请登录后发表评论
1 楼 2017-12-17 22:15
第三种我从来没想过,不错有收获,算是扩展了

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • 针对交易系统大促场景下热点数据写优化的相关案例。当然,不同的企业有不同的买球软件推荐的解决方案和实现,但是万变不离其宗,还是那句话,对于大型网站而言,其架构一定是简单和清晰的,而不是炫技般的复杂化,毕竟解决问题采用...

  •   何时扣减扣减库存,目前有两种主流方式: 方式1:下单减库存——即用户下单成功时减少库存数量 优点:用户体验好,系统逻辑简单; 缺点:会导致恶意下单或下单后却不买,使得真正有需求的用户无法购买,影响真实...

  • 本文融入了作者及其团队实践中的思考、心得与方法,可以帮助大家解决大型网站架构演变过程中遇到的诸多难题。 本文的所有内容,并不是对架构理论的泛泛而谈,而是云集技术架构从 0 到 1 演变的宝贵实践经验。我...

  • 挑战库存跨机房单元化部署,实现真正的交易单元封闭。

  • 本文原题“阿里数据库十年变迁,那些你不知道的二三事”,来自阿里巴巴官方技术公号的分享。 1、引言 第十个双11即将来临之际,阿里技术推出《十年牧码记》系列,邀请参与历年双11备战的核心技术大牛,一起回顾...

  • 一个商品在下单之前需要先调用库存服务,进行扣除库存,再调用订单服务,创建订单记录,正常情况下,两边数据库各自更新成功,两边数据保持一致性,但是在非正常情况下,有可能库存的扣减完成了,随后的订单记录却...

  • 秒杀场景下的一致性问题,主要就是库存扣减的准确性问题。 1 、减库存的方式 电商场景下的购买过程一般分为两步:下单和付款。“提交订单”即为下单,“支付订单”即为付款。基于此设定,减库存一般有以下几个方式:...

  • 数据迁移说白了,考验的不是一个人的技术功底,而是一个人干活的细致程度,以及抗压能力。无论在哪个公司,数据库迁移的机会都不会太多,因此,我也是非常珍惜这次历练,用阿里的一句老话来说就是 “因人成事,借事...

  • 技术与能力其他概念数据赋能数据产品二.数据分析可以解决问题类型:1.“是多少”问题的解决思路2.“是什么”问题的解决方法3.“为什么”问题的解决方法4.“会怎样”问题的解决方法5.属于“怎么做”的方法总结三.数据...

  • 点击上方「蓝字」关注买球官网平台前言秒杀大家都不陌生。自2011年首次出现以来,无论是双十一购物还是 12306 抢票,秒杀场景已随处可见。简单来说,秒杀就是在同一时刻大量请求争抢购买同一商品并完...

  • oceanbase 资深买球软件推荐的解决方案架构师孟磊围绕“原生分布式数据库助力跨境电商低成本稳步增长”主题进行解读,结合实践与案例,探讨跨境电商如何通过打好数据底座,保障未来业务稳步增长的同时,用更低的成本享受更高的性能...

  • 在日前的京东技术开放日618技术分享专场,多位京东技术专家联袂解析了京东的技术研发体系如何在高强度的负载压力下,保证业务系统的平稳运行,并介绍大型互联网平台技术升级、备战思路、应急预案设计、问题应对等各...

  • 核心篇数据结构与算法网路:tcp/ip,http操作系统, 文件, shell, cpu, io, epoll, 非阻塞io,进程/线程/协程,锁hashmap, co...

  • 《请先别急着嘲笑书名——这才是真正的大型网站架构买球软件推荐的解决方案》     作者介绍: ...高翔龙,杭州云集微店...1、货真价实的互联网场景下大型网站架构演变过程中核心技术难题的买球软件推荐的解决方案; 2、全部来源于作者真...

  • 内部技术博客是美团技术同学知识交流与沉淀的公共平台,在这里,你可以找到各团队的技术实践总结、填坑案例、新技术学习笔记、基本功修炼、团队管理经验、成长感悟等丰富内容。同时,我们也需要有才华的你,把个人...

global site tag (gtag.js) - google analytics