－、高可用策略
1- 一个性能差的高可用其实上是假的高可用，高可用一定有性能的下限
2- 高可用首先是要保证重要业务的高可用，需要对业务进行取舍，关注于最重要的方面

3- 根据业务的优先级进行区分，高优先级的业务走不同的通道，保持高的服务质量，即QoS是高可用的重要组成部分

4- 高可用的一个最廉价同时也是最简单的方案就是扩容

5- 可服务节点的水平扩展和流量分流是保证高可用的常见手段

6- 对于异常的事件，或者说峰拥，需要进行自我保护，通过排队的机制来确保业务能够能够继续。否则的话事情只会是更糟


二、相关技术
高可用包含了如上所示的这些方面，每一个方面都不能够独立地解决高可用的问题，而需要统筹考虑。简单地说，相关的技术有：

1- 性能评估和测量

2- 业务的重要度区分

3- 不同重要的业务不同的通道，业务上进行分离

4- 服务的水平扩展

5- 流量的均衡分配

6- 性能的动态监控

7- 软件的自我保护

8- 协商式的请求分流

转载请标明出处：

https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html

本文出自方志朋的博客

个人博客纯净版：https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html
最新Finchley版本请访问：

https://www.fangzhipeng.com/springcloud/2018/08/07/sc-f7-config.html

或者

http://blog.csdn.net/forezp/article/details/81041045
上一篇文章讲述了一个服务如何从配置中心读取文件，配置中心如何从远程git读取配置文件，当服务实例很多时，都从配置中心读取文件，这时可以考虑将配置中心做成一个微服务，将其集群化，从而达到高可用，架构图如下：

一、准备工作
继续使用上一篇文章的工程，创建一个eureka-server工程，用作服务注册中心。
在其pom.xml文件引入Eureka的起步依赖spring-cloud-starter-eureka-server，代码如下:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.forezp</groupId>
	<artifactId>eureka-server</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>jar</packaging>

	<name>eureka-server</name>
	<description>Demo project for Spring Boot</description>

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>1.5.2.RELEASE</version>
		<relativePath/> <!-- lookup parent from repository -->
	</parent>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
		<java.version>1.8</java.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka-server</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>Dalston.RC1</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

	<repositories>
		<repository>
			<id>spring-milestones</id>
			<name>Spring Milestones</name>
			<url>https://repo.spring.io/milestone</url>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>


</project>


在配置文件application.yml上，指定服务端口为8889，加上作为服务注册中心的基本配置，代码如下：
server:
  port: 8889

eureka:
  instance:
    hostname: localhost
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

入口类：
@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(EurekaServerApplication.class, args);
	}
}


二、改造config-server
在其pom.xml文件加上EurekaClient的起步依赖spring-cloud-starter-eureka，代码如下:
<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-config-server</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>

		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
	</dependencies>


配置文件application.yml，指定服务注册地址为http://localhost:8889/eureka/，其他配置同上一篇文章，完整的配置如下：
spring.application.name=config-server
server.port=8888

spring.cloud.config.server.git.uri=https://github.com/forezp/SpringcloudConfig/
spring.cloud.config.server.git.searchPaths=respo
spring.cloud.config.label=master
spring.cloud.config.server.git.username= your username
spring.cloud.config.server.git.password= your password
eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/

最后需要在程序的启动类Application加上@EnableEureka的注解。
三、改造config-client
将其注册微到服务注册中心，作为Eureka客户端，需要pom文件加上起步依赖spring-cloud-starter-eureka，代码如下：
<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-config</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>

配置文件bootstrap.properties，注意是bootstrap。加上服务注册地址为http://localhost:8889/eureka/
spring.application.name=config-client
spring.cloud.config.label=master
spring.cloud.config.profile=dev
#spring.cloud.config.uri= http://localhost:8888/

eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server
server.port=8881



spring.cloud.config.discovery.enabled 是从配置中心读取文件。
spring.cloud.config.discovery.serviceId 配置中心的servieId，即服务名。
这时发现，在读取配置文件不再写ip地址，而是服务名，这时如果配置服务部署多份，通过负载均衡，从而高可用。
依次启动eureka-servr,config-server,config-client

访问网址：http://localhost:8889/

访问http://localhost:8881/hi，浏览器显示：

foo version 3

本文源码下载：
https://github.com/forezp/SpringCloudLearning/tree/master/chapter7
四、参考资料
spring_cloud_config
更多阅读
史上最简单的 SpringCloud 教程汇总
SpringBoot教程汇总
Java面试题系列汇总

    

        

        扫码关注公众号有惊喜
    
    

        （转载本站文章请注明作者和出处 方志朋的博客）
    

高可用集群
 

这篇先来认识高可用集群的一些基本概念。

1、什么是高可用集群

       高可用集群（High Availability Cluster，简称HA Cluster），是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件、硬件、人为造成的故障对业务的影响降低到最小程度。


       简单说就是：保证服务不间断地运行，比如，在淘宝网什么时候都可以上去买东西，微信随时可以打开发消息聊天。

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

       要保证集群服务100%时间永远完全可用，几乎可以说是一件不可能完成的任务。比如，淘宝在这几年双十一刚开始的时候，一下子进来买东西的人很多，访问量大，都出现一些问题，如下单后却支付不了。所以说只能保证服务尽可能的可用，当然有些场景相信还是可能做到100%可用的。


       通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%。


      具体HA衡量标准:



描述


通俗叫法


可用性级别


年度停机时间


基本可用性


2个9


99%


87.6小时


较高可用性


3个9


99.9%


8.8小时


具有故障自动恢复能力的可用性


4个9


99.99%


53分钟


极高可用性


5个9


99.999%


5分钟


 
3、高可用集群实现原理

      高可用集群主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)和自动恢复(FailBack)。
      简单来说就是，用高可用集群软件实现故障检查和故障转移（故障/备份主机切换）的自动化，当然像负载均衡、DNS分发也可提供高可性。

3-1、自动侦测(Auto-Detect)/ 故障检查

     自动侦测阶段由主机上的软件通过冗余侦测线，经由复杂的监听程序，逻辑判断，来相互侦测对方运行的情况。
     常用的方法是：集群各节点间通过心跳信息判断节点是否出现故障。

3-1-1、问题是：当有节点（一个或多个）和另外节点互相接收不到对方心跳信息时，如何决定哪一部分节点是正常运行的，而哪一部分是出现故障需要隔离的呢（避免集群脑裂）？

      这时候通过法定票数（quorum）决定，即当有节点故障时，节点间投票决定哪个节点是有问题的，票数大于半数为合法。


票数：
       每个节点可以设置票数，即决定节点在集群内是否合法（正常）的权限值，这个是可以有多有少的，例如有些节点的性能较好或有其他优势，可以设置较多的票数。
法定票数（quorum）：

       当一个节点能和另一个节点保持心跳信息，该节点就获取得了另一个节点的票数，该节点获得的所有票数就是法定票数。

3-1-2、比较特殊的是只有两个节点的集群，或两边票数相等

       这时候可以借助另外的参考节点，如ping网关（可以是一个节点），可以和测试点ping通，但不可以和对方通，说明对方节点有问题，或本节点有问题；还有就是通过仲裁设备，如仲裁磁盘，每个节点都间隔一定时间不停往磁盘写数据，若监测到对方不再写入的时候，可能对方节点出故障。
      但最好还是使得组成集群的节点数量为单数台（2n+1），当集群分区脑裂时，节点数量小于一半（>n+1）的分区自动停止对外提供服务。


3-1-3、Pasox算法和Zookeeper


      关于“投票”，有必要知道著名的Pasox算法和Zookeeper：
Paxos算法：


      Paxos算法解决的是保证集群中每个节点执行相同的操作序列，可以保证分布式群集中的数据一致性。
      例如，通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准）；而其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。

      编号严格递增，当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己数据不一致了，自动停止对外服务并重启同步过程。
      任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。


Zookeeper：


      Zookeeper是 Hadoop 大数据生态的一个独立组件，是 Google 的 Chubby一个开源的实现，可以说是Paxos算法（类似）的实现。
      Zookeeper主要提供分布式协调服务，分布式应用程序可以基于它实现服务注册（高可用），同步服务，配置维护和命名服务等。
      Zookeeper真正提供的是类似我们普通电脑上的文件系统目录的功能，不过可以原子的进行增/删/改/查操作；具体要实现什么分布式协调服务，需要自己写程序来操作Zookeeper上的“目录”。

      Zookeeper为什么可以作为分布式系统提供协调服务？


      最主要的是Zookeeper本身运行的是一个由多个Zookeeper节点组成的稳定的高可用集群。

       Zookeeper集群的高可用性和各节点“目录”数据的一致性正是基于 类似 Paxos算法实现的投票机制来保证的。

      所以 Zookeeper集群节点数量最好也是单数（2n+1），当集群脑裂分区时，分区节点数量不超过一半的（<n+1），会自动停止对外服务。
       比如：


      5台ZK节点组成ZK集群，当分成2台和3台的两个分区时，2台的分区会自动停止对外服务，3台的分区会继续提供服务。

      另外，如果用6台节点组成ZK集群，当分成3台和3台的两个分区时，这两个分区都自动停止对外服务，所以，容错率和5台节点组成的集群的是一样的，更应该用单数（2n+1）节点数量组成集群。




3-2、自动切换/故障转移（FailOver）

      自动切换阶段某一主机如果确认对方故障，则正常主机除继续进行原来的任务，还将依据各种容错备援模式接管预先设定的备援作业程序，并进行后续的程序及服务。
      通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。
      通过上面判断节点故障后，将高可用集群资源（如VIP、httpd等，下面详见）从该不具备法定票数的集群节点转移到故障转移域（Failover Domain，可以接收故障资源转移的节点）。

3-2-1、高可用集群资源（HA Resource）和集群资源类型

集群资源是集群中使用的规则、服务和设备等，如VIP、httpd服务、STONITH设备等。类型如下：
        1、Primitive：主资源，在某一时刻只能运行在某个节点上，如VIP。
        2、group：组，资源容器，使得多个资源同时停/启等，一般只包含primitive资源。
        3、clone：克隆，可以在多个节点运行的资源，例如stonith设备管理进程、集群文件系统的分布式锁（dlm）作为资源，应运行在所有节点上。
        4、master/slave：特殊的clone资源，运行在两个节点上，一主一从，如：分布式复制块设备drbd（2.6.33之后整合进内核了）。

3-2-2、转移到哪个节点

根据资源的倾向（资源粘性、位置约束的分数比较）进行转移；
资源的倾向（资源定位的依据）：

 A、资源粘性：资源对节点倾向程度，资源是否倾向于当前节点。score，正值倾向于当前节点（还要和位置约束结合）。
 B、资源约束（Constraint）：资源和资源之间的关系

a、排列约束 （colocation）：资源间的依赖/互斥性，定义资源是否运行在同一节点上。score，正值表示要运行在同一节点上，负值则不可。
b、位置约束（location）：每个节点都有一个score值，正值则倾向于本节点，负值倾向于其他节点，所有节点score比较，倾向于最大值的节点。
c、顺序约束（order）：定义资源执行动作的次序，例如vip应先配置，httpd服务后配置。特殊的score值，-inf 负无穷，inf 正无穷。


       也就是说资源粘性定义资源对资源当前所在节点的倾向性，而位置约束定义资源对集群中所有节点的倾向性。如webip的资源粘性为100，位置约束对node1为200，当webip在node2上时，node1上线资源会转移到node1，因为当前节点node2粘性100小于对node1的位置约束200；如webip的资源粘性为200，位置约束对node1为100，当webip在node2上时，node1上线资源不会转移到node1，继续留在node2上，因为当前节点node2粘性200大于对node1的位置约束100。


3-3、自动恢复/故障回转(FailBack)

      自动恢复阶段在正常主机代替故障主机工作后，故障主机可离线进行修复工作。在故障主机修复后，透过冗余通讯线与原正常主机连线，自动切换回修复完成的主机上。

3-3-1、当排除故障后，是否要故障回转？

      根据资源粘性和资源约束的设置，一般备用设备单纯只用于备份，性能低于主设备，所以当主设备恢复时应转回，但故障回转需要资源转移，会影响到正在使用的客户，过程代价较高，所以是否需要回转根据实际判断。

3-4、其他关注点
3-4-1、如果节点不再成为集群节点成员时（不合法），如何处理运行于当前节点的资源？

      如果集群没有对其进行Fecning/Stonith隔离前，可以进行相关配置（without_quorum_policy），有如下配置选项：



1、stop：直接停止服务；
2、ignore：忽略，以前运行什么服务现在还运行什么（双节点集群需要配置该选项）；
3、Freeze：冻结，保持事先建立的连接，但不再接收新的请求；
4、suicide：kill掉服务。


3-4-2、集群脑裂（Split-Brain）和资源隔离（Fencing）

       脑裂是因为集群分裂导致的，集群中有节点因为处理器忙或者其他原因暂时停止响应时，与其他节点间的心跳出现故障，但这些节点还处于active状态，其他节点可能误认为该节点"已死"，从而争夺共享资源（如共享存储）的访问权，分裂为两部分独立节点。


       脑裂后果：这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。
       脑裂解决：上面3-1-1、3-1-2的方法也能一定程度上解决脑裂的问题，但完全解决还需要资源隔离（Fencing）。
       资源隔离（Fencing）：
              当不能确定某个节点的状态时，通过fencing把对方干掉，确保共享资源被完全释放，前提是必须要有可靠的fence设备。

   节点级别：
            STONITH（shoot the other node in the head，爆头。硬件方式），直接控制故障节点的电源，绝对彻底。
    资源级别：

            例如：FC SAN switch（软件方式）可以实现在存储资源级别拒绝某节点的访问


4、高可用集群工作模型
4-1、Active/Passive：主备模型

       一个活动主节点，另一个不活动作为备用节点，当主节点故障，转移到备节点，这时备节点就成为了主节点。备节点完全冗余，造成一定浪费。如下图，mysql、DRBD主从节点间还要进行同步：


4-2、Active/Active：双主模型

       两个节点都是活动的，两个节点运行两个不同的服务，也互为备用节点。也可以提供同一个服务，比如ipvs，前端基于DNS轮询。这种模型可以使用比较均衡的主机配置，不会造成浪费。

4-3、N+1

      N个活动主节点N个服务，一个备用节点。这需要额外的备用节点必须能够代替任何主节点，当任何主节点故障时，备节点能够负责它的角色对外提供相应的服务。如下图，最后一个备用节点可以作为前两台主节点的DRBD和第三台主节点的MYSQL提供备用功能：


4-4、N+M

      N个活动主节点，M个备用节点。像上面的N+1模型，一个备用节点可能无法提供足够的备用冗余能力，备用节点的数量M是成本和可靠性要求之间的折衷。
      也有一种说法：N-M: N个节点M个服务， N>M， 活动节点为N， 备用节点为N-M。

4-5、N-to-1

      这和N+1一样，也是N个活动主节点，一个备用节点；不同是的备用节点成为主节点只是暂时的，当原来故障的节点修复后，必须回转才能正常工作。

4-6、N-to-N

      N个主节点N个备用节点。这是A/A双主和N + M模型的组合，N节点都有服务，如果一个坏了，剩下的每个节点都可以作为替代提供服务。如下图，当共享存储是可用的，每一个节点都可能会被用于故障切换。起搏器甚至可以运行服务的多个副本，以分散工作量。


5、高可用集群架构层次
    
5-1、节点主机层 

       这一层主要是正在运行在物理主机上的服务，高可用集群相关的软件运行在各主机上，集群资源也是在各主机上。

5-2、Messaging and Membership Layer

       信息传递层，传递集群信息的一种机制，通过监听UDP 694号端口，可通过单播、组播、广播的方式，实时快速传递信息，传递的内容为高可用集群的集群事务，例如：心跳信息，资源事务信息等等，只负责传递信息，不负责信息的计算和比较。


       成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。

5-3、CRM（Cluster Resource Manager）

      集群资源管理器层，它主要是用来提供那些不具有高可用的服务提供高可用性的。它需要借助Messaging Layer来实现工作，因此工作在Messaging Layer上层。
      资源管理器的主要工作是收集messaging Layer传递的节点信息，并负责信息的计算和比较，并做出相应的动作，如服务的启动、停止和资源转移、资源的定义和资源分配。
      在每一个节点上都包含一个CRM，且每个CRM都维护这一个CIB（Cluster Information Base，集群信息库），只有在主节点上的CIB是可以修改的，其他节点上的CIB都是从主节点那里复制而来的。
       CRM会推选出一个用于计算和比较的节点，叫DC（Designated coordinator）指定协调节点，计算由PE（Policy Engine）策略引擎实现，计算出结果后的动作控制由TE（Transition Engine）事务引擎实现。
       在每个节点上都有一个LRM（local resource manager）本地资源管理器，是CRM的一个子功能，接收TE传递过来的事务，在节点上采取相应动作，如运行RA脚本等。

5-4、RA（Resource Rgent）

      资源代理层，简单的说就是能够集群资源进行管理的脚本，如启动start，停止stop、重启restart和查询状态信息status等操作的脚本。LRM本地资源管理器负责运行。
      资源代理分为：



1、Legacy heartbeat（heatbeat v1版本的资源管理）；
2、LSB（Linux Standard Base），主要是/etc/init.d/*目录下的脚,start/stop/restart/status；
3、OCF（Open Cluster Famework），比LSB更专业，更加通用,除了上面的四种操作，还包含monitor、validate-all等集群操作，OCF 的规范在http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD。
4、STONITH：实现节点隔离


6、高可用集群软件
6-1、Messaging Layer 集群信息层软件

1、heartbeat (v1, v2)
2、heartbeat v3

可以拆分为：heartbeat, pacemaker, cluster-glue

3、corosync

从OpenAIS分离的项目。

4、cman 
5、keepalived

一般用于两个节点的集群


6、ultramokey

6-2、CRM集群资源管理器软件

1、Haresource

heartbeat v1 v2包含，使用文本配置接口haresources

2、crm 

heartbeat v2包含，可以使用crmsh或者heartbeat-gui来进行配置

3、pacemaker 

heartbeat v3分离出来的项目，配置接口：CLI：crm、pcs和GUI：hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs

4、rgmanager 

Cman包含，使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性，也可以使用RHCS（Redhat Cluster Suite）套件来进行管理：Conga的全生命周期接口，Conga（luci/ricci）先安装后，可用其安装高可用软件，再进行配置。


6-3、常用组合

heartbeat v2+haresource(或crm) (说明：一般常用于CentOS 5.X)
heartbeat v3+pacemaker (说明：一般常用于CentOS 6.X)
corosync+pacemaker (说明：现在最常用的组合)
cman + rgmanager (说明：红帽集群套件中的组件，还包括gfs2,clvm)
keepalived+lvs (说明：常用于lvs的高可用)


7、共享存储

       高可用集群多节点都需要访问数据，如果各节点访问同一个数据文件都是在同一个存储空间内的，就是说数据共享的就一份，而这个存储空间就共享存储。


       如Web或Mysql高可用集群，他们的数据一般需要放在共享存储中，主节点能访问，从节点也能访问。当然这也不是必须的，如可以通过rsync、DRBD来同步分别存储在主、从节点上的块数据，而且相对共享存储实现成本更低，具体使用什么需要根据实际场景来选择。下面我们就简单说一下共享存储的类型：

7-1、DAS（Direct attached storage，直接附加存储）

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


       这是设备块级别驱动上实现的共享，持有锁是在节点主机本地上的，无法通知其他节点，所以如果多节点活动模型的集群同时写入数据，会发生严重的数据崩溃错误问题，主备双节点模型的集群在分裂的时候了会出现问题；


       常用的存储设备：RAID 阵列、SCSI 阵列。

7-2、NAS（network attached storage，网络附加存储）

       文件级别交互的共享，各存储设备通过文件系统向集群各节点提供共享存储服务，是用C/S框架协议来实现通信的应用层服务。


       常用的文件系统：NFS、FTP、CIFS等，如使用NFS实现的共享存储，各节点是通过NFS协议来向共享存储请求文件的。

7-3、SAN（storage area network、存储区域网络)

        块级别的，将通信传输网络模拟成SCSI（Small Computer System Interface）总线来使用，节点主机（initiator）和SAN主机（target）都需要SCSI驱动，并借助网络隧道来传输SAN报文，所以接入到SAN主机的存储设备不一定需要是SCSI类型的。


        常用的SAN：FC光网络（交换机的光接口超贵，代价太高）、IPSAN（iscsi、存取快，块级别，廉价）。




经过写这篇文章，对高可用集群有了一个基本的认识，下面将会动手进行应用配置……

 
【参考资料】
1、《大型网站技术架构：核心原理与案例分析》

2、《从Paxos到Zookeeper ：分布式一致性原理与实践》

3、《大话存储Ⅱ—存储系统架构与底层原理极限剖析》

4、Pacemaker：http://clusterlabs.org/wiki/Pacemaker
5、High-availability cluster：https://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations|
6、Linux 高可用（HA）集群基本概念详解：http://www.linuxidc.com/Linux/2013-08/88522.htm
7、高可用集群基本概念与heartbeat文本配置接口：http://www.178linux.com/10982
8、高可用集群原理：http://boxinknown.blog.51cto.com/10435935/1673396
9、理解 OpenStack 高可用(HA) （4）: Pacemaker 和 OpenStack Resource Agent （RA）：http://www.cnblogs.com/sammyliu/p/5025362.html

高可用：设备可用性强，具有高可替代性，故障发生后，系统能马上恢复。

高性能：设备性能强，系统运算能力强，响应速度快。

高并发：设备并发能力强，具有同时处理多种事务的能力。

一个小型的网站，可以使用最简单的html静态页面就实现了，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

　　大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。

1、HTML静态化

　　其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

　　除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化、有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。

　　同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现。比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储在数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

2、图片服务器分离

　　大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

　　在应用服务器和图片服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持、尽可能少的LoadModule，保证更高的系统消耗和执行效率。

3、数据库集群、库表散列

　　大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

　　在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

　　上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。

　　我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。

　　sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4、缓存

　　缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。

　　架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。

　　网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也肯定有。

5、镜像

　　镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6、负载均衡

　　负载均衡将是大型网站解决高负荷访问和大量并发请求采用的高端解决办法。

　　负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。

（1）、硬件四层交换

　　第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。

　　第四层交换功能就像是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。

　　在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。“Yahoo中国”当初接近2000台服务器，只使用了三、四台Alteon就搞定了。

(2)、软件四层交换

　　大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。

　　软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的强壮性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。

　　一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。

　　对于大型网站来说，前面提到的每个方法可能都会被同时使用到，这里介绍得比较浅显，具体实现过程中很多细节还需要大家慢慢熟悉和体会。有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大。

7、最新：CDN加速技术

什么是CDN？

　　 CDN的全称是内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络“边缘”，使用户可以就近取得所需的内容，提高用户访问网站的响应速度。

　　CDN有别于镜像，因为它比镜像更智能，或者可以做这样一个比喻：CDN=更智能的镜像+缓存+流量导流。因而，CDN可以明显提高Internet网络中信息流动的效率。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等问题，提高用户访问网站的响应速度。

CDN的类型特点

　 　CDN的实现分为三类：镜像、高速缓存、专线。

　　镜像站点（Mirror Site），是最常见的，它让内容直接发布，适用于静态和准动态的数据同步。但是购买和维护新服务器的费用较高，还必须在各个地区设置镜像服务器，配备专业技术人员进行管理与维护。对于大型网站来说，更新所用的带宽成本也大大提高了。

　　高速缓存，成本较低，适用于静态内容。Internet的统计表明，超过80%的用户经常访问的是20%的网站的内容，在这个规律下，缓存服务器可以处理大部分客户的静态请求，而原始的服务器只需处理约20%左右的非缓存请求和动态请求，于是大大加快了客户请求的响应时间，并降低了原始服务器的负载。

　　CDN服务一般会在全国范围内的关键节点上放置缓存服务器。

　　专线，让用户直接访问数据源，可以实现数据的动态同步。

CDN的实例

　　举个例子来说，当某用户访问网站时，网站会利用全球负载均衡技术，将用户的访问指向到距离用户最近的正常工作的缓存服务器上，直接响应用户的请求。

　　当用户访问已经使用了CDN服务的网站时，其解析过程与传统解析方式的最大区别就在于网站的授权域名服务器不是以传统的轮询方式来响应本地DNS的解析请求，而是充分考虑用户发起请求的地点和当时网络的情况，来决定把用户的请求定向到离用户最近同时负载相对较轻的节点缓存服务器上。

　　通过用户定位算法和服务器健康检测算法综合后的数据，可以将用户的请求就近定向到分布在网络“边缘”的缓存服务器上，保证用户的访问能得到更及时可靠的响应。

　　由于大量的用户访问都由分布在网络边缘的CDN节点缓存服务器直接响应了，这就不仅提高了用户的访问质量，同时有效地降低了源服务器的负载压力。

附：某CDN服务商的服务说明

采用GCDN加速方式

　　采用了GCDN加速方式以后，系统会在浏览用户和您的服务器之间增加一台GCDN服务器。浏览用户访问您的服务器时，一般静态数据，如图片、多媒体资料等数据将直接从GCDN服务器读取，使得从主服务器上读取静态数据的交换量大大减少。

　　为VIP型虚拟主机而特加的VPN高速压缩通道，使用高速压缩的电信<==>网通、电信<==>国际（HK）、网通<==>国际（HK）等跨网专线通道，智能多线，自动获取最快路径，极速的动态实时并发响应速度，实现了网站的动态脚本实时同步，对动态网站有一个更加明显的加速效果。

　　每个网络运营商（电信、网通、铁通、教育网）均有您服务器的GCDN服务器，无论浏览用户是来自何处，GCDN都能让您的服务器展现最快的速度！另外，我们将对您的数据进行实时备份，让您的数据更安全！

8、降级

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

降级预案

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

错误：比如可用率低于90%,或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

降级按照是否自动化可分为：自动开关降级和人工开关降级。

降级按照功能可分为：读服务降级、写服务降级。

降级按照处于的系统层次可分为：多级降级。

降级的功能点主要从服务端链路考虑，即根据用户访问的服务调用链路来梳理哪里需要降级：

页面降级、页面片段降级、页面异步请求降级、服务功能降级、读降级、写降级

自动开关降级：超时降级、统计失败次数降级、故障降级、限流降级

人工开关降级：读服务降级、写服务降级

9、分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。

　　在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。应用层具体负责业务和视图的展示;服务层为应用层提供服务支持;数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。

　　分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。

　　所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。

10、限流

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。

    一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。

11、隔离

线程隔离：

线程隔离主要是指线程池隔离，在实际使用时，我们会把请求分类，然后交给不同的线程池处理。当一种业务的请求处理发生问题时，不会将故障扩散到其他线程池，从而保证其他服务可用。

进程隔离

由于传统的系统所有功能都集中在一个系统中，为了避免系统其中一个模块功能出现问题导致整个系统无法使用的情况发生，将其该系统拆分成多子系统实现物理隔离，故通过进程隔离使得某一个子系统出现问题时不影响到其他子系统。

集群隔离

随着调用方的增多，当秒杀（并发量特别大功能）类似的服务被刷新会影响到其他服务的稳定性时，应该考虑为秒杀（并发量特别大功能）类似的服务提供单独的服务集群，即分服务分组，这样当某一个分组出现问题时，不会影响到其他分组，从而实现了故障隔离愿景。

机房隔离

随着对系统可用性的要求，会进行多机房部署，每一个机房的服务都有自己的服务分组，本机房的服务应该只调用本机房的服务，不进行跨机房调用。其中，一个机房服务发生问题时，可以通过DNS/负载均衡将请求全部切到另一个机房，或者考虑服务能自动重试其他机房的服务，从而提升系统可用性。

读写隔离

为了提高数据访问，一般采用redis主从模式将读和写进群分离，在正常情况下，当主redis集群出现问题时，从redis集群还是可以用的，从而不影响用户的访问。

动静隔离

例如当用户访问如结算页时，如果JS/CSS等静态资源也在结算页系统中时，很可能因为访问量太大导致带宽被打满导致出现不可用。

为了不影响结算等用户操作的功能，将其JS/CSS等静态资源静态化与用户操作功能分开部署。

资源隔离

最常见的资源如磁盘、CPU、网络；对于宝贵的资源都会存在竞争问题。

我们可以使用JIMDB数据同步时要dump数据，SSD盘容量用了50%以上，dump到同一块磁盘时遇到了容量不足的问题，我们通过单独挂一块SAS盘来专门同步数据。还有如使用Docker容器时，有的容器写磁盘非常频繁，因此要考虑为不同的容器挂载不同的磁盘。

12、超时重试

在实际开发过程中，我们见过太多故障时因为没有设置超时或者设置得不对而造成的，而这些故障都是因为没有意识到超时设置的重要性而造成的。如果应用不设置超时，则可能会导致请求响应慢，慢请求积累导致连锁反应，甚至造成应用雪塌。而有些中间件或者框架在超时后进行重试（例如dubbo默认重试两次），读服务天然适合重试，但写服务大多不能重试（如写订单、支付等），重试次数太多会导致多倍请求流量。

例如模拟了Ddos攻击（分布式拒绝服务（DDoS:Distributed Denial of Service）攻击指借助于客户/服务器技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动DDoS,通常，攻击者使用一个偷窃帐号将DDoS主控程序安装在一个计算机上，在一个设定的时间主控程序将与大量代理程序通讯，代理程序已经被安装在网络上的许多计算机上。代理程序收到指令时就发动攻击。利用客户/服务器技术，主控程序能在几秒钟内激活成百上千次代理程序的运行。），后果可能是灾难，因此，务必设置合理的重试机制，并且应该和熔断、快速失败机制配合。所以在进行代码Review时，一定记得Review超时与重试机制。

13、自动化

具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。

14、冗余

网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。

15、安全

网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证;登录、交易需要对网络通信进行加密;为了防止机器人程序滥用资源，需要使用验证码进行识别;对常见的XSS攻击、SQL注入需要编码转换;垃圾信息需要过滤等。

16、集群

对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。

　　服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可;另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。

17、分布式

对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

　　在网站应用中，常用的分布式方案有一下几种.

　　分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。

　　分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力;通过使用独立域名加快浏览器并发加载的速度。

　　分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。

　　分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

18、压力测试

线下压力测试

通过如Jmeter,Apac,he ab 压力测试系统的某一个接口等（如登录、查询订单）或者某一个组件（例如数据库连接池），然后进行调优（如调优JVM参数，优化代码等），实现单个接口或者组件的性能最优。

线上压力测试

线上压力测试份方式非常多，按读分为读压、写压测和混合压测，按照数据仿真度分为仿真压力测试和引流压力测试，按照给用户提供服务分为隔离集群压力测试和线上集群压力测试。

19、系统优化和容灾

拿到全面的压力测试报告后，接下来就是分析报告，然后进行一些有针对性的优化，如硬件升级、系统扩容、参数调优、代码优化（代码同步改异步）、架构优化（如加缓存、读写分离、历史数据归档）等。在扩容时也需要考虑容灾，比如分组部署、跨机房部署。容灾是通过部署多组（单机房或多机房）相同系统，当其中一组出现问题时，可以切换到另一个分组，保证系统可用

20、应急预案

在系统压力测试之后发现一些系统瓶颈，在系统优化之后会提升系统吞吐量并降低响应时间，容灾之后的系统可用性得以保障，但还是会存在一些风险，如网络抖动、某台机器负载过高、某个服务变慢、数据库Load值过高，为了防止因为这些问题而出现系统雪崩，需要针对这些情况制定应急预案，从而在出现突发情况时，有响应的措施来解决掉这些问题。

应急预案可按照如下几步进行：首先进行系统分级，然后进行全链路分析、配置监控，最后制定应急预案。


转自：https://blog.csdn.net/u010900284/article/details/83541101