3、高可用集群（HAC）/04、尚硅谷-Linux云计算-集群- 高可用集群/13、尚硅谷-Linux云计算-集群-高可用集群说明

大家好。欢迎大家继续收看上硅谷的云计算视频，我是万阳老师。这节课呢，我们去给大家去讲解我们的高可用集群。那之前呢，我们已经把我们的负载均衡集群已经讲解完毕。那首首先我们先看一下我们等会要去讲解的几个不同的分类。第一个。高可用集群的说明。主要是想给大家描述一下我们高可用集群的必要性。那第二个keep alive的原理。那k live呢，是我们在实现高可用集群的时候比较常用的这么一种方案，所以我们要先了解它的原理，然后再去通过第三节的iOS的D模式加开live，给大家去构建一个完完整的高可用集群。第四个T加enx。黑B呢，也是我们另一款的高可用软件，拿它呢去跟indis结合，去实现一个ins这个软件的高可用。

也就意味着我们会有不同的高可用方案的构建。如果大家以后在生产环境中可以去选择去采取哪一款模式去使用。我们先看第一节。高可用集群的说明。那。首先我们之前也说过了一些高可用的一些特性了，在这里再给大家回顾一下。首先我们之前说过，高可用的主要目的呢，它是为了尽可能的。提高。服务的可用性对吧。首先什么叫尽可能呢？我们之前也说过一个概念，就是两个九标准，三个九标准，四个九标准，五个九对吧，那基本上我们用软件就能构建到三个九标准。两个九才是我们最基础的，如果两个角度保证不了的话，你不配调高和用户环境，能理解我的意思吧，那四个九呢，可能需要我们的一些硬件设备的参与了，那五个九呢，可以说是一个理论上的概念了。

你需要整个IDC的配合，包括你的网络供应商的配合，包括我们整个集群配置的配合，包括你的开发配合，很难做到。那举个例子。比如某度宣传的质体是99.999999%高可溶性。那结果有一次一下午宕机，百度云宕机了一下午，大家可以自己去算一下。到底这个可用性维持在多少对吧。好，所以我们的高可用一般维持在三个九，是属于一个比较呃中心公司可能比较倾向的一种方案，原因是我们的可用性越高，它背后带来的资金成本就会越高。假设我现在开了一家公司，每天的访问量可能只有几百个人。那么小时我的损失带来的，带来的资金可能只有几百块钱，结果我花了上千万就构建了一个四个九标准的这么一个集群，你觉得合适吗？

对吧，所以所以还是那句话，适合自己的才是真正的好集群，没有什么所谓的固定集群模式。那还有就是我需要说明的就是高可用集群它的实现原理还记得吗？就是我们的心跳检测对吧。那知道这些我们的最基础的概念以后，我们再去看我们的高可用集群。那首先我们先看一下我们之前构建的一个iOS的拓扑结构，这应该看这种方式应该是我们的那模式，这个大家要相信大家都能分辨出来对吧，那如果是。DR模式的话应该放在这里对吧，那的模式的话，充当我们的真实服务器和客户端之间的这么一个角色。那先问大家第一个问题。这么几个节点客户端我们不考虑对吧，不属于我们的服务器，那这么几个节点。

如果阿帕奇宕机会怎样？访问会中断。原因是什么？如果我们采用的轮询算法的话，交给他没问题，交给他没问题，交给他，诶，结果服务不在了，那这个用户的访问连接就中断了。其实iOS做不到检测功能。其实我们正常的一个负载均衡集群，应该包括后端健康状态检测，也就如果有它，有一天我判断这个阿帕奇死了的话，能自动把它剔除出去。但这里的默认的iOS是做不到的。那如果我们就想只采用我们的iOS机群做到这个功能怎么办呢？可以自己写一个小脚本。那在这里呢，我花了一点时间给大家写了一个小脚本，那这是我们上节课构建的这么一个nat模式的这么一个iOS的集群，对吧？那现在我先还原一下我们外IPSIDM。

IBIM杠，我们可以看到。我们的持续化连接已经没有了，对吧，因为我持做持续化连接以后我没有保存，那我重启以后会还原到之前的。那我现在去访问，我们现在这个集群刷新是不是能跳转啊。那如果有一天我们的UR死了，比如iddd stop。这里不太好解释，原因是什么呢？我们的浏览器有缓存，看在这里转圈了。对吧，好，那从哪里可以判断呢，你会发现。这里是不是依然在存在？也就意味着，如果我们应该做到的事情就是当当幺二在台服务器检测他死了以后能把它剔出去，我的子节列列表里应该只留一个幺三，而不是现在幺二还在。那我们知道这个实现原理以后，是不是就可以比较容易的通过脚本的方式把它给构建出来了呢？给大家看一下我们的这个小脚本。

定义了我们的集群地址，定义了我们集群端口，定义了本地红花以及真实服务器那定义转换我们的数组态以及我们的循环算法，轮续算法。底下呢，定义了我们的工作方式，工作集群的端口以及从事检测次数，以及我们当前的循环日志。然后定义了几个函数，分别是添加以及删除以及检测。那给大家讲，给大家简单讲一下我写这个脚本的一个最基础的思想。循环呢，去判断我们当前拥有的真实服务器的节点，它的状态。是否正常？如果正常静默。等待下一个式循环。如果不正常，或删除或添加。这就是这个脚本的功能。那如果大家学了一些Python语言或购物语言的话，用购物语言可能写起来。更好一点，原因是他是不是贴身之时多线程啊。

对吧，好，那我们把这个复制一下，我们看看能不能实现。YM，最好我们再去写脚本的时候，把它放在一个比较常见的一个目录下，不要把脚本到处去扔，到时候你都找不到对吧？那我的习惯是在UR local下创建一个script脚本目录，然后感叹号到了服。我们进到这个目录下，我们就写一个叫check。Is。叫real。点SH。好。那我们去把它里面的一些关键字给修改一下，我的集群IP是20.20.20.1。端口八零没问题，没问题，真实服务器分别是幺二和幺三。好群端口八零没问题，我们当天是我们的纳塔模式M'M好检测次数三次保存退出。

那change I加X check iOS。给他一个执行权限，对吧，那我们拜。Check。它是一个占用我们的前端守护的进程的，对吧？啊占用我们前端窗口的，那所以呢，我们先打开一个窗口，我们看一下，我们看一下效果，刚才你会发现幺二已经没了。看到了吗，为什么？一号刚才服务器是不是被我停了，脚本循环检测我们的web服务器是否正常的时候，检测它不正常是不是就会把它删除。那有一天这时候理论上应该怎么办？理论上我们的监控服务器应该开始报警了，说哎，你的幺二外部服务器死了，赶紧去救一下。那作为运营员来说，我接收到我们的报警请求以后，我去把它的服务给恢复，那start。那C。Local house，我们看到服务已经正常了，对吧。

那你会我们再看一下，诶，幺二又回来了。那如果iOS加上我们的这个脚本以后，那是不是就证明。我们的这两台或者这三台服务器，任何一台的死亡都不会造成我们的访问中断。是不是已经over了？那这个脚本我也会提供给大家，有兴趣的话可以用自己的啊，可以学习隐瞒，比如Python，对于我们的go。对于我们的运维啊，帮助还是比较大的，可以用这种语言类似的去按照我的逻辑把它给描述出来即可，对吧。这个脚本还是比较粗糙的，好，那接下来我们继续往后看。既然这三个阿帕奇任何一台死亡都没问题了。那我又会有一个问题，就是这里是不是还有个MS呢？如果他死了呢？你会发现我们中间已经没有继承者了，对吧？那这样的话是不是就会带来一个很大的问题，什么很大的问题啊。

不管后面多台，三台还是1000台，还是1万台。他们哪怕再健康。我们的iOS死了。我们的FS死了，红了。这三台再健康都白搭。所以对于我们is集群来说，其实is的高混用本身的高可用是非常重要的一个概念。那怎么办呢？我们就可以通过我们的高可用技术把iOS做替换。或者做一个副本。它俩之间就像咱们之前说的一样，高可用的原理，心跳检测。正常客户端的请求会请到is组上。那负载到不同的集群下，那如果有一天iOS主器械了。从iOS就会接替，那客户端的访问会转移到从iOS去代理到不同节点。这个就是我们的。高负载均衡高可用的啊，负载均衡加我们的高可用的这么一种实现方案。

那这个相信大家已经给大家讲明白了，对吧，但还要注意一点就是其实高可用，高可用也是有不同分类的。我这里说的分类，不再是我们的软件上的分类，而是我们的实验原理上的分类。服务，我们一般把它讲成这两个，一个叫做我们的什么。有状态，一个叫无状态。还记得谁是有状态，谁是无状态吗？无状态，我们讲的标准协议是不是就IP啊，所以阿帕奇。比如iOS。这些我们都可以把它理解为是无状态，那有状态是谁啊，满circle。典型的有状态服务。也就意味着，如果把阿帕奇给删了，IOS给删了，我在N段时间之后，只要配置一样把它给添加上，其实它们的功能上没有完全没有任何区别。

那对于买SQ来说呢，如果我把数据库运行运行啪给它断了，过一会再加进来。那他的数据是不是已经可能比其他的数据库缺少了不少的东西？那可能造成我们的一些服务中断或者是错误，对吧，那对于我们的服务实现高可用的话，其实无状态更容易去实现高可用。有状态是比较难实现高可用的，因为你想要把它一些数据给恢复。那这里我们典型讲的是iOS的有状态服务啊，通过iOS的无状态服务去。那这里我们讲的是LY的无状态服务的这么一个高复方案。那当然有状态服务呢，我们如果有时间的话，也可以再给大家添加上，比如拿我们的呃，MFS加k live。加我们DDB，实现我们有状态服务的高可用，这是完全没有问题的。

这个呢，就是我们的一个高可用集群，为什么需要它的一个说明，以及iOS我们的nat模式加上脚本以后，怎么去实现我们的子节电的可用性。相信已经给大家说清楚了，对吧，好。那这节课我们就先到这里。再见。