Apache Kafka 源码剖析

Getting Start

下载

• http://kafka.apache.org/

优点和应用场景

• Kafka消息驱动，符合发布-订阅模式，优点和应用范围都共通
• 发布-订阅模式优点
  1. 解耦合 ： 两个应用不需要相互调用
  2. 可扩展性 ： 消费者的个数可实时扩展
  3. 实时性 ： 消费者能实时的获取生产者发布的事件
  4. 高效 ：减少由于多个消费者请求数据造成的数据计算带来的资源消耗
  5. 异步通讯 ：发布-订阅模式是天生的异步通讯
• Kafka其他优点
  1. 持久化 ： 消息丢失的可控性极高
  2. 高性能 ： 磁盘顺序读写性能比内存随机读写还高，每秒10万条消息
  3. 高吞吐量 ：每秒上百MB的吞吐量
  4. 顺序性
• 发布-订阅模式应用范围
  1. 适合数据一被生产，就需要被处理的情况
  2. 适合数据具有潜在消费者的情况
  3. 适合无论有没有消费者，数据都在生产的情况
  4. 不适合对数据的处理时间有特殊限定的情况
• 应用场景
  1. 最为消息中间件，实现消息队列和消息的发布-订阅，消息驱动的服务
  2. 数据总线，一对多的模式
  3. 日志收集，消息中间件的一种应用
  4. 数据库主从同步

核心概念

• Broker
  1. 一个Kafka server就是一个Broker
  2. 一般情况下，一个Broker独占一台服务器，发挥微服务的优势
  3. 服务器资源有限的情况下，需要设计出Broker/Topic/Partition/Replica的最优分配策略，从而充分利用服务器资源
  4. 一个broker可以有多个topic
• Topic
  1. 存储消息的逻辑上的消息集合
  2. 每个Topic有多个分区
• 分区 Partition
  1. 同一个Topic的不同分区分配在不同Broker上，也就是一个分区一个服务器
  2. 不同Topic的分区可以共享一个服务器
  3. 同一个分区的消息是有序的，通过维护offset实现
  4. 相同key的消息会被发布到同一个分区
  5. 同一个分区的消息会被一个消费组里固定的一个消费者独占消费
  6. 通过增加分区来增加并行处理能力
  7. 每个分区可以有多个副本
• 消费组 Consumer Group
  1. 实现一个消息只被同组的一个消费者独占消费
  2. 消费组里的消费者有变化的时候会触发Rebalance操作重新分配分区与消费者的对应关系
  3. Rebalance操作实现了分区消费的故障转移
  4. 通过增加分区和消费组里的消费者数量来水平扩展，理想情况一对一，也可以一对多，最好不要多对一，造成浪费
• 副本 Replica
  1. 同一个分区的不同副本分配在不同Broker上，但是这些Broker可以是在同一台服务器上,也可以不是
  2. 副本是一个热备份设计，会选举一个作为Leader，提供对外服务
  3. Fllower副本批量的从Leader副本同步消息
• HW & LEO
  1. HW是所有ISR副本都有的最新offset，HW之前的消息在所有副本中都存在,HW由Leader副本维护
  2. 所有消费者只能获取HW之前的消息，这样保证了Leader副本不可用的情况下，所有消费者的状态是一致的
  3. LEO是每个副本各自的最新offset
• ISR集合
  1. 满足两个条件的副本会被选入ISR可用副本集合
     1. 副本与Zookeeper连接
     2. 副本的LEO与Leader副本的LEO差值不超过阈值
  2. ISR集合保证了Kafka不会被故障副本拖累，也保证了Leader的HW与LEO的差值在阈值内
• 生产者
  1. 异步提交
     1. acks=0 : 生产者只管提交，不会等待Leader副本返回，不保证数据不丢失
  2. 同步提交
     1. acks=1 : 默认设置，生产者等待Leader副本返回成功，保证数据在Leader中部丢失，但是不保证重新选举后数据不丢失
  3. 同步复制
     1. acks=all : 生产者等待所有副本同步消息后才算提交成功，保证数据不丢失，性能低
• Log
  1. 一个副本对应一个Log，用于持久化数据，Kafka采用顺序读写的方式，性能高
  2. 一个Log里有多个Segment，每个Segment有一个日志文件和一个索引文件
  3. 日志文件的大小有限制，超出后会生成新的Segment
  4. 日志消息保留策略有两种
     1. 消息的保留时间超过指定时间，可以被删除
     2. Topic的存储满，可以开始删除最旧的消息
     3. 保留策略可以全局配置，也可以按Topic配置
  5. 日志压缩
     1. 开启日志压缩后，相同的key会被定期合并，只保留最新的value

Kafka/zookeeper 命令

1. 启动Zookeeper
   1. ./zookeeper-server-start.sh ../config/zookeeper.properties
2. 启动Kafka
   1. ./kafka-server-start.sh ../config/server.properties
3. 查看Topic
   1. ./kafka-topics.sh --list --zookeeper localhost:9860
      
4. 删除Topic
   1. ./kafka-topics.sh --delete --zookeeper localhost:9860 /kafka --topic test
   2. 不会立马删除topic
5. 查看Topic的详细信息
   1. ./kafka-topics.sh --zookeeper localhost:9860 --topic test--describe
6. 查看zk信息
   1. ./zookeeper-shell.sh 127.0.0.1:9860
      
7. 生产数据
   1. ./kafka-console-producer.sh --broker-list cvatap3d.nam.nsroot.net:9801 --topic midcurve-ds
8. 消费数据
   1. ./kafka-console-consumer.sh --zookeeper localhost:9860 --topic midcurve-ds-subscribe --from-beginning

Kafka集群

zookeeper集群配置 ： zookeeper.properties

• clientPort=2180
  1. 端口号
• dataDir=/tmp/zookeeper
  1. 集群信息记录目录，清空目录可以重置zookeeper
  2. 如果需要在同一台server上启动多个node，这个路径必须不同
• tickTime=2000
  1. zookeeper副本与leader之间维护心跳的频率
• initLimit=5
  1. zookeeper的leader初始化连接follower时等待多少个tickTime时间的心跳，超时副本连接失败
• syncLimit=2
  1. leader与follower之间发送消息,请求和应答超时是多少个tickTime
• server.0=cvatap3d.nam.nsroot.net:2888:3888
• server.1=cvatap3d.nam.nsroot.net:2889:3889
• server.2=cvatap3d.nam.nsroot.net:2890:3890
  1. 第一个启动的为leader
  2. zookeeper集群数量必须是基数3,5,7...
  3. 0，1，2是服务id，需要在对应的dataDir=/tmp/zookeeper下面创建myid文件，内容就是服务id，比如0
  4. ip或者host都可以
  5. 后面两个端口是zookeeper内部通讯使用
     1. 第一个端口是用于副本与Leader建立TCP连接
     2. 第二个端口是用于Leader选举的TCP端口

Kafka配置 ： server.properties

• broker.id=0
  1. 同一个zookeeper集群下的broker的id必须唯一
• log.dirs=/tmp/kafka-logs
  1. 启动kafka会从zookeeper下载配置到log目录
  2. 如果修改了server.properties可能因为配置与存储的配置不匹配导致启动失败，这时候可以删除这个目录
  3. 如果需要在同一台server上启动多个broker，这个路径必须不同
• zookeeper.connect=localhost:2181
  1. zookeeper集群，以逗号隔开
• listeners=PLAINTEXT://cvatap3d.nam.nsroot.net:9093
  1. broker的host:port

zookeeper与kafka

• Kafka将Broker信息注册到zookeeper
  1. zookeeper会维护topic与broker的关系，选举Leader
  2. 监控partition leader存活性,发现Leader异常会重新选举Leader
  3. 当异常Broker恢复后，会在一段时间后重新分配Leader
  4. Broker从zookeeper获取集群中其它Broker信息
• Consumer端将自己注册到zookeeper
  1. 用来获取broker列表
  2. 并和partition leader建立socket连接
  3. 在Consumer Group发生变化时进行rebalance
  4. Zookeeper管理consumer的offset跟踪当前消费的offset。
• Producer端将自己注册到zookeeper
  1. 用来获取broker列表和分区状态，从而将消息发布到正确的Broker
  2. Zookeeper不管理producer

Kafka使用经验总结

Consumer

• Consumer默认自动提交Offset，并且是一获取便提交，默认间隔5秒
  1. 当发生错误重启，如果你当消费能力强，可能造成重复消费5秒内当Offset
  2. 如果消费能力比较弱，也可能提交的Offset没有消费完，造成Offset丢失
• 消费者使用pull的方式去拿消息
  1. 简化kafka实现，消费者自己控制消费进度，不会有消息积压的压力
  2. kafka通过长轮询/长连接来提高pull的实时性
  3. 可以设置消费端缓存消息大小：queue.buffering.max.meesages ，在自动提交模式下缓存大小需要适当控制

Kafka强一致性保证

• Producer同步复制，性能下降
• Kafka幂等设置
  1. Kafka使用Produce Id和sequence number实现幂等，判断一次提交的所有消息的seq num一样，Produce Id由zookeeper随机生成，每次不一样
  2. 单分区幂等，不支持分区幂等，也就是当重新分配key与分区关系当时候不支持幂等
  3. 单会话幂等，不提供重启Prodicer后单幂等
  4. Kafka当幂等大部分情况下有效，单不能完全信任
  5. enabled.idempotence=true, 此时就会默认把acks设置为all，所以不需要再设置acks属性了。也就是说幂等自动开启同步复制？
• 消费者手动提交offset
• 分区事物管理
• 安全关闭
  1. producer.close()：优先把消息处理完毕，优雅退出。
  2. producer.close(timeout): 超时时，强制关闭。
• 可重试/不可重试异常区别对待

Spring Cloud Stream 使用Kafka

Producer 生产数据

• 随机发送
  1. spring.cloud.stream.bindings.[channelName].producer.partitionKeyExpression不设置
  2. spring.cloud.stream.bindings.[channelName].producer.partitionCount=10
     1. 如果partitionCount > Partition数量， 会报错，但如果autoAddPartitions=true,则不报错而自动添加Partition，与instanceCount无关
     2. 如果如果partitionCount < Partition数量，则会被Partition数量覆盖
• 定向发送
  1. spring.cloud.stream.bindings.[channelName].producer.partitionKeyExpression=payload.currency
  2. 当Partition变多后,重启会重新分配，但是不重启的情况下还是保持不变，也就是说消费者自动添加Partiton后，还需要重启生产者

Consumer Offset管理

• Offset的起驶位置
  1. spring.cloud.stream.kafka.bindings.channelName.consumer.resetOffsets
     1. true : 每次从startOffset开始
     2. false：从Consumer当前位置开始
  2. spring.cloud.stream.kafka.bindings.channelName.consumer.startOffset
     1. 新消费组都起驶位置，latest=0, earliest=lastOffset+1
• 不设置组名：groupId=anonymous
  1. resetOffsets 默认true, startOffset 默认latest, 所以默认每次都从最新都消息消费
  2. 无法设置resetOffsets=false，因为无法知道它当前Offset，但是可以改变startOffset
• 设置组名：
  1. spring.cloud.stream.bindings..group
  2. resetOffsets 默认false, startOffset 默认earliest, 所以新消费组默认从0开始消费，并且拥有记录Offset能力
• Offset 提交
  1. spring.cloud.stream.kafka.bindings.channelName.consumer.autoCommitOffset
     1. 默认true, 自动提交Offset
     2. false会在Message对象都header字段里添加一个kafka_acknowledgment对象，可以用来手动提交offset
     3. 但是它的AckMode.MANUAL并不是立刻提交的，而是所有pull到的Offset都处理后批量自动提交，所以只能控制哪些Offset需要提交，不能控制什么时候提交
  2. spring.cloud.stream.kafka.bindings.channelName.consumer.ackEachRecord
     1. 默认false：当所有一次pull到的Offset都消费完里之后（@StreamListener都方法执行完），才会自动提交Offset
     2. true: 每一个消息消费完都提交Offset
  3. Offset管理的是最后提交的Offset,而不是处理好的Offset的list

Consumer Partition分配

• 自动分配
  1. spring.cloud.stream.kafka.bindings.channelName.consumer.autoRebalanceEnabled=true
  2. 自动分配Partition给消费组成员，并且会在当前pull的消息被处理完后才分配，有效避免消息被重复消费,但是也不能完全信任，比如消息处理缓慢造成心跳失败或者pull轮询使得它直接认为成员丢失而进行rebalance，但是数据其实还在处理
  3. 如果Comsumer数量 > Partition数量， Consumer会闲置, 但如果autoAddPartitions=true,会根据 max(instanceCount*concurrency,minPartitionCount)自动添加，并在一段时间后自动分配
  4. 自动分配与instanceCount/instanceIndex。对concurrency的处理和手动分配一样
• 手动分配
  1. autoRebalanceEnabled=false
  2. spring.cloud.stream.instanceCount : 根据Partition数量/（instanceCountconcurrency）数量来决定分配到这个instance的Partition。如果instanceCountconcurrency > Partition数量, 会报错, 但如果autoAddPartitions=true,则不报错而自动添加Partition
  3. spring.cloud.stream.instanceIndex : iinstanceIndex必须在indexCount范围内。如果index一样，将消费相同Partition的消息,这样就违反了一个Partition只能被一个Comsumer Member消费的原则，造成消息的重复消费
  4. spring.cloud.stream.bindings.channelName.consumer.partitioned????????
• Instance并发消费
  1. spring.cloud.stream.bindings.channelName.consumer.concurrency=10
  2. 同一个instance的同一个channel的多个消费者Listener也会消费相同Partition的消息，并且是同步处理，造成低性能的消息的重复消费,与concurrency无关，也就是说spring的一个instance的一个channel就只能有一个consumer的@StreamListener。是否可以定义多个channel监听同一个topic来实现instance级别的concurrency？
  3. concurrency=10代表你想在一个instance中启动10consumer线程去处理10个partition的message

数据强一致性

• 保证消息至少被发送一次
• 保证消息只被发送一次
• 保证消息至少被消费一次
  1. ackEachRecord=false保证消息至少被消费一次，但是可以有一整批消息会被消费多次
  2. ackEachRecord=true保证消息至少被消费一次，而且保证Consumer故障减少后？消息不会被重复消费，但是不保证增加Consumer
• 保证消息只被消费一次

性能优化

在线水平伸缩

转载于:https://www.cnblogs.com/judesheng/p/10621682.html