版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/zy_281870667/article/details/79946919
Kafka背景
Kafka最初是由LinkedIn公司使用Scala语言实现的，用作LinkedIn的活动流（Activity Stream）和运营数据处理管道（Pipeline）的基础。现在它已被多家不同类型的公司作为多种类型的数据管道和消息系统使用。
领英在2011年捐赠给Apache，然后在2012年成为First-class Apache项目。
领英在2011年捐赠给Apache，然后在2012年成为First-class Apache项目。
Kafka是什么？
Kafka官方定义：分布式的流媒体平台
Apache Kafka是分布式订阅、发布、消息传递的系统和强大的队列，可以处理大量数据，并使您能够将消息从一个端点传递到另一个终端。
Kafka适用于离线和在线消息消费。
Kafka消息被保留在磁盘上，并在集群内复制以防止数据丢失。
Kafka建立在ZooKeeper同步服务之上。
它与Apache Storm和Spark完美结合，实时流式传输数据分析。
Apache Kafka是分布式订阅、发布、消息传递的系统和强大的队列，可以处理大量数据，并使您能够将消息从一个端点传递到另一个终端。
Kafka适用于离线和在线消息消费。
Kafka消息被保留在磁盘上，并在集群内复制以防止数据丢失。
Kafka建立在ZooKeeper同步服务之上。
它与Apache Storm和Spark完美结合，实时流式传输数据分析。
Kafka优缺点
优点：
1、高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition， consumer group 对partition进行consume操作。
2、可扩展：Kafka集群支持热扩展，可以在集群启动后把新服务器加入到集群。
3、容错性：允许节点失败，Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时， Zookeeper将通知生产者和消费者使用其他的Broker。
缺点：
1、重复消息：Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
2、消息乱序：Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
3、复杂性：Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。
1、高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition， consumer group 对partition进行consume操作。
2、可扩展：Kafka集群支持热扩展，可以在集群启动后把新服务器加入到集群。
3、容错性：允许节点失败，Kafka每个Partition数据会复制到几台服务器，当某个Broker失效时， Zookeeper将通知生产者和消费者使用其他的Broker。
缺点：
1、重复消息：Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
2、消息乱序：Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
3、复杂性：Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。
Kafka拓扑结构
Producer：可以是web前端产生的Page View、搜索等用户活动跟踪，或者是服务器日志、系统CPU报警、警告等运营指标
Zookeeper：Kafka通过Zookeeper管理集群配置，检测partition leader存活，以及在Consumer Group发生变化时进行rebalance
Zookeeper：Kafka通过Zookeeper管理集群配置，检测partition leader存活，以及在Consumer Group发生变化时进行rebalance
名词解释
Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker
Producer：负责发布消息到Kafka broker
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic（类似MQ中的queue）
Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition
Segment：多个大小相等的段组成了一个partition，segment文件名为上一个segment文件最后一条消息的offset值。
Offset：一个连续的用于定位被追加到分区的每一个消息的序列号，最大值为64位的long大小，19位数字字符长度。
Consumer：消息消费者，向Kafka broker读取消息的客户端。
Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）
Producer：负责发布消息到Kafka broker
Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic（类似MQ中的queue）
Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition
Segment：多个大小相等的段组成了一个partition，segment文件名为上一个segment文件最后一条消息的offset值。
Offset：一个连续的用于定位被追加到分区的每一个消息的序列号，最大值为64位的long大小，19位数字字符长度。
Consumer：消息消费者，向Kafka broker读取消息的客户端。
Consumer Group：每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）
Topic、partition、segment关系图
Kafka Producer
生产者将消息发送到broker上
消息的存放位置：客户端可以控制消息发送到哪个partition，有两种，一种是随机的；，一种是通过自定义函数指定partition
Kafka的批量发送：kafka支持使用批处理来提高处理效率，在配置的阀值内实现消息的批量发送
1. hash（message）% numPartition
2.阈值可以是大小或者时间，一般是64K的大小或者10毫秒（max.message.bytes）
消息的存放位置：客户端可以控制消息发送到哪个partition，有两种，一种是随机的；，一种是通过自定义函数指定partition
Kafka的批量发送：kafka支持使用批处理来提高处理效率，在配置的阀值内实现消息的批量发送
1. hash（message）% numPartition
2.阈值可以是大小或者时间，一般是64K的大小或者10毫秒（max.message.bytes）
Kafka Consumer
消费者从broker拉取消息
Kafka也有两种模式，队列模式（Queue）和发布-订阅模式（Pub）
队列模式：consumers可以同时争夺消息，但是只有一个consumer消费。
发布-订阅模式：消息会被广播到consumers中，多个consumer可以加入一个consumer group，以组的身份共同竞争一个topic，topic的消息会被订阅的consumer group内的一个consumer消费。
Consumer需要维护消费的状态：消息是否被消费了，是在consumer这边记录的，这样的不会对集群和其他consumer产生影响，非常轻量级。
Kafka也有两种模式，队列模式（Queue）和发布-订阅模式（Pub）
队列模式：consumers可以同时争夺消息，但是只有一个consumer消费。
发布-订阅模式：消息会被广播到consumers中，多个consumer可以加入一个consumer group，以组的身份共同竞争一个topic，topic的消息会被订阅的consumer group内的一个consumer消费。
Consumer需要维护消费的状态：消息是否被消费了，是在consumer这边记录的，这样的不会对集群和其他consumer产生影响，非常轻量级。
1.每一个consumer都是有一个consumer group的，不指定则归属默认的consumer group下。
2.发布订阅模式中，若所有的consumer都在一个consumer group中，那就是队列模式的效果。
3.消费状态是根据offset（偏移量）来确定的，类似于数组的下标。凭借offset，我们可以随心所欲的消费
2.发布订阅模式中，若所有的consumer都在一个consumer group中，那就是队列模式的效果。
3.消费状态是根据offset（偏移量）来确定的，类似于数组的下标。凭借offset，我们可以随心所欲的消费
Topic & Partition
Topic相当于传统MQ的queue，producer发送消息必须指定Topic
Partition（分区）出现的原因：如果一个topic对应一个文件，随着数据量的不断增大，这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition的诞生正是为了处理这个问题：它把topic的消息拆分存储
Topic下的partition是没有上限的，根据具体业务情况来定，一般来说
（1）Topic的partition数量大于等于broker数量，可以提高吞吐率
（2）同一个partition的replica尽量分散到不同机器，高可用
当新加一个partition时，之前的partition数据不会变，新加的partition刚开始是空的，随后进去Topic下的message就会重新参与所有partition的load balance
Partition（分区）出现的原因：如果一个topic对应一个文件，随着数据量的不断增大，这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition的诞生正是为了处理这个问题：它把topic的消息拆分存储
Topic下的partition是没有上限的，根据具体业务情况来定，一般来说
（1）Topic的partition数量大于等于broker数量，可以提高吞吐率
（2）同一个partition的replica尽量分散到不同机器，高可用
当新加一个partition时，之前的partition数据不会变，新加的partition刚开始是空的，随后进去Topic下的message就会重新参与所有partition的load balance
1.一个topic如果有三个partition，这三个partition可能不在同一个broker上。
2.在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是[topicname]_[partition]_[序号]
3.Partition的数量：在创建Topic的时候指定
2.在物理结构上，每个partition对应一个物理的目录（文件夹），文件夹命名是[topicname]_[partition]_[序号]
3.Partition的数量：在创建Topic的时候指定
Topic的解剖图
1.单个Partition内部是有序的，多个partition不保证有序
2.多个Partition内的消息数量并不保证一致
2.多个Partition内的消息数量并不保证一致
Partition & Replica
为了实现故障自动转移，Kafka在0.8版本之后，针对partition增加了Replica（副本）。每个partition可以在其他broker节点存副本，以便某个broker宕机不会影响集群。
存replica副本的方式是按照broker的顺序存的，比如：有5个kafka broker，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1和broker2，partition2存broker2和broker3，以此类推
副本数最大，安全系数越高，但是性能越低；副本数少的话，安全系数较低。
存replica副本的方式是按照broker的顺序存的，比如：有5个kafka broker，某个topic有3个partition，每个partition存2个副本，那么partition1存broker1和broker2，partition2存broker2和broker3，以此类推
副本数最大，安全系数越高，但是性能越低；副本数少的话，安全系数较低。
1.Kafka副本数不能大于broker数
2.Replica的数量：在创建Topic的时候指定（副本数量是包括本身的）
2.Replica的数量：在创建Topic的时候指定（副本数量是包括本身的）
副本分配图
假设集群一共有4个brokers，一个topic有4个partition，每个Partition有3个副本。下图是每个Broker上的副本分配情况。
Controller机制
在Kafka早期，对于分区的状态管理依赖ZK的Watcher，每个broker都要在ZK上注册Watcher，所以ZK会出现太多的Watcher。假如某个broker宕机，而这个宕机的broker上又有很多partition的话，就会造成很多watcher的触发，造成集群内大规模调整。这种设计容易出现羊群效应和ZK集群过敏
KafkaController作为kafka集群的控制者，有且存在一个leader，若干个follower，leader处理所有的读和写操作，然后副本到followers。这样ZK的压力会减小很多
Controller的职责：更新元数据、创建删除topic的行动执行等
KafkaController作为kafka集群的控制者，有且存在一个leader，若干个follower，leader处理所有的读和写操作，然后副本到followers。这样ZK的压力会减小很多
Controller的职责：更新元数据、创建删除topic的行动执行等
官网的一段描述：we elect one of the brokers as the “controller”. This controller detects failures at the broker level and is responsible for changing the leader of all affected partitions in a failed broker. （controller在broker级别就检测出故障，并且负责更改故障broker内的受影响的partition的leader）
Leader机制
和controller机制类似，不能一股脑的把所有节点的监听压力都放到ZK上，也不适合把压力放到controller上面，因为controller的压力已经很大了，所以出现了leader机制。
在Kafka中发生复制时确保partition的日志能有序地写到其他节点上，N个replicas中，其中一个replica为leader，其他都为follower, leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。
在Kafka中发生复制时确保partition的日志能有序地写到其他节点上，N个replicas中，其中一个replica为leader，其他都为follower, leader处理partition的所有读写请求，与此同时，follower会被动定期地去复制leader上的数据。
官网的一段描述：Each partition has one server which acts as the "leader" and zero or more servers which act as "followers". The leader handles all read and write requests for the partition while the followers passively replicate the leader.
ISR副本同步队列
ISR (In-Sync Replicas)，这个是指副本同步队列，是由Kafka维护的列表，往partition写入一条消息，只有被ISR列表中的所有副本写入，才会被视为已提交。在leader发生故障或者宕机的时候，就会在ISR列表选举出一个新的leader（ISR状态存储在ZK）
消息延迟的处理：followers从leader同步消息会有一定延迟（延迟时间和延迟条目 ，新版的0.10.x只支持延迟时间，不支持延迟条目），超出阈值则会被剔除出ISR。
新版为什么移除ISR的“延迟条目”机制？
消息延迟的处理：followers从leader同步消息会有一定延迟（延迟时间和延迟条目 ，新版的0.10.x只支持延迟时间，不支持延迟条目），超出阈值则会被剔除出ISR。
新版为什么移除ISR的“延迟条目”机制？
1。容易被误伤。假如延迟条目设置为10，如果流量高峰，producer一次性发送20条消息到broker，在leader接收到消息而又未同步到followers的那个时间区间，如果被检测到未同步消息，那就会被移除ISR，而实际上该follower是存活的且性能没问题的。
2。无法给出一个适合的值。“延迟条目”是全局的，设置太大了，会影响真正“落后”follower的移除；设置小了，导致follower频繁的进出ISR列表。
3。延迟时间（replica.lag.time.max.ms）是10秒
2。无法给出一个适合的值。“延迟条目”是全局的，设置太大了，会影响真正“落后”follower的移除；设置小了，导致follower频繁的进出ISR列表。
3。延迟时间（replica.lag.time.max.ms）是10秒
Leader的选举
Kafka是在ISR列表顺序选择一个副本。
为什么不使用少数服从多数的方法？
少数服从多数是一种比较常见的Leader选举法，要求超过半数的投票。
这种方法冗余度较高，比如：如果容忍二台机器失败，则需要五台机器。
而使用Kafka的这种方式，则只需要三台机器。
极端情况：假如所有的ISR副本都宕机了，该肿么办？
为什么不使用少数服从多数的方法？
少数服从多数是一种比较常见的Leader选举法，要求超过半数的投票。
这种方法冗余度较高，比如：如果容忍二台机器失败，则需要五台机器。
而使用Kafka的这种方式，则只需要三台机器。
极端情况：假如所有的ISR副本都宕机了，该肿么办？
Kafka提供了两种方案，一种是：等待ISR列表中的副本复活；另一种是：选择一个立即可用的，但是不一定在ISR列表中的副本。
前者保持了一致性，但是，可能需要等待很长时间；后者不需要等待很长时间，但是，又无法保证一致性（高可用性和强一致性的二选一）
kafka默认后者（unclean.leader.election.enable=true）
前者保持了一致性，但是，可能需要等待很长时间；后者不需要等待很长时间，但是，又无法保证一致性（高可用性和强一致性的二选一）
kafka默认后者（unclean.leader.election.enable=true）
Ack机制
Kafka保证消息的送达，提供了三种ACK级别
1：当ack=0，这意味着producer发送出消息即送达，不等待服务器的确认。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
2：当ack=1，表示producer写leader成功，broker就返回成功，没有等待所有
followers写入成功（默认）
3：当ack=-1，producer需要等待ISR中的所有副本都确认接收到数据后才算一
次发送完成，可靠性最高。但是这样也不能100%保证数据不丢失，比如当ISR中只有一个leader时（ISR中的成员由于某些情况会增加也会减少，可能最少就只剩一个leader），这样就变成了ack=1的情况
1：当ack=0，这意味着producer发送出消息即送达，不等待服务器的确认。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
2：当ack=1，表示producer写leader成功，broker就返回成功，没有等待所有
followers写入成功（默认）
3：当ack=-1，producer需要等待ISR中的所有副本都确认接收到数据后才算一
次发送完成，可靠性最高。但是这样也不能100%保证数据不丢失，比如当ISR中只有一个leader时（ISR中的成员由于某些情况会增加也会减少，可能最少就只剩一个leader），这样就变成了ack=1的情况
1。当ack=1，一旦有某个broker宕机导致Partition Follow和leader切换，可能会导致丢数据
2。如果一定要高可靠性，则设置ack=-1且同时设置最小副本数大于1
3。若不满足ACK，produc会抛出异常 NotEnoughReplicas or NotEnoughReplicasAfterAppend
2。如果一定要高可靠性，则设置ack=-1且同时设置最小副本数大于1
3。若不满足ACK，produc会抛出异常 NotEnoughReplicas or NotEnoughReplicasAfterAppend
kafka安装和基本操作
启动ZK
zookeeper-server-start ../../config/zookeeper.properties
启动kafka
kafka-server-start ../../config/server.properties
创建topic
kafka-topics --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --create --topic myTopic
删除指定topic
kafka-topics --zookeeper localhost:2181 --delete --topic topic-test
查看已创建的topic列表
kafka-topics --zookeeper localhost:2181 --list
查看topic的信息
kafka-topics --zookeeper localhost:2181 --describe --topic myTopic
进入指定Topic的 消费控制台
kafka-console-consumer --bootstrap-server localhost:9092 --topic myTopic --from-beginning
进入指定Topic的 生产控制台
kafka-console-producer --broker-list localhost:9092 --topic myTopic