比较好的网站建设品牌升级,成都专业做网站公司有哪些,网站服务器怎么更换,网站在线支付接口申请文章目录 计算高可用存储高可用高可用状态决策小结 今天#xff0c;我们聊聊复杂度的第二个来源高可用。
参考维基百科#xff0c;先来看看高可用的定义。 系统无中断地执行其功能的能力#xff0c;代表系统的可用性程度#xff0c;是进行系统设计时的准则之一。 这个定义… 文章目录 计算高可用存储高可用高可用状态决策小结 今天我们聊聊复杂度的第二个来源高可用。
参考维基百科先来看看高可用的定义。 系统无中断地执行其功能的能力代表系统的可用性程度是进行系统设计时的准则之一。 这个定义的关键在于“无中断”但恰好难点也在“无中断”上面因为无论是单个硬件还是单个软件都不可能做到无中断硬件会出故障软件会有 bug硬件会逐渐老化软件会越来越复杂和庞大……
除了硬件和软件本质上无法做到“无中断”外部环境导致的不可用更加不可避免、不受控制。例如断电、水灾、地震这些事故或者灾难也会导致系统不可用而且影响程度更加严重更加难以预测和规避。
所以系统的高可用方案五花八门但万变不离其宗本质上都是通过“冗余”来实现高可用。通俗点来讲就是一台机器不够就两台两台不够就四台一个机房可能断电那就部署两个机房一条通道可能故障那就用两条两条不够那就用三条移动、电信、联通一起上。高可用的“冗余”解决方案单纯从形式上来看和之前讲的高性能是一样的都是通过增加更多机器来达到目的但其实本质上是有根本区别的高性能增加机器目的在于“扩展”处理性能高可用增加机器目的在于“冗余”处理单元。
通过冗余增强了可用性但同时也带来了复杂性我会根据不同的应用场景逐一分析。
计算高可用
这里的“计算”指的是业务的逻辑处理。计算有一个特点就是无论在哪台机器上进行计算同样的算法和输入数据产出的结果都是一样的所以将计算从一台机器迁移到另外一台机器对业务并没有什么影响。既然如此计算高可用的复杂度体现在哪里呢最简单的单机变双机为例进行分析。先来看一个单机变双机的简单架构示意图。 你可能会发现这个双机的架构图和上期“高性能”讲到的双机架构图是一样的因此复杂度也是类似的具体表现为
需要增加一个任务分配器选择合适的任务分配器也是一件复杂的事情需要综合考虑性能、成本、可维护性、可用性等各方面因素。任务分配器和真正的业务服务器之间有连接和交互需要选择合适的连接方式并且对连接进行管理。例如连接建立、连接检测、连接中断后如何处理等。任务分配器需要增加分配算法。例如常见的双机算法有主备、主主主备方案又可以细分为冷备、温备、热备。
上面这个示意图只是简单的双机架构我们再看一个复杂一点的高可用集群架构。 这个高可用集群相比双机来说分配算法更加复杂可以是 1 主 3 备、2 主 2 备、3 主 1 备、4 主 0 备具体应该采用哪种方式需要结合实际业务需求来分析和判断并不存在某种算法就一定优于另外的算法。例如ZooKeeper 采用的就是 1 主多备而 Memcached 采用的就是全主 0 备。
存储高可用
对于需要存储数据的系统来说整个系统的高可用设计关键点和难点就在于“存储高可用”。存储与计算相比有一个本质上的区别将数据从一台机器搬到到另一台机器需要经过线路进行传输。线路传输的速度是毫秒级别同一机房内部能够做到几毫秒分布在不同地方的机房传输耗时需要几十甚至上百毫秒。例如从广州机房到北京机房稳定情况下 ping 延时大约是 50ms不稳定情况下可能达到 1s 甚至更多。
虽然毫秒对于人来说几乎没有什么感觉但是对于高可用系统来说就是本质上的不同这意味着整个系统在某个时间点上数据肯定是不一致的。按照“数据 逻辑 业务”这个公式来套的话数据不一致即使逻辑一致最后的业务表现就不一样了。以最经典的银行储蓄业务为例假设用户的数据存在北京机房用户存入了 1 万块钱然后他查询的时候被路由到了上海机房北京机房的数据没有同步到上海机房用户会发现他的余额并没有增加 1 万块。想象一下此时用户肯定会背后一凉马上会怀疑自己的钱被盗了然后赶紧打客服电话投诉甚至打 110 报警即使最后发现只是因为传输延迟导致的问题站在用户的角度来说这个过程的体验肯定很不好。 除了物理上的传输速度限制传输线路本身也存在可用性问题传输线路可能中断、可能拥塞、可能异常错包、丢包并且传输线路的故障时间一般都特别长短的十几分钟长的几个小时都是可能的。例如2015 年支付宝因为光缆被挖断业务影响超过 4 个小时2016 年中美海底光缆中断 3 小时等。在传输线路中断的情况下就意味着存储无法进行同步在这段时间内整个系统的数据是不一致的。
综合分析无论是正常情况下的传输延迟还是异常情况下的传输中断都会导致系统的数据在某个时间点或者时间段是不一致的而数据的不一致又会导致业务问题但如果完全不做冗余系统的整体高可用又无法保证所以存储高可用的难点不在于如何备份数据而在于如何减少或者规避数据不一致对业务造成的影响。
分布式领域里面有一个著名的 CAP 定理从理论上论证了存储高可用的复杂度。也就是说存储高可用不可能同时满足“一致性、可用性、分区容错性”最多满足其中两个这就要求我们在做架构设计时结合业务进行取舍。
高可用状态决策
无论是计算高可用还是存储高可用其基础都是“状态决策”即系统需要能够判断当前的状态是正常还是异常如果出现了异常就要采取行动来保证高可用。如果状态决策本身都是有错误或者有偏差的那么后续的任何行动和处理无论多么完美也都没有意义和价值。但在具体实践的过程中恰好存在一个本质的矛盾通过冗余来实现的高可用系统状态决策本质上就不可能做到完全正确。下面我基于几种常见的决策方式进行详细分析。
独裁式
独裁式决策指的是存在一个独立的决策主体我们姑且称它为“决策者”负责收集信息然后进行决策所有冗余的个体我们姑且称它为“上报者”都将状态信息发送给决策者。 独裁式的决策方式不会出现决策混乱的问题因为只有一个决策者但问题也正是在于只有一个决策者。当决策者本身故障时整个系统就无法实现准确的状态决策。如果决策者本身又做一套状态决策那就陷入一个递归的死循环了。
协商式
协商式决策指的是两个独立的个体通过交流信息然后根据规则进行决策最常用的协商式决策就是主备决策。 这个架构的基本协商规则可以设计成
2 台服务器启动时都是备机。2 台服务器建立连接。2 台服务器交换状态信息。某 1 台服务器做出决策成为主机另一台服务器继续保持备机身份。
协商式决策的架构不复杂规则也不复杂其难点在于如果两者的信息交换出现问题比如主备连接中断此时状态决策应该怎么做。
如果备机在连接中断的情况下认为主机故障那么备机需要升级为主机但实际上此时主机并没有故障那么系统就出现了两个主机这与设计初衷1 主 1 备是不符合的。 如果备机在连接中断的情况下不认为主机故障则此时如果主机真的发生故障那么系统就没有主机了这同样与设计初衷1 主 1 备是不符合的。 如果为了规避连接中断对状态决策带来的影响可以增加更多的连接。例如双连接、三连接。这样虽然能够降低连接中断对状态带来的影响注意只能降低不能彻底解决但同时又引入了这几条连接之间信息取舍的问题即如果不同连接传递的信息不同应该以哪个连接为准实际上这也是一个无解的答案无论以哪个连接为准在特定场景下都可能存在问题。 综合分析协商式状态决策在某些场景总是存在一些问题的。
民主式
民主式决策指的是多个独立的个体通过投票的方式来进行状态决策。例如ZooKeeper 集群在选举 leader 时就是采用这种方式。 民主式决策和协商式决策比较类似其基础都是独立的个体之间交换信息每个个体做出自己的决策然后按照“多数取胜”的规则来确定最终的状态。不同点在于民主式决策比协商式决策要复杂得多ZooKeeper 的选举算法 Paxos绝大部分人都看得云里雾里更不用说用代码来实现这套算法了。
除了算法复杂民主式决策还有一个固有的缺陷脑裂。这个词来源于医学指人体左右大脑半球的连接被切断后左右脑因为无法交换信息导致各自做出决策然后身体受到两个大脑分别控制会做出各种奇怪的动作。例如当一个脑裂患者更衣时他有时会一只手将裤子拉起另一只手却将裤子往下脱。脑裂的根本原因是原来统一的集群因为连接中断造成了两个独立分隔的子集群每个子集群单独进行选举于是选出了 2 个主机相当于人体有两个大脑了。 从图中可以看到正常状态的时候节点 5 作为主节点其他节点作为备节点当连接发生故障时节点 1、节点 2、节点 3 形成了一个子集群节点 4、节点 5 形成了另外一个子集群这两个子集群的连接已经中断无法进行信息交换。按照民主决策的规则和算法两个子集群分别选出了节点 2 和节点 5 作为主节点此时整个系统就出现了两个主节点。这个状态违背了系统设计的初衷两个主节点会各自做出自己的决策整个系统的状态就混乱了。
为了解决脑裂问题民主式决策的系统一般都采用“投票节点数必须超过系统总节点数一半”规则来处理。如图中那种情况节点 4 和节点 5 形成的子集群总节点数只有 2 个没有达到总节点数 5 个的一半因此这个子集群不会进行选举。这种方式虽然解决了脑裂问题但同时降低了系统整体的可用性即如果系统不是因为脑裂问题导致投票节点数过少而真的是因为节点故障例如节点 1、节点 2、节点 3 真的发生了故障此时系统也不会选出主节点整个系统就相当于宕机了尽管此时还有节点 4 和节点 5 是正常的。
综合分析无论采取什么样的方案状态决策都不可能做到任何场景下都没有问题但完全不做高可用方案又会产生更大的问题如何选取适合系统的高可用方案也是一个复杂的分析、判断和选择的过程。
小结
今天我们聊了复杂度来源之一的高可用分析了计算高可用和存储高可用两个场景给出了几种高可用状态决策方式希望对你有所帮助。 【星猿杂谈】在这里我们共同探索科技新趋势分享积累的点滴从编程语言到系统架构从人工智能到高性能计算我们追求技术的进步同时珍视分享的力量。欢迎关注我们在技术的精彩世界中一起遨游发现更多未知
