用于发布/订阅场景的 Redis 与服务总线答案

【问题标题】：Redis vs Service Bus for pub/sub scenario用于发布/订阅场景的 Redis 与服务总线
【发布时间】：2016-05-09 09:37:13
【问题描述】：

我在 Azure 中有几个服务，我想使用某种发布/订阅服务在它们之间同步更改。

我正在研究 Redis 和 Azure 服务总线。

要同步的数据非常简单 - 大部分是不超过 100 个字符的字符串

我想知道什么是我的首选 - 或者我的方向是否正确..

我的要求很简单：

【问题讨论】：

这个问题与 StackOverflow 无关，因为它非常广泛且征求意见。没有正确答案；只是意见。此外：“高速和低延迟”的解释很开放，并且可能通过任何一种选择来满足。 “足够简单”也是如此。不知道“数据非常简单”是什么意思。两种解决方案都可以在本地使用。
我已经编辑了这个问题，但我仍然认为是主题。我想听听意见。这就是重点，向比我更了解的人学习并听取各种意见，以帮助我做出正确的决定。
我同意 - 它可以进行热烈的讨论。但是......就是这样：StackOverflow 不是讨论意见和进行热烈讨论的地方。没有客观的答案可以在这里发布。而且您的编辑不会使其偏离主题。

【解决方案1】：

不要为此使用 Redis。 Redis PubSub 不可靠（它是即发即弃）。如果 Redis 发布消息时没有人在听会发生什么？它永远丢失了，这意味着您的服务将不会同步...

也许您没有听说过Azure Pack。它不是完整的本地 Azure，但它包含 Service Bus。如果您从公共云或私有云中使用它应该没有问题。

请注意，您也许可以使用 Redis 实现可靠的消息传递，但不能在默认的 pubsub 之上实现。

Redis 和 Service Bus 的可能替代方案应该是 RabbitMQ。

【讨论】：