系统的高可用（纯理论）

专注服务端首先要专注的是关于高可用。

有的时候高可用系统并不是简单的技术方案，会包含很多其他的东西。

什么是高可用？

基本来讲是为了让我们的计算机（硬件/软件）做到full time可用。设计上一般有下面的方法：

1. 对软/硬件冗余，消除单点故障。任何系统都有一个或多个冗余系统做standby。
2. 对故障的检测和恢复。检测故障使用备份的节点接管故障点。就是failover。
3. 需要可靠的交汇点。一些不易冗余的节点，或者被看做是单点的节点，比如域名解析，负载均衡。

冗余的问题

系统软硬件冗余可以保证高可用，但是冗余之后的问题是多个节点状态的数据复制和数据一致性的保证。

一致性问题：

1. 系统的数据镜像到冗余节点是异步的。在failover的时候会出现数据差异。
2. 数据镜像到冗余节点是同步的，会导致冗余节点越多性能越差。

所以在选择中会有取舍，依照业务特点来。

高可用设计原理：

1. 数据不丢失就需要持久化。
2. 服务高可用，需要做备份（副本），包括应用节点和数据节点。
3. 节点之间复制就会有数据一致性问题。
4. 不可能做到100%高可用，达到常说的9个SLA。

常见的高可用方案有：

1. M/S，MM实现起来简单存在一些问题；
2. 2PC，3PC有一定的性能问题；
3. Paxos较为复杂，比如zk；

高可用问题：

1. 最终一致性来讲，宕机情况下会出现数据没有完全同步，出现数据节点数据差异。
2. 强一致性来讲，使用两阶段提交/三阶段提交方案，需要结合Paxos协议实现。

当今的开源软件中，缓存，消息系统，数据库都有持久化和复制的设计，实现了自身的高可用。

以MySql为例：

1. MySql Repleaction是传统的异步数据同步方式/半同步（只有一个Slave收到更新就返回成功）这个本质上不到2个9。
2. MySql Fabric就是数据分片下的M/S读写分离模式。高可用可以达到99%。
3. DRBD通过底层的磁盘同步方案来解决数据同步问题，及时RAID 1把两台以上的主机的硬盘镜像成一个。这个方案不到3个9。
4. Solaris Clustering/Orical VM，这个机制监控了包括硬件，操作系统，网络和数据库。方案会伴随节点间心跳，还会用到SAN或本地的分布式存储系统，用到虚拟化技术。是一个全栈式的方案。
5. MySql Cluster是官方的开源方案，把MySql的集群分成Sql Node和Data Node，Data Node是一个自动化sharing和复制的机器NDB，为了高可用，MySql Cluster采用了完全同步的数据复制来冗余数据节点，也是采用比较多的方案。接近于5个9。

比如，99.999%的可用性，一年只能有5分半钟的服务不可用。感觉很难做到吧。

影响高可用的因素

处理设计系统的高可用，还需要面对硬件，第三方服务，建筑施工队的因素。

意外因素：

1. 系统的故障：主机，操作系统，中间件，数据库，网络，电源，外设设备。
2. 数据和中介：人员误操作，硬盘故障，数据异常。
3. 自然灾害，人为损坏，供电。

计划内因素：

1. 日常任务：备份，容量规划，用户和安全处理，后台批处理。
2. 运维日常：数据库维护，应用维护，中间件维护，操作系统维护，网络维护。
3. 升级相关：数据库，应用，中间件，操作系统，网络，硬件升级。

小团队没有这么多资源，还是实用一些靠谱的云服务吧。