迪庆公司网站开发方法,全球电商平台排行榜,网络推广外包公司一般在哪里招聘,网站成品免费下载本部分主要是问题引入#xff0c;以及给出一个解决方案
1 脑裂#xff08;Split Brain#xff09;
replication system的共同点#xff1a;单点
前面几个容错特性#xff08;fault-tolerant#xff09;的系统#xff0c;有一个共同的特点。
MapReduce复制了计算以及给出一个解决方案
1 脑裂Split Brain
replication system的共同点单点
前面几个容错特性fault-tolerant的系统有一个共同的特点。
MapReduce复制了计算但是复制这个动作或者说整个MapReduce被一个单主节点控制。GFS以主备primary-backup的方式复制数据会实际的复制文件内容但它也依赖一个单主节点来确定每一份数据的主拷贝的位置。VMware FT在一个Primary虚机和一个Backup虚机之间复制计算相关的指令。当其中一个虚机出现故障时为了能够正确的恢复需要一个Test-and-Set服务来确认Primary虚机和Backup虚机只有一个能接管计算任务。
它们都是一个多副本系统replication system背后存在一个共性它们需要一个单节点来决定在多个副本中谁是主Primary。使用一个单节点的好处是它不可能否认自己因为只有一个节点它的决策就是整体的决策缺点是它本身又是一个单点故障Single Point of Failure将系统容错的关键点转移到了这个单点上。在系统出现局部故障时通过primary copy继续工作。使用单点是为了避免脑裂Split-Brain。当出现故障时要极其小心的决定数据的主拷贝否则需要面临脑裂的场景。 这里主要说明多副本系统虽然是多副本但是最终还是搞了一个单点来做决定而这样做的目的是为了避免脑裂同样单点故障又可以通过新的primary继续工作。 下面通过示例可以得知如果是多副本系统要么同时等待所有副本响应这样还不如单点因为多个是一个出现问题的多倍要么不等待多个那这样就会出现脑裂根源也很简单在分布式系统中根本无法确定你连接不上的这个服务到底是宕机了还是仅仅你连接不上而其它服务可以。 脑裂带来的问题及其严重性
这里通过将单点Test-and-Set服务设计为多副本说明为什么出现故障时很难避免脑裂。 VMware FT中的Test-and-Set之前是一个单点服务而VMware FT依赖这个Test-and-Set服务来确定Primary虚机为了提高系统的容错性构建一个多副本的Test-and-Set服务。网络里面有两个服务器S1S2都是Test-and-Set服务的拷贝还有两个客户端C1C2它们需要通过Test-and-Set服务确定主节点是谁。在这个例子中这两个客户端本身就是VMware FT中的Primary和Backup虚拟机。 这两个Test-and-Set服务器中的数据记录将从0开始任意一个客户端发送Test-and-Set指令这个指令会将服务器中的状态设置成1两个服务器都应该设置成1然后将旧的值0返回给客户端。本质上来说这是一种简化了的锁服务。 **当一个客户端可以与其中一个服务器通信但是不能与另一个通信时有可能出现脑裂的问题。**假设客户端需要将请求同时发送给两个服务器。这时就需要考虑脑裂问题即会出现各种情况的网络分区以及服务器不响应需要如何处理。
如果我们只将C1的请求设置给S1而不设置给S2会导致S2的数据不一致。或许应该规定对于任何操作客户端必须总是与两个服务器交互而不是只与其中一个服务器交互。**但是这是一个错误的想法因为这里根本就没有容错甚至比只使用一个服务器更糟。**因为当两个服务器中的一个故障了或者失联了我们的系统就不能工作了。对于一个单点的服务我们只依赖一个服务器。现在我们有两个服务器并且两个服务器都必须一致在线这里的难度比单个服务器更大。如果客户端不能同时与两个服务器交互那它就与它能连通的那个服务器交互同时认为另一个服务器已经关机了。这也是一个错误的答案呢我们的故障场景是另一个服务器的状态无从知晓实际可能是网络线路出现了故障从而导致C1可以与S1交互但是不能与S2交互。同时C2可以与S2交互但是不能与S1交互。如果一个客户端连接了两个服务器为了达到一定的容错性客户端只与其中一个服务器交互也应该可以正常工作。但是这样就不可避免的出现了这种情况假设这根线缆中断了将网络分为两个部分。C1发送Test-and-Set请求给S1S1将自己的状态设置为1并返回之前的状态0给C1。C1对应的虚拟机会认为自己可以成为主节点。但是同时S2里面的状态仍然是0。如果现在C2也发送了一个Test-and-Set请求本来应该发送给两个服务器但是现在从C2看来S1不能访问根据之前定义的规则那就发送给S2吧。同样的C2也会认为自己持有了锁。如果这个Test-and-Set服务被VMware FT使用那么这两个VMware 虚机都会认为自己成为了主虚拟机而不需要与另一个虚拟机协商这是一个错误的场景。 这里主要是针对上面的共同点通过举反例说明单点的必要性。 实际上Lecture4中最后也提到 test and set 应该也是具有容错性的服务而不是某个单点。 **在有两个拷贝副本的配置中看起来我们只有两种选择要么等待两个服务器响应那么这个时候就没有容错能力要么只等待一个服务器响应那么就会进入错误的场景通常称为脑裂。**这基本是上世纪80年代之前要面临的挑战。多副本系统时需要排除脑裂的可能这里有两种技术
构建一个不可能出现故障的网络。比如电脑中连接了CPU和内存的线路就是不可能出现故障的网络。如果网络不会出现故障这样就排除了脑裂的可能。当网络不出现故障时那就意味着如果客户端不能与一个服务器交互那么这个服务器肯定是关机了。这里假设有足够多的资金就能接近这个假设。 主要还是只要有网络的情况下节点A和节点B连接异常但是B本身是什么样的节点B和其他节点是什么样的是未知的。 人工解决问题不要引入任何自动完成的操作。默认情况下客户端总是要等待两个服务器响应如果只有一个服务器响应永远不要执行任何操作。之后通过运维人员检查进行关机等处理这里本质上把人作为了一个决策器这个人也是个单点。
很长一段时间内人们都使用以上两种方式中的一种来构建多副本系统。这虽然不太完美因为人工响应不能很及时不出现故障的网络又很贵但是这些方法至少是可行的。
2 Majority Vote (quorum)
尽管存在脑裂的可能人们发现哪怕网络可能出现故障可能出现分区实际上是可以正确的实现能够自动完成故障切换的系统。这种能自动恢复同时又避免脑裂的多副本系统关键点在于多数投票Majority Vote。这也是用来构建Raft的一个基本概念。 网络分区Partition当网络出现故障将网络分割成两半网络的两边独自运行且不能访问对方。 多数投票系统的第一步在于服务器的数量要是奇数而不是偶数。如果只有两个服务器被网络故障分隔的两边它们看起来完全是一样的它们运行了同样的软件它们也会做相同的事情这样不太好会导致脑裂。但如果服务器的数量是奇数的那么当出现一个网络分割时两个网络分区将不再对称这是多数投票吸引人的地方。首先你要有奇数个服务器。然后为了完成任何操作例如Raft的Leader选举例如提交一个Log条目在任何时候为了完成任何操作你必须凑够过半的服务器来批准相应的操作。 如果是偶数会如何呢这里举两个例子 2副本那么如果分区就要等待过半投票即2/2 1 2也就是每一个都要等待2个的响应那这个和6.1中第二小节示例中的方案一必须与所有副本通信又有何区别反而提高了故障概率。4副本过半投票 4/213这里好一些了能够容忍1个的故障但是这和3副本相比并不能提高容错概率还不如之间5副本或者3副本浪费反而不会提高容错。 综上偶数情况下如果被网络故障均分那么整个系统依然是不可用的。
这里背后的逻辑是如果网络存在分区最多只有一个分区能够拥有过半的服务器。这里有一点需要明确当我们在说过半的时候我们是在说所有服务器数量的一半而不是当前开机服务器数量的一半。这个点困扰了我Robert教授很长时间如果你有一个系统有3个服务器其中某些已经故障了如果你要凑齐过半的服务器你总是需要从3个服务器中凑出2个即便你知道1个服务器已经因为故障关机了。过半总是相对于服务器的总数来说。 服务器的总数一是因为实际上很难完全知道具体出现故障的机器到底是怎么了另一方面是因为为了后面的过半更新过半选举这样选出来的leader一定包含有最新数据。 个人思考 这里的开机在有网络的情况下A连接不上B无法判断B是否开机B和C是否连接需要及时处理故障机需要提供快速的数据恢复 对于多数投票可以用一个更通用的方程式来描述如果系统有 2 * F 1 个服务器那么系统最多可以接受F个服务器出现故障仍然可以正常工作。这也被称为多数投票quorum系统因为3个服务器中的2个就可以完成多数投票。 有关多数投票系统的一个特性就是最多只有一个网络分区会有过半的服务器我们不可能有两个分区可以同时完成操作。这里背后更微妙的点在于如果你总是需要过半的服务器才能完成任何操作同时你有一系列的操作需要完成其中的每一个操作都需要过半的服务器来批准例如选举Raft的Leader那么每一个操作对应的过半服务器必然至少包含一个服务器存在于上一个操作的过半服务器中。任意两组过半服务器至少有一个服务器是重叠的。实际上相比其他特性Raft更依赖这个特性来避免脑裂。 例如当一个Raft Leader竞选成功那么这个Leader必然凑够了过半服务器的选票而这组过半服务器中必然与旧Leader的过半服务器有重叠。新的Leader必然知道旧Leader使用的任期号Term ID因为新Leader的过半服务器必然与旧Leader的过半服务器有重叠而旧Leader的过半服务器中的每一个必然都知道旧Leader的任期号。类似的任何旧Leader提交的操作必然存在于过半的Raft服务器中而任何新Leader的过半服务器中必然有至少一个服务器包含了旧Leader的所有操作。这是Raft能正确运行的一个重要因素。 在多数投票这种思想的支持下大概1990年的时候有两个系统基本同时被提出。这两个系统指出你可以使用这种多数投票系统从某种程度上来解决之前明显不可能避免的脑裂问题例如通过使用3个服务器而不是2个同时使用多数投票策略。两个系统中的一个叫做Paxos1989Raft论文对这个系统做了很多的讨论另一个叫做ViewStamped ReplicationVSR 1988。尽管Paxos的知名度高得多Raft从设计上来说与VSR更接近。VSR是由MIT发明的。 学生提问可以为Raft添加服务器吗 Rober教授Raft的服务器是可以添加或者修改的Raft的作者提出了方法来处理这种场景但是比较复杂。 参考文献 https://pdos.csail.mit.edu/6.824/schedule.html https://mit-public-courses-cn-translatio.gitbook.io/mit6-824/
