本文目录
Kafka为什么要抛弃ZooKeeper
ZooKeeper 的作用 ZooKeeper 是一个开源的分布式协调服务框架，你也可以认为它是一个可以保证一致性的分布式(小量)存储系统。特别适合存储一些公共的配置信息、集群的一些元数据等等。 它有持久节点和临时节点，而临时节点这个玩意再配合 Watcher 机制就很有用。 当创建临时节点的客户端与 ZooKeeper 断连之后，这个临时节点就会消失，并且订阅了节点状态变更的客户端会收到这个节点状态变更的通知。 所以集群中某一服务上线或者下线，都可以被检测到。因此可以用来实现服务发现，也可以实现故障转移的监听机制。 Kafka 就是强依赖于 ZooKeeper，没有 ZooKeeper 的话 Kafka 都无法运行。ZooKeeper 为 Kafka 提供了元数据的管理，例如一些 Broker 的信息、主题数据、分区数据等等。 在每个 Broker 启动的时候，都会和 ZooKeeper 进行交互，这样 ZooKeeper 就存储了集群中所有的主题、配置、副本等信息。 还有一些选举、扩容等机制也都依赖 ZooKeeper 。 例如控制器的选举：每个 Broker 启动都会尝试在 ZooKeeper 注册/controller临时节点来竞选控制器，第一个创建/controller节点的 Broker 会被指定为控制器。 竞争失败的节点也会依赖 watcher 机制，监听这个节点，如果控制器宕机了，那么其它 Broker 会继续来争抢，实现控制器的 failover。 从上面就可以得知 ZooKeeper 对 Kafka 来说很重要。 那为什么要抛弃 ZooKeeper 软件架构都是演进的，之所以要变更那肯定是因为出现了瓶颈。 先来看看运维的层面的问题。 首先身为一个中间件，需要依赖另一个中间件，这就感觉有点奇怪。 你要说依赖 Netty 这种，那肯定是没问题的。但是 Kafka 的运行需要提供 ZooKeeper 集群，这其实有点怪怪的。 就等于如果你公司要上 Kafka 就得跟着上 ZooKeeper ，被动了增加了运维的复杂度。 好比你去商场买衣服，要买个上衣，服务员说不单卖，要买就得买一套，这钱是不是多花了？ 所以运维人员不仅得照顾 Kafka 集群，还得照顾 ZooKeeper 集群。 再看性能层面的问题。 ZooKeeper 有个特点，强一致性。 如果 ZooKeeper 集群的某个节点的数据发生变更，则会通知其它 ZooKeeper 节点同时执行更新，就得等着大家（超过半数）都写完了才行，这写入的性能就比较差了。 然后看到上面我说的小量存储系统了吧，一般而言，ZooKeeper 只适用于存储一些简单的配置或者是集群的元数据，不是真正意义上的存储系统。 如果写入的数据量过大，ZooKeeper 的性能和稳定性就会下降，可能导致 Watch 的延时或丢失。 所以在 Kafka 集群比较大，分区数很多的时候，ZooKeeper 存储的元数据就会很多，性能就差了。 还有，ZooKeeper 也是分布式的，也需要选举，它的选举也不快，而且发生选举的那段时候是不提供服务的！ 基于 ZooKeeper 的性能问题 Kafka 之前就做了一些升级。 例如以前 Consumer 的位移数据是保存在 ZooKeeper 上的，所以当提交位移或者获取位移的时候都需要访问 ZooKeeper ，这量一大 ZooKeeper 就顶不住。 所以后面引入了位移主题（Topic 是 __consumer_offsets），将位移的提交和获取当做消息一样来处理，存储在日志中，避免了频繁访问 ZooKeeper 性能差的问题。 还有像一些类似乐字节这样的大公司，可能要支持百万分区级别，这目前的 Kafka 单集群架构下是无法支持稳定运行的，也就是目前单集群可以承载的分区数有限。 所以，Kafka 需要去 ZooKeeper 。 所以没了 Zookeeper 之后的 Kafka 的怎样的？ 没了 Zookeeper 的 Kafka 就把元数据存储到自己内部了，利用之前的 Log 存储机制来保存元数据。 就和上面说到的位移主题一样，会有一个元数据主题，元数据会像普通消息一样保存在 Log 中。 所以元数据和之前的位移一样，利用现有的消息存储机制稍加改造来实现了功能，完美！ 然后还搞了个 KRaft 来实现 Controller Quorum。 这个协议是基于 Raft 的，协议具体就不展开了，就理解为它能解决 Controller Leader 的选举，并且让所有节点达成共识。 在之前基于 Zookeeper 实现的单个 Controller 在分区数太大的时候还有个问题，故障转移太慢了。 当 Controller 变更的时候，需要重新加载所有的元数据到新的 Controller 身上，并且需要把这些元数据同步给集群内的所有 Broker。 而 Controller Quorum 中的 Leader 选举切换则很快，因为元数据都已经在 quorum 中同步了，也就是 quorum 的 Broker 都已经有全部了元数据，所以不需要重新加载元数据！ 并且其它 Broker 已经基于 Log 存储了一些元数据，所以只需要增量更新即可，不需要全量了。 这波改造下来就解决了之前元数据过多的问题，可以支持更多的分区！ 最后 可能看到这里有人会说，那为何一开始不这么实现？ 因为 ZooKeeper 是一个功能强大且经过验证的工具，在早期利用它来实现一些功能，多简单哟，都不需要自己实现。 要不是 ZooKeeper 的机制导致了这个瓶颈，也不可能会有这个改造的。 软件就是这样，没必要重复造轮子，合适就好。 PS：给大家推荐个特别牛的Kafka自学课程，B站：BV1Bf4y1W7B6
Linux版kafka&zookeeper启动方式
Linux版kafka启动方式 方法一： 在bin的上一级目录执行命令： 加守护进程启动 方法二： 在bin的上一级目录执行命令： 通过后台来启动 ZooKeeper服务命令: 在准备好相应的配置之后，可以直接通过zkServer.sh 这个脚本进行服务的相关操作
zookeeper在kafka作用
zookeeper在kafka作用如下：Kafka将元数据信息保存在Zookeeper中，但是发送给Topic本身的数据是不会发到Zk上的。kafka使用zookeeper来实现动态的集群扩展，不需要更改客户端（producer和consumer）的配置。broker会在zookeeper注册并保持相关的元数据（topic，partition信息等）更新。而客户端会在zookeeper上注册相关的watcher。一旦zookeeper发生变化，客户端能及时感知并作出相应调整。这样就保证了添加或去除broker时，各broker间仍能自动实现负载均衡。
你了解那些Kafka的核心概念吗
Kafka中的数据称为message，就类似于record和row。Message是以batches的形式写入Kafka，batch就是一组数据，他们被写入同一个topic和partition。 Message被写入topic，topic又被分成了partition。每个partition可以在不同的server上。 分批次写入消息是为了提高效率。 topic：主题，一个主题代表了一类消息，就像数据库中的表一样。 Partition：分区，一个主题有若干个分区，同一个主题的分区可以不分布在同一个机器上，单一主题中的分区有序，但是无法保证所有的分区有序。 Producer用来创造消息。默认情况下，producer不care往哪个partition中写，一个topic中message会被均匀的分配到partition中。通过message key，partitioner会生成这个key的hash并把message写到特定的partition中。 Consumer读取数据。一个consumer会subscribe到一个或多个topic下，并以message被produce的顺序读取。通过跟踪message offset，consumer记录哪些消息已经被消费过。每个message有一个独立的offset，对于每个partition，通过存储最后消费消息的offset在zookeeper或kafka中，consumer可以停止重启是不失去上次读取的位置。 Consumer组成了consumer group，group保证了每个partition只有一个成员进行消费。如果一个consumer失败，group中的consumer会rebalance partition。 一个kafka的server称为一个broker。一个partition在cluster中被归在一个broker下，这个broker被称为partition的leader。一个partition可以被assign到多个broker下，这样partition就会被复制。 Replica：副本，分为leader和follower，leader对外提供服务。 为什么要用kafka：多个生产者，多个消费者，磁盘存储，可拓展性高，高性能。 把partition从一个consumer分配到另一个consumer称为rebalance。Rebalance保证了consumer group的高可用和高拓展性。在rebalance过程中，consumer不消费消息。 offset：在partition中给message连续的id，用来识别每条消息。 Zookeeper的作用：在集群不同节点间建立coordination。同时，如果哪个节点失败，我们还可以通过zookeeper从之前committed offset中恢复因为zookeeper周期性的commit offset。如果kafka的cluster有什么更改，zookeeper会通知所有node这一更改比如增删broker或topic。 ISR：In-Sync Replicas, 是和leader同步的复制的分区，这些followers和leader有着相同的message。 QueueFullException：当producer以broker无法接受的速度发送消息是会出现，解决方案是增加broker的数量。 Retention Period: retention period 可以帮助保持所有published的消息并不在乎消息是否被消费。这些记录可以通过retention period的配置进行销毁来腾出一些空间。 多分区多副本的好处：kafka通过给topic指定多个分区分布在多个broker上，并发能力较好（负载均衡）。partition可以指定replica数，增加了消息存储的安全性，提高了容灾能力，不过也增加了存储空间。
kafka权限控制
***隐藏网址*** 请先在不配置任何身份验证的情况下启动Kafka Kafka中的SCRAM实现使用Zookeeper作为凭证(credential)存储。 可以使用 kafka-configs.sh 在Zookeeper中创建凭据。 对于启用的每个SCRAM机制，必须通过添加具有机制名称的配置来创建凭证。 必须在启动Kafka broker之前创建代理间通信的凭据。 可以动态创建和更新客户端凭证，并使用更新的凭证来验证新连接。 这里只演示,不操作 或者不修改 kafka-server-start.sh 脚本, 而是将下面的内容添加到 ~/.bashrc 再官方文档中写的是 这里其实没必要写成 SASL_SSL , 我们可以根据自己的需求选择SSL或PLAINTEXT, 我这里选择PLAINTEXT不加密明文传输, 省事, 性能也相对好一些 Kafka所有Broker 先使用kafka-console-producer 和 kafka-console-consumer 测试一下 可以看到admin用户无需配置ACL就可以生成消息 生产消息 可以看到报错了, 因为fanboshi用户还没有权限 其实也会报错的, 报错内容就不贴了 生产者 消费者 都没问题了 好像只能去zookeeper看? 尝试删除alice 去ZK查看 kafka ACL常用权限操作 创建topic 使用bin/kafka-topics.sh创建 注意工具bin/kafka-topics.sh访问的是zookeeper而不是kafka，即他是一个zookeeper client而不是一个kafka client，所以它的认证都是通过zookeeper完成的。 Case 1：如果zookeeper没有配置ACL激活： Case 2：如果zookeeper已经配置ACL激活： 命令还是前面的那个命令，但是必须提供java.security.auth.login.config指向jaas.conf文件。例如： 命令的配置可以直接修改jvm的启动脚本，或者设置在环境变量里： 这里配置的用户必须是zookeeper服务端已经配置运行可以访问的客户端用户。例如，下面的zookeeper服务端配置： 运行客户端为admin的用户作为zookeeper客户端连接访问。 查询topic 查询topic操作的ACL认证，同前面创建topic操作的认证一样，不细说，参考前面。 删除topic 删除topic操作的ACL认证，同前面创建topic操作的认证一样，不细说，参考前面。
