燕郊教育网站建设修改wordpress站点标题

当前位置： 首页 > news >正文

燕郊教育网站建设,修改wordpress站点标题,网页制作软件有那些,7个湖北seo网站推广策略生产故障#xff5c;Kafka ISR频繁伸缩引发性能急剧下降-阿里云开发者社区 本文是笔者双十一系列第二弹#xff0c;源于一个双十一期间一个让笔者猝不及防的生产故障#xff0c;本文将详细剖析Kafka的副本机制#xff0c;以及ISR频繁变更(扩张与伸缩)为什么会导致集群不可…生产故障Kafka ISR频繁伸缩引发性能急剧下降-阿里云开发者社区 本文是笔者双十一系列第二弹源于一个双十一期间一个让笔者猝不及防的生产故障本文将详细剖析Kafka的副本机制以及ISR频繁变更(扩张与伸缩)为什么会导致集群不可用。 1、Kafka副本机制 Kafka数据组织方式是topic-parition的结构每一个topic可以设置多个分区各个分区的数据是topic数据的一部分数据分片为了保证单个分区的高可用行又引入了副本机制即一个分区的数据会存储多份避免单点故障. 一个3节点的Broker集群每一个Toipic的副本因子设置为3则对于其中一个Topic其存储结构如下图所示 正如上图所示一个Topic有三个分区p0,p1,p2其中每一个分区有3个副本(3份相同的数据)其与客户端交互的关键点如下 每一个分区的Leader负责该分区的读写分一个分区的follower从Leader节点复制数据如果leader分区所在的broker宕机会触发leader选举上述的模型满足高可用的诉求但同时会带来一个设计难题如何保证同一个分区中Leader与follwer节点数据的一致性。 Kafka副本之间的数据复制模型如下图所示 Kafka复制模型采取的是拉模型即follower节点主动向leader拉取数据leader节点可用根据从节点发起的拉起请求的消息偏移量从而得知从节点当前复制数据的位置。 Kafka在数据副本一致性方面并没有采取诸如raft协议之列的而是之间基于最高水位线与leader_epoch机制本文不深入探讨在一致性方面的知识这些后续会一一剖析。 在Kafka中引入了一个概念副本同步集即ISR集合。 所谓的副本同步集表示这个集合中的副本能跟上Leader的从节点判断的规则两者之间同步消息的时间间隔不能超过设置的阔值该值由参数 replica.lag.time.max.ms 来控制默认为10s。 例如上图中分区p0的leader节点成功写入了5条消息两者在服务端存储的时间间隔为15s而其中一个从节点只复制了t1与最新的t5消息间隔15s超过了replica.lag.time.max.ms设置的10s则Leader会将该节点从ISR集合中剔除而另外一个从节点尽管只复制了4条消息但落户Leader副本的时间间隔小于10s则该节点会作为ISR集合中的一员。 ISR集合与副本数的关系如下图所示 那这个ISR集合的作用是什么呢 一个非常重要的作用可以用来实现消息发送阶段消息不丢失。 构建KafkaProducer对象时可以设置acksall或者-1表示必须ISR集合中的副本全部成功写入消息才会向客户端返回成功注意这里并不是说所有副本写入成功。 并且对ISR集合中的副本的个数也有要求可以在topic级别的配置参数 min.insync.replicas进行设置该值默认为2。 例如将topic的副本因子设置为3表示有三个副本只要ISR集合中的数量不少于2个将acks设置为all时才能正常写入成功如果ISR集合中的副本数量小于min.insync.replicas则消息发送会失败。 以上就是Kafka ISR集合的一些基本介绍该专栏后续会继续深入探讨kafka的日志存储、高低水位线、Leader epoch等机制。 在探究ISR伸缩与扩张会引发消息发送、消息消费性能急剧下降原因之前想提出一个思考题 思考题从上文中可知ISR集合中各个副本虽然是同步集合但判断是否同步的规则确实从节点不落后Leader节点多少数据那这些副本之间的数据并不是完全同步的如果在Leader切换过程中会丢失消息吗 2、ISR频繁伸缩缩引发性能急剧下降 双十一期间一个Kafka集群频繁发生ISR读写性能急剧下降监控图如下所示 起初一个topic的写入tps达到了25W每秒当出现ISR收缩与扩张后断崖式下降与此同时服务端会有大量的日志 为什么会ISR频繁收缩与扩张为导致性能急剧下降呢 当然首先如果acks设置为all消息写入下降这个是必然的因为ISR集合中的数量会低于min.insync.replicas导致消息无法写入但这个topic是用于同步数据库binlog如果出现集群等原因导致消息丢失完全可以回放binlog进行数据补推故消息发送时是将acks设置为1(Leader节点写入成功即返回成功)。 那又是为什么呢 通过系统相关的监控发现发生问题时的CPU、磁盘都没有瓶颈故优先排查Kafka的线程堆栈信息。 关键信息一Kafka Broker在处理消息写入时需更新Kafka高水位线需要申请leaderIsrUpdateLock的读锁如下图所示 原来消息写入时需要加读锁但由于读锁与读锁之间时相容的并不影响消息发送的并发度。 关键信息二Kafka Broker在处理消息拉起请求时(消费端、从节点都会发fetch请求)需同样需要更新Kafka高水位线需要申请leaderIsrUpdateLock的读锁如下图所示 消息发送、消息写入都需要申请读写锁leaderIsrUpdateLock中的读锁并不会影响并发度。 关键信息三Kafka Broker在ISR发生扩张与伸缩时需要申请leaderIsrUpdateLock的写锁如下图所示 在ISR集合发生变更时对高水位线的的更新需要加写锁此时会与消息发送、消费客户端消费消息、分区副本消息复制发送锁竞争并发度急剧下降这样就解释了为什么ISR收缩与扩张会导致TPS急剧下降。 令人比较“无语”的是这里会有一个连锁反应因为会影响副本分区从其Leader节点拉取消息的速率容易加剧ISR的扩张与收缩从而使问题越来越严重。 3、解决方案 经过上述分析ISR的频繁扩张与收缩其最直观的原因是follower副本从Leader副本复制数据由于复制跟不上导致两者之间数据同步的差距超过了replica.lag.time.max.ms导致Leader分区会将跟不上进度的副本剔除ISR然后当follwer分区跟上后又能加入ISR。 故可以通过调整Kafka相关的参数来减少ISR发生的几率 replica.lag.time.max.ms从默认10s调整为30snum.replica.fetchers从默认值1调整为10该参数的主要作用是设置Follower节点用于从服务端复制数据的线程数量调整该参数可以加大并发在线程堆栈线程名称为ReplicaFetcherThread线程注意这个是控制一个节点到集群单个Broker的链接数例如一集群有8个节点该值设置为10那一个节点就会创建 8-1* 10 共70个ReplicaFetcher线程。本文就到介绍到这里里其实ISR频发扩张后还会引发更加严重的问题最后竟然引发了整个集群无法写入消息无法消费消息这些将在后续文章中发布