后记

全书讨论了三个软件、八个主题，贯穿它们的是同一种视角。

设计决策面对什么约束、代价由谁承担，是比较方案时的两个基本问题。关注 Redis、MySQL、Kafka 各自放弃了什么，比关注它们各自做到了什么更有信息量。

全书反复出现几条线索，我在第 10 章把它们收成了五条规律。如果只能留一条，我留第一条：先弄清正本在哪里，其余取舍才有参照。

这本书能帮你养成这样的习惯，就够了。

这本书是怎么来的

刚工作那几年，我用这三个软件，关心的是命令表、索引怎么建、分区怎么配，能用好就够了。开始负责系统设计后，我的关注点变了：选型会上没人替我回答“为什么是这个”，出了故障也没人替我复盘“当时怎么想的”。被这类问题问住过几次之后，我换了一种看法：不再先问怎么用，先问它面对什么约束、做了什么取舍。

换了看法之后，这三个软件在我眼里变了样子。还是那些命令、那些参数，但背后多出一套讲得通的逻辑，而且这套逻辑在不同系统之间是通的。

下一步做什么

这本书的价值在于读完之后的动手。可以从自己维护的系统入手，先找出它的正本：是数据库、是日志，还是消息队列？然后问自己：如果这个正本丢了或坏了，哪些东西能重建、哪些东西就永久丢了？

接下来，可以在隔离的测试环境里，挑一个天天在用但从来没动过的参数，对比调整前后的行为。“可靠性保证有成本”这句话读十遍，不如在自己的终端里实际观察一次。

在下一次技术评审时，试着先说约束再说方案。把“我们选 Kafka 因为它快”换成“我们的峰值写入是 XX MB/s、消费者可以接受 YY 秒延迟、数据最多允许丢失 ZZ 条。需要验证 Kafka 的写入吞吐、消费延迟，以及持久化和副本确认配置能否满足这些要求”。方案质量会在这些细节里体现出来。

书里的规律灵不灵，希望你在自己的系统里去印证。

致谢

感谢 Redis、MySQL、Kafka 三个开源社区，本书所有的机制探讨都建立在它们的源码、文档与改进提案之上；感谢这些软件的作者与贡献者，把设计思考留在代码、论文与 KIP 里，帮我们减少重复探索。

本书的初稿与文字打磨借助了生成式 AI 工具。书中的假设场景用于解释机制与取舍，所有技术判断、取舍与案例均由作者独立负责；多轮交叉核验帮我校准了不少技术细节，残留的错漏仍由我负责。

也感谢每一位翻开这本书的读者。

关于作者

作者是软件架构师，做过 IoT、电商订单和 SaaS 系统，从一线开发做到首席架构师。这本书里的判断来自这些年的踩坑、复盘和选型评审；书中的应用场景是为阐释机制与取舍而设计的假设场景。

版权与勘误

商标声明：Redis 是 Redis Ltd. 的商标；MySQL 是 Oracle Corporation 及其关联公司的商标或注册商标；Apache Kafka、Kafka 是 Apache Software Foundation 的商标。本书对上述名称的使用仅作技术讨论，不代表各商标权属方对本书内容的认可。

免责声明：本书所含信息仅供学习与参考。作者不对因采纳本书中的任何技术建议、配置参数或架构方案而导致的任何直接或间接损失承担责任。书中提及的第三方软件与服务的性能、安全性与可用性以其官方文档为准。

本书勘误与版本更新见 https://github.com/jgsliu7/architecture-tradeoffs，欢迎读者反馈；技术细节随版本演进，采纳前请以 Redis、MySQL、Kafka 官方文档为准。