redis - ServiceStack Redis Mq : is eventual consistency an issue?

Question

我正在考虑将单体式应用程序转变为面向微服务的应用程序，为此需要一个强大的消息传递系统来进行进程间通信。这个想法是让微服务进程在服务器集群上运行以实现高可用性，将要处理的请求添加到所有应用程序都可以访问的消息队列中。我正在考虑将 Redis 用作 transient 数据的 KV 存储以及使用 .Net 的 ServiceStack 框架作为消息代理，但我担心 Redis 应用的最终一致性概念会使请求处理不可靠。这就是我对 Redis 在 Mq 方面的作用的理解:

1. 客户端 1 向节点 1 上的队列发送请求
2. 节点 1 将使用 pub/sub 通知该队列上的所有监听器存在请求并将请求异步推送到节点 2。
3. 节点 1 上的监听器将从该节点拉取请求，其中只有一个会按应有的方式获取请求。请求删除的更新被异步发送到节点 2，但需要一些时间才能到达。
4. 初始请求由节点 2 接收(假设 RTT 有一点延迟)，它将继续并使用 pub/sub 通知连接到它的监听器。在从节点 1 接收到关于从队列中删除请求的更新之前，节点 2 上的监听器也可以拉取该请求。结果是两个监听器最终处理了同一个请求，这将对我们的系统造成严重破坏。

Redis 或 ServiceStack Redis Mq 的实现中是否有任何东西可以防止所描述的情况发生？还是我误解了 Redis 中的复制？或者我应该放弃 Mq 的 Redis/SS 方法并使用 RabbitMQ 之类的方法来代替我认为符合 ACID 的方法吗？

Answer 1

不可能在 Redis MQ 中处理同一条消息两次当消息 worker 从 Redis List 弹出消息时支持的 MQ 和所有 Redis 操作都是原子的，因此没有其他消息 worker 可以访问已从列表中删除的消息。

ServiceStack.Redis(Redis MQ 使用)只支持 Redis Sentinel for HA尽管 Redis 支持 multiple replicas它们仅包含主数据集的只读 View ，因此所有写入操作(如列表添加/删除操作)只能在单个主实例上发生。

与使用 Redis MQ 而不是像 Rabbit MQ 这样的特定用途 MQ 的一个显着区别是 Redis 不支持 ACK，因此如果从 MQ 弹出消息的消息工作进程崩溃，那么它的消息就会丢失，而不是Rabbit MQ，如果未确认消息的有状态连接终止，则 RabbitMQ 服务器将消息恢复回 MQ。