flowchart LR
N0["01 消息与重复"]
N1["02 可靠事件"]
N2["03 幂等消费"]
N3["04 一致性取舍"]
N4["05 跨服务收尾"]
N5["06 超时与保护"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
分布式与可靠性
从请求、数据与业务边界学到后端架构、可靠性和部署实践
0 子目录3 文档
CHAPTER OVERVIEW · 章节概览
先承认消息可能重复、依赖可能失败，再设计可靠事件、跨服务收尾和过载保护，不把重试当成万能解法。
本章学习路线
箭头表示建议的学习顺序；先理解问题，再逐步进入实现与实践。
按顺序学习
3消息队列、Outbox 与幂等消费：接受重复，避免丢失意图订单已经保存，但发通知时网络断了；或者通知发成功了，程序却在保存“已发送”之前崩溃。问题的根源是数据库和外部系统有各自的提交点。单靠调整两行代码的顺序，很难抹掉中间空档。一致性、CAP 与 Saga：跨服务流程怎样收尾订单服务说支付成功，库存服务却还在处理预留。用户应该看到“完成”“处理中”还是“失败”？分布式一致性讨论最终要回到这些具体可观察的行为，而不是只给数据库贴 CP 或 AP 标签。超时、重试、限流与熔断：依赖变慢时别把自己拖垮一个慢支付接口可能占住所有请求线程和连接，让原本不依赖支付的查询也失败。可靠性设计不是保证外部永远正常，而是限制坏依赖的影响，并让调用结果仍然可解释。