【问题标题】:Ensuring Azure Service Bus never loses a single message确保 Azure 服务总线永远不会丢失一条消息
【发布时间】:2021-08-08 23:50:10
【问题描述】:

我有一个系统,其中丢失来自 Azure 服务总线的消息将是一场灾难,也就是说,数据将永远丢失,并且没有实用的方法来修复损坏而不会造成重大中断。

在这种情况下,我能否完全依赖 ASB? (即使它要宕机几个小时,它总是会在失败时恢复它所持有的相同消息)

如果不是,在消息至关重要且不能丢失的情况下,解决此问题的好方法是什么?在发布之前将消息简单地保存到数据库以便在发生灾难时可以引用它是否常见?

【问题讨论】:

    标签: azure message-queue azureservicebus messaging event-driven


    【解决方案1】:

    Azure 服务总线不会丢失消息。一旦消息被代理成功接收,它就在那里并且不会去任何地方。通常出错的地方是消息接收和处理,这是用户自定义代码。这就是 Service Bus 具有 PeekLock 接收模式和基于传递计数的死信的原因之一。

    如果您需要强有力的保证,请不要自己重新发明轮子。使用为您完成此任务的消息传递框架,例如 NServiceBus 或 MassTransit。

    【讨论】:

    • 我在考虑 Azure 中断等灾难的情况。当然,在这种情况下,当时总线上的任何消息都可能丢失,即使它恢复了?
    • 您拥有具有高级层的可用区 OOTB。除非所有 3 个副本都被清除,否则消息不会丢失。此外,不要将中断与灾难恢复混为一谈。中断可能会随机发生。灾难场景是......好吧,想想哥斯拉?
    【解决方案2】:

    使用 azure 服务总线,您可以做到这一点并确保 99.99%, 在最坏的情况下,您会在dead-letter queues 找到您的消息,但它永远不会被删除。

    另一种选择是使用 Azure 存储队列并将 TTL 设置为 -1,它将提供无限的生命周期,

    但因为我有点老派,为了确保 101%,我建议使用 azure 表存储的手动解决方案, 因此,您可以决定何时添加/删除或更新线条,因为您使用的信息和数据的批评性

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-08-22
      • 2022-01-16
      • 2022-10-08
      • 2020-10-23
      • 2023-01-13
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多