总体结构

Producer

producer根据用户指定的算法，将消息发送到指定的partition

Part

1. kafka以topic来进行消息管理，每个topic包含多个part（ition），每个part对应一个逻辑log，有多个segment组成。
2. 每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。
3. 每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。
4. 发布者发到某个topic的消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应part的最后一个segment上添加该消息，
5. 当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，
6. segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

Broke

1. 消息不在内存中cache，直接写入到磁盘，充分利用磁盘的顺序读写性能
2. 直接使用linux 文件系统的cache，来高效缓存数据。
3. 即使消息被消费,消息仍然不会被立即删除.日志文件将会根据broker中的配置要求,保留一定的时间之后删除
4. 采用linux Zero-Copy提高发送性能。
5. Topic划分为多个partition，提高parallelism
6. 可以通过实现Partitioner接口来定制Partition的分区规则
7. At least one 消息绝不会丢，但可能会重复传输
8. 通过冗余机制来保证信息的安全
9. 一个Broke可以包含多个Topic的Part,一个Topic也可以将多个Part分布到不同的不同的Broke上
10. 数据压缩：支持GZIP和Snappy压缩协议

Consumer 公共特性

1. Consumer根据消费能力自主控制消息拉取速度
2. Consumer根据自身情况自主选择消费模式，例如批量，重复消费，从尾端开始消费等

Lower Level Consumer

1. Consumer从kafka集群pull数据
2. Consumer负责维护消息的消费记录,控制获取消息的offset
3. Consumer可将offset设成一个较小的值，重新消费一些消息
4. 必须找出指定Topic Partition中的lead
   broker
5. 添加事务管理机制以保证消息被处理且仅被处理一次
6. 在一个处理过程中只消费Partition其中的一部分消息

High Level Consumer

1. High Level模式下的Group Name 是整个Kafka集群的全局变量
2. 消息消费以Consumer Group为单位，每个Consumer Group中可以有多个consumer，每个consumer是一个线程，topic的每个partition同时只能被某一个consumer读 取，Consumer Group对应的每个partition都有一个最新的offset的值，存储在zookeeper上的。所以在正常情况下不会出现重复消费的情况。
3. 因为consumer的offerset并不是实时的传送到zookeeper（通过配置来制定更新周期），所以Consumer如果突然Crash，有可能会读取重复的信息
4. High Level Consumer 可以并且应该被使用在多线程的环境，线程模型中线程的数量(也代表group中consumer的数量)和topic的partition数量有关，下面列举一些规则：
   1. 当提供的线程数量多于partition的数量，则部分线程将不会接收到消息；
   2. 当提供的线程数量少于partition的数量，则部分线程将从多个partition接收消息；
   3. 当某个线程从多个partition接收消息时，不保证接收消息的顺序；可能出现从partition3接收5条消息，从partition4接收6条消息，接着又从partition3接收10条消息；
   4. 当添加更多线程时，会引起kafka做re-balance, 可能改变partition和线程的对应关系。

Consumer Group

1. 允许consumer
   group（包含多个consumer，如一个集群同时消费）对一个topic进行消费，不同的consumer
   group之间独立订阅，互不干扰。
2. 当broker或consumer加入或离开时会触发负载均衡算法，使得一个consumer
   group内的多个consumer的订阅负载平衡
3. 每个partition只会被consumer
   group内的一个consumer消费，故kafka保证每个partition内的消息会被顺序的订阅，但多个Consumer
   Group可同时消费这一消息。。
4. 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group
5. 如果需要实现广播，只要每个Consumer有一个独立的Group
6. 要实现单播只要所有的Consumer在同一个Group里

Zookeeper

1. 每个broker启动后会在zookeeper上注册一个临时的broker
   registry，包含broker的ip地址和端口号，所存储的topics和partitions信息。
2. 每个consumer启动后会在zookeeper上注册一个临时的consumer
   registry：包含consumer所属的consumer
   group以及订阅的topics。
3. 每个consumer
   group关联一个临时的owner registry和一个持久的offset
   registry。对于被订阅的每个partition包含一个owner
   registry，内容为订阅这个partition的consumer id；同时包含一个offset registry，内容为上一次订阅的offset。