极客时间《消息队列高手课》笔记

1. 异步处理

对于一个秒杀系统，需要解决的核心问题是，如何利用有限的服务器资源，尽可能多地处理短时间内的海量请求。

处理一个秒杀请求包含了很多步骤：如风险控制、库存锁定、生成订单、短信通知、更新通知数据等。如果没有任何优化，正常的处理流程是：App 将请求发送给网关，依次调用上述 5 个流程，然后将结果返回给 APP。

但上述5个步骤中，只需要风险控制和库存锁定这两步就可以决定秒杀是否成功，对于后续的生成订单、短信通知和更新统计数据等步骤，并不一定要在秒杀请求中处理完成。

所以当服务端完成前面 2 个步骤，确定本次请求的秒杀结果后，就可以马上给用户返回响应，然后把请求的数据放入消息队列中，由消息队列异步地进行后续的操作。

20220724164833

处理一个秒杀请求，从 5 个步骤减少为 2 个步骤，这样不仅响应速度更快，并且在秒杀期间，我们可以把大量的服务器资源用来处理秒杀请求。秒杀结束后再把资源用于处理后面的步骤，充分利用有限的服务器资源处理更多的秒杀请求。

可以看到，在这个场景中，消息队列被用于实现服务的异步处理。

这样做的好处是：

  • 可以更快地返回结果；
  • 减少等待，自然实现了步骤之间的并发，提升系统总体的性能。

2. 流量控制

在用消息队列实现了部分工作的异步处理后，我们还需要考虑如何避免过多的请求压垮我们的秒杀系统。

一个设计健壮的程序有自我保护的能力，也就是说，它应该可以在海量的请求下，还能在自身能力范围内尽可能多地处理请求，拒绝处理不了的请求并且保证自身运行正常。

我们可以使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。

加入消息队列后，整个秒杀流程变为：

  1. 网关在收到请求后，将请求放入请求消息队列；
  2. 后端服务从请求消息队列中获取 APP 请求，完成后续秒杀处理过程，然后返回结果。

20220724165036

这种设计的优点是：能根据下游的处理能力自动调节流量，达到“削峰填谷”的作用。但这样做同样是有代价的：

  • 增加了系统调用链环节，导致总体的响应时延变长。
  • 上下游系统都要将同步调用改为异步消息，增加了系统的复杂度。

3. 服务解耦

对于一个电商系统来说，当一个新订单创建时：

  • 支付系统需要发起支付流程；
  • 风控系统需要审核订单的合法性；
  • 客服系统需要给用户发短信告知用户；
  • 经营分析系统需要更新统计数据；
  • ……

这些订单下游的系统都需要实时获得订单数据。随着业务不断发展，这些订单下游系统不断的增加，不断变化，并且每个系统可能只需要订单数据的一个子集，负责订单服务的开发团队不得不花费很大的精力，应对不断增加变化的下游系统，不停地修改调试订单系统与这些下游系统的接口。任何一个下游系统接口变更，都需要订单模块重新进行一次上线，对于一个电商的核心服务来说，这几乎是不可接受的。

所有的电商都选择用消息队列来解决类似的系统耦合过于紧密的问题。引入消息队列后，订单服务在订单变化时发送一条消息到消息队列的一个主题 Order 中，所有下游系统都订阅主题 Order，这样每个下游系统都可以获得一份实时完整的订单数据。无论增加、减少下游系统或是下游系统需求如何变化，订单服务都无需做任何更改，实现了订单服务与下游服务的解耦。

其他

  • 作为发布 / 订阅系统实现一个微服务级系统间的观察者模式；
  • 连接流计算任务和数据；
  • 用于将消息广播给大量接收者。

消息队列带来的一些问题

  • 引入消息队列带来的延迟问题；
  • 增加了系统的复杂度；
  • 可能产生数据不一致的问题。