构建可承极端流量的软件系统最佳实践
免责声明~ 任何文章不要过度深思！ 万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」； 不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。 怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」
1 Ticketmaster出啥问题了？
暂停整个销售意味着存在一个对票务结账流程至关重要且可能导致连锁故障的依赖性，问题可能与PayPal支付处理工作流有关。Ticketmaster依赖PayPal作为其主要的全球支付处理平台。
2 Verified Fans系统缺陷
Ticketmaster最初实施Verified Fans系统，以区分机器人和真实人类，以打击黄牛和门票转售商。有350万经过验证的粉丝注册进行预售。其中150万收到邀请码，而200万则处等待状态。这通常是缩短等待时间、使门票销售更加顺利的好方法。然而，泰勒·斯威夫特引起“历史上前所未有的需求”：
- Ticketmaster原本准备好处理150万受邀购票的粉丝，但当超过1400万人出现时，他们不知所措
- 网站上超过15％的交互经历问题，包括邀请码验证错误
- 一旦系统容量超过，系统未能拒绝新请求，因此用户继续发送请求，最终超载和使服务器崩溃
最终，一些用户即使将门票放入购物车也无法结账。为控制损失，Ticketmaster尝试等待更多的客户并延迟销售，导致排队时间更长。许多经过验证的粉丝在这些队列中等了几个小时，最终却收到错误消息。一举一动，足见慎重。设置对请求数量施加硬限制可能本可以防止许多混乱和挫败感。
3 连锁故障
尽管一开始就清楚Eras巡演将带来巨大的门票需求，但这一需求的规模将在太晚才能实现。
Ticketmaster的第一个错误是对试图购买门票的顾客数量准备不足。容量规划是系统设计重要方面，当系统没有足够的安全保障来限制请求时，事情易失控。
事故事后分析中识别到重要因素：
在这四个因素作用，请求数量激增到惊人***35亿次***，之前峰值四倍。
产生效果类似[DDoS攻击]。虽然我相信Ticketmaster学会更加优先考虑未来更为强大的容量规划措施，但看到一个应该为这种时刻做好准备的公司在压力下失败还是有些出乎意料。主要教训应该是企业在容量规划方面采取主动措施的***重要性***。通过正确的应急措施，类似场景可避免。
4 如何设计一个应对高需求的系统？
实时排队是难题。如Ticketmaster的目标是让数十万甚至数百万用户实时排队等待抢购门票的活动，那将需要大量的处理能力。时间戳粒度不足以为任何可感知数量的并发用户排队。 （有比实时排队更好的为顾客提供服务的方法，但稍后讨论。）
这种情况在分布式计算的世界并不新鲜，甚至有一个你可能以前听说过的名字：“Thundering Herd（雷鸣般的群体）”问题。大型分布式系统如Facebook处理过比泰勒·斯威夫特粉丝更多的“雷鸣般的群体”问题。
可假设Ticketmaster并无太多弹性容量。弹性容量指备用服务器的可用性，用于处理流量的增加。通常，这些额外服务器用于非关键数据或非时间敏感的处理。当网站访问量激增时，这些备用服务器可用于帮助管理额外的负载。然而，仅增加更多计算能力似乎有点简单化。因此，让我们讨论在需求高情况下系统如何设计扩展的三种方式。
5 缓存
处理高流量负载的最明显方法是尽可能缓存尽可能多的数据。缓存可以在服务器或客户端级别执行，对于频繁请求的资源的响应特别有用。如果能够加快交付速度，就可以为更多用户提供服务，同时利用更少的计算能力。
6 优雅降级
经典的容量规划考虑。最简单形式中，优雅降级本质是一种逐渐拒绝请求的方式。随负载增加，工作流程将如下：
image-20231219211827722
优雅降级确保即使其他部分失败，核心系统功能也是可用的。现实优雅降级的例子是自动扶梯：当自动扶梯停止移动时，它就变成楼梯。正常工作时效率更高，但最终结果一样。
7 构建一个等待室并设置购买时间限制
Ticketmaster已经拥有一个名为“智能队列”的等待室，并设置一个时间限制购买门票。这都是解决机器人攻击或用户持有门票却无购买意图的好做法。
Ticketmaster并未明确规定在队列最终解除时有多少用户可尝试购买门票。Ticketmaster系统试图“保留”放入购物车的门票，然后给予完成交易的时间限制。
问题出现在购物车中的门票实际上并不可用时。当发生这种情况时，在结账时会出现错误，用户将返回到交互式座位图（ISM）以将另一张门票放入购物车中。这可能导致系统列出待售门票的用户大规模涌入。
8 第三方依赖是否毁掉Ticketmaster？
防止将来发生这种情况的Ticketmaster最佳方法确实取决于Ticketmaster的内部设计。
由于大多故障发生在用户购物车门票后，有可能通过PayPal等支付处理依赖或VISA和Mastercard等卡提供商平台引起的支付处理依赖引起了系统连锁故障。
9 但需求是不是太高了？
这确∂实是问题的一部分。导致泰勒·斯威夫特巡回演唱会前的独特条件确保了一个对歌手下一场演出渴望不已的粉丝群体。她长时间舞台缺席，加上热切的后疫情音乐会观众的热情，创造对门票的前所未有需求。
Ticketmaster估计，“根据我们网站访问量，泰勒需要进行超过900场体育场演出（几乎是她正在进行的演出次数的20倍）。”即使Ticketmaster能够完美地进行一次发布，许多粉丝仍然可能一无所获。再加上她在北美巡演的社交媒体炒作，不难看出为欧洲Swifties销售门票将是一项挑战。
咋做？总的来说，通过部署上面提到的所有缓解策略（缓存、弹性需求、优雅降级等），为10亿次系统调用做好准备是一个好的做法。这比Ticketmaster报告的35亿流量要多得多，因此可能是他们的系统被一个引起系统中连锁故障的棘手瓶颈所阻塞。
10 有限发售系统的未来
暂时放下容量规划，从用户角度考虑预售流程。
一些用户认为Ticketmaster的Verified Fans系统复杂。许多粉丝报告说他们花了几个小时在队列中，最终在队列前面时却遇到结账错误。整个预售流程需要很多时间，有时长达四到五小时。这还不包括注册为Verified Fan并收到预售代码所需准备时间。
对有正常日常职责的普通粉丝，这承诺可能是不可承受之重。可添加多层粒度以帮助减轻软件系统和消费者压力：
虽然我不认为Ticketmaster会完全推翻他们的预售工作流程，但重要的是要记住，容量限制和其他系统设计瓶颈有时可以通过优化其他方面来解决。
这种全面解决问题的方法是系统设计的关键方面。
参考：
- 编程严选网