水

感谢，已经更新。

感谢，已经更新。

大多数消息系统保持哪些消息在broker已经消耗的元数据，即，当一个消息被分发给消费者时，broker直接记录或者它也可以等待来自消费者的确认。很多消息系统用于存储的规模有限，这也是务实的选择 - - 因为broker知道已经被消耗的可以立刻删除，保持存储的数据大小。大多数消息系统保留在broker上消费消息的元数据。 也就是说，当消息发送给消费者时，broker本地立即记录该事实，或者可以等待消费者的应答确认。 这是一个相当直观的选择，实际上对于单个机器服务器来说，尚不清楚这个状态是什么。 由于许多消息系统中用于存储的数据结构规模不大，这也是务实的选择 - 因为broker知道哪些已经消费，可以立即删除它，从而保持数据大小不变。

这块重复了

你可以想一些其他的可能性的设计，不仅仅是pull，端对端。生产者在本地写入本地日志，broker从那里pull，消费者再pull，我们经常推荐的类似一种“存储-转发”的生产者，这种方式很有意思，但是我们觉得不是很适合我们这种有成千上万的生产者的情况，我们的大规模运行的持久化数据系统的经验使我们觉得，在许多应用领域涉及数以千计的系统磁盘不会真的使事情变得更加可靠，将是操作的噩梦。而在实践中我们发现，我们可以运行与大型强大的销售管道，而不需要生产的持久性。你也可以想一些其他的可能性的设计，不仅仅是pull，端对端。生产者在本地写入本地日志，broker从那里pull，消费者再从broker那里pull，类似一种“存储-转发”的生产者，这种方式很有意思，但是我们觉得不是很适合我们这种有成千上万的生产者的情况，我们的大规模运行的持久化数据系统的经验使我们觉得，在许多应用领域涉及数以千计的系统磁盘不会真的使事情变得更加可靠，将是操作的噩梦。而在实践中我们发现，我们可以大规模运行具有强大的SLA管道，

翻译重复了

您好，我想问一下，那个在 kafka_server_jaas.conf 中 您只配置了 zk的client端，请问一下zk的server端需要配置吗，需要的话一般在哪里配置.....叨扰了