高可用

写在前面的话 Hi，小伙伴们。继上期分享了如何用Docker部署自己的第一个SpringBoot应用之后，爱折腾的Storm还是耐不住性子，又折腾了一下SpringCloud应用的部署。在不使用Docker部署的时候呢，在本地模拟搭建一个高可用的Eureka集群是相当简单的。但是使用Docker部署的时候遇到了节点无法通信的问题，折腾半天终于完美解决这个问题，以此记录一下。 原因猜测 在项目中，我使用的是域名来区分不同的Eureka服务，本地Host绑定这些域名解析为127.0.0.1 但是部署到容易当中的时候就无法进行通信了，因此需要使用其他方法来建立通信。更改配置，使用ip并不是我的意图，虽然在实际生产环境是可以的，但是硬编码的风格显然不是最好的方案。 解决方案 经过资料的收集和整理，发现docker-compose能够解决这个问题，它能够自定义编排要发布的容易，包括容器依赖和通信并且统一部署。因此我在此使用它来解决上述的部署问题。 准备工作 首先我们需要构建Eureka服务，使用不同的端口，具体源码见我的开源项目 SpringBoot-Cloud-Learning : 分别绑定配置文件中的三个域名到host，解析到127.0.0.1 尝试直接启动这单个SpringBoot应用，是可以直接发布成分布式高可用Eureka集群的。 进入http://eureka-server-01

原文链接: https://blog.csdn.net/a964921988/article/details/82628478 　　 　　因为数据库部署在Linux上，需要做数据库集群实现高可用，而所有的PostgresqlHA方案中，流复制HA的可用性，部署成本，性能都是比较好的，而管理流复制集群的工具，pacemaker+corosync则是比较成熟可靠的，借此机会学习下Pacemaker。Pacemaker官网 http://clusterlabs.org/ 简要介绍 Pacemaker是Linux环境中使用最广泛的开源集群资源管理器 Pacemaker利用集群基础架构(Corosync或者Hearbeat)提供的消息和集群成员管理功能,实现节点和资源级别的故障检测和资源恢复,从而最大程度保证集群服务的高可用 从逻辑功能而言,pacemaker在集群管理员所定义的资源规则驱动下,负责集群中软件服务的全生命周期管理,这种管理甚至包括整个软件系统以及软件彼此之间的交互. Pacemaker在实际应用中可以管理任何规模的集群,由于其具备强大的资源依赖模型,这使得集群管理员能够精确描述和表达集群资源之间的关系(包括资源的顺序和位置等关系).同时,对于任何形式的软件资源,通过为其自定义启动与管理脚本(资源代理),几乎都能最为资源对象被Pacemaker管理.

​ ​本文是Spring Cloud专栏的第三篇文章，了解前两篇文章内容有助于更好的理解后面文章： Spring Cloud第一篇 | Spring Cloud前言及其常用组件介绍概览 Spring Cloud第二篇 | 使用并认识Eureka注册中心 ​ 一、Eureka注册中心高可用集群概述 1-1、传统架构 在微服务架构的这种分布式系统中,我们要充分考虑各个微服务组件的高可用性问题,不能有单点故障,由于注册中心Eureka本身也是一个服务,如果它只有一个节点,那么它有可能发生故障,这样我们就不能注册与查询服务了,所以我们需要—个高可用的服务注册中心,这就需要通过注册中心集群来解决。Eureka服务注册中心它本身也是一个服务,它也可以看做是一个提供者,又可以看做是一个消费者,我们之前通过配置eureka.client.register-with-eureka= false让注册中心不注册自己,但是我们可以向其他注册中心注册自己。 Eureka server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就会形成一组互相注册的服务注册中心,进而实现服务清单的互相同步,往注册中心A上注册的服务,可以被复制同步到注册中心B上,所以从任何一台注册中心上都能查询到已经注册的服务,从而达到高可用的效果。 ​ 二、Eureka注册中心高可用集群搭建

Nginx作为对外暴露的访问入口，必须具有高可用性，才能保证能够正常提供服务。单机Nginx服务的情况下，一旦出现宕机，将会导致需要Nginx路由的服务不可用访问，因此，保证Nginx服务的HA（high availabitlity）,也就是高可用性。 keepalived+lvs+nginx如何保证Nginx高可用？ keepalived是一个集群高可用的轻量级解决方案，关于他的介绍不多做描述，度娘很多。这里主要分析一下是如何保证nginx高可用。 我们都知道单机无法保证高可用，那么必定要实现主备或者集群来保证其可用性。Nginx本身并没有提供这样的功能，keepalived就是解决这种问题的一种实现方案。利用keepalived可以实现主备架构，在master故障发生时进行故障转移，选举备机作为新的master提供服务，同时结合keepalived提供的检测机制，可以保证Nginx的高可用。 按照我的理解，画了下面的架构图，下面看图分析。 首先是外部请求，客户端访问在 keepalived中的vrrp配置的对外暴露的虚拟ip，访问到 keepalived-service-master 所在服务器 server1 ，此时 keepalived-service-backup 服务做备用，不提供对外服务。 通过 keepalived-service-master 中的路由配置

1. 测试环境—高可用 两台nginx服务器，主：192.168.1.196，备：192.168.1.197 两台tomcat服务器：192.168.1.194 和 192.168.1.195 vip：192.168.1.198 nginx + keepalived实现HA部署图预览效果，如下图所示： 图1-nginx + keepalived实现HA部署   分别在nginx主服务器和nginx备服务器上部署keepalived软件，通过配置keepalived来模拟之前我们所说的三种状态： 正常状态，client通过vip发出请求时，由nginx主服务器提供服务，把请求转发到后台的tomcat服务器。 故障状态，当nginx主服务器宕机了，client通过vip发出请求时，由nginx备服务器提供服务，把请求转发到后台的tomcat服务器。 当nginx主服务器恢复时，nginx备服务器让出位置，由nginx主服务器继续提供服务。 2. 配置nginx主服务器 进入/etc/keepalived目录下，修改配置文件： nginx主服务器具体配置如下： ! Configuration File for keepalived #全局配置 global_defs { notification_email { #指定keepalived在发生切换时需要发送email到的对象，一行一个

一、场景需求 二、Keepalived 简要介绍 Keepalived 是一种高性能的服务器高可用或热备解决方案，Keepalived 可以用来防止服务器单点故障的发生，通过配合 Nginx 可以实现 web 前端服务的高可用。 Keepalived 以 VRRP 协议为实现基础，用 VRRP 协议来实现高可用性(HA)。VRRP(Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP 协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器 IP(一个或多个)，而在路由器组内部，如果实际拥有这个对外 IP 的路由器如果工作正常的话就是 MASTER，或者是通过 算法 选举产生，MASTER 实现针对虚拟路由器 IP 的各种网络功能， 如 ARP 请求，ICMP，以及数据的转发等；其他设备不拥有该虚拟 IP，状态是 BACKUP，除了接收 MASTER 的VRRP 状态通告信息外，不执行对外的网络功能。当主机失效时，BACKUP 将接管原先 MASTER 的网络功能。VRRP 协议使用多播数据来传输 VRRP 数据，VRRP 数据使用特殊的虚拟源 MAC 地址发送数据而不是自身网卡的 MAC 地址，VRRP 运行时只有 MASTER 路由器定时发送 VRRP 通告信息，表示 MASTER 工作正常以及虚拟路由器 IP(组)

MySQL数据库作为最基础的数据存储服务之一，在整个系统中有着非常重要的地位，因此要求其具备 高可用性 是无可厚非的。有很多解决方案能实现不同的 SLA （服务水平协定），这些方案可以保证 数据库服务器 在硬件或软件出现故障时服务继续可用。 高性能性需要解决的主要有两个问题，即如何实现 数据共享 或同步数据，另一个是如何处理failover，数据共享一般的解决方案是通过SAN（Storage Area Network）来实现，而 数据同步 可以通过 rsync 软件或 DRBD 技术来实现；failover的意思就是当服务器死机或出现错误时可以自动切换到其他备用的服务器，不影响服务器上业务系统的运行。本文重点介绍一下目前比较成熟的Mysql高性能解决方案。 1、主从复制解决方案 这是MySQL自身提供的一种高可用解决方案，数据同步方法采用的是MySQL replication技术。MySQL replication就是一个日志的复制过程，在复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器，简单说就是从服务器到主服务器拉取二进制日志文件，然后再将日志文件解析成相应的SQL在从服务器上重新执行一遍主服务器的操作，通过这种方式保证数据的一致性。 MySQL replication技术仅仅提供了日志的同步执行功能，而从服务器只能提供读操作，并且当主服务器故障时

最近在研究 负载均衡。目前研究的是keepalived+lvs模式 1、软件介绍 keepalived：顾名思义是保持存活，常用来搭建设备的高可用，防止业务核心设备出现单点故障。keepalived主要用作realserver的健康检查以及负载均衡主机和backup主机之间的故障漂移。 单点故障：在公司整个业务流程中，某一点出现故障就会导致整个系统架构不可用，单点故障常发生在数据库、核心业务系统等。对此我们的解决办法是对核心业务系统进行高可用负载均衡。 LVS：Linux Virtual Server，linux虚拟服务器，是一个虚拟的服务器集群系统。目前有三种负载均衡技术（VS/NAT、VS/TUN和VS/DR）；十种调度算法（rrr|wrr|lc|wlc|lblcr|lblc|dh|sh|sed|nq）。 2、实验拓扑图。 本次实验一共用到4台服务器，其中两台服务器用来搭建keepalived+lvs，另两台是对外提供服务的web服务器。 本次实验用到了5个ip地址。 Master：10.68.4.201 Backup：10.68.4.58 web1：10.68.4.198 web2:10.68.4.248 virtualIP：10.68.4.199 3、拓扑图介绍 keepalived--master和keepalived--backup

作者：中华石杉 Redis 哨兵集群实现高可用 哨兵的介绍 sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能： 集群监控：负责监控 redis master 和 slave 进程是否正常工作。 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。 哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。 哨兵的核心知识 哨兵至少需要 3 个实例，来保证自己的健壮性。 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。 哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了 2 个哨兵实例，quorum

作者：中华石杉 Redis 主从架构 单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。 redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发 redis replication 的核心机制 redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量； 一个 master node 是可以配置多个 slave node 的； slave node 也可以连接其他的 slave node； slave node 做复制的时候，不会 block master node 的正常工作； slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了； slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。 注意，如果采用了主从架构，那么建议必须开启