极简单系列-kafka 基本原理

简单来说 这就是今天的全部内容了。
生产者 生产消息到 集群，集群存储消息，消费者消费

---

具体要谈里边的原理 需要先了解几个概念

topic

Topic可以理解为一个队列，生产者和消费者面向的都是一个 topic

Partition

分区。这是一个物理概念。一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；
为了实现扩展性，一个非常大的 topic 可以分布到多个 服务器上，

也就是我发送多条消息 ，这些消息可能会实际落到不同的分区上存储。消息1 存到了分区1 上 消息2 存到了消息2上

---

Broker

一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。

Replica

分区的副本数，为保证集群中的某个节点发生故障时，该节点上的 分区 数据不丢失 做的备份。
图里 这个 topic 的 replica 是3 也就是每个分区 会有3份相同的数据。

但是这三份相同的数据 只会有一个对外，对外的叫leader，其他的叫follower 。生产者只发送数据到leader， 消费者只从follower 消费数据。Follower实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 leader

---

消费端这边可以有 单个消费者 和 消费者组。
这也很好理解。一个消费者 速度有上限，可以多个消费者在一个组里 共同去消费同一个topic 。消费者组之间的消费互不影响

---

架构图

这是kafka 整体的流程图

这里 集群里有两个broker， Topic A 有两个 分区。每个分区副本数是2 分区0的leader 在 broker1 上，分区1 的leader 在 broker2 上。

生产者 生产了topicA 的两个消息 ，这两个消息落到了不同的分区。Follower 从leader 同步数据

一个消费者组里有两个消费者 ，每个消费者分别消费指定的分区。同时 zk 里保存这些 节点的存活信息等。通过watch 同步给集群的管理者

这样设计的好处有两个

1是假如当前某个服务挂断了 只要这个服务上的leader 在其他服务上还有副本 就可以变成leader 继续提供服务

2是如果某个 topic 过大 。可以创建多个分区 存储在多个服务器上

---

对比下rabitMq 镜像模式

每个节点上都有这个queue的一个完整镜像，就是包含了这个queue的全部数据的意思，所以这种集群模式叫做镜像集群模式。
任何一个节点宕机了，也不会出现问题，其他节点上海包含了这个queue的完整数据。别的consumer都可以到其他的节点上去消费数据。

但是它不是分布式的，如果一个队列的数据量很大，大道这个机器上的容量无法容纳了，此时还能怎么办呢？束手无策了就。

对比kafka的优势也就很明显了。