系统复杂度的另一个原因是高可用性，即无间断的提供服务。业内一般用几个9来表达服务的可用程度，即如下公式：

服务年度可用性=(服务年度可用时间/年度总时间) x 100%

知名大型网站要达到99.99%（俗称4个9），也是很难的，支付宝还会被挖断光缆，百度DNS解析也会出现问题呢！

任何软件和硬件都会出现问题，磁盘会坏，软件有bug，按理说每50行代码就有可能产生一个bug，windows系统bug是修改不完的 ，所以一直在打patch啊！如何实现系统的高可用，通过冗余，就是增加机器的方式，这里增加机器和高性能增加机器不同，高性能中增加机器是为了提供计算性能，这里的是为了提供冗余服务。如：数据存储通过提供备份方案，来实现数据存储的高可用，通常的主备方案就是一种选择，Redis集群的主备方案，Mysql的主备方案等等。服务高可用可以通过集群方式来搭建服务集群，当一台服务出现问题时自动切换到另外一台提供服务。

下面从2个场景来阐述高可用的复杂性。

• 业务服务高可用

通过把业务服务部署在多台机器上提供服务，就需要该服务为无状态的，即每次请求不管落在那台服务器上，返回结果都是一样的。同样需要一个负载均衡服务器，进行任务分发，这里和上一讲说的高性能复杂度一样，同样引入了连接管理，轮询算法等额外的工作量。而随着集群规模越来越大，复杂度就会越来越高。比如，集群规模增大时，我们使用Zookeeper来进行状态协调各种资源，而其选举算法ZAB就是太复杂。

• 数据服务高可用

数据的高可用，表现在鸡蛋不能放在一个篮子里面，如果放在3个篮子里面，那么同样的copy三份呢？还是一份切成三小份，放在不同的篮子里面？这个要根据实际情况来定，通常使用比较多的MySQL的主备方案，就是一种高可用方案，他是把鸡蛋copy一份放在其他篮子里面，并且可以做到故障时自动切换，这种切换的复杂度根据不同的实施方案是不同的，是完全自动化，还是半人工的，都有不同的实施方案。

缓存Redis在实现集群方案时，通过AOF方式进行数据同步，如何做到数据延迟小，如何对外提供透明稳定的服务，其复杂程度也是不低的。另外，如果涉及到跨机房的数据高可用方案，就更加复杂，涉及到传输速率，延迟等等问题。有时候我们只能通过业务上的妥协来达成可用。

总之，我们在高可用的需求下，通过不断的优化机制和协调业务流程，最终来降低系统崩溃的风险，要做到万无一失，适合所有场景的高可用方案是不存在的。