二、高可用集群的衡量标准

三、高可用集群的层次结构

五、高可用集群常用软件

七、集群文件系统与集群LVM

八、高可用集群的工作原理

   高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。

   高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。

   高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的 情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。

• 99% 一年宕机时间不超过4天

• 99.9% 一年宕机时间不超过10小时

• 99.99% 一年宕机时间不超过1小时

• 99.999% 一年宕机时间不超过6分钟

三、高可用集群的层次结构

1.位于最底层的是信息和成员关系层（Messaging and Membership），Messaging主要用于节点之间传递心跳信息，也称为心跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。

2.集群资源管理层（Cluster Resource Manager），真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器（CRM，cluster Resource Manager），它能为实现高可用提供核心组件，包括资源定义，属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM（本地资源管理器）组件。对于CIB，只有工作在DC（主节点）上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后，是由DC通过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源。

3.资源代理层（Resource Agents），集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本)，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用),Legacy heartbeat（v1版本的资源管理）。

核心组件的具体说明（如上图）：

1.ccm组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。

2.crmd组件（Cluster Resource Manager，集群资源管理器，也就是pacemaker）：实现资源的分配，资源分配的每个动作都要通过crm来实现，是核心组建，每个节点上的crm都维护一个cib用来定义资源特定的属性，哪些资源定义在同一个节点上。

3.cib组件（集群信息基库，Cluster Infonation Base）：是XML格式的配置文件，在内存中的一个XML格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有DC上的cib才能进行修改，其他节点上的cib都是拷贝DC上。配置cib文件的方法有，基于命令行配置和基于前台的图形界面配置。

4.lrmd组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。

• PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让TE来执行自己的策略。

   STONITH(Shoot The Other Node in the Head，”爆头“)， 这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动， 这种方式需要硬件支持。

 STONITH应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给STONITH，就是我们常说的”爆头

2.多节点热备（N+1）

3.多节点共享存储（N-TO-N）

   说到集群， 我们不得不说到，共享存储，因为不管理是Web高可用也，Mysql高可用也好，他们的数据都是共享的就一份，所有必须放在共享存储中，主节点能访问，从节点也能访问。下面我们就简单说一下共享存储。

说明：设备直接连接到主机总线上的，距离有限，而且还要重新挂载，之间有数据传输有延时

• FC光网络（交换机的光接口超贵，一个差不多2万，如果使用这个，代价太高）

• IPSAN（iscsi）存取快，块级别，廉价

七、集群文件系统与集群LVM（集群逻辑卷管理cLVM）

注：一般用于高可用双主模型中（如下图）

八、高可用集群的工作原理

说明：这里主要以主/从节点的高可用来说明工作原理。

   主服务器和从服务器建立双机热备，基本上都是共享一个存储，以mysql为例。通常情况下，数据库文件挂载在主数据库服务器上，用户连接到主服务器上进行数据库操作。当主服务器出现故障时，从服务器就会自动挂载数据库文件，并接替主服务器的工作。用户在未通知的情况下，通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后，又可以重新提供服务；

 那么，从服务器是如何知道主服务器挂掉了呢，这就要使用一定的检测机制，如心跳检测，也就是说每一个节点都会定期向其他节点通知自己的心跳信息，尤其是主服务器，如果从服务器在几个心跳周期内（可自行设置心跳周期）还没有检测到的话，就认为主服务器宕掉了，而这期间在通告心跳信息当然不能使用tcp传输的，如果使用tcp检测，还要经过三次握手，等手握完了，不定经过几个心跳周期了，所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的，如果主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，这个时候从服务器要是把主服务资源抢过去（共享数据文件），但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是从服务器抢占资源的时候，直接把主服务器给“STONITH”，就是我们常说的“爆头”；

 那么，我们又用什么方式来检测心跳信息呢？就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、从服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连，以避免Heartbeat通信线路本身存在单点故障。

   上面的原理中我们提到了“隔离方法”，下面我们来说一说，隔离方法有两种，一种是节点隔离，另一种是资源隔离。节点隔离就是我们常说的STONITH（Shoot The Other Node In the Head ，俗称“爆头”)，意思就是直接切断电源；常用的方法是所有节点都接在一个电源交换机上，如果有故障，就直接导致该节点的电压不稳定，或断电，让有故障的节点重启或关闭。（如下图），而资源隔离，就是 fencing 直接把某种资源截获过来。

  下面我们再来说一说“心路线”的类型，一种是串行电缆，另一种就是我们常看到的以太网线（交叉的双绞线），它们各有优缺点，串行电缆，被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。以太网线连接，使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主从服务器之间同步文件系统，从而减少了对正常通信连接带宽的占用。（如下图）

高可用集群，英文原文为High Availability Cluster，简称HACluster，简单的说，集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统 就是集群的节点（node）。 高可用集群的出现是为了使集群的整体服务尽可能可用，从而减少由计算机硬件和软件易错性所带来的损失。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。 高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。只有两个节点的高可用集群又称为双机热备，即使用两台服务器互相备份。当一台服务器出现故障时，可由另一台服务器承担服务任务，从而在不需要人工干预的 情况下，自动保证系统能持续对外提供服务。双机热备只是高可用集群的一种，高可用集群系统更可以支持两个以上的节点，提供比双机热备更多、更高级的功能，更能满足用户不断出现的需求变化。

99.9% 一年宕机时间不超过10小时

99.99% 一年宕机时间不超过1小时

99.999% 一年宕机时间不超过6分钟

Membership），Messaging主要用于节点之间传递心跳信息，也称为心跳层。节点之间传递心跳信息可以通过广播，组播，单播等方式。成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。 2.集群资源管理层（Cluster Resource Manager），真正实现集群服务的层。在该层中每个节点都运行一个集群资源管理器（CRM，cluster Resource Manager），它能为实现高可用提供核心组件，包括资源定义，属性等。在每一个节点上CRM都维护有一个CIB(集群信息库 XML文档)和LRM（本地资源管理器）组件。对于CIB，只有工作在DC（主节点）上的文档是可以修改的，其他CIB都是复制DC上的那个文档而来的。对于LRM,是执行CRM传递过来的在本地执行某个资源的执行和停止的具体执行人。当某个节点发生故障之后，是由DC通过PE（策略引擎）和TE（实施引擎）来决定是否抢夺资源。 3.资源代理层（Resource Agents），集群资源代理(能够管理本节点上的属于集群资源的某一资源的启动，停止和状态信息的脚本)，资源代理分为：LSB（/etc/init.d/*）,OCF(比LSB更专业，更加通用),Legacy heartbeat（v1版本的资源管理）。

核心组件的具体说明（如上图）： 1.ccm组件（Cluster Consensus Menbership Service）：作用，承上启下，监听底层接受的心跳信息，当监听不到心跳信息的时候就重新计算整个集群的票数和收敛状态信息，并将结果转递给上层，让上层做出决定采取怎样的措施，ccm还能够生成一个各节点状态的拓扑结构概览图，以本节点做为视角，保证该节点在特殊情况下能够采取对应的动作。 2.crmd组件（Cluster Resource Manager，集群资源管理器，也就是pacemaker）：实现资源的分配，资源分配的每个动作都要通过crm来实现，是核心组建，每个节点上的crm都维护一个cib用来定义资源特定的属性，哪些资源定义在同一个节点上。 3.cib组件（集群信息基库，Cluster Infonation Base）：是XML格式的配置文件，在内存中的一个XML格式的集群资源的配置文件，主要保存在文件中，工作的时候常驻在内存中并且需要通知给其它节点，只有DC上的cib才能进行修改，其他节点上的cib都是拷贝DC上。配置cib文件的方法有，基于命令行配置和基于前台的图形界面配置。 4.lrmd组件（Local Resource Manager，本地资源管理器）：用来获取本地某个资源的状态，并且实现本地资源的管理，如当检测到对方没有心跳信息时，来启动本地的服务进程等。 5.pengine组件： PE（Policy Engine）：策略引擎，来定义资源转移的一整套转移方式，但只是做策略者，并不亲自来参加资源转移的过程，而是让TE来执行自己的策略。TE（Transition Engine）： 就是来执行PE做出的策略的并且只有DC上才运行PE和TE。

6.stonithd组件 STONITH(Shoot The Other Node in the Head，”爆头“)， 这种方式直接操作电源开关，当一个节点发生故障时，另 一个节点如果能侦测到，就会通过网络发出命令，控制故障节点的电源开关，通过暂时断电，而又上电的方式使故障节点被重启动， 这种方式需要硬件支持。 STONITH应用案例（主从服务器），主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，如果这个时候备用服务器一下子把服务资源抢过去，但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从服务器上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是备用服务器抢占资源的时候，直接把主服务器给STONITH，就是我们常说的”爆头

总结：我们经常在技术博客中看到，heartbeat+pacemaker实现mysql高可用，或corosync+pacemaker实现mysql高可用等，有的博友会问了，我们到底用什么好呢？经过上面的说明大家应该有所了解！

说到集群， 我们不得不说到，共享存储，因为不管理是Web高可用也，Mysql高可用也好，他们的数据都是共享的就一份，所有必须放在共享存储中，主节点能访问，从节点也能访问。下面我们就简单说一下共享存储。 1.DAS:(Direct attached storage)直接附加存储 说明：设备直接连接到主机总线上的，距离有限，而且还要重新挂载，之间有数据传输有延时 RAID 阵列

3.SAN:(storage area network)存储区域网络 说明：块级别的，模拟的scsi协议 FC光网络（交换机的光接口超贵，一个差不多2万，如果使用这个，代价太高）

IPSAN（iscsi）存取快，块级别，廉价

集群文件系统：gfs2、ocfs2 集群LVM：cLVM 注：一般用于高可用双主模型中（如下图）

说明：这里主要以主/从节点的高可用来说明工作原理。 主服务器和从服务器建立双机热备，基本上都是共享一个存储，以mysql为例。通常情况下，数据库文件挂载在主数据库服务器上，用户连接到主服务器上进行数据库操作。当主服务器出现故障时，从服务器就会自动挂载数据库文件，并接替主服务器的工作。用户在未通知的情况下，通过从数据库连接到数据库文件进行操作。等主服务器的故障修复之后，又可以重新提供服务； 那么，从服务器是如何知道主服务器挂掉了呢，这就要使用一定的检测机制，如心跳检测，也就是说每一个节点都会定期向其他节点通知自己的心跳信息，尤其是主服务器，如果从服务器在几个心跳周期内（可自行设置心跳周期）还没有检测到的话，就认为主服务器宕掉了，而这期间在通告心跳信息当然不能使用tcp传输的，如果使用tcp检测，还要经过三次握手，等手握完了，不定经过几个心跳周期了，所以在检测心跳信息的时候采用的是udp的端口694来进行传递信息的，如果主服务器在某一端时间由于服务繁忙，没时间响应心跳信息，这个时候从服务器要是把主服务资源抢过去（共享数据文件），但是这个时候主服务器还没有宕掉，这样就会导致资源抢占，就这样用户在主从上都能访问，如果仅仅是读操作还没事，要是有写的操作，那就会导致文件系统崩溃，这样一切都玩了，所以在资源抢占的时候，可以采用一定的隔离方法来实现，就是从服务器抢占资源的时候，直接把主服务器给“STONITH”，就是我们常说的“爆头”； 那么，我们又用什么方式来检测心跳信息呢？就是通过心跳线来检测。运行在从服务器上的Heartbeat可以通过以太网连接检测主服务器的运行状态，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。通常情况下，主、从服务器间的心跳连接是一个独立的物理连接，这个连接可以是串行线缆、一个由“交叉线”实现的以太网连接。Heartbeat甚至可同时通过多个物理连接检测主服务器的工作状态，而其只要能通过其中一个连接收到主服务器处于活动状态的信息，就会认为主服务器处于正常状态。从实践经验的角度来说，建议为Heartbeat配置多条独立的物理连，以避免Heartbeat通信线路本身存在单点故障。 上面的原理中我们提到了“隔离方法”，下面我们来说一说，隔离方法有两种，一种是节点隔离，另一种是资源隔离。节点隔离就是我们常说的STONITH（Shoot The Other Node In the Head ，俗称“爆头”)，意思就是直接切断电源；常用的方法是所有节点都接在一个电源交换机上，如果有故障，就直接导致该节点的电压不稳定，或断电，让有故障的节点重启或关闭。（如下图），而资源隔离，就是 fencing 直接把某种资源截获过来。

下面我们再来说一说“心路线”的类型，一种是串行电缆，另一种就是我们常看到的以太网线（交叉的双绞线），它们各有优缺点，串行电缆，被认为是比以太网连接安全性稍好些的连接方式，因为hacker无法通过串行连接运行诸如telnet、ssh或rsh类的程序，从而可以降低其通过已劫持的服务器再次侵入备份服务器的几率。但串行线缆受限于可用长度，因此主、备服务器的距离必须非常短。以太网线连接，使用此方式可以消除串行线缆的在长度方面限制，并且可以通过此连接在主从服务器之间同步文件系统，从而减少了对正常通信连接带宽的占用。（如下图）

我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。

保证系统高可用，架构设计的核心准则是：冗余。

有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中，如何通过冗余+自动故障转移来保证系统的高可用特性。

常见互联网分布式架构分为：

（1）客户端层：典型调用方是浏览器browser或者手机应用APP

（2）反向代理层：系统入口，反向代理

（3）站点应用层：实现核心应用逻辑，返回html或者json

（4）服务层：如果实现了服务化，就有这一层

（5）数据-缓存层：缓存加速访问存储

（6）数据-数据库层：数据库固化数据存储

整个系统的高可用，又是通过每一层的冗余+自动故障转移来综合实现的。

【客户端层->反向代理层】的高可用 【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余来实现的。以nginx为例：有两台nginx，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。 自动故障转移：当nginx挂了的时候，keepalived能够探测到，会自动的进行故障转移，将流量自动迁移到shadow-nginx，由于使用的是相同的virtual IP，这个切换过程对调用方是透明的

【反向代理层->站点层】的高可用 【反向代理层】到【站点层】的高可用，是通过站点层的冗余来实现的。假设反向代理层是nginx，nginx.conf里能够配置多个web后端，并且nginx能够探测到多个后端的存活性。 自动故障转移：当web-server挂了的时候，nginx能够探测到，会自动的进行故障转移，将流量自动迁移到其他的web-server，整个过程由nginx自动完成，对调用方是透明的。

【站点层->服务层】的高可用 【站点层】到【服务层】的高可用，是通过服务层的冗余来实现的。“服务连接池”会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。 自动故障转移：当service挂了的时候，service-connection-pool能够探测到，会自动的进行故障转移，将流量自动迁移到其他的service，整个过程由连接池自动完成，对调用方是透明的（所以说RPC-client中的服务连接池是很重要的基础组件）。

【服务层>缓存层】的高可用 【服务层】到【缓存层】的高可用，是通过缓存数据的冗余来实现的。

缓存层的数据冗余又有几种方式：第一种是利用客户端的封装，service对cache进行双读或者双写。 缓存层也可以通过支持主从同步的缓存集群来解决缓存层的高可用问题。

以redis为例，redis天然支持主从同步，redis官方也有sentinel哨兵机制，来做redis的存活性检测。 自动故障转移：当redis主挂了的时候，sentinel能够探测到，会通知调用方访问新的redis，整个过程由sentinel和redis集群配合完成，对调用方是透明的。

说完缓存的高可用，这里要多说一句，业务对缓存并不一定有“高可用”要求，更多的对缓存的使用场景，是用来“加速数据访问”：把一部分数据放到缓存里，如果缓存挂了或者缓存没有命中，是可以去后端的数据库中再取数据的。

这类允许“cache miss”的业务场景，缓存架构的建议是： 将kv缓存封装成服务集群，上游设置一个代理（代理可以用集群冗余的方式保证高可用），代理的后端根据缓存访问的key水平切分成若干个实例，每个实例的访问并不做高可用。 缓存实例挂了屏蔽：当有水平切分的实例挂掉时，代理层直接返回cache miss，此时缓存挂掉对调用方也是透明的。key水平切分实例减少，不建议做re-hash，这样容易引发缓存数据的不一致。

【服务层>数据库层】的高可用

大部分互联网技术，数据库层都用了“主从同步，读写分离”架构，所以数据库层的高可用，又分为“读库高可用”与“写库高可用”两类。

【服务层>数据库层“读”】的高可用 【服务层】到【数据库读】的高可用，是通过读库的冗余来实现的。

既然冗余了读库，一般来说就至少有2个从库，“数据库连接池”会建立与读库多个连接，每次请求会路由到这些读库。 自动故障转移：当读库挂了的时候，db-connection-pool能够探测到，会自动的进行故障转移，将流量自动迁移到其他的读库，整个过程由连接池自动完成，对调用方是透明的（所以说DAO中的数据库连接池是很重要的基础组件）。

【服务层>数据库层“写”】的高可用 【服务层】到【数据库写】的高可用，是通过写库的冗余来实现的。

以mysql为例，可以设置两个mysql双主同步，一台对线上提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务。 自动故障转移：当写库挂了的时候，keepalived能够探测到，会自动的进行故障转移，将流量自动迁移到shadow-db-master，由于使用的是相同的virtual IP，这个切换过程对调用方是透明的。

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

方法论上，高可用是通过冗余+自动故障转移来实现的。

整个互联网分层系统架构的高可用，又是通过每一层的冗余+自动故障转移来综合实现的，具体的：

（1）【客户端层】到【反向代理层】的高可用，是通过反向代理层的冗余实现的，常见实践是keepalived + virtual IP自动故障转移

（2）【反向代理层】到【站点层】的高可用，是通过站点层的冗余实现的，常见实践是nginx与web-server之间的存活性探测与自动故障转移

（3）【站点层】到【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过service-connection-pool来保证自动故障转移

（4）【服务层】到【缓存层】的高可用，是通过缓存数据的冗余实现的，常见实践是缓存客户端双读双写，或者利用缓存集群的主从数据同步与sentinel保活与自动故障转移；更多的业务场景，对缓存没有高可用要求，可以使用缓存服务化来对调用方屏蔽底层复杂性

（5）【服务层】到【数据库“读”】的高可用，是通过读库的冗余实现的，常见实践是通过db-connection-pool来保证自动故障转移

（6）【服务层】到【数据库“写”】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移