Apache Kafka 2.8不依赖ZooKeeper就能运行
问题导读
1.Kafka不使用zookeeper带来哪方面的提升？
2.KRaft作用是什么？
3.Quorum控制器作用什么？
分布式发布与订阅系统Apache Kafka在即将发布的2.8版本，使用Kafka内部的仲裁（Quorum）控制器来取代ZooKeeper，因此用户第一次可在完全不需要ZooKeeper的情况下执行Kafka，这不只节省计算资源，并且也使得Kafka性能更好，还可支持规模更大的集群。
过去Apache ZooKeeper是Kafka这类分布式系统的关键，因为ZooKeeper管理元资料，存储着资料分割的位置，以及主要副本等信息，ZooKeeper扮演协调代理的角色，所有代理服务器启动时，都会连接到Zookeeper进行注册，当代理状态发生变化时，Zookeeper也会存储这些资料，在过去，ZooKeeper是一个强大的工具，但是毕竟ZooKeeper是一个独立的软件，使得Kafka整个系统变得复杂，因此官方决定使用内部仲裁控制器来取代ZooKeeper。
这项工作从去年4月开始，而现在这项工作取得部分成果，用户将可以在2.8版本，在没有ZooKeeper的情况下执行Kafka，官方称这项功能为Kafka Raft元资料模式（KRaft）。在KRaft模式，过去由Kafka控制器和ZooKeeper所操作的元资料，将整合到这个新的Quorum控制器，并且在Kafka集群内部执行，当然，如果用户有特殊使用场景，Quorum控制器也可以在专用的硬件上执行。
在Kafka内部执行的Quorum控制器，会使用新的KRaft协议来确保仲裁间能精确地复制元资料副本，并使用事件来源存储模型来存储状态，以确保内部状态机可以精确地被重新创建，官方提到，KRaft协议具有的事件驱动特性，和基于ZooKeeper控制器不同，不会在启动之前从ZooKeeper加载装态，当领导节点变更的时候，新激活的控制器内存早已记录所有提交的元资料。
另外，KRaft协议使用事件驱动机制来关注整个集群的元资料，过去必须依赖RPC来处理的任务，现在受益于事件驱动以及实际的日志传输，这些改变所带来的好处，便是让Kafka仍够支持更多的分割。
新的仲裁控制器是专门设计在单个集群中，处理大量的分割，在过去的实例中，受限于重要的元资料，必需要在外部共识机制ZooKeeper，以及内部领导控制器Kafka间移动，Kafka仅能达到20万个分割，而在新的仲裁控制器中，过去外部共识与领导管理的角色，都由同一个组件扮演，因此现在于单个集群中，分割数可以达到过去10倍，约是2百万个分割。
过去Kafka因为带着ZooKeeper，因此被认为拥有沉重的基础设施，而在移除ZooKeeper之后，Kafka更轻巧更适用于小规模工作负载，轻量级单体程序适合用于边缘以及轻量级硬件解决方案。
值得注意的是，在抢先体验版中，有部分像是ACL、安全以及交易等功能都尚未支持，而且在KRaft模式下，也还不支持重新分配分割和JBOD，官方提到，这些功能会在今年稍晚的版本中提供，而且因为仲裁控制器还在实验阶段，也不建议将其用于生产环境中。
最新经典文章，欢迎关注公众号http://www.aboutyun.com/data/attachment/forum/201903/18/215536lzpn7n3u7m7u90vm.jpg
原文链接
https://mp.weixin.qq.com/s/UaG0ORe95PuQi5Kb-H7Wtg
从 offset 提交到 Zookeeper
到 offset 提交到 Topic
到 支持事务 完成 End-to-End Exactly-Once
到 支持简单 ETL 处理
到 不依赖 Zookeeper 完成 HA
看来 Kafka 在未来可能还要取代 计算引擎了 (jset 提交到 Zookeeper
到 offset 提交到 Topic
到 支持事务 完成 End-to-End Exactly-Once
到 支持简单 ETL 处理
到 不依赖 Zookeeper 完成 HA
看来 Kafka 在未来可能还要取代 计算引擎了 (感觉局限于 scala 也不一定哈哈哈)
页:
[1]