kafka

一、概述

Kafka是最初由Linkedin公司开发，基于Scala语言编写的一个分布式、分区的、多副本的、多订阅者，由zookeeper协调的分布式日志系统，也可以当做MQ系统。

二、Kafka特性

1. 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，延迟最低只有几毫秒；
2. 高并发：支持数千个客户端同时读写；
3. 持久性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；
4. 容错性：允许集群中节点失败；
5. 可扩展性：集群支持热扩展；

二、Kafka应用场景

1. 日志收集：可以用作各个服务的系统日志收集，通过kafka以统一接口服务的方式开放给各种consumer；
2. 消息系统：解耦生产者与消费者之间，缓存消息等。
3. 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
4. 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
5. 流式处理：比如spark streaming和storm。

三、Kafka架构

1. Producer：消息的生产者，就是向 Kafka broker 发消息的客户端。
2. Consumer：消息的消费者，向 Kafka broker 取消息的客户端。
3. Consumer Group：消费组，由多个 Consumer 组成，这些消费者共用一个Group ID
4. Broker：一台 Kafka 服务器就是一个 broker。一个集群由多个 broker 组成。
5. Topic：消息的主题，逻辑概念，可以理解为消息的分类。在每个broker上都可以创建多个topic。
6. Partiton：Topic的分区，每个topic可以有多个partition，这些partition可以分布到多个 broker上，每个 partition都是有序的队列，且存放的数据都是不重复的。
7. Replication：副本，由一个 leader（主分区）和若干个 follower（备胎）组成。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。follower和leader绝对是在不同的机器上，同一个机器对同一个分区也只能存放一个副本。

四、消费者组和分区关系

1. Topic中的一个partition只能被订阅该topic的消费组中的一个消费者消费，该组的其他消费者不能再重复消费这个partition。
2. 多个不同的消费组订阅了同一个topic，每个消费组都可以消费topic中的所有partition，且消费位移之间互不影响。
3. 消费组中一个消费者可以消费多个partition。
4. 一个消费组存在的消费者个数大于分区数时，会出现消费组未被分配到partition的消费者。
5. 如果所有的消费者都隶属于同一个消费组，那么所有的消息都会被均衡地投递给每一个消费者，即每条消息只会被一个消费者处理，这就相当于点对点模式的应用。
6. 如果所有的消费者都隶属于不同的消费组，那么所有的消息都会被广播给所有的消费者，即每条消息会被所有的消费者处理，这就相当于发布/订阅模式的应用。

五、消息传递模式

1. 点对点模式（一对一，消费者主动拉取数据）
   生产者将生产的消息发送到 Queue 中，然后消费者从 Queue 中取出并且消费消息。消息被消费以后，会从 Queue 中删除不再存储，所以消费者不可能消费到已经被消费的消息。Queue 支持存在多个消费者，只是多个消费者属于相互竞争的状态，一个消息只会被一个消费者拿到。
   
2. 发布 / 订阅模式（一对多，消费者消费数据之后不会清除消息）
   消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）该topic。和点对点方式不同，发布到 topic 中的消息会被所有订阅者消费。
   

六、zookeeper作用

1. 每个Broker在启动时，都会到zk上进行注册，然后zk会到/brokers/ids下创建各个broker的节点，节点的路径为/brokers/ids/[0...N]，然后每个Broker就会将自己的IP地址和端口信息记录到该节点中去。zk为Broker创建的节点类型是临时节点，一旦Broker宕机，则对应的临时节点也会被自动删除。
2. 在Kafka中，同一个Topic的消息会被分成多个partition并将其分布在多个Broker上，这些partition信息及与Broker的对应关系也都是由zk在维护，通过/borkers/topics/topic.name节点来记录。在Broker服务器启动后，会到对应Topic节点上注册自己的Broker ID并写入针对该Topic的分区总数，如/brokers/topics/login/3->2，这个节点表示Broker ID为3的一个Broker服务器，对于"login"这个Topic的消息，提供了2个分区进行消息存储，同样，这个分区节点也是临时节点。
3. 每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/[group_id]/ids/[consumer_id]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。每个消费者都需要关注所属消费者分组中其他消费者服务器的变化情况，即对/consumers/[group_id]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。消费者还需要对/broker/ids/[0-N]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。
4. Producer向zk中注册watcher，用来监听topic的partition的消息，以便动态了解运行情况，实现负载均衡。zk不管理producer，只是能够提供当前broker的相关信息。
5. 在Kafka中，规定了每个partition只能被同组的一个消费者进行消费，因此，需要在zk上记录partition 与 Consumer 之间的关系，每个消费者一旦确定了对一个partition的消费权力，需要将其Consumer ID 写入到zk对应消息分区的临时节点上，例如：/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]，
   其中，[broker_id-partition_id]就是一个消息分区 的标识，节点内容就是该消息分区上消费者的Consumer ID。
6. 在消费者对指定消息分区进行消息消费的过程中，需要定时地将分区消息的消费进度Offset记录到zk上，以便在该消费者进行重启或者其他消费者重新接管该消息分区的消息消费后，能够从之前的进度开始继续进行消息消费。Offset在Zookeeper中由一个专门节点进行记录，其节点路径为:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]节点内容就是Offset的值。