数据库高可用是个老生常谈的话题了，就是因为它对企业数据安全和保障业务连续性的重要程度，让企业不容忽视这一点。

那么什么是数据库高可用？

高可用（High Availability）是系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

如果一台系统能够不间断的提供服务，那么这台系统的可用性据说100%。那如果系统每运行100个时间单位，就会出现1个时间单位无法提供服务，那么该台系统的可用性是99%。

目前大部分企业的高可用目标是4个9，也就是99.99%，也就是允许这台系统的年停机时间为52.56分钟。

为实现系统高可用，其架构设计的核心准则是：冗余。

系统需要全天候24销售不间断运行，则需要相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。

容灾就等价于高可用？

有人说容灾所说的“灾难”指的大范围，高烈度的故障，例如火灾、地震、洪水、大范围的停电，所以往往还会有个限定词叫异地容灾。而高可用只要做到硬件冗余，实现单点故障时的业务接管就行了。这个观点只对了一半。

现如今，企业真正关心的“灾难”可以泛指非正常情况下的故障停机，而高可用则还应当应对由于IT运维工作等原因带来的计划内停机，因为无论是计划内还是计划外的停机都会对企业业务连续性造成损失。并且灾难故障往往是十年一遇甚至百年一遇，而维护停机工作才是无可避免经常会对业务连续性造成威胁的停机事件。

接下来给大家介绍两个常见的提高可用性的方案：

方案一：提高冗余度，多实例运行，用资源换可用性

主要有几点需要注意：

1. N+2应该是标配

N+2就是说平时如果一个服务需要1个实例正常提供服务，那么我们就在生产环境上应该部署1 +2=3个节点。主要因为：服务N+1部署只能提供热备容灾，发布的时候就失去保护了。

2. 实例之间必须对等、独立

千万不要搞一大一小，或者相互依赖。否则你的N+2就不是真的N+2。

3. 流量控制能力非常重要

想做到高可用，必须拥有一套非常可靠的流量控制系统。这套系统按常见的维度，比如说源IP，目标IP来调度是不够的，最好能按业务维度来调度流量。比如说按API，甚至按用户类型，用户来源等等来调度。

方案二：变更管理（Change Management）

主要注意以下几点：

1.线下测试（Offline Test）

线下测试永远比线上调试容易一百倍，也安全一百倍。

可用性的阶段性提高，不是靠运维团队，而是靠产品团队。能在线下完成的测试，绝不拍脑门到线上去实验。

2.灰度发布

首先灰度发布是速度与安全性作为妥协，是发布众多保险的最后一道，却不是唯一的一道。如果纯粹是为了灰度而灰度，人为的拖慢进度，反而会造成线上多版本长期间共存，可能会导致新的问题发生。

回到本质：灰度发布是上线的最后一道安全防护机制。即不能过慢，让产品团队过度依赖，也不能过于随机，失去了他的意义。

总之，灰度发布，全在细节里。

3.服务必须对回滚提供支持

这点是必须需要强调的！