带你读《存储漫谈:Ceph原理与实践》——1.2.1 有中心架构

简介: 带你读《存储漫谈:Ceph原理与实践》——1.2.1 有中心架构

1.2  各主流分布式方案对比


分布式存储系统种类繁多,通常按照使用场景,可将分布式存储系统划分为分布式块存储、分布式文件存储以及分布式对象存储 3 类,如图 1-6 所示。


image.png 图 1-6 分布式存储系统分类

块存储将裸磁盘空间直接映射给主机使用,主机层面操作系统识别出磁盘后,可对磁盘进行分区、格式化文件系统或者直接进行裸设备读写。块存储使用线性地址空间,不关心数据的组织方式以及结构,读写速度更快,但共享性较差。

文件存储将文件系统直接挂载给主机使用,主机层面操作系统可对挂载后的文件系统直接进行读写,读写操作遵循 POSIX(Portable Operating System Interface of UNIX)语义,类似操作本地文件系统。文件存储使用树状结构以及路径访问方式,更方便理解、记忆,更适合结构化数据的存取,共享性更好,但读写性能较差。

对象存储介于块存储与文件存储之间,以 restful api 或者客户端 sdk 的形式供用户使用,更适合非结构化数据的存取。对象存储使用统一的底层存储系统,管理文件以及底层介质的组织结构,然后为每个文件分配一个唯一的标识,用户需要访问某个文件,直接提供文件的标识即可。

除以上 3 种分布式存储方案的划分外,分布式存储系统还可分为分布式数据库系统和分布式缓存系统等。

从架构角度切入,无论是分布式块存储系统、分布式对象存储系统、分布式文件存储系统,抑或是分布式数据库系统、分布式缓存系统,其架构无外乎以下两种。

◆ 有中心架构

有中心架构下,分布式存储集群实现统一的元数据服务,元数据统一存储并管理,客户端发起对数据的读写前,先向元数据服务器发起读写请求。

◆ 无中心架构

无中心架构下,分布式存储系统没有单独的元数据服务,元数据与数据一样,切片打散后存储在多台存储服务器上,客户端通过特定算法进行计算,确定元数据及数据的存储位置,并直接向存储节点相关进程发起数据的读写访问请求。依照使用的算法类型,无中心架构又可细分为私有算法模式以及一致性散列(Hash)模式。下文以 HDFS、Ceph、Swift 为例,对 3 种方案做简要对比。


1.2.1  有中心架构

HDFS(Hadoop Distribution File System)是有中心分布式存储系统的典型代表。在这种架构中,一部分节点 Name Node 用于存放管理数据(元数据文件),另一部分节点Data Node 用于存放业务数据(数据文件),其系统架构如图 1-7 所示。

在图 1-7 中,如果客户端需要从某个文件读取数据,首先从 Name Node 获取该文件的位置信息(具体在哪个 Data Node),然后从该 Data Node 上获取具体的数据。在该架构中Name Node通常是主备部署,而Data Node则是由大量服务器节点构成一个存储集群。由于元数据的访问频度和访问量相对数据都要小很多(参见后文 HDFS 使用场景),因此Name Node 通常不会成为性能瓶颈;Data Node 在集群中通常将数据以副本形式存放,该策略下既可以保证数据的高可用性,又可以分散客户端的请求。因此,这种分布式存储架构可以横向扩展 Data Node 的数量来增加存储系统的承载能力,也即实现系统的动态横向扩展。

HDFS 目前主要用于大数据的存储场景,HDFS 也是 Hadoop 大数据架构中的存储组件。HDFS 在开始设计的时候,就已经明确了它的应用场景(即大数据服务),具体如下:

image.png

图 1-7 HDFS 系统架构

(1)对大文件存储的性能要求比较高的业务场景

HDFS 采用集中式元数据的方式进行文件管理,元数据保存在 Name Node 的内存中,文件数量的增加会占用大量的 Name Node 内存。即当 HDFS 存储海量小文件时,元数据会占用大量内存空间,引起整个分布式存储系统性能的下降。由于此限制,HDFS 更适合应用在存储大文件的使用场景,文件大小以百 MB 级别或者 GB 级别为宜。

(2)读多写少的业务场景

HDFS 的数据传输吞吐量比较高,但是数据写入时延比较差,因此,HDFS 不适合频繁的数据写入场景,但就大数据分析业务而言,其处理模式通常为一次写入、多次读取,然后进行数据分析工作,HDFS 可以胜任该场景。

相关文章
|
网络协议 NoSQL API
转转客服IM系统的WebSocket集群架构设计和部署方案
客服IM系统是转转自研的在线客服系统,是用户和转转客服沟通的重要工具,主要包括机器人客服、人工客服、会话分配、技能组管理等功能。在这套系统中,我们使用了很多开源框架和中间件,今天讲一下客服IM系统中WebSocket集群的的实践和应用。
766 141
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
313 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1601 3
|
12月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
722 61
|
12月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
732 1
|
消息中间件 监控 Cloud Native
高效设计:支持亿级用户社交关系的100W QPS架构方案
面对亿级用户与百万QPS的高并发场景,性能测试成为系统稳定的关键。本文剖析真实业务痛点,详解从接口压测、全链路监控到瓶颈定位的完整性能体系,助你掌握大厂级性能优化能力,从容应对卡顿、宕机等线上挑战。
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
4413 57

热门文章

最新文章