你好，我是志东，这是专栏的最后一节课。很高兴在这里遇见你，这说明你选择了坚持！
本专栏虽然较短，但我们已经从技术的角度对秒杀系统的高可用、高性能、一致性等方面进行了深入的讨论和学习，相信你已经有了不少的收获。
那在正式结课之前，我想我还有一些压箱底的东西是可以和你分享的，关于秒杀系统之上的其他思考，这些都是比较宝贵的经验总结。也许未来，当你真正有机会参与大厂的百万级流量的秒杀系统建设时，这些思考可以帮助你少走弯路，从容应对挑战。
如果你身处电商大厂核心系统的开发团队，你一定知道，这些电商平台在每年大促前，都会有几个月的备战期。而在备战期，最重要的一个事情，就是对核心业务链路进行系统压测，找到系统最大承压能力，再评估最大承压能力是否能满足业务预估的备战目标，如果不满足就需要进行相应的优化和扩容。
这里提到的业务流量预估，对于电商大盘来说，相对比较容易一些。业务结合自己的销售目标可以预估个大致的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次数等；然后我们还需要对接口的流量以及性能进行监控；对核心业务流程中的重要节点也需要进行监控。
报警方式：一般是微信告警，但是需要研发第一时间进行介入处理的，需要配置成电话告警，比如数据库宕机。
问题原因：线上出现故障，无外乎这几个方面的原因。系统层面的故障（基础设施和中间件），需要快速进行降级或切换；业务系统变更导致的，比如上线新功能，更改配置，压测引起线上故障，这时候需要第一时间进行回滚操作；依赖的下游接口变更导致的，需要快速定位问题通知下游。
好了，以上就是我做秒杀业务近几年的沉淀和思考。
希望这个专栏能帮助你在这条技术之路上越走越远。那么任何一段旅程都有终点，感谢你的陪伴。我是志东，我们后会有期！
最后，文末有一份结课问卷，希望你可以花两分钟的时间填写一下。我会认真倾听你对这个专栏的意见或建议，期待你的反馈。
