gitbook/手把手带你搭建秒杀系统/docs/432014.md

116 lines
15 KiB
Markdown
Raw Permalink Normal View History

2022-09-03 22:05:03 +08:00
# 结束语|秒杀系统之上的业务协同思考
你好,我是志东,这是专栏的最后一节课。很高兴在这里遇见你,这说明你选择了坚持!
本专栏虽然较短,但我们已经从技术的角度对秒杀系统的高可用、高性能、一致性等方面进行了深入的讨论和学习,相信你已经有了不少的收获。
那在正式结课之前,我想我还有一些压箱底的东西是可以和你分享的,关于秒杀系统之上的其他思考,这些都是比较宝贵的经验总结。也许未来,当你真正有机会参与大厂的百万级流量的秒杀系统建设时,这些思考可以帮助你少走弯路,从容应对挑战。
## 如何预估秒杀活动的流量?
如果你身处电商大厂核心系统的开发团队,你一定知道,这些电商平台在每年大促前,都会有几个月的备战期。而在备战期,最重要的一个事情,就是对核心业务链路进行系统压测,找到系统最大承压能力,再评估最大承压能力是否能满足业务预估的备战目标,如果不满足就需要进行相应的优化和扩容。
这里提到的业务流量预估对于电商大盘来说相对比较容易一些。业务结合自己的销售目标可以预估个大致的GMV涨幅和订单涨幅在业务的基础上适当增加点buffer就可以作为技术侧的同比备战目标这样压测目标也就出来了。
举个例子假如业务今年双11预期销售同比增长30%那技术侧可以按照同比1.4倍或1.5倍来进行备战。比如下单接口去年双11的QPS为10000/s那么今年我们就要准备15000/s的下单能力。除了下单接口核心交易流程的各个链路都可以参照这个逻辑比如进购物车接口去年的QPS为10w/s那么今年就准备15w/s促销接口、优惠券接口、商品详情接口等都以此类推。
**在流量比较均衡增长且没有突发瞬时流量的场景下,以上的预估逻辑没有问题,但是在秒杀场景下,这种按照同比倍数的预估逻辑就不一定能奏效了。**
试想一下在2020年疫情最严重的时候全国口罩紧缺的情况下那时候上线口罩秒杀活动确实很难对流量进行准确预估。我记得当时第一场口罩秒杀活动开始前技术团队虽然预估到流量会很大但是究竟有多大没有人能给出相对准确的数据。虽然我们紧急进行了3倍容量的系统扩容但其实面对未知的流量我们的扩容能不能撑住流量心里真没有底。
事实也证明京东在前几场的口罩秒杀活动时因为流量过大、评估不足出现过部分用户商详页白屏、结算页白屏的情况。面对这些问题技术团队日夜奋战经过几个通宵的紧急优化系统才调整到最佳状态最终能够承接300万人同时秒杀。
毫不夸张地说口罩SKU的秒杀活动是互联网秒杀历史上流量最高的单个SKU没有之一。在当时大厂纷纷采用抽签方式进行口罩派发时只有京东采用预约+秒杀的方式,这体现了京东技术团队强大的技术能力和自信。
瞬时流量的预估确实是个难题不仅仅是秒杀系统大家熟知的微博突发热点事件也有类似的问题。流量明星突然宣布结婚离婚都会对系统造成直接冲击所以坊间有个说法明星火不火够不够TOP就看能不能搞挂微博。虽然是有点戏谑的说法但也确实反映了突发瞬时流量背后巨大的技术挑战。
**那面对秒杀的突发瞬时流量,我们是不是就束手无策,坐以待毙呢?**
那倒也不是,前面的课程已经介绍过了,通过对流量的提前管控,我们可以有个初步预估,再结合前面介绍的削峰、限流、降级等高可用手段,我们是能够应对秒杀的挑战的。
另一方面,任何一次的失败都是宝贵的财富。我们当时通过对一开始几次口罩活动出现问题的复盘总结,就摸清楚了流量的大致范围以及流量的大致组成,多少用户流量,多少刷子流量,再结合库存情况和用户体验考量,就可以有针对性地进行扩容,调整限流阈值。
最后,通过前几场活动信息的收集,我们找到了少量库存下(库存< 5w秒杀系统能承载的普遍模式在这种模式下参与用户最多系统资源利用最大化用户抢购体验最佳这种模式在经过验证后可以非常快速地适用到其他秒杀场景具备通用性
因此,面对不可控的秒杀瞬时流量预估问题,我们要化被动为主动,转化成为在一定库存下,结合系统资源和抢购体验,秒杀系统需要服务多少流量的问题。
## 如何做好跨团队的业务协同?
参与秒杀活动的都是稀缺爆品,非常火爆,一旦活动处理不当,可能出现大规模群诉事件。更夸张的,可能演变成为一个公共危机事件,占据热搜头条,给公司和商家的声誉造成负面影响。
因此,秒杀活动除了本专栏提到的技术挑战外,业务的挑战同样巨大。所以,秒杀活动的顺利完成,不仅仅需要技术团队的努力,更需要公司内跨部门的紧密配合、高度协同,才能共同完成业务目标。涉及的团队包括运营团队、产品团队、技术团队、客服团队、法务团队、公关团队等。
运营团队负责采购和销售,连接供应商和用户,制定商品秒杀活动的销售计划;产品和技术团队落地业务诉求,保障秒杀系统平稳运行,确保活动正常开展;客服团队处在第一线,需及时安抚用户和反馈用户心声;法务和公关团队要对活动中可能出现的法律和公关问题进行评估,给出指导建议。
大的电商平台在做爆品秒杀活动计划的时候,比如茅台,需要提前联动各团队,进行各种风险点评估,只有准备充分之后,才会上线秒杀活动。
**因此,项目之初,我们就需要成立一个各个团队核心成员组成的虚拟项目小组,主要工作内容包括事前、事中和事后几个部分。**
事前,针对秒杀活动的各个环节,进行全流程串联以及风险评估,提前将可能的技术问题和业务问题识别出来,进行补漏和改进。事中,针对活动过程中出现的问题,快速响应,及时灭火,将损失和影响最小化。事后,全团队进行总结复盘,为流程和系统提供优化建议。
上面提到的业务协同内容还是比较抽象的,我们可以结合几个案例再看看,具象化业务协同会涉及到的内容,感受其重要性。
**第一个案例:**我们知道秒杀活动具有非常强的引流作用因为参与秒杀的都是高价值的爆品比如1499元平价茅台抢到一瓶马上转手能赚1000元这些商品天生具备高流量特质这个特点也很容易被商家盯上加以利用。在2020年618大促前夕就有一个酒商看到京东自营的茅台秒杀模式后就拿出一瓶茅台库存来进行1499元预约秒杀活动主要目的是给自己的店铺增加曝光度和用户关注度。当技术侧监控到这个问题后立即召集虚拟协同团队开会商讨解决方案。
你可能会问,为啥平台要介入商家的营销活动?正常一般不会,但是像这种没有提前规划和报备的活动,会给平台带来不少的危害。
一是平台需要消耗大量的硬件资源来应对这个秒杀;二是任何一场秒杀背后,都需要技术人员的全力保障,为了一个库存,耗费这么多的人力物力资源,投入产出太低。另一方面,当几十万甚至上百万人来秒杀一个库存时,意味着几乎所有人都抢不到,一旦宣传出去,处理不好就会上升到“平台虚假宣传”的舆情高度上来,对平台的伤害很大。
因此这就需要运营、商家、客服、公关、法务等一块讨论,协商善后方案,避免大规模群诉和舆情。
**第二个案例:**是正常上架商品时导致的投诉事件。你可能会问,上架商品不是正常的操作吗?怎么还会有投诉?听我慢慢和你说,当平价茅台已经按照固定时间点进行预约秒杀活动后,用户已经习惯了这种售卖方式,这种情况下,用户没有买到,会怪自己运气和手速,而不会推责给平台。
在去年年底的时候业务有非常少量的库存需要在12月30日前清掉想着快速卖掉完事就没有通过预约秒杀营销方式而是直接上架了商品当做普通商品售卖。库存卖完没几分钟没想到紧接着就是大量的客诉进来给一线客服带来了巨大的压力。为什么会投诉理由也很容易理解黄牛们会投诉平台没有按照原有规划投放库存突然进行售卖质疑平台内部有猫腻投放给自己员工。
可见,对于这种千万只眼睛盯着的爆品,卖与不卖,如何售卖,都是压力巨大,需要业务、客服、法务等协同一致,按照既定计划进行,任何的计划变更,需要团队一起进行流程串联和推演。
另外,当平台上线了风控和限购后,黄牛被拦截在外,他们的利益受到损害,他们就会制造各种谣言和舆论来给平台压力。比如会在各种媒体曝光所谓的平台漏洞、技术漏洞,试图混肴视听,希望平台在各种压力之下变更售卖规则,从中谋利。这时候,就需要技术、客服、公关和法务部门通力合作,从技术角度消除谣言,客服要顶住黄牛压力,公关部门要联动媒体进行投诉删文,避免事件扩大化。
**第三个案例:**运营、产品、技术、客服、法务等需要对秒杀全场景下出现的所有面向用户侧的文案通盘评审,对不合理的文案,需要客服和法务的专业意见进行优化。
比如如果用户是因为已经买到了上限被限购拦住了那我们可以直接文案提示“您本月已经购买过2瓶达到上限”这个文案对用户比较直观也能接受因为规则就是这样定的。
如果用户被风控识别为黄牛,被风控拦截不能下单,那我们能不能直接提示“您是风险用户,不能购买”?显然不能,这样的文案会招来黄牛的投诉。因此,这种情况应该展示何种文案以及后续如何处理,需要客服和法务的专业意见,一般这种黄牛用户,我们的文案可以直接提示“很抱歉没有抢到,下次再来”。
再来,系统在运行过程中,也会出现抖动、接口超时以及流量过大被限流的情况,那我们要怎样友好地提示用户呢?
在普通售卖场景,我们这样提示“系统开了小差,请你稍后重试”,“当前参与人数多,系统繁忙,请你稍后重试”,一般也不会有太大问题。但是在秒杀场景,就可能招来大量客诉,因为商品非常昂贵,一旦出现系统异常文案,用户就会怪罪于平台的问题而导致他没有抢到,要求赔偿。
因此秒杀的文案,还是需要结合法务和客服的意见,修改为“很抱歉没有抢到,下次再接再厉”。你可能会觉得这样修改文案,对用户不公平,实际上你仔细想想,如果用户被限流,本身就表示他的手速还是慢了,提示“没有抢到”也合理。
综上几个案例,可见秒杀活动的开展不仅仅是运营和技术的事情,需要公司内各个部门协同联动,共同保障业务顺利开展。
## 如何快速发现爆品?
有了各部门的业务协同联动机制,还有一个事情需要技术侧提供,那就是快速地发现爆品,及时进行预警,联动各部门协同处理。因此,如何快速发现爆品就很关键了。
对于热点爆品的发现技术上可以归结为Redis热点数据的发现。方法也比较简单首先会在一个周期内对key进行请求统计在达到请求量级后会对热点key进行收集和预警反馈给虚拟联动小组决策处理。
## 如何建设监控应急体系?
在搭建秒杀系统高可用时,需要有一套监控应急体系的支撑,各个大厂都会花大把的精力来重点建设。这里我也整理了监控应急体系建设的思维导图,供你参考,涉及以下几个重要的方面:目标、发现问题、监控维度、问题原因、问题解决、问题复盘、演练/值班/报备制度等。
下面我就几个重要的方面详细展开讨论。
**发现问题**:当系统出现异常的时候,我们要能第一时间感知问题、发现问题。而发现问题的途径一般又分为被动和主动,被动的有舆情事件被关注、被用户投诉、订单或资损被业务投诉、兄弟研发部门群里通知;主动的主要是指研发能够根据报警感知系统变化。对监控体系的建设来说,我们希望能做到,系统的异常都是主动通过报警感知到的。
**监控维度**哪些内容需要监控也很重要。我们从架构底层往上看首先需要感知基础设施的故障包括物理机、网络、Docker、域名等指标接着我们需要对中间件的各种故障进行监控包括MySQL、Redis、ES、Dubbo等微服务应用方面的监控需要监控线程数、FullGC次数等然后我们还需要对接口的流量以及性能进行监控对核心业务流程中的重要节点也需要进行监控。
**报警方式**:一般是微信告警,但是需要研发第一时间进行介入处理的,需要配置成电话告警,比如数据库宕机。
**问题原因**:线上出现故障,无外乎这几个方面的原因。系统层面的故障(基础设施和中间件),需要快速进行降级或切换;业务系统变更导致的,比如上线新功能,更改配置,压测引起线上故障,这时候需要第一时间进行回滚操作;依赖的下游接口变更导致的,需要快速定位问题通知下游。
![图片](https://static001.geekbang.org/resource/image/e5/a7/e56218077cacf2bab3f955361b9a85a7.jpg?wh=1920x2127)
好了,以上就是我做秒杀业务近几年的沉淀和思考。
1. 关于预估秒杀流量,和大促备战不同,在很难预估的前提下,我们要做的就是化被动为主动,提前规划秒杀商品的流量上限,提前进行扩容和限流。
2. 关于跨团队的业务协同,对于秒杀而言,公司内客服、法务、公关、产品、运营等团队缺一不可,我们要做的就是提前成立由核心成员组成的虚拟项目小组,共同应对各类突发问题。
3. 关于爆品的快速发现方法,以及高可用系统搭建过程中必不可少的监控应急体系,它们不仅仅是秒杀系统需要的,也是任何一个互联网应用必须考虑的内容,我们应予以重视。
希望这个专栏能帮助你在这条技术之路上越走越远。那么任何一段旅程都有终点,感谢你的陪伴。我是志东,我们后会有期!
最后,文末有一份结课问卷,希望你可以花两分钟的时间填写一下。我会认真倾听你对这个专栏的意见或建议,期待你的反馈。
[![](https://static001.geekbang.org/resource/image/dd/4d/dd6b2862d9e42e68cb5c4ca1f6bb3f4d.jpg?wh=1142x801)](https://jinshuju.net/f/AvlIbF)