使用者竞争模式

只喝牛奶的杀手

发布于 2019-09-02 09:48:06

6130

使多个并发使用者能够处理同一消息通道上收到的消息。它可让系统同时处理多个消息，以优化吞吐量、改进可扩展性和可用性，以及平衡工作负荷。

上下文和问题

在云中运行的应用程序需要处理大量的请求。常用方法不是同步处理每个请求，而是应用程序通过消息传递系统将它们传送到异步处理它们的另一个服务（使用者服务）。此策略有助于确保在处理请求时应用程序中的业务逻辑不会被阻止。

在一段时间内，由于多种原因请求的数量会大幅度变化。用户活动或来自多个租户的总请求数的突增可能会导致不可预测的工作负荷。在高峰时间，系统可能需要每秒处理数百个请求，而在其他时间，请求的数量可能非常少。此外，为处理请求而执行的工作的性质可能会有很大变化。运行使用者服务的单个实例可能导致该实例充满请求，或者消息系统可能由于来自应用程序的消息涌入而过载。为了处理这种波动的工作负荷，系统可以运行使用者服务的多个实例。但是，这些使用者必须进行协调以确保每条消息仅传送给一个使用者。工作负荷还需要在使用者之间处于负载均衡状态，以防止实例成为瓶颈。

解决方案

使用消息队列来实现应用程序和使用者服务实例之间的信道。应用程序以消息的形式将请求发送到队列，使用者服务实例从队列接收消息并进行处理。此方法可让使用者服务实例的相同池处理来自应用程序实例的消息。该图说明了如何使用消息队列将工作分布到服务实例。

此解决方案具有以下优点：

它提供了一个负载调节系统，可以处理应用程序实例发送的大幅度变化的请求量。队列充当应用程序实例和使用者服务实例之间的缓冲区。这有助于尽量减少对应用程序和服务实例的可用性和响应性的影响，如基于队列的负载调节模式中所述。处理需要长时间运行处理的消息时不会阻止使用者服务的其他实例同时处理其他消息。
它提高了可靠性。如果生成者直接与使用者通信，而不使用这种模式且不对使用者进行监视，则消息很可能丢失或未能处理（如果使用者失败）。在此模式中，消息不会发送到特定服务实例。失败的服务实例不会阻止生成者，并且任何工作服务实例都可处理消息。
它不需要使用者之间或生成者与使用者实例之间的复杂协调。消息队列可确保每条消息至少传送一次。
可缩放。消息数量波动时，系统可以动态地增加或减少使用者服务实例的数量。
如果消息队列提供事务读取操作，则可以提高复原能力。如果使用者服务实例读取和处理消息（作为事务操作的一部分），并且使用者服务实例失败，则该模式可以确保消息将返回到队列由另一使用者服务实例进行选取并处理。

问题和注意事项

在决定如何实现此模式时，请考虑以下几点：

消息排序。不能保证使用者服务实例接收消息的顺序，且不一定反映创建消息的顺序。设计系统以确保消息处理是幂等的，因为这有助于消除对消息处理顺序的任何依赖。有关详细信息，请参阅 Jonathon Oliver 博客中的 Idempotency Patterns（幂等模式）。

Microsoft Azure 服务总线队列可通过消息会话对消息执行保证的先进先出顺序。有关详细信息，请参阅使用会话的消息传送模式。

为复原能力设计服务。如果系统专用于检测和重新启动失败的服务实例，则可能需要实现由服务实例作为幂等操作执行的处理，以尽量减少对多次检索和处理的单个消息的影响。
检测有害消息。格式不正确的消息或需要访问不可用资源的任务可能会导致服务实例失败。系统应阻止此类消息返回队列，并在其他位置捕获和存储这些消息的详细信息，以便在必要时对其进行分析。
处理结果。处理消息的服务实例与生成消息的应用程序逻辑完全分离，它们可能无法直接通信。如果服务实例生成必须传递回应用程序逻辑的结果，则此信息必须存储在两者都可访问的位置。为了防止应用程序逻辑检索不完整的数据，系统必须在处理完成时指示。

如果使用的是 Azure，工作进程可使用专用消息答复队列将结果传回应用程序逻辑。应用程序逻辑必须能够将这些结果与原始消息相关联。有关此方案的详细信息，请参阅 Asynchronous Messaging Primer（异步消息传送入门）。

缩放消息传送系统。在大规模解决方案中，单个消息队列可能不堪应付太多的请求，并且在系统中成为瓶颈。在这种情况下，请考虑对消息系统进行分区以将消息从特定生成者发送到特定队列，或者使用负载均衡在多个消息队列之间分发消息。
确保消息传送系统的可靠性。需要可靠的消息传递系统来保证在应用程序将消息放入队列之后它不会丢失。这对于确保所有消息至少传送一次至关重要。