kafaka-无限横向扩展消息中间件

本文参考文章：

http://www.cnblogs.com/likehua/p/3999538.html

简介

        kafka集群有多个实例组成，每个实例称为broker。
broker，producer和consumer都依赖zookeeper保存meta信息。
每个topic都有多个partition分区，每个分区保存在不同的server上
分区上每个消息都有一个offset（分区上消息是顺序的）
新消息时append到每个分区后面的
pull模式，非push模式（发布订阅）
生产者通过random，hash等模式把消息均衡发送到多个partition里面
每个分区又被分为多个segmentfile，名字为最小offset.kafka。
每个分区同一时刻只允许一个consumer连接，一个consumer同时可以连接多个分区。

复制备份

        kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);
leader处理所有的read-write请求,follower需要和leader保持同步
当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它.

copy-on-write方式

zookeeper

    1) Broker node registry: 当一个kafkabroker启动后,首先会向zookeeper注册自己的节点信息(临时znode),同时当broker和zookeeper断开连接时,此znode也会被删除.


    格式: /broker/ids/[0...N]   -->host:port;其中[0..N]表示broker id,每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),znode的值为此broker的host:port信息.


    2) Broker Topic Registry: 当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息,仍然是一个临时znode.


    格式: /broker/topics/[topic]/[0...N]  其中[0..N]表示partition索引号.


    3) Consumer and Consumer group: 每个consumer客户端被创建时,会向zookeeper注册自己的信息;此作用主要是为了"负载均衡".


    一个group中的多个consumer可以交错的消费一个topic的所有partitions;简而言之,保证此topic的所有partitions都能被此group所消费,且消费时为了性能考虑,让partition相对均衡的分散到每个consumer上.


    4) Consumer id Registry: 每个consumer都有一个唯一的ID(host:uuid,可以通过配置文件指定,也可以由系统生成),此id用来标记消费者信息.


    格式:/consumers/[group_id]/ids/[consumer_id]


    仍然是一个临时的znode,此节点的值为{"topic_name":#streams...},即表示此consumer目前所消费的topic + partitions列表.


    5) Consumer offset Tracking: 用来跟踪每个consumer目前所消费的partition中最大的offset.


    格式:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]-->offset_value


    此znode为持久节点,可以看出offset跟group_id有关,以表明当group中一个消费者失效,其他consumer可以继续消费.


    6) Partition Owner registry: 用来标记partition被哪个consumer消费.临时znode


    格式:/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]-->consumer_node_id

consumer启动步骤

    A) 首先进行"Consumer id Registry";


    B) 然后在"Consumer id Registry"节点下注册一个watch用来监听当前group中其他consumer的"leave"和"join";只要此znode path下节点列表变更,都会触发此group下consumer的负载均衡.(比如一个consumer失效,那么其他consumer接管partitions).


    C) 在"Broker id registry"节点下,注册一个watch用来监听broker的存活情况;如果broker列表变更,将会触发所有的groups下的consumer重新balance


    1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partition leader建立socket连接并发送消息.


    2) Broker端使用zookeeper用来注册broker信息,已经监测partitionleader存活性.


    3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息.