服务器集群常见架构解析
在日常运维中，系统一挂，老板就急。这时候你得知道背后的集群长什么样，才能快速定位问题。不同的架构决定了故障的表现形式和排查路径。
主从架构（Master-Slave）
这是最基础的一种结构。一个主节点负责写操作，多个从节点同步数据并处理读请求。比如你家的数据库，MySQL 常用这种模式。一旦查询变慢，先看看是不是主从延迟了。有时候从库没跟上，查出来的还是旧数据，用户以为系统出bug，其实只是同步卡住了。
排查时重点看同步状态。像 Redis 的 INFO replication 命令，一眼就能看出从节点是否掉线。
主备架构（Active-Standby）
两个节点，一个干活，一个待命。就像公司里两个值班工程师，一个在电脑前盯着，另一个在休息室睡觉。真出事了，才叫醒切换。常见于高可用场景，比如 PostgreSQL 配合 Keepalived 使用。
但问题也明显：备用机长期闲置，资源浪费。而且切换可能不顺利，网络抖一下，脑裂了，两台都觉得自己该上岗，结果数据冲突，谁也不认谁。
对等架构（Peer-to-Peer）
所有节点地位平等，数据互相复制。Cassandra 和 DynamoDB 就是典型例子。没有单点压力，扩容方便。但一致性是个头疼事。你往A节点写入一条记录，马上去B节点查，可能还看不到。这叫最终一致性。
用户投诉“我刚提交的订单去哪儿了”，往往就是这个原因。这时候不能光查日志，还得看数据同步的确认级别（consistency level）设置得对不对。
负载均衡+无状态服务
前端加个负载均衡器，比如 Nginx 或 HAProxy，后端一堆无状态应用服务器。用户请求打过来，随便转给哪个都行。这种结构好扩展，一台挂了没关系，流量自动切走。
但别忘了健康检查配置。曾经有次线上502，查了半天发现是负载均衡的检测路径写错了，一直标记后端为宕机，其实服务根本没问题。
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080;
check interval=3000 rise=2 fall=3 timeout=1000;
}微服务与服务网格
现在越来越多系统拆成微服务，每个功能独立部署。这时候集群不再是简单的一排机器，而是一张网。服务之间调用频繁，一个下游抖动，上游跟着超时，雪崩就这么来了。
这时候光看单台服务器负载没用，得用链路追踪工具，比如 Jaeger 或 SkyWalking，顺着调用链往下扒。见过一次故障，根源居然是某个服务缓存没设过期时间，内存慢慢吃光，最后OOM重启。
分片架构（Sharding）
数据量大了以后，单库扛不住，就得拆库拆表。比如用户ID尾号0-4去A库，5-9去B库。这种架构性能上去了，但故障定位更复杂。用户登录失败，得先算他分在哪一片，再去查对应实例。
有一次报警说某片写入延迟高，上去一看，那片正好赶上促销活动，流量突增，其他片却闲着。容量规划时没留余量，临时扩容又来不及，只能限流顶住。
每种架构都有它的脾气。了解清楚自己系统的骨架，故障来了才不会手忙脚乱。很多时候问题不在代码，而在结构本身的设计取舍。