02-分布式对象存储设计原理
保存图片、音视频等大文件就是对象存储:
-
很好的大文件读写性能 -
还可通过水平扩展实现近乎无限容量 -
并兼顾服务高可用、数据高可靠
对象存储“全能”,主要因为,对象存储是原生分布式存储系统,相比MySQL、Redis等单机存储系统,虽这些非原生存储系统,也具备集群能力,但它们构建大规模分布式集群非常不易。
随云计算普及,很多新生代存储系统,都是原生分布式系统,原设计目标之一就是分布式存储集群,如[ES]、[Ceph]和国内很多大厂推出的新一代数据库,做到:
-
近乎无限存储容量 -
超高读写性能 -
数据高可靠:节点磁盘损毁不会丢数据 -
实现服务高可用:节点宕机不会影响集群对外提供服务
这些原生分布式存储如何实现这些特性?“互相抄作业”,除了存储的数据结构不一样,提供的查询服务不一样以外,这些分布式存储系统,面临的很多问题都一样,实现方法差不多。
对象存储的查询服务和数据结构都简单,是最简单的原生分布式存储系统。
1 对象存储数据咋保存大文件的?
对象存储对外提供的服务,就是近乎无限容量的大文件KV存储,所以对象存储和分布式文件系统之间,无明确界限。对象存储的内部,肯定有很多存储节点,保存这些大文件,这个就是数据节点的集群。
为管理这些数据节点和节点中的文件,还需一个存储系统保存集群的节点信息、文件信息和它们的映射关系。这些为管理集群而存储的数据,叫元数据。保存元数据的存储系统须为集群。但元数据集群存储的数据量少,数据变动不频繁,客户端或网关都会缓存一部分元数据,所以元数据集群对并发要求不高。类似zk或etcd分布式存储即可。
存储集群为对外提供访问服务,还要一个网关集群,对外接收外部请求,对内访问元数据和数据节点。网关集群中的每个节点不需保存任何数据,都是无状态节点。有些对象存储没有网关,是客户端,功能和作用一样。
对象存储如何处理对象读写请求?处理读和写请求的流程一样。网关收到对象读写请求后,先拿请求中的Key,去元数据集群查找这Key在哪个数据节点,再去访问对应数据节点读写数据,最后把结果返回给客户端。
这张图虽画的对象存储集群结构,但名词改改,可套用到绝大多数分布式文件系统和数据库上去,如HDFS。
2 对象如何拆分和保存的?
对象存储如何保存大文件对象。一般,对象存储中保存的文件都是图片、视频大文件。在对象存储中,每个大文件都会被拆成多个大小相等块儿(Block),把文件从头到尾按固定块大小,切成一块一块,最后一块长度有可能不足一个块大小,也按一块处理。块大小配置为几十KB到几MB。
大对象文件拆分成块的目的:
-
提升读写性能,这些块可分散到不同的数据节点,就可并行读写 -
把文件分成大小相等块儿,便于维护管理
对象被拆成块后,还是过于碎片化,如直接管理这些块,会导致元数据的数据量大,也没必要管理到这么细粒度。所以一般都会再把块聚合,放到块的容器。“容器”,存放一组块的逻辑单元。没有统一叫法,如ceph中称为Data Placement。容器内的块数大多固定,所以容器大小也固定。
容器类似MySQL和Redis的“分片”,都是复制、迁移数据的基本单位。每个容器都会有N个副本,这些副本的数据都一样。其中有一个主副本,其他是从副本,主副本负责数据读写,从副本去到主副本上去复制数据,保证主从数据一致。
对象存储一般不记录类似Binlog的日志。主从复制复制的不是日志,而是整块数据:
-
性能。操作日志里就包含数据。在更新数据时,先记录操作日志,再更新存储引擎中的数据,相当于在磁盘上串行写2次数据。对于像数据库这种,每次更新的数据都很少的存储系统,这个开销可接受。但对于对象存储,它每次写入的块很大,两次磁盘IO的开销就有些不太值得 -
存储结构简单,即使没有日志,只要按照顺序,整块儿的复制数据,仍然可以保证主从副本的数据一致性。
以上的对象(即文件)、块和容器,都是逻辑层概念,数据落实到副本上,这些副本就是真正物理存在。这些副本再被分配到数据节点上保存起来。这里的数据节点就是运行在服务器上的服务进程,负责在本地磁盘上保存副本的数据。
数据访问
请求一个Key时:
-
网关首先去元数据查找这个Key的元数据 -
然后根据元数据中记录的对象长度,计算出对象有多少块 -
就可分块并行处理。对每个块,还要再去元数据,找到它被放在哪个容器
容器就是分片,怎么把块映射到容器,不同的系统选择实现的方式也不一样,有用哈希分片的,也有用查表法把对应关系保存在元数据。找到容器后,再去元数据中查找容器的N个副本都分布在哪些数据节点上。然后,网关直接访问对应的数据节点读写数据就可以了。
小结
对象存储是最简单的分布式存储系统,主要由数据节点集群、元数据集群和网关集群(或者客户端)三部分构成。数据节点集群负责保存对象数据,元数据集群负责保存集群的元数据,网关集群和客户端对外提供简单的访问API,对内访问元数据和数据节点读写数据。
为了便于维护和管理,大的对象被拆分为若干固定大小的块儿,块儿又被封装到容器(也就分片)中,每个容器有一主N从多个副本,这些副本再被分散到集群的数据节点上保存。
对象存储虽然简单,但是它具备一个分布式存储系统的全部特征。所有分布式存储系统共通的一些特性,对象存储也都具备,比如说数据如何分片,如何通过多副本保证数据可靠性,如何在多个副本间复制数据,确保数据一致性等等。
希望你不仅学会对象存储,还要对比分析,对象存储和其他分布式存储系统如MySQL集群、HDFS、ES等有啥共同地方,差异在哪。想通这些,你对分布式存储系统的认知,绝对上升全新高度。然后再看之前不了解的存储系统,就简单了。
FAQ
对象存储不是基于日志来进行主从复制。假设对象存储一主二从三副本,采用半同步方式复制数据,即主副本和任意一个从副本更新成功后,就给客户端返回成功响应。主副本所在节点宕机之后,这两个从副本中,至少有一个副本上的数据是和宕机的主副本上一样的,我们需要找到这个副本作为新的主副本,才能保证宕机不丢数据。
但没有日志,如果这两个从副本上的数据不一样,如何确定哪个上面的数据是和主副本一样新?
如果出现缓存不同步的情况,在你负责的业务场景下,该如何降级或者补偿?
设置一个合理TTL,即使出现缓存不同步,等缓存过期后就会自动恢复。再如识别用户手动刷新操作,强制重新加载缓存数据(注意防止大量缓存穿透)。还可以在管理员后台系统中,预留一个手动清除缓存的功能,必要的时候人工干预。
做素材库的,现在自建对象服务器,对象服务器里面大多都是图片素材,场景是读多写少。选择Ceph可以用于生成环境吗?建议你使用公有云的对象存储服务,小规模的公司自建对象存储维护成本太高,不是太划算。
对象存储的cdn缓存是怎么做的?是每次要访问这些元数据,还是直接把这些源数据所有都放在内存里?数据量这么大感觉不适合放内存里吧?CDN缓存的文件一般是保存在CDN节点的磁盘上,当然不排除某些CDN会用节点的内存缓存文件,加速访问。
为什么分块后又聚合到容器中,直接一个容器一个块不行吗?
一个容器就是一个分片,是数据复制的基本单位。也就是说,每个分片都有n个 副本。
分片不能做的太小,越小意味着存储同样容量的数据,分片数量越多。数量过多,查找分片时,需要查找的元数据就会太多,影响查找效率。
对数据复制,同样要有一定的开销,比如记录日志位置,维护数据一致性的开销。分片太小,相对的,这些开销就大。
数据冗余技术主要由两种:
-
传统副本复制 -
纠删码,基于纠删算法,时间换空间 (著名开源对象存储MinIO就是基于纠删码的)
获取更多干货内容,记得关注我哦。
本文由 mdnice 多平台发布