3 ，Kafka 工作流程分析，生产，保存，消费

一 ，producer 生产消息 ：

1 ，写入方式 ： 生产者写数据的过程 producer

1. producer ：生产者
2. push ：推
3. patition ：分区
4. broker ： kafka 的分机
5. 写过程 ：
   producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘 ( 顺序写磁盘效率比随机写性能要高，保障 kafka 吞吐率 ) 。
6. 总结 ： 每条消息，都按照时间顺序，依次写入分区。

2 ，分区 ，理论 ： partition

1. 理论 ： 消息发送时都被发送到一个 topic ，其本质就是一个目录，而 topic 是由一些 Partition Logs ( 分区日志 ) 组成。
2. 分区的原因 ： 扩展容量，高并发
   1 ，方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
   2 ，可以提高并发，因为可以以Partition为单位读写了。
3. 分区的原则 ：我这个数据属于哪个分区 ？
   1 ，指定了patition，则直接使用；
   2 ，未指定 patition 但指定 key，通过对 key 的 value 进行 hash 出一个 patition
   3 ，patition 和 key 都未指定，使用轮询选出一个 patition。

3 ，分区 ，架构图 ：partition

解释 ： 我们可以看到，每个 Partition 中的消息都是有序的，生产的消息被不断追加到 Partition log上，其中的每一个消息都被赋予了一个唯一的 offset 值。

4 ，副本 ：Replication

1. 官方解释 ：同一个partition可能会有多个replication（对应 server.properties 配置中的 default.replication.factor=N）。没有replication的情况下，一旦broker 宕机，其上所有 patition 的数据都不可被消费，同时producer也不能再将数据存于其上的patition。引入replication之后，同一个partition可能会有多个replication，而这时需要在这些replication之间选出一个leader，producer和consumer只与这个leader交互，其它replication作为follower从leader 中复制数据。
2. 我的解释 ：
   1 ，目的 ： 为了防止数据丢失。
   2 ，怎么做到的 ： 类似 zookeeper ，同一个数据，有 leader ，有 follower ，消费者消费的时候，直接跟 leader 打交道。

5 ，写入流程 ：

1）producer先从zookeeper的 "/brokers/…/state"节点找到该partition的leader
2）producer将消息发送给该leader
3）leader将消息写入本地log
4）followers从leader pull消息，写入本地log后向leader发送ACK
5）leader收到所有ISR中的replication的ACK后，增加HW（high watermark，最后commit 的offset）并向producer发送ACK

二 ，broker 保存消息 ：

1 ，存储方式 ：

物理上把 topic 分成一个或多个 patition（对应 server.properties 中的 num.partitions=3 配置），每个patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件）

2 ，存储策略 ： 官方

1. 无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据：
2. 基于时间：log.retention.hours=168
3. 基于大小：log.retention.bytes=1073741824
4. 需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

3 ，存储策略 ： 我

1. kafka 的数据是可以不删除的。
2. 一定时间后删除。
3. 一定大小后，删除前面的
4. 复杂度 ： kafka 的性能稳定，不受数据量大小影响。

4 ，kafka 的数据在 zookeeper 的存储方式 ：

1. 注意：producer不在zk中注册，消费者在zk中注册。
2. 但是，在发数据的时候，他要跟 zookeeper 打招呼。
3. 因为，无论是生产还是消费，都要找 leader 。
   

5 ，读数据的时候 ：

1. 不同组的消费者 ： 可以消费同一个分区的数据。
2. 同组消费者，不可以消费同一个分区的数据。
3. 数据单发 ： 把所有消费者都放到一组，那么，他们只有一个人在消费数据。
4. 数据群发 ： 每个消费者属于一个组，那么，每个人都可以消费数据。

三 ，Kafka 消费过程分析

1 ，kafka 提供了两套 consumer API ：

1. 哪两套 ：高级 Consumer API 和低级 Consumer API。
2. 适用场景 ：
   1 ，低级 ：复制任务，高级 api 来不了的活，用这个来干。
   2 ，高级 ：简单任务

2 ，高级 API ：

1. 高级API优点
   1 ，高级 API 写起来简单
   2 ，不需要自行去管理 offset，系统通过 zookeeper 自行管理。
   3 ，不需要管理分区，副本等情况，.系统自动管理。
   4 ，消费者断线会自动根据上一次记录在 zookeeper 中的 offset 去接着获取数据（默认设置 1 分钟更新一下 zookeeper 中存的 offset ）
   5 ，可以使用 group 来区分对同一个 topic 的不同程序访问分离开来（不同的 group 记录不同的 offset ， 这样不同程序读取同一个 topic 才不会因为 offset 互相影响）
2. 高级 API 缺点
   不能自行控制 offset（对于某些特殊需求来说）
   不能细化控制如分区、副本、zk等

3 ，低级 API ：

1. 低级 API 优点
   1 ，能够让开发者自己控制offset，想从哪里读取就从哪里读取。
   2 ，自行控制连接分区，对分区自定义进行负载均衡
   3 ，对 zookeeper 的依赖性降低 ( 如：offset 不一定非要靠 zk 存储，自行存储 offset 即可，比如存在文件或者内存中 )
2. 低级 API 缺点
   太过复杂，需要自行控制offset，连接哪个分区，找到分区leader 等。

4 ，消费者组 ：

1. 消费者是以 consumer group 消费者组的方式工作，由一个或者多个消费者组成一个组，共同消费一个 topic 。
2. 每个分区在同一时间只能由 group 中的一个消费者读取。 ( 注意 ：同一时间 )
3. 多个 group 可以同时消费这个 partition。
4. 有一个由三个消费者组成的 group，有一个消费者读取主题中的两个分区，另外两个分别读取一个分区。某个消费者读取某个分区，也可以叫做某个消费者是某个分区的拥有者。
5. 负载均衡 ： 在这种情况下，消费者可以通过水平扩展的方式同时读取大量的消息。另外，如果一个消费者失败了，那么其他的group成员会自动负载均衡读取之前失败的消费者读取的分区。
   

4 ，消费方式 ：

1. consumer 采用 pull（拉）模式从 broker 中读取数据。
2. push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。
3. 对于Kafka而言，pull模式更合适，它可简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——即可批量消费也可逐条消费，同时还能选择不同的提交方式从而实现不同的传输语义。
4. pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直等待数据到达。为了避免这种情况，我们在我们的拉请求中有参数，允许消费者请求在等待数据到达的“长轮询”中进行阻塞（并且可选地等待到给定的字节数，以确保大的传输大小）。