高可用

一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指， 通过设计减少系统不能提供服务的时间 。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。 方法论上，高可用保证的原则是“集群化”，或者叫“冗余” ：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是 通过“自动故障转移”来实现系统的高可用 。 接下来我们看下典型互联网架构中，如何通过 冗余+自动故障转移

原创 2016-12-05 58沈剑 架构师之路 一、什么是高可用 高可用HA （ High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务，我们说系统的可用性是100%。 如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。 很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。 百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度HA最高的褒奖。 二、如何保障系统的高可用 我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。 保证系统高可用，架构设计的核心准则是：冗余。 有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。

中间件 1.概述 应用场景 单体架构 如果一个模块升级，比如订单系统，整个系统都要升级 耦合度高，开发困难 分布式架构 后台由多个系统组成 多系统协同处理一个请求可以看成分布式系统 系统之间相互调用 ，用RPC远程调用的方式实现 但这样系统之间耦合度相对较高 为了解决耦合，实现更强的扩展性架构，分布式系统中引入了消息中间件 基于消息中间件的分布式系统架构 消息中间件 利用高效可靠的消息传递机制进行平台无关的数据交流 并基于数据通信来进行分布式系统的集成 通过提供消息传递和消息排队模型，可以在分布式环境下扩展进程间的通信 消息中间件的应用场景 跨系统数据传递、高并发流量削峰、数据异步处理...等等 常用的消息中间件 ActiveMQ、RabbitMQ、Kafka、RocketMQ 核心设计 本质： 一种具备 接收请求、保存数据、发送数据 等功能的 网络应用 。 和一般网络应用程序的区别是它主要负责数据的接收和传递，所以性能一般都高于普通程序。 5大核心组成： 协议 持久化机制 消息分发机制 高可用设计 高可靠设计 2.协议 协议是计算机之间通信时共同遵从的一组约定，都遵守相同的约定，计算机之间才能相互交流。 是对数据格式和计算机之间交换数据时必须遵守的规则的正式描述。 协议三要素： 语法：即数据与控制信息的结构或格式。 语义：即需要发出何种控制信息，完成何种动作以及做出何种响应。

## 分布式事务选型 ### 选型依据: - 多语言支持 - 微服务框架兼容程度 - 关系型数据库-MQ事务的支持 - 性能与稳定性以及是否支持高可用 - 业务代码侵入性 - 可拓展性 - 社区活跃度及影响力 ------ ### GTS概览 #### 针对不同的应用场景,GTS主要提供标准模式(AT)和自定义模式(MT)两种事务模式. - **AT模式**: GTS 最主要的事务模式,通过 GTS 基于 DRDS/RDS 数据源,对 sql 语句提供分布式事务的支持.他帮助应用以最小的改动代价来实现数据库的事务功能.AT 模式适用于 DRDS 分库分表/多数据库数据源/跨进程的多数据库数据源等几乎任何 DRDS 应用场景下的分布式事务. - **MT模式**: 提供给用户的一种可介入两阶段提交过程的一种模式.在这种模式下,用户可以根据自身的业务场景的需求自定义在 GTS 两阶段提交的过程中每阶段的具体行为.MT 模式提供了更多的可能性和灵活性,以达到特殊场景下的自定义特殊功能实现.**MT 模式不依赖于数据库,几乎满足任何事务场景.** #### 在 AT 和 MT 两种模式下,GTS 又提供了三种具体的使用方式: - **AT模式下,使用注解接入分布式事务** 这种方式只需要代码中依赖 GTS 的 SDK 即可.在希望引入分布式事务的方法上,仅需一行注解即可.适用场景包括

redis介绍 　　Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API的非关系型数据库。 传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。 Github 源码：https://github.com/antirez/redis Redis 官网：https://redis.io/ Redis支持的数据类型？ String字符串： 格式: set key value string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。 string类型是Redis最基本的数据类型，一个键最大能存储512MB。 Hash（哈希） 格式: hmset name key1 value1 key2 value2 Redis hash 是一个键值(key=>value)对集合。 Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边

写在前面的话 主从架构在一般情况下只能满足我们小公司业务并非一刻都不能中断服务。但是对于大型公司而言，对然数据丢失，数据库挂了，我们可以通过技术找回，修复。但是其中修复过程所消耗的时间是不被允许的。此时就需要引入高可用，以保证我们主库在宕机情况下有另外的数据库顶上去，以保证我们的服务 7 x 24 无间断。 数据库基本架构 在日常的小项目中，对于数据库的基本架构一般有以下选型： 1. 一主一从 / 一主多从 2. 多级主从 3. 双主 4. 循环复制 高级一点的 高性能 架构，也就是需要第三方服务帮助的架构： 1. 读写分离。常见的基于 MySQL Proxy 的有：Atlas / MySQL Router / ProxySQL / MaxScale 等 2. 分布式架构。常见的有：Cobar / TDDL / Mycat 等 最后就是 高可用 架构： 1. 单活 MMM，谷歌的 mysql-mmm。 2. 单活 MHA，日本人开发的 mysql-master-ha。 3. 多活 MGR，MySQL 5.7.17 以后官方新特性，基于组的复制。 4. 其它的 MariaDB，Percona 自己的 Cluster 架构。 MHA 环境搭建 对于 MHA，可以类比为 Zabbix，拥有 Server 端和 Agent 端，这里就是 Manager 和 Node 端。 整个架构至少包含

1.Keepalived高可用基本概述 1.什么是高可用 一般是指2台机器启动着相同的业务系统,当有一台机器down机了, 另外一台服务器能快速的接管, 对于访问的用户是无感知的。 2.高可用通常使用什么软件? 通常服务高可用我们选择使用keepalived软件实现 3.keepalived是如何实现高可用的？ keepalived软件是基于VRRP协议实现的。VRRP虚拟路由冗余协议，主要用于解决单点故障问题 4.那VRRP是如何诞生的，VRRP的原理又是什么？ 比如公司的网络是通过网关转换进行上网的，那如果该路由器故障了，网关无法转发报文了，此时所有人都将无法上网，这么时候怎么办呢？ 通常做法是给路由增加一台备节点，但问题来了?如果我们的主网关master故障了，用户是需要手动修改网关指向Backup，如果用户过多修改起来会非常的麻烦。 第一个问题: 假设用户将指向都修改到Backup路由器，那么Master路由器如果修复好了又该怎么办？ 第二个问题: 假设Master网关故障，我们将Backup网关配置为Master网关IP行不行? 其实上不行，因为PC第一次是通过ARP广播寻找到Master网关的Mac地址与IP地址，PC则会将Master网关的对应IP与MAC地址写入ARP缓存表中，那么PC第二次则会直接读取ARP缓存表中的MAC地址与IP地址，然后进行数据包的转发

在微服务架构这样的分布式环境中，我们需要充分的考虑发生故障的情况，所以在生产环境中我们必须对各个组件进行高可用部署。Eureka Server 的设计一开始就考虑了这个问题，在Eureka的服务治理设计中，所有的结点，既是服务提供方，也是服务消费方，服务注册中心也不例外。Eureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册自己。这样就可以形成一组相互注册的服务注册中心，以实现服务清单的相互同步，达到高可用的效果。 具体实现方式：搭建一个双节点的服务注册中心集群 如A ，B两个注册中心，在建立时分别注册到本身，并相互注册。 实现方法一： 环境为Ubuntu IntellijIDE jdk1.8 步骤1：建立eureak-server注册中心 点击File ，New，Project，选择左侧的Spring Initializr，并配置好JDK版本（一定为jdk1.8）点击next， 默认不变，再点击next，选择右侧的Spring Cloud Discovery，对应选择左侧的Eureka Server，点击next，输入项目名，点击finish 。需要分别建立两个工程。 不需要配置pom.xml 在节点A和B中配置@EnableEurekaServer。 @EnableEurekaServer @SpringBootApplication public

Eureka高可用注册中心 Eureka Server的设计一开始就考虑到了高可用的问题，在eureka服务治理设计中，所有的节点即是是服务提供方，也是服务消费方。 在部署高可用注册中心前我们先需要准备一下，本地环境。因为我们实例是在单台电脑上的，所以需要模拟堕胎服务器，我们需要修改一下本机的host文件。 windows的host文件在C:\Windows\System32\drivers\etc\hosts 在host文件后面加上 127.0.0.1 peer1 127.0.0.1 peer2 修改完成，我们就来尝试搭建高可用的服务注册中心集群。接着上一章的服务中心的基础上面扩展，来构建一个双节点服务注册中心集群。 在resource目录下面： 创建application-peer1.yml配置文件，作为peer1服务中心的配置，并将serviceId指向peer2. server: port: 8762 spring: application: name: service -register eureka: instance: prefer -ip -address : false hostname: peer1 client: fetch -registry : true register -with -eureka : true serviceUrl:

一、缓存概述 缓存是分布式系统中的重要组件，主要解决高并发，大数据场景下，热点数据访问的性能问题。提供高性能的数据快速访问。 1.1缓存的原理 （1） 将数据写入/读取速度更快的存储（设备）； （2） 将数据缓存到离应用最近的位置； （3） 将数据缓存到离用户最近的位置。 1.2缓存分类 在分布式系统中，缓存的应用非常广泛，从部署角度有以下几个方面的缓存应用。 （1） CDN缓存； （2） 反向代理缓存； （3） 分布式Cache； （4） 本地应用缓存； 1.3缓存媒介 常用中间件：Varnish，Ngnix，Squid，Memcache，Redis，Ehcache等； 缓存的内容：文件，数据，对象； 缓存的介质：CPU，内存（本地，分布式），磁盘（本地，分布式） 1.3缓存设计 缓存设计需要解决以下几个问题： （1） 缓存什么？ 哪些数据需要缓存：1.热点数据；2.静态资源； （2） 缓存的位置？ CDN，反向代理，分布式缓存服务器，本机（内存，硬盘） （3） 如何缓存的问题？ 过期策略 1.固定时间：比如指定缓存的时间是30分钟； 2.相对时间：比如最近10分钟内没有访问的数据； 同步机制 实时写入；（推） 异步刷新；（推拉） 二、CDN缓存 CDN主要解决将数据缓存到离用户最近的位置，一般缓存静态资源文件（页面，脚本，图片，视频，文件等）。国内网络异常复杂