Chap 1 Kafka简介
1.Apache Kafka是一款开源的，分布式的，基于分区、日志提交和订阅推送的消息系统。设计用于：
- 持久化消息到硬盘，TB级别
- 高吞吐量，每秒数百M读写
- 分布式，支持弹性伸缩
- 实时性
Chap 2 搭建Kafka集群
1.Kafka集群支持
- 单节点，单broker
- 单节点，多broker
- 多节点，多broker
2.Kafka组成
- Topic：消息目录名，类似于数据库表名Topic是可以分区的，消息在Topic中有唯一的序列号:offset。
- Broker：运行的一个kafka server进程。Topic在Broker处理进程中创建。
- ZK：充当broker和消费者之间的协调器，记录状态/配置/标记信息等。
- Producers：产生Tpoic中的消息
- Consumers：消费Producers产生的消息
3.一些操作说明
- 创建topic时，replication-factor指定副本数，partitions指定分区数目。
- 创建生产者时，使用broker-list指定broker列表并指定topic。
- 创建消费者时，使用from-beginning指定从头读取并需要指定topic
Chap 3 Kafka设计
1.Kafka设计准则
- topic是逻辑的概念，可以分为多个partition。partition是物理的概念，对应于有序/不可修改的日志文件。新消息写入topic，日志文件会新增记录，并在消息达到配置数量或者超时时写入硬盘。需要注意的是，flushed的消息才能被消费者读取到。
- 分区中的消息使用offset唯一记录自己，每个分区可以设置副本用以容错
- 分区至少有一个leader负责数据读写，其副本称之为follower。主副本信息存储在ZK中。主本出现问题后，副本会选举变成leader。
- 消费者通过消费者组进行管理，对于消费者组订阅的主题，组内的消费者只能有一个消费者进行消费。消费者顺序消费消息并设置当前消息的offset。
- Kafka定义基于时间的消息保存策略，超期后会自动清除消息。
- 为了让生产者知道消息是否写入成功，提供获取回执和等待时间的配置。
- 消费者读取消息然后记录处理位置offset，如果读取消息进行处理后，写入位置信息前消费者出现错误，下一个消费者会重复消费该消息。
2.日志压缩：相同key的消息，只保存最新的value，删除key相同的旧数据。Kafka支持的保存策略有：基于时间、基于文件大小和基于日志压缩。基于日志压缩的保存策略：
- 消息的排序始终不变
- 消息有序偏移，offset保持不变
- 从0偏移开始遍历消息，能读取所有key的最新值
3.与其它消息系统不同，消费消息的元数据由consumer发起（保存在ZK中）而不是server。这可能导致：丢失消息和重复消费。所有的broker地位相同，没有master，broker的元数据保存在ZK。生产者发送消息支持同步和异步模式。
4.支持消息压缩，可以将一批消息压缩发送给broker，可以减少网络消耗。0.7版本之前，这批压缩消息会被同一个consumer消费，0.8之后的版本可以根据offset拆分访问。支持的压缩协议：GZIP和Snappy。
5.消息分区策略由生产者决定，broker按照消息到达的顺序存储消息，有几个分区由broker决定。
6.通过复制策略提供容灾，分为leader和fffollower，leader保存follower的列表：ISR(in-sync replicas)。支持的复制策略有：
- 同步复制：生产者从ZK获取leader并写入消息，然后leader将消息写到follower并获取回执，全部回执成功后leader提交写入log并给生产者返回响应。此时，消费者便能拉去新写入的消息。
- 异步复制：不等待follower回执就写入log，可能由于broker错误而不能保证消息的有效投递。
7.当有follpwer失效时，leader将从ISR列表中将其删除。当follower又回来时，首先重置日志到上次的checkpoint，然后从leader同步数据，同步完成后，leader将其写入到ISR列表中。
当leader出现错误（写入分区日志或者发送回执到生产者之前），消息会重新发送到新leader。优先选择早注册的follower成为leader，然后将其offset设置为集群的offset。其他follower通过注册在ZK的监听器察觉此动作，重置日志到上次checkpoint并向新leader开始同步数据。新leader在等待超时或者所有follower完成同步后将ISR列表写入ZK并承接读写工作。
Chap 4消费者
1.生产者连接任意节点，获取关于当前分区leader的元数据信息，然后将消息写入当前分区。写入时可以通过key并进行hash操作确定写入哪个分区。为了提高效率，支持按照时间或者条数进行批量异步写入，并提供回调函数处理写入错误，用以防止数据丢失。
2.通过实现Partitioner接口来实现分区计算。
Chap 5消费者
1.消费者连接任意节点获取leader分区信息。每个分区只能由订阅该topic的一个消费者消费，消费后会更新offset，然后根据offset由另一个消费者消费其他分区。
2.消费者API分为顶层API和底层API：
- 顶层API：只读取数据，不与broker交互，不需要用户处理offset。内部自动从ZK读取offset并存储最终的offset，offset是基于消费者组进行存储的。同一消费者组，已经有运行的消费者进程，新增消费者进程，会进行reblance，可能造成消息的不确定性，因此，必须停已经运行的消费者进程。
- 底层API：无状态，需要进行broker与消费者进行交互。
PS：六七章待读。
