ScorpC的博客

RocketMQ 的 NameServer 虽然设计非常简洁，但很好地解决了路由寻址的问题。 而 Kafka 却采用了完全不同的设计思路，它选择使用 ZooKeeper 这样一个分布式协调服 务来实现和 RocketMQ 的 NameServer 差不多的功能。 先简单了解一下 ZooKeeper，然后再来一起学习一下 Kafka 是如何借助 ZooKeeper 来构建集群，实现路由寻址的。 一、Zookeeper的作用 Apache ZooKeeper 它是一个非常特殊的中间件，为什么这么说呢?一

消息队列在收发两端，主要是依靠业务代码，配合请求确认的机制，来保证消息不会丢失的。 而在服务端，一般采用持久化和复制的方式来保证不丢消息。 把消息复制到多个节点上，不仅可以解决丢消息的问题，还可以保证消息服务的高可用。即使某一个节点宕机了，还可以继续使用其他节点来收发消息。所以大部分生产系统，都会把消息队列配置成集群模式，并开启消息复制，来保证系统的高可用和数据可靠性。 接下来主要分析一下：消息复制需要解决的一些问题，以及 RocketMQ 和 Kafka 都是如何 应对这些问题来实现复制的。 目录：

上传一篇，之前看kafka Consumer源码做的笔记。 正文如下： kafka版本：2.2 首先，kafka消费模型的要点： Kafka 的每个 Consumer(消费者)实例属于一个 ConsumerGroup(消费组); 在消费时，ConsumerGroup 中的每个 Consumer 独占一个或多个 Partition(分 区); 对于每个 ConsumerGroup，在任意时刻，每个 Partition 至多有 1 个 Consumer 在消费; 每个 ConsumerG.