缓存命中率跌到多少该告警？我们反过来用空值率和穿透量推了一把阈值
将告警指标从缓存命中率改为空值率和穿透量，可大幅提升异常捕捉速度。空值率直接反映“查无此数据”的请求占比，信号清晰且误报少；配合绝对穿透量阈值作为二级确认，能有效过滤低流量干扰。组合告警规则将发现延迟从分钟级降至秒级，并联动空值缓存策略实现自动止血，同时需注意集群聚合和内存保护等落地细节。
分类: 后端架构
共 52 篇文章
订单超时取消时，消息重试用指数退避还是直接扔死信？我们把三种策略放一起跑了一遍
订单超时取消场景下，三种消息处理策略的压测对比显示：业务补偿通过状态校验实现零资损，表现最稳；指数退避在低故障率时延迟友好，但瞬时故障会放大问题；死信队列必须配合监控和人工处理，否则易引发积压和顺序混乱。选择需权衡实时性、开发成本和容错能力。
拆微服务时，我们纠结了半年的订单-商品-用户边界，最后被一张数据库表说服了
团队因订单服务拆分半年后决定重新合并，源于对`order_item_snapshot`表的重新审视。争论焦点从按领域还是按用户旅程拆分，转向识别“商品目录”与“商品快照”的本质区别。核心原则是数据跟随其变更原因走，动态商品信息归商品服务，下单时不可变的交易快照归订单服务。最终通过快照表实现订单服务零外部依赖，大幅降低延迟，并明确了“不一致”才是快照的正确行为。
拆微服务最怕拆出个“分布式单体”：同步调用链太深、共享数据库、没法独立发布，这三个信号我靠它拦住了好几次
拆分微服务前，需用三个信号体检：同步调用链深度超3层易雪崩，应改异步或合并；共享物理表即耦合，宁可冗余数据；服务不敢独立上线说明交付边界假，需验证发布独立性、契约测试和回滚能力。按序检查可有效拦截分布式单体陷阱。
线上缓存雪崩了三次，我们靠自动识别热点 Key 和动态分散才把这事摁住
面对频繁的热点 Key 引发的缓存雪崩，团队构建了一套自动化解决方案。通过客户端采样与 Flink 基线偏离度算法，能在 20 余秒内自动识别热点。识别后，系统会动态计算副本数并分散读请求，同时利用 Keyspace 通知异步同步数据，保证最终一致性。此外，还加入了客户端限流、分片熔断和本地缓存三重兜底，实现了对业务透明的热点防护。
服务间认证三种走法：JWT 透传、网关统一鉴权、mTLS 的性能损耗与安全边界实测对比
三种服务间认证方案实测对比：JWT透传性能最优但token泄露风险大；网关统一鉴权性能略优，但网关成为单点瓶颈；mTLS安全最强但性能损耗近半。测试基于Go服务和Envoy/Istio，覆盖QPS、延迟、CPU等指标。选型需权衡性能与安全：低QPS可任选，高QPS需按业务场景取舍，金融等高合规场景建议mTLS，中等规模推荐网关方案。
先拆查询还是先拆交易：我们两次微服务化的真实账单
从两次微服务拆分实践出发，对比先拆查询与先拆交易两种路径的决策逻辑、实施代价与适用场景。核心结论是：选择取决于业务约束——旧系统稳定但查询慢时先拆查询，用数据冗余换低风险；旧系统本身成瓶颈时先拆交易，用高复杂度换架构根治。同时强调团队能力与业务容错空间是隐性关键变量。
那次缓存雪崩，我们在过期时间上加了一层随机抖动才稳住
缓存雪崩源于大量key同时过期导致请求穿透至数据库。解决方案包括：用key哈希值生成固定随机抖动，将过期时间分散到宽窗口；对热点key采用本地缓存、Redis和数据库三级架构，并提前异步刷新避免集中失效。该策略适用于高QPS、数据库脆弱的场景，需权衡一致性与复杂度。
压到极限才见真章：Kafka、RocketMQ、Pulsar 在不同分区下堆积到接近崩盘时，延迟到底差多少
在极端分区（最高5000）和高堆积（TB级）条件下，对Kafka、RocketMQ和Pulsar进行物理集群压测。结果显示，Kafka延迟恶化最可控，呈渐进式增长；RocketMQ在2000分区时出现性能断崖，延迟飙升至秒级；Pulsar在分区超500后几乎不可用，架构开销导致指数级恶化。性能断崖根因各异，选型需匹配业务瓶颈。
我们团队用版本号管接口兼容性踩过的坑，以及为什么最后选了消费者驱动契约测试
版本号管理接口兼容性在微服务规模扩大后迅速失控，线上多版本并存导致事故频发。核心问题是服务端单方面声明兼容，却不知消费方实际使用情况。团队转向消费者驱动契约测试，由消费方定义需求、服务端验证，并通过CI流水线和Can I Deploy检查实现自动化兼容管理，最终将接口事故降为零，废弃字段得以安全清理。