高可用

«结论先行：半同步复制（semi-sync）的“安全”是有时间预算的，超时会静默退化为异步，这个窗口里的丢事务风险，比大家以为的大得多。本文用一次真实事故 + 一组可复现的配置，把 "rpl_semi_sync_master_timeout

一、现象：一条毒消息，30 秒内把 4 个队列打到 0 QPS 去年大促前压测，我们的订单事件流（RocketMQ 5.1.4，4 个 Queue，消费端 8 线程）在 QPS 5200 时突然出现「消费延迟从 200ms 飙到 47s」，

背景 做了 8 年网络工程，最近一年反复遇到同一个争论：核心出口要不要上双 ISP / 双机房 / 双上联。很多团队的答案是"要"，理由很朴素——单链路就是单点，SRE 教科书里写得很明白。但真正落地时大家会撞上一组很现实的账：第二链路的带

背景 做了 5 年网络工程，最近一年反复遇到同一个争论：核心服务到底要不要上双机房/多活。我见过两种极端——一边是「核心链路必须两地三中心，否则一次机房断网就全崩」，一边是「就一个机房加个快照备份，省下的钱够发三个月工资」。两边的声音都有道

【背景】 我负责一个数据中心出口：两台核心（Cisco N9K，IOS-XR）做 eBGP 双活，下行 4 条 100G 上联走 ECMP（等价多路径，哈希键默认含五元组 + VLAN）。业务是对象存储网关，流量特征很"肥"：少数几条大对象

背景 上周在排查一次 P99 毛刺时，顺带翻了下我们网关侧的几段老代码，发现一个挺有意思的分歧：同一个团队里，三个不同服务的"安全门"（鉴权、风控、限流、白名单校验）在下游依赖抖动时，处理方式完全不一样——有的直接 403 拒掉，有的直接放

【背景】 我负责一个双活数据中心的出口链路：两台核心交换机（Cisco N9K，IOS-XR 邻居是运营商 AS4134）跑 eBGP 双上联，业务侧是长连接 gRPC 服务，对丢包非常敏感（一次 50ms 内的丢包窗口就能让上游熔断）。链