新版本架构图如下图所示：
注意点：
1、老版本 consumer 需要跟zookeeper进行连接，把offset存放在zookeeper中，新版本为了优化这块，已经把offset存在broker中的__consumer_offsets topic中
2、kafka是采用消息队列的点对点模式，生产者 push消息到 kafka集群中，消费者 消费消息 需要while(true)轮询 去 kafka集群中 主动去拉数据
3、生产者只能往一个topic中推数据，而且是往leader分区去推数据，具体往topic中哪个分区推数据，后续要专门讲一下
4、消费者可以同时消费多个topic ,当这个消费者没有配置group.id时，则会自动创建一个消费组，这个消费组里面只有这个一个消费，一个消费组在消费一个topic的时候，是消费完一个分区，然后才会消费下一个分区的数据
比如：有两个分区 分区1有数据 ， 1 ，4 ，7
分区2有数据 ， 2 ，5 ，8
则消费者消费的数据顺序为 147 258
zookeeper里面存放的数据
可见zookeeper里面主要存放的是 borker节点信息，topic及分区信息
broker 保存消息
物理上把topic分成一个或多个patition（对应 server.properties 中的num.partitions=3配置），每个patition物理上对应一个文件夹（该文件夹存储该patition的所有消息和索引文件），如下：
[atguigu@hadoop102 logs]$ ll drwxrwxr-x. 2 atguigu atguigu 4096 8月 6 14:37 first-0 drwxrwxr-x. 2 atguigu atguigu 4096 8月 6 14:35 first-1 drwxrwxr-x. 2 atguigu atguigu 4096 8月 6 14:37 first-2 [atguigu@hadoop102 logs]$ cd first-0 [atguigu@hadoop102 first-0]$ ll -rw-rw-r--. 1 atguigu atguigu 10485760 8月 6 14:33 00000000000000000000.index -rw-rw-r--. 1 atguigu atguigu 219 8月 6 15:07 00000000000000000000.log -rw-rw-r--. 1 atguigu atguigu 10485756 8月 6 14:33 00000000000000000000.timeindex -rw-rw-r--. 1 atguigu atguigu 8 8月 6 14:37 leader-epoch-checkpoint
消息删除策略
无论消息是否被消费，kafka都会保留所有消息。有两种策略可以删除旧数据：
1）基于时间：log.retention.hours=168
2）基于大小：log.retention.bytes=1073741824
需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。
