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

Question

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

这将是巨大的，如果有人可以澄清这些概念： -

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

我将生产性服务，这将创建消息，并加入到MQ。消费者将使用此消息并执行相应的操作。一旦消费者ACK完成消息处理， MQ会将偏移量移至下一个偏移量。我不希望我的邮件被错过，所以我必须确保邮件成功使用。此外，我试图让这个系统消耗一次消息（尝试尽可能接近）。

现在我基于这样的认识以下几个问题： -

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

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

编辑：我打算在系统中使用Java，Zookeeper，Kafka，Cassandra。

Answer 1

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

您是否瞄准一次交货，因为两次做同样的工作是浪费时间，或者是因为如果您两次做同样的事情，所有东西都燃烧到地面上，这会造成浪费？

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

如果是后者，那么设计这个系统的时间会更加困难。您需要能够判断某个进程是否崩溃，或者是否比平时耗时更长。您还需要继续留下它，可能再次从事这项工作。如果更新类似增加10个不同的计数器，则再次执行更新可能会使计数器增加一倍。