为什么kafka和zk总是在一起？

一.概念

发布订阅，一个发布者发布到消息，所有订阅者都可以接收到

生产消费，一个消息对象只能被一个消费者消费

kafka是生产者，zookeeper是消费者

有3个微服务，聚合形成一个统一的业务层

但是每个微服务都需要互相知道对方的服务地址。这样每个微服务地址修改，其他微服务的配置文件都需要修改，这样就是耦合的。

解耦就是服务注册中心，统一管理所有的微服务信息

每个微服务调用接口，统一从服务注册中心获取，这样每个微服务地址修改，只需要向注册中心报备，其他微服务什么都不用改，这样就是解耦的。

那么有个角色就是“服务注册中心”，这个可以用 Zookeeper、Eureka、Consul 作为实现方案

二.例子

zk是用于消息列队的，分布式，调节各个程序之间的通信和操作

例如一个网站 注册分几部

1.用户点击注册，网站发请求到后端服务器

2.后端服务器收到后，给用户发个邮件

3.用户点击邮件进行验证，证明是他本人

4.将这个用户添加到数据中

这一套下来用户才算注册了，才能正常登陆，但有几个问题：

1.用户如果当前不方便验证邮件，那就没法注册了，显然不合理

2.当这个程序的数据库地址变动了，就需要在代码里修改，让程序知道最新的数据库地址，这样会很麻烦

3.这显然不合理

就引出了消息列队的作用 就是异步操作 程序收到请求 直接跳过2和3 先写到数据库 让用户可以登录 后面再发邮件 这是异步的 异步就是消息列队

也就是用户可以登录后 过段时间在验证邮件 不然超过24小时或者一些时间 不验证就禁止登录 如此

那就需要多个程序来完成这个任务 就是分布式 A程序负责接收请求 写到数据库 B程序负责发邮件 验证邮件，如果超时不验证 告诉A程序禁止账号

那你可以选择搞一个C程序 协调这2 一个注册请求进来 调用A注册 再调用B进行发邮件啥的

zk就是这个C程序 他将请求进行拆分 放到一个箱子里 箱子1号位置是用户1的注册请求，2号位置是用户3的邮件请求， zk依次将这些请求发到对应的小程序里

因为是异步的 所以不着急 就好像同时3用户注册 用户A点击注册了，可能10分钟后验证邮件才发过来

kafka是一个篮子 将这些请求装进去 然后依次交给zk zk将注册请求给A程序，验证请求给B程序

如果请求太多 篮子放不下 就堵塞了 就需要加kafka， 如果zk解决不过来了 那又堵塞了 就要加zk

kafka是生产者 他储存请求 zk是消费者 对请求进行处理

zk也是冗余作用的 比如A程序可以有10个 他做负载均衡 也做备份 当A1程序挂了 就把请求给A2

zk是中转站 他将各种请求异步的给各种其它程序 但要求是异步的请求

如果是比较严格的 例如打钱给别人 多个程序验证 就得同步 异步会出问题

Pro push消息到broker里面，然后会记录一个信息，（类似存储位置），给zk记录起来，然后consum消费时候先去zk里问他要数据存储的节点和位置。

取到信息返回，zk在这里面起到通讯作用，broker是kafka的存储，zk执行事物时候一般先把消息给leader，然后leader去推送，comsuer取消息时候是pull。