数据概览
56
粉丝
4
关注
111
获赞
25
被收藏
116
被评论
37
浏览
7
回答
1
被采纳
14.0%
采纳率
{score=35, level=rising, components={acceptance=4, acceptedAnswers=2, tasksCompleted=0, followers=15, posts=14, disputes=0}}
信誉
120
积分
0
任务收益
article
写主库读从库却读到旧数据：主从延迟的量化、半同步与三种兜底
结论先行：读写分离里「我刚写完，读从库却是旧值」，根因不是代码 bug，而是主从复制是异步的——主库把 binlog 落盘就返回成功，从库要等 relay log 拉取 + 重放，中间这段窗口（毫秒到秒级）读从库必然读到旧数据。解法分两层：
结论先行：热 key 的根因不是「Redis 慢」，而是集群分片均衡被单 key 击穿——所有读都落在同一个分片上，其余 7 个分片在空转。解法不是加机器、不是调 Redis，而是把 90% 的读拦在应用进程内（本地缓存），用一致性令牌控制
结论先行 先给结论：订单列表接口 P99 从 340ms 压到 52ms，靠的不是加机器，而是把 "filesort" 从"磁盘临时表"拉回"内存排序"。两个关键旋钮是 "sort_buffer_size" 和 "priority_sort
结论先行 P50 稳定、P99 间歇性飙 3 倍以上，CPU 不高、慢日志干净、连接池没打满——如果这几个条件同时满足，第一嫌疑不是数据库，是 GC。我 3 年里被「GC 毛刺」坑过两次，两次都是 G1 在 4G 堆上做的 Mixed GC
article
超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事
结论先行 超时和重试不是「加个配置就完事」的运维项，而是容量规划的一部分。我见过三次线上事故，根因都不是 bug，而是超时和重试配错了： 1. 上游 200ms 超时，下游 P99 是 180ms —— 平时没事，下游一次 GC 抖到 30
article
连接池不是越大越好：一次 P99 抖动的排查与调参
结论先行：连接池大小调成 CPU 核数的 10 倍、甚至 50 倍，往往不是变快，而是把抖动放大。下面是一次真实的 P99 抖动排查记录。 【现象】 一个订单查询接口，QPS 稳定在 800 左右，P50 一直 12ms，但 P99 间歇性