网站维护常识,网站设计机构图,如何做php网站,做资源教程网站kafka是一个优秀大吞吐消息队列#xff0c;下面我就从实用的角度来讲讲kafka中#xff0c;“kafka为何有大吞吐的机制”#xff0c;“数据不丢失问题”#xff0c;“精准一次消费问题” 01、kafka的架构组织和运行原理 kafka集群各个节点的名称叫broker#xff0c;因为kaf… kafka是一个优秀大吞吐消息队列下面我就从实用的角度来讲讲kafka中“kafka为何有大吞吐的机制”“数据不丢失问题”“精准一次消费问题” 01、kafka的架构组织和运行原理 kafka集群各个节点的名称叫broker因为kafka是一个消息队列所以对应着有producer和consumer。在数据组织层面来说kafka是通过topic来区分同一类数据但是topic是抽象的概念具体组织数据的Partition它是物理的文件topic中的数据会具体落在各个Partition中一个Partition的数据又有多个segment组成segment也是抽象的segment中包含了log和index文件这才是kafka具体存储数据的文件。 02、kafka为什么能实现低延迟高吞吐 kafka通过如下的技术实现它的低延迟高吞吐 Zero Copy零拷贝 技术 kafka的零拷贝技术在代码层面是调用Java的NIO包下的FileChannel实现其中的transferTo()方式是具体实现零拷贝方法。 零拷贝的具体实现需要操作系统和硬件的支持在Linux中上述的transferTo方法最终会调用到底层的sendfile方法实现如下图sendfile方法只需要进行2次“上下文切换”和2次的DMA数据拷贝即可完成数据的读写操作对应kafka的数据生产和消费DMA它是一种无须CPU参与就能直接把内存数据和外设数据进行交换的设备是CPU读写大批量数据的一种替代设备 Page Cache页缓存 磁盘顺序读写 当数据写入磁盘的时数据会被先写入Page Cache一般操作系统是按照4kb划分一个Page根据一定机制再把一批Page刷到磁盘中这样就会有一批生产者产生的数据其实还是在操作系统内存中的此时如果consumer在拉取数据直接从Page Cache中就能拿到如果生产者和消费者的速率差不多的情况下kafka相当于是基于内存在读写数据而且kafka在flush到磁盘的时候数据是按照磁盘顺序读写这样也大大提升了刷写的速度。 分区分段 索引 kafka中通过Partition把topic中的数据分成若干份放入broker中在Partition中数据其实是按照一个个小的segment存储的这也非常符合很多分布式系统的分区分桶的思路。与此同时kafka也给一个个segment建立了稀疏索引文件也就是哪些xxxx.index和xxxx.timestapindex文件 批量读写 同时kafka在读写的时候也都是按照批操作的这样相对于单条处理来说减少了不必要的额外传输开销 批量压缩 压缩可以通过减少message的体积使数据在网络传输时得到很大优化
03、kafka中如何实现CAP原则 CAP 原则是指在一个分布式系统中对于一致性可用性和分区容忍性是不能同时满足的总的来说kafka不是严格的只实现CAP原则中的某两个放弃其中一个它是一种动态的平衡 kafka通过多副本的ISR机制实现分区容忍性 kafka对于每个topic会提供多个一模一样的副本然后在这些副本中选出一个leader来对外提供读写服务。其中这些正常的副本会在一个ISR的集合中如果其中一个副本挂掉就会被踢出ISR但是服务正常可用如果是leader挂掉此次会根据配置让ISR中的副本选举出新的leader对外提供服务这里就牺牲了系统的可用性 kafka通过高水位机制实现数据的一致性 kafka通过牺牲follow副本的可用性只允许leader副本对外提供读写服务来提高数据的一致性这在一致性的实现上简单很多。具体来说kafka是通过只对外提供高水位以下的数据访问从而实现各个副本之间数据的最终一致性。 在版本的kafka中高水位机制会出现丢数据和数据不一致的情况在高版本中通过epoch机制修复了这样的问题。 kafka对于可用性来说没有做到那么严格比如leader副本所在的机器有问题对应的topic短暂不可用一直要到新的leader选举成功才行
04、数据不丢失的具体实现
broker端 通过配置不能让落后太多的副本参加leader的选举unclean.leader.election.enable false开启配置多个副本replication.factor 1 producer端 ack设置为-1或是allpro.put(ProducerConfig.ACKS_CONFIG,“all”)send方法中一定要用带返回值的如果失败了可以及时的得到通知或是做出相应的策略 consumer端 offset的提交设置为手动提交
05、kafka中的消费者组及相关问题 kafka的consumer在消费topic数据的时候是通过group的方式消费的 group中还有一个rebalance的过程它是为了更好的把消费者分配到分区中消费数据存在的rebalance机制运行起来的时候所有的消费者都会暂停工作 对系统有比较大的影响 group的作用 隔离不同group中消费者的互相影响实现kafka消息的订阅模式 group中消费数据特点 一个Partition只能让同一个group中的一个消费者来消费为了保证分区中数据的顺序性一般情况下一个分区分配一个消费者去消费即可也会出现一个消费者同时消费多个分区的情况 group的中consumer的分配和管理 它是通过rebalance机制来分配和管理rebalance机制会把group中的每个消费者分配到对应的topic的Partition中进行消费如果其中一个消费者挂了它会从新分配一个新的过来消费有新的消费者加入会给它分配对应的分区消费 rebalance机制的问题 在rebalance机制运行的过程中group中的所有消费者都会停下来不消费参加rebalance这就会给系统带来一定时间的停摆 rebalance机制产生的条件和应对 group中consumer数量发生变化时订阅的topic发生变化时订阅的topic的Partition发生变化时这三种情况下都会触发rebalance机制rebalance机制如果不是频繁发生的话是一种正常现象 非正常情况下减少rebalance触发 例如consumer没有及时发送心跳请求导致误以为对应的consumer挂掉还有consumer处理数据时间过长导致被踢出group这些都是非正常情况可以根据自己业务运行时间调整调大heartbeat.intgerval.mssession.timeout.ms,max.poll.interval.ms等参数的数值
06、kafka集群的调优
broker端集群优化 设置num.replica.fetcher参数与CPU核数一致提供副本同步的效率调大replica.fetch.min.bytes里避免小批量数据的同步提供吞吐量调大replica.fetch.max.byte在一批次中尽量多的同步数据也是为了提高吞吐量指定broker端JVM的垃圾回收器为G1 producer端优化 调大batch.size参数提供批次写入的量增大吞吐量默认是16k调大buffer.memory参数提高生产者端缓存的内存大小retriest调大重试次数避免网络抖动带来的问题根据业务的需求调整ack的值 consumer端优化 根据具体业务调整max.poll.records的大小max.poll.interval.ms调整批次拉取之间的最大延迟避免不必要的rebalanceheartbeat.interval.ms调整消费者和kafka之间的心跳超时时间一般调整为session.timeout.ms的三分之一避免不必要的rebalance
