五年后，我重新画了一遍自己的技术地图

一、触发这次盘点的契机

2021 年春天，我参加了一次内部的技术分享，主题是 Redis 集群高可用。

讲的人是外面请进来的，讲了一个小时，主从复制、哨兵、Cluster 模式讲得很清晰。我坐在下面，大部分内容都听懂了，但有几个问题让我不舒服：

他问了一句：Redis Cluster 的数据分片是怎么做的，哈希槽有多少个，怎么分配的？

我愣了两秒。Redis 我用了两年多了，缓存、分布式锁、消息队列，每天在用。但哈希槽这件事，我说不清楚——我只知道它在做分片，但分片的细节我从没认真看过。

会后我回到工位，查了一下，发现答案其实不难，16384 个槽，按 CRC16 对节点数取模分配。五分钟就搞定了。

但让我难受的不是这个知识点，而是这件事暴露的一个模式：我用了两年的东西，有大量的”我以为我懂其实没深入过”的盲区。

那天晚上我在本子上写了一行字：到底哪些东西我是真的懂，哪些只是会用？

二、我的技术地图现状

诚实地分了两列：

真正懂原理（能解释，能排障，能在不同场景下设计）

• MySQL：索引结构（B+ 树）、事务隔离级别、MVCC 原理、锁机制、主从复制基本原理——用了四年，出过问题，也排过障，这部分算真懂
• Spring 容器：Bean 生命周期、IOC/AOP 实现原理、循环依赖怎么解决——做过功能，看过源码片段
• HTTP & RESTful：基本协议、状态码语义、请求头的作用——每天用，完整理解

只是会用（能完成任务，但说不清楚为什么）

• Redis：会用，但集群细节、持久化策略的取舍、过期淘汰策略的底层逻辑——没深入过
• RabbitMQ：会配，会发消息消息，但消息可靠性保障（持久化 + confirm + 事务）的完整链路——说不完整
• K8s：会写 Deployment 和 Service，但 Pod 调度策略、资源配额的工作原理——摸过但没体系
• 网络基础：TCP 三次握手、四次挥手能背，但 TIME_WAIT、CLOSE_WAIT 出问题时怎么排——没遇到过
• JVM：堆结构和 GC 算法能说出来，但真正遇到 OOM 和 GC 停顿问题时怎么分析——经验不足

三、最大的短板在哪里

看完这个表，短板很明显：基础设施和底层原理。

我在应用层写了五年代码，业务逻辑、接口设计、数据库优化都还算有积累。但越往下——网络、操作系统、JVM 调优、分布式协议——我的理解越薄。

这不是说我懒。更准确的原因是：我工作的大多数时候，这些知识不是必须的。用 Spring Boot 能跑起来，MySQL 能查出数据，Redis 能缓存，就够了。

但”够用”和”真正懂”之间的差距，只有在你被问倒、排障排不出来、或者设计大一点的系统时，才会暴露出来。那次技术分享是一个比较温和的暴露方式。

四、接下来的方向判断

想了很久，最后决定：不补短板，先扩长板，但要在长板里补深度。

补短板的问题在于，我那时候的岗位和工作内容不需要 JVM 调优或者网络协议分析，强行补了用不上，学了也容易忘。

但我决定在自己已经”会用”的那些工具里，选两个认真补深度——Redis 和 RabbitMQ。不是为了面试，而是因为我每天在用它们做设计决策，但我不确定那些决策是不是对的。

结果是值得的。把 Redis 的持久化策略和集群方案认真看了一遍之后，我后来在一次架构讨论里，能说清楚”为什么这个场景不适合用 Redis 做主存储”——而不是只能说”好像风险比较高”。

知道为什么，比知道怎么用，要值钱得多。