我们在需求阶段经常会遇到下列问题，针对直播抢购场景，假设我们要设计一款直播抢购的功能，比如某网红的直播间粉丝过亿，500万人在线，100万单商品瞬间被抢，下单并发高达200万QBS，如果当时出现评论区卡死，商品白屏，连库存服务也挂了，订单系统也崩溃了，这应该怎么办？
分析：首先这是普通的技术难题，库存服务挂了，订单系统也跟着崩了，那肯定是服务依赖没处理好，或者说是这个全链路这个压测不到位，引发了连锁反应。
问：系统缺乏防护机制的原因是什么？
答：我认为系统缺乏防护机制的原因主要有三个。首先，流量失控没有限流措施，导致高并发直接压垮了系统。其次，服务之间的强依赖耦合太紧，一个服务出现问题，其他服务也会受到影响。最后，隔离措施不足，资源和逻辑没有有效隔离，单点故障迅速蔓延，导致整个系统瘫痪。
问：如何设计以避免这种局面？
答：我会采取三个主要策略来解决这个问题。首先，拦截，通过限流和熔断机制拦截和限制流量，比如设定阈值，超过阈值时进行限流或降级，以保护服务不被压垮。其次，缓解，通过缓存和排队等方式缓解流量高峰，提升系统吞吐能力。最后，隔离，通过隔离故障域，将问题限制在局部，防止故障蔓延到整个系统。
问：熔断机制为何不能完全解决问题？
答：熔断机制虽然可以保护下游服务，但它没有考虑到用户行为对系统的影响。当用户因为库存紧张而疯狂重试下单时，会导致订单服务压力暴增，线程池很快被打满，系统还是会崩溃。因此，除了熔断，还需要结合限流、异步排队等手段，减少系统压力。
问：具体如何改进系统以应对用户行为？
答：我会从两个方面改进系统。首先，在订单服务上增加限流机制，限制用户短时间内只能提交一次订单请求，防止用户疯狂重试。同时，优化用户提示文案，如提示系统繁忙或排队信息，减少用户反复尝试。其次，如果流量仍然很大，可以考虑使用异步排队机制，将请求放入队列异步处理，并通知用户已进入排队状态，以缓解并发压力。
问：如何排查系统瓶颈？
答：如果系统在资源未满的情况下卡住，我会从系统的调用链和资源分配入手，逐层分析每个环节的运行情况，找到真正的瓶颈。可能的瓶颈包括线程池消息队列积压、竞争或网络连接问题。
问：“三板斧”策略具体是如何执行的？
答：我的“三板斧”策略包括三个层次的改进。首先是逻辑层，梳理出关键路径和支撑路径，确保关键路径稳定，支撑路径出现问题时可以通过降级或异步处理来解决。其次是服务层，重点在于服务调用和资源隔离，通过线程池隔离和限流控制来防止服务间相互影响。最后是基础层，将底层资源划分为独立的资源池，比如线程池和数据库连接池，按照用户类型或业务模块分开使用，实现区域隔离，防止局部问题影响整体系统。
