玩转kafka

http://zookeeper.apache.org/releases.html#download

http://kafka.apache.org/downloads.html(下载最新 二进制版本，本文示例kafka_2.9.2-0.8.1.1.tgz )

https://github.com/miknil/Kafka4n(net开发程序)

https://cwiki.apache.org/confluence/display/KAFKA/0.8.0+SimpleConsumer+Example（官方例子）

https://cwiki.apache.org/confluence/display/KAFKA/Consumer+Group+Example

1.zookeeper安装

你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg

2.kafka安装（注意kafka中zookeeper跟1中的一致性）

zookeeper-server-start ../../config/server.properties

3.kafka详细介绍

kafka是linkedin用于日志处理的分布式消息队列，linkedin的日志数据容量大，但对可靠性要求不高，其日志数据主要包括用户行为（登录、浏览、点击、分享、喜欢）以及系统运行日志（CPU、内存、磁盘、网络、系统及进程状态）。

当前很多的消息队列服务提供可靠交付保证，并默认是即时消费（不适合离线）。高可靠交付对linkedin的日志不是必须的，故可通过降低可靠性来提高性能，同时通过构建分布式的集群，允许消息在系统中累积，使得kafka同时支持离线和在线日志处理。

处理逻辑

kafka的每个partition只能同时被一个group中的一个consumer消费
增加并发能力，通过增加partition来实现
多线程消费，是指消费多个partition，每个partition的顺序是有保证的

 

 

Kafka存储策略

1.  kafka以topic来进行消息管理，每个topic包含多个part（ition），每个part对应一个逻辑log，有多个segment组成。

2.  每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。

3.  每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。

4.  发布者发到某个topic的消息会被均匀的分布到多个part上（随机或根据用户指定的回调函数进行分布），broker收到发布消息往对应 part的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被 flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创 建新的segment。

发布与订阅接口

发布消息时，kafka client先构造一条消息，将消息加入到消息集set中（kafka支持批量发布，可以往消息集合中添加多条消息，一次行发布），send消息时，client需指定消息所属的topic。

订阅消息时，kafka client需指定topic以及partition
num（每个partition对应一个逻辑日志流，如topic代表某个产品线，partition代表产品线的日志按天切分的结果），client订
阅后，就可迭代读取消息，如果没有消息，client会阻塞直到有新的消息发布。consumer可以累积确认接收到的消息，当其确认了某个offset
的消息，意味着之前的消息也都已成功接收到，此时broker会更新zookeeper上地offset registry（后面会讲到）。

无状态broker

1.  Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。（如何主从热备）

2.  Broker不保存订阅者的状态，由订阅者自己保存。

3.  无状态导致消息的删除成为难题（可能删除的消息正在被订阅），kafka采用基于时间的SLA(服务水平保证)，消息保存一定时间（通常为7天）后会被删除。

4.  消息订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset进行重新读取消费消息。

Consumer group

1. 允许consumer group（包含多个consumer，如一个集群同时消费）对一个topic进行消费，不同的consumer group之间独立订阅。

2. 为了对减小一个consumer group中不同consumer之间的分布式协调开销，指定partition为最小的并行消费单位，即一个group内的consumer只能消费不同的partition。

传统的消息系统有两种模型：队列和发布-订阅模式。在队列模型中，一堆消费者会从一台机子上读消息，每一条消息只会被一个消费者读到；在发布订阅模型中， 消息会向所有的消费者广播。Kafka提供了一种单一的将这两种模型进行抽象的消费者模式——消费者组（consumer group）。

消费者会属于某一个组，发布到每个主题的消息会递送给订阅了这个主题的消费者组中的一个消费者。消费者实例可以是不同的进程或者在不同的机器上。如果所有 的消费者从属于同一个组，这就跟传统的队列模式一样了。如果每个消费者自成一组，那么这就是发布订阅模式了，所有的消息会被广播给所有的消费者。但是通常 情况下，我们发现，主题会有多个消费者组，每个组对应一个逻辑上的订阅者，每个组由多个消费者实例组成以保证扩展性和容错性。

Zookeeper 协调控制

1. 管理broker与consumer的动态加入与离开。

2. 触发负载均衡，当broker或consumer加入或离开时会触发负载均衡算法，使得一

个consumer group内的多个consumer的订阅负载平衡。

3.  维护消费关系及每个partion的消费信息。

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。

消息交付保证

1. kafka对消息的重复、丢失、错误以及顺序型没有严格的要求。

2. kafka提供at-least-once delivery,即当consumer宕机后，有些消息可能会被重复delivery。

3. 因每个partition只会被consumergroup内的一个consumer消费，故kafka保证每个partition内的消息会被顺序的订阅。

4. Kafka为每条消息为每条消息计算CRC校验，用于错误检测，crc校验不通过的消息会直接被丢弃掉。

Kafka未来研究方向

1. 数据压缩（节省网络带宽及存储空间）

2. Broker多副本

3. 流式处理应用