Dark Side of Cloud Storage:多副本 vs. 主从

保障一个在线系统的可靠性和可用性的常用基本手段是多副本和主-从两种方案。这两种方案都的核心目的是消除单点。单点就是在一个系统中,某一个服务,或者功能模块,只有一个实例在运行。造成的问题就是,一旦这个实例下线,那么整个系统将会宕机;一旦这个实例丢失数据,那么整个系统将丢失数据。

消除单点的手段不外乎增加实例数,也就是我们常说的“冗余”。但是冗余并没有那么简单。有些服务或模块没有持久化的状态(通俗地讲,不保存数据),增加冗余很容易,按要求多重部署即可。但如果服务或模块需要保存数据,那么问题就复杂了。人们在实践中发展出两种常用的冗余方案:主-从和多副本。

多副本方案很直观:不想要单点,那就增加数据的份数,坏了一个,还有其他的。但是,考虑到服务下线或者损坏,多个副本之间数据可能不一样。我们无法确定从一个副本上读到的数据是最新的。因为任何一次对多个副本的数据写入,都无法保证都成功。这就是我们常说的"一致性"问题。要得到正确的数据,必须整合所有的副本。通常的处理手段是规定成功写入的副本数必须超过某个数量,成功读取的份数也必须超过某个数量。只要两个数值设定合理,就能确保读取到最新的数据。

主-从方案更容易理解:用额外的从服务器不停地备份主服务器的数据,主服务器宕了或者数据丢了,从服务器可以接替主服务器,继续工作。主从之间的数据备份有两种方式:异步备份和同步备份。异步模式下,数据写入主服务器后,随即向客户端反馈成功。随后在恰当的时候,数据被同步到从服务器中。同步备份是说数据写入主服务器后,主服务器将数据转发至从服务器,当从服务器也写入成功,再向客户端反馈成功。

显而易见,异步主从备份无法保证可靠性。因为主服务器丢失数据的时候,总会有一些数据没有来得及备份到从服务器,这些数据就永远丢失了。

因此,同步数据备份比一部数据备份更好地保证可靠性。每次正确的写入都会有两份数据存在。主服务器宕机,从服务器那边还有另一份。(当然,实际情况远比这复杂得多,这里就不展开了)。同步数据备份的一大问题是性能。数据写入请求要通过主服务器转发到从服务器,并获得反馈,才能响应用户。大幅增加了请求的延迟。

现在,我们先抛开性能问题,看看其他方面。可靠性之后,我们还得考虑可用性。同步写的模式要求主和从服务器都写入成功,才能告诉客户成功。因此,当主从两台服务器有任何一台下线,系统就不可用。如果放松要求,从服务器不一定要写成功,那么有些数据只有主服务器上的一份数据,依然会丢失数据。

为了保证可靠性的同时,提高可用性,一个合理的选择是增加从服务器的数量,比如2台、3台,甚至5台。不一定要每台从服务器都写成功,只要保证有1台,保险点2台从服务器写入成功,便反馈客户数据以妥善保存。如此。可以保障足够的可靠性,而可用性也不会受到单台服务器下线的影响。

(Bad feelings I have about this, huh)

接下来的问题是一致性。主从模式最大的好处就是不用操心一致性问题,因为主服务器的数据都是成功写入的。同用户的视角一致。

真的是这样么?一般情况下,或者说没有异常情况的时候是这样。当主服务器出现问题,比如硬件失效,或者系统崩溃,那么就需要将一台从服务器升格为主服务器,以确保系统可用。

但是,前面说过了,从服务器并不一定要每次都写成功。于是,从服务器升格而来的主服务器可能数据不完整。相比原来的主服务器少了数据。在用户眼里,此时的系统丢了数据。尽管实际上数据还在,只是不在当前的主服务器上。

现在我们来解决这个问题。问题的根源是从服务器的数据和主服务器不一致,最直接的解决方法是设法让它们一致。主服务器在向从服务器作同步写的时候,可以多试几次,提高成功率。但是,终究还是有怎么重试也无法成功的时候。如果就此作罢,那么数据不一致的情况依然存在。如果一直这么重试下去,就无法响应用户。唯一的做法是反馈用户,同时接着重试。为减少系统的复杂性,通常会将这后续的重试操作放在一个单独的服务模块里异步地执行。但是,重试这个步骤无论在主逻辑,还是在异步的独立模块中执行,都无法保证完全成功。系统各类异常会打断重试的努力。甚至会丢失重试任务。重试这个failover过程本身会fail。那么如果要保证failover能够正确及时的执行,那么就必须处理好failover的failover。按这个逻辑下去,还有failover的failover的failover...。没底了。所以,实际上是无法保证主从服务器的数据完全一致,而不影响可用性。这条路是走不通的。

那么,我们退而求其次,容忍主从服务器的数据不一致,寻找消除数据不一致的问题。前面提到,我们不一定要每台从服务器的每次写入都成功,只需要保证有一定数量的从服务器成功即可。所以,多台从服务器的数据整合起来,就可以确保同主服务器一致。这样的话,一旦主服务器宕机,从服务器升格为主服务器,新的主服务器每收到一个数据读取的请求,就去从服务器那里把相应的数据都取来,同自己的数据一起比对,找出正确的那份数据,返还给用户。

等等,这不就变成了多副本的方案么?的确如此。根本而言,主-从方案同时满足可靠性、可用性和一致性的前提是没有服务器宕机。这本身就违背了“任何东西都会失效”这个基本事实。(更血腥的事实是“任何不可能发生的事情也会发生”,而且总是在你认为不会发生的时候发生)。而且,主-从方案的一致性基准是建立在主服务器上的,在发生了主从服务器切换之后,整个集群就失去了一致性基准,从而被迫在所有主-从服务器上寻求一致性。而多副本方案一开始就明确服务器是不可靠的,单台服务器的数据是不可能完整和准确的。整个系统的可靠性、可用性和一致性建立在所有服务器数据整合之上。

在接受了“任何东西都会失效”这个前提之后,我们看到主-从方案也不得不综合所有服务器的数据,以便获得一致性。这也等同于多副本方案,但却要付出更多的代价,比如主-从切换逻辑,多一次主从转发的数据访问延迟。

但是,多副本方案并非完美。通常它只能用于非常简单的数据存储结构和数据操作逻辑,比如map和插入/删除等简单操作。涉及多个数据的操作,非幂等的操作,或者带有事务的操作,使得各副本间的一致性比对非常困难。

对于可靠性可用性要求不高的场景,我们往往只能退而求其次,使用主-从模式,以牺牲可靠性、可用性为代价,确保业务逻辑得以实现。在使用主-从方案时,我们通常会设法提高设备的可靠性,比如使用RAID,减少出错的概率。

有时,我们对于可靠性、可用性和一致性的要求非常高,主-从方式无法满足。那么,只能改变业务逻辑,将其简化成能够适用于多副本架构的形式。大型对象存储对可靠性、可用性和一致性有极高的要求,(它是在线服务的服务,依赖可靠性和可用性赚钱,此处绝对马虎不得)。因而不得不放弃任何复杂的数据操作,将其简化到适应多副本存储的形态。所以说大型对象存储系统采用<key,value>的形式,并非是自愿,或者睿智的,完完全全是被迫的。云存储系统不可避免地采用多副本的方案。

多副本和主-从方案之间的比较问题是非常典型云计算问题(或者说“坑”)。很多方案在单独考虑某一种需求,比如可靠性,或者可用性,都可以应付。但一旦将这些需求综合在一起考虑,这些方案将会遇到各种障碍。另一方面,一个在线系统的方案,不仅仅考虑在一般情况下的功能实现,必须时刻考虑在异常情况出现时,可能遇到的各种问题。后者占据了云计算系统架构和设计的7、8成工作量。换句话说,云计算系统成功的难易程度,取决于你躲过了多少"坑"。


展开阅读全文

没有更多推荐了,返回首页