`

淘宝“超卖”背后的技术猜想

阅读更多

今年2012.11.11淘宝脱光大促销,是电子商务一个重要的里程碑,按照马云的说法,这次打响了对传统商业贸易购物的第一枪,宣告了多年来对传统行业的商务行为的革命。
按照历史逻辑分析,每一次革命必然给世人带来崭新的时代,但同时在某些方面也会付出一定的“血”代价,除了某些行业进入衰退期,支撑这场革命运动的背后力量的弱点也会一一暴露出来,而这股背后力量就是来自于淘宝(天猫)的技术系统平台。

根据淘宝官方提供的线索,超卖的原因是前后台商品数据的不一致,导致了这次系统的漏洞。但是如何导致数据不一致,却没有相应的解释。如此留下的悬念,让技术屌丝的我展开了“哥德巴赫”的猜想。

一般来讲,成熟的电子商务平台,除了提供给外部会员访问的前台系统(后续称为买家系统),必然会有配套的提供给内部运营管理的后台系统(后续称为信运系统),对于淘宝的商业模式来说,里面还有一个提供给商户管理的商务前台(后续称为卖家系统),如果三个系统分离的话,往往就是造成数据的不一致的罪魁祸首。

从操作流程上来讲,在活动之前,信运系统除了审核会员,商家,商品等基本功能外,会针对预定活动设定时间,制定规则;卖家系统上架活动商品,设定价格,数量等一系列的活动参数;活动当天,买家系统负责展示活动商品,订单交易等一系列最大流量的请求操作。当然在这个过程中,卖家系统也会同时根据销售情况更新数据。

从系统架构层面,想必淘宝基本上离不开MVC的设计模式,第一层展示层(Viewer), 第二层业务逻辑层(Controller),第三层数据存储层(Model Data),我这里自底向上分析导致这场故障的可疑点。

直观来讲,所有数据必然都是在数据库里面,那不一致最有可能是数据库不一致,首先淘宝可能采用的是Master-Slave读写分离的模式,那必然是有多台Master、Slave的数据库服务器,写操作指向master节点,读操作分流到slave节点,这样主从数据库就需要进行及时的同步保证一致性,往往在主库或从库压力巨大的时候,master的更新很难快速到slave。主从复制一般是先把master含有更新操作binlog复制到slave,slave通过I/O_thread线程写入replay_log,随后slave的sql_thread单线程解析replay_log重放里面的更新操作。如果暂不考虑网络传输binglog延迟的话,对于sql_thread可以进行调优,在可控的场景下,采用多线程sql_thread并发进行binlog追加,缩短延迟时间。也听过一种优化方式就是,开发mysql插件可以在sql_thread读取replay_log之前,把update所涉及的数据在内存中预热,从而帮助sql_thread缩短sql执行的时间。当然对于这些优化的前提,还是先建议把binlog记录格式从statement或mixed改成row的形式,尽管这个会造成日志大量增加,但是对于上述优化,row记录更具有可控性。
以前在电信行业,接触过mysql cluster的架构,其中所有mysql服务器都是master active的状态,都支持并发的读写,在每次写操作的时候,mysql永远保证所有节点数据的一致性,其中原理肯定相比之前的M-M模式更加复杂,当然性能也不错,可能从运维成本和可控性角度来讲,互联网公司很少采用这种架构。

说完mysql主从复制本身的局限性,我们可以提一提,在业务开发过程中,设计的冗余字段。譬如一家淘宝店铺的商品种类数,其中每件商品的库存,还有每件商品的点评数等等统计字段,我认为按照淘宝的设计,对于这些统计字段不可能每次执行这种sql语句(select count(1) from * group by *)来获得的,否则按照当天流量,数据库早就挂了。那么有人可能会说那就把它缓存起来,当然这是一个提高性能的办法,但是对于这些数据必然需要进行持久化到磁盘,以防止突然宕机或重启导致的数据丢失,那么这些冗余字段的一致性维护就需要可靠的机制来保证,目前业界通用做法采用消息系统来完成,复制更新来源系统发出通知消息,订阅此类消息的关系系统就会自动更新对所拥有的冗余字段,如此一来,消息系统的收发性能,响应时间和Qos质量保证就尤为重要,如果发生的长时间的延迟,连续重发,甚至丢包等现象,就会导致冗余字段数据不一致,从而引发业务上的错乱。所以消息系统可以选择一些高性能高可用性的成熟中间件,并且能够遵循JMS(JSR-914)规范,除此之外,通过执行一些脚本作业进行一致性确认及补偿,对于非敏感型的业务数据,并不一定需要实时一致,但可以保证最终一致性。

说到数据库这种磁盘持久化,不得不说一下另外一种存储形式-缓存,顾名思义,缓存就是缓冲区的存储,它与数据库存储不同之处,它是放在内存里面的,当然如果一旦重启,缓存数据就会丢失,而它的优点就是业务逻辑的程序可以直接在从内存里面读取它,避免了诸如读取磁盘的耗时I/O操作,可以大大的提高系统性能。许多业务中的计数器,类似上面的统计字段,往往适合放在缓存里面,提供高并发的读取,既然这样,大家就自然而然想到,这个缓存数据又是如何保证一致性或实时性,更新数据之后,是否可以保证能够成功的刷新缓存,这些都是值得怀疑的地方。我的建议是,虽然有时无法保证一定成功刷新缓存,但是可以在某些数据的敏感区间内做二阶段确认,比如当某衣服实际还剩下不到10件的时候,在提交提单的时候,除了从缓存中读取到库存数并且发现已经小于10时,可以从数据库读取真实的库存,做一次数据对比,以此判断是否还可以进一步交易。

在业务逻辑层面,我想更多谈的就是业务操作的同步,当大量会员交易的时候,库存的数据就要很迅速的更新,前一个交易的结果就会影响到下一个交易行为的可行性,落地到技术细节,就演变成了多线程读与写的同步问题和事务控制,这个也算是并发操作的经典问题,同时放在多台业务系统组成的集群环境下面,就变得更加复杂。根据不同的部署来看,一般分为两种情况,一种是所有持久化数据存在中心化数据库服务器,缓存数据存在独立的分布式缓存集群服务器,那对于业务系统来讲,不管有几台,其实他们是无状态的,除了增加事务控制外,数据一致性大部分由存储服务器来保证。另外一种就是一部分缓存数据放在了业务系统本身,通过集群技术,分布式存储这些数据,这样一来,就从单进程的多线程同步演变成跨JVM的分布式同步,甚至引入了分布式事务控制。根据经验,笔者建议尽可能采用第一种保证业务服务器的无状态性,避免第二种分布式情况带来的复杂性,降低运维成本。但是在某些场景下,比如复杂结构的大数据对象,就不大建议存放在外部缓存系统,否则带来了网络I/O反而增加了延时,更适合放在业务系统本身,那么到底是replicated-ALL存储,还是distributed存储,这个还要结合考虑系统所需的伸缩性和稳定性。笔者正在研究几款内存数据网格的中间件,适用于集群环境下面使用,待觉得成熟之后,可以推荐给大家,一起讨论研究。

在某些时刻,极端高峰的时候,数据一致性问题从技术上已经不大可能避免的话,还可以采用一些特殊的非正常手段进行保护,比如服务降级,流控,可以把超过阀值一些交易操作请求放到排队系统,通过时间换空间的做法,保证系统的稳定性,从而保证数据的一致性。

到这里,其实从底向上分析,已经有许多在系统架构上面可能导致问题的关键点,尽管笔者目前是局外人,但是这些也是曾经经历过的种种,姑且在这里抛砖引玉,欢迎有缘人或当事人一起吐槽。

有时候可能事实喜欢开个冷笑话,说不定就像狂欢当天,某位老板手贱把一款原价118的商品标错了11.8元,所以可能就是淘宝压根忘记了更新某个字段。呵呵,不过我想应该不会发生这种低级问题的。

最后淘宝对于超卖事件,也对买家做出了经济补偿,就像上面提到的数据作业补偿一样,一旦一时发生了不一致或不平衡,最后还是需要保证一致性或平衡性, 今年最后奋力一搏的淘宝,以一天进账4亿的收入非常出色的完成收官之作奠定了电商领域的霸主地位。

0
3
分享到:
评论

相关推荐

    使用rabbitmq解决超卖问题

    在高并发的电子商务环境中,超卖问题是一个常见的挑战。当多个用户同时购买同一商品时,如果库存管理不当,可能会导致实际库存数量小于销售订单的数量,从而出现超卖现象。为了解决这个问题,我们可以利用消息队列,...

    通达信指标公式源码 超卖选股源码.doc

    在这个超卖选股公式中,主要涉及到以下几个技术指标和计算方法: 1. **长期** 和 **中长期**:这两个指标是基于高低价差与价格区间的相对位置来判断市场的长期和中期趋势。 `(C-LLV(L,周期)) / (HHV(C,周期)-LLV(L,...

    通达信指标公式源码反应严重超买超卖副图指标.doc

    该指标公式源码反应严重超买超卖副图指标,是一种基于通达信指标的技术指标,用于检测市场的超买和超卖现象。 该指标公式源码中定义了多个变量,包括VAR1、VAR2、VAR3、K、D、VAR18、VAR28、VAR38、K8、D8、VAR188...

    通达信指标公式源码 超买超卖-超级KDJ.doc

    KDJ 指标是一种常用的技术指标,用于判断股票的超买和超卖状态。但是,传统 KDJ 指标存在一个问题,即信号过多和繁杂,容易导致投资者难以作出正确的投资决定。为解决这个问题,该指标采用了 MA 均线的平滑处理,对...

    全能RSI超买超卖5MEA.zip

    全能RSI超买超卖交易策略,RSI是确认趋势的强度是涨跌点数之和比率制作的一种技术曲线,是反映出市场在一定时期内的景气程度,当RSI高于50水平并开始下跌,表明上涨趋势正在减弱,当低于50并开始上涨,表明下跌趋势...

    双11天猫、淘宝网的超卖问题是如何产生

    这会导致淘宝的双11活动卖出的金额191亿元很水啊情况是这样的吗?而且大多发生在零点10分以内的?  这会导致淘宝的双11活动卖出的金额191亿元很水啊  情况是这样的吗?而且大多发生在零点10分以内的?  当商家的存货...

    Spring Boot + redis解决商品秒杀库存超卖

    在众多抢购活动中,在有限的商品数量的限制下如何保证抢购到商品的用户数不能大于商品数量,也就是不能出现超卖的问题;还有就是抢购时会出现大量用户的访问,如何提高用户体验效果也是一个问题,也就是要解决秒杀...

    超买超卖更清晰 KDJ叠加RSI通达信指标公式源码.doc

    RSI指标是一种技术指标,用于判断股价的超买和超卖情况。RSI的计算公式为: RSI = SMA(MAX(CLOSE - LC1, 0), 6, 1) / SMA(ABS(CLOSE - LC1), 6, 1) * 100 其中,LC1是昨日收盘价,SMA是简单移动平均线的简称。 ...

    Redis中的String类型及使用Redis解决订单秒杀超卖问题

    本系列将和大家分享Redis分布式缓存,本章主要简单介绍下Redis中的String类型,以及如何使用Redis解决订单秒杀超卖问题。 Redis中5种数据结构之String类型:key-value的缓存,支持过期,value不超过512M。 Redis是...

    赢顺云指标公式源码文华财经指标中期方向线超买超卖.doc

    文档“赢顺云指标公式源码文华财经指标中期方向线超买超卖.doc”主要涉及的是金融市场的技术分析工具,特别是一种基于移动平均线(Moving Average)理论的指标设计,用于判断市场的中期趋势以及超买和超卖状态。...

    股票技术指标详解整理.pdf

    超买超卖指标是股票技术指标中的一种,它可以反映股票的超买超卖状态。超买超卖指标是基于股票价格的变化和交易量的变化来计算的。 超买超卖指标的应用原则是:当股票价格高于移动平均线时,表明股票处于超买状态;...

    高并发场景防止库存数量超卖少卖

    在高并发电商场景下,商品超卖(即销售量超出库存)是常见问题,主要由并发扣减库存导致。常规做法是在扣减库存前检查库存充足性,...总的来说,解决商品超卖问题需要综合运用多种技术和策略,以适应复杂的高并发场景。

    解决高并发环境下Redis连接超时与超卖问题

    在高并发环境中,系统往往面临着连接超时和资源超卖的问题,特别是在电商秒杀或抢购场景中,数据库和缓存系统的压力巨大。本示例针对这些问题,利用Redis的乐观锁机制来提供解决方案。Redis是一种高性能的键值存储...

    个人编写一个超卖指标——苦尽甘来通达信指标公式源码.doc

    个人编写超卖指标公式源码解析 在金融市场中,技术分析是...个人编写的超卖指标公式源码是一种复杂的技术分析工具,通过计算和逻辑关系,帮助投资者和投资银行家判断当前市场的趋势和超卖状态,并做出正确的投资决策。

    Redis的类库及Redis解决订单秒杀超卖问题,极光推送代码

    Redis是一种高性能的键值数据库,常用于数据缓存、消息队列、计数系统以及分布式锁等场景。在本文中,我们将重点讨论Redis的类库、...在实际开发过程中,理解并熟练掌握这些技术将对提升应用性能和稳定性大有裨益。

    通达信指标公式源码 短线超卖 短线指标 副图源码.doc

    通达信指标公式源码提供了短线超卖指标的编写方法,读者可以根据该公式编写自己的短线超卖指标。该公式基于RSI(Relative Strength Index,相对强弱指标)技术指标,通过计算股票的相对强弱来判断股票的涨跌趋势。 ...

    期货软件指标公式源码文华财经指标中期方向线超买超卖.doc

    期货软件指标公式源码文华财经指标中期方向线超买超卖.doc

    淘宝记账王 V3.3

    10. **技术支持与服务**:软件开发者通常会提供技术支持和服务,包括在线帮助文档、用户论坛、客服热线等,以便用户在使用过程中遇到问题时能得到及时的帮助。 综上所述,淘宝记账王V3.3是一款为淘宝卖家量身定制的...

    淘宝红绿仙女版--自己搭建

    总结来说,淘宝红绿仙女版的搭建涉及前端开发、后端开发、数据库设计、服务器配置、负载均衡、高并发处理等多个方面,需要全面的IT知识和技术。在整个过程中,开发者需关注用户体验、系统性能、数据安全和稳定性,以...

    test(2).zip_淘宝

    在IT行业中,淘宝作为中国最大的在线购物平台,其背后的技术架构和系统流程是业界广泛关注的焦点。本篇文章将深入探讨“test(2).zip_淘宝”这个压缩包所揭示的相关知识点,主要涵盖网上购物系统的流程、设计模式以及...

Global site tag (gtag.js) - Google Analytics