创建快照以后，快照系统把对数据卷的写请求重定向给了快照预留的存储空间，直接将新的数据写入快照卷。上层业务读源卷时，创建快照前的数据从源卷读，创建快照后产生的数据，从快照卷读。
写操作：
如上图简要示例，快照创建以后，若上层业务对源卷写数据X，X在缓存中排队，快照系统判断X即将写入源卷的逻辑地址，然后将数据X写入快照卷中预留的对应逻辑地址中，同时，将源卷和快照卷的逻辑地址写入映射表，即写重定向。我们可以看到，上层针对源卷写入一个数据块X，存储上只发生一次写操作，只是写之前进行了重定向。
读操作：
若快照创建以后，上层业务对源卷进行读，则有两种情况：1）若读取的数据，在创建快照前产生，数据是保存在源卷上的，那么，上层就从源卷进行读取；2）若需要读取的数据是创建快照以后才产生的，那么上层就查询映射表，从快照卷进行读取（即读重定向）。
若快照创建以后，上层业务对快照卷进行读，同样也有两种情况：1）若读取的数据，在创建快照前产生，数据是保存在源卷上的，那么上层就查询映射表，从源卷进行读取；2）若需要读取的数据是创建快照以后才产生的，那么上层就直接从快照卷进行读取。
我们可以看到，ROW快照也是根据创建快照后上层业务产生的数据，来实时占用必需的存储空间。
快照回滚（rollback）：
采用ROW技术的快照，其源卷始终保存着快照创建前的完整数据，快照创建后，上层业务产生的数据都写入了快照中，因此，快照的回滚只是取消了对源卷的读重定向操作。通俗地说，就是源卷上没有进行任何数据操作，上层业务对源卷的读，仅限于读源卷（即不会去读取快照卷的数据）。
快照删除：
采用ROW技术的快照，其源卷始终保存着快照创建前的完整数据，快照创建后，上层业务产生的数据都写入了快照中。因此，若要删除快照，必然要先将快照卷中的数据，回拷到源卷中，拷贝完成才能删除，如上图。此时我们可以设想，如果，针对一份源数据，在18:00创建了快照，上层业务持续产生大量新的数据，19:00又创建了快照，20:00又创建了快照……那么，在有多份快照的情况下，如果需要删除快照，就会出现，多个快照向源卷回拷数据的情况，可能导致回拷量非常大，耗时很长。
两种技术对比
如上表，COW的写时拷贝，导致每次写入都有拷贝操作，大量写入时，源卷的写性能会有所下降，而读源卷是不会受到任何影响的，删除快照时，只是解除了快照和源卷的关系，同时删除了快照卷的数据而已。ROW在每次写入仅做了重定向操作，这个操作耗时是几乎可以忽略不计的，源卷的写性能几乎不会受到影响，但读源卷时，则需要判断数据是创建快照前还是创建快照后，导致大量读时，性能受到一定影响，比较致命的是，若源卷有多个快照，在删除快照时，所有快照的数据均需要回拷到源卷才可以保证源卷数据的完整性。
结语上面简单地介绍了存储快照的实现原理，实际上，快照特性应用广泛，其应用对象是很多的：
目前，主流厂商在自研产品上，对上面的ROW和COW技术都有小范围的改动，也有一些新兴的快照技术已经诞生，但这个行业里，没有最好的快照技术。技术为业务服务，只有针对业务类型做好本地化适配，才能达到最佳效用。
问答消失存储过程？
相关阅读腾讯云CIS入门——Kubernetes部署
腾讯云API：用Python使用腾讯云API（机器翻译实例）
主机迁移实践分享
此文已由作者授权腾讯云+社区发布，原文链接：https://cloud.tencent.com/developer/article/1158686?fromSource=waitui
欢迎大家前往腾讯云+社区或关注云加社区微信公众号（QcloudCommunity），第一时间获取更多海量技术实践干货哦~
海量技术实践经验，尽在云加社区！