EP 6.3：主从架构

Source: Dev.to

概述

在系统设计中，主从（或 Leader‑Follower）架构是一种用于实现可扩展性和高可用性的基础模式，尤其在数据库系统中。它模拟了这样一种通信：一个设备或进程（Master）对一个或多个其他设备或进程（Slaves）拥有单向控制权。

MASTER → SLAVE

在数据驱动的应用中，这种架构将写操作与读操作分离。

核心概念

• 真相来源 – Master 负责所有写操作（INSERT、UPDATE、DELETE）。
• 协调 – Master 将变更记录在日志中。
• 传播 – Master 将变更推送到 Slaves，使其保持同步。
• 只读 – Slaves 通常仅限于读操作。
• 数据复制 – Slaves 持续拉取或接收来自 Master 的更新。
• 可扩展性 – 可以根据需要添加任意数量的 Slaves 来处理读流量。

复制类型

同步复制

• Master 在确认 所有 Slaves 已写入数据后，才向客户端确认写入成功。
• 优点： 零数据丢失。
• 缺点： 延迟更高；系统受最慢的 Slave 限制。

异步复制

• Master 写入数据后，立即向客户端确认，然后在后台将数据发送给 Slaves。

半同步复制

• Master 在 至少一个 Slave 确认更新后，才完成写入。

为什么使用主从架构？

读可扩展性

• 适用于读密集型应用（例如社交媒体平台），写少读多的场景。多个 Slaves 可以分担读取负载。

高可用性

• 当某个 Slave 失效时，系统仍可继续运行。若 Master 失效，可将某个 Slave 提升为新的 Master。

分析隔离

• 重度分析查询可以在 Slave 上执行，而不会影响 Master 对实时事务的性能。

备份

• 可以暂停某个 Slave 进行完整数据库备份，而不影响 Master 的在线工作负载。

最终一致性

• 由于复制延迟，从 Slave 读取的数据可能在 Master 写入后短时间内是陈旧的。

写入瓶颈

• 只有一个 Master 负责写入，这在写密集型工作负载（如高频交易）下可能成为瓶颈。

故障转移复杂性

• 在崩溃时将 Slave 提升为 Master 需要精细的协调（通常由 Sentinel、Zookeeper 等工具处理），以避免数据损坏或脑裂（split‑brain）情形。

常见使用场景

• 电子商务网站： 写操作（如用户资料更新）发送到 Master；商品浏览的读操作则从多个 Slaves 获取。
• Redis： 主缓存节点充当 Master；Slaves 提供高速读访问并确保数据持久性。
• Hadoop 分布式文件系统（HDFS）： NameNode 为 Master（元数据），DataNode 为 Slaves（实际数据块）。

结论

主从架构通过将写和读职责分离，实现了可扩展性、高可用性以及工作负载的隔离。了解同步、异步和半同步复制的权衡后，你可以为应用的“一致性”和“性能”需求选择合适的配置。