kafka 环境配置:JDK1.8
SSH安装配置:对于kafka 集群来讲,配置ssh免密登录不是必须的步骤,但分布式系统,一般会由多台机器构成,为了便于操作管理,一般通过ssh方式启动集群代理。
安装ssh:
sudo apt-get install ssh
进入.ssh目录,生成秘钥对:
ssh-keygen -t rsa
ssh-keygen 用于生成认证秘钥,-t 用来指定秘钥类型,这里选择rsa 秘钥。执行完毕后会在.ssh 目录下生成is_rsa 和 id_rsa.pub 两个文件,前者是私钥,后者是公钥。
ZooKeeper 环境:
ZooKeeper 是分布式应用程序协调服务框架,分布式应用程序可以基于 ZooKeeper 实现同步服务、配置维护、命名服务等, ZooKeeper 能提供基于类似于文件系统的目录节点树 方式的数据存储,通过监控各节点数据状态的变化,达到基于数据的集群管理。
zookeeper 集群主要角色说明:
leader :集群的领导者,负责投票的发起和决议及更新系统状态。
follower: 跟随者,接受客户端的请求并返回结果给客户端,参与投票。
observer: 接受客户端的请求,将写的请求转发给leader,不参与投票。observer 目的是扩展系统,提高读的速度。
Kafka 依赖 ZooKeeper ,通过 ZooKeeper 来对代理、消费者上下线管理、集群、分区元数据管理等,因此 ZooKeeper 也是 Kafka 得以运行的基础环境之一。
zookeeper 安装参考:CSDN
kafka 下载链接:https://pan.baidu.com/s/1b2lN_0IhA4zx3f-mt49j3Q 提取码:pb7y
kafka 安装参考: kafka --第一章:基础知识_welcome to 一点点 home-CSDN博客
kafka Manager 下载链接:链接:https://pan.baidu.com/s/1tW_5diGSg2ZhJFAnwy4w9w 提取码:bps9
kafka Manager 安装参考:kafka --第一章:基础知识_welcome to 一点点 home-CSDN博客
Kafka manager 安装:查看集群中代理列表,主题列表,消费组列表,每个主题对应的分区列表等,通过web界面操作来创建一个主题或者在代理负载不均衡时,手动执行分区平衡操作等。kafka 监控及管理工具:kafka Manager,kafka web console, kafkaOffsetMonitor等工具都可以。
kafka 核心组件包括:延迟操作组件,控制器,协调器,网络通信,日志管理器,副本管理器,动态配置管理器及心跳检测等。
1.延迟操作组件:协助客户端处理创建主题操作,协助组协调器处理JoinGroupRequest 和HeartBeatRequest请求,协助副本管理器处理ProduceRequest 和 FetchRequest 请求。
2.delayedoperation:kafka 将一些不立即执行而要等到满足一定条件之后才触发完成的操作称为延迟操作,并将这类操作定义为一个抽象类DelayedOperation ,DelayedOperation 是一个基于事件启动有失效事件的TimerTask。TimerTask实现了Runnable 接口,维护了一个TimerTaskEntry对象,TimerTaskEntry 绑定了一个TimerTask,TimerTaskEntry 被添加到TimerTaskList中,TimerTaskList 是一个环形双向链表,按失效时间排序。
DelayedOperation 是一个抽象类,具体的延迟操作类继承于该抽象类,分别用来协助相应组件对不同的请求完成延迟处理请求。
DelayedOperation 只有一个AtomicBoolean 类型的completed 属性,用来控制某个延迟操作。在延迟时间delayMs 内,onComplete 方法只被调用一次。
tryComplete()方法: 一个抽象方法,由子类来实现,负责检测执行条件是否满足 若满足执行条件,则调用forceComplete()方法完成延迟操作。
• forceCompete()方法: 该方法在条件满足时,检测延迟任务是否未被执行。若未被执行,则先调用 TimerTask.cancel()方法解除该延迟操作与 TimerTaskEntry 的绑定,将该延迟操作TimerTaskList 链表中移除,然后调用 onComplete()方法让延迟操作执行完成 通过completed CAS 原子操作(completed.compareAndSet),可以保证并发操作时只有第一个调用该方法的线程能够顺利调用 onComplete()完成延迟操作,其他线程获取的 ompleted属性false ,即不会调用 onComplete()方法 ,这就保证了 onComplete() 只会被调用一次。
• onComplete()方法:是一个抽象方法,由子类来实现,执行延迟操作满足执行条件后需要执行的实际业务逻辑。 例如, DelayedProduce 和 DelayedFetch 都是在该方法内调用responseCallback 客户端做出响应。
safeTryComplete()方法:以synchronized 同步锁调用 onComplete()方法,供外部调用。
• onExpiration()方法:一个抽象方法,由子类来实现当延迟操作己达失效时间的相应逻辑处理。 Kafka 通过 SystemTimer 来定期检测请求是否超时。 SystemTimer 是Kafka实现的底层基于层级时间轮和 DelayQueue 定时器 维护了 newFixedThreadPool 线程
池,用于提交相应的线程执行。例如,当检测到延迟操作己失效时则将延迟操作提交到该线程池,即执行线程的 run()方法的逻辑。 DelayedOperation 覆盖了 TimerTask run()方法,在该方法中先调用 forceCompeteO方法,当该方法返回 true 后再调用 onExpiration()方法。
DelayedOperationPurgatory
DelayedOperationPurgatory 是一个对DelayedOperation 管理的辅助类。
watch() 方法: 用于将DelayedOperation 添加到operations 集合中。
tryCompleteWatched()方法: 用于迭代operations 集合中的DelayOperation ,通过DelayedOperation.isCompleted检测该DelayedOperation 是否已执行完成。若已执行完成,则从operations 集合中移除该DelayedOperation ,否则调用DelayedOperation.safeTryComplete()方法尝试让该DelayedOperation 执行完成,若执行完成,即safeTryComplete()方法返回true,则将DelayedOperation从operations 集合中移除,最后检测operations 集合是否为空,如果为空,则表示operations 所关联的DelayedOperation 已全部执行完成,因此将Watchers 从 Purgatory 的 Pool 中移除。
主题作为消息的归类,可以细分为一个分区或多个分区,分区可以看作对消息的二次归类。分区的划分不仅为Kafka提供了可伸缩性,水平扩展的功能,还通过多副本机制来为Kafka提供数据冗余以提高数据可能性。
分区可以有一个到多个副本,每个副本对应一个日志文件,每个日志文件对应一到多个日志分段,每个日志分段还可以细分为索引文件,日志存储文件和快照文件等。
消息中间件的性能一般是指吞吐量,性能一般根机器,消息写入的吞吐量还会受到消息的大小,压缩方式,消息发送方式(同步/异步),消息确认类型(acks),副本因子等参数影响,消息消费的吞吐量还会受到应用逻辑处理速度的影响。
目前Kafka只支持增加分区数而不支持减少分区数。如果减少,会报错invalidPartitionException。
Kafka-configs.sh 脚本是专门用来堆配置进行操作的,这里的操作是指在运行状态下修改原有的配置,如此可以达到动态变更的目的。Kafka-configs.sh脚本包含变更配置alter和查看配置describe这两种指令类型。同使用Kafka- topics.sh脚本变更配置的原则一样,增删改的行为都可以看作变更操作,不过Kafka- config.sh脚本不仅可以支持主题相关的配置,还可以支持操作broker,用户和客户端这3个类型的配置。
分区使用多副本机制来提升可靠性,但只有leader副本对外提供读写服务,而follower副本只负责在内部进行消息的同步。如果一个分区的leader副本不可用,那么就意味着整个分区变得不可用,此时就需要Kafka从剩余的follower副本中挑选一个新的leader副本来继续对外提供服务。
当Kafka集群的broker宕机或崩溃的问题,当分区的leader节点发生故障时,其中一个follower节点就会成为新的leader节点,这样就会导致集群的负载不均衡,从而影响整体的健壮性和稳定性。当原来的leader节点恢复之后重新加入集群时,它只能成为一个新的follower节点而不再对外提供服务。
解决负载均衡问题:为了能够有效的治理负载均衡的情况,Kafka引入来优先副本的概念。所谓的优先副本是指在AR集合列表中的第一个副本。理想情况下,优先副本就是该分区的leader副本,所以也可以称之为preferred leader。Kafka要确保所有主题的优先副本在Kafka集群中均匀分布,这样就保证来所有分区的leader均衡分布。如果leader分布过于集中,就会造成集群负载不均衡。
所谓的优先副本的选举是指通过一定的方式促使优先副本选举为leader副本,以此来促进集群的负载均衡,这一行为称为分区平衡。
分区重分配堆集群的性能有很大的影响,需要占用额外的资源,比如网络和磁盘。在实际操作中,我们将降低重分配的粒度,分成多个小批次来执行,以此来将负面的影响降到最低,这一点和优先副本的选举有异曲同工之妙。
注意:如果要将某个broker下线,那么在执行分区重分配动作之前最好先关闭或重启broker。这样这个broker就不再是任何分区的leader节点来。它的分区就可以被分配给集群中的其他broker。这样可以减少broker间的流量复制,以此提升重分配的性能,以及减少对集群的影响。
复制限流:分区重分配的本质在于数据复制,先增加新的副本,然后进行数据同步,最后删除旧的副本来达到最终的目的,数据复制会占用额外的资源,如果重分配的量太大必然会严重影响整体的性能,尤其是处于业务高峰期的时候。减小重分配的粒度,以小批次的方式来操作是一种可行的解决思路。如果集群中某个主题或某个分区的流量在某段时间内特别大,那么只靠减小粒度是不足以应对的,这时需要有一个限流的机制,可以对副本间的复制流量加以限制来保证重分配期间整体服务不会受太大的影响。
副本间的复制限流有两种实现方式:Kafka-config.sh脚本和Kafka-reassign-partitions.sh脚本。
如何选择合适的分区数:要根据实际的业务场景,软件条件,硬件条件,负载均衡情况等来做具体的考量。
性能测试工具:性能与分区数有着必然的关系,在设定分区数时一般也需要考虑性能的因素。通过Kafka-producer-perf-test.sh脚本的使用。
消息中间件的性能一般是指吞吐量。除了跟硬件资源有关,消息写入的吞吐量还会受到消息大小,消息压缩方式,消息发送方式(同步/异步),消息确认类型,副本因子等参数的影响,消息消费的吞吐量还会受到应用逻辑处理速度的影响。
偏移量索引文件用来遍历消息偏移量offset到物理地址之间的映射关系,方便快速定位消息所在的物理文件位置; |
时间戳索引文件则根据指定的时间戳timestamp来查找对应的偏移量信息。 |