RocketMQ 顺序消息靠分区有序，真碰上需要全局强顺序的业务，加个业务层序号成本到底高多少
RocketMQ 的顺序消息仅支持分区有序，无法实现全局有序。强行在业务层通过全局序号、排序缓冲区、去重和断点续跑等机制实现全局顺序，会带来显著的状态管理、测试和运维复杂度，成本远高于直觉。更优方案是采用单线程顺序消费加异步分发，或换用原生支持全局顺序的中间件。
分类: 后端架构
共 52 篇文章
BEST 实测了 Kafka MirrorMaker 和 Pulsar 异地复制的容灾切换时间，RPO 的差距比预想的大
Kafka MirrorMaker 2与Pulsar异地复制在AWS跨区域容灾场景下的实测对比显示，RTO差距不大（秒级），但RPO差异显著：Pulsar基于存储层同步复制实现RPO=0，代价是延迟增加6.5倍；MirrorMaker 2的异步架构导致RPO波动最高达11秒，极端场景可能丢失数万条消息。架构设计决定了容灾能力上限，金融级场景需权衡一致性与延迟。
排查缓存问题我一般就靠慢查询、热 Key 分析和命中率曲线这三板斧，基本能把事故现场还原出来
缓存故障排查靠三板斧：慢查询日志、热Key分析和命中率曲线。慢查询要关注命令类型、Key模式和时间分布，O(N)命令直接定性为缺陷。热Key分析需区分读多写少和频繁更新场景，警惕伪热Key。命中率曲线重点看断崖式下跌和缓慢下降，区分整体与核心业务命中率。事故还原按慢查询、命中率、热Key顺序排查，可覆盖95%故障场景。
模拟 Redis 挂了、数据刚好过期、100 个请求同时打进来，这套单元测试怎么搭
缓存层重构的关键在于用可控的 Mock Redis Client 精确模拟异常态，而非简单返回 null。通过接口化底层操作，可模拟缓存未命中、连接超时和数据过期三种场景，并利用并发原语发起 100 个请求，验证数据库仅穿透一次。测试需覆盖雪崩延迟、脏数据清理等边界情况，并集成到 CI 中，开启 race detector 以捕获竞态条件。
Kafka 的 Exactly-Once 语义听着很美，在跨系统场景下我还是老老实实上了业务去重表
Kafka 的 Exactly-Once 语义仅保证其内部消息不丢不重，一旦消费端涉及数据库、缓存或第三方 API 等外部系统写入，该承诺即失效。文章通过订单分账踩坑案例，剖析了跨系统场景下的重复处理根因，并给出基于数据库唯一索引的业务去重表方案，实现业务层真正的“恰好一次”处理。
查缓存没命中就全砸到库上，连接池满了怎么办？我用 CompletableFuture 把重复请求合并了一下
请求合并是解决缓存穿透的高效方案：用 ConcurrentHashMap 存 CompletableFuture，首个线程执行查询，后续线程挂起等待同一结果，避免数据库连接池被重复查询打满。需注意用 Optional 包装空值、finally 清理 Map、设置容量上限防内存膨胀，配合本地缓存可消化缓存过期瞬间的并发流量。
缓存预热搞不好比冷启动还慢——三种加载策略的耗时曲线和雪崩风险，压测数据摆出来聊聊
缓存预热并非万能解药，策略不当反而会放大风险。全量加载启动慢但运行稳定，需配合TTL打散防雪崩；懒加载启动快但雪崩时毫无自保能力，必须依赖限流熔断；增量加载折中，但热点识别不准则效果大打折扣。选择策略需权衡启动延迟与数据库压力，并针对各自弱点配套保护机制。
IoT 消息队列选型，我把 MQTT 和 AMQP 丢到弱网里跑了一组对比数据
MQTT 在弱网下延迟和功耗优于 AMQP，但离线消息可靠性需额外设计。实测显示，MQTT 延迟约为 AMQP 的 40%，功耗低 30%，吞吐领先约 10%。AMQP 在低连接数时性能差距缩小，且离线消息零丢失。选型需权衡设备规模、网络质量与消息可靠性需求。
康威定律之下：我们拆服务前先调了组织，结果跨团队协作还是掉了链子
组织调整是微服务拆分的骨架，但缺乏协作协议会导致跨团队沟通崩溃。问题不在代码所有权，而在团队间的交互接口、排期机制和契约设计未被系统化。需建立跨域需求优先级通道、消费者驱动的接口契约和自动化集成测试，并明确协作节奏与冲突仲裁原则，才能避免信息流动失真。
跨服务日志里 traceId 断了，排查时用这几种传参和存储方式把它接上
跨服务调用中 traceId 断层是常见故障根源。文章提出一套完整方案：用带时间戳的雪花算法生成有序 ID，通过 HTTP 头、RPC 隐式传参和 MQ 消息属性统一传递，并在下游做格式校验与兜底生成。日志需用 MDC 输出 traceId、spanId 和服务名，并处理线程池传递。检索时利用时间前缀加速，通过 `trace_source` 字段快速定位断点。