高可用

到目前为止，我们已经基本掌握了MQ的相关核心工作原理，同时一起设计了消息路由中心 （ 消息中间件路由中心你会设计吗，不会就来学学 ）和 Broker 主从架构( 消息队列Broker主从架构详细设计方案，这一篇就搞定主从架构 )，现在如果让你基于它的基本原理去设计一套 MQ 的生产部署架构出来，你准备怎么去思考呢？ 在这套架构中，你需要着重考虑的就是高可用问题，也就是说要保证整个系统在运行过程中，其中的任何一个环节宕机都不能影响整个系统。今天我们就来打卡如何设计一套高可用的消息中间件生产部署架构。 NameServer 集群化，保证路由高可用 首先，我们就是需要将NameServer 集群化部署，这里建议可以部署三台机器，这样可以充分的保证我们消息路由中心的可用性，哪怕其中的两台挂了，也还有一台 NameServer 在运行，这样就能保证我们 MQ 系统的稳定性。 前面我们也知道我们的NameServer 设计采用的是Peer-to-Peer 模式，即可以支持集群化部署的，每台机器是独立运行的，他们彼此直接不直接通信。 每台NameServer 机器都拥有所有的路由信息，包括所有的 Broker 节点信息、数据信息等 ，这样只要有一台 NameServer 存活就不会影响系统的稳定性。 所以，消息路由中心 NameServer 的集群化是我们整个MQ生产部署的第一步。

MHA高可用群集基本部署 MHA概述 MHA目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司youshimaton(现就职于Facebook公司)开发。 MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。 MHA还提供在线主库切换的功能，能够安全地切换当前运行的主库到一个新的主库中(通过将从库提升为主库),大概0.5-2秒内即可完成。 基本部署实验流程 一、实验前期准备 名称 角色 地址 centos7-2 master 192.168.142.203 centos7-3 slave1 192.168.142.132 centos7-min slave2 192.168.142.172 centos7-4 manger（监控端） 192.168.142.136 二、开始实验 1、所有服务器环境准备 安装epel源（不进行检查） [root@manger ~]# yum -y install epel-release --nogpgcheck 安装环境包 [root@manger ~]# yum -y install \ perl-DBD-MySQL \ perl-Config

一、什么是RHCS RHCS是Red Hat Cluster Suite的缩写，也就是红帽集群套件，RHCS是一个能够提供高可用性、高可靠性、负载均衡、存储共享且经济廉价的集群工具集合，它将集群系统中三大集群架构融合一体，可以给web应用、数据库应用等提供安全、稳定的运行环境。 更确切的说，RHCS是一个功能完备的集群应用解决方案，它从应用的前端访问到后端的数据存储都提供了一个行之有效的集群架构实现，通过RHCS提供的这种解决方案，不但能保证前端应用持久、稳定的提供服务，同时也保证了后端数据存储的安全。 RHCS提供了集群系统中三种集群构架，分别是高可用性集群、负载均衡集群、存储集群。 二、RHCS提供的三个核心功能 1， 高可用集群是RHCS的核心功能。当应用程序出现故障，或者系统硬件、网络出现故障时，应用可以通过RHCS提供的高可用性服务管理组件自动、快速从一个节点切换到另一个节点，节点故障转移功能对客户端来说是透明的，从而保证应用持续、不间断的对外提供服务，这就是RHCS高可用集群实现的功能。 2，RHCS通过LVS（Linux Virtual Server）来提供负载均衡集群，而LVS是一个开源的、功能强大的基于IP的负载均衡技术，LVS由负载调度器和服务访问节点组成，通过LVS的负载调度功能，可以将客户端请求平均的分配到各个服务节点，同时，还可以定义多种负载分配策略

1.什么是数据库高可用 1.1什么是高可用集群 N+1原则：N就是集群，1就是高可用，高可用的核心就是冗余；集群式保证服务最低使用标准的 1.2高可用集群的衡量标准 一般是通过系统的可靠性和可维护性来衡量的 MTTF:平均无故障时间，这是衡量可靠性的 MTTR：衡量系统的可维护性能 HA=MTTF/(MTTF+MTTR)*100% SLA: 99.999%-表示一年故障时间不超过6分钟 ；普通系统999到9999之间 1.3实现高可用的三种方式 主从方式(非对称) 这种方式的组织形式通常都是通过两个节和一个或多个服务器，其中一台作为主节点(active), 另外一台作为备份节点(standy),备份节点应该随时都在检测主节点的健康状况，当主节点发生故障，服务会自动切换到备份 节点保障服务正常运行 主从对外方式 对称方式 两个节点，都运行着不同的服务，且相互备份，相互检测对方的健康，当任意一个节点发送故障，这个节点上的服务就会 自动切换到另一个节点。 多机方式 包含多个节点多个服务，每个节点都要备份运行不同的服务，出现问题自动迁移 思考：公司的数据库服务主从是否自动切换？ 1.4 mysql数据的高可用实现 1.4.1 主从方式(非对称) 资源：两条同版本的mysql数据库 主从实现的内部运行原理和机制 1.主数据库服务会把数据的修改记录记录进binlog日志，binlog一定要打开

前言 通常来说，自动化运维有两种类型的运维方式： 定时的脚本任务， 比如定时更换云服务的 acess key secret , 定时检查 ecs 对外暴露的端口等 报警事件的紧急处理, 比如 ecs 实例发生异常重启 在传统的运维中，对于定时任务的处理通常用crontab脚本来实现，但是一旦管理的机器多了，必定会对脚本进行集中管理，这个时候对集中管理脚本的机器的可用性、脚本里面会散落密码明文等相关信息以及定时任务执行的记录都是一个很大的挑战；而对于事件驱动的报警处理，要么是通过短信报警告知运维人员，要么需要自建服务来处理报警信息, 无论是哪种方式，财务成本和运维成本都很大。本文探讨一种新的运维方式，利用函数计算做自动化运维，以极低的成本就可以获得一个高可靠，高质量的运维服务。 函数计算 阿里云 函数计算 是一个事件驱动的serverless计算服务。通过函数计算，您无需管理服务器等基础设施，只需编写代码并上传。函数计算会为您准备好计算资源，以弹性、可靠的方式运行您的代码，具体表现为： 无需采购和管理服务器等基础设施 按需付费，比如对运维管控这类低频调用的系统，财务成本通常能节约90%以上 专注业务逻辑的开发，能极大提高开发效率，比如 十分钟上线弹性高可用的图片处理服务 稳定高可用，毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力 提供日志查询、性能监控、报警等功能快速排查故障

根据阿里云《分布式文件存储系统技术及实现》整理而成。 1 分布式存储的客观需求 存储容量大 考虑对1PB数据进行排序，输入输出都需要1PB，算上中间临时数据，总共需要3-4PB。考虑多用户使用，则集群需要的总的存储空间大于100PB。 高吞吐量，如1PB数据排序需要在2小时内完成，每秒需要几十GB 数据可靠性，在数据规模增长时，降低数据丢失 服务高可用，99.95%意味着每年每年只有4-5小时不可用 高效运维，将日常硬件处理做成流程化，对监控报警要有完善支持 低成本，保证数据安全，正确服务稳定前提下，降低成本，才是分布式存储的核心竞争力 2 小概率事件对分布式系统挑战 单机系统下很少发生的事件，在大规模分布式系统中就会经常发生。 可能发生的小概率问题有： 1 磁盘错误 单机下运行稳定，集群下可能出现频繁。要考虑如何发现慢节点自动规避，发现机器宕机自动绕过。 2 Raid卡故障 发生在高可用节点上的事件。Raid卡是带有电池的缓存块，写入速度很快，能够在断电时保存数据。利用raid卡先缓存数据，之后再写入磁盘中。 3 网络故障 网络架构是一种树形结构，通过顶层交换机连接下层交换机，交换机下连接多台机器。 当上连交换机节点出错时，一部分主机将与其他主机分离，无法发挥作用。 可以将关键角色分布在不同的交换机下，将数据存储多份，某些机器失效时还可以访问到数据。 4 电源故障

本篇主要讲工作中的真实经历，我们怎么打造亿级日志平台，同时手把手教大家建立起这样一套亿级 ELK 系统。日志平台具体发展历程可以参考上篇 「从 ELK 到 EFK 演进」 废话不多说，老司机们座好了，我们准备发车了~~~ 整体架构 整体架构主要分为 4 个模块，分别提供不同的功能 Filebeat ：轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说：Filebeat就是新版的 Logstash-fowarder，也会是 ELK Stack 在 Agent 的第一选择。 Kafka : 数据缓冲队列。作为消息队列解耦了处理过程，同时提高了可扩展性。具有峰值处理能力，使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 Logstash ：数据收集处理引擎。支持动态的从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储以供后续使用。 Elasticsearch ：分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析，并能将这三者结合起来。Elasticsearch 基于 Lucene 开发，现在使用最广的开源搜索引擎之一，Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。 Kibana ：可视化化平台

近期，BoCloud博云收到了一封感谢信： 由BoCloud博云（全称：苏州博纳讯动软件有限公司）承建的某大型股份制银行信用卡中心（以下简称：卡中心）容器管理平台建设项目，在面对工期紧、任务重、要求高等诸多困难和压力下，我司高度重视与配合，在项目组全体成员的共同努力下，扎扎实实、勤勤恳恳、严谨负责、保质保量地完成了阶段性建设目标，为该卡中心应用的容器化工作提供了有力的技术支持与保障。 数字化转型发展到今天，其核心是促进业务变革与创新。伴随互联网+对银行业的深度渗入，使得To C场景与互联网的结合成为不可逆转的大趋势，银行业务的互联网化导致银行业务形态发生变化。传统IT架构已无法支撑互联网化业务的创新与变革，这意味着数字化转型时代，企业业务的敏捷与弹性，对企业底层IT架构支撑提出了更高的要求。 BoCloud博云根据该行信用卡中心应对互联网化业务快速发展和建设敏捷IT架构的需求，为卡中心建设了现代化容器PaaS云平台。该平台是基于DevOps和微服务理念，运用容器等技术，所搭建高可用、高弹性、响应快速开发迭代的容器PaaS云平台。建设内容主要分为： 1、建设高可用容器云PaaS平台 基于Docker和Kubernetes建设高可用容器云PaaS平台，通过平台提供分布式微服务框架与服务治理服务、容器生命周期管理、应用生命周期管理、智能运维、应用商店与分布式应用组件服务

原文: 搭建 RabbitMQ Server 高可用集群 阅读目录： 准备工作 搭建 RabbitMQ Server 单机版 RabbitMQ Server 高可用集群相关概念 搭建 RabbitMQ Server 高可用集群 搭建 HAProxy 负载均衡 因为公司测试服务器暂不能用，只能在自己电脑上重新搭建一下 RabbitMQ Server 高可用集群，正好把这个过程记录下来，以便日后查看。 公司测试服务器上的 RabbitMQ 集群，我搭建的是三台服务器，因为自己电脑空间有限，这边只能搭建两台服务器用作高可用集群，用的是 Vagrant 虚拟机管理工具。 环境介绍： RabbitMQ 节点 IP 地址 工作模式 node1 192.168.1.50 DISK CentOS 7.0 - 64位 node2 192.168.1.51 DISK CentOS 7.0 - 64位 整体架构： 1. 准备工作 首先，在 node1 服务器上，修改 vi /etc/hostname ： node1 在 node2 服务器上，修改 vi /etc/hostname ： node2 然后在 node1 服务器上，修改 vi /etc/hosts ： node1 192.168.1.50 node2 192.168.1.51 127.0.0.1 node1 ::1 node1 在 node2

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Mysql Fabric用来管理mysql服务，提供扩展性和容易使用的系统，管理mysql分片和高可用部署(当前实现了两个特性：高可用和使用数据分片的横向扩展，能单独使用或结合使用这两个特性。)。 架构图： 应用请求一个扩展的mysql连接器版本，使用XML-RPC协议访问Fabric，当前可以使用python和J连接器。Fabric管理启动 GTIDs(全局事务标识) 的mysql集合，检查和维护服务器之间的一致性。集合中的服务器叫高可用组。不属于Fabric高可用组的成员实例，叫备用存储(backing store)。 Fabric组织服务器在一个组(叫高可用组)，管理不同分片或简单提供高可用。例如如果使用标准异步复制，Fabric可以配置自动监控mysql服务状态。如果组中当前master错误，组中有一个服务器能变成master，它选择一个新的服务器做为master。 除了高可用操作如故障转移和切换，Fabric也允许分片操作，如分片创建和移除。 高可用和数据分片在两个层实现： 1、mysqlfabric进程处理任何管理请求，接收通过mysqlfabric命令行接口或其他支持XML/RPC接口的进程的管理任务。当使用HA特性，该进程能监控master服务器，当master故障时能进行故障恢复