分布式系统架构(一)——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 负责实际工作负载,需要设计高效的单机引擎,并配合全局做冗余。该架构简单直接,但威力强大。

相关文章
|
6天前
|
设计模式 安全 Java
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
【分布式技术专题】「Tomcat技术专题」 探索Tomcat技术架构设计模式的奥秘(Server和Service组件原理分析)
41 0
|
6天前
|
负载均衡 监控 Dubbo
Java微服务架构设计与实践:构建可伸缩的分布式系统
【4月更文挑战第2天】微服务架构响应现代业务需求,通过拆分大型应用为独立服务实现模块化和可扩展性。Java中的Spring Boot和Dubbo等框架支持服务注册、负载均衡等功能。遵循单一职责、自治性和面向接口原则,每个服务专注特定逻辑,独立部署运行。实际项目中,如电商系统,服务按功能拆分,提升可维护性和扩展性。还需考虑服务通信、数据一致性和监控等复杂话题。Java微服务架构助力构建高效、灵活的应用,应对未来挑战。
Java微服务架构设计与实践:构建可伸缩的分布式系统
|
6天前
|
存储 关系型数据库 分布式数据库
电子好书发您分享《PolarDB分布式版架构介绍PolarDB分布式版架构介绍》
**《PolarDB分布式版架构介绍》电子书分享:** 探索阿里云PolarDB分布式设计,采用计算存储分离,借助GMS、CN组件实现大规模扩展。[阅读更多](https://developer.aliyun.com/ebook/8332/116553?spm=a2c6h.26392459.ebook-detail.5.3b3b2ccbVVjjt0)
22 3
|
4天前
|
消息中间件 分布式计算 中间件
秀出天际!阿里甩出的988页分布式微服务架构进阶神仙手册我粉了
秀出天际!阿里甩出的988页分布式微服务架构进阶神仙手册我粉了
|
6天前
|
存储 分布式计算 分布式数据库
【专栏】云计算与分布式系统架构在数字化时代的关键作用。云计算,凭借弹性、可扩展性和高可用性,提供便捷的计算环境
【4月更文挑战第27天】本文探讨了云计算与分布式系统架构在数字化时代的关键作用。云计算,凭借弹性、可扩展性和高可用性,提供便捷的计算环境;分布式系统架构则通过多计算机协同工作,实现任务并行和容错。两者相互依存,共同推动企业数字化转型、科技创新、公共服务升级及数字经济发展。虚拟化、分布式存储和计算、网络技术是其核心技术。未来,深化研究与应用这些技术将促进数字化时代的持续进步。
|
6天前
|
缓存 负载均衡 Java
Java分布式系统架构设计与实现
【4月更文挑战第2天】在快速发展的互联网时代,Java分布式系统成为应对复杂业务和高用户量的首选。通过服务化拆分、注册发现、负载均衡和缓存等技术,如Spring Cloud和Dubbo,开发者能构建高效、可靠、可扩展的系统。服务注册与发现确保服务间通信,负载均衡分配请求,分布式缓存如Redis提升性能。面对数据一致性和监控等挑战,Java提供工具解决,助力打造现代分布式应用。
Java分布式系统架构设计与实现
|
5天前
|
缓存 负载均衡 监控
探索分布式系统演进之路:从负载均衡到微服务架构
小米分享了分布式系统的发展,从早期的负载均衡(入口级、网关和客户端)到微服务架构的演进。微服务实现服务解耦,增强系统弹性,但带来了新的挑战。为优化数据库性能,实施了主备读写分离、全文搜索引擎、缓存集群等措施。通过微服务治理,如服务注册、动态配置、灰度发布等,提升了系统稳定性和可靠性。未来将继续优化分布式系统,提供更好的服务体验。关注公众号“软件求生”了解更多。
26 6
|
6天前
|
运维 Cloud Native 持续交付
构建未来:以云原生为基石的分布式系统架构深入理解操作系统的内存管理机制
【4月更文挑战第30天】 随着企业数字化转型的不断深入,传统的IT架构已难以满足市场对于敏捷性、可扩展性和成本效益的需求。云原生技术作为推动这一变革的关键因素,其设计理念和实现方式正在重塑软件开发和运维模式。本文将探讨云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)、以及无服务器计算等,并分析其在构建分布式系统中的作用与挑战。通过实际案例,我们将展示如何利用云原生技术构建高效、弹性和可维护的分布式系统。
|
6天前
|
负载均衡 应用服务中间件 nginx
服务器架构、分布式系统、负载均衡、微服务、高可用性
**分布式系统取代单体架构,以微服务实现高扩展性和灵活性。通过负载均衡技术增强性能,防止单点故障,结合冗余备份与故障切换保障高可用性,这种架构是支撑大规模在线业务的关键。**
48 3
|
6天前
|
存储 运维 物联网
【专栏】OceanBase 是一款先进的分布式数据库系统,以其分布式架构、高扩展性、高可用性和强一致性特点,应对大规模数据处理挑战
【4月更文挑战第29天】OceanBase 是一款先进的分布式数据库系统,以其分布式架构、高扩展性、高可用性和强一致性特点,应对大规模数据处理挑战。它支持混合负载,适用于金融、电商和物联网等领域,提供高性能、低成本的解决方案。尽管面临技术复杂性、数据迁移和性能优化等问题,通过合理策略可克服挑战。随着技术发展,OceanBase 在数字化时代将持续发挥关键作用。