分布式¶

参考文档¶

分布式与微服务.md、消息队列.md、注册中心与服务发现.md、redis.md、缓存.md、缓存一致性.md、可靠性与容错.md、分布式事务.md

知识地图¶

• 概念：先理解这个模块为什么存在。
• 工具：再看它通过哪些工具落地。
• 场景：最后判断什么时候该用，什么时候不该用。

核心整理¶

分布式是为了解决规模和协作问题，但会引入网络、数据一致性和运维复杂度。缓存降低延迟，消息队列解耦和削峰，注册中心做服务发现，可靠性靠限流、熔断、降级、重试和可观测性。

我在整理这部分时的重点是把工具放回工程场景，而不是孤立记名词。一个工具出现，通常是为了解决某种复杂度：协作复杂度、上下文复杂度、运行环境复杂度、系统规模复杂度或信息获取复杂度。

学习笔记¶

1. 先读 Why，确认它解决的问题。
2. 再读 What，建立概念边界。
3. 再读 How，补命令、API、配置和实践。
4. 最后用一个小 demo 验证。

实践清单¶

• 用自己的话解释本模块核心概念。
• 找一个最小 demo 跑通。
• 记录一个踩坑点。
• 把相关命令或配置写成可复用片段。
• 回看飞书原文，补齐遗漏的术语。

飞书思考题¶

飞书原文未在本模块设置集中独立的思考题，因此本节只保留原文知识整理，不额外添加题目。

分布式不是免费的¶

单体系统的好处是简单。分布式的好处是可扩展、职责清晰、独立部署，但代价是网络失败、数据一致性和运维复杂度。

拆服务前应该问：

• 单体是否真的成为瓶颈？
• 数据是否必须强一致？
• 团队是否能维护服务治理？
• 出问题时能不能追踪调用链？

缓存¶

缓存提高性能，但引入一致性问题。常见问题：

• 穿透：查不存在的数据。
• 击穿：热点 key 失效瞬间打到数据库。
• 雪崩：大量 key 同时失效。
• 不一致：数据库更新后缓存仍旧。

常见策略：空值缓存、TTL 随机化、互斥锁、热点预热、更新数据库后删除缓存。

Redis¶

Redis 不只是缓存，也可做：

• 计数器。
• 排行榜。
• 分布式锁。
• Pub/Sub。
• Stream。
• session 存储。

分布式锁要有过期时间和唯一 token，释放锁时确认是自己的锁。

消息队列¶

消息队列用于异步、削峰、解耦、重试。

Kafka 更适合高吞吐日志流，RabbitMQ 路由和传统队列能力更强。

队列使用的核心难点：

• 消息是否会丢。
• 消息是否会重复。
• 消费是否幂等。
• 顺序如何保证。
• 积压如何处理。

注册中心¶

服务实例会变化，所以不能把 IP 写死。注册中心提供服务注册、发现和健康检查。etcd、Consul、Zookeeper 背后都涉及一致性协调。

可靠性¶

限流防止流量打爆系统；熔断防止依赖故障扩散；降级在部分功能不可用时保核心功能；重试要配合超时、退避和幂等。

分布式事务¶

跨服务事务很难。方案包括 2PC、TCC、Saga、事务消息和最终一致性。很多互联网业务会选择最终一致性加补偿，而不是追求全局强一致。

知识卡片¶

幂等¶

重复执行多次，结果和执行一次相同，称为幂等。消息队列和重试机制都强依赖幂等设计。

熔断¶

当下游持续失败，暂时停止请求它，避免故障扩散。

最终一致性¶

不是立刻一致，但系统最终会通过重试、补偿、消息等方式达到一致。