Kafka使用心得(4)—Kafka详细分析

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可能会采取用户可配方式。