为了节省存储空间，可能会用到压缩技术，压缩大家都很熟悉了，这里不多介绍。
如果是一个海量分布式存储系统，尤其是提供公有云服务，比如网盘服务，肯定会有用户上传一模一样的文件，为了节省成本，自然想到避免存储重复的文件，这就是重删技术（Data deduplication），可参考int32bit：百度云的「极速秒传」使用的是什么技术？，简单理解就是客户端上传文件时，先在本地计算下hash指纹，然后上传到服务器比对，如果指纹一样，说明文件已经存在，此时不需要上传文件内容，直接链接下即可，不仅节省了存储空间(比压缩更省），还节省了上传时间，实现秒传。我了解的Fusion Storage是实现了重删技术，OpenStack Swift、Ceph貌似都没有。

另一个问题是，如果集群彻底瘫了，数据就彻底没了，这可不能忍。为了解决这个问题，你自然会想到使用复制手段，即备份技术，把文件复制存储到其它廉价存储服务器中，比如S3。当用户执行save操作时，复制这个文件并重命名为xxx-20210321233020(时间戳），这样非常容易就能恢复到备份的任意版本，由于每次都要拷贝整个文件，因此称为全量备份(full backup)。每次都复制显然耗时耗空间，自然想到只复制上一次备份后改变的内容，这样就可以节省存储空间，即增量(incremental backup)备份。注意，备份一定要拷贝到其它存储系统，如果仅仅是拷贝到当前存储系统，不叫备份，只能叫副本，集群瘫了，数据仍然不能恢复。副本主要用于防故障，即一块硬盘坏了数据不丢且还能读，备份还用于防人祸，比如误删操作，能回滚到前面的一个备份点上。

以上备份技术需要用户自己手动执行，如果没有实时备份，集群突然挂了，数据还是会丢。因此需要采取容灾策略，其中一个容灾策略就是异地同步技术，或者叫做复制技术(geo-replication/mirror)，这个类似于mysql的主从同步，即在异地建立一个一模一样的集群，这个集群正常情况下不向用户提供存储服务，仅仅同步本地的集群数据，当本地的集群挂了，能够自动切换到异地集群，服务依然可用。注意这个和副本之间完全同步不一样，复制技术通常采用异步策略，基于操作日志replay，mysql使用binlog，ceph使用journal日志。ceph的rbd mirror就是采用的此种技术，关于rbd mirro介绍参考Ceph Jewel Preview: Ceph RBD mirroring。

当然即使有如上的副本技术、备份技术、容灾技术，集群瘫了也可能短时间内不可用。这就引入两个指标，一个是RPO，故障后数据可恢复到故障前哪个时间点，当然越小约好，0表示能立即恢复，无穷大表示数据废了恢复不了了，3表示能恢复到故障前3秒，这其实和备份策略有关，比如每天0点备份，那备份点就是当天0点数据。另一个指标为RTO，即故障后多长时间可以恢复，0表示服务连续毫无影响，无穷大表示服务再也恢复不了了，60表示一个分钟能恢复。

分布式存储系统不仅需要大量的磁盘IO，还需要网络IO，然而网络带宽必然是有限的，有限的资源就必然需要合理的分配。如果某个用户持续不断的读写，抢占大量的IO带宽，则必然导致其它用户性能下降，甚至出现饿死状况。因此需要公平控制用户的IO资源使用情况，于是引入了QoS。QoS的目标是要实现系统IOPS的调度分配，对单一客户端的IOPS、IO带宽进行限制，不能让某个客户端独占了整个系统的IOPS。QoS限制客户端能够使用的最大值称为limit，即上限。注意，QoS不是仅仅有limit就够了，为了避免某些客户端迟迟得不到IO调度而被饿死，QoS还包含一个下限控制，称为reservation。上限limit容易理解，这个下限就容易弄混，因为有人会想，如果我的这个客户端就是没有IO需求，那它的IOPS就是0，这个下限有什么意义。其实这个下限是一个承诺，当客户端有大于reservation的IOPS请求时，系统能够保证给予不小于reservation的IOPS，如果客户端本身就不需要大于的reservation的值，那自然不需要分配其IOPS。
因此，这个reservation翻译为预留更合适，系统调度IOPS时，会优先满足reservation的值，多余的再根据实际情况分配。当然在同时满足了请求的上限和下限下，不同的请求IOPS仍然不同，优先级也有可能不一样，因此还需要一个控制指标，称为分配比例。系统会根据权重去分配，能者多得，这样才能真正发挥资源的最大价值。关于QoS的实现，有两种思路，一种是直接使用Linux系统的cgroup实现，QEMU对虚拟机的磁盘QoS控制就是使用的该原理，这种方式不依赖于存储系统本身的实现。

另一种是QoS由存储系统自己，对某个节点实现QoS可参考VMware在OSDI发表的一篇论文mClock: handling throughput variability for hypervisor IO scheduling，而dmClock即分布式的mClock，实现分布式系统的QoS控制，目前是作为Ceph的一个子项目，ceph/dmclock，关于dmClock的介绍可参考虚拟化I/O QoS mClock算法介绍。

为了继续下文内容，需要先介绍下几个不同的存储服务（接口）：

块存储：即提供裸的块设备服务，裸设备什么都没有，需要用户自己创建分区、创建文件系统、挂载到操作系统才能用，挂一个块存储设备到操作系统，相当于插一个新U盘。只实现了read、write、ioctl等接口。SAN、LVM、Ceph RBD、OpenStack Cinder等都属于块存储服务。
文件存储：可以简单理解为分布式文件系统，通常实现了POSIX接口，不需要安装文件系统，直接像NFS一样挂载到操作系统就能用。典型的文件存储如NAS、HDFS、CephFS、GlusterFS、OpenStack Manila等。
对象存储：提供Web存储服务，通过HTTP协议访问，只需要Web浏览器即可使用，不需要挂载到本地操作系统，实现的接口如GET、POST、DELETE等，典型的对象存储如百度网盘、S3、OpenStack Swift、Ceph RGW等。
有些存储系统只提供以上某种接口，有些存储系统则能够同时支持以上三种存储服务接口，比如Ceph。

块存储最典型的使用场景是作为虚拟机的磁盘。虚拟机通常需要申请几十GB到几TB的虚拟硬盘，但虚拟机实际上并不是一下就真的会用那么多的存储，如果申请多少就分配多少，显然会造成磁盘空间利用率不高，不能实现超售。因此引入了精简配置(thin provision），这个其实不难理解，就是类似于Linux的稀疏文件(sparse file)，关于Linux稀疏文件介绍可参考int32bit: sparse文件处理与传输，简单理解就是当申请一个20GB的虚拟磁盘时并不会立即真正从硬盘中分配空间，而是用多少分配多少，因此可以创建总大小远大于实际物理磁盘空间大小的磁盘，实现磁盘超售。但需要注意控制超售率，避免虚拟磁盘写满时，物理磁盘空间不足导致数据损坏。

分布式存储和本地存储一样，自然需要有版本控制，用户可以随时回滚到任意一个时间点的存储状态，或者基于某个时间点的版本修改，类似于git的checkout以及branch操作。当然你可以使用备份技术实现，只是太耗时耗空间。
为了实现这个功能，引入快照技术(snapshot)，快照的功能形如其名，就是把当前的存储状态拍个照保存下来，以后可以随时回滚到某个快照时刻的状态。可以在快照的基础上，创建一个一样的磁盘卷，称为克隆（clone），注意和复制（copy）的不同，创建的新卷并没有拷贝源数据，也没有分配任何存储空间，只是画了一个指针指向原来的快照卷，秒级完成。OpenStack使用Ceph存储后端能够秒级创建虚拟机就是这个原因。当用户读取数据时，如果自己的卷没有找到，则需要在它parent中去找，如何写入则取决于采用何种快照方式。
快照的实现有两种方式，一种是COW（Copy On Write，写时拷贝），快照是只读的，不允许修改，当用户有新的数据写入克隆的磁盘时，会首先从快照中拷贝一份数据写到另一个分配的空间，然后把修改的数据覆盖新分配的空间，相当于两次写操作。当磁盘创建快照，克隆，再创建快照，再克隆，形成一条很长的克隆链，当读取数据时，需要从当前卷开始查找，找不到查找其parent卷，直到查找到base镜像，写入数据也类似，当没有当前卷的块时，需要从其parent中依次查找，然后拷贝到自己的卷中，再写入新的数据。显然，当链越来越长时，卷的读写性能越来越差，因此需要控制链的长度。
另一种快照技术是ROW(Redirect On Write)，这个和COW不同，当有新数据写入时，直接写入一个新分配的区，然后修改卷的指针指向新的区地址，只有一次写操作，关于COW与ROW介绍可以参考ROW/COW 快照技术原理解析。虚拟机可能同时挂了多个虚拟硬盘，需要对这个虚拟机打快照，此时需要保证所有的卷的快照时一致的，而不能出现各个卷快照点不一致。于是引入了一致性快照技术(Consistency Snapshot Group)，参考存储专栏：深度解读高端存储的快照技术_存储在线。
以上，粗略总结了分布式存储系统的一些关键技术，参考了很多博客文章。需要强调的是真正实现分布式存储系统的技术远不止这些，其它的技术，诸如副本不一致时如何同步，新增或者减少节点时数据如何迁移，引入缓存提高性能等等。