1. 这不是笔记是系统设计能力的“肌肉记忆”训练手册“system-design-notes”这个标题乍看平平无奇像极了某位工程师随手建的 GitHub 仓库名或是 Slack 里被快速刷过的共享文档链接。但如果你在一线做过三年以上后端、平台或基础设施相关工作就会立刻意识到这四个单词背后藏着一个真实、高频、高压、且几乎无法靠临阵磨枪解决的核心战场——如何在白板上在30分钟内把一个模糊的业务需求拆解成可落地、可扩展、可运维的分布式系统骨架。这不是考试是面试是技术方案评审是凌晨三点线上告警时你脑子里最先闪过的链路图。我带过十几轮校招和社招面试也经历过从单体服务崩盘到重构为微服务集群的完整周期最深的体会是所谓“系统设计能力”根本不是天赋而是通过大量结构化笔记沉淀下来的条件反射。这里的 notes不是随手记下的碎片灵感而是经过反复验证、交叉比对、踩坑修正后的决策日志。它记录的是“为什么选 Kafka 而不是 RabbitMQ 做订单队列”是“为什么用户中心必须做读写分离而商品中心可以先不做”是“为什么这个缓存穿透方案在压测时 QPS 掉了40%”。它解决的是工程师在面对“做一个支持千万日活的秒杀系统”这种命题时不再从零开始拍脑袋而是能迅速调用已有的模式库、权衡矩阵和失败案例库做出有依据的判断。适合谁不是刚学完 HTTP 协议的新人而是已经写过至少两个中型项目、能独立部署服务、对数据库慢查有基本敏感度的实战派也不是只关注代码优雅性的纯算法选手而是每天要和运维、DBA、前端、产品经理掰扯资源配比和技术边界的“接口人”。它不教你如何写 Hello World但它能让你在技术方案会上说出的第一句话就让人觉得“这人靠谱”。2. 内容整体设计与思路拆解为什么“笔记”必须是结构化的决策日志2.1 拒绝“知识搬运”拥抱“决策复盘”笔记的本质是认知压缩市面上绝大多数“系统设计笔记”存在一个致命误区它们本质上是知识搬运工。把《Designing Data-Intensive Applications》里的章节标题抄下来把 Gossip 协议的定义背一遍把 CAP 定理的三种组合列个表——这叫资料整理不叫笔记。真正的 system-design-notes核心价值在于“决策复盘”。举个具体例子当你要设计一个短链服务short URL service你会面临至少五个关键决策点ID 生成策略自增IDSnowflakeHash、存储选型MySQLRedisSSDHDD混合、缓存策略本地缓存分布式缓存TTL怎么设、防刷机制IP限流用户限流令牌桶还是漏桶、高可用方案主从切换多机房部署。每一个选项背后都对应着成本、复杂度、性能、可维护性四个维度的真实 trade-off。我的笔记里不会只写“用 Snowflake”而是会记录“2023年Q3我们为营销活动上线短链服务初期用 MySQL 自增ID上线后第2天因分库分表改造导致ID重复回滚耗时47分钟改用 Snowflake 后ID 生成延迟稳定在 0.8ms 内但引入了时钟回拨风险最终在服务启动时加入 NTP 校验 降级为 Redis INCR对比测试显示同等并发下Snowflake 比 UUID 存储空间节省62%索引查询快3.2倍”。你看这已经不是知识点这是带着时间戳、数据、后果、补救措施的完整决策快照。它之所以有效是因为它完成了“认知压缩”——把一次耗时数天的方案讨论、压测、上线、回滚的全部信息压缩成一行可检索、可复用的结论。下次再做类似项目你不需要重走一遍弯路只需要搜索“short url id generation”就能看到这个快照并基于当前新条件比如这次预算更紧、团队对 Redis 更熟做微调。2.2 结构化框架用“场景-问题-方案-验证”四层漏斗过滤噪音没有结构的笔记就是信息垃圾场。我坚持用一套固定的四层框架来组织每一条 notes这套框架是我从无数次无效会议和混乱文档中血泪总结出来的场景Scenario精确锚定上下文。绝不写“高并发系统”而是写“电商大促期间首页商品瀑布流接口预估峰值 QPS 50,000P99 延迟要求 200ms现有架构为单体 Java 应用 MySQL 主从”。场景越具体后续决策越精准。问题Problem直击本质痛点。不是“性能差”而是“MySQL 主库 CPU 持续 95%慢查询日志显示SELECT * FROM product WHERE category_id ? ORDER BY sort_order LIMIT 20占总耗时 68%该 SQL 无法走索引全表扫描平均耗时 1.2s”。问题必须可测量、可定位。方案Solution明确技术选型与关键参数。不写“加缓存”而是写“在应用层增加 Guava Cache 本地缓存maximumSize(10000),expireAfterWrite(10, TimeUnit.MINUTES),refreshAfterWrite(5, TimeUnit.MINUTES)同时将category_id sort_order建联合索引覆盖查询字段”。参数不是随便填的10000是根据预估热点商品数 × 3 倍冗余计算得出10分钟是商品排序更新频率的 2 倍。验证Validation用数据说话。不是“效果很好”而是“上线后主库 CPU 降至 45%该 SQL 平均耗时从 1.2s 降至 8msP99 延迟从 1.8s 降至 180ms缓存命中率稳定在 92.3%”。验证数据必须来自真实压测或灰度流量而非开发环境模拟。这套框架像一个漏斗自动过滤掉所有模糊、主观、无法证伪的描述。它强迫你把“我觉得”变成“数据显示”把“可能有问题”变成“监控指标已突破阈值”。久而久之你的思维习惯就被重塑了——看到需求第一反应不再是“用什么技术”而是“在这个场景下核心瓶颈是什么数据指标是多少”2.3 领域驱动分类按“数据流”而非“技术栈”组织知识很多人的笔记按技术栈分类Kafka 笔记、Redis 笔记、MySQL 笔记……这在学习阶段有用但在实战中极其低效。因为真实问题从来不是“Redis 怎么用”而是“用户登录态如何在多端Web/App/小程序间同步且保证退出即失效”。这个问题会横跨 Redis存储 token、JWT传输凭证、网关鉴权拦截、前端token 刷新逻辑多个技术点。所以我的 notes 严格按“数据流”和“核心能力域”组织共分六大主干数据持久化域聚焦“数据怎么存、怎么查、怎么保证一致”。包括分库分表策略ShardingSphere vs 自研路由、读写分离的中间件选型MyCat vs ProxySQL、最终一致性事件驱动Debezium Kafka、多源数据聚合Elasticsearch 同步策略。流量调度域聚焦“请求怎么来、怎么分、怎么扛”。包括 API 网关选型Kong vs Spring Cloud Gateway、负载均衡算法加权轮询 vs 最小连接数 vs 一致性哈希、熔断降级Sentinel 规则配置实战、AB 测试流量染色。状态管理域聚焦“状态放哪、怎么同步、怎么失效”。包括分布式 SessionRedis Cluster vs JWT、分布式锁Redlock vs ZooKeeper 临时节点、幂等性设计Token DB 唯一索引 vs 状态机。可观测性域聚焦“出了问题怎么发现、怎么定位、怎么归因”。包括日志采集Filebeat Logstash ES 的 pipeline 优化、链路追踪Jaeger Agent 部署模式选择、指标监控Prometheus exporter 选择与自定义指标埋点。安全合规域聚焦“数据怎么保护、权限怎么控、审计怎么留痕”。包括敏感字段加密AES-GCM vs SM4、OAuth2.0 授权码模式在微服务中的落地网关统一鉴权 vs 服务间透传、GDPR 数据删除的级联实现。成本效能域聚焦“钱花在哪、效果如何、还能省多少”。包括云资源规格选型CPU 密集型 vs 内存密集型实例对比、CDN 缓存策略Cache-Control 头的精细化设置、冷热数据分离S3 Glacier vs 本地 SSD。这种分类法让你在遇到新问题时能直接定位到“状态管理域”然后在里面搜索“多端登录态同步”而不是在 Redis 笔记里大海捞针再跳到 JWT 笔记再跳到网关笔记……效率提升是数量级的。3. 核心细节解析与实操要点从“知道”到“做到”的关键跃迁3.1 场景描述必须包含“三要素”规模、SLA、约束很多人写笔记时场景描述非常潦草“做一个消息通知系统”。这毫无价值。真正有用的场景必须包含三个硬性要素规模Scale这是所有技术选型的基石。不能只说“用户量大”要量化。例如“日均推送消息 2000 万条其中 80% 集中在晚 8-10 点峰值 TPS 达 15,000目标用户为 App 用户设备在线率约 65%”。这个数据直接决定了你是否需要 Kafka吞吐量还是 RabbitMQ低延迟决定了你是否需要做消息分级普通通知 vs 紧急告警决定了你是否需要做离线推送APNs/FCM的兜底。SLAService Level Agreement这是技术方案的“红线”。不能只说“要快”要定义清楚。例如“99.9% 的消息需在 3 秒内触达用户设备99.99% 的消息需在 1 分钟内完成投递含离线重试消息丢失率 0.001%”。这个 SLA 直接决定了你能否接受“尽力而为”的 UDP 协议决定了你是否必须做消息持久化磁盘 or 内存决定了你是否需要做端到端的 ACK 机制。约束Constraints这是现实世界的“枷锁”。不能只考虑技术最优要考虑团队、成本、时间。例如“团队目前无 Kafka 运维经验但有成熟 Redis 运维体系预算限制不允许采购商业消息中间件上线周期仅 6 周需最小化改动现有用户服务”。这个约束直接否决了“上一套 Kafka 集群”的理想方案把你逼向“基于 Redis Stream Lua 脚本实现轻量级消息队列”的务实路径。我见过太多失败的设计根源就在于一开始就没把这三要素钉死。一个“日均百万”的系统硬套“日均亿级”的架构结果是过度设计、维护成本爆炸一个“SLA 要求 99.99%”的系统用了“尽力而为”的方案结果是线上事故频发。所以我的每一条 notes开头必然是这样一行“【场景】日均消息 2000 万峰值 TPS 15kSLA99.9% 3s99.99% 1min约束团队无 Kafka 经验预算有限6 周上线”。3.2 方案设计必须回答“五个为什么”穿透表面直抵本质写下“方案”二字只是开始。真正的价值在于对方案进行五层追问。这源于丰田生产方式的“5 Whys”分析法我将其移植到系统设计中确保每个决策都有坚实根基Why this technology?为什么选这个技术不是“因为大家都用”而是“因为 Kafka 的分区机制天然支持水平扩展其磁盘顺序写入特性在 15k TPS 下单节点吞吐稳定在 100MB/s远超 RabbitMQ 的内存模型在同等压力下的表现实测 RabbitMQ 在 12k TPS 时 Erlang VM GC 频繁延迟抖动剧烈”。Why this configuration?为什么是这个配置不是“网上教程这么写的”而是“replication.factor3是为了容忍 1 个 broker 故障min.insync.replicas2是为了在保证可用性的同时避免acksall导致的写入阻塞retention.ms6048000007天是基于业务方确认超过 7 天未消费的消息视为失效且磁盘成本可控7天数据量 ≈ 2TBSSD 成本 $500”。Why this topology?为什么是这个拓扑不是“画个图好看”而是“采用Producer - Kafka Cluster (3 nodes) - Consumer Group (2 instances)的拓扑是因为消费者实例数2等于 Kafka Topic 的 Partition 数2保证了每个 Partition 由唯一 Consumer 消费避免了消息乱序同时Consumer 实例部署在不同可用区避免单点故障”。Why this fallback?为什么有这个兜底不是“以防万一”而是“当 Kafka 集群不可用时Producer 自动降级为写入本地文件队列使用 RocksDB并启动定时任务每 30 秒尝试重连 Kafka本地队列最大容量为 10 万条预计可支撑 Kafka 故障 1 小时15k TPS * 3600s / 100000 ≈ 0.54 小时足够运维介入”。Why this metric?为什么监控这个指标不是“监控平台有这个选项”而是“重点监控kafka.server:typeReplicaManager,nameUnderReplicatedPartitions因为该值 0 意味着有 Partition 的 ISRIn-Sync Replicas数量不足是集群不稳定、数据丢失风险的最早期信号其阈值设为 0一旦告警必须 5 分钟内响应”。这五个“为什么”把一个看似简单的“用 Kafka”决策变成了一个立体的、有纵深、有预案、有验证的完整方案。它逼着你去查文档、做压测、画拓扑、写降级代码、配监控告警。这才是工程师该干的事。3.3 验证环节必须包含“三类数据”让结论无可辩驳“验证”是整个 notes 的皇冠也是最容易被敷衍的部分。很多人写“上线后效果良好”这等于没写。真正的验证必须提供三类硬数据基准数据Baseline方案上线前的原始状态。这是所有对比的起点。例如“上线前MySQL 主库 CPU 平均 85%峰值 98%SELECT * FROM order WHERE user_id ? AND status paid查询平均耗时 1.5sP99 为 3.2s订单创建接口 P99 延迟 2.8s”。没有 baseline就谈不上“提升”。实施数据Implementation方案上线过程中的关键数据。这证明方案是可控、可预测的。例如“灰度发布期间10% 流量Kafka Producer 发送成功率 99.998%平均延迟 12msConsumer Group 消费 Lag 保持在 500 条以内Redis 缓存命中率从 35% 提升至 89%”。这些数据告诉你方案本身没有引入新的、不可控的风险。结果数据Result方案全量上线后的最终效果。这是价值的最终体现。例如“全量上线后MySQL 主库 CPU 降至平均 42%峰值 65%上述 SQL 查询平均耗时降至 15msP99 为 45ms订单创建接口 P99 延迟降至 180ms用户投诉‘下单卡顿’下降 92%”。这里的数据必须和 baseline 严格对应形成闭环。我坚持所有验证数据必须来自生产环境的真实监控系统如 Prometheus Grafana而非本地 JMeter 模拟。因为只有真实流量才能暴露“缓存雪崩”、“连接池耗尽”、“GC 颠簸”这些模拟器永远无法复现的幽灵问题。有一次我们为一个搜索服务加了 ElasticsearchJMeter 压测一切完美但上线后第二天监控发现 ES 集群 JVM 内存使用率持续 95%GC 频繁。追查发现是某个运营后台的“全量导出”功能触发了 ES 的深度分页from10000, size100导致大量内存被TopDocs占用。这个教训被我郑重记入 notes“ES 深度分页是内存杀手必须在网关层强制拦截from 1000的请求并返回友好提示”。这条 notes后来帮我们避开了三次类似的线上事故。4. 实操过程与核心环节实现一份可直接“抄作业”的短链服务笔记4.1 【场景】日均短链生成 500 万峰值 TPS 8000SLA99.9% 100ms99.99% 500ms约束团队熟悉 MySQL 和 Redis无 Go/Python 高并发服务经验2 周上线这个场景设定直接排除了“用 Go 写高性能短链服务 Redis MySQL”的炫技方案。我们必须在熟悉的、可控的技术栈上做出最稳妥的选择。规模500 万/日意味着 MySQL 单表数据量将在半年内突破 10 亿必须考虑分表SLA100ms意味着任何网络 IO 都必须极致优化约束2周上线意味着不能碰任何新中间件所有组件必须是团队手熟的。4.2 【问题】MySQL 自增 ID 作为短链码导致分库分表后全局唯一性丧失且 ID 连续性易被爬虫遍历高并发下INSERT ... SELECT生成短链的行锁竞争严重P99 延迟飙升至 450ms这是我们在上一个版本中踩的坑。当时为了快速上线直接用AUTO_INCREMENT结果分库后不同库的 ID 重复导致短链冲突而为了生成唯一短链码我们用了INSERT IGNORE INTO short_url (long_url, code) VALUES (?, ?)其中code是随机生成的 6 位字符串。在 8000 TPS 下INSERT IGNORE的唯一索引冲突检查引发了严重的行锁等待数据库监控显示Innodb_row_lock_time_avg持续高于 200ms。4.3 【方案】放弃自增 ID采用“号段模式”预生成 Redis 缓存 MySQL 异步落库这是在约束下找到的最优解。核心思想是把“生成唯一 ID”这个高并发、强一致的瓶颈操作变成“批量预取 本地缓存”的低延迟操作。号段生成器MySQL新建一张id_generator表结构为(biz_tag VARCHAR(32), max_id BIGINT, step INT, version INT)。biz_tag为short_url。每次取号时执行UPDATE id_generator SET max_id max_id step, version version 1 WHERE biz_tag short_url AND version ?。成功则返回旧的max_id失败则重试。step设为 1000意味着每次 UPDATE 只需执行一次就能拿到 1000 个连续 ID。这极大降低了数据库压力。Redis 缓存本地化应用启动时从id_generator表中取出第一个号段如 1-1000存入本地内存ConcurrentHashMap并异步启动一个守护线程当本地号段剩余量 100 时再次向 MySQL 请求下一个号段1001-2000并原子性地替换本地缓存。这样99.9% 的 ID 生成请求都在内存中完成毫秒级。短链码转换Base62拿到数字 ID如 123456后用 Base62 编码0-9a-zA-Z共 62 个字符转换为 6 位字符串如2fXc。Base62 比 Base36仅 0-9a-z更短且避免了大小写混淆l和1O和0。MySQL 异步落库削峰生成短链码后不立即写入 MySQL 主库。而是将(long_url, short_code, create_time)三元组放入一个内存队列如 Disruptor由一个单独的、低优先级的线程池以固定速率如 1000 QPS批量写入 MySQL。这彻底解耦了“生成”和“存储”保证了生成接口的超高性能。提示Base62 编码的实现必须是无状态的、纯函数式的。我用了一个预计算的字符数组char[] BASE62_CHARS 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.toCharArray()然后通过while (num 0) { result.append(BASE62_CHARS[num % 62]); num / 62; }实现。避免使用任何正则或字符串拼接保证单次编码耗时 1μs。4.4 【验证】全链路压测与生产数据基准数据旧方案INSERT IGNORE方式P99 延迟 450msMySQL CPU 85%Innodb_row_lock_waits每秒 120 次。实施数据灰度号段模式上线后本地内存 ID 生成耗时稳定在 0.02msRedis 缓存命中率 99.99%异步写入线程池积压队列长度始终 500。结果数据全量短链生成接口 P99 延迟降至 42ms满足 100ms SLAMySQL CPU 降至 35%Innodb_row_lock_waits归零上线首周生成短链 3800 万条无一重复无一超时。这个方案的精妙之处在于它没有发明任何新技术而是把已有的、团队熟悉的技术MySQL、Redis、线程池用一种符合场景约束的方式重新组合。它牺牲了一点点“绝对实时”的数据一致性短链生成后最多延迟 1 秒才写入 MySQL但换来了压倒性的性能、稳定性和可维护性。这就是系统设计的真谛在约束中寻找最优解而非在真空中追求完美。5. 常见问题与排查技巧实录那些没人告诉你的“幽灵陷阱”5.1 问题缓存击穿Cache Breakdown——不是“没缓存”而是“缓存失效瞬间的惊群效应”几乎所有讲缓存的笔记都会提“缓存穿透、缓存击穿、缓存雪崩”但绝大多数人只停留在概念层面。真正的坑在于“缓存击穿”的具体形态。它不是指某个 key 没有缓存而是指一个极热的 key如首页 Banner 图片其缓存 TTL 到期的瞬间恰好有数千个并发请求同时发现缓存 miss于是全部涌向数据库造成数据库瞬时压力飙升甚至被打挂。这和“缓存穿透”恶意请求不存在的 key完全不同。排查技巧监控先行在 Redis 监控中设置keyspace_hits和keyspace_misses的比率告警。如果某个 key 的misses突然激增且hits断崖下跌大概率是击穿。日志佐证在应用层对get(key)返回 null 的操作记录key和timestamp。如果发现同一key在毫秒级时间窗口内出现数百次null日志就是击穿铁证。数据库侧印证查看 MySQL 的Threads_running和Innodb_row_lock_waits如果它们与 Redis 的misses激增时间点完全吻合即可锁定。解决方案非教科书版永不过期 后台刷新推荐给热 key 设置一个超长 TTL如 30 天但业务逻辑中每次读取时检查其“逻辑过期时间”存于 value 中的一个字段。如果逻辑过期则由当前请求线程异步刷新缓存并立即返回旧值其他请求继续读旧值。这避免了“惊群”但要求业务能接受短暂的脏数据。分布式互斥锁慎用当发现缓存 miss先尝试获取一个分布式锁如SET key lock_value NX PX 30000获取成功者去加载 DB 并写入缓存失败者则 sleep 50ms 后重试。注意这个方案最大的坑是“锁过期时间”必须远大于 DB 查询耗时否则会出现“锁失效多个线程同时加载 DB”的二次击穿。我吃过亏DB 查询平均 200ms我把锁设为PX 300结果在 GC STW 期间锁提前释放导致 3 个线程同时加载DB 崩了。现在我的规则是锁过期时间 DB 查询 P99 耗时 × 3。5.2 问题消息堆积Message Backlog——不是“消费者太慢”而是“生产者太猛”消息队列堆积第一反应总是“消费者处理不过来”。但在我经手的 7 次重大堆积事故中有 5 次的根因是生产者。典型场景一个批处理任务需要发送 100 万条消息它没有做任何流控直接for (i0; i1000000; i) { kafkaTemplate.send(topic, msg); }。Kafka Producer 的默认batch.size16384linger.ms0这意味着每条消息都试图立即发送瞬间打满网络带宽和 Kafka broker 的网络线程broker 响应变慢Producer 的send()调用开始阻塞进而拖垮整个生产者应用。排查技巧看 Producer Metrics重点关注kafka.producer:typeproducer-metrics,client-idxxx下的record-send-rate实际发送速率和request-latency-avg请求延迟。如果record-send-rate远低于预期且request-latency-avg持续 100ms说明 Producer 已被压垮。看 Broker Metricskafka.server:typeBrokerTopicMetrics,nameBytesInPerSec如果突然飙升且kafka.network:typeRequestMetrics,nameRequestsPerSec,requestProduce也同步飙升基本可以确定是生产者洪流。抓包验证在 Producer 机器上tcpdump -i any port 9092 -w producer.pcap用 Wireshark 打开看 TCP 包的发送间隔和大小。如果看到大量小包 1KB以毫秒级间隔狂发就是罪魁祸首。解决方案实操版强制批处理修改 Producer 配置linger.ms10等待 10ms攒一批发batch.size3276832KB。这能让吞吐量提升 5-10 倍。客户端流控必须在业务代码中用Semaphore或RateLimiter控制send()的调用频率。例如RateLimiter.create(1000)表示每秒最多发送 1000 条。这比依赖 Kafka 的内部机制更可靠。异步发送 回调处理永远不要用send().get()同步等待。用send(callback)并在 callback 中处理Future的 success/failure。失败时必须有重试逻辑指数退避和死信队列DLQ兜底。我见过太多人忽略 callback导致消息发送失败无声无息数据丢失。5.3 问题数据库连接池耗尽Connection Pool Exhaustion——不是“连接数不够”而是“连接泄漏”Cannot get JDBC Connection报错第一反应是“把maxActive从 20 调到 100”。这往往是饮鸩止渴。真正的根因90% 是连接泄漏某个 DAO 方法打开了Connection但在异常分支中没有调用connection.close()。这个连接就永远留在池子里不再归还。随着请求增多可用连接越来越少最终池子枯竭。排查技巧Java 生态启用 Druid 连接池的泄漏检测druid.stat.log-slow-sqltruedruid.connection-propertiesdruid.stat.mergeSqltrue;druid.stat.slowSqlMillis2000最关键的是druid.remove-abandoned-on-borrowtrue和druid.remove-abandoned-timeout-millis60000。开启后如果一个连接被借出超过 60 秒未归还Druid 会自动回收它并打印 WARN 日志日志中会包含abandonedConnectionInfo里面有完整的堆栈精准定位到哪一行代码没关连接。Arthas 热诊断线上出问题不用重启。用 Arthas 的watch命令监控javax.sql.DataSource.getConnection()的返回值再watchjava.sql.Connection.close()的调用对比两者数量。如果getConnection次数远大于close次数就是泄漏。数据库侧验证show processlist看Command列是否大量为Sleep且Time列数值巨大如 300。这些就是“睡死”的连接。解决方案防御式编程必须用 try-with-resources所有涉及Connection,Statement,ResultSet的代码必须写成try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { // business logic } catch (SQLException e) { // handle }这是 JDK 7 引入的语法糖能保证无论正常执行还是抛异常资源都会被自动关闭。统一 DAO 层封装在 BaseDAO 中提供executeQuery(String sql, Object... args)方法内部完成getConnection-prepareStatement-setParameters-executeQuery-closeAll的全流程。业务代码只需关心 SQL 和参数彻底屏蔽资源管理细节。这是我团队的强制规范上线三年零连接泄漏事故。6. 个人经验笔记不是终点而是你技术影响力的放大器写 system-design-notes 到今天已经是我工作流程中不可分割的一部分。它早已超越了“备忘录”的范畴成了我技术影响力的核心载体。我分享几条最实在的体会首先它倒逼你成为“问题终结者”而非“方案搬运工”。当你习惯性地在每条 notes 里写清“场景-问题-方案-验证”你就再也无法忍受那种“这个需求我们用微服务吧”、“这个性能差加个缓存吧”的模糊表达。你会本能地追问“哪个场景什么问题数据指标是多少”。这种思维惯性会让你在任何技术讨论中都成为那个能一针见血指出核心矛盾的人。其次它构建了你独一无二的“技术信用资产”。在团队里当别人遇到一个棘手问题第一反应是翻你的 notes而不是去 Stack Overflow 或问 ChatGPT。因为你的 notes 里有他们正在经历的、一模一样的场景有你踩过的坑有你验证过的数据。这种基于真实战功建立的信任是任何头衔和证书都无法替代的。我现在的职级晋升材料里“主导编写并维护团队系统设计知识库system-design-notes覆盖 12 个核心业务域被引用超 2000 次平均缩短方案设计周期 40%”是 HR 和技术委员会都高度认可的关键项。最后它让你的技术输出具备了“可传承性”。很多资深工程师离开公司后他脑子里的经验就跟着走了。而我的 notes是一份活的、可搜索的、可执行的文档。新同学入职他的第一个任务不是看代码而是阅读notes/README.md里面清晰地列出了“入职第一周必读的 5 条 notes”比如notes/data-persistence/sharding-strategy-for-user-center.md。这比任何口头传授都高效、准确、无歧义。所以别再把“system-design-notes 系统设计笔记：结构化决策日志的实战方法论
1. 这不是笔记是系统设计能力的“肌肉记忆”训练手册“system-design-notes”这个标题乍看平平无奇像极了某位工程师随手建的 GitHub 仓库名或是 Slack 里被快速刷过的共享文档链接。但如果你在一线做过三年以上后端、平台或基础设施相关工作就会立刻意识到这四个单词背后藏着一个真实、高频、高压、且几乎无法靠临阵磨枪解决的核心战场——如何在白板上在30分钟内把一个模糊的业务需求拆解成可落地、可扩展、可运维的分布式系统骨架。这不是考试是面试是技术方案评审是凌晨三点线上告警时你脑子里最先闪过的链路图。我带过十几轮校招和社招面试也经历过从单体服务崩盘到重构为微服务集群的完整周期最深的体会是所谓“系统设计能力”根本不是天赋而是通过大量结构化笔记沉淀下来的条件反射。这里的 notes不是随手记下的碎片灵感而是经过反复验证、交叉比对、踩坑修正后的决策日志。它记录的是“为什么选 Kafka 而不是 RabbitMQ 做订单队列”是“为什么用户中心必须做读写分离而商品中心可以先不做”是“为什么这个缓存穿透方案在压测时 QPS 掉了40%”。它解决的是工程师在面对“做一个支持千万日活的秒杀系统”这种命题时不再从零开始拍脑袋而是能迅速调用已有的模式库、权衡矩阵和失败案例库做出有依据的判断。适合谁不是刚学完 HTTP 协议的新人而是已经写过至少两个中型项目、能独立部署服务、对数据库慢查有基本敏感度的实战派也不是只关注代码优雅性的纯算法选手而是每天要和运维、DBA、前端、产品经理掰扯资源配比和技术边界的“接口人”。它不教你如何写 Hello World但它能让你在技术方案会上说出的第一句话就让人觉得“这人靠谱”。2. 内容整体设计与思路拆解为什么“笔记”必须是结构化的决策日志2.1 拒绝“知识搬运”拥抱“决策复盘”笔记的本质是认知压缩市面上绝大多数“系统设计笔记”存在一个致命误区它们本质上是知识搬运工。把《Designing Data-Intensive Applications》里的章节标题抄下来把 Gossip 协议的定义背一遍把 CAP 定理的三种组合列个表——这叫资料整理不叫笔记。真正的 system-design-notes核心价值在于“决策复盘”。举个具体例子当你要设计一个短链服务short URL service你会面临至少五个关键决策点ID 生成策略自增IDSnowflakeHash、存储选型MySQLRedisSSDHDD混合、缓存策略本地缓存分布式缓存TTL怎么设、防刷机制IP限流用户限流令牌桶还是漏桶、高可用方案主从切换多机房部署。每一个选项背后都对应着成本、复杂度、性能、可维护性四个维度的真实 trade-off。我的笔记里不会只写“用 Snowflake”而是会记录“2023年Q3我们为营销活动上线短链服务初期用 MySQL 自增ID上线后第2天因分库分表改造导致ID重复回滚耗时47分钟改用 Snowflake 后ID 生成延迟稳定在 0.8ms 内但引入了时钟回拨风险最终在服务启动时加入 NTP 校验 降级为 Redis INCR对比测试显示同等并发下Snowflake 比 UUID 存储空间节省62%索引查询快3.2倍”。你看这已经不是知识点这是带着时间戳、数据、后果、补救措施的完整决策快照。它之所以有效是因为它完成了“认知压缩”——把一次耗时数天的方案讨论、压测、上线、回滚的全部信息压缩成一行可检索、可复用的结论。下次再做类似项目你不需要重走一遍弯路只需要搜索“short url id generation”就能看到这个快照并基于当前新条件比如这次预算更紧、团队对 Redis 更熟做微调。2.2 结构化框架用“场景-问题-方案-验证”四层漏斗过滤噪音没有结构的笔记就是信息垃圾场。我坚持用一套固定的四层框架来组织每一条 notes这套框架是我从无数次无效会议和混乱文档中血泪总结出来的场景Scenario精确锚定上下文。绝不写“高并发系统”而是写“电商大促期间首页商品瀑布流接口预估峰值 QPS 50,000P99 延迟要求 200ms现有架构为单体 Java 应用 MySQL 主从”。场景越具体后续决策越精准。问题Problem直击本质痛点。不是“性能差”而是“MySQL 主库 CPU 持续 95%慢查询日志显示SELECT * FROM product WHERE category_id ? ORDER BY sort_order LIMIT 20占总耗时 68%该 SQL 无法走索引全表扫描平均耗时 1.2s”。问题必须可测量、可定位。方案Solution明确技术选型与关键参数。不写“加缓存”而是写“在应用层增加 Guava Cache 本地缓存maximumSize(10000),expireAfterWrite(10, TimeUnit.MINUTES),refreshAfterWrite(5, TimeUnit.MINUTES)同时将category_id sort_order建联合索引覆盖查询字段”。参数不是随便填的10000是根据预估热点商品数 × 3 倍冗余计算得出10分钟是商品排序更新频率的 2 倍。验证Validation用数据说话。不是“效果很好”而是“上线后主库 CPU 降至 45%该 SQL 平均耗时从 1.2s 降至 8msP99 延迟从 1.8s 降至 180ms缓存命中率稳定在 92.3%”。验证数据必须来自真实压测或灰度流量而非开发环境模拟。这套框架像一个漏斗自动过滤掉所有模糊、主观、无法证伪的描述。它强迫你把“我觉得”变成“数据显示”把“可能有问题”变成“监控指标已突破阈值”。久而久之你的思维习惯就被重塑了——看到需求第一反应不再是“用什么技术”而是“在这个场景下核心瓶颈是什么数据指标是多少”2.3 领域驱动分类按“数据流”而非“技术栈”组织知识很多人的笔记按技术栈分类Kafka 笔记、Redis 笔记、MySQL 笔记……这在学习阶段有用但在实战中极其低效。因为真实问题从来不是“Redis 怎么用”而是“用户登录态如何在多端Web/App/小程序间同步且保证退出即失效”。这个问题会横跨 Redis存储 token、JWT传输凭证、网关鉴权拦截、前端token 刷新逻辑多个技术点。所以我的 notes 严格按“数据流”和“核心能力域”组织共分六大主干数据持久化域聚焦“数据怎么存、怎么查、怎么保证一致”。包括分库分表策略ShardingSphere vs 自研路由、读写分离的中间件选型MyCat vs ProxySQL、最终一致性事件驱动Debezium Kafka、多源数据聚合Elasticsearch 同步策略。流量调度域聚焦“请求怎么来、怎么分、怎么扛”。包括 API 网关选型Kong vs Spring Cloud Gateway、负载均衡算法加权轮询 vs 最小连接数 vs 一致性哈希、熔断降级Sentinel 规则配置实战、AB 测试流量染色。状态管理域聚焦“状态放哪、怎么同步、怎么失效”。包括分布式 SessionRedis Cluster vs JWT、分布式锁Redlock vs ZooKeeper 临时节点、幂等性设计Token DB 唯一索引 vs 状态机。可观测性域聚焦“出了问题怎么发现、怎么定位、怎么归因”。包括日志采集Filebeat Logstash ES 的 pipeline 优化、链路追踪Jaeger Agent 部署模式选择、指标监控Prometheus exporter 选择与自定义指标埋点。安全合规域聚焦“数据怎么保护、权限怎么控、审计怎么留痕”。包括敏感字段加密AES-GCM vs SM4、OAuth2.0 授权码模式在微服务中的落地网关统一鉴权 vs 服务间透传、GDPR 数据删除的级联实现。成本效能域聚焦“钱花在哪、效果如何、还能省多少”。包括云资源规格选型CPU 密集型 vs 内存密集型实例对比、CDN 缓存策略Cache-Control 头的精细化设置、冷热数据分离S3 Glacier vs 本地 SSD。这种分类法让你在遇到新问题时能直接定位到“状态管理域”然后在里面搜索“多端登录态同步”而不是在 Redis 笔记里大海捞针再跳到 JWT 笔记再跳到网关笔记……效率提升是数量级的。3. 核心细节解析与实操要点从“知道”到“做到”的关键跃迁3.1 场景描述必须包含“三要素”规模、SLA、约束很多人写笔记时场景描述非常潦草“做一个消息通知系统”。这毫无价值。真正有用的场景必须包含三个硬性要素规模Scale这是所有技术选型的基石。不能只说“用户量大”要量化。例如“日均推送消息 2000 万条其中 80% 集中在晚 8-10 点峰值 TPS 达 15,000目标用户为 App 用户设备在线率约 65%”。这个数据直接决定了你是否需要 Kafka吞吐量还是 RabbitMQ低延迟决定了你是否需要做消息分级普通通知 vs 紧急告警决定了你是否需要做离线推送APNs/FCM的兜底。SLAService Level Agreement这是技术方案的“红线”。不能只说“要快”要定义清楚。例如“99.9% 的消息需在 3 秒内触达用户设备99.99% 的消息需在 1 分钟内完成投递含离线重试消息丢失率 0.001%”。这个 SLA 直接决定了你能否接受“尽力而为”的 UDP 协议决定了你是否必须做消息持久化磁盘 or 内存决定了你是否需要做端到端的 ACK 机制。约束Constraints这是现实世界的“枷锁”。不能只考虑技术最优要考虑团队、成本、时间。例如“团队目前无 Kafka 运维经验但有成熟 Redis 运维体系预算限制不允许采购商业消息中间件上线周期仅 6 周需最小化改动现有用户服务”。这个约束直接否决了“上一套 Kafka 集群”的理想方案把你逼向“基于 Redis Stream Lua 脚本实现轻量级消息队列”的务实路径。我见过太多失败的设计根源就在于一开始就没把这三要素钉死。一个“日均百万”的系统硬套“日均亿级”的架构结果是过度设计、维护成本爆炸一个“SLA 要求 99.99%”的系统用了“尽力而为”的方案结果是线上事故频发。所以我的每一条 notes开头必然是这样一行“【场景】日均消息 2000 万峰值 TPS 15kSLA99.9% 3s99.99% 1min约束团队无 Kafka 经验预算有限6 周上线”。3.2 方案设计必须回答“五个为什么”穿透表面直抵本质写下“方案”二字只是开始。真正的价值在于对方案进行五层追问。这源于丰田生产方式的“5 Whys”分析法我将其移植到系统设计中确保每个决策都有坚实根基Why this technology?为什么选这个技术不是“因为大家都用”而是“因为 Kafka 的分区机制天然支持水平扩展其磁盘顺序写入特性在 15k TPS 下单节点吞吐稳定在 100MB/s远超 RabbitMQ 的内存模型在同等压力下的表现实测 RabbitMQ 在 12k TPS 时 Erlang VM GC 频繁延迟抖动剧烈”。Why this configuration?为什么是这个配置不是“网上教程这么写的”而是“replication.factor3是为了容忍 1 个 broker 故障min.insync.replicas2是为了在保证可用性的同时避免acksall导致的写入阻塞retention.ms6048000007天是基于业务方确认超过 7 天未消费的消息视为失效且磁盘成本可控7天数据量 ≈ 2TBSSD 成本 $500”。Why this topology?为什么是这个拓扑不是“画个图好看”而是“采用Producer - Kafka Cluster (3 nodes) - Consumer Group (2 instances)的拓扑是因为消费者实例数2等于 Kafka Topic 的 Partition 数2保证了每个 Partition 由唯一 Consumer 消费避免了消息乱序同时Consumer 实例部署在不同可用区避免单点故障”。Why this fallback?为什么有这个兜底不是“以防万一”而是“当 Kafka 集群不可用时Producer 自动降级为写入本地文件队列使用 RocksDB并启动定时任务每 30 秒尝试重连 Kafka本地队列最大容量为 10 万条预计可支撑 Kafka 故障 1 小时15k TPS * 3600s / 100000 ≈ 0.54 小时足够运维介入”。Why this metric?为什么监控这个指标不是“监控平台有这个选项”而是“重点监控kafka.server:typeReplicaManager,nameUnderReplicatedPartitions因为该值 0 意味着有 Partition 的 ISRIn-Sync Replicas数量不足是集群不稳定、数据丢失风险的最早期信号其阈值设为 0一旦告警必须 5 分钟内响应”。这五个“为什么”把一个看似简单的“用 Kafka”决策变成了一个立体的、有纵深、有预案、有验证的完整方案。它逼着你去查文档、做压测、画拓扑、写降级代码、配监控告警。这才是工程师该干的事。3.3 验证环节必须包含“三类数据”让结论无可辩驳“验证”是整个 notes 的皇冠也是最容易被敷衍的部分。很多人写“上线后效果良好”这等于没写。真正的验证必须提供三类硬数据基准数据Baseline方案上线前的原始状态。这是所有对比的起点。例如“上线前MySQL 主库 CPU 平均 85%峰值 98%SELECT * FROM order WHERE user_id ? AND status paid查询平均耗时 1.5sP99 为 3.2s订单创建接口 P99 延迟 2.8s”。没有 baseline就谈不上“提升”。实施数据Implementation方案上线过程中的关键数据。这证明方案是可控、可预测的。例如“灰度发布期间10% 流量Kafka Producer 发送成功率 99.998%平均延迟 12msConsumer Group 消费 Lag 保持在 500 条以内Redis 缓存命中率从 35% 提升至 89%”。这些数据告诉你方案本身没有引入新的、不可控的风险。结果数据Result方案全量上线后的最终效果。这是价值的最终体现。例如“全量上线后MySQL 主库 CPU 降至平均 42%峰值 65%上述 SQL 查询平均耗时降至 15msP99 为 45ms订单创建接口 P99 延迟降至 180ms用户投诉‘下单卡顿’下降 92%”。这里的数据必须和 baseline 严格对应形成闭环。我坚持所有验证数据必须来自生产环境的真实监控系统如 Prometheus Grafana而非本地 JMeter 模拟。因为只有真实流量才能暴露“缓存雪崩”、“连接池耗尽”、“GC 颠簸”这些模拟器永远无法复现的幽灵问题。有一次我们为一个搜索服务加了 ElasticsearchJMeter 压测一切完美但上线后第二天监控发现 ES 集群 JVM 内存使用率持续 95%GC 频繁。追查发现是某个运营后台的“全量导出”功能触发了 ES 的深度分页from10000, size100导致大量内存被TopDocs占用。这个教训被我郑重记入 notes“ES 深度分页是内存杀手必须在网关层强制拦截from 1000的请求并返回友好提示”。这条 notes后来帮我们避开了三次类似的线上事故。4. 实操过程与核心环节实现一份可直接“抄作业”的短链服务笔记4.1 【场景】日均短链生成 500 万峰值 TPS 8000SLA99.9% 100ms99.99% 500ms约束团队熟悉 MySQL 和 Redis无 Go/Python 高并发服务经验2 周上线这个场景设定直接排除了“用 Go 写高性能短链服务 Redis MySQL”的炫技方案。我们必须在熟悉的、可控的技术栈上做出最稳妥的选择。规模500 万/日意味着 MySQL 单表数据量将在半年内突破 10 亿必须考虑分表SLA100ms意味着任何网络 IO 都必须极致优化约束2周上线意味着不能碰任何新中间件所有组件必须是团队手熟的。4.2 【问题】MySQL 自增 ID 作为短链码导致分库分表后全局唯一性丧失且 ID 连续性易被爬虫遍历高并发下INSERT ... SELECT生成短链的行锁竞争严重P99 延迟飙升至 450ms这是我们在上一个版本中踩的坑。当时为了快速上线直接用AUTO_INCREMENT结果分库后不同库的 ID 重复导致短链冲突而为了生成唯一短链码我们用了INSERT IGNORE INTO short_url (long_url, code) VALUES (?, ?)其中code是随机生成的 6 位字符串。在 8000 TPS 下INSERT IGNORE的唯一索引冲突检查引发了严重的行锁等待数据库监控显示Innodb_row_lock_time_avg持续高于 200ms。4.3 【方案】放弃自增 ID采用“号段模式”预生成 Redis 缓存 MySQL 异步落库这是在约束下找到的最优解。核心思想是把“生成唯一 ID”这个高并发、强一致的瓶颈操作变成“批量预取 本地缓存”的低延迟操作。号段生成器MySQL新建一张id_generator表结构为(biz_tag VARCHAR(32), max_id BIGINT, step INT, version INT)。biz_tag为short_url。每次取号时执行UPDATE id_generator SET max_id max_id step, version version 1 WHERE biz_tag short_url AND version ?。成功则返回旧的max_id失败则重试。step设为 1000意味着每次 UPDATE 只需执行一次就能拿到 1000 个连续 ID。这极大降低了数据库压力。Redis 缓存本地化应用启动时从id_generator表中取出第一个号段如 1-1000存入本地内存ConcurrentHashMap并异步启动一个守护线程当本地号段剩余量 100 时再次向 MySQL 请求下一个号段1001-2000并原子性地替换本地缓存。这样99.9% 的 ID 生成请求都在内存中完成毫秒级。短链码转换Base62拿到数字 ID如 123456后用 Base62 编码0-9a-zA-Z共 62 个字符转换为 6 位字符串如2fXc。Base62 比 Base36仅 0-9a-z更短且避免了大小写混淆l和1O和0。MySQL 异步落库削峰生成短链码后不立即写入 MySQL 主库。而是将(long_url, short_code, create_time)三元组放入一个内存队列如 Disruptor由一个单独的、低优先级的线程池以固定速率如 1000 QPS批量写入 MySQL。这彻底解耦了“生成”和“存储”保证了生成接口的超高性能。提示Base62 编码的实现必须是无状态的、纯函数式的。我用了一个预计算的字符数组char[] BASE62_CHARS 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.toCharArray()然后通过while (num 0) { result.append(BASE62_CHARS[num % 62]); num / 62; }实现。避免使用任何正则或字符串拼接保证单次编码耗时 1μs。4.4 【验证】全链路压测与生产数据基准数据旧方案INSERT IGNORE方式P99 延迟 450msMySQL CPU 85%Innodb_row_lock_waits每秒 120 次。实施数据灰度号段模式上线后本地内存 ID 生成耗时稳定在 0.02msRedis 缓存命中率 99.99%异步写入线程池积压队列长度始终 500。结果数据全量短链生成接口 P99 延迟降至 42ms满足 100ms SLAMySQL CPU 降至 35%Innodb_row_lock_waits归零上线首周生成短链 3800 万条无一重复无一超时。这个方案的精妙之处在于它没有发明任何新技术而是把已有的、团队熟悉的技术MySQL、Redis、线程池用一种符合场景约束的方式重新组合。它牺牲了一点点“绝对实时”的数据一致性短链生成后最多延迟 1 秒才写入 MySQL但换来了压倒性的性能、稳定性和可维护性。这就是系统设计的真谛在约束中寻找最优解而非在真空中追求完美。5. 常见问题与排查技巧实录那些没人告诉你的“幽灵陷阱”5.1 问题缓存击穿Cache Breakdown——不是“没缓存”而是“缓存失效瞬间的惊群效应”几乎所有讲缓存的笔记都会提“缓存穿透、缓存击穿、缓存雪崩”但绝大多数人只停留在概念层面。真正的坑在于“缓存击穿”的具体形态。它不是指某个 key 没有缓存而是指一个极热的 key如首页 Banner 图片其缓存 TTL 到期的瞬间恰好有数千个并发请求同时发现缓存 miss于是全部涌向数据库造成数据库瞬时压力飙升甚至被打挂。这和“缓存穿透”恶意请求不存在的 key完全不同。排查技巧监控先行在 Redis 监控中设置keyspace_hits和keyspace_misses的比率告警。如果某个 key 的misses突然激增且hits断崖下跌大概率是击穿。日志佐证在应用层对get(key)返回 null 的操作记录key和timestamp。如果发现同一key在毫秒级时间窗口内出现数百次null日志就是击穿铁证。数据库侧印证查看 MySQL 的Threads_running和Innodb_row_lock_waits如果它们与 Redis 的misses激增时间点完全吻合即可锁定。解决方案非教科书版永不过期 后台刷新推荐给热 key 设置一个超长 TTL如 30 天但业务逻辑中每次读取时检查其“逻辑过期时间”存于 value 中的一个字段。如果逻辑过期则由当前请求线程异步刷新缓存并立即返回旧值其他请求继续读旧值。这避免了“惊群”但要求业务能接受短暂的脏数据。分布式互斥锁慎用当发现缓存 miss先尝试获取一个分布式锁如SET key lock_value NX PX 30000获取成功者去加载 DB 并写入缓存失败者则 sleep 50ms 后重试。注意这个方案最大的坑是“锁过期时间”必须远大于 DB 查询耗时否则会出现“锁失效多个线程同时加载 DB”的二次击穿。我吃过亏DB 查询平均 200ms我把锁设为PX 300结果在 GC STW 期间锁提前释放导致 3 个线程同时加载DB 崩了。现在我的规则是锁过期时间 DB 查询 P99 耗时 × 3。5.2 问题消息堆积Message Backlog——不是“消费者太慢”而是“生产者太猛”消息队列堆积第一反应总是“消费者处理不过来”。但在我经手的 7 次重大堆积事故中有 5 次的根因是生产者。典型场景一个批处理任务需要发送 100 万条消息它没有做任何流控直接for (i0; i1000000; i) { kafkaTemplate.send(topic, msg); }。Kafka Producer 的默认batch.size16384linger.ms0这意味着每条消息都试图立即发送瞬间打满网络带宽和 Kafka broker 的网络线程broker 响应变慢Producer 的send()调用开始阻塞进而拖垮整个生产者应用。排查技巧看 Producer Metrics重点关注kafka.producer:typeproducer-metrics,client-idxxx下的record-send-rate实际发送速率和request-latency-avg请求延迟。如果record-send-rate远低于预期且request-latency-avg持续 100ms说明 Producer 已被压垮。看 Broker Metricskafka.server:typeBrokerTopicMetrics,nameBytesInPerSec如果突然飙升且kafka.network:typeRequestMetrics,nameRequestsPerSec,requestProduce也同步飙升基本可以确定是生产者洪流。抓包验证在 Producer 机器上tcpdump -i any port 9092 -w producer.pcap用 Wireshark 打开看 TCP 包的发送间隔和大小。如果看到大量小包 1KB以毫秒级间隔狂发就是罪魁祸首。解决方案实操版强制批处理修改 Producer 配置linger.ms10等待 10ms攒一批发batch.size3276832KB。这能让吞吐量提升 5-10 倍。客户端流控必须在业务代码中用Semaphore或RateLimiter控制send()的调用频率。例如RateLimiter.create(1000)表示每秒最多发送 1000 条。这比依赖 Kafka 的内部机制更可靠。异步发送 回调处理永远不要用send().get()同步等待。用send(callback)并在 callback 中处理Future的 success/failure。失败时必须有重试逻辑指数退避和死信队列DLQ兜底。我见过太多人忽略 callback导致消息发送失败无声无息数据丢失。5.3 问题数据库连接池耗尽Connection Pool Exhaustion——不是“连接数不够”而是“连接泄漏”Cannot get JDBC Connection报错第一反应是“把maxActive从 20 调到 100”。这往往是饮鸩止渴。真正的根因90% 是连接泄漏某个 DAO 方法打开了Connection但在异常分支中没有调用connection.close()。这个连接就永远留在池子里不再归还。随着请求增多可用连接越来越少最终池子枯竭。排查技巧Java 生态启用 Druid 连接池的泄漏检测druid.stat.log-slow-sqltruedruid.connection-propertiesdruid.stat.mergeSqltrue;druid.stat.slowSqlMillis2000最关键的是druid.remove-abandoned-on-borrowtrue和druid.remove-abandoned-timeout-millis60000。开启后如果一个连接被借出超过 60 秒未归还Druid 会自动回收它并打印 WARN 日志日志中会包含abandonedConnectionInfo里面有完整的堆栈精准定位到哪一行代码没关连接。Arthas 热诊断线上出问题不用重启。用 Arthas 的watch命令监控javax.sql.DataSource.getConnection()的返回值再watchjava.sql.Connection.close()的调用对比两者数量。如果getConnection次数远大于close次数就是泄漏。数据库侧验证show processlist看Command列是否大量为Sleep且Time列数值巨大如 300。这些就是“睡死”的连接。解决方案防御式编程必须用 try-with-resources所有涉及Connection,Statement,ResultSet的代码必须写成try (Connection conn dataSource.getConnection(); PreparedStatement ps conn.prepareStatement(sql); ResultSet rs ps.executeQuery()) { // business logic } catch (SQLException e) { // handle }这是 JDK 7 引入的语法糖能保证无论正常执行还是抛异常资源都会被自动关闭。统一 DAO 层封装在 BaseDAO 中提供executeQuery(String sql, Object... args)方法内部完成getConnection-prepareStatement-setParameters-executeQuery-closeAll的全流程。业务代码只需关心 SQL 和参数彻底屏蔽资源管理细节。这是我团队的强制规范上线三年零连接泄漏事故。6. 个人经验笔记不是终点而是你技术影响力的放大器写 system-design-notes 到今天已经是我工作流程中不可分割的一部分。它早已超越了“备忘录”的范畴成了我技术影响力的核心载体。我分享几条最实在的体会首先它倒逼你成为“问题终结者”而非“方案搬运工”。当你习惯性地在每条 notes 里写清“场景-问题-方案-验证”你就再也无法忍受那种“这个需求我们用微服务吧”、“这个性能差加个缓存吧”的模糊表达。你会本能地追问“哪个场景什么问题数据指标是多少”。这种思维惯性会让你在任何技术讨论中都成为那个能一针见血指出核心矛盾的人。其次它构建了你独一无二的“技术信用资产”。在团队里当别人遇到一个棘手问题第一反应是翻你的 notes而不是去 Stack Overflow 或问 ChatGPT。因为你的 notes 里有他们正在经历的、一模一样的场景有你踩过的坑有你验证过的数据。这种基于真实战功建立的信任是任何头衔和证书都无法替代的。我现在的职级晋升材料里“主导编写并维护团队系统设计知识库system-design-notes覆盖 12 个核心业务域被引用超 2000 次平均缩短方案设计周期 40%”是 HR 和技术委员会都高度认可的关键项。最后它让你的技术输出具备了“可传承性”。很多资深工程师离开公司后他脑子里的经验就跟着走了。而我的 notes是一份活的、可搜索的、可执行的文档。新同学入职他的第一个任务不是看代码而是阅读notes/README.md里面清晰地列出了“入职第一周必读的 5 条 notes”比如notes/data-persistence/sharding-strategy-for-user-center.md。这比任何口头传授都高效、准确、无歧义。所以别再把“system-design-notes