一.Kafka生产过程分析
1.写入方式
producer采用push模式将消息发送到broker，每条消息都被追加(append)到分区中，属于顺序写磁盘(顺序写磁盘效率要比随机写内存要高，保障Kafka吞吐率)。
2.分区
消息发送时都被发送到一个topic，其本质就是个目录，而topic是由一些分区日志组成
1）分区的原因
（1）方便在集群中扩展，每个分区可以通过调整以适应它所在的机器，而一个topic又可以有多个分区组成，因此整个集群就可以适应任意大小的数据了；
（2）可以提高并发，因为可以以分区为单位读写了。
2）分区的原则
（1）指定了分区，则直接使用；
（2）未指定分区但指定key，通过对key的value进行hash出一个分区；
（3）分区和key都未指定，使用轮询选出一个分区。
3.副本
同一个分区可能会有多个副本(对应server.properties配置中的defalut.replication.factor=N)。没有replication的情况下，一旦broker宕机，其上所有的分区数据都不可被消费，同时producer也不能再将数据存于其上的分区。引入副本之后，同一个分区可能会有多个副本(副本之间不能共存同一机器，否则副本没有意义)，这时需要在这些副本之间选出一个leader，producer和consumer只与这个leader交互，其它副本作为follower从leader中复制数据。
4.写入流程
二.Broker保存消息
1.存储方式
物理上把topic分成一个或多个分区(对应server.properties中的num.patitions=3配置) ，每个分区物理上对应一个文件夹(该文件夹存储该分区所有消息和索引文件)
2.存储策略
无论消息是否被消费，Kafka都会保留所有消息。有两种策略可以删除久数据：
1）基于时间：log.retention.hours=168
2）基于大小：log.retention.bytes=1073741824
需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里 删除过期文件与提高Kafka性能无关。
3.Zookeeper存储结构
注意：
1）这里我么没有指定组名，所以他会随机生成一个组名
2）producer不在zk中注册，消费者在zk中注册
三.Kafaka消费过程分析
Kafka提供了两种consumerAPI。
１.高级API
１）高级API优点
写起来简单
不需要自己管理offsets，系统通过zookeeper自行管理
消费者断线会自动根据上一次的offsets去接着获取数据(默认设置1分钟更新以下zookeeper中的offsets)
可以使用group来区分对于同一个topic的不同进程(不同的group记录不同的offsets，这样不同的进程才不会混淆offsets)
2）高级API缺点
不能自行控制offsets(对于某些需求)
不能细化控制分区副本zk等
２.低级API
1）低级API优点
能让开发者自己控制offsets，像从哪里读取就从哪里读取
自行控制连接分区，对分区自定义进行负载均衡
对zookeeper的依赖性降低（如：offsets不一定分要靠zk来存储，通过参数指定--bootstrap-server来使offsets存储到kafka中）
2）低级API缺点
不好写复杂繁琐
3 .消费者组
消费者是以consumer group消费者组的方式工作，有一个或者多个消费者组成一个组，共同消费一个topic，每个分区在同一时间只能由group中的一个消费者读取，但是多个group可以同时消费这个分区。在这种情况下，消费者可以通过水平扩展的方式读取大量消息。另外如果一个消费者失败了，那么其他group成员会自动负载均衡读取之前失败的消费则读取的分区
4.消费方式
consumer采用pull(拉)模式从broker中读取消息
push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络阻塞，而pull模式则可以根据consumer的消费能力以适当的速率进行消费。
对于Kafka而言，pull模式跟适合，它可以简化broker的设计，consumer可自主控制消费消息的速率，同时consumer可以自己控制消费方式——批量或逐条，同时还能选择不同的提交方式从而实现不同的传输语义。
pull模式不足之处在于如果Kafka没有消息，消费者可能会陷入循环中，一直等待消息到达。为了避免这种情况，我们在pull中设置参数，允许消费者请求在等待消息到达的长轮询中进行阻塞。
5.消费者组案例
1）需求：测试同一个消费者组中的消费者，同一时间只能有一个消费则消费。
2）案例实操
（1）在node1 node2上修改 /root/apps/kafka_2.11-0.11.0.2/config/consumer.properties 为任意组名如下
（2）测试
node3为生产者，node1和node2为消费者，我们可以看到同一时间只有一个消费者获得了消息，而在该消费者挂掉之后， 另一消费者会获得消息 。
测试成功。
图2来源：https://blog.csdn.net/lizhitao/article/details/23744675#commentBox