使用者竞争模式

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

上下文和问题

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

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

解决方案

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

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

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

问题和注意事项

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

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

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

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

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

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

何时使用此模式

在以下情况下使用此模式:

  • 应用程序的工作负荷分为可以异步运行的任务。
  • 任务是独立的且可并行运行。
  • 工作量是多变的,因此需要可缩放的解决方案。
  • 该解决方案必须提供高可用性,并且如果任务的处理失败,必须具有复原能力。

在以下情况下,此模式可能不起作用:

  • 难以将应用程序工作负荷分成离散任务,或任务之间存在高度依赖性。
  • 任务必须同步执行,且应用程序逻辑必须等待任务完成后才能继续。
  • 必须以特定顺序执行任务。

某些消息传递系统支持会话,使生成者能够将消息组合在一起,并确保由相同的使用者进行处理。 此机制可用于按优先级排列的消息(如果支持)以实现消息排序的形式,从生成者到单个使用者按顺序传送消息。

本文分享自微信公众号 - 只喝牛奶的杀手(killerhub),作者:azure

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-12-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 隔舱模式

    此模式之所以称为“隔舱”(Bulkhead),是因为它类似于船体的分段区。 如果船体受到破坏,只有受损的分段才会进水,从而可以防止船只下沉。

    只喝牛奶的杀手
  • 优先级队列模式

    为发送到服务的请求确定优先级,以便高优先级请求能够得到比低优先级请求更快速地接收和处理。 在向各个客户端提供不同服务级别保障的应用程序中,此模式非常有用。

    只喝牛奶的杀手
  • 开发应该知道的Linux系统分析-IO篇

    小文件读写的性能瓶颈是磁盘的寻址(随机读写性能更差),评估的标准是tps。大文件读写的性能瓶颈是带宽,评估的标准是持续的读写速度。Linux可以利用空闲内存作文...

    只喝牛奶的杀手
  • kafka学习之路(二)——提高

    消息发送流程 因为Kafka内在就是分布式的,一个Kafka集群通常包括多个代理。为了均衡负载,将话题分成多个分区,每个代理存储一或多个分区。多个生产者和消费...

    汤高
  • 原创 | 消息中间件的工作原理和RabbitMQ入门

    消息(Message)是指应用于应用之间传送的数据,消息的类型包括文本字符串、JSON、XML、内嵌对象等等...

    黄泽杰
  • 冒烟测试

    冒烟测试源自硬件行业,对一个硬件或者硬件组件改动后,直接给设备加电,看看设备会不会冒烟,没冒烟,就表示待测组件是通过了测试。

    week
  • 选软件要靠自己不能只靠专家

    2017年写过一篇关于SAAS的文章放到知乎,结果有很多网友加我微信,咨询我问题,其中有些人会让我推荐一个”成熟”的餐饮软件给他。说实话,市面是真正好的餐饮软件...

    用户5829239
  • 百万并发量苹果官网准备好了吗?——一分钟学会服务器压力测试

    企业需要良好的网站性能。网站的访问速度和顺利的体验是企业必须要做好的事情。本文从苹果官网两年来每次预购都出现的服务器宕机情况,揭示服务器性能测试的重要性,手把手...

    WeTest质量开放平台团队
  • 千防万防,黑客难防!获取远程桌面权限

    找到上传点,上传1.php文件失败,提示只允许上传jpg文件。于是传图马抓包改后缀

    随心助手
  • “一切都是消息”--MSF(消息服务框架)之【发布-订阅】模式

    在上一篇,“一切都是消息”--MSF(消息服务框架)之【请求-响应】模式 ,我们演示了MSF实现简单的请求-响应模式的示例,今天来看看如何实现【发布-订阅】模式...

    用户1177503

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动