kafka消息 Broker节点分配 测试

我们的kafaka的节点 Broker默认都是 多副本的

测试方法：

1、我们配置了 Broke的默认分配次序

2、在 web后台页面中做对应的 操作

3、检查 当前的消息日志是 落在 哪个Broke节点服务器

4、停掉当前落在的 Broke节点 服务器，可以shutdown  或 init 0

5、重新在web后台操作对应的消息推送功能

6、检查 当前 消息日志落在 哪个服务器节点

1）kafaka-broker-api-version.sh    --bootstrap-server    Broker节点服务器IP地址

2）或者直接通过 消费者日志查看 消费是在落在哪台服务器节点上。

由于 主Broke已经停机，必然会落在其他的 Broke服务器节点上。

 

 kafakag工作模式：

我们将消息的发布（publish）称作 producer，将消息的订阅（subscribe）表述为 consumer，将中间的存储阵列称作 broker(代理)，这样就可以大致描绘出这样一个场面：

生产者将数据生产出来，交给 broker 进行存储，消费者需要消费数据了，就从broker中去拿出数据来，然后完成一系列对数据的处理操作。

多个 broker 协同合作，producer 和 consumer 部署在各个业务逻辑中被频繁的调用，三者通过 zookeeper管理协调请求和转发。这样一个高性能的分布式消息发布订阅系统就完成了。

举个例子： 报社生存报纸，个人要订阅报纸，然后订阅报纸通过邮递或者 快递公司 把报纸 传递到 个人手上，当快递公司歇业或没有多余时间时，就把 报纸给到邮递 让邮递 来 发送到个人手上，这里就有一个 协调的服务 可以看作是 zookeeper。