设计一个存储器
发布网友
发布时间：2023-03-28 17:18
共1个回答
热心网友
时间：2023-10-28 12:01
1.云计算存储开发
2003年，谷歌发表论文GFS，披露解决了索引地球的海量互联网数据的存储问题。2006年，亚马逊推出了划时代的AWS云计算服务EC2和S3，开启了改变世界IT格局的云计算时代。谷歌，微软，阿里云等。都跟着。
上面提到的A Bite os S3 Arch如何构建一个分布式存储系统来支持大规模S3对象存储。云计算还有另外两个重要的基础存储基础架构组件EBS(弹性块存储)和EFS(弹性文件服务)，分别对应传统IT基础架构中的本地磁盘和共享文件存储服务。
云计算很重要的一点就是超卖和灵活性，所以支持EBS和EFS方案的底层基础存储层的支持不太可能是本地本地化方案，必须是分布式的存储资源管理和分配系统。
然而，与S3服务相比，EBS底层的分布式存储系统提供的IO模型实际上有很大不同。S3的基本外部接口功能是PUT/GET/DELETE，它对底层分布式文件系统的要求是Append。EBS和EFS需要支持对用户随机地址空间的重写，那么如何设计底层存储系统来支持这两类服务呢？
对于这一块的业务架构，目前各大互联网公司基本都没有开源，基本架构也没有或者很少正面出来。这一方面可能被视为商业秘密，另一方面可能从安全、*等方面考虑。
当然，开源系统的论文和一些互联网公司的存储系统可以参考，比如ceph、Lustre、HDFS、GlusterFS、FastDFS、Window Azure Storage、GFS等等。这些都称自己为分布式文件系统，但是在具体的场景和文件的定义上有很多不同。以下几个方面差别很大。
EBS底层的分布式存储系统至少需要确保以下几点
EBS底层分布式存储系统需要提供上述重要特性，还有一些重要的核心需求。
那么如何设计和构建EBS底层的分布式存储系统来满足业务的需求，也就是如何设计一个向上层业务提供随机IO能力的分布式存储系统。这里有一些可能的方法来建立它。
对于EBS业务，抽象地说，需要底层分布式文件系统提供可以随机读写的文件的能力。按照最直接的方式，可以如下图逻辑映射。1TB Vdisk /dev/sad对应的是底层分布式文件系统为/foo/sda的文件。1TB地址空间上的chunk是按需分配的，分配的基本单元一般是固定的，如下图，4MB。
Qemu等。提供了对接块设备驱动的API，只要在分布式文件系统对接对应的客户端实现API，块设备就可以向上输出。
网易实现了这种从0到1的构建方式。CURVE现在是开源的(百度类似于这个方案)，底层抽象为典型的分布式文件系统，向服务输出具有随机读写能力的文件，以支持上层块设备的EBS类型服务。架构基本类似于经典分布式文件系统的鼻祖GFS，如下图所示。
基础设施
数据表面核心
底层ChunkServer基于Raft)状态机来实现副本一致性。有关详细信息，请参见Raft对等复制状态机。所有上层用户的写入都依赖于一致性协议来确保多个副本的一致性，每个用户的区块都分配给这些复制组。
如上图所示
这种架构方案优点是：
该方案的缺点：
上述构建模式1是一种0对1的架构设计和实现。第二种构造方法主要是和圈内的童鞋沟通，细节无法研究，但从整体结构层面解释分析没有大问题。
其基本架构类似于Window Azure Storage的架构。Stream层构建在底层，Partition层构建在Stream层的基础上(类似GFS)，EBS方案可以构建在Partition层的基础上(类似BigTable)。
如何支持基于这种架构的服务，需要从另一个角度思考如何解决这个问题。回到问题的出发点，EBS随机地址空间读写方案的核心是什么问题？
简单来说，块设备提供对每个地址空间(比如4KB)的原子读写(PUT/GET)。换句话说，如果为每个EBS实例的每个4KB内容定义了一个全局可编码的惟一键，那么它的内容就是4KB的固定大小值。那么底层的分布式存储系统就是一个专用的分布式键值系统。
构造方法2基本上遵循这样的思想。
作为上面的基本逻辑视图示例，底层物理层结构如下图所示。
StreamLayer:类似于GFS/HDFS层次结构，每个流类似于一个文件，流只支持append。Stream由盘区组成(类似于HDFS/GFS的chunk)，盘区使用固定复制组的方案实现多个副本/EC(参考微软PacificA协议)。范围支持可变长度。当盘区不可用时，seal/new创建一个新的盘区继续提供写入，以保证写入的高可用性。
分区服务器：提供一段表(根据字典
序*）的kv 存储服务（增/删/改/查）。其通过WAL实现数据的快速和及时写入，保障数据的持久性；然后写入MemStore（SkipList跳表实现），在MemStore达到固定大小，比如128MB的时候Dump成SSTable（Sorted String Table），Block Cache 负责SStable 热点数据的读缓存。一个Partiton Server 负责多个Partition。
架构方面的更加具体的参考Window Azure Storage 的paper或者BigTable开源实现方面的书籍和资料，这里不多做展开。
在实际操作层面，对于一个上层的EFS实例，有挺多的映射关系：
一般来说为了实现EFS的快照和克隆功能，一个EFS实例一般都选择一个table。如果是只有一个WAL，写入的吞吐容易受影响，可以在上层使用一定的间接的业务逻辑手段使得多个相邻的地址空间换分到不同的Region，从而把上层IO映射到更多的Region，使用多个WAL写入能力提升带宽。比如将地址空间按照1MB取模划分到4个独立的连续字典序区间Region。
此种构架方案的优点：
反脆弱：这是这种方案我认为最最大的优点，也是相比方案一的绝对杀手锏，很多分布式存储系统其实从 基层层面都没有好好考虑这个问题，或者到意识到这种方案的巨大优势。即从读层面WAS基本实现了 已经seal 数据的任何副本是可读的。对于写数据来说，由于写入只*在当前 尚未seal 掉的chunk上，也就是3个磁盘上，并且在故障情况下随时可以seal掉转移。这两点使得虽然 上层一个table的数据打散到底层这么多磁盘上。但是从爆炸半径来说，基本上算是实现了本地盘方案的爆炸半径，甚至在故障，过载情况下可以实现快速转移。从这点上来说，这样基本为分布式存储方案去完全干掉本地存储方案，打下了极其坚实的基础。
此种构建方案的缺点：
构建方案3类似方案2的变种。核心的不同点在于，构建方案2的全局排序和垃圾回收工作依赖于后期的compaction。而构建方式3倾向于尽可能块得进行原地排序。
其基本原理是，通过WAL 写入确保数据持久性，然后使用到内存。后台定期将写入原地使用到随机读写文件（没错，底层除了需要实现AppendFile，还需要实现弱一致的随机读写文件RandomFile，多幅本的数据一致性由Client负责，这引入一个缺点，随机读写文件很难做EC），WAL使用seal-new的方式确保写入可用性，读取采用Merge 更新数据（wal） 基线数据（随机读写文件数据）的方式实现数据的读取。在内存中建立对整个WAL内容的索引，最新的数据在WAL中则直接从WAL中读取，否则从随机读写文件中读取，其基本读写流程图如下
写入：写入还是一样写入WAL，然后更新内存索引，将最新数据的使用MemTable(Hash表)指向WAL。但是最终结果的Dump其实并不是按照sstable的方式，而是直接后台异步mp到对应RandomFile的随机地址空间。
PS1：WAL 也是类似Segment方式，定期做checkpoint（刷入RandomFile），在内存中会构建所有WAL segment的索引，WAL采用Seal/New的方式来保障可用性。
PS2: RandomFile是随机读写文件，为了保障WAL长度的收敛性，后台线程会将WAL数据写入RandomFile。RandomFile 没法使用Seal-New的可用性，但是由于是BackGround的写入。所以如果发现一个副本失败，会使得BackGround mp机制阻塞（这种方案在坏盘恢复场景下，会导致BackGround写入会卡很久）。
读取: 读取会首先通过Memtable查找最新数据是否在WAL中，不存在的情况下再读RandomFile。对于RandomFile未达到一致性状态的数据，会从WAL里头进行读取。（PS:由于WAL(AppendFile) 到 RandomFile的写入是全三副本，并且一直是卡着的，所以RandomFile的恢复可以采用很鲁棒的方式，直接选中任意一个还在复制组中的副本作为数据源复制。)
这种方案可以一定程度解决。读放大、空间利用率等方面的问题。但是在克隆、快照等方面会稍微差一些，并且随机读写文件很难做EC（EC改写好麻烦）。
如上对3种构建方式进行了简要的构建和优缺点的说明。没有绝对的那个构建方案优于另外一个构建方案。在实践过程中应结合自身面向的实际业务特点和技术条件等进行选择，能快速跟上业务发展并且对方案做中长期的评估适时进行调整。
很重要一点是一定得进行抽丝剥茧、形而上得分析问题的本质。这样才能够把精力集中在真正的问题上，好钢放在刀刃上。
简单来说，块设备提供了对每一个地址空间（比如4KB）的原子写入和读取(PUT/GET)。换一个角度来说如果对每一个EBS实例的每一个4KB内容定义一个全局可编码的唯一Key，其内容为4KB的固定大小的Value。那么这个底层分布式存储系统就是一个专用的分布式Key-Value系统。
以上不同的方案，从逻辑上往上抽象都可以认为是向业务提供KV存储。最本质的区别可以认为是排序在什么时候进行。构建方案1总体来说是即刻全局排序。构建方案2 则采用局部有序的方案。而架构方案3则 使用架构方案1和方案2 的折中。
另外一个很重要的差别是从核心可靠性的角度来说，构建方案1采用了多数派（如Raft）方案应对分布式的CAP问题。而构建方案2、3采用PrimayBackup Master（多数派） Append Only的特点来应对CAP问题。
