某网站优化方案iis 网站301重定向

某网站优化方案,iis 网站301重定向,Wordpress 百度云存储,备案网站代理商有次上线监控告警突然炸了#xff0c;Kafka 订单 Topic 消息积压量突破 10 万条#xff0c;下游支付服务拿不到数据#xff0c;部分用户付款后一直显示处理中。紧急登录集群排查#xff0c;发现消费者组明明有 3 个节点#xff0c;却只有 1 个在正常消费#xff0c;原来 …有次上线监控告警突然炸了Kafka 订单 Topic 消息积压量突破 10 万条下游支付服务拿不到数据部分用户付款后一直显示处理中。紧急登录集群排查发现消费者组明明有 3 个节点却只有 1 个在正常消费原来 10 分钟前触发了 Rebalance另外两个节点还卡在分区重新分配的状态导致消费能力直接砍半。所以我的经验是Kafka出现消息积压、重复、丢失这类问题直接看是否有Rebalance能解决大部分问题。什么时候会触发 RebalanceRebalance 本质是消费者组内分区与消费者的重新分配只有当消费者、分区的对应关系被打破时才会触发下边咱们看看几种比较常见的场景1. 消费者数量变了最频繁扩容触发业务高峰时加了消费者节点比如 3 个分区原本 2 个消费者承担新增 1 个后需要重新分配成 1 个消费者对应 1 个分区下线触发消费者节点宕机、网络断连或进程被误杀比如 3 个消费者少了 1 个剩下 2 个要接手它的分区必然触发 Rebalance。之前我们的日志服务就踩过坑K8s 节点资源不足导致消费者 Pod 频繁重启每重启一次就触发一次 Rebalance消息积压越来越严重。2. Topic 分区数加了Kafka 不支持减少分区但新增分区时已存在的消费者组不会自动感知新分区必须通过 Rebalance才能把新分区分配给组内消费者。比如给order-topic从 5 个分区扩到 8 个原本的消费者组只会消费旧的 5 个分区直到触发 Rebalance 后才会接手新增的 3 个分区。3. 订阅的 Topic 变了消费者组通过subscribe()订阅 Topic 时若修改订阅列表比如从只订阅order-topic改成同时订阅order-topic和pay-topic会触发 Rebalance重新分配所有订阅 Topic 的分区。4. 心跳或消费超时隐性坑消费者靠心跳向 Coordinator协调者证明自己活着这两个超时参数设不好很容易触发误判式 Rebalance心跳超时消费者每 3 秒默认heartbeat.interval.ms发一次心跳超过 45 秒默认session.timeout.ms没发就被判定死亡消费超时处理单批消息超过 5 分钟默认max.poll.interval.ms哪怕心跳正常也会被强制踢出组触发 Rebalance。我们之前处理大订单消息时单条消息处理要 6 分钟直接触发消费超时导致 Rebalance 频繁发生。Rebalance 引起哪些问题Rebalance 不是瞬间完成的整个过程要经历注销旧分区→选举 Leader→分配新分区→消费者初始化期间对业务的影响比你想的大。1. 消费暂停消息积压Rebalance 期间所有消费者都会暂停消费等待新的分区分配。如果消费者组规模大比如 100 个消费者、1000 个分区Rebalance 可能持续几十秒这段时间 Topic 消息只会堆积下游服务拿不到数据。所以在有消息积压的情况优先看看是否有 Rebalance 的情况。2. 消息重复和消息丢失Rebalance 后消费者重新拿到分区时消费进度可能倒退若没及时提交 offset不管自动还是手动会从最后一次提交的 offset 开始消费中间没提交的消息要么重复处理要么直接跳过也就是消息重复消费和消息丢失的原因。极端情况比如 Coordinator 宕机offset 存储的分区发生主从切换可能导致 offset 数据错乱进度直接回到几天前。3. 资源浪费负载不均Rebalance 要靠 Coordinator 协调频繁触发会占用 Kafka 集群的 CPU 和网络资源而且 Kafka 默认的分区分配策略Range 或 RoundRobin很容易导致负载不均。比如 5 个分区分配给 2 个消费者可能出现 3 个分区 vs 2 个分区的情况其中一个消费者压力翻倍处理速度变慢又会触发新的 Rebalance陷入恶性循环。什么情况下会丢数据Rebalance 本身不会直接丢数据但结合offset 提交和处理逻辑很容易出现消息漏消费。1.自动提交 offset 消费没完成Kafka 默认自动提交 offset提交时机是 poll 到消息后等 5 秒默认auto.commit.interval.ms自动提交。如果刚提交完 offset消息还没处理完就触发 Rebalance新消费者会从已提交的 offset 之后 开始消费中间没处理的消息就丢了。举个例子消费者 A poll 到 offset 100-200 的消息5 秒后自动提交 offset 200处理到 150 条时节点突然宕机触发 Rebalance新消费者 B 从 offset 200 开始消费offset 150-199 的消息直接丢失。2. 手动提交 offset 时机错了手动提交时如果把提交 offset 放在处理消息之前也会丢数据。错误逻辑先提交 offset → 再处理消息风险提交后、处理前触发 Rebalance新消费者会跳过已提交的消息导致未处理的消息丢失。正确的做法应该是先处理消息→再提交 offset确保消息处理完才更新进度。什么情况下会重复消费相比丢数据kafka Rebalance 导致的重复消费更普遍核心原因都是 offset 提交滞后于消息处理。1. 手动提交时Rebalance 打断了提交开启手动提交后若在处理完消息→提交 offset 的间隙触发 Rebalanceoffset 没提交成功新消费者会从上次提交的位置重新消费。消费者 A 处理完 offset 100-200 的消息准备提交时因心跳超时被踢出组新消费者 B 从 offset 100 开始消费导致 100-200 的消息被重复处理。2. 消费超时被踢消息还在处理处理消息耗时超过max.poll.interval.ms消费者被判定死亡但实际还在处理消息。消费者 A 处理大消息用了 6 分钟超过默认 5 分钟的超时时间被踢出组新消费者 B 接手分区从上次提交的 offset 开始消费消费者 A 后来处理完消息想提交 offset 却发现自己已被踢出提交失败导致消息重复。3. offset 找不到回退到最早如果消费者组的auto.offset.reset设为earliest默认是latestRebalance 后找不到已提交的 offset比如 offset 数据损坏会从 Topic 最早的消息开始消费导致历史消息重复。如何优化 RebalanceRebalance 这种情况是无法完全避免不过我们可以来优化能把影响降到最低。1. 避免频繁触发 Rebalance调优超时参数根据消息处理耗时把max.poll.interval.ms设大比如大消息设为 10 分钟session.timeout.ms设为 60-120 秒避免误判死亡保证消费者稳定用监控盯紧消费者节点的 CPU、内存避免 K8s Pod 频繁重启或服务器宕机。2. 安全处理 offset 提交优先手动提交关闭自动提交enable.auto.commitfalse在消息处理完成后再调用commitSync()提交必要时用事务如果业务不允许重复消费结合 Kafka 事务确保消息处理 和 offset 提交原子性。3. 优化分区分配选粘性分配策略把partition.assignment.strategy设为StickyAssignorRebalance 时尽量保留原有分配减少分区变动。4. 优化消费逻辑做好幂等性比如用订单 ID 作为唯一键即使重复消费也不会导致业务逻辑出错比如重复扣钱、重复生成订单。写在最后Rebalance 是面试的时候常爱问的场景题它是 Kafka 消费者组的双刃剑用好能均衡负载用不好就会引发故障最后我总结下触发 Rebalance 主要是消费者或分区变了或超时了丢数据和重复消费本质是 offset 提交和 Rebalance 时机没配合好优化超时参数、手动提交 offset、做好幂等性是减少影响的关键。看完等于学会点个赞吧