竞争消费者模式——云计算架构常用设计模式

背景

    在云上，一个应用程序应该具有处理大量请求的能力。常用的技术是应用程序发送消息到另一个拥有异步处理能力的服务。这种策略可以确保应用在等待过程中能继续处理业务逻辑而不被阻塞。
    大多数情况下，请求的数量也会随着时间的变化而有着显著变化。如高峰时期，每秒可能需要处理数百个请求，而其他时间，请求数量可能会很少。为了处理这种波动请求，系统可以运行消费者服务的多个实例。但是，这些实例必须保证系统的安全性(不重复、不丢失、可靠)。工作负载也需要在负载之间进行均衡，防止实例称为系统的瓶颈。

目的

允许多个并发消费者处理同一消息通道上接收的信息，使系统能够并发处理多个消息，以优化吞吐量，提高可扩展性和可用性，平衡工作负载。

建议方案

    使用消息队列作为应用程序和消费者服务实例之间的通信通道。
    具体过程如下：应用程序以消息的形式将请求发送到消息队列，消费者服务实例从队列接收消息并处理他们。
    此方法使得消费者服务实例池能够处理来自应用程序的任何实例消息。

• 好处：
  • 此设计支持处理应用程序实例发送请求量变化大的情况；
  • 提高了系统可靠性：保证消息的丢失重传以及避免异常后的任务阻塞；
  • 无需生产者和消费者之间的复杂同步来保证消息的可靠性；
  • 提高系统的扩展性：根据需求量的波动，动态添加或减少消费者实例；
  • 如果消息队列提供事务读操作，可以保证服务实例失败后，消息将返回队列并被另外一个消费者获取，提高了系统弹性。

考虑因素

• 消息顺序及服务伸缩性：消费者实例接收消息是无序的，设计系统需要确保消息的处理是幂等的(任意次执行的结果与一次执行的结果是一样的)；
• 能够检测有害信息：对于格式不正确或者访问不可用资源的任务，系统应避免这些信息进入队列；
• 处理结果：由于服务实例与应用程序的逻辑完全解耦，他们可能完全无法通信。如果服务实例必须返回结果给应用，则消息应该存储在两者都可以访问的位置，并提供处理已完成的某种指示，防止应用逻辑检索不完整的数据。
• 扩展消息系统：当任务过多时，考虑对消息系统进行分区，将特定生产者指向特定队列；
• 确保系统的可靠性：需要保证任务不丢失且至少传送一次。

适用情况

适用情况：

• 工作负载可以分割成异步运行的任务；
• 任务独立，可以并行运行；
• 工作负载高度可变，需要可扩展的解决方案；
• 解决方案提供高可用，任务失败时具有弹性。

不适用情况：

• 工作负载间耦合度较高；
• 任务间必须同步执行，应用程序逻辑必须等待任务完成才能继续。