第一章：分布式系统概述

大家好，我是你们这门课的老朋友。今天咱们聊聊分布式系统的那些事儿。

说实话，我入行那会儿，分布式还是个挺高大上的词儿。现在呢？你随便打开一个App，背后都是一堆机器在干活。说白了，分布式系统就是一群计算机，通过网络协作，对外表现得像一台超级计算机。

1.1 分布式系统的定义

什么叫分布式系统？我个人的理解是：一群独立的计算机，通过网络连接，协同完成共同的任务。

嗯，这里要注意几个关键点：

• 独立性：每台机器都有自己的内存和CPU，不是共享的
• 网络连接：它们靠网络通信，不是靠共享总线
• 协同工作：对外看起来像一台机器

我记得刚带团队那会儿，有个新人问我：“老师，那多台服务器跑同一个程序算分布式吗？”我说：“你想想看，如果它们之间不通信、不协作，那叫多副本，不叫分布式。”

1.2 发展历程：从单机到分布式

分布式系统不是一天建成的。我经历过几个阶段：

时代	特点	我踩过的坑
单机时代	一台机器搞定一切	流量一上来，机器直接冒烟
垂直拆分	按功能拆成不同模块	模块间调用越来越乱
水平扩展	加机器解决问题	数据一致性成了噩梦
微服务时代	每个服务独立部署	服务间通信、监控、治理...头大

我曾经在一个电商项目里，刚开始就一台服务器扛着。双十一那天，用户量暴增，服务器直接挂了。老板急得直跺脚。后来我们上了分布式，加了十几台机器，结果又遇到了数据不一致的问题——用户下单了，库存却显示还有货。嗯，这就是分布式系统要面对的核心挑战。

1.3 核心挑战：CAP理论

说到分布式系统的核心挑战，绕不开CAP理论。这个理论是Eric Brewer教授提出的，说白了就是：一致性、可用性、分区容错性，三者最多只能同时满足两个。

你可能会问：“为什么不能三者兼得？”我举个例子你就明白了。

假设你有两台服务器，分别在北京和上海。用户A在北京修改了数据，这时候北京和上海之间的网络断了。如果保证一致性，上海那边就不能响应请求，直到网络恢复——这就牺牲了可用性。如果保证可用性，上海那边继续响应，但数据可能是旧的——这就牺牲了一致性。

我个人习惯把CAP理论当作一个选择题：你的系统到底要什么？

• CP系统：牺牲可用性，保证一致性。比如银行转账系统，宁可暂时不可用，也不能账对不上
• AP系统：牺牲一致性，保证可用性。比如社交媒体的点赞数，差几个没关系，但不能点不了
• CA系统：牺牲分区容错性。但说实话，在分布式系统里，网络分区是常态，所以CA系统基本不存在

1.4 一致性模型

CAP理论里的一致性，其实是个很粗的概念。实际工程中，一致性有很多种模型。我给大家梳理一下：

一致性模型	描述	适用场景
强一致性	写入后，立刻能读到最新数据	银行、支付系统
最终一致性	写入后，过一段时间才能读到最新数据	DNS、缓存系统
因果一致性	有因果关系的操作，顺序必须一致	社交网络的时间线
读己之写一致性	自己写的数据，自己立刻能读到	用户个人设置

你想想看，为什么会有这么多模型？因为强一致性太贵了。每次写入都要等所有节点确认，延迟高得吓人。

我记得有一次做直播弹幕系统，用户发弹幕要求实时显示。如果用强一致性，弹幕发出去要等几百毫秒才能显示，用户体验极差。后来我们用了最终一致性——弹幕先显示在发送者自己的屏幕上，其他用户稍微晚一点看到。用户根本感觉不到差异，但系统性能提升了好几倍。

1.5 我的经验总结

说了这么多，我给大家总结几条实战经验：

1. 先想清楚业务要什么。别一上来就追求强一致性，很多时候最终一致性就够了
2. 网络是不可靠的。设计系统时，默认网络会断、消息会丢、节点会挂
3. 监控和可观测性很重要。分布式系统出问题时，你得像侦探一样找线索
4. 不要过度设计。我见过太多团队，业务还没跑起来，先搞了一套复杂的分布式方案。结果呢？系统复杂度上去了，稳定性反而下降了

好了，第一章就到这里。分布式系统的核心挑战，说白了就是：在不可靠的网络上，构建可靠的系统。听起来矛盾，但这就是我们工程师要解决的问题。

下一章，咱们聊聊分布式系统的通信机制。到时候我会分享一些我在消息队列上踩过的坑，保证让你少走弯路。