从“专用”云存储产品到“通用”云存储产品有多远？——2009-1-15 CTO俱乐部第一次聚会“云计算”后记

　　CTO俱乐部第一次聚会的主题是“云计算”，有幸认识了北京美地森科技创始人游峰先生，聆听游峰先生关于云存储方面进展的介绍。关于聚会的概述发表在：
　　2009-1-15 CTO俱乐部第一次聚会，http://blog.csdn.net/hu_zhenghui/archive/2009/01/16/3793180.aspx
　　其中关于云存储的讨论，有幸受到游峰先生的关注，因此我就该话题展开讨论，发表在：
　　云存储“有效”应用和云存储“无效”应用，http://blog.csdn.net/hu_zhenghui/archive/2009/01/17/3808511.aspx
　　游峰先生又进一步指导我参考Google相关资料，就此问题，我继续展开说明我的观点，发表在：
　　云存储“有效”应用实例和云存储“有效”应用平台, http://blog.csdn.net/hu_zhenghui/archive/2009/01/18/3832075.aspx
　　游峰先生介绍我参考关于虚拟操作系统的相关资料，就此问题，我继续展开说明我的观点，发表在：
　　从总拥有成本TCO看云应用平台粒度, http://blog.csdn.net/hu_zhenghui/archive/2009/01/24/3852636.aspx
　　在从粗粒度角度讨论了云应用平台之后，游峰先生又介绍我参考关于通用云存储产品的相关资料，就此问题，我继续展开说明我的观点，请各位前辈和专家斧正。
　　在这里我特指“通用”云存储产品，“通用”是和“专用”相对应，从“专用”的角度来看，既可以是专门用于特定应用的云存储产品，例如邮件存储应用（包括 POP3、IMAP或者其他借助于HTTP等通讯协议实现类似于IMAP的协议）和UGC应用（用户创造内容，包括文本、图片、视频和文件等）；也可以是适用于广泛应用但需要进行部分二次开发的云存储产品。虽然几乎所有的应用都可以经过部分二次开发后使用云存储产品，但应用和云存储产品之间的耦合仍属于强耦合，如果不能将强耦合解耦，那么云存储产品就仍是“专用”，而不是“通用”。接下来本文将从一些具体产品的使用场景来探讨“通用”云存储产品应当具体的特性。
　　先从Windows Server漫游配置文件说起，Windows Server从NT 4.0开始支持漫游配置文件，在配置成漫游配置文件之后，无论用户在哪一台Windows客户端上登录，客户端都会自动从服务器上下载该用户的配置文件，然后在用户注销客户端时，将客户端上修改过的配置文件同步到服务器上，从这个基本功能可以看出两个主要特性，其一是自动同步，其二是增量更新。但是这两个主要特性在实际应用的环境中却经常遇到问题，当同一个用户先后在两个客户端上登录时，然后先后在这两个客户端上注销时，同步到服务器上的文件就出现了冲突。因为无法确定哪一个客户端上传的文件副本才是需要为用户保留的文件，既使用户在两个客户端分别操作的是不同的文件，甚至是不打开任何文件，直接登录后注销也会出现冲突，因为在两台客户端都有了一些配置文件的副本（例如注册表文件）。从这个场景中可以看出“通用”云存储产品应当具有解决或避免副本冲突的能力。
　　参考本地文件系统的具体实现，有三种常见的避免副本冲突的处理方案，实时同步、写锁定和日志式。
　　先看实时同步。简言之，当一个进程写文件时，另一个进程立刻就能读到所更新的内容。这个功能可以说是文件系统的基本功能，因为硬盘速度低于内存速度，所以使用内存作为硬盘的缓存可以提高访问速度，因此在两个进程同时访问同一个文件时，直接访问内存中的缓存即可，以至于会认为这是理所当然的事情。但是当这个同步需要跨越网络时，就需要面对网络速度远远慢于客户端中任何一个存储设备的情况，所以可以排除通过实时同步这个方案来避免副本冲突。但是在特定应用中，仍可以通过实时同步来避免副本冲突，例如Google Docs中，可以同时打开一个文档的多个副本，在每个副本中的修改，都会“实时”反映到另一个正在编辑的副本中，这样借助于特定应用本身的特性，就可以最大限度的避免副本冲突的问题，既便如此，仍无所避免所有的冲突，例如两个同户同时修改表格中的同一个单元格。
　　由于实时同步仍无法解决所有的副本冲突问题，所以文件系统中就有了写锁定。写锁定简言之就是当一个进程以写的方式打开文件时，禁止其他所有的进程以写的方式打开这个文件（本文不讨论共享、排他、阻塞、非阻塞等锁的具体类型，仅为了方便讨论类比）。这个功能在本地文件系统上能很方便的实现，但是在远程文件系统上却遇到了障碍，原因在于应用程序操作的是文件的本地副本，因此在不改造应用程序的前提下，就需要为写锁定和解除写锁定设计关联的事件。最直观的方案就是给有本地副本的文件增加写锁定，当删除本地副本时解除写锁定，但是这种方式又阻碍了只读的情况，因此首先可以排除这个方案。接下来可以考虑将所有的本地副本都视为只读，然后仅在应用程序打开文件时才锁定文件。这个方案首先要求客户端与服务器保持网络联接，这样才能在客户端监视到本地应用程序打开文件时即时通知服务器锁定文件。与本地文件系统一样，除了需要保持网络联接的条件外，这个方案面临的最大难题是互锁的情况，也就是当两个应用程序同时打开一些文件后，又要打开另一个应用程序已经打开的文件时，就会出现互锁的情况。此时只有禁止其中一个应用程序打开文件才能让另一个应用程序继续执行下去。这样被禁止的应用程序就有了无法保存的数据，虽然没有被禁止的应用程序可以在执行后解除写锁定。但是文件的内容已经发生了变化，被禁止的应用程序既便再写入，也必将覆盖另一个应用程序对该文件所做的修改。总之，在互锁的情况下，总会有一个应用程序所作的修改被丢弃。由于所有数据被丢弃的情况都和写锁定有关，因此可以通过检测写锁定来预防这种情况，将本地文件副本再制作一个副本。但是这个方案不仅失去了远程存储本身的意义，而且将导致越来越多的文件间数据不一致的情况。
　　既然写锁定仍有弊端，所以一些较新的文件系统就实现了日志式（Journal）。日志式文件系统的代表有Linux下常用的ext3fs和 Windows常用的NTFS。日志式文件系统用独立的日志文件跟踪磁盘内容的变化。就像关系型数据库（RDBMS），日志文件系统可以用事务处理的方式，提交或撤消文件系统的变化。本地文件系统通过日志式特性，可以在出现意外的情况下，保证文件系统的一致性，使文件系统具备“事务”特征。推广到网络上，通过记录“日志”，可以保证多个文件间的数据一致，在数据不一致的情况下，为人工干预提供足够多的仲裁信息。
　　经过以上分析可以看出，对具体应用程序不进行改造的前提下，“通用”云存储产品将无法避免出现人工参与进行仲裁的情况。下面分析在允许人工仲裁时，需要考虑的情况。此时可以类比版本管理工具，例如CVS，SVN等。
　　1. 没有关闭应用程序的情况。如果应用程序修改了部分文件，而没有修改另外的部分文件时，通过人工仲裁可以保证上传数据是一致的，避免上传数据不一致的情况。
　　2. 两阶段提交。当人工参与仲裁时，就可以将文件分成两个阶段提交，第一阶段将所修改的文件上传到服务器端，第二个阶段同时更新这些文件，如果出现了潜在的文件不一致的情况，由人工决定全部放弃还是全部覆盖。
　　3. 版本化。在两阶段提交的基础上，可以将文件标记版本，通过人工参与仲裁，可以保证每个版本中的文件是一致的。
　　前面是从人工参与云存储产品部分仲裁的角度来分析，下面通过人工参与应用程序部分仲裁的角度来分析各种应用程序在“通用”云存储产品上人工参与仲裁的情况。
　　1. 操作单一文本文件的应用程序。由于操作单一文件，所以不会有多个文件间不一致的情况，由于是文本格式，可以在出现冲突时使用文本合并工具人工参与仲裁（合并）。
　　2. 操作单一非文本文件，而且支持合并的应用程序（例如Microsoft® Word）。由于操作单一文件，所以不会有多个文件间不一致的情况，由于工具本身支持合并，可以在出现冲突时使用工具人工参与仲裁（合并）。
　　3. 操作单一非文本文件，而又不支持合并的应用程序。由于操作单一文件，所以不会有多个文件间不一致的情况，但是工具不支持合并，所以在人工参与仲裁时，只能选择保留其中的一个版本。
　　4. 操作多个文件的应用程序。由于同时操作多个文件，所以在人工参与仲裁时，不仅只能选择保留其中的一个版本，而且需要了解较多的应用程序知识，才能保证给文件标记版本时，同一个版本的不同文件是一致的。
　　在讨论了这么多的局限性之后，那么“通用”云存储产品的市场又将在什么地方呢？
　　1. 灾难恢复。虽然人工仲裁的成本很高，但是相对于数据丢失而言，仍是值得的，所以现有的数据存档服务可以发展成为“通用”云存储产品。
　　2. 手持设备。由于手持设备的移动特征，通过物理连接和电脑传输文件的局限性很大。借助于“通用”云存储产品将解决这个问题。
　　在面对市场时，“通用”云存储产品仍需要解决下面这些问题。
　　1. 大文件的断点传输。特别要将大文件的断点传输和人工参与仲裁相结合。
　　2. 大文件的增量传输。既便有了断点续传。大文件的上传和下载仍将耗费较长的时间，此时应当有增量传输的功能，每次只传输大文件中修改的部分。
　　3. 支持通用协议。为了解决上述问题。“通用”云存储产品需要设计专用的协议，因此客户端也要安装有相应的软件。在不便于安装软件、或者还没有开发出客户端软件的客户端上，应当支持通过通用协议访问部分功能，例如HTTP协议、FTP协议、IMAP协议等等。
　　4. 在线编辑。对于可识别文件类型的情况，“通用”云存储产品应当支持通过浏览器进行在线编辑。
　　5. 加密。敏感数据的托管存放始终是不可回避的问题。对于敏感数据而言，泄密造成的损失甚至会高于丢失造成的损失。特别是在云存储机制已经最大限度的减少了丢失数据的可能性之后，敏感数据的加密显得尤为重要。
　　最后关于本文的讨论，需要特别说明的是：
　　1. 本文的着眼点不是讨论网络文件系统技术规格，因此并不涉及具体的文件系统技术标准（例如POSIX标准中的文件系统部分）

　　2. 本文涉及具体的产品，但云存储并不是这些产品的设计初衷，因此相关的评价不代表对这些产品在其专用领域的评价
　　3. 本文标题是为了使本文所讨论的内容具体化、形象化，并不是对该问题的全面论述