集群服务器

Zookeeper的介绍 ZK在分布式系统的应用 Zookeeper搭建 集群角色介绍 ZK的常用命令 一、Zookeeper的介绍 官方： ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。 二、ZK在分布式系统的应用 分布式配置中心 分布式job 服务注册与发现 存储数据 三、Zookeeper搭建 1）单机模式 官网下载： zookeeper官网 解压tar zxvf zookeeper-3.4.11.tar.gz 进入conf目录下：cp zoo_sample.cfg zoo.cfg 启动：进入bin目录下：sh zkServer.sh start 验证：在bin目录下：sh zkServer.sh status 或者使用jps -vm查看 连接：在bin目录下：sh zkCli.sh 2）集群模式（机器有限，使用伪分布式） 1、描述 伪分布式集群就是在一台机器部署多个zk应用，部署之前服务器需要有jdk环境。使用 java -version可以显示相关java信息才可以进行zookeeper搭建。 2、步骤 官网下载： zookeeper官网 解压tar zxvf

1．YARN产生背景 1.1 MapReduce本身存在的问题 JobTracker单点故障问题；如果Hadoop集群的JobTracker挂掉，则整个分布式集群都不能使用了。 JobTracker承受的访问压力大，影响系统的扩展性。 不支持MapReduce之外的计算框架，比如Storm、Spark、Flink等。 1.2 MRv1 JobTracker：用户程序提交了一个Job，任务（job）会发给JobTracker，JobTracker是Map-Reduce框架中心，它负责把任务分解成map和reduce的作业（task）；需要与集群中的机器定时心跳(heartbeat)通信；需要管理那些程序应该跑在那些机器上；需要管理所有job失败、重启操作。 Tasktracker是JobTracker和Task之间的桥梁，Tasktracker可以配置map和reduce的作业操(task slot)。TaskTracker通过心跳告知JobTracker自己还有空闲的作业Slot时，JobTrackr会向其分派任务。它将接收并执行JobTracker的各种命令:启动任务、提交任务、杀死任务。 TaskScheduler工作再JobTracker上。根据JobTracker获得的slot信息完成具体的分配工作，TaskScheduler支持多种策略以提高集群工作效率。 局限性

运行环境：CentOS 7(版本号:1503) Redis版本：3.0.5 参考文档：① http://www.redis.cn/topics/cluster-tutorial.html ② http://www.linuxidc.com/Linux/2015-08/121845.htm 注意：redis集群需要至少6个节点，也就是六台服务器。如果服务器数量不足可在每台服务器上建立多个节点，如2台服务器，每台服务器上建立3个节点 一、 为所有服务器安装Redis 1.使用ssh工具连接服务器，下载和解包。 cd /usr/local/ wget http://download.redis.io/releases/redis-3.0.5.tar.gz tar -zxvf redis-3.0.5.tar.gz 2.重命名文件夹 mv redis-3.0.5 redis 3.编译安装 cd redis make && make install 在这里可能会碰到一个错误导致编译不过(如下) make[1]: Entering directory `/redis/src' CC adlist.o In file included from adlist.c:34: zmalloc.h:50:31: error: jemalloc/jemalloc.h: No such file or

RabbitMQ实现集群高可用 前言 为什么搭建rabbitmq集群？ rabbitmq集群有那些模式？ 如何搭建Rabbitmq集群？ rabbitmq镜像高可用策略有那些？ RabbitMQ这款产品本身的优点众多，大家最看好的便是他的异步化提高系统抗峰值能力，然后便是系统及功能结构解耦，既然它如此重要，那么我们就需要考虑它的高可用性。 rabbitmq有3种模式 ： 单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已，生产上肯定不能用。 普通模式：普通集群就是在多台机器上启动多个实例。每个队列只会存在其中的一个实例上，然后所有实例同步这些队列的元数据。消费者在进行消费的时候，如果连接的实例上恰好不是队列所在的实例，就会根据队列的元数据去队列所在实例上拉取数据 由此可知，集群模式并没做到分布式，如果队列所在的实例宕机了，会导致接下来其他实例就无法从那个实例拉取消息，所以集群主要是提高吞吐量的 镜像模式:把需要的队列做成镜像队列，存在与多个节点属于** RabbitMQ的HA方案 。**该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉

配置阿里云SLB全站HTTPS集群（以下内容仅为流程，信息可能有些对应不上） 1 登录阿里云购买两台实例 1.1 按量付费购买两台实例 1.2 配置网络可以不选择分配外网 1.3 自定义密码 1.4 购买完成 1.5 实例列表 2 购买SLB实例 2.1 按量付费购买SLB实例 2.2 SLB实例列表 3. 配置负载均衡实例端口转发 3.1 配置SLB服务器5555端口转发到服务器的22端口（另一台同样配置6666端口转发） 3.2 配置SLB服务器80端口负载均衡到两台服务器的80端口 4. 配置服务器 4.1 利用端口转发连接没有外网的服务器实例（两台机器） 4.2 修改主机名并安装nginx（两台机器） [root@iZuf6ghkj6xlvmskd7k9e7Z ~]# hostnamectl set-hostname test01 [root@iZuf6ghkj6xlvmskd7k9e7Z ~]# bash [root@test01 ~]# yum install -y nginx 4.3 配置并启动nginx（两台机器） [root@test01 ~]# vim /etc/nginx/nginx.conf server { listen 80; server_name test.mumusir.com; root /usr/share/nginx/html; }

目前为止Redis官方支持的三种集群方式 （以下内容仅为作者的个人理解，如果存在错误欢迎指出） 1：Redis主从配置（容错率较低，master节点宕机后整个服务就不可用了。） 2：Redis哨兵模式（是在主从集群的升级版本，支持master自动切换。不支持横向扩容） 3：Cluster集群模式（需要升级至Redis 3.0） Redis主从配置 简介： 主：一个Redis服务器为Master节点。负责写入数据，和同步数据至从节点。 从：一台或者多台Redis服务器为Slave节点。不支持写入数据，可以提供同读取数据的服务（但是可能会出现主从数据不一致的情况） （缺点：不能水平扩容，并且该模式的高可用特性都会受到Master主节点内存的限制。） 主从配置数据同步的过程简介： 当Slave节点首次启动时，会主动向Master节点发起socket连接。在连接成功后会发送SYNC命令进行数据同步（该同步是全量同步），之后主节点会每隔10秒钟（默认配置）向从节点发送PING命令（心跳）来保证连接的有效性。从节点会每隔1秒钟（默认配置）向主节点发送REPLCONF ACK命令来维护数据偏移量的offset。之后会从节点会向主节点发送PSYNC命令来同步增量数据（如果一切正常的情况下是进行增量复制。但是具体是进行全量复制还是，增量复制有很多种情况决定）。

实践中会发现，生产环境中使用单个 Docker 节点是远远不够的，搭建 Docker 集群势在必行。然而，面对 Kubernetes, Mesos 以及 Swarm 等众多容器集群系统，我们该如何选择呢？它们之中，Swarm 是 Docker 原生的，同时也是最简单，最易学，最节省资源的，比较适合中小型公司使用。 Docker Swarm 介绍 Swarm 在 Docker 1.12 版本之前属于一个独立的项目，在 Docker 1.12 版本发布之后，该项目合并到了 Docker 中，成为 Docker 的一个子命令。目前，Swarm 是 Docker 社区提供的唯一一个原生支持 Docker 集群管理的工具。它可以把多个 Docker 主机组成的系统转换为单一的虚拟 Docker 主机，使得容器可以组成跨主机的子网网络。 Docker Swarm 是一个为 IT 运维团队提供集群和调度能力的编排工具。用户可以把集群中所有 Docker Engine 整合进一个「虚拟 Engine」的资源池，通过执行命令与单一的主 Swarm 进行沟通，而不必分别和每个 Docker Engine 沟通。在灵活的调度策略下，IT 团队可以更好地管理可用的主机资源，保证应用容器的高效运行。 Docker Swarm 优点 任何规模都有高性能表现 对于企业级的 Docker Engine

nginx 是一个http服务器，是由俄罗斯人发明的，目前主流的服务器，作为负载均衡服务器，性能非常好，最高支持5万个并发连接数，在淘宝被广泛使用（据说被淘宝的工程师优化到单机200万的并发，非常的厉害） 单个tomcat最大支持的用户并发量默认是150，在测试过程中250左右开始会有性能的问题 举个栗子，有3台tomcat，有N多请求同时经过nginx的时候，nginx作为一个路由，把请求分别分发给这3台tomcat，以此减少tomcat负重 作为集群，当其中一台tomcat宕机，出现故障，那么nginx将会自动排除这个服务 tomcat 与 nginx 之间通过ajp协议，这个协议提供很高的通信速度以及性能 另外，nginx也能够存放静态资源，项目中会存在很多图片，以及静态页面，如果把这些静态资源放入nginx中，那么性能会提高，速度是毫秒级别的，非常快 在动静分离的项目中，所有静态资源（HTML, CSS, JavaScript）都放入此服务器中，客户端请求到nginx，这样将会拦截大量的非动态请求，以此提高性能 工作原理： 在upstream bakend 中配置多个tomcat服务器，每个请求按照不同的时间顺序去请求不同的tomcat，如果在某一时段中有tomcat挂了，那么会被自动剔除 ip_hash：主要用于解决session问题，使用后

1.为什么需要Session共享？ 随着互联网的日益壮大,单服务器单数据库早已经不能满足实际需求。目前大多数大型网站的服务器都采用了分布式服务集群的部署方式，所谓集群，就是让一组计算机服务器协同工作，解决大并发,大数据量瓶颈问题。但是在服务集群中，session共享往往是一个比较头疼的问题。因为session是在服务器端保存的，如果用户跳转到其他服务器的话，session就会丢失。 如果你的网站是存放在一个机器上，那么是不存在这个问题的，因为会话数据就在这台机器，但是如果你使用了负载均衡把请求分发到不同的机器呢？ 这个时候会话id在客户端是没有问题的，但是如果用户的两次请求到了两台不同的机器，而它的session数据可能存在其中一台机器，这个时候就会出现取不到session数据的情况，于是session的共享就成了一个问题。 传统的应用服务器，如tomcat、jboss等，其自身所实现的session管理大部分都是基于单机的， 对于大型分布式网站来说，支撑其业务的远远不止一台服务器，而是一个分布式集群， 请求在不同服务器之间跳转。那么，如何保持服务器之间的session同步呢？ 2.如何实现Session共享？ Session共享有多种解决方法，常用的有四种：客户端Cookie保存、服务器间Session同步、使用集群管理Session、把Session持久化到数据库。 2.1

转自：http://book.51cto.com/art/201405/439557.htm 先来看一下什么是Session。 用户使用网站的服务，基本上需要浏览器与Web 服务器的多次交互。HTTP 协议本身是无状态的，需要基于HTTP 协议支持会话状态（Session State）的机制。而这样的机制应该可以使Web 服务器从多次单独的HTTP 请求中看到“会话”，也就是知道哪些请求是来自哪个会话的。具体实现方式为：在会话开始时，分配一个唯一的会话标识（SessionId），通过Cookie 把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉Web 服务器请求是属于哪个会话的。在Web 服务器上，各个会话有独立的存储，保存不同会话的信息。如果遇到禁用Cookie 的情况，一般的做法就是把这个会话标识放到URL 的参数中。我们可以通过图2-8 来看一下上述过程。 当我们的应用服务器从一台变到两台后，如同图2-7 中的结构，我们就会遇到Session的问题了。具体是指什么问题呢？ 我们来看图2-9，当一个带有会话标识的HTTP 请求到了Web 服务器后，需要在HTTP请求的处理过程中找到对应的会话数据（Session）。而问题就在于，会话数据是需要保存在单机上的。 在图2-9 所示的网站中，如果我第一次访问网站时请求落到了左边的服务器，那么我的Session