集群技术

目前的项目很少会采用单机架构了，一是因为单机性能有限，二是因为单机服务一旦故障整个系统就无法继续提供服务了。所以目前集群和分布式的架构使用得很广泛，主要就是为了解决上述两个问题，一个性能问题，一个故障问题， 通过分布式架构解决性能（高并发）问题，通过集群架构解决故障服务（高可用）问题。 技术简介 Lombok通过简单注释来精简代码来达到消除冗长代码的目的 优点：提高编程效率、简洁代码、消除冗长代码、避免修改字段名忘记修改方法名 增加jar 下载idea的lombok插件 Pojo中的get/set就可以用注解替换 Maven隔离 不同环境配置进行分离清除打包mvn clean package -Dmaven.test.skip=true -Pdev实际项目环境，环境之间的各种差异，maven环境隔离的配置，设置默认环境，验证-重新打包测试 Tomcat集群 能带来什么：1.提高性能、高可用，2.项目横向扩展能力（纵向扩展指提升服务器的性能）实现原理：通过Nginx负载均衡进行请求转发架构对比： 新问题：1.Session登录信息存储与读取，2.服务器定时任务并发解决方案：1.nginx ip hash policy 可以不改变现有技术架构，横向扩展（省事），但负载不平均，ip变化下无法服务。Tomcat单机部署多应用/多机部署多应用

集群式： 集群概念 1. 两大关键特性 集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性： · 可扩展性－－集群的性能不限于单一的服务实体，新的服务实体可以动态地加入到集群，从而增强集群的性能。 · 高可用性－－集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出 错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。 2. 两大能力 为了具有可扩展性和高可用性特点，集群的必须具备以下两大能力： · 负载均衡－－负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。 · 错误恢复－－由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。 负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图（信息上下文）必须是一样的。 3. 两大技术 实现集群务必要有以下两大技术： · 集群地址－

redis 安装配置学习笔记 //wget http://download.redis.io/releases/redis-2.8.17.tar.gz 下载最新版本 wget http://download.redis.io/redis-stable.tar.gz 首先必须要有 gcc 与 make apt-get install gcc apt-get install make 1、解压 root@localhost:~# tar -xvf redis-stable.tar.gz 2、测试 root@localhost:~/redis-stable# ./runtest You need tcl 8.5 or newer in order to run the Redis test 提示需要安装tcl make完成后，在原src目录下，会生成出六个exe(可执行程序)，服务端只需要redis-server.exe即可 3、运行redis 后台方式启动redis ./redis-server & 启动redis客户端链接 ./redis-cli 输入ping 返回pong 即为安装成功 扩展知识： redis-cli用法：redis-cli [OPTIONS] [cmd [arg [arg ...]]] -h <主机ip>，默认是127.0.0.1 -p <端口>，默认是6379

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

1. kafka概述 1.1 kafka简介 Apache Kafka 是一个快速、可扩展的、高吞吐的、可容错的分布式“发布-订阅”消息系统， 使用 Scala 与 Java 语言编写，能够将消息从一个端点传递到另一个端点，较之传统的消息中 间件(例如 ActiveMQ、RabbitMQ)，Kafka 具有高吞吐量、内置分区、支持消息副本和高容 错的特性，非常适合大规模消息处理应用程序。 Kafka 官网: http://kafka.apache.org/ Kafka主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 支持在线水平扩展 Kafka通常用于两大类应用程序： 建立实时流数据管道，以可靠地在系统或应用程序之间获取数据 构建实时流应用程序，以转换或响应数据流 要了解Kafka如何执行这些操作，让我们从头开始深入研究Kafka的功能。 首先几个概念： Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。 Kafka集群将 记录 流存储在称为 主题的 类别中。 每个记录由一个键

摘自： 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 失效，则整个系统将无法运作。而为了解决该问题，一般采用冗余的方式，增加多台机器

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

目录 lvs高可用集群 技术简介： 集群采用三层结构： lvs集群类型中的术语： lvs集群的类型： lvs-nat： lvs-dr： lvs-tun： lvs-fullnat： ipvs scheduler： 静态方法：仅根据算法本身进行调度 动态方法：主要根据每RS当前的负载状态及调度算法进行调度； lvs-nat配置： 拓扑结构： lvs-nat数据流向图: 设计要点： RS1： RS2： VS: lvs-dr配置： 拓扑结构： LVS-DR模拟数据流向图 设计要点： dr模型中，各主机上均需要配置VIP，解决地址冲突的方式有三步： RS的预配置脚本： VS的配置脚本： 路由器上配置： 后记 lvs-dr模型中：vip与dip/rip不在同一网段的实验环境设计及配置实现 参考文档 lvs高可用集群 技术简介： LVS集群采用IP负载均衡技术和基于内容请求分发技术。 调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行， 且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。 整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。 为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性 集群采用三层结构： 一般来说，LVS集群采用三层结构，其主要组成部分为： 负载调度器（load balancer）

我们之前都是一个调度器来调度多台web后端服务器 但是调度器也有不能工作的时候，完一坏了所有的web服务器都不能访问，这就要求调度器也要备份 因此就引出了高可用的集群KeepAlived 也就是有多个调度器（有主有备），利用keepalived保证web服务通过正常的调度器工作 所有调度器同时宕机的可能性是很小的 1.keepalived的基本概念 Keepalived是Linux下的一个轻量级别的高可用解决方案 高可用（High Avalilability，HA），其实两种不同的含义：广义上来讲，是指整个系统的高可用性，狭义上来讲就是主机的冗余和接管 Keepalived起初是为LVS设计的，专门用来监控集群系统中的各个服务的节点的状态 它根据TCP/IP参考模型的第三，第四，第五层交换机制检测每个服务器的节点状态 如果某个服务器出现异常，或者工作出现故障，keepalived将检测到，并将出现故障的服务器节点从集群系统中剔除 这些工作都只自动完成的，不需要人为干预，需要人工完成的只是修复出现故障的服务节点 也就是可以使用keepalived可以实现调度器的转换 后来keepalived又加入了VRRP的功能 VRRP（Virtual Router Redundancy Protocol）虚拟路由冗余协议出现的目的是 解决静态路由出现单点故障的问题