问题标签 [message-bus]

我正在使用MassTransit，但我认为这是一个概念性问题，通常适用于任何传输抽象/总线消息传递（RabbitMq、SQS、NServiceBus 等）。

我有一个可能存在竞争消费者的场景（即：同一微服务的 2 个实例从同一队列接收消息，因此彼此“窃取”消息）。

问题是微服务ClientSubscribed通过打开与第三方服务器的 websocket 来响应消息（即：），因此特定实例被附加到特定第三方的通道。

当使用另一条消息时（例如ClientUnsubscribed：），微服务必须终止/断开 websocket。

现在，问题是微服务 A 是ClientSubscribed与第三方接收并打开持久 websocket 的那个，而微服务 B 是接收 的那个ClientUnsubscribed，websocket 终止不会发生（微服务 B 没有打开 websocket） .

对于我们将事件驱动与状态和水平可扩展性相结合的此类场景，我们有哪些选择，就像竞争消费者一样？

我可以抛出异常，消息将再次入队，但也许它会重新传递给同一个消费者，并且它会不断抛出异常，直到消息被“正确的”消费者消费。有其他选择吗？

我们需要从数据库发布多个事件作为 json 字符串。像这样通过公共交通发布这个 json 事件：

在配置中我们使用这个配置：

使用此配置时，json 事件已成功发布，但我们有一个奇怪的问题：“all”事件使用者被空消息数据调用！...在Rabbitmq jsut 中发布了我们的“动态事件”，但在masstrasit 中，所有消费者都调用了！感谢您让我们知道我们是否犯了错误

我正在构建一个通知应用程序，它将作为 mac/windows/linux 本机启动。目标是用户可以设置在他们的机器上发送推送通知的时间间隔，然后他们可以选择一个动作来执行任务。

我的问题真的是我应该将间隔服务放在哪里，在应用程序运行时放在应用程序本身上，还是让服务器不断运行，每 5 分钟以上检查一次数据库以查看哪些用户也发送通知？我被告知使用消息总线（可能是 AWS SNS）并让它处理间隔通知。

尽管我同意这是解决此问题的好方法，但我想尝试自己构建一个，以便了解有关消息总线的更多信息。以及学习如何正确维护将不断检查/发送定时消息的服务器。

让服务器不断运行检查数据库，用户收到通知并发送许多推送（可能不会在服务器上很好地扩展）的想法似乎违背了最佳实践，但是我又不知道什么是最佳实践处理这样的服务。

任何建议、文章或方向表示赞赏。

基本上是主题所说的。我想知道当客户端通过从同一个 nats 服务器发送/接收的消息进行通信时，通过使用相同的加密/解密机制是否可以获得性能方面的好处。

如果有人感兴趣，我在这里提出了同样的问题：

https://github.com/nats-io/nats-server/discussions/2740

例如，考虑以下两种基于 n​​ats 的通信场景：

• 场景#1：

发布者 (P) 使用加密解密方案 (A) 和他自己的加密密钥 (A) 向 nats 发布主题“foo.bar”

消费者 (C) 订阅了 nats-subject "foo.bar"，使用加密解密方案 (B) 和他自己的加密密钥 (B)

在这种情况下，我假设 nats-server 将使用解密方案 (A) 对 (P) 发布的消息进行解密，并在使用加密重新加密这些消息后检查主题并将“foo.bar”消息转发给消费者 (C) -方案（B）。

• 场景#2：

发布者 (P) 使用加密解密方案 (A) 和他自己的加密密钥 (A) 向 nats 发布主题“foo.bar”

消费者 (C) 订阅了 nats-subject "foo.bar"，使用与发布者完全相同的加密-解密-方案 (A)

在这种情况下，我假设 nats-server 只需要使用解密方案 (A) 解密 (P) 发布的消息的主题，并在检查主题后将“foo.bar”消息转发给消费者（ C）通过“按原样”“复制粘贴”消息的有效负载（数据），因为加密 - 解密机制完全相同。

我猜想加密-解密中的这种对称性应该在负载高时提供更好的性能。

我的这些假设是对的吗？还是我错过了什么？我还没有看到有人指出场景#2 是提高性能和减少延迟（也可能降低错误率）的一种手段。

想法？洞察力？相关文档的链接？