归档

那次 gRPC 连接每隔两分钟就断，最后发现是 Keepalive 的 permit-keepalive-time 配反了 CI 里跑全量测试太慢了，我们用分片加依赖分析把时间从半小时压到十分钟以内 把限流阈值从代码里拽出来之后，我们设计了一套 DSL，运营活动期间自己改配置就行 Redis 原子计数在主从切换时丢数，我们靠 Lua 脚本加本地缓存兜住了那波被放行的流量 网关层扛下 gRPC 和 RESTful 两套协议转换时，路由、序列化与错误码映射的完整落地步骤

网关限流过了，线程池却先扛不住了——我们给每个接口单独配了线程隔离和排队 秒杀那几秒，Apollo 热更新还没到客户端，我们把长轮询的生效延迟压到了毫秒级 四种 gRPC 流式服务端，我们踩坑后终于知道什么时候该用哪种了 接了大模型生成测试用例后，我们统计了一周数据，发现人工还得改掉 40%

日采 TB 级日志，Kafka 零拷贝和 ES 直写到底差多少资源？我们跑了一周实测 Sentinel 集群限流 Token Server 挂了，我们在控制台侧做了本地降级，压测数据验证了容灾效果 我在 gRPC 拦截器里把重试、超时、熔断串成一条链，业务代码终于不用再贴满重复的容错片段了 你的 UI 测试脚本是不是也写了一堆 findElement 然后改版就全崩 从延迟、积压、分区倾斜三个指标反推 Pulsar 容量规划，比盯着 CPU 内存管用得多 同一套压测场景，滑动窗口和令牌桶在突发流量下的延迟分布差了一个数量级 RocketMQ 顺序消息靠分区有序，真碰上需要全局强顺序的业务，加个业务层序号成本到底高多少

BEST 实测了 Kafka MirrorMaker 和 Pulsar 异地复制的容灾切换时间，RPO 的差距比预想的大 排查缓存问题我一般就靠慢查询、热 Key 分析和命中率曲线这三板斧，基本能把事故现场还原出来 模拟 Redis 挂了、数据刚好过期、100 个请求同时打进来，这套单元测试怎么搭 Kafka 的 Exactly-Once 语义听着很美，在跨系统场景下我还是老老实实上了业务去重表 查缓存没命中就全砸到库上，连接池满了怎么办？我用 CompletableFuture 把重复请求合并了一下 缓存预热搞不好比冷启动还慢——三种加载策略的耗时曲线和雪崩风险，压测数据摆出来聊聊 IoT 消息队列选型，我把 MQTT 和 AMQP 丢到弱网里跑了一组对比数据 康威定律之下：我们拆服务前先调了组织，结果跨团队协作还是掉了链子 跨服务日志里 traceId 断了，排查时用这几种传参和存储方式把它接上 缓存命中率跌到多少该告警？我们反过来用空值率和穿透量推了一把阈值

订单超时取消时，消息重试用指数退避还是直接扔死信？我们把三种策略放一起跑了一遍 拆微服务时，我们纠结了半年的订单-商品-用户边界，最后被一张数据库表说服了 拆微服务最怕拆出个“分布式单体”：同步调用链太深、共享数据库、没法独立发布，这三个信号我靠它拦住了好几次 线上缓存雪崩了三次，我们靠自动识别热点 Key 和动态分散才把这事摁住