Kafka详细分析
前面说过Kafka主要包括：客户端，Broker，ZK，消费者四块内容。
1. 客户端
客户端的作用为收集消息，将消息正确的发送到客户端。
1.1 消息
客户端的消息包括：CRC，版本号，Key，Length，属性，Value
1.2 客户端和ZK
客户端启动之前需要指定ZK地址，客户端需要ZK来获取Broker信息。
客户端启动时的步骤：
1. 客户端向ZK注册自己，获取所有的Broker leader地址
2. Watch Broker的变动，Broker发生变动后，会自动调整发送的位置，重新做负载均衡
3. 发送消息
1.3 负载均衡
客户端支持多种负载均衡方式。
- 轮询：遍历Broker发送消息
- Hash：对Key进行Hash发到不同的Broker
2 消费者
消费者用来消费消息的。和生产者一样，消费者也是需要先和ZK打交道。
2.1 消息
消费者收到的消息包含了：消息实体，partition，offset，CRC等信息
2.2 和ZK关系
客户端启动时的步骤：
1. 消费者向ZK注册自己，获取所有的Broker leader地址。
2. Watch Broker的变动
3. Watch Other Consumer的加入和退出
2.3 负载均衡
消费者负载均衡由两方面引起：
1. Broker变动
2. Consumer变动
负载均衡方案很简单：n = Partition Count / Consumer Count 向下取整。每个
Consumer负责n个Partition。
比如Partition id为：1，2，3，4，5
两个Consumer id为：A，B
则A负责1,2；B负责：3,4,5
2.4 Consumer API
目前0.9版本之前，只有High Consumer API和Simple Consumer API两套接口。
High API比较好用，采用流式消费的方式，支持自动Commit，但是不支持offset的设
置，无法手动设置offset。
Simple API接口丰富，功能强大，巨难用。需要消费者自己发送http请求获取消息，
自己管理offset，自己维护broker的变更。
好消息是0.9版本之后（包括0.9）提供了KafkaClient，基本上包含了常用的一些请
求，但据说多线程会有问题。
3 Broker
broker集群主要解决以下几个问题：
- 消息备份
- follow失效和重启
- leader失效
- 所有Replicas失效
3.1 消息备份
Kafka的每个partition包括一个leader broker和若干个follow broker(可以为0)，那么消息如何进行同步就比较重要。常见的方式为：同步备份，异步备份。
同步备份
client发送消息到leader之后，leader会将数据写入Cache并flush到磁盘，修改HW，之后follow去拉取消息，将消息写入cache，不用等待flush到磁盘就返回ack影响，leader收到所有follow的ack后向client发送ack，并标记消息为commited状态，只有commited状态的消息才能被消费。follow在cache积累一定量消息或者达到一定时间后会flush到磁盘，再更新本地的HW。
流程为：
1. Client发送消息
2. leader写入消息，修改HW
3. follow同步消息到cache，发送ack
4. leader向client发送ack
5. client发送下一条
6. follow flush到磁盘，更新HW
异步备份
Client可以选择异步发送，不用等待Leader的确认。而Leader也不会等待全部follow同步数据。Leader允许follow落后一些消息(可配置)，这样follow可以批量拉取数据，增强了消息备份的性能。
3.2 follow失效和重启
follow存活必须满足两个条件：
1. follow没有down掉
2. follow没有落后leader太多
leader会跟踪一个ISR(in-sync Replicas)，当发现follow没有存活时，会自动将其从ISR中删除。follow重启后，自动读取本地保存的HW，删除HW之后的数据，再从leader进行消费，追上leader后会被加入ISR。
3.3 leader失效
ZK里面动态维护了一个ISR，可以认为这个ISR里面所有的follow都跟上了leader，选择新的leader只能从ISR里面产生，当一个leader失效以后，ZK会选择第一个向ZK注册并在ISR里面的follow为leader。选出leader后，其它的follow会同步新leader的HW，保持本地的HW和leader的一致，之后新leader就可以进行工作。
3.4 所有Replicas失效
当只有一个Replicas还存活的时候，kafka就可以正常进行工作。如果kafka所有的Replicas都失效了，有以下两种方案：
1. 等待ISR中任意一个Replicas活过来，并作为leader
2. 选择任意一个Replicas活过来，并作为leader
目前Kafka选择了第二种方式。后续Kafka可能会采取用户可配方式。