云存储的黑暗面：元数据保障(2)

主从模型

首先我们必须解决可靠性和可用性问题，尽可能保证保存下来的元数据不丢失，也尽可能让服务始终在线。这里有一个关键点：怎样才算保存下来?这个问题看似简单，实则至关重要。一般我们会认为所谓保存下来就是存储到磁盘或其他持久存储设备上。但在一个在线系统中无法以此界定。在一个在线服务中，数据完成保存是指明确向客户端反馈数据已经正确保存。一旦向客户端发出这样的反馈，那么便是承诺数据已经保存下来。在这个界定之下，元数据的可靠性保障则颇为复杂。

前面说过，元数据系统是一个数据库系统，保障数据库系统可靠性最常用手段就是主从模型(图2)，即读写主数据库，而主数据库将数据复制到从数据库，从而确保数据库没有单点。主从模型同时也保障了可用性，当主服务器下线时，从服务器可以切换成主服务器，继续提供服务。这样的保障手段对于一般的在线应用大体上够用了，但对于云存储的元数据而言，则存在诸多问题。其中缘由颇为复杂，让我们从最基本的可靠性开始。

主从模型是依靠主服务器向从服务器复制每次写入的数据，以确保数据存留不止一份。但这里有个同步和异步的问题。所谓“异步”是指主服务器完成数据写入之后，即刻向客户端反馈写入成功信息，然后在适当的时候(通常都是尽快)向从服务器复制数据。客户端得到保存完成的信息后便欢欢喜喜做后面的事情去了。而此刻相应的数据只有主服务器上保存着，如果发生磁盘损坏之类的问题，便会丢失那些尚未来得及复制到从服务器的数据。之后如果客户端来提取这条数据，服务端却无法给出，对存储系统而言，是很丢人的事。

即便没有发生硬件损坏的情况，依然可能丢失数据。由于硬盘之类的存储介质速度缓慢，无法跟上数据访问的节奏，所以数据库都会使用内存进行缓存。当服务器发生掉电或者崩溃，数据库发生非正常的退出时，都会造成缓存中没有写入磁盘的数据丢失，进而造成数据的丢失。

在存储系统长期的运行过程中，硬件肯定会坏，掉电必然会发生，系统也难保不会崩溃。所以这种异步的数据复制过程必然会有数据的丢失。这对于在线存储服务而言是无法容忍的。

既然异步存在这样的问题，那么同步地复制数据是否会好些呢?所谓“同步”是指主服务器完成数据写入后，并不立即反馈用户，而是先将数据复制到从服务器。等到从服务器正确写入，再向用户反馈数据写入完成。这样，任何时刻都会至少有两台服务器拥有某一条数据，即便一台服务器出了问题，也可以确保数据还在。如果有多台从服务器自然就万无一失了。

同步模式解决了可靠性问题，却引入了新问题。最基本的问题就是同步的数据复制造成延迟的增加：主服务器需要等待从服务器完成写入才能反馈。

让我们先放下性能问题，毕竟在线对象存储对于主从同步的延迟还没有那么敏感。剩下的问题则是根本性的。同步模式解决了可靠性问题，下一步需要考虑可用性问题。对于在线存储服务而言，必须要确保系统不受单点故障的影响。同步模式则恰恰受制于此。为了确保可靠性，必须主从服务器都写入成功，才能向用户反馈成功。如果从服务器下线，那么这个条件就被破坏，不得不向用户反馈失败，直到从服务器重新恢复。而当主服务器下线后，从服务器则设法升级为主服务器继续服务。但此时只有一台服务器，也不能满足数据不少于两份的要求。如果允许主从之间容忍从服务器的下线，那么可靠性又受到了削弱。这样产生了令人啼笑皆非的结果，主从模型是为了提高可靠性和可用性，现在反到受制于单点故障。

解决这一问题的方法也不是很难：增加从服务器的数量，并且允许主从复制失败。如此，当一台从服务器下线后，其他从服务器依然可以接收数据，确保任何时刻一份数据都至少拥有两个以上的副本，以维持可靠性。不过，具体操作上并没有那么简单，主从之间复制成功的数量必须满足一个阈值。这个阈值也必须满足一个条件才能保证数据一致性，关于这个要点后面会具体阐述。

又有新的问题出现。当主服务器下线时，一台从服务器便会被升级成为主服务器。但前面说了，为了可用性，并不要求主从服务器间的复制每次都成功，那么新的主服务器的数据可能是不完整的。这样对于用户而言，便会出现数据一致性的问题：原先成功写入的数据却读不到了，或者读到的都是很旧的版本，已被覆盖掉的东西。给用户造成的印象便是数据丢失了，这是严重的问题。

最直观的解决途径是设法补上那些数据。但考虑到元数据的量，这样的修补是无法在短期内完成的。另一个更复杂却真正有效的方法是读取数据时，同时读所有的服务器，不管主从。然后将所得的结果整合在一起，找出正确的版本。

事情还没有完结，存放在数据库中的数据经年累月地运行之后，会逐步退化。磁盘的失效，磁道的损坏，乃至人为的操作失误，都可能造成数据副本的丢失。换句话说，即便是主服务器，我们也无法完全保证数据的完整性和一致性。无论如何都无法回避主从服务器之间的一致性问题。

无论是主服务器，还是从服务器，终究需要对缺失的数据副本进行修补，否则数据的退化终究会造成数据的遗失。这种修补的过程也是困难重重，后面会进一步分析。

最后，最重要的就是运维。架构、设计、开发之类的都是短期过程，虽说系统需要不断演进，但毕竟都是阶段性的工作。而运维，则是持久的、不间断的任务。一个在线服务的正常运行最终还要依赖运维，运维决定了服务的品质。因此，一个设计方案的可维护性具有很高的优先级。

在可维护性方面，主从模型除了常规的系统维护事务外，还有很多额外的运维过程。主服务器下线，需要将某一台从服务器切换为主服务器，这个过程是一个运维过程。理论上，一个主从集群可以实现自动切换。但实际使用中，这种切换并不能确保成功，往往需要人为干预，切换失败也是常有的事。对于计划中的下线，如升级软硬件等，运维强度尚不算大，但对于软硬件故障造成的突发下线，主从切换往往是紧急运维事件。一旦失败，便是服务下线的大事故。其中充满了风险和不可控因素，并不利于存储服务的高可用。

一个在线系统的架构，最好的情况就是无论是正常运行，还是发生意外故障，都能够以同一种方式运行，无须额外的应急处理。用通俗的话说，在线系统必须能够不动声色地扛住局部异常，为运维人员赢得回旋处理的余地。对于云存储的元数据系统尤是如此。元数据位居关键路径，又存在持久化的状态，还受到各种特性要求的约束，它的架构着实是一项富于挑战的任务。