一、集群基础概念：什么是集群、集群的三种模式、集群与单机的区别
大家好，我是你们的老朋友。今天咱们聊聊集群最基础的东西。
说实话，很多人一上来就追着问“K8s怎么搭”、“Hadoop怎么配”，结果连集群的基本概念都没搞明白。我见过太多这样的案例了——项目上线前三天，才发现架构选型就选错了。嗯，咱们今天就把地基打牢。
1.1 什么是集群？
集群，说白了就是一堆服务器假装成一台服务器。
你想想看，单机再强，CPU、内存、硬盘总有上限。但如果你把几台、几十台甚至上千台机器连在一起，让它们协同工作，对外看起来就像一台超级计算机——这就是集群。
我个人习惯把集群比作“搬砖队”：
- 单机是一个大力士，能扛500斤。但万一他生病了，活就停了。
- 集群是一群普通工人，每人扛50斤。有人累了，别人顶上；活多了，加人就行。
集群的核心价值就两个：高可用和高扩展。高可用是说一台挂了，服务不中断；高扩展是说业务涨了，加机器就行，不用换硬件。
1.2 集群的三种模式
我在项目中遇到过不少团队，把三种模式混为一谈，结果架构设计得一塌糊涂。咱们一个一个说清楚。
1.2.1 主从模式（Master-Slave）
这是最常见的模式。一台主节点（Master）负责调度和写操作，若干从节点（Slave）负责读操作或备份。
特点：
- 主节点是“大脑”，从节点是“手脚”
- 写操作只能走主节点，读操作可以走从节点
- 主节点挂了，整个集群可能瘫痪（除非做自动切换）
典型场景：MySQL主从复制、Redis主从、Hadoop HDFS（NameNode是主，DataNode是从）
1.2.2 对等模式（Peer-to-Peer）
对等模式里，所有节点都是平等的。没有“领导”，大家各自干活，互相备份。
特点：
- 没有单点故障，任何一个节点挂了都不影响整体
- 数据在所有节点间同步或分片
- 扩展性好，加节点就行
典型场景：Cassandra、Elasticsearch、RabbitMQ镜像队列
1.2.3 混合模式（Hybrid）
混合模式就是把主从和对等结合起来。说白了，局部是对等，全局是主从，或者反过来。
举个例子：
- Kubernetes：Etcd集群是对等模式（Raft协议选主），但K8s整体是主从模式（Master节点管控Worker节点）
- MongoDB副本集：副本集内部是对等（选举主节点），但主从切换后还是主从模式
我个人习惯把混合模式叫做“取长补短”。主从模式管理简单，但对等模式高可用好。混合模式就是用对等解决主从的单点问题，用主从简化对等的一致性难题。
主从 = 一个领导，一群员工（简单但领导不能倒）
对等 = 一群合伙人（没领导，但协调麻烦）
混合 = 有董事会，有CEO，有员工（结构清晰，容错好）
1.3 集群与单机的区别
这个区别，我用一张表格说清楚：
| 对比维度 | 单机 | 集群 |
|---|---|---|
| 可用性 | 单点故障，宕机即停服 | 节点冗余，单节点故障不影响 |
| 扩展性 | 垂直扩展（换更强的硬件），有上限 | 水平扩展（加机器），理论上无限 |
| 性能 | 受限于单机硬件 | 可线性提升（但网络开销要考虑） |
| 管理复杂度 | 低，一台机器搞定 | 高，需要配置、监控、协调 |
| 数据一致性 | 强一致，本地操作 | 需要分布式协议（如Raft、Paxos） |
| 成本 | 单台高性能机器贵 | 多台普通机器，总成本可能更低 |
嗯，这里要注意：不是所有场景都适合上集群。我见过一个团队，就一个日活几百的小网站，硬是搭了5台机器的K8s集群。运维成本比业务开发还高，得不偿失。
1.4 知识体系结构图
下面这张图，帮你把本章的核心逻辑串起来：
1.5 避坑指南
最后，分享几个我亲身踩过的坑：
- 我曾经以为集群就是“多搞几台机器装一样的软件”。结果数据没同步，用户看到的信息都不一样。记住：集群不是简单的堆机器，数据同步和一致性才是核心。
- 我曾经在选型时盲目追求“对等模式”，觉得没有单点故障就是好。结果业务需要强一致性，对等模式根本满足不了，最后被迫重构。选模式之前，先想清楚你的业务是CP（一致性优先）还是AP（可用性优先）。
- 我曾经以为集群搭好就万事大吉。结果某天半夜磁盘满了，所有节点一起报警。集群的监控和告警比搭建更重要，别等出事了才想起来。