丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
首先，我们需要理解什么是高可用，英文叫HighAvailability（Wikipedia词条），基本上来说，就是要让我们的计算环境（包括软硬件）做到full-time的可用性。在设计上一般来说，需要做好如下的设计：
对软硬件的冗余，以消除单点故障。任何系统都会有一个或多个冗余系统做standby；
对故障的检测和恢复。检测故障以及用备份的结点接管故障点。这也就是failover；
需要很可靠的交汇点（CrossOver）。这是一些不容易冗余的结点，比如域名解析，负载均衡器等。
听起似乎很简单吧，然而不是，细节之处全是魔鬼，冗余结点最大的难题就是对于有状态的结点的数据复制和数据一致性的保证（无状态结点的冗余相对比较简单）。冗余数据所带来的一致性问题是魔鬼中的魔鬼：
如果系统的数据镜像到冗余结点是异步的，那么在failover的时候就会出现数据差异的情况；
如果系统在数据镜像到冗余结点是同步的，那么就会导致冗余结点越多性能越慢。
所以，很多高可用系统都是在做各种取舍，这需要比对着业务的特点来的，比如银行账号的余额是一个状态型的数据，那么，冗余时就必需做到强一致性，再比如说，订单记录属于追加性的数据，那么在failover的时候，就可以到备机上进行追加，这样就比较简单了。
下面，总结一下高可用的设计原理：
要做到数据不丢，就必需要持久化；
要做到服务高可用，就必需要有备用（复本），无论是应用结点还是数据结点；
要做到复制，就会有数据一致性的问题；
我们不可能做到100%的高可用，也就是说，我们能做到几个9个的SLA。
这个图基本上来说是目前高可用系统中能看得到的所有的解决方案的基础了。M/S、MM实现起来不难，但是会有很多问题，2PC的问题就是性能不行，而Paxos的问题就是太复杂，实现难度太大。
总结一下各个高可用方案的的问题：
对于最终一致性来说，在宕机的情况下，会出现数据没有完全同步完成，会出现数据差异性；
对于强一致性来说，要么使用性能比较慢的XA系的两阶段提交的方案，要么使用性能比较好，但是实现比较复杂的Paxos协议。
注：这是软件方面的方案。当然，也可以使用造价比较高的硬件解决方案，不过本文不涉及硬件解决方案。
另外，现今开源软件中，很多缓存，消息中间件或数据库都有持久化和Replication的设计，从而也都有高可用解决方案，但是开源软件一般都没有比较高的SLA，所以，如果我们使用开源软件的话，需要注意这一点。
下面，我们来看一下MySQL的高可用的方案的SLA（下图下面红色的标识表示了这个方案有几个9）：
简单解释一下MySQL的这几个方案（主要是想表达一个越多的9就越复杂）
MySQLRepleaction就是传统的异步数据同步或是半同步Semi-Sync（只要有一个slave收到更新就返回成功）这个方式本质上不到2个9；
MySQLFabric简单来说就是数据分片下的M/S的读写分离模式。这个方案的的可用性可以达到99%；
DRBD通过底层的磁盘同步技术来解决数据同步的问题，就是RAID1——把两台以上的主机的硬盘镜像成一个。这个方案不到3个9；
MySQLCluster是官方的一个开源方案，其把MySQL的集群分成SQLNode和DataNode，DataNode是一个自动化sharing和复制的集群NDB，为了更高的可用性，MySQLCluster采用了“完全同步”的数据复制的机制来冗余数据结点。这个方案接近5个9。
那么，这些2个9，3个9，4个9，5个9是什么意思呢？又是怎么来的呢？请往下看。
上面那些都不是本文的重点，本文的重点现在开始，如何测量系统的高可用性。当然是SLA，全称ServiceLevelAgrement，也就是有几个9的高可用性。
工业界有两种方法来测量SLA：
比如，99.999%的可用性，一年只能有5分半钟的服务不可用。感觉很难做到吧。
老实说，我们很难计算我们设计的系统有多少的可用性，因为影响一个系统的因素实在是太多了，除了软件设计，还有硬件，还有每三方的服务（如电信联通的宽带SLA），当然包括“建筑施工队的挖掘机”。所以，正如SLA的定义，这不仅仅只是一个技术指标，而是一种服务提供商和用户之间的contract或契约。这种工业级的玩法，就像飞机一样，并不是把飞机造出来就好了，还有大量的无比专业的配套设施、工具、流程、管理和运营。
简而言之，SLA的几个9就是能持续提供可用服务的级别，不过，工业界中，会把服务不可用的因素分成两种：一种是有计划的，一种是无计划的。
下图来自Oracle的《HighAvailabilityConceptsandBestPractices》
我们可以看到，上面的宕机原因包括如下：
无计划的
系统级的故障–包括主机、操作系统、中间件、数据库、网络、电源以及外围设备；
数据和中介的故障–包括人员误操作、硬盘故障、数据乱了；
还有：自然灾害、人为破坏、以及供电问题。
有计划的
日常任务：备份，容量规划，用户和安全管理，后台批处理应用；
如果你没有一套科学的牛逼的软件工程的管理，没有牛逼先进的自动化的运维工具，没有技术能力很牛逼的工程师团队，怎么可能出现高可用的系统。
是的，要做出高可用的系统，这就是一套严谨科学的工程管理，其中包括但不限于了：
软件的设计、编码、测试、上线和软件配置管理的水平
工程师的人员技能水平
运维的管理和技术水平
数据中心的运营管理水平
依赖于第三方服务的管理水平
深层次的东西则是——对工程这门科学的尊重：
对待技术的态度
一个公司的工程文化
领导者对工程的尊重
所以，以后有人在你面前提高可用，你要看的不是他的技术设计，而还要看看他们的工程能力，看看他们公司是否真正的尊重工程这门科学。
有好些非技术甚至技术人员和我说过，做个APP做个网站，不就是找几个码农过来写写代码嘛。等系统不可用的时候，他们才会明白，要找技术能力比较强的人，但是，就算你和他们讲一万遍道理，他们也很难会明白写代码怎么就是一种工程了，而工程怎么就成了一门科学了。其实，很多做技术的人都不明白这个道理。
看完这些，最后让我们都扪心自问一下，你还敢说你的系统是高可用的了么？