食材网站模板wordpress插件video playe

食材网站模板,wordpress插件video playe,郑州仿站定制模板建站,贷款公司通过做网站来给予平台贷款RocketMQ 高可用保障#xff08;HA#xff09;详细实战指南 这份文档讲的是“怎么让 RocketMQ 尽量不停 尽量不丢 出事能自动/快速恢复”。 高可用不是一个开关#xff0c;是一整套工程#xff1a;架构冗余 正确配置 客户端容错 运维监控 演练。 目录 1. 先把目标说…RocketMQ 高可用保障HA详细实战指南这份文档讲的是“怎么让 RocketMQ尽量不停 尽量不丢 出事能自动/快速恢复”。高可用不是一个开关是一整套工程架构冗余 正确配置 客户端容错 运维监控 演练。目录1. 先把目标说清楚可用性 vs 不丢消息2. HA 的分层思路从外到内3. NameServer 高可用4. Broker 高可用核心4.1 经典 Master/Slave4.x 常见4.2 DLedgerRaft 多副本 自动故障转移4.3 5.x Controller / 自动主从切换4.4 跨机房/跨可用区AZ建议5. 客户端侧容错很多人忽略但很致命5.1 Producer发送高可用5.2 Consumer消费高可用6. 关键配置项建议带理由7. 监控与告警你不监控就等于没 HA8. 故障演练清单建议每季度至少一次9. 最小可落地的“生产推荐拓扑”10. 常见坑踩一个就能把你打回原形1. 先把目标说清楚可用性 vs 不丢消息高可用通常包含两类目标经常被混在一起服务可用性AvailabilityBroker 挂一台业务还能继续发/收可能降级、延迟上升但不停数据可靠性Durability / 不丢消息机器断电/进程崩溃/磁盘异常也要保证“已返回成功的消息”不丢现实里这俩通常要做权衡同步刷盘 同步复制更不容易丢但吞吐/延迟会更差异步刷盘 异步复制性能好但极端故障下可能丢“最后一小段”所以你要先定清楚你是金融级宁慢不丢还是互联网业务可补偿吞吐优先。2. HA 的分层思路从外到内按层拆开看HA 才能落地接入层 / 路由层NameServer、5.x 可能还有 Proxy存储层Broker 的刷盘、复制、多副本、故障转移客户端层Producer 重试、故障规避Consumer 重试、幂等、DLQ运维层监控、告警、容量、发布、演练你会发现Broker 做得再强客户端不重试、不幂等一样能把系统整趴。3. NameServer 高可用NameServer 是路由中心不存消息但它对“新连接、新路由更新”很关键。3.1 部署建议至少 2 台 NameServer建议 3 台更稳分散到不同物理机/不同 AZ别全在一台宿主机客户端配置多个地址namesrvAddrip1:9876;ip2:9876;ip3:98763.2 客户端行为要点Producer/Consumer 会从 NameServer 拉路由并缓存NameServer 短暂挂掉通常不影响已缓存路由的消息收发但如果你只有 1 台 NameServer它挂了你就很难做路由更新、扩容、故障切换恢复会很痛4. Broker 高可用核心Broker 决定了消息存在哪、怎么复制、挂了怎么恢复。4.1 经典 Master/Slave4.x 常见这是最传统、最常见的部署模型。大方向是多个Master分摊负载Topic 的队列分布在多个 Master 上每个 Master 配一个或多个Slave做备份同机房/跨 AZ 视成本与网络而定4.1.1 多 Master无 Slave优点成本低、吞吐高缺点单 Master 挂了它上面的队列不可写直到恢复可靠性一般4.1.2 多 Master 多 Slave异步复制优点吞吐好挂主后可读视配置缺点主挂的瞬间可能丢最后一小段未复制的数据看复制滞后4.1.3 多 Master 多 Slave同步双写 / 同步复制优点更不容易丢消息主从都写成功才算成功缺点写延迟上升吞吐下降对网络抖动更敏感经验如果你真的对“不丢”敏感同步复制 同步刷盘是最直接的思路但要准备好吞吐下降。4.2 DLedgerRaft 多副本 自动故障转移DLedger 的定位用 Raft 做一致性复制让 Broker 更像“有选主能力的多副本日志系统”。典型价值多副本 commitlog一般是3 副本奇数Leader 挂了能自动选举新 Leader自动恢复写能力更接近“强一致复制”具体一致性取决于配置与实现适用你需要更强的自动故障转移能力你愿意付出更多机器和网络成本多副本4.3 5.x Controller / 自动主从切换RocketMQ 5.x 里常见的方向是把“主从切换/控制面能力”抽出来形成Controller有的场景也会和 DLedger 思路结合。你可以把它理解成Broker 专心做存储与读写Controller 负责集群状态、主从切换、选主等控制逻辑目标是故障时更自动、更快恢复写入如果你在用 5.x并且你的部署方案支持 Controller/自动故障转移模式建议优先评估这一套尤其是云原生/容器化环境。4.4 跨机房/跨可用区AZ建议跨 AZ 是 HA 的“终极形态”之一但成本也更高网络 RTT、带宽、丢包都会影响同步复制。建议优先级从易到难同机房多实例 多盘冗余 快速自动拉起同城双 AZMaster/Slave 分 AZ复制链路跨 AZ异地多活/双写业务复杂度最大通常需要业务侧强补偿实操建议同步复制跨 AZ先压测网络抖动对延迟的影响异步复制跨 AZ更现实但要接受极端情况下的少量丢失或用业务补偿5. 客户端侧容错很多人忽略但很致命5.1 Producer发送高可用你要做到的效果是某个 Broker/某条链路坏了Producer 自动绕开尽量发到别处。建议点namesrvAddr 配多个发送失败重试同步/异步都要考虑合理设置retryTimesWhenSendFailedretryTimesWhenSendAsyncFailed开启“故障规避/延迟容错”不同版本叫法不同核心是把高延迟/失败的 broker 暂时踢出候选发送端一定要有日志与告警失败率、超时率、分位延迟P95/P99非常重要Producer 侧要理解“发送成功”的语义如果是异步刷盘/异步复制成功不代表“已在多副本落稳”。真要“金融级不丢”要配合 Broker 侧策略同步刷盘 同步复制一起上。5.2 Consumer消费高可用Consumer 的高可用目标是某个消费者挂了其他实例接管某条消息失败不要把整体拖死。建议点一个消费组至少2 个实例别单点使用集群消费Clustering进行负载分担消费失败要有重试策略 DLQ死信队列业务必须幂等RocketMQ 默认更偏至少一次语义对“毒消息”要有隔离策略重试次数上限进入 DLQ 后有处理入口人工/自动补偿6. 关键配置项建议带理由配置名不同版本可能略有差异但核心思路一致。6.1 Broker 刷盘策略flushDiskTypeASYNC_FLUSH吞吐更高极端断电可能丢最后一小段SYNC_FLUSH更安全但延迟更高建议核心链路资金/账务/关键订单优先SYNC_FLUSH非核心链路日志/埋点/可补偿事件ASYNC_FLUSH常见6.2 Broker 复制角色brokerRole常见选项ASYNC_MASTER异步复制 masterSYNC_MASTER同步复制 masterSLAVE从节点建议要更稳SYNC_MASTER要吞吐ASYNC_MASTER6.3 线程池与快速失败防雪崩当下游故障时Broker 线程池可能堆积导致雪崩。建议关注“快速失败”/队列长度/线程池大小等配置让系统在压力异常时更快返回错误从而触发上游重试与熔断而不是把自己拖死。6.4 存储与磁盘CommitLog 强依赖磁盘顺序写吞吐别用共享盘/垃圾盘糊弄磁盘 80% 以上就是事故前夜清理策略/扩容必须提前建议commitlog 盘与系统盘分离RAID/云盘级别的可靠性选型要清楚别只看价格7. 监控与告警你不监控就等于没 HA必须监控的“生死指标”7.1 Broker 维度Broker 存活心跳、进程、端口磁盘使用率尤其是 store 目录复制滞后主从同步延迟、in-sync 状态写入/读取 TPS、延迟P95/P99线程池队列堆积、拒绝数7.2 Topic/Group 维度消费堆积lag重试量、DLQ 增长消费失败率、消费耗时分位数7.3 NameServer / Controller如有节点存活leader 状态如果是 controller/raft 集群路由更新时间异常告警建议“硬阈值 趋势阈值”组合比如磁盘增长速度异常也要报警不要只报警“挂了”要报警“快挂了”8. 故障演练清单建议每季度至少一次你可以按这个顺序做演练NameServer 挂一台预期消息收发基本正常路由更新能力下降但不致命Broker Master 挂掉预期有自动切换能力写入恢复可能有短暂抖动无自动切换该 master 上的队列不可写业务侧要容错/降级Slave 挂掉/复制链路中断预期集群可用性仍在但可靠性下降告警要响磁盘写满/写慢最真实的事故之一预期写入延迟飙升、失败率上升快速失败与上游熔断是否工作消费者整体不可用全部停预期堆积上涨恢复后逐步追赶没有把 Broker 打爆演练必须产出故障发生时间线发现时间MTTD恢复时间MTTR根因与改进项9. 最小可落地的“生产推荐拓扑”如果你想用最少机器做一个“还算靠谱”的生产 HA方案 A经典 Master/Slave成本相对低NameServer2~3 台Broker至少 2 个 Master每个 Master 配 1 个 SlaveMaster/Slave 跨 AZ 更好关键 TopicSYNC_MASTER SYNC_FLUSH或至少 SYNC_MASTER方案 BDLedger / Controller自动故障转移更强NameServer2~3 台Controller如你的架构需要奇数个节点常见 3Broker按多副本/自动切换方案部署通常 3 副本更稳配套完善监控告警 演练10. 常见坑踩一个就能把你打回原形只有 1 台 NameServerBroker 全在同一台宿主机/同一 AZ看似多副本实际同生共死异步刷盘 异步复制还自信“绝对不丢”消费者不幂等重试导致重复扣款/重复发货DLQ 没人管死信越积越多最后变成“系统性欠账”磁盘不监控/不扩容写满直接宕机不演练事故发生才第一次验证方案最后一句话RocketMQ 的 HA 不是靠“部署多几台”就完事了真正靠谱的组合是多 NameServer Broker 多副本/可切换 Producer 重试与故障规避 Consumer 幂等与 DLQ 监控告警 定期演练把这套跑顺你的 RocketMQ 才算真的“高可用”。