主从架构（Coordinator-Worker Architecture）综述

声明：为力求内容的准确性，为大家提供更优质的技术内容。如果您发现文章内容中任何不准确或遗漏的部分。非常希望您能评论指正，我将尽快修正疏漏。

当提到主从架构或者主从模式的时候，首先映入你脑海的是什么？

可能你会想到 MySQL 为应对大规模、高性能应用场景而提供的主从复制功能，或者你会想到同样场景下的 Redis 主从复制功能。亦或是其他系统主从相关功能。这里以 MySQL 主从复制功能为例，其解决的基本问题是让一台服务器（或者一个运行实例）的数据与其他服务器（实例）保持同步。如果你所想到的主从架构（模式）与此类似，那么我们需要先对这一术语的理解达成一致性共识。

定义

上面提及的主从模式，担任主节点和担任从节点的服务器或实例，在系统中所负责并承担的工作近乎相同，且几乎处于同一层级。通常可认为从节点所具备的能力为主节点的子集，两者差异并不明显。而且大都采用同一个制品（可运行软件包或镜像）在运行时区分角色。并且在主节点故障时期，均可通过人工或自动化机制升级从节点，实现故障的恢复。

问题在上面描述的内容于字面意义上，并不能很好的契合主从架构（模式）。因为从字面意义上主节点（master）与从节点（slave）之间，并不能同等看待，主节点（master）更多意味着拥有对从节点（slave）的操纵或指挥以及监控权。这也就不难理解为何会引发海外平权运动下，诸多系统软件对相关术语的修正。抛开这些技术无关因素，我们也会发现经过修正后的术语其实更好的体现了系统的能力。依然以 MySQL 为例，在官方文档中已经采用 source（源） 和 replica（副本） 替换了 master（主库） 和 slave（从库）。

替换后的描述如 source/replica 或 primary/secondary ，对应中文下的主备架构/模式。在语意层面更能清晰的表述这种系统中两个角色的功能与差异。如果你认可上面的内容，为了方便我们讨论后续内容，这里我们将此类架构/模式统一定义为主备（primary/secondary）架构/模式。

接下来我要为本文所讨论的主从（coordinator/worker）架构/模式给出一个定义：

主从架构是一种分布式系统的计算模型，其中至少有一个节点充当主节点，其余节点充当从节点。主节点对从节点实施管控，从节点负责任务的计算与执行，并存储结果等。

应用

主从架构/模式基本上是分布式系统中最简单的架构与模式。在微服务架构流行的当下，主从模式也是 99% 以上应用系统开发中常用的架构模式。具体我们结合下图来详细说明。

如上面左侧图示，在多数微服务架构中，服务调用方通常充当着主节点的角色，服务提供方则充当着从节点，一个调用请求便是一个任务。当发起服务调用请求时，相当于通过 LoadBalancer 类组件在从节点集群中选择执行任务的节点。

在较早时期的企业信息化架构中，数据库不仅承担数据存储，同时通过存储过程承担着多数逻辑运算。虽然有硬件加持，但数据库需要承载的负载压力依然比较大。因为对硬件设施的依赖，使其扩展成本高昂。如右侧图示，在当今的系统架构中数据库将运算逻辑完全剥离，有应用服务承担运算，而数据库更多退化为数据存储设施，扮演着伪主节点的角色。而应用服务节点依然承担着从节点的身份，从数据库中获取数据（相当于任务），在节点内完成一系列计算处理，将加工后的数据（相当于任务执行结果）再次存入数据库中。

除此之外，Redis 的哨兵节点在特定场景下也扮演着主节点的角色，而 Redis 集群中的主/从节点则相当于哨兵节点的从节点。MapReduce、GFS 以及 HDFS 中，包括 Kubernetes 均采用了这种主从架构/模式，只不过在这些系统中有着更复杂的组件以及架构，来处理各种异常容错场景，从而满足更高的可用性要求，使其具备更短的故障恢复时间。

总结

上文中提到主从架构/模式基本上是分布式系统中最简单的架构与模式，是因为主节点的存在将分布式场景化解为调度问题。采用该架构模式，可以相对较容易的实现系统负载的提升。而系统负载能力的提升，意味着系统吞吐量的提升，以及系统容量的提升。

你好，我是 HAibiiin，一名探索独立开发的 Product Engineer，你可以关注【公众号：单核生悟】与我交流，一起探索技术之外的更多可能。

本文为架构与系统设计系列文章。系统设计能力对于许多从业人员来讲相对薄弱，一方面缺乏实际经验的锻炼，另一方面简中互联网缺乏同类型内容。当你背了很多八股，刷了许多算法，但是面对系统设计却无从下手。当你迈过了中高级工程师的门槛，却苦于简中互联网技术内容在深度与实用性上的匮乏，而迷失了成长方向时。希望我的系列文章能给你帮助。