高可用

Zabbix高可用搭建系列： 一、Zabbix高可用架构 二、编译安装Zabbix 三、实现Zabbix高可用 四、MySQL主主同步与高可用 1.KeepAlived简介 Keepalived是Linux下一个轻量级别的高可用解决方案。高可用(High Avalilability,HA)，其实两种不同的含义：广义来讲，是指整个系统的高可用，狭义的来讲就是主机与主机间的冗余和接管，Keepalived起初是为LVS设计的，专门用来监控集群系统中各个服务节点的状态，它根据TCP/IP参考模型的第三、第四层、第五层交换机制检测每个服务节点的状态，如果某个服务器节点出现异常，或者工作出现故障，Keepalived将检测到，并将出现的故障的服务器节点从集群系统中剔除，这些工作全部是自动完成的，不需要人工干涉，需要人工完成的只是修复出现故障的服务节点。后来Keepalived又加入了VRRP的功能，VRRP（Vritrual Router Redundancy Protocol,虚拟路由冗余协议)出现的目的是解决静态路由出现的单点故障问题，通过VRRP可以实现网络不间断稳定运行，因此Keepalvied 一方面具有服务器状态检测和故障隔离功能，另外一方面也有HA cluster功能，我们这儿使用的就是VRRP的功能。 2.实现zabbix-server高可用 Master：192.168

Zabbix高可用搭建系列： 一、Zabbix高可用架构 二、编译安装Zabbix 三、实现Zabbix高可用 四、MySQL主主同步与高可用 1.主主同步 Master：192.168.164.152 ~ ] # cat / etc / my . cnf #我们这儿使用GTID实现复制 [ mysqld ] datadir = / opt / mysql / data basedir = / opt / mysql socket = / tmp / mysql . sock symbolic - links = 0 skip - name - resolve slave_skip_errors = 1062 #跳过 1062 错误， 1062 错误是指一些主键重复 server_id = 1 #数据库唯一ID，主从ID不能相同 log - bin = / opt / mysql / log / binary - log #开启binlog日志 relay - log = / opt / mysql / log / relay - log #开启relay日志 binlog_format = mixed #复制模式，混合复制 sync_binlog = 1 #开启binlog日志同步到磁盘 auto - increment - increment = 2 #自增步长 auto -

大型站点高并发架构技术 高并发: 高并发主要是由于网站PV访问量大，单台服务器涌承载大量访问所带来的压力，所以会采用多台服务器进行分流，采用服务器集群技术，对于每个访问会被发送到哪台服务器，我们采取负载均衡策略，常见的技术有LVS，由于网站中有大量的静态页面，所以采用缓存服务器和反向代理技术，包括HAPROXY，REDIS,数据库可以采用数据库集群，进行读写分离，缓解数据库压力。 大型站点高并发架构就是利用负载均衡技术、反向代理技术、数据库集群、web服务器集群、Nosql技术等，以实现单台数据器不能达到的并发量，换句话说就是用一群屌丝代替一个高富帅。 1.大型站点高并发架构是为了解决百万千万级PV带来的性能瓶颈。 2.出现高并发架构的原因是大型网站发现在巨量pv下买更多更好的服务器已经无法简单的解决问题，只能从架构 上想办法来，充分发挥设备的效能。 3. 高可用解决方案（corosync,pacemaker,KeepAlived）负载均衡（LVS）缓存服务（Varnish）反向代理（haproxy）web服务器（Apache，Nginx，Tomcat）站点架构（Lamp，Lnmp） 什么是大型站点 大型站点高并发架构。首先，什么是大型站点，大型站点至少有两个特点（1）访问量大，淘宝的每日PV有几十亿（2）后台服务器多，淘宝后台服务器据说有十多万台。然后，大型网站的高并发架构

自从activemq5.9.0开始，activemq的集群实现方式取消了传统的Master-Slave方式，增加了基于zookeeper+leveldb的实现方式，其他两种方式：目录共享和数据库共享依然存在。本文主要阐述基于zookeeper和leveldb搭建activemq集群，这里需要特别提醒，本文实现的集群仅提供主备功能，避免单点故障，没有负载均衡功能。 下面开始我们的征途。 一、搭建zookeeper集群 关于搭建zookeeper集群的文章请参考： zookeeper的集群模式下的安装和配置 。 本文使用zookeeper3.4.6，3台虚拟机：192.168.2.161, 192.168.2.145, 192.168.2.146，zookeeper使用其默认端口：2181。 zookeeper集群搭建完成之后，我顺便搭建了两套监控系统：taokeeper-monitor和node-zookeeper-browser。前者是淘宝开源的一套监控zookeeper的系统，用了之后感觉得到的有效信息不多，而且集群趋势图总是不显示；后者是用nodejs实现的zookeeper节点数据查看系统，虽然页面不太美观，但是实用。 图 1. taokeeper-monitor界面 图 2. node-zookeeper-browser界面 二、搭建activemq集群 1、安装

1、Eureka高可用原理 基于两两注册的方式，将多个Eureka注册中心相互注册，实现Eureka的高可用。 2、Eureka高可用实现 假设当前在服务器A（Eureka-1）、服务器B（Eureka-2）、服务器C（Eureka-3）分别部署了三个Eureka注册中心，这三个Eureka实例的注册地址分别为： Eureka-1： http://192.168.0.1:8761/eureka/ Eureka-2： http://192.168.0.2:8761/eureka/ Eureka-3： http://192.168.0.3:8761/eureka/ 这三个Eureka注册中心处于不同的IP地址服务器上：192.168.0.1，192.168.0.2，192.168.0.3； 使用IntelJ IDEA打开着三个项目对应的application.yml配置文件，分别添加如下配置： （1）Eureka-1的application.yml文件 # Eureka-1号注册中心：向2号和3号Eureka注册 eureka: client: service-url: defaultZone: http://192.168.0.2:8761/eureka/,http://192.168.0.3:8761/eureka/ Eureka-1号注册中心向192.168.0.2，192

随着云计算的快速发展，企业上云已经成为了一种趋势，不仅有越来越多的企业在关注和咨询 云桌面 这一方面的事情，同时有很多的企业已经在开始享受云桌面这一新的应用，面对这一趋势企业要如何才能更好的使用好它呢？IT老兵根据多年的经验告诉大家，企业在部署云桌面前做好这几点很重要。 首先安全性，数据资源对于企业来说至关重要，如何确保企业在享受云桌面带来的优势的同时保证数据的安全，是目前大多数企业最为关心的话题，根据禹龙云多年的行业经验发现，企业最为关心的就是在使用云桌面时，除了内部要确保员工不能通过U盘等存储工具进行随意拷贝，以及访问重要数据需要授权之外，对外还要确保企业数据不被网络病毒的入侵从而造成数据的泄露和丢失。数据是企业的重中之重稍有不慎就有可能给企业带来重大的损失。 其次高可用，所谓高可用的意思就是当我们的服务器出现故障时，它可以通过高可用快速的进行数据的备份、把数据迁移到另外一台服务器上保障数据的安全性和业务的连续性。减少停工时间，保持其服务的高度可用性；同时当企业有新的员工增加时可以快速的为新的员工提供全新的桌面使用，从而提高企业的运维管理效率和可靠性以及降低IT运维工作中的人为风险。 第三经济性，当前云桌面厂家有很多它的功能也是多种多样的，企业在部署时需要从它的经济性出发，比如对于资金比较紧张的企业来说前期可以考虑租赁的模式，既可以享受云计算的成果又可以节省前期的经济投入

前言 Redis 是一个高性能的 key-value 数据库，现时越来越多企业与应用使用 Redis 作为缓存服务器。楼主是一枚 JAVA 后端程序员，也算是半个运维工程师了。在 Linux 服务器上搭建 Redis ，怎么可以不会呢？下面楼主就带着大家从0开始，依次搭建： Redis 单机服务器 -> Redis 主从复制 -> Redis-Sentinel高可用 。逐步搭建出高可用的Redis缓存服务器。 搭建Redis 1. 下载并解压 首先从 Redis 官网下载 Redis 并解压，楼主使用的版本是4.0.2。依次执行如下命令： cd /opt wget http://download.redis.io/releases/redis-4.0.2.tar.gz tar -zcvf redis-4.0.2.tar.gz 如果没有安装 gcc 依赖包，则安装对应依赖包 yum install -y gcc-c++ tcl 2. 编译并安装 下载并解压完毕后，则对源码包进行编译安装，楼主的 Redis 安装路径为 /usr/local/redis ，同学们可以自行修改语句： make install PREFIX=你想要安装的路径 cd /opt/redis-4.0.2 make install PREFIX=/usr/local 复制 Redis 相关命令到 /usr/sbin

用 Hystrix 构建高可用服务架构 Hystrix 是什么？ 在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是 依赖服务 ，有的时候某些依赖服务出现故障也是很正常的。 Hystrix 可以让我们在分布式系统中对服务间的调用进行控制，加入一些 调用延迟 或者 依赖故障 的 容错机制 。 Hystrix 通过将依赖服务进行 资源隔离 ，进而阻止某个依赖服务出现故障时在整个系统所有的依赖服务调用中进行蔓延；同时Hystrix 还提供故障时的 fallback 降级机制。 总而言之，Hystrix 通过这些方法帮助我们提升分布式系统的可用性和稳定性。 Hystrix 的历史 Hystrix 是高可用性保障的一个框架。Netflix（可以认为是国外的优酷或者爱奇艺之类的视频网站）的 API 团队从 2011 年开始做一些提升系统可用性和稳定性的工作，Hystrix 就是从那时候开始发展出来的。 在 2012 年的时候，Hystrix 就变得比较成熟和稳定了，Netflix 中，除了 API 团队以外，很多其他的团队都开始使用 Hystrix。 时至今日，Netflix 中每天都有数十亿次的服务间调用，通过 Hystrix 框架在进行，而 Hystrix 也帮助 Netflix 网站提升了整体的可用性和稳定性。 2018 年 11 月，Hystrix 在其

1、熟悉几个组件 1.1、apache —— 它是Apache软件基金会的一个开放源代码的跨平台的网页服务器，属于老牌的web服务器了，支持基于Ip或者域名的虚拟主机，支持代理服务器，支持安全Socket层(SSL)等等，目前互联网主要使用它做静态资源服务器，也可以做代理服务器转发请求(如：图片链等)，结合tomcat等servlet容器处理jsp。 1.2、ngnix —— 俄罗斯人开发的一个高性能的 HTTP和反向代理服务器。由于Nginx 超越 Apache 的高性能和稳定性，使得国内使用 Nginx 作为 Web 服务器的网站也越来越多，其中包括新浪博客、新浪播客、网易新闻、腾讯网、搜狐博客等门户网站频道等，在3w以上的高并发环境下，ngnix处理能力相当于apache的10倍。 参kao：apache和tomcat的性能分析和对比(http://blog.s135.com/nginx_php_v6/) 1.3、lvs —— Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。由毕业于国防科技大学的章文嵩博士于1998nian5月创立，可以实现LINUX平台下的简单负载均衡。了解更多，访问官网：http://zh.linuxvirtualserver.org/。 1.4、HAProxy —— HAProxy提供 高可用性 、

概述 本文是学习大型分布式网站架构的技术总结。对架构一个高性能、高可用、可伸缩及可扩展的分布式网站进行了概要性描述，并给出一个架构参考。文中一部分为读书笔记，一部分是个人经验总结，对大型分布式网站架构有较好的参考价值。 作者简介 烂皮猪，十余年工作经验，曾在Google等外企工作过几年，精通Java、分布式架构，微服务架构以及数据库，最近正在研究大数据以及区块链，希望能够突破到更高的境界 一、大型分布式网站架构技术 1、大型网站的特点 用户多，分布广泛 大流量，高并发 海量数据，服务高可用 安全环境恶劣，易受网络攻击 功能多，变更快，频繁发布 从小到大，渐进发展 以用户为中心 免费服务，付费体验 2、大型网站架构目标 高性能：提供快速的访问体验。 高可用：网站服务一直可以正常访问。 可伸缩：通过硬件增加/减少，提高/降低处理能力。 安全性：提供网站安全访问和数据加密、安全存储等策略。 扩展性：方便地通过新增/移除方式，增加/减少新的功能/模块。 敏捷性：随需应变，快速响应； 3、大型网站架构模式 分层：一般可分为应用层、服务层、数据层、管理层与分析层； 分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页、用户中心。 分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作。 集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问。 缓存