【问题标题】:Pub-Sub messaging system for two way communication用于双向通信的 Pub-Sub 消息系统
【发布时间】:2019-02-09 12:07:12
【问题描述】:

嗨,我有图像中捕获的系统。我打算采用一个可靠的消息传递系统,但我对使用哪一个有点困惑。下面解释了数据的详细流程和我的要求。

Step 1: data from System is given to Publisher. 
Step 2: Publisher simply pushes the data to the Topic based Messaging 
        system.
Step 3: There will be  more than one subscribers for each topic and
        subscribers should get notified as soon there are some entries in
        messaging system. 
Step 4: Subscribers process the data and update the status back to messaging 
        system. 
Step 5: Publisher should get notified for the processed messages and 
        acknowledge the System which gave the data.

所以,我的问题是我可以将 RabbitMq 或 Kafka 用于“基于主题的消息传递系统”吗?我的主要要求是从订阅者那里更新状态,并且发布者应该收到状态更新的通知。 (我对此时的吞吐量、性能和可扩展性不太在意)。我的另一个担忧是数据恢复/HA。

【问题讨论】:

  • 您看到对同步处理感兴趣,即发布者等待响应。通常在架构中使用队列来实现异步处理。有一些方法可以在不使流程同步的情况下验证交易是否已处理,请说明这是否是您要查找的内容。
  • 我正在寻找发布者如何知道交易是否已处理,并且我希望订阅者能够确认。这里没有发布者不同步。
  • @Abhinay - 您是否找到了一个基于主题的 MQ 来提供这种开箱即用的支持,或者您是否妥协于使用不同的主题来获得订阅者的确认?
  • @AndyDufresne :没有开箱即用的支持(但在 RabbitMQ 中确实存在类似的支持)。我们继续使用 Rabbitmq。 RabbitMQ 具有类似的从订阅者那里获取通知的方式,并且基于该发布者将决定删除该消息。但是我们没有使用这个功能,我们修改了我们的设计。

标签: apache-kafka rabbitmq message-queue publish-subscribe


【解决方案1】:

如果有一个 N+1 主题系统,一个用于发布将由 N 个订阅者消费的消息,以及 N 个用于确认的主题,每个订阅者一个。 您的“系统”可以订阅所有这 N 个确认主题,并可以验证是否所有订阅者都处理了生产者发布的原始消息。 例如,Kafka 中的每条消息。有一个消息密钥,并且可以使用相同的消息密钥将原始消息与其订阅者特定的确认关联起来。

这是否能在您的系统中实现您想要的功能?

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-04-25
    • 2017-01-31
    • 1970-01-01
    • 1970-01-01
    • 2019-08-11
    • 1970-01-01
    • 1970-01-01
    • 2019-05-17
    相关资源
    最近更新 更多