使用消息队列和协调服务设计系统

Question

我是设计系统的新手，对消息队列和协调服务（zookeeper）有一些疑问。

如果有人能澄清这些概念，那就太好了：-

我对正在设计的系统中的 MQ 的理解：-

我将拥有生产者服务，它将创建消息并添加到 MQ。消费者将使用此消息并执行适当的操作。一旦消费者 ACK 的消息处理完成； MQ 会将偏移量移动到下一个。我不希望我的消息被错过，所以我必须确保消息被成功使用。我也试图让这个系统只使用一次消息（尽可能接近）。

基于这种理解，现在我有以下问题：-

1)如果我希望我的生产者和消费者在同一个 DC 中运行多个实例（以实现高可用性），那么我是否需要将生产者和消费者都作为单独的 Zookeeper 服务？我所有不同的服务（在微服务世界中）是否需要单独的 zookeeper 服务器/实例或同一个实例可以解决这个问题？

2) 当消息被消费者消费时，它会在消费后确认 MQ（完成处理并采取任何需要的操作。）。我试图了解对于每秒将有数千个请求的系统来说，这将如何更快。如果我们阅读更多消息或不等待 ACK 直到处理，那么在消费者失败的情况下，这些消息将被遗漏，因为它们从未成功处理过。我知道拥有更多消费者会使它并行工作，但不清楚这个概念是如何工作的。有人可以向我解释一下什么是正确的消费和配置组件之间的交互方式，以使其优化、持久、高可用性、可靠并且接近一次模型。

编辑：我计划在系统中使用 Java、Zookeeper、Kafka、Cassandra。

Answer 1

消息队列可以像任何消息传递系统一样以两种基本模式工作：至少一次传递，或最多一次传递。两者都争取只交付一次，但我们在这里讨论的是边缘情况。你将不得不选择其中之一。如果你所有的生产者和消费者之间的通信（包括生产者-生产者和消费者-消费者）都经过消息队列，那么只有消息队列需要一个zookeeper集群。通过单个系统集中所有消息传递是这样做的首选方式。

您的目标是只交付一次，因为重复执行相同的工作很浪费，或者如果您执行两次相同的工作，一切都会被烧毁？

如果是前者，构建一些简单的东西。消息队列本身可以跟踪这一点，因为一旦他们中的一个回复结果，它将停止要求新消费者使用任务，或者，如果存储必须更持久，使用 redis 或 couchbase 或cassandra 或一些简单的键/值存储来存储成功完成的事情。在内存中记下您已发出但尚未收到答复的请求。在数据库中存储“此操作已完成”注释。

如果是后者，您将很难设计这个系统。您需要能够判断一个进程是否崩溃，或者它是否比平时花费了更长的时间。你还需要从它离开的地方继续，可能重新做一遍工作。如果更新类似于增加十个不同的计数器，那么再次执行更新可能会使某些计数器增加两次。