一、分布式系统概述：从单机到集群的进化之路

大家好，我是老张。做分布式系统这块十几年了，今天咱们聊聊最基础的东西——分布式系统到底是什么。

说实话，我刚入行那会儿，对“分布式”这三个字特别敬畏。总觉得很高大上，离自己很远。直到有一次，我负责的一个电商后台在双十一直接挂了……嗯，从那以后，我才真正开始认真研究分布式。

1.1 什么是分布式系统？

先给个定义。分布式系统，说白了就是一群廉价的计算机，通过网络连在一起，对外表现得像一台超级计算机。

你想想看，一台机器的CPU再强，内存再大，总有天花板。但如果你把100台普通机器连起来，让它们协同工作，那能力就完全不一样了。

我个人习惯把分布式系统拆成三个关键词来理解：

• 分布性：机器在物理上是分散的，可能在不同机房，甚至不同城市
• 自治性：每台机器都有自己的CPU、内存、硬盘，能独立运行
• 协同性：通过网络通信，这些机器要像一个人一样工作

这里有个坑，我踩过。很多人以为分布式就是“把程序拆开部署到多台机器上”。不对。真正的分布式，要考虑网络延迟、部分故障、数据一致性……这些才是难点。

1.2 发展历程：从单机到云原生

分布式系统不是一天建成的。我把它分成四个阶段，你感受一下：

阶段	时间	特点	代表技术
单机时代	1990s	一台机器搞定所有	大型机、单体应用
集群时代	2000s	多台机器做负载均衡	LVS、Nginx、MySQL主从
分布式时代	2010s	数据分片、服务拆分	Hadoop、ZooKeeper、Kafka
云原生时代	2020s	容器化、弹性伸缩	Kubernetes、Service Mesh

我记得2012年做第一个分布式项目时，用的还是自己手写的RPC框架。那时候哪有现在这么多现成工具，连个服务注册发现都得自己撸。现在想想，真是硬核。

1.3 核心目标：可扩展性、可用性、一致性

做分布式系统，本质上就是在追求三个东西。我管它叫“分布式三驾马车”。

1.3.1 可扩展性（Scalability）

说白了就是：加机器，就能提升性能。

但这里有个陷阱。很多系统号称“可扩展”，实际上加机器后性能提升非常有限。为什么？因为存在瓶颈点。

• 垂直扩展：换更强的机器。简单，但有上限
• 水平扩展：加更多机器。理论上无限，但设计难度大

我在项目中遇到过：一个数据库，加了从库后读性能确实上去了，但写性能反而下降了。因为主从同步带来了额外开销。这就是典型的“扩展陷阱”。

1.3.2 可用性（Availability）

可用性就是系统能不间断提供服务的能力。

业界常用“几个9”来衡量：

可用性	年停机时间	典型场景
99%（2个9）	87.6小时	内部系统
99.9%（3个9）	8.76小时	一般商业系统
99.99%（4个9）	52.56分钟	金融、电商
99.999%（5个9）	5.26分钟	电信、核心交易

你想想看，要做到5个9，意味着一年只能宕机5分钟。这难度，啧啧。

1.3.3 一致性（Consistency）

一致性就是所有节点看到的数据是一样的。

但分布式系统里，一致性是有代价的。CAP理论告诉我们：一致性、可用性、分区容忍性，三者只能选其二。

实际项目中，我们通常这样权衡：

• 强一致性：写入后，所有读取都能看到最新数据。代价是性能下降
• 最终一致性：写入后，过一段时间所有节点才一致。性能好，但短暂不一致
• 因果一致性：有因果关系的操作保证顺序，无关的可以乱序

我个人习惯：核心交易用强一致性，非核心业务用最终一致性。比如用户下单，必须强一致；但用户头像更新，最终一致就够了。

1.4 典型应用场景

说了这么多理论，咱们看看实际中哪些地方用到了分布式系统。

1. 搜索引擎：Google、百度。数据量太大，单机根本存不下
2. 电商平台：淘宝、京东。高并发、高可用，双十一峰值每秒几十万笔订单
3. 社交网络：微信、微博。全球用户，实时消息推送
4. 金融系统：支付宝、银行核心。强一致性、高可靠性
5. 物联网：设备数据采集、处理。海量终端，实时性要求高

我参与过一个物联网项目，几十万个传感器，每秒上报数据。刚开始用单机处理，CPU直接100%。后来改成分布式流处理架构，用Kafka + Flink，才扛住。这就是典型的“不用分布式不行”的场景。

1.5 知识体系总览

下面这张图，是我自己画的分布式系统核心知识结构。你看一眼，心里就有谱了。

好了，第一章就到这里。分布式系统是个大话题，但万变不离其宗。记住那三个核心目标，后面的内容都是围绕它们展开的。