Kafka的Producer和Consumer源码学习
先解释下两个概念：
high watermark (HW)
它表示已经被commited的最后一个message offset(所谓commited, 应该是ISR中所有replica都已写入)，HW以下的消息都已被ISR中各个replica同步，从而保持一致。HW以上的消息可能是脏数据：部分replica写成功，但最终失败了。
Kafka Partition： 1> 均衡各个Broker之间的数据和请求压力； 2> 分摊处理不同的消费者进程； 3> 在partition内可以保证局部有序和状态记录；
Producer发送数据时，Broker的内部处理流程： a. Broker Server接到一个Producer request
b. 会先从ZK中获取该topic的metadata
c. 进而找到partition的metadata
d. 从而确定对应的partition leader
e. 接下来通过该leader partition来append log
f. 最后计算是否调整leader的High Watermark (它是ISR中所有replica的logEndOffset的最小值与leader的logEndOffset比较得出的最大值) 当然，Broker Server还要根据Producer request的需要决定是否回复ack给client；
Kafka Producer配置：
Kafka的Producer采用了 linkedBlockingQueue, 所以用户设置的batchNumMessages不能大于queueBufferingMaxMessages.
Producer线程可以设定为定期更新Topic Metadata （topic.metadata.refresh.interval.ms, 若该值为负值，则取消定期更新）；但是一旦Producer遇到失败情况（partition missing or leader not available), 她会自动更新Metadata;
message.send.max.retries: Kafka有可能会出现某个partition leader暂时不可访问的情况，这个配置参数描述了Producer在此种情况下最多retry的次数。
compression.codec： 在Producer配置中，该参数指定压缩模式，默认是NoCompressionCodec(对所有Topic都不使用压缩)
compressed.topics： 在compression.codec不是NoCompressionCodec的前提下,则为指定的若干Topic执行写压缩,当compressed.topics为空时则是为所有topic执行压缩。
producer.type： sync or async
metadata.broker.list： Producer通过这个参数指定的Broker来获取Topic Metadata
partitioner.class: 关于生产者向指定的分区发送数据，通过设置partitioner.class的属性来指定向那个分区发送数据；如果自己指定必须编写相应的程序，默认是kafka.producer.DefaultPartitioner,分区程序是基于散列的键（ Utils.abs(key.hashCode) % numPartitions ）。
retry.backoff.ms： 设置Producer在refresh metadata之前要等待的时间 (Producer在每次retry之前都要refresh metadata, 但是可能partition的leader selection等需要一定的执行时间)，默认100毫秒；
Kafka Consumer配置:
group.id: 指定consumer所属的consumer group
consumer.id: 如果不指定会自动生成
socket.timeout.ms： 网络请求的超时设定
socket.receive.buffer.bytes： Socket的接收缓存大小
fetch.message.max.bytes： 试图获取的消息大小之和(bytes)
num.consumer.fetchers： 该消费去获取data的总线程数
auto.commit.enable: 如果是true, 定期向zk中更新Consumer已经获取的last message offset(所获取的最后一个batch的first message offset)
auto.commit.interval.ms： Consumer向ZK中更新offset的时间间隔
queued.max.message.chunks： 默认为2
rebalance.max.retries: 在rebalance时retry的最大次数，默认为4
fetch.min.bytes： 对于一个fetch request, Broker Server应该返回的最小数据大小，达不到该值request会被block, 默认是1字节。
fetch.wait.max.ms: Server在回答一个fetch request之前能block的最大时间（可能的block原因是返回数据大小还没达到fetch.min.bytes规定）；
rebalance.backoff.ms： 当rebalance发生时，两个相邻retry操作之间需要间隔的时间。
refresh.leader.backoff.ms： 如果一个Consumer发现一个partition暂时没有leader, 那么Consumer会继续等待的最大时间窗口（这段时间内会refresh partition leader);
auto.offset.reset： 当发现offset超出合理范围（out of range)时，应该设成的大小（默认是设成offsetRequest中指定的值）：
smallest: 自动把该consumer的offset设为最小的offset；
largest: 自动把该consumer的offset设为最大的offset；
anything else: throw exception to the consumer；
consumer.timeout.ms： 如果在该规定时间内没有消息可供消费，则向Consumer抛出timeout exception；
该参数默认为-1， 即不指定Consumer timeout；
client.id： 区分不同consumer的ID，默认是group.id
Kafka Consumer如何与ZK交互：
/brokers/ids/[0]...[N-1]: N是Broker个数，每个[i]是一个Broker,里面存储着每个Broker相关的信息（ip,port,epoch等）；
/brokers/topics/[topic_name]/partitions/[0]...[N-1]/state： N是这个topic的partition数目，state里存放了每个partition的leader及ISR等信息；
备注: [topic_name]这个znode本身也存储了所有partition对应的leader broker；
/consumers/[group_id]/ids/[consumer_id]/[topic0]-[topicN]: [consumer_id]是一个临时znode, 其子node是该consumer监听的topic
/consumers/[group_id]/offsets/[topic_name]/[partition_id]: [partition_id]结点中的值即为offset
/consumers/[group_id]/owners/[topic_name]: ?（会陆续补充）
ConsumerFetcherThread的内部命名：
"ConsumerFetcherThread-%s-%d-%d".format(consumerIdString, fetcherId, sourceBroker.id)
Kafka消费端如何知道从哪个partition消费，以及如何在多个消费者之间平衡对于多个partition的消费？ 目前Broker Server端不会做类似处理，client端可以利用zookeeper来动态分配。（此处还有些不解）
Kafka Consumer在ZK中注册后会监听Broker变化及同组内（Consumer Group）consumer的加入或推出，从而自动实现partitions与consumers的平衡。
关于平衡算法，简单的说就是在实现平衡过程中，尽量保证一个consumer只和尽可能少的Broker维持连接。
