Kafka 入门
消费者与生产者
Kafka是一个消息队列，把消息放到队列里边的叫生产者，从队列里边消费的叫消费者。
topic 与 partition
- 一个消息中间件，队列不单单只有一个，我们往往会有多个队列，而我们生产者和消费者就得知道：把数据丢给哪个队列，从哪个队列消息。我们需要给队列取名字，叫做topic(相当于数据库里边表的概念)
- 现在我们给队列取了名字以后，生产者就知道往哪个队列丢数据了，消费者也知道往哪个队列拿数据了。我们可以有多个生产者往同一个队列(topic)丢数据，多个消费者往同一个队列(topic)拿数据
- 为了提高一个队列(topic)的吞吐量，Kafka会把topic进行分区(Partition)
- 所以生产者实际上是往一个topic名为Java3y中的分区(Partition)丢数据，消费者实际上是往一个topic名为Java3y的分区(Partition)取数据
- 一台Kafka服务器叫做 Broker，Kafka 集群就是多台 Kafka 服务器：
- 一个 topic 会分为多个 partition，实际上 partition 会分布在不同的broker中，举个例子：
由此得知：Kafka是天然分布式的。
Kafka 集群实现的高可用
由于数据存在多个partition中，为了达到高可用，因此需要使用备份分区。
- 我们数据存在不同的partition上，那 Kafka 就把这些partition做备份。比如，现在我们有三个partition，分别存在三台broker上。每个partition都会备份，这些备份散落在不同的broker上。
红色块的 partition 代表的是主分区，紫色的 partition 块代表的是备份分区。生产者往topic丢数据，是与主分区交互，消费者消费topic的数据，也是与主分区交互。 - 备份分区仅仅用作于备份，不做读写。如果某个 Broker 挂了，那就会选举出其他 Broker 的 partition 来作为主分区，这就实现了高可用。
Kafka 的持久化
当生产者把数据丢进 topic 时，我们知道是写在 partition 上的，那 partition 是怎么将其持久化的呢
- Kafka是将partition的数据写在磁盘的(消息日志)，不过 Kafka 只允许追加写入(顺序访问)，避免缓慢的随机 I/O 操作。
- Kafka 也不是 partition 一有数据就立马将数据写到磁盘上，它会先缓存一部分，等到足够多数据量或等待一定的时间再批量写入(flush)。
消费者组
消费者组（Consumer Group）是由一个或多个消费者实例（Consumer Instance）组成的群组，具有可扩展性和可容错性的一种机制。可以理解而为对消息信息进行分流
- 消费者组内的消费者共享一个消费者组ID，这个ID 也叫做 Group ID，组内的消费者共同对一个topic进行订阅和消费，同一个组中的消费者只能消费一个分区的消息，多余的消费者会闲置，派不上用场。
我们在上面提到了两种消费方式
- 一个消费者群组消费一个主题中的消息，这种消费模式又称为点对点的消费方式，点对点的消费方式又被称为消息队列
- 一个主题中的消息被多个消费者群组共同消费，这种消费模式又称为发布-订阅模式
- 如上图所示，某个主题中共有4个分区（Partition）：P0、P1、P2、P3。
- 有两个消费组A和B都订阅了这个主题，消费组A中有4个消费者（C0、C1、C2和C3），消费组B中有2个消费者（C4和C5）。
- 按照 Kafka 默认的规则，最后的分配结果是消费组A中的每一个消费者分配到1个分区，消费组B中的每一个消费者分配到2个分区，
- 两个消费组之间互不影响。每个消费者只能消费所分配到的分区中的消息。 换言之，每一个分区只能被一个消费组中的一个消费者所消费。
- 我们再来看一下消费组内的消费者个数变化时所对应的分区分配的演变。
- 假设目前某消费组内只有一个消费者C0，订阅了一个主题，这个主题包含7个分区：P0、P1、P2、P3、P4、P5、P6。也就是说，这个消费者C0订阅了7个分区。
消费者的重平衡
发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题（Topic），主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，而消息订阅者从主题中订阅消息。主题使得消息的订阅者和发布者互相保持独立，不需要进行接触即可保证消息的传递，发布/订阅模式在消息的一对多广播时采用。Kafka 同时支持两种消息投递模式，而这正是得益于消费者与消费组模型的契合：
- 如果所有的消费者都隶属于同一个消费组，那么所有的消息都会被均衡地投递给每一个消费者，即每条消息只会被一个消费者处理，这就相当于点对点模式的应用。
- 如果所有的消费者都隶属于不同的消费组，那么所有的消息都会被广播给所有的消费者，即每条消息都会被所有的消费者处理，这就相当于发布/订阅模式的应用。
这相当于一个分布式的过程，即每个消费者处理的数据相同。原来一个消费者处理10000条数据,现在有100 个消费者，那么每个消费者只需要处理100条数据即可
消费者的读操作
正常的读磁盘数据是需要将内核态数据拷贝到用户态的，而 Kafka 通过调用 sendfile() 直接从内核空间（DMA的）到内核空间（Socket的），少做了一步拷贝的操作。如下所示：
Kafka的回溯操作：
- 如果一个消费者组中的某个消费者挂了，那挂掉的消费者所消费的分区可能就由存活的消费者消费。那存活的消费者是需要知道挂掉的消费者消费到哪了，此时会出现一个
offset用来表示消费者的消费进度。 - 在以前版本的Kafka，这个offset是由Zookeeper来管理的，后来Kafka开发者认为Zookeeper不合适大量的删改操作，于是把offset在broker以内部topic(__consumer_offsets)的方式来保存起来。
- 每次消费者消费的时候，都会提交这个offset，Kafka可以让你选择是自动提交还是手动提交。
Zookeeper 在 kafka 中的作用
- 探测 broker 和 consumer 的添加或移除。
- 负责维护所有 partition 的领导者/从属者关系（主分区和备份分区），如果主分区挂了，需要选举出备份分区作为主分区。
- 维护topic、partition等元配置信息
