要开始使用Apache Kafka®并不难。学习资源在互联网上随处可见，尤其是在Confluent开发者网站上。如果你是Kafka的新手，我推荐你从Kafka 101课程开始。但如果你对Kafka真的很认真，你可能想深入了解一下：它是如何在节点之间复制数据的，如果复制失败会怎样，消费者如何自动扩展但永远不会失去订购保证，以及Kafka的秘诀是什么？
Jun Rao的Kafka内部课程通过解释Kafka如何由内而外地工作，回答了所有这些问题，以及更多的问题。还有谁能比卡夫卡最初的共同创造者之一更适合做这件事呢？从最初的几行代码到今天的大名鼎鼎的KIPs，他在这项技术中发挥了关键作用。
基础知识
本课程以回顾Kafka的基本原理开始。如果你已经对基础知识很熟悉了，你可能会想跳过这一节，但从该框架的原始创建者之一那里了解Kafka的概况是很独特的。Jun的经验和见解使这个模块远远超过了Kafka 101的回顾。
Apache Kafka代理内部
当我们向Kafka生产事件时，它只是被附加到主题上，而当我们消费事件时，我们只是在下一个偏移处检索事件，对吗？嗯，是的，但是比起这个描述，还有很多事情要做。Jun将带领我们进入代理机构，解释每个生产或获取请求的过程。
我们将看看那些以快速、有效和有弹性的方式处理请求的移动部件。我们将了解Kafka中数据的物理存储，以及它是如何影响这个过程的。
这种对Kafka代理机内部的观察不仅仅是有趣的，它还为我们提供了对我们每天在使用Apache Kafka时的一些配置的洞察力。
数据平面。复制协议
复制是Kafka代理的最重要的功能之一，而且它处理得很好。事实上，它处理得非常好，以至于我们除了设置主题的复制因子外，常常不怎么考虑它。但是，当你考虑到我们是多么依赖复制来提供我们所期望的Kafka的持久性和高可用性时，可能就需要对它的工作原理有更深入的了解。
在这个模块中，Jun给我们提供了详细的解释和图解示例。他涵盖了分区领导者和追随者的角色、同步副本列表、领导者纪元、高水印等等。
Apache Kafka的控制平面
我们都听说了在KIP-500中首次宣布的ZooKeeper移除，现在在这个模块中，我们将近距离观察ZooKeeper的替代品KRaft。我们将看到KRaft的一些优点，如改进的可扩展性和更有效的元数据传播。然后我们将通过一些KRaft元数据复制和调和的逐步例子，以及如何从可用的选民中选出活动控制器。
消费者组协议
消费者组是一个几乎神奇的组件，它允许我们轻松安全地扩大或缩小Kafka消费者应用程序。巫师幕后的技术就是消费者组协议。在这个模块中，Jun给我们彻底解释了消费者组协议的工作原理。他将介绍组协调人、组成员、分区分配策略，以及它们如何影响再平衡过程。
我们还将学习组协调器的故障转移、组的初始化和分区偏移跟踪。我们甚至会看到不同的分区分配策略的详细例子，包括惊人的CooperativeStickyAssignor 。当所有的事情都完成后，你可能仍然会怀疑这是否真的是魔术。
自己试一试吧
通过这个实践练习，你可以亲眼看到消费者组协议的力量。
配置耐久性、可用性和排序保证
Apache Kafka以其强大的耐久性、可用性和排序保证而闻名，但它是如何实现这些的，我们又该如何利用它们呢？在这个模块中，Jun会告诉我们一些关键的配置，比如acks 和min.insync.replicas ，以及它们如何影响耐久性和可用性。我们还将了解到这些配置中固有的一些权衡因素。
最后，我们将讨论Idempotent Producer和消息密钥是如何提供强大的订购保证的，足以让人放心。
交易
在事件流系统中，多个事件需要被处理以完成一个工作单元，交易是必不可少的。而Kafka的事务性生产者和Kafka Stream的精确一次语义（EOS）都在工作中。在这个模块中，我们将看到非事务性流处理系统中的故障如何导致数据损坏或更糟。然后，我们将看到事务如何保护我们免受这种情况的影响。
由于Kafka主题是一个不可改变的事件附加记录，我们不能像在关系型数据库中那样直接回滚。因此，我们将看到Kafka如何使用一种策略，在日志中添加中止或提交标记，同时设置消费者isolation.level=read_committed ，以提供我们需要的保护。
主题压实
主题压缩是Kafka默认的基于时间的保留的一个替代方案。在压缩的主题中，我们的目标是为每个键提供最新的值。在这个模块中，我们将了解压缩主题的用例和限制，然后Jun将带我们深入了解主题压缩的过程。我们将看到压缩过程在段级是如何工作的，以及何时触发压缩。我们还将了解处理墓碑和事务（中止/提交）标记的特殊方式，以使我们的应用程序有时间来处理这些重要的工件。
一个被压缩的主题保证有一个键的最新值，但有时它也会有较早的值。在经历了这个模块后，你会明白为什么。
分层存储
虽然一直以来都可以在Kafka中长期保存数据，但分层存储让它变得更加实惠。通过将旧的数据转移到对象存储中，比如亚马逊的S3，分层存储大大减少了我们在经纪人上需要的昂贵的本地存储。请加入Jun的讨论，了解分层存储的好处以及它是如何工作的。
虽然分层存储将通过KIP-405进入Apache Kafka，但在这个模块中，我们将看到我们如何在今天用Confluent来使用它。
集群弹性
Kafka集群可以根据需要通过添加和删除经纪人节点来扩大或缩小规模，但伴随着这种能力，需要在经纪人之间重新平衡数据。在这个模块中，我们将看看一些不同的工具，我们可以用它们来保持我们的集群处于平衡状态。从Apache Kafka自带的kafka-reassign-partitions.sh shell脚本，到Confluent的全功能自平衡集群，我们将看看这些工具是如何工作的，以及一些需要考虑的优点和缺点。
地理复制
为了实现我们的高可用性和灾难恢复目标，我们经常需要在一个以上的数据中心或云区域进行操作。这就带来了对地理复制的需求。幸运的是，与集群数据平衡一样，我们有多种解决方案来应对这一挑战。在本模块中，Jun将带领我们了解以下在多个地点操作Kafka集群的工具。
- Confluent多区域集群
- Kafka MirrorMaker 2
- Confluent Replicator
- Confluent集群链接
我们将了解这些工具各自的工作原理以及它们的优缺点。你仍然需要做一些工作来确定适合你情况的最佳选择，但知道我们有这些工具可用，不是很好吗？
自己试一试
在这个实践练习中尝试使用集群连接的地理复制。
接下来的步骤
如果你准备更深入地了解Kafka的内部结构，请查看下面的资源。
- 查看Confluent Developer上完整的Kafka内部课程
- 对我们即将举行的聚会进行RSVP
在做了28年的开发者、架构师、项目经理（已恢复）、作家、培训师、会议组织者和家庭教育的父亲之后，Dave Klein在Confluent找到了他梦想的工作--开发者倡导者。Dave对Apache Kafka事件流的神奇世界感到惊叹，并渴望帮助其他人探索这个世界。
