理解一个产品运行在多台机器后出现的新问题。
订单与支付、库存与抢购、多租户 SaaS、内容与媒体
分布式系统由多个通过网络协作的进程、节点或服务共同完成任务。
规模、可用性和团队独立性会推动系统分布到多台机器，同时引入延迟、失败和一致性问题。
位于架构与基础设施交界处，影响服务通信、数据和稳定性。
扩容、复制、CAP、分布式锁、分布式事务、超时、重试、熔断和降级。
大型 SaaS、支付、协作编辑和微服务平台都属于分布式系统。
当一个产品由多个网络节点共同完成任务，它就进入分布式世界。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
订单请求经过网关、订单服务、库存服务、支付服务、数据库和消息系统。
每个 Node 都可能独立变慢或失败，整体仍需给用户明确结果。
Distributed System 通过网络协作，并针对 Partial Failure 设计超时、重试和补偿。
页面需要“处理中、结果未知、稍后查询”等状态，避免把网络故障直接等同于业务失败。
多个前端服务器、后端实例、缓存节点、数据库副本和消息消费者可以共同支撑一个产品。用户看到一个系统，内部可能跨越很多机器和区域。
网络连接存在延迟、丢包和中断，远程调用比本地函数更不可靠。设计与工程都要接受“部分成功”和“暂时未知”。
加载、重试、同步中和局部失败状态，很多都来自分布式不确定性。
提升单机能力叫纵向扩容，增加实例数量叫水平扩容。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
开票瞬间并发从几百上升到几十万。
Scale Up 有硬件上限和单点风险，带状态的应用也难以平均分配请求。
通过 Scale Out 增加多个 Stateless 应用实例，把会话和共享状态放到外部存储。
设计排队、等待时间、库存确认和限流页面，降低用户重复刷新。
Scale Up 通过更多 CPU、内存和更快磁盘增强一台机器，实施简单但存在上限。Scale Out 增加机器或实例，需要负载均衡和数据协调。
无状态应用更容易水平扩容，因为任何实例都能处理请求。会话和文件需要放到共享系统或进行粘性路由。
用户量增长时，页面表现可能不变，背后实例数量和流量治理已经发生变化。
数据系统通过副本和分片提高可用性与容量。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
主数据库突然宕机，系统保存了大量项目和合同。
单份数据会形成单点故障，单台机器容量也可能达到上限。
Replication 保存副本并支持 Failover；数据量继续增长时可按租户或范围 Sharding。
故障切换期间可能短暂只读或延迟，页面要给出维护和重试提示。
Replication 保存多个数据副本，一个节点故障时可以切换。Sharding 把不同数据分散到多个节点，提高容量和并行处理能力。
复制会带来同步延迟，分片会让跨分片查询和事务更复杂。备份用于灾难恢复，不能完全替代实时副本。
跨地区产品可能出现刚修改后另一个端暂时未更新，这通常与复制延迟有关。
网络分区发生时，系统需要在强一致与持续可用之间做权衡。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
银行转账必须立即看到准确余额；点赞数晚几秒同步通常可以接受。
网络分区时，系统无法同时保证所有节点立即一致和始终可用。
余额优先 Strong Consistency；点赞可接受 Eventual Consistency。CAP 帮助理解这种选择。
关键金额要显示确认结果，弱一致数据可显示近似值或稍后刷新。
Consistency 要求所有节点看到一致数据，Availability 要求每个请求都得到响应，Partition Tolerance 要求网络分裂时系统仍能工作。分布式系统通常必须面对网络分区。
实际设计会按业务选择：余额和库存更强调正确性，点赞数和推荐可以接受短暂延迟。CAP 是理解方向，不是简单给数据库贴标签。
产品文案和交互要反映业务容忍度：余额需要明确确认，点赞可以先乐观更新。
多节点并发操作同一资源时需要协调。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
两名用户几乎同时确认同一会议室和时间。
多个服务或实例同时检查“可用”后都写入，会产生重复预订。
Distributed Lock 或数据库唯一约束保护关键资源，确保只有一个请求成功。
提交后显示确认中，失败时明确“刚刚已被他人预订”并推荐其他时段。
订单创建成功、库存已锁定，支付服务随后失败。
跨服务无法使用一个本地数据库事务覆盖全部步骤。
Saga 把流程拆成多个本地事务，并为已完成步骤定义 Compensation，例如释放库存。
设计订单取消中、库存释放中和人工处理状态。
分布式锁可以避免多个实例同时执行同一任务，例如同一订单重复结算。锁需要超时、所有权和故障恢复，错误实现可能导致死锁或重复执行。
跨服务事务难以使用单个数据库事务覆盖。Saga、事件和补偿操作常用于让多个步骤最终达到可接受状态。
长流程要设计部分完成、撤销、人工介入和可追踪步骤。
远程调用必须设定失败边界，避免故障扩散。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
首页依赖推荐服务，服务响应变慢并持续报错。
无限等待和盲目 Retry 会堆积请求，拖垮整个首页。
设置 Timeout；仅对安全请求重试；连续失败触发 Circuit Breaker；使用热门内容作为 Fallback。
推荐区域可以降级为固定内容，并明确哪些功能暂时不可用。
Timeout 限制等待时间，Retry 处理短暂故障，指数退避避免大量请求同时重试。Circuit Breaker 在下游持续失败时暂时停止调用。
Fallback 或降级可以返回缓存、默认值或关闭非核心功能。重试只适合幂等或可安全重复的操作。
系统降级时应保留核心任务，清楚提示哪些数据可能延迟或功能暂不可用。
请求跨越多个服务后，需要统一日志、指标和追踪。
先看用户动作和业务风险，再理解技术为什么出现，以及它会怎样改变页面、状态和流程。
用户只看到支付处理中，后端请求经过网关、订单、支付和数据库。
单个服务日志无法还原完整调用链。
每次请求携带 Correlation ID，Distributed Trace 串起各 Node 的耗时、错误和依赖。
错误页或客服工具可展示可复制的请求编号，帮助快速定位。
一个错误可能发生在 Gateway、业务服务、缓存、数据库或第三方接口。Trace ID 将各节点日志串成完整调用链。
指标观察延迟、错误率、吞吐和资源，分布式追踪观察单次请求路径，日志提供详细事件。没有这些能力，很难定位间歇性故障。
用户反馈“偶尔失败”时，工程需要时间、账号、操作和请求标识才能定位。
为“支付成功但库存扣减失败”设计一条补偿流程，并写出用户最终可能看到的三种状态。