集群服务器

1、tomcat集群 　　利用nginx对请求进行分流，将请求平均的分给不同的tomcat去处理，减少单个tomcat的负载量，提高tomcat的响应速度。 2、创建多个tomcat服务器（同一个服务器上） 　　① 先安装配置好1个tomcat服务器 　　　　安装tomcat： http://www.cnblogs.com/origalom/p/7643425.html 　　　　以普通用户运行tomcat： http://www.cnblogs.com/origalom/p/7666897.html 　　② 将安装好的tomcat复制一份 1 cd /usr/local/tomcat/ # 进入tomcat所在目录 2 cp -r tomcat8080/ tomcat8081 # 复制一份新的tomcat 3 chown -R tomcat:tomcat tomcat8081/ # 修改tomcat目录的所有者 　 ③ 修改daemon.sh 　　　　如果在创建tomcat时，在daemon.sh中设置了CATALINA_HOME等变量，则新拷贝的tomcat需要将这些变量设置成新的地址。 　　④ 修改端口，让新的tomcat可以正常运行 vim tomcat8081/conf/server.xml 　 　 修改tomcat内部的端口，使用一个未使用的端口号，一般可以往上加一： 　

Blog Address： https://blog.51cto.com/14669127 微软于2月13日发布了Azure共享磁盘的预览版本，这是业界第一个共享云块存储。Azure共享磁盘支持块存储工作负载迁移到云上，包括要求最高的企业应用程序，他们目前在存储区域网络（san）上运行，其中包括集群数据库，并行文件系统，持久容器和机器学习应用程序，这种独特的功能使客户能够运行对延迟敏感的工作负载，而不会影响快速故障转移和高可用性的部署模式，这包含为Windows 或基于Linux的集群文件系统构建的应用程序。有了Azure共享磁盘，客户现在可以灵活地将运行在Windows Server上的集群环境迁移到Azure，包含Windows Server 2008，该功能旨在支持SQL Server故障转移集群实例（FCI）、扩展文件服务器（SoFS），远程桌面服务器（RDS）和Windows 服务器上运行的SAP ASCS/SCS。 目前，Azure共享磁盘为在集群环境中运行的应用程序提供了一致的体验，这意味着当前利用SCSI持久保留的任何应用程序都可以使用这组众所周知的命令将集群中的节点注册到磁盘。然后应用程序可以从一系列受支持的访问模式中选择一个或者多个节点对磁盘的读写，这些应用程序可以部署在高可用配置中，同时还可以利用Azure磁盘持久性保证。

一、MySQL读写分离 Mysql的主从复制和Mysql的读写分离两者有着紧密联系，首先部署主从复制，只有主从复制完了，才能在此基础上进行数据的读写分离。 Master数据库处理事务性增、删除、修改、更新操作（CREATE、INSERT、UPDATE、DELETE），而让Slave数据库处理SELECT操作，MYSQL读写分离前提是基于MYSQL主从复制，这样可以保证在Master上修改数据，Slave同步之后，WEB应用可以读取到Slave端的数据。 简单来说 ，读写分离就是只在主服务器上写，只在从服务器上读，基本的原理是让主数据库处理事务性查询，而从数据库处理select查询，数据库复制被用来把事务性查询导致的改变更新同步到集群中的从数据库。 基于中间代理层实现 代理一般位于客户端和服务器之间，代理服务器接到客户端请求后通过判断后转发到后端数据库，有两个代表性程序。 （1）mysql-proxy 为mysql开源项目，通过其自带的lua脚本进行SQL判断，虽然是mysql的官方产品，但是mysql官方不建议将其应用到生产环境 （2）Amoeba （变形虫）由陈思儒开发，曾就职与阿里巴巴，该程序由java语言进行开发，阿里巴巴将其应用于生成环境，它不支持事物和存储过程 如果业务压力不是很大的时候要做读写分离，取决于硬盘读取的性能，客户才满意， 读库（配置低），写库（配置高

作者 | 易立 阿里云资深技术专家 导读 ：Kubernetes 已经成为企业新一代云 IT 架构的重要基础设施，但是在企业部署和运维 Kubernetes 集群的过程中，依然充满了 复杂性和困扰 。 阿里云容器服务自从 2015 年上线后，目前 托管着上万的 K8s 集群 来支撑全球各地的客户。我们对客户在规划集群过程中经常会遇见的问题，进行一些分析解答。试图缓解大家的“ 选择恐惧症 ”。 如何选择 Worker 节点实例规格？ 裸金属还是虚拟机？ 在 Dimanti 2019 年的容器调查报告中，对专有云用户选择裸金属服务器来运行容器的主要原因进行了分析。 选择裸金属服务器的最主要原因（ 超过 55% ）是：传统虚拟化技术 I/O 损耗较大；对于 I/O 密集型应用，裸金属相比传统虚拟机有更好的性能表现； 此外近 36% 的客户认为：裸金属服务器可以降低成本 。大多数企业在初始阶段采用将容器运行在虚拟机的方案，但是当大规模生产部署的时候，客户希望直接运行在裸金属服务器上来减少虚拟化技术的 license 成本（这也常被戏称为“VMWare 税”）； 还有近 30% 的客户因为在物理机上部署有更少的额外资源开销 （如虚拟化管理、虚拟机操作系统等）；还有近 24% 的客户选择的原因是：可以有更高的部署密度，从而降低基础设施成本； 超过 28% 的客户认为

在master 中 修改名字 配置网关（no改yes） 下载ntp等 重启 克隆 slave1 slave2 然后打开slave1 slave2 改名字 重启 三个机器重新启动后 ，查看ifconfig 查看ip 然后在Xshell中打开三台机器 配置host （三个） { vi /etc/hosts 写入ip+主机名 192.168.31.153 master 192.168.31.154 slave1 192.168.31.152 slave2 } 关闭防火墙 （三个） { 关闭防火墙：systemctl stop firewalld 查看状态：systemctl status firewalld 禁止防火墙自启：systemctl unenable firewalld } master·中·{选择时区：tzselect 5 9 1 1} master 作为 ntp 服务器，修改 ntp 配置文件。（master 上执行） { vi /etc/ntp.conf 写入 server 127.127.1.0 fudge 127.127.1.0 stratum 10 重启 ntp 服务： /bin/systemctl restart ntpd.service } 其他机器同步（slave1，slave2） ntpdate master 免密： ssh-keygen -t dsa -P

摘自： https://www.cnblogs.com/yangyuanhu/p/12439106.html Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2 | 0 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 2 | 1 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; 2 | 2 rpc的实现原理

ZooKeeper 我想大家应该都略有耳闻，可能你在开发中没有直接使用过，但常用的 Hadoop、HBase、Kafka、Dubbo 等都有使用到 ZooKeeper。那 ZooKeeper 到底起到了什么样的作用，为什么这些框架、系统需要使用 ZooKeeper呢，我们在开发过程中应该如何使用 ZooKeeper，又是否有 ZooKeeper的替代品呢。本文将围绕以上问题，从以下三方面说起： 来源与作用； 经典应用场景； 替代品。 1. 来源与作用 ZooKeeper 的设计初衷是什么？这要从雅虎的一个研究小组说起。当时，研究人员发现雅虎内部的很多分布式系统都需要依赖一个组件进行分布式协调，但是这些组件往往都存在分布式单点问题。所以雅虎便组织开发了 一个通用的无单点问题的分布式协调框架 ，那就是 ZooKeeper，一方面解决 单点问题 ，另一方面，将 分布式协调 从分布式系统中 抽离 出来，让开发者更专注于业务逻辑。 下面分别对 “单点问题” 和 “分布式协调” 进行讲述。 1.1 单点问题 单点问题（又叫单点故障，Single Point of Failure，SPOF）是指在系统中一旦失效就会让整个系统无法运作的部件。举个例子，将系统只部署在机器 A 一台机器上，如果机器 A 失效，则整个系统将无法运作。而为了解决该问题，一般采用冗余的方式，增加多台机器

版本：Centos7 Haddop3.2.1 JDK1.8 装备工作 ： 在安装前先要确保三台服务器之间能够ping通，已经安装了jdk，主机名的设置以及hosts文件的修改（ip和主机名映射关系），还有各主机的免密登录以及关闭防火墙。 本次安装用到的三台虚拟机如下： ip hostname 192.168.59.101 hadoop1(主机节点) 192.168.59.102 hadoop2（从节点） 192.168.59.103 hadoop3（从节点） 1、设置主机名称 hostnamectl set-hostname hostname 2、修改hosts文件添加ip映射关系 在三台机器中打开并编辑 vim /etc/hosts文件并追加ip和主机名的映射关系 3、配置免密登录 以hoaddp1为例，我们执行如下命令生成密匙 ssh-keygen -t rsa 执行这条命令一直按回车即可，生成成功后出现如下界面： 然后另外两台机器也要执行如上操作，这样三台机器就成功的生成了密匙，我这里使用的是root用户，密匙生成在~/.ssh/目录下，接下来我们需要把三台服务器生成的公匙都追加到各服务器的~/.ssh/authorized_keys文件中，操作如下： #在hadoop1、hadoop2、hadoop3中都执行下面这三台命令 ssh-copy-id -i hadoop1

rabbitmq是目前消息队列比较热门的使用技术，这里它和其他几类技术的对比本文就不做赘述了。本文主要讲述在Docker下如何部署rabbitmq分布式集群。本文不讲述docker及rabbitmq镜像的安装下载。 一、前期准备 本文以两台服务器作为示例。服务器A的IP为192.168.1.10，服务器B的IP为192.168.1.11。为了后期管理更多docker配置方便，分别在A，B两台服务器里面新建docker目录，其结构示例如下： cd /home/user/ mkdir docker cd docker mkdir rabbitmq cd rabbitmq touch hosts vim hosts 进入刚创建好的hosts文件配置服务器映射，编辑好以后wq保存退出 192.168.1.10 rabbit1 192.168.1.11 rabbit2 二、在A服务器中启动已经下载好的rabbitmq镜像 docker run -d --privileged=true --net host --hostname rabbit1 --name rabbitmq1 -v /home/user/docker/rabbitmq:/var/lib/rabbitmq -v /home/user/docker/rabbitmq/hosts:/etc/hosts -e RABBITMQ

文章目录 1 zookeeper简介 1.1 数据发布与订阅（配置中心） 1.2 负载均衡 1.3 命名服务(Naming Service) 1.4 分布式通知/协调 1.5 集群管理与 Master 选举 1.6 分布式锁 1.7 分布式队列 1 zookeeper简介 ZooKeeper 是一个高可用的分布式数据管理不系统协调框架。基于对 Paxos 算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得 ZooKeeper 解决很多分布式问题。 网上对 ZK 的应用场景也有不少介绍，本文将系统地对 ZK 的应用场景迚行一个分门归类的介绍。 值得注意的是， ZK 并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利用其提供的一系列 API 接口，摸索出来的典型使用方法。 1.1 数据发布与订阅（配置中心） 发布不订阅模型，即所谓的 配置中心 ，顾名思义就是发布者将数据发布到 ZK 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到 ZK 上迚行集中管理。这类场景通常是这样：应用在启劢的时候会主动来获取一次配置，同时，在节点上注册一个 Watcher ，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端