边思考边实现：RobustMQ 写作手记
这段时间写了不少关于 RobustMQ 存储层设计的文章，有朋友问我：代码写了多少？我有些尴尬地回答：文章倒是写了好几篇，代码还在路上。
这看起来有点本末倒置。通常的做法应该是先把系统做出来，验证可行，再写文章分享。但我选择了相反的路径：先把思考写出来，和大家讨论，然后再去实现。为什么会这样？
RobustMQ 是一个探索过程
首先要说明的是，RobustMQ 不是一个商业化项目，至少现在不是。它没有 KPI，没有融资压力，没有必须在某个时间节点交付的硬性要求。这让我可以用一种相对从容的方式去探索：下一代消息平台应该是怎么设计的？
这个探索本身就是 RobustMQ 最重要的部分。我在思考：消息队列的痛点在哪里？现有方案（Kafka、Pulsar、RocketMQ）各自的优劣是什么？有没有可能通过合理的技术组合，在简单性和灵活性之间找到更好的平衡点？存算分离真的是必然趋势吗？ISR 和 Quorum 各自的适用场景是什么？
这些思考本身就有价值，不一定非要等实现出来才能分享。而且坦白说，很多想法在写成文字之前，只是脑子里模糊的念头。写的过程强迫我把想法梳理清楚，发现逻辑上的漏洞，思考得更深入。
写作即思考
写文章对我来说不只是分享，更是思考的工具。
当我要写"为什么选择 ISR 而不是 Quorum"这个章节时，我必须把两者的优劣分析透彻。脑子里觉得 ISR 更好，但为什么更好？Quorum 的问题具体在哪里？写的过程中我发现：Quorum 的核心问题是后台修复的复杂度，而这个复杂度在设计阶段容易被低估。
当我要写"Active/Sealed Segment 分离"的价值时，我得算清楚：Leader 数量从 10 万降到 1000，具体节省了什么成本？Sealed Segment 任意副本可读，对负载均衡的影响有多大？写的过程中我意识到：这个设计不只是降低管理成本，还让分层存储的实现变简单了，因为 Sealed Segment 不可变。
这些思考的深化，很多是在写文章的过程中发生的。如果只是在脑子里想，很容易停留在表面。写出来，逻辑链条就清晰了，问题也暴露了。
展示思考过程的价值
我希望通过这些文章，展示 RobustMQ 的思考过程，而不只是最终结果。
这些文章不代表最终形态，架构也可能会一直改变。比如最开始我倾向于 Quorum，后来想明白了后台修复的复杂度，改成了 ISR。比如一开始没有 Active/Sealed 的概念，后来发现 Leader 数量是个问题，加入了这个设计。这些变化都是思考的结果。
我觉得展示这个过程本身就有价值。让大家看到一个消息队列是怎么从想法变成设计的，遇到了哪些问题，如何权衡和选择。这比只展示一个光鲜的最终结果更真实，也可能对其他在做类似探索的人有启发。
而且这些文章也是在邀请讨论。我的想法可能有偏差，设计可能有问题。写出来，如果有人指出"这里考虑得不对"，或者"那个场景你没想到"，这对我是有价值的反馈。闭门造车很容易陷入思维盲区，把想法暴露出来，接受质疑和讨论，可能让设计变得更好。
边写边改的节奏
RobustMQ 的开发节奏是：一边写代码，一边思考，一边总结文章，一边优化。
可能这周在实现 I/O Pool，发现批量处理比预期的效果更好，那就写篇文章总结。下周在设计索引，纠结同步构建还是异步构建，把两个方案的优劣写出来，写的过程中想清楚了，选择同步构建。再下周在对比 ISR 和 Quorum，写着写着发现 Quorum 的坑比想象的多，决定用 ISR。
代码和文章是并行的，互相促进的。代码实现过程中遇到的问题，促使我重新思考设计。写文章梳理思路的过程，又指导了代码的实现。这个循环让整个项目在持续演进。
不是炫耀，是记录
这些文章不是在炫耀"我们设计得多牛逼"，更多是在记录"我们现在是这么想的"。
可能过几个月回头看，会觉得有些想法很幼稚，有些设计有明显问题。但这就是探索的过程，不是每一步都是对的，重要的是在不断试错中前进。把这个过程记录下来，将来回顾时，至少知道自己走过的路，犯过的错，学到的教训。
而且对于开源项目来说，透明度很重要。让大家知道我们在想什么，在做什么，为什么这么选择。即使最后项目没做成，至少这些思考的记录对后来者也可能有参考价值。
探索的意义
RobustMQ 是一个探索的过程，探索下一代消息平台应该是怎么设计的。
这个探索可能成功，也可能失败。可能最后发现某些设计行不通，需要推倒重来。可能发现实现难度超出预期，不得不妥协。也可能发现市场根本不需要这样的系统，整个项目都是一厢情愿。
但探索本身就有意义。即使最后没有做成一个成功的产品，至少我们认真思考过这些问题，验证过这些想法，这个过程让我们学到了东西。而这些思考的记录，可能对其他在做类似探索的人有启发。
邀请同行
我写这些文章，也是在邀请大家一起探索。
如果你也在思考消息队列的设计，如果你对存算分离、一致性协议、分层存储这些话题感兴趣，如果你有不同的想法或者发现了我们设计中的问题，欢迎交流讨论。这些文章不是结论，是起点。我们希望和大家一起探索这个思考的过程。
基础软件确实不性感，确实没有 AI 那么有想象空间。但它很重要，它有技术深度，它值得被认真对待。我选择做这件事，不是因为它性感，而是因为我觉得它有意义。