共计 1497 个字符，预计需要花费 4 分钟才能阅读完成。
Kafka 是支流的音讯流零碎，其中的概念还是比拟多的，上面通过图示的形式来梳理一下 Kafka 的外围概念，以便在咱们的头脑中有一个清晰的意识。
根底
Kafka (Kafka 是什么，次要利用在什么场景?) 是一套流解决零碎，能够让后端服务轻松的互相沟通，是微服务架构中罕用的组件。
生产者消费者
生产者服务 Producer 向 Kafka 发送音讯，消费者服务 Consumer 监听 Kafka 接管音讯。
一个服务能够同时为生产者和消费者。
Topics 主题
Topic 是生产者发送音讯的指标地址，是消费者的监听指标。
一个服务能够监听、发送多个 Topics。
Kafka 中有一个【consumer-group（消费者组）】的概念。
这是一组服务，表演一个消费者。
如果是消费者组接管音讯，Kafka 会把一条音讯路由到组中的某一个服务。
这样有助于音讯的负载平衡，也不便扩大消费者。
Topic 表演一个音讯的队列。
首先，一条音讯发送了。
而后，这条音讯被记录和存储在这个队列中，不容许被批改。
接下来，音讯会被发送给此 Topic 的消费者。
然而，这条音讯并不会被删除，会持续保留在队列中。
持续发送音讯。
像之前一样，这条音讯会发送给消费者、不容许被改变、始终呆在队列中。
（音讯在队列中能呆多久，能够批改 Kafka 的配置）
Partitions 分区
下面 Topic 的形容中，把 Topic 看做了一个队列，实际上，一个 Topic 是由多个队列组成的，被称为【Partition（分区）】。
这样能够便于 Topic 的扩大。
生产者发送音讯的时候，这条音讯会被路由到此 Topic 中的某一个 Partition。
消费者监听的是所有分区。
生产者发送音讯时，默认是面向 Topic 的，由 Topic 决定放在哪个 Partition，默认应用轮询策略。
也能够配置 Topic，让同类型的音讯都在同一个 Partition。
例如，解决用户音讯，能够让某一个用户所有音讯都在一个 Partition。
例如，用户 1 发送了 3 条音讯：A、B、C，默认状况下，这 3 条音讯是在不同的 Partition 中（如 P1、P2、P3）。
在配置之后，能够确保用户 1 的所有音讯都发到同一个分区中（如 P1）。
这个性能有什么用呢？
这是为了提供音讯的【有序性】。
音讯在不同的 Partition 是不能保障有序的，只有一个 Partition 内的音讯是有序的。
架构
Kafka 是集群架构的，ZooKeeper 是重要组件 (不过在 2.8 版本之后就抛弃了 Zookeeper：再见 ZooKeeper！)。
ZooKeeper 管理者所有的 Topic 和 Partition。
Topic 和 Partition 存储在 Node 物理节点中，ZooKeeper 负责保护这些 Node。
例如，有 2 个 Topic，各自有 2 个 Partition。
这是逻辑上的模式，但在 Kafka 集群中的理论存储可能是这样的：
Topic A 的 Partition #1 有 3 份，散布在各个 Node 上。
这样能够减少 Kafka 的可靠性和零碎弹性。
3 个 Partition #1 中，ZooKeeper 会指定一个 Leader，负责接管生产者发来的音讯。
其余 2 个 Partition #1 会作为 Follower，Leader 接管到的音讯会复制给 Follower。
这样，每个 Partition 都含有了全量音讯数据。
即便某个 Node 节点呈现了故障，也不必放心音讯的损坏。
Topic A 和 Topic B 的所有 Partition 散布可能就是这样的：
感激浏览，心愿对你有所帮忙 😃
翻译整顿自：https://timothystepro.medium….
转自：https://blog.csdn.net/duysh/a…
