1. 分布式系统概述：从单机到集群的进化之路
大家好，我是你们的老朋友。今天咱们聊聊分布式系统——这个听起来高大上、实际上每天都在折磨我们的东西。
说实话，我刚开始做后端开发那会儿，对分布式系统是又敬又怕。敬的是它解决了单机搞不定的问题，怕的是它带来的麻烦比单机多十倍。后来踩了无数坑，才慢慢摸到门道。
好，咱们正式开始。
1.1 什么是分布式系统？
分布式系统，说白了就是一群计算机凑在一起，对外假装是一台机器。
你想想看，用户访问你的网站，他根本不在乎背后是1台服务器还是1000台。他只关心页面能不能打开、数据对不对。这就是分布式系统的核心目标——让一群独立的计算机，对外表现得像一台计算机。
我个人习惯用这个定义：分布式系统是多个自治计算节点通过网络通信协作，共同完成任务的系统。注意三个关键词：自治、网络、协作。
关键特征：
- 自治性：每个节点都有自己的内存和CPU，独立运行
- 网络通信：节点之间靠消息传递，不是共享内存
- 协作性：单个节点完不成任务，必须抱团
- 透明性：用户感知不到背后的复杂性
1.2 发展历程：我经历过的那些阶段
分布式系统不是一天建成的。我入行那会儿，正好赶上从单体到分布式的转型期，感触特别深。
| 阶段 | 时间 | 特点 | 我的经历 |
|---|---|---|---|
| 单体架构 | 2000年前 | 一台机器搞定一切 | 我第一个项目就是单体，部署简单，但一挂全挂 |
| 垂直拆分 | 2000-2005 | 按功能拆成不同模块，部署在不同机器 | 记得当时拆了个电商系统，订单和用户分开部署，爽了半年 |
| SOA架构 | 2005-2010 | 面向服务，ESB总线 | ESB太重了，我参与的项目最后都放弃了 |
| 微服务 | 2010至今 | 轻量级、独立部署、去中心化 | 现在基本都在用微服务，但服务多了也头疼 |
| 云原生 | 2015至今 | 容器化、编排、不可变基础设施 | K8s成了标配，我最近的项目全在K8s上跑 |
为什么会从单体走向分布式？说白了，就是单机扛不住了。用户量上来了，数据量上来了，单机的CPU、内存、磁盘都有上限。你想想看，淘宝双11的流量，一台机器能扛得住吗？
1.3 核心挑战：CAP理论
说到分布式系统，CAP理论是绕不开的。我面试别人的时候，第一题经常问这个。
CAP理论说：一个分布式系统，最多只能同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）中的两个。
CAP详解：
- C - 一致性：所有节点在同一时刻看到的数据是一样的。你写入了A节点，读B节点也能读到最新数据
- A - 可用性：每个请求都能得到响应，不会一直等着。注意，响应可以是失败，但不能不响应
- P - 分区容错性：网络出问题了，节点之间联系不上，系统还能继续工作
这里有个常见的误解——很多人以为CAP是让你三选二。其实不是的。在分布式系统里，网络分区是必然发生的，所以P是必选的。你只能在C和A之间做取舍。
避坑指南：
我曾经在一个项目中，天真地以为可以同时保证强一致性和高可用。结果网络抖动了一下，整个系统卡死了半小时。后来才明白，在分布式世界里，你必须接受某些不完美。
实际应用中，我们通常这样选：
- CP系统：牺牲可用性，保证一致性。比如ZooKeeper、Etcd。网络分区时，少数节点会停止服务
- AP系统：牺牲一致性，保证可用性。比如Eureka、Cassandra。网络分区时，数据可能不一致，但系统还能用
- CA系统：理论上不存在，因为网络分区一定会发生
1.4 一致性模型：到底多一致才算够？
CAP理论里的一致性，其实是个很粗的概念。实际开发中，我们需要更细粒度的一致性模型。
我习惯把一致性模型分成三类：
| 模型 | 描述 | 典型场景 | 我的建议 |
|---|---|---|---|
| 强一致性 | 写入后立即能读到最新数据 | 银行转账、支付系统 | 能不用就不用，性能代价太大 |
| 最终一致性 | 写入后过一段时间才能读到最新数据 | DNS、社交动态 | 大部分场景够用，注意窗口期 |
| 因果一致性 | 有因果关系的操作，顺序必须一致 | 评论回复、聊天记录 | 折中方案，我比较常用 |
实战技巧：
我个人习惯这样选：如果业务能接受短暂的不一致，就用最终一致性。如果必须严格一致，那就用分布式事务，但要做好性能下降的准备。记住，没有银弹。
1.5 典型应用场景
说了这么多理论，咱们看看实际中哪些地方用到了分布式系统。
场景一：搜索引擎
Google、百度这种，数据量是PB级的。单机根本存不下，更别说建索引了。它们把数据分片到成千上万台机器上，查询时并行搜索，再合并结果。
场景二：电商系统
双11的时候，每秒几十万笔订单。单机数据库早就挂了。所以要用分布式缓存（Redis集群）、分布式数据库（TiDB）、消息队列（Kafka）来扛流量。
场景三：社交网络
微信、微博这种，用户遍布全球。你发一条朋友圈，要推送给所有好友。这背后是分布式消息推送系统，还要考虑跨地域的延迟问题。
场景四：物联网
智能家居、工业传感器，成千上万个设备同时上报数据。需要一个分布式数据采集和处理系统，实时分析数据。
我的经验：
做分布式系统，千万别一上来就想着搞多复杂。我见过太多人，明明几百个用户，非要上微服务、上K8s，结果运维成本比业务开发还高。先单机，再拆分，最后分布式，这个顺序别搞反了。
1.6 本章小结
好，咱们回顾一下今天的内容：
- 分布式系统就是一群计算机假装成一台机器
- 从单体到云原生，走了20多年，每一步都是被逼的
- CAP理论告诉我们，网络分区时必须在一致性和可用性之间做选择
- 一致性模型有很多种，选合适的，别追求完美
- 搜索引擎、电商、社交、物联网，到处都是分布式系统的影子
下一章，咱们聊聊分布式系统的通信机制——RPC和消息队列。这些东西我踩过的坑，够写一本书了。
记住一句话：分布式系统不是目的，解决问题才是。