Getting Start
下载
优点和应用场景
- Kafka消息驱动,符合发布-订阅模式,优点和应用范围都共通
- 发布-订阅模式优点
- 解耦合 : 两个应用不需要相互调用
- 可扩展性 : 消费者的个数可实时扩展
- 实时性 : 消费者能实时的获取生产者发布的事件
- 高效 :减少由于多个消费者请求数据造成的数据计算带来的资源消耗
- 异步通讯 :发布-订阅模式是天生的异步通讯
- Kafka其他优点
- 持久化 : 消息丢失的可控性极高
- 高性能 : 磁盘顺序读写性能比内存随机读写还高,每秒10万条消息
- 高吞吐量 :每秒上百MB的吞吐量
- 顺序性
- 发布-订阅模式应用范围
- 适合数据一被生产,就需要被处理的情况
- 适合数据具有潜在消费者的情况
- 适合无论有没有消费者,数据都在生产的情况
- 不适合对数据的处理时间有特殊限定的情况
- 应用场景
- 最为消息中间件,实现消息队列和消息的发布-订阅,消息驱动的服务
- 数据总线,一对多的模式
- 日志收集,消息中间件的一种应用
- 数据库主从同步
核心概念
- Broker
- 一个Kafka server就是一个Broker
- 一般情况下,一个Broker独占一台服务器,发挥微服务的优势
- 服务器资源有限的情况下,需要设计出Broker/Topic/Partition/Replica的最优分配策略,从而充分利用服务器资源
- 一个broker可以有多个topic
- Topic
- 存储消息的逻辑上的消息集合
- 每个Topic有多个分区
- 分区 Partition
- 同一个Topic的不同分区分配在不同Broker上,也就是一个分区一个服务器
- 不同Topic的分区可以共享一个服务器
- 同一个分区的消息是有序的,通过维护offset实现
- 相同key的消息会被发布到同一个分区
- 同一个分区的消息会被一个消费组里固定的一个消费者独占消费
- 通过增加分区来增加并行处理能力
- 每个分区可以有多个副本
- 消费组 Consumer Group
- 实现一个消息只被同组的一个消费者独占消费
- 消费组里的消费者有变化的时候会触发Rebalance操作重新分配分区与消费者的对应关系
- Rebalance操作实现了分区消费的故障转移
- 通过增加分区和消费组里的消费者数量来水平扩展,理想情况一对一,也可以一对多,最好不要多对一,造成浪费
- 副本 Replica
- 同一个分区的不同副本分配在不同Broker上,但是这些Broker可以是在同一台服务器上,也可以不是
- 副本是一个热备份设计,会选举一个作为Leader,提供对外服务
- Fllower副本批量的从Leader副本同步消息
- HW & LEO
- HW是所有ISR副本都有的最新offset,HW之前的消息在所有副本中都存在,HW由Leader副本维护
- 所有消费者只能获取HW之前的消息,这样保证了Leader副本不可用的情况下,所有消费者的状态是一致的
- LEO是每个副本各自的最新offset
- ISR集合
- 满足两个条件的副本会被选入ISR可用副本集合
- 副本与Zookeeper连接
- 副本的LEO与Leader副本的LEO差值不超过阈值
- ISR集合保证了Kafka不会被故障副本拖累,也保证了Leader的HW与LEO的差值在阈值内
- 生产者
- 异步提交
- acks=0 : 生产者只管提交,不会等待Leader副本返回,不保证数据不丢失
- 同步提交
- acks=1 : 默认设置,生产者等待Leader副本返回成功,保证数据在Leader中部丢失,但是不保证重新选举后数据不丢失
- 同步复制
- acks=all : 生产者等待所有副本同步消息后才算提交成功,保证数据不丢失,性能低
- Log
- 一个副本对应一个Log,用于持久化数据,Kafka采用顺序读写的方式,性能高
- 一个Log里有多个Segment,每个Segment有一个日志文件和一个索引文件
- 日志文件的大小有限制,超出后会生成新的Segment
- 日志消息保留策略有两种
- 消息的保留时间超过指定时间,可以被删除
- Topic的存储满,可以开始删除最旧的消息
- 保留策略可以全局配置,也可以按Topic配置
- 日志压缩
- 开启日志压缩后,相同的key会被定期合并,只保留最新的value
Kafka/zookeeper 命令
- 启动Zookeeper
- ./zookeeper-server-start.sh ../config/zookeeper.properties
- 启动Kafka
- ./kafka-server-start.sh ../config/server.properties
- 查看Topic
- ./kafka-topics.sh --list --zookeeper localhost:9860
- 删除Topic
- ./kafka-topics.sh --delete --zookeeper localhost:9860 /kafka --topic test
- 不会立马删除topic
- 查看Topic的详细信息
- ./kafka-topics.sh --zookeeper localhost:9860 --topic test--describe
- 查看zk信息
- ./zookeeper-shell.sh 127.0.0.1:9860
- 生产数据
- ./kafka-console-producer.sh --broker-list cvatap3d.nam.nsroot.net:9801 --topic midcurve-ds
- 消费数据
- ./kafka-console-consumer.sh --zookeeper localhost:9860 --topic midcurve-ds-subscribe --from-beginning
Kafka集群
zookeeper集群配置 : zookeeper.properties
- clientPort=2180
- 端口号
- dataDir=/tmp/zookeeper
- 集群信息记录目录,清空目录可以重置zookeeper
- 如果需要在同一台server上启动多个node,这个路径必须不同
- tickTime=2000
- zookeeper副本与leader之间维护心跳的频率
- initLimit=5
- zookeeper的leader初始化连接follower时等待多少个tickTime时间的心跳,超时副本连接失败
- syncLimit=2
- 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
- 第一个启动的为leader
- zookeeper集群数量必须是基数3,5,7...
- 0,1,2是服务id,需要在对应的dataDir=/tmp/zookeeper下面创建myid文件,内容就是服务id,比如0
- ip或者host都可以
- 后面两个端口是zookeeper内部通讯使用
- 第一个端口是用于副本与Leader建立TCP连接
- 第二个端口是用于Leader选举的TCP端口
Kafka配置 : server.properties
- broker.id=0
- 同一个zookeeper集群下的broker的id必须唯一
- log.dirs=/tmp/kafka-logs
- 启动kafka会从zookeeper下载配置到log目录
- 如果修改了server.properties可能因为配置与存储的配置不匹配导致启动失败,这时候可以删除这个目录
- 如果需要在同一台server上启动多个broker,这个路径必须不同
- zookeeper.connect=localhost:2181
- zookeeper集群,以逗号隔开
- listeners=PLAINTEXT://cvatap3d.nam.nsroot.net:9093
- broker的host:port
zookeeper与kafka
- Kafka将Broker信息注册到zookeeper
- zookeeper会维护topic与broker的关系,选举Leader
- 监控partition leader存活性,发现Leader异常会重新选举Leader
- 当异常Broker恢复后,会在一段时间后重新分配Leader
- Broker从zookeeper获取集群中其它Broker信息
- Consumer端将自己注册到zookeeper
- 用来获取broker列表
- 并和partition leader建立socket连接
- 在Consumer Group发生变化时进行rebalance
- Zookeeper管理consumer的offset跟踪当前消费的offset。
- Producer端将自己注册到zookeeper
- 用来获取broker列表和分区状态,从而将消息发布到正确的Broker
- Zookeeper不管理producer
Kafka使用经验总结
Consumer
- Consumer默认自动提交Offset,并且是一获取便提交,默认间隔5秒
- 当发生错误重启,如果你当消费能力强,可能造成重复消费5秒内当Offset
- 如果消费能力比较弱,也可能提交的Offset没有消费完,造成Offset丢失
- 消费者使用pull的方式去拿消息
- 简化kafka实现,消费者自己控制消费进度,不会有消息积压的压力
- kafka通过长轮询/长连接来提高pull的实时性
- 可以设置消费端缓存消息大小:queue.buffering.max.meesages ,在自动提交模式下缓存大小需要适当控制
Kafka强一致性保证
- Producer同步复制,性能下降
- Kafka幂等设置
- Kafka使用Produce Id和sequence number实现幂等,判断一次提交的所有消息的seq num一样,Produce Id由zookeeper随机生成,每次不一样
- 单分区幂等,不支持分区幂等,也就是当重新分配key与分区关系当时候不支持幂等
- 单会话幂等,不提供重启Prodicer后单幂等
- Kafka当幂等大部分情况下有效,单不能完全信任
- enabled.idempotence=true, 此时就会默认把acks设置为all,所以不需要再设置acks属性了。也就是说幂等自动开启同步复制?
- 消费者手动提交offset
- 分区事物管理
- 安全关闭
- producer.close():优先把消息处理完毕,优雅退出。
- producer.close(timeout): 超时时,强制关闭。
- 可重试/不可重试异常区别对待
Spring Cloud Stream 使用Kafka
Producer 生产数据
- 随机发送
- spring.cloud.stream.bindings.[channelName].producer.partitionKeyExpression不设置
- spring.cloud.stream.bindings.[channelName].producer.partitionCount=10
- 如果partitionCount > Partition数量, 会报错,但如果autoAddPartitions=true,则不报错而自动添加Partition,与instanceCount无关
- 如果如果partitionCount < Partition数量,则会被Partition数量覆盖
- 定向发送
- spring.cloud.stream.bindings.[channelName].producer.partitionKeyExpression=payload.currency
- 当Partition变多后,重启会重新分配,但是不重启的情况下还是保持不变,也就是说消费者自动添加Partiton后,还需要重启生产者
Consumer Offset管理
- Offset的起驶位置
- spring.cloud.stream.kafka.bindings.channelName.consumer.resetOffsets
- true : 每次从startOffset开始
- false:从Consumer当前位置开始
- spring.cloud.stream.kafka.bindings.channelName.consumer.startOffset
- 新消费组都起驶位置,latest=0, earliest=lastOffset+1
- 不设置组名:groupId=anonymous
- resetOffsets 默认true, startOffset 默认latest, 所以默认每次都从最新都消息消费
- 无法设置resetOffsets=false,因为无法知道它当前Offset,但是可以改变startOffset
- 设置组名:
- spring.cloud.stream.bindings..group
- resetOffsets 默认false, startOffset 默认earliest, 所以新消费组默认从0开始消费,并且拥有记录Offset能力
- Offset 提交
- spring.cloud.stream.kafka.bindings.channelName.consumer.autoCommitOffset
- 默认true, 自动提交Offset
- false会在Message对象都header字段里添加一个kafka_acknowledgment对象,可以用来手动提交offset
- 但是它的AckMode.MANUAL并不是立刻提交的,而是所有pull到的Offset都处理后批量自动提交,所以只能控制哪些Offset需要提交,不能控制什么时候提交
- spring.cloud.stream.kafka.bindings.channelName.consumer.ackEachRecord
- 默认false:当所有一次pull到的Offset都消费完里之后(@StreamListener都方法执行完),才会自动提交Offset
- true: 每一个消息消费完都提交Offset
- Offset管理的是最后提交的Offset,而不是处理好的Offset的list
Consumer Partition分配
- 自动分配
- spring.cloud.stream.kafka.bindings.channelName.consumer.autoRebalanceEnabled=true
- 自动分配Partition给消费组成员,并且会在当前pull的消息被处理完后才分配,有效避免消息被重复消费,但是也不能完全信任,比如消息处理缓慢造成心跳失败或者pull轮询使得它直接认为成员丢失而进行rebalance,但是数据其实还在处理
- 如果Comsumer数量 > Partition数量, Consumer会闲置, 但如果autoAddPartitions=true,会根据 max(instanceCount*concurrency,minPartitionCount)自动添加,并在一段时间后自动分配
- 自动分配与instanceCount/instanceIndex。对concurrency的处理和手动分配一样
- 手动分配
- autoRebalanceEnabled=false
- spring.cloud.stream.instanceCount : 根据Partition数量/(instanceCountconcurrency)数量来决定分配到这个instance的Partition。如果instanceCountconcurrency > Partition数量, 会报错, 但如果autoAddPartitions=true,则不报错而自动添加Partition
- spring.cloud.stream.instanceIndex : iinstanceIndex必须在indexCount范围内。如果index一样,将消费相同Partition的消息,这样就违反了一个Partition只能被一个Comsumer Member消费的原则,造成消息的重复消费
- spring.cloud.stream.bindings.channelName.consumer.partitioned????????
- Instance并发消费
- spring.cloud.stream.bindings.channelName.consumer.concurrency=10
- 同一个instance的同一个channel的多个消费者Listener也会消费相同Partition的消息,并且是同步处理,造成低性能的消息的重复消费,与concurrency无关,也就是说spring的一个instance的一个channel就只能有一个consumer的@StreamListener。是否可以定义多个channel监听同一个topic来实现instance级别的concurrency?
- concurrency=10代表你想在一个instance中启动10consumer线程去处理10个partition的message
数据强一致性
- 保证消息至少被发送一次
- 保证消息只被发送一次
- 保证消息至少被消费一次
- ackEachRecord=false保证消息至少被消费一次,但是可以有一整批消息会被消费多次
- ackEachRecord=true保证消息至少被消费一次,而且保证Consumer故障减少后?消息不会被重复消费,但是不保证增加Consumer
- 保证消息只被消费一次
性能优化
在线水平伸缩
|
|
|