后端存储实战课
李玥
美团高级技术专家
44005 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

18 | 分布式存储:你知道对象存储是如何保存图片文件的吗?

数据一致性
逻辑单元
目的
存储系统
重要性
查询服务
存储结构
容器映射
块儿处理
元数据查找
主从复制
容器
块儿
细节
流程
网关集群
元数据
存储节点集群
共性
原生分布式存储系统
高可靠
高可用
水平扩展
大文件读写性能
思考题
数据访问流程
对象拆分和保存
对象读写请求处理
数据保存
实现方式
特性
对象存储
分布式存储

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
我们都知道,保存像图片、音视频这类大文件,最佳的选择就是对象存储。对象存储不仅有很好的大文件读写性能,还可以通过水平扩展实现近乎无限的容量,并且可以兼顾服务高可用、数据高可靠这些特性。
对象存储之所以能做到这么“全能”,最主要的原因是,对象存储是原生的分布式存储系统。这里我们讲的“原生分布式存储系统”,是相对于 MySQL、Redis 这类单机存储系统来说的。虽然这些非原生的存储系统,也具备一定的集群能力,但你也能感受到,用它们构建大规模分布式集群的时候,其实是非常不容易的。
随着云计算的普及,很多新生代的存储系统,都是原生的分布式系统,它们一开始设计的目标之一就是分布式存储集群,比如说ElasticsearchCeph和国内很多大厂推出的新一代数据库,大多都可以做到:
近乎无限的存储容量;
超高的读写性能;
数据高可靠:节点磁盘损毁不会丢数据;
实现服务高可用:节点宕机不会影响集群对外提供服务。
那这些原生分布式存储是如何实现这些特性的呢?
实际上不用我说,你也能猜得到,这里面同样存在严重的“互相抄作业”的情况。这个也可以理解,除了存储的数据结构不一样,提供的查询服务不一样以外,这些分布式存储系统,它们面临的很多问题都是一样的,那实现方法差不多也是可以理解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

对象存储是一种原生的分布式存储系统,具有近乎无限的存储容量、超高的读写性能、数据高可靠和服务高可用等特点。在对象存储中,大文件会被拆分成多个大小相等的块,然后聚合成容器,每个容器都有多个副本,其中一个是主副本,其他是从副本。这些副本被分配到数据节点上保存,实现了数据的分布式存储。当请求一个文件时,网关会根据元数据找到对应的数据节点进行读写操作。对象存储的设计和实现方法可以帮助读者快速了解分布式存储系统的一些共性,为进一步学习和认识其他分布式存储系统打下基础。 对象存储是最简单的分布式存储系统,主要由数据节点集群、元数据集群和网关集群(或者客户端)三部分构成。数据节点集群负责保存对象数据,元数据集群负责保存集群的元数据,网关集群和客户端对外提供简单的访问API,对内访问元数据和数据节点读写数据。大的对象被拆分为若干固定大小的块儿,块儿又被封装到容器(也就分片)中,每个容器有一主N从多个副本,这些副本再被分散到集群的数据节点上保存。对象存储虽然简单,但它具备一个分布式存储系统的全部特征,如数据分片、多副本保证数据可靠性、数据一致性等。 文章还提出了一个思考题,讨论了对象存储采用半同步方式复制数据时,主副本宕机后如何确定新的主副本的问题。这篇文章通过介绍对象存储的基本原理和特点,为读者提供了对分布式存储系统的认知,并鼓励读者对比分析对象存储和其他分布式存储系统,如MySQL集群、HDFS、Elasticsearch等,以提升对分布式存储系统的理解。文章内容丰富,对读者有很大的帮助,也值得分享给更多的朋友。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(27)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里回顾一下上节课的思考题: 如果出现缓存不同步的情况,在你负责的业务场景下,该如何降级或者补偿? 这个问题我看到留言区有一些同学给出了非常好的答案,比如说,设置一个合理的缓存过期时间,这样即使出现缓存不同步,等缓存过期后就会自动恢复。再比如,识别用户手动刷新操作,强制重新加载缓存数据(但要注意防止大量缓存穿透)。还可以在管理员的后台系统中,预留一个手动清除缓存的功能,必要的时候人工干预。
    2020-04-07
    5
    35
  • L
    老师,我问一个小问题。公司是做素材库的,现在自建对象服务器,对象服务器里面大多都是图片素材,场景是读多写少。选择Ceph可以用于生成环境吗?或者有没有更好的方案选择?谢谢老师

    作者回复: 建议你使用公有云的对象存储服务,小规模的公司自建对象存储维护成本太高,不是太划算。

    2020-04-10
    3
    20
  • 喆里
    请教个问题,为什么分块后又聚合到容器中,直接一个容器一个块不行吗?这块设计思路没看明白

    作者回复: 一个容器就是一个分片,是数据复制的基本单位。也就是说,每个分片都有n个 副本。 分片不能做的太小的原因是,分片越小,意味着存储同样容量的数据,分片的数量越多。分片数量过多,查找分片时,需要查找的元数据就会太多,影响查找效率。 另外,对于数据复制,同样要有一定的开销,比如记录日志位置,维护数据一致性的开销。分片太小,相对的,这些开销就会比较大。

    2020-05-25
    18
  • 于海涛
    老师,有一个问题想问您,对象存储的cdn缓存是怎么做的?是每次要访问这些元数据,还是直接把这些源数据所有都放在内存里?数据量这么大感觉不适合放内存里吧?感谢老师

    作者回复: CDN缓存的文件一般是保存在CDN节点的磁盘上,当然不排除某些CDN会用节点的内存缓存文件,加速访问。

    2020-05-15
    2
    9
  • Jxin
    每次操作都更新操作时间。谁的操作时间最新谁就是最接近主节点的副节点。

    作者回复: 那这个时间从哪儿来呢?如果都从本机的时钟获取,怎么保证集群中所有节点的时钟是一致的呢?

    2020-04-07
    2
    3
  • J.Smile
    老师,有个地方不清楚,这里的每个容器一般只存储对象的一部分块,那么首先应该是从元数据集群中根据key找到这个对象对应的所有容器,第二步,因为多个容器中的块组成一个完整对象,而每个容器又被存到某个数据节点中了,所以此时应该再去元数据集群中找多个容器所对应的数据节点。总之,只要找到了容器的存储位置,容器内块就找到了。文章中提到的块的聚合指的是容器来聚合块吗?这样元数据集群就是管理容器了。容器内存的是块的索引还是实际数据呢?

    作者回复: 容器内存放的就是实际的数据。

    2020-04-17
    2
    2
  • 每天晒白牙
    如果是基于 Raft 协议的,会根据任期的编号大小决定谁是领导者
    2020-04-07
    18
  • Kevin Wang
    老师讲得很好,提一点建议。 数据冗余技术主要由两种: 1. 传统副本复制 2. 纠删码,基于纠删算法,时间换空间 (著名开源对象存储MinIO就是基于纠删码的) 建议文中也提一下第2种。
    2020-07-31
    2
    7
  • 对象存储 不是一般都有版本控制的吗 ? 最新的版本就是最新的数据
    2020-04-07
    1
    6
  • 凯文小猪
    有些同学对于为什么不适用操作日志可能有疑惑 这里简单说一下: 1.文件系统为了保证一致性与原子性 需要使用journal(又被称为write ahead logging,即WAL)技术来实现。 写入时或者更新时 要先写index node日志 数据日志,而这些对于文件系统来说会有两个问题: a)通常文件系统保存的文件都很大 所以无论怎么分割块 index node 天生就多,这样journal日志写入反而是个负担 b)分布式存储不像文件系统需要支持很多的搜索场景 所以内部存储不是用B树 而是KV ,故写入反而简单,如果同步失败也可以快速发现重做即可 2.binlog文件的增大 会导致每次写操作必须保证原子性 因为宿主机linux文件系统还是以一页 16KB来做一次原子写 ,这就会衍生出其他的问题。 最后回答下老师的问题 可以使用版本号来维护 将其作为epoch,在根据其大小用raft选主即可
    2021-12-15
    3
收起评论
显示
设置
留言
27
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部