上篇讲了高性能：5分钟架构，聊透架构设计背后的道理
「画外音：持续更新中哟，先关注，别走丢了哈！」
读完上篇，你有回去琢磨自己所在的系统的高性能是怎么设计的么？用到了哪些方式？如果你想改善的话，从哪里下手？有哪些思路？可以留言跟大家一起沟通，好问题我也会第一时间回复你哟。
今天聊聊三高之一的「高可用」。
不仅高，还可*（激动了，字被自动隐藏了）
车门已焊死，别跑！我们严肃、正经地聊技术吧！
高可用，简单说就是，系统拥有一直持续执行它的功能的能力，且中途不会断，那就可以认为它的可用性程度非常不错，能做到这样的架构师，真心不容易，以前填过的坑可能比我吃的枸杞还要多。
但，系统这东西好比小熊养生壶，用久了也会裂的，哪儿有东西是一直完美的呀，好比我们很多同事不也一直在写 bug 嘛……更恐怖的是，某个模块的代码你眼看着他越写越多，某个系统的模块他越写越多……细思极恐！！总结如下：
硬件层面，机器宕机了；
软件层面，软件 bug；
不可抗因素，地震、电力系统故障、火灾、恐怖袭击等。
可怜的养生壶，陪了我2年多，还炖了辣么多的枸杞
其实，我们根本不可能做到不中断，天灾人祸，总有一天会让它停下来的，那我们要做点儿啥才能让这个风险降下来呢？其实，就跟小动物养育后代一样，为了保证物种基因能在这风云变幻的世界上延续下去，一般来说后代的个数都会很多，这样才能争取更多机会，俗称「冗余」，哈哈哈。
咱系统要保证高可用，冗余是必须的了，一台不够，就两台，不行就三台或者更多，像机房、电缆、通信通道等等，都是一样的道理，咱有钱，不要惊，不要怕！总结如下：我们本质上是通过数据冗余备份、失效转移来保证高可用并解决问题，单机变集群架构模式。
但高可用的冗余，跟高性能的冗余本质上是不一样的，也是面试官最喜欢给大家挖坑的。高性能的冗余，在于增加机器提升处理性能，好比猴子多吃了一颗槟榔和烟，法力无边；高可用的冗余，在于增加个数，好比猴子身上的毫毛，越多越暖，变的小猴子越多战斗力也越强。
难的东西来了，当毫毛变的小猴子越来越多，如何管理？其实，跟很多企业的管理层一样，几个人的团队好管，整天乐呵呵的，该喝茶喝茶；但上百人的团队，领导哪怕想上吊都没空。当你冗余部署了机器之后，有这么几个地方需要留意，考验的是「计算高可用」：
机器是用来执行任务的，我们需要添加「任务分配器」来实现合理分配任务；
根据实际情况，优化相关的分配算法；
做好任务分配器和业务服务器的连接、交互管理工作。
还有我们的「存储高可用」，如果也要实现它，那核心在哪儿呢？是不是要必须保证数据的一致？是的，你猜对了。因为存储，存的是数据，数据如果要备份就需要进行传输，在传输的过程中会因地理位置不一样会有不一样的耗时，那么就有可能会造成数据不一致。当数据不一致时，哪怕执行的是正确的逻辑，最终的业务结果也是让你怀疑人生的。那你应该明白了，我们在实现存储高可用的时候，重点是如何保证数据完整备份，难点是如何让数据不一致对业务造成的影响能达到最小。总结如下：
任务分配器，用来解决计算高可用的问题，优化同一服务组件部署在多个服务器上的效率；
异地备份，用来解决存储高可用问题，数据存储在多台服务上时，要注意数据一致的优化处理。
「可以先了解下 CAP 理论，是高可用系统面临的理论局限性，后面会细讲 ^_^」
高可用方案带来的新问题：如何在集群中判断当前系统是否已经处于高可用状态？
得靠「决策」！决策的方案，大致有这几种：
中心独裁式决策；
协商式；
民主式。
其中，独裁式最怕中心出问题，一旦中心崩溃，则决策瘫痪；协商式，主要是讨论谁当老大，也就是主备决策，但如果协商双方的信息交换过程中出现了问题，决策则无法做出选举，比如会出现两个主机、一个故障一个备（没主机了）等；民主式，类似区块链的决策算法，但会出现“脑裂”（也就是信息不通导致选出来多个结果），所以还要额外添加投票方式来辅助，保证投票节点数必须超过系统总节点数一半，才能继续处理。
不过还是会有一个大坑，如果某些时候系统并没有因为脑裂问题导致投票节点数过少，而本身就是有一半的机器已经发生故障了，这个时候居然也没去选主，这个时候，反正就是，敌不动我不动，整个系统也就相当于瘫痪了。
架构设计，其实解决的就是系统的复杂度，从复杂中找出解决方案，就NX了，加油！！
高可用就先捋到这儿，下次捋完高可靠的哈！
记得关注哟，别走丢了哈～
-----------------------
公众号：江帅帅（ID：NXJSS666）
CSDN 博客：江帅帅
每篇架构技术好文，都是小宝藏噢～
感谢你的阅读！
转载：https://blog.csdn.net/qq_41340258/article/details/112504929