分布式系统架构(一)——Master-Workers 架构

简介: 分布式系统架构(一)——Master-Workers 架构

分布式系统有很多经典的套路,也即设计模式。每个设计模式可以解决经典的一类问题,积累的多了,便可以稍加变化,进行取舍,设计出贴合需求的架构组织。但似乎大家在这方面经验分享的不太多,因此之后打算总结一些工作和学习的经验,既是备忘,也希望对大家有些助益。篇幅所限、能力所囿,难以面面俱到,又或疏于精确。不当之处,欢迎指正。

每篇将以概述背景、架构模块、总结延伸来分别解析,本篇是第一篇:Master-Workers 架构。

概述

Master-Workers 架构(粗译为主从架构)是分布式系统中常见的一种组织方式,如 GFS 中的 Master、ChunkServers;MapReduce 中的 Master、Workers。面对分布式系统中一堆分离的机器资源,主从架构是一种最自然、直白的组织方式——就像一群人,有个说了算 leader 进行组织、协调,才能最大化这群人的对外输出能力。

这也是计算机系统中常见的一种分而治之思想的体现。即将一个复杂的系统,拆解成几个相对高内聚、低耦合的子模块,定义清楚其功能边界交互接口,使得系统易于理解、维护和扩展。对于主从架构来说,主(Master) 通常会维护集群元信息、进而依靠这些元信息进行调度,从(Workers) 通常负责具体数据切片(存储系统)的读写或者作为子任务(计算系统)的执行单元。

架构模块

主从架构系统,通常由单个 Master ,多个 Worker 组成。插一句,这里英文翻译没有用 Slave 的原因是,我觉得 Worker 更中性一些。当然,单个 Master 会有性能瓶颈和可用性问题,通常也有多种解决方案,后面详说。但单个 Master 的好处是显而易见的:Master 作为一个控制节点,而不用处理由多副本带来的一致性问题,大大降低实现难度。

以我更熟悉一点的存储系统架构为例,其架构图通常长这样。

image.png

                            master-workers architecture

除了系统内部的 Master 和 Worker 外,还有使用系统的外部用户。我们通常称之为**客户端(Client),**Client 通过系统暴露的接口(如 RPC、HTTP)与系统进行交互。

Master

Master 通常会存储系统的元信息,什么是元信息呢?可以理解为集群组织信息在 Master 脑中的一个倒影,或者说视图(View):比如集群有多少 Worker、每个 Worker 有多少剩余容量、负载如何、哪些 Worker 存储了哪些数据等等。

那元信息是怎么收集的呢?主要分两种情况:

  1. 配置。可以理解为集群静态信息,比如系统初始有多少个 Worker、Worker 的物理拓扑、每个 Worker 的容量等等,Master 会在启动时加载这些配置信息。
  2. 汇报。主要是集群动态信息,Worker 在运行时,主动将自身状态汇报给 Master,比如 Worker 是否存活、Worker 负载信息、Worker 存了哪些数据等等。在系统运行中,Worker 会定时地通过心跳(Heartbeat) 等方式,持续给 Master 汇报。

有了这些元信息,Master 就可以对整个集群情况有个掌握,从而做出一系列的决策,试举几例:

  1. 调度(Schedule)。一个新的写数据请求来了,要分配给哪个 Worker 负责?通常会选择一个负载小的。
  2. 均衡(Balance)。随着 Worker 变动、数据增删,数据在不同机器中分布可能不再均匀,在某些机器形成读写热点、在另一些机器却存在资源浪费,从而影响系统整体性能。因此需要实时监测,适时迁移。
  3. 路由(Locate/Route)。一个读写请求来了,不知道去找哪个 Worker?Master 便会查询元信息,给出对应数据的 Worker 信息。

Master 的可用性

可以看出整个系统的可用性全系 Master 一身。业界也有很多解决办法,比如:

  1. 使用主备。即给 Master 做个分身,备 Master 所有元信息要时刻跟主 Master 保持一致,一旦主 Master 挂掉,分身立刻跟上。Hadoop 后来这么干过。
  2. 使用共识算法(consensus algorithm)。简单来说,就是由一堆 Master 机器来组成委员会,每个状态变更都要通过某种算法达成共识。Google 的 Spanner 就是这么干的。
  3. 无主。系统中不再有 Master,人人平等,然后通过某种策略,比如说一致性哈希(consistent hash),来分活干。Amazon 的 Dynamo 是这么干的。

每种策略都是比较大的主题,以后可以分别单开一篇,本文限于篇幅不再展开。

Workers

在存储系统中,Workers 会存储实际数据,并对外提供数据 IO 服务。

从单机视角来看,Worker 需要设计一个贴合业务需求的单机引擎,高效的存储数据。单机引擎设计也是一个很大的话题,这里简要提一嘴:

  1. 索引设计:比如 B+ 树、LSM-tree、哈希索引等等。
  2. 底层系统:是用裸盘还是文件系统。
  3. 存储介质:使用可持久化内存、固态硬盘还是机械硬盘。

从多机视角来看,机器的数量一上去,系统中单台机器出现故障的概率便大大提高。为了应对这种常态化的故障,需要:

  1. 运维的自动化。机器不可用后要自动剔除,修好后要便捷上线。
  2. 数据的冗余化。机器故障后数据不能丢,因此每份数据要多副本存放、使用 EC 算法做冗余。

小结

Master-Workers 架构是分布式系统中最常用的一种组织方式。该架构类似于人类社群的组织方式,将系统的职责进行拆解,Master 收集元信息,并据此进行任务调度;Workers 负责实际工作负载,需要设计高效的单机引擎,并配合全局做冗余。该架构简单直接,但威力强大。

相关文章
|
21天前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
5月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
1433 57
|
9月前
|
存储 缓存 NoSQL
分布式系统架构8:分布式缓存
本文介绍了分布式缓存的理论知识及Redis集群的应用,探讨了AP与CP的区别,Redis作为AP系统具备高性能和高可用性但不保证强一致性。文章还讲解了透明多级缓存(TMC)的概念及其优缺点,并详细分析了memcached和Redis的分布式实现方案。此外,针对缓存穿透、击穿、雪崩和污染等常见问题提供了应对策略,强调了Cache Aside模式在解决数据一致性方面的作用。最后指出,面试中关于缓存的问题多围绕Redis展开,建议深入学习相关知识点。
597 8
|
5月前
|
消息中间件 缓存 算法
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
255 0
分布式开发:数字时代的高性能架构革命-为什么要用分布式?优雅草卓伊凡
|
7月前
|
并行计算 PyTorch 算法框架/工具
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
本文探讨了如何通过技术手段混合使用AMD与NVIDIA GPU集群以支持PyTorch分布式训练。面对CUDA与ROCm框架互操作性不足的问题,文章提出利用UCC和UCX等统一通信框架实现高效数据传输,并在异构Kubernetes集群中部署任务。通过解决轻度与强度异构环境下的挑战,如计算能力不平衡、内存容量差异及通信性能优化,文章展示了如何无需重构代码即可充分利用异构硬件资源。尽管存在RDMA验证不足、通信性能次优等局限性,但该方案为最大化GPU资源利用率、降低供应商锁定提供了可行路径。源代码已公开,供读者参考实践。
499 3
融合AMD与NVIDIA GPU集群的MLOps:异构计算环境中的分布式训练架构实践
|
7月前
|
人工智能 运维 监控
领先AI企业经验谈:探究AI分布式推理网络架构实践
当前,AI行业正处于快速发展的关键时期。继DeepSeek大放异彩之后,又一款备受瞩目的AI智能体产品Manus横空出世。Manus具备独立思考、规划和执行复杂任务的能力,其多智能体架构能够自主调用工具。在GAIA基准测试中,Manus的性能超越了OpenAI同层次的大模型,展现出卓越的技术实力。
|
9月前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
753 41
|
9月前
|
存储 缓存 安全
分布式系统架构7:本地缓存
这是小卷关于分布式系统架构学习的第10篇文章,主要介绍本地缓存的基础理论。文章分析了引入缓存的利弊,解释了缓存对CPU和I/O压力的缓解作用,并讨论了缓存的吞吐量、命中率、淘汰策略等属性。同时,对比了几种常见的本地缓存工具(如ConcurrentHashMap、Ehcache、Guava Cache和Caffeine),详细介绍了它们的访问控制、淘汰策略及扩展功能。
203 6
|
9月前
|
存储 关系型数据库 分布式数据库
[PolarDB实操课] 01.PolarDB分布式版架构介绍
《PolarDB实操课》之“PolarDB分布式版架构介绍”由阿里云架构师王江颖主讲。课程涵盖PolarDB-X的分布式架构、典型业务场景(如实时交易、海量数据存储等)、分布式焦点问题(如业务连续性、一致性保障等)及技术架构详解。PolarDB-X基于Share-Nothing架构,支持HTAP能力,具备高可用性和容错性,适用于多种分布式改造和迁移场景。课程链接:[https://developer.aliyun.com/live/253957](https://developer.aliyun.com/live/253957)。更多内容可访问阿里云培训中心。
211 0
[PolarDB实操课] 01.PolarDB分布式版架构介绍
|
10月前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案

热门文章

最新文章