一、为什么要集群？
1.JavaEE项目，如果部署在一台Tomcat上，所有的请求，都由这一台服务器处理，存在很大风险：
A：并发处理能力有限
（一般单台服务器处理的并发量为250左右，超过250，可能会出现数据丢失，链接不稳定的情况）。因为单服务器的性能有限制。所以单台Tomcat的最大连接数有限制，
B：容错率低，一旦服务器故障，整个服务就无法访问了。
eBay于 1999年6月停机22小时的事故，中断了约230万的拍卖，使eBay的股票下降了9.2个百分点。
C：单台服务器计算能力低，无法完成复杂的海量数据计算。
提高CPU主频和总线带宽是最初提供计算机性能的主要手段。但是这一手段对系统性能的提供是有限的。接着人们通过增加CPU个数和内存容量来提高性能，于是出现了向量机，对称多处理机(SMP)等。但是当CPU的个数超过某一阈值，这些多处理机系统的可扩展性就变的极差。主要瓶颈在于CPU访问内存的带宽并不能随着CPU个数的增加而有效增长。与SMP相反，集群系统的性能随着CPU个数的增加几乎是线性变化的。
使用集群架构完成工作主要有以下几点决定：
1、高性能计算
一些国家重要的计算密集型应用（如天气预报，核试验模拟等），需要计算机有很强的运算处理能力⌄以全世界现有的技术，即使是大型机器，其计算能力也是有限的，很难单独完成此任务。因为计算时间可能会相当长，也许几天，甚至几年或更久。因此，对于这类复杂的计算业务，便使用了计算机集群技术，集中几十上百台，甚至成千上万台计算机进行计算。
2、价格有效性
早期的淘宝，支付宝的数据库等核心系统就是使用上百万元的小型机服务器。后因使用维护成本太高以及扩展设备费用成几何级数翻倍，甚至成为扩展瓶颈，人员维护也十分困难，最终使用PC服务器集群替换之，比如，把数据库系统从小机结合Oracle数据库迁移到MySQL开源数据库结合PC服务器上来。不但成本下降了，扩展和维护也更容易了。
3、可伸缩性
当服务负载，压力增长时，针对集群系统进行较简单的扩展即可满足需求，且不会降低服务质量。
通常情况下，硬件设备若想扩展性能，不得不增加新的CPU和存储器设备，如果加不上去了，就不得不购买更高性能的服务器，就拿我们现在的服务器来讲，可以增加的设备总是有限的。如果采用集群技术，则只需要将新的单个服务器加入现有集群架构中即可，从访问的客户角度来看，系统服务无论是连续性还是性能上都几乎没有变化，系统在不知不觉中完成了升级，加大了访问能力，轻松地实现了扩展。集群系统中的节点数目可以增长到几千乃至上万个，其伸缩性远超过单台超级计算机。
4、高可用性
单一的计算机系统总会面临设备损毁的问题，如CPU，内存，主板，电源，硬盘等，只要一个部件坏掉，这个计算机系统就可能会宕机，无法正常提供服务。在集群系统中，尽管部分硬件和软件还是会发生故障，但整个系统的服务可以是7*24小时可用的。
集群架构技术可以使得系统在若干硬件设备故障发生时仍可以继续工作，这样就将系统的停机时间减少到了最小。集群系统在提高系统可靠性的同时，也大大减小了系统故障带来的业务损失，目前几乎100%的互联网网站都要求7*24小时提供服务。
5、透明性
多个独立计算机组成的松耦合集群系统构成一个虚拟服务器。用户或客户端程序访问集群系统时，就像访问一台高性能，高可用的服务器一样，集群中一部分服务器的上线，下线不会中断整个系统服务，这对用户也是透明的。
6、可管理性
整个系统可能在物理上很大，但其实容易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用。
7、可编程性
在集群系统上，容易开发及修改各类应用程序。
蓝海大脑水冷工作站超融合架构承担着计算资源池和分布式存储资源池的作用，极大地简化了数据中心的基础架构，通过软件定义的计算资源虚拟化和分布式存储架构实现无单点故障、无单点瓶颈、弹性扩展、性能线性增长等能力。通过简单方便的统一管理界面，实现对数据中心计算、存储、网络、虚拟化等资源的统一监控、管理和运维。
型号 蓝海大脑水冷服务器
英特尔
处理器 Intel Xeon Gold 6240R 24C/48T,2.4GHz,35.75MB,DDR4 2933,Turbo,HT,165W.1TB
Intel Xeon Gold 6258R 28C/56T,2.7GHz,38.55MB,DDR4 2933,Turbo,HT,205W.1TB
Intel Xeon W-3265 24C/48T 2.7GHz 33MB 205W DDR4 2933 1TB
Intel Xeon Platinum 8280 28C/56T 2.7GHz 38.5MB,DDR4 2933,Turbo,HT 205W 1TB
Intel Xeon Platinum 9242 48C/96T 3.8GHz 71.5MB L2,DDR4 3200,HT 350W 1TB
Intel Xeon Platinum 9282 56C/112T 3.8GHz 71.5MB L2,DDR4 3200,HT 400W 1TB
AMD
处理器 AMD锐龙Threadripper Pro 3945WX 4.0GHz/12核/64M/3200/280W
AMD锐龙Threadripper Pro 3955WX 3.9GHz/16核/64M/3200/280W
AMD锐龙Threadripper Pro 3975WX 3.5GHz/32核/128M/3200/280W
AMD锐龙Threadripper Pro 3995WX 2.7GHz/64核/256M/3200/280W
AMD锐龙Threadripper Pro 5945WX 4.1G 12核/64M/3200/280W
AMD锐龙Threadripper Pro 5955WX 4.0G 16核/64M/3200/280W
AMD锐龙Threadripper Pro 5965WX 3.8G 24核/128M/3200/280W
AMD锐龙Threadripper Pro 5975WX 3.6G 32核/128M/3200/280W
AMD锐龙Threadripper Pro 5995WX 2.7G 64核/256M/3200/280W
显卡 NVIDIA A100×4, NVIDIA GV100×4
NVIDIA RTX 3090×4, NVIDIA RTX 3090TI×4,
NVIDIA RTX 8000×4, NVIDIA RTX A6000×4,
NVIDIA Quadro P2000×4,NVIDIA Quadro P2200×4
硬盘 NVMe.2 SSD: 512GB，1TB； M.2 PCIe - Solid State Drive (SSD),
SATA SSD: 1024TB, 2048TB, 5120TB
SAS:10000rpm&15000rpm,600GB,1.2TGB,1.8TB
HDD : 1TB，2TB,4TB,6TB,10TB
外形规格 立式机箱
210尺寸mm（高*深*宽) : 726 x 616 x 266
210A尺寸mm（高*深*宽) : 666 x 626 x 290
210B尺寸mm（高*深*宽) : 697 x 692 x 306
声卡：7.1通道田声卡
机柜安装 : 前置机柜面板或倒轨（可选）
电源 功率 : 1300W×22000W×1
软件环境 可预装 CUDA、Driver、Cudnn、NCCL、TensorRT、Python、Opencv 等底层加速库、选装 Tensorflow、Caffe、Pytorch、MXnet 等深度学习框架。
前置接口 USB3.2 GEN2 Type-C×4
指承灯电和硬盘LED
灵动扩展区 : 29合1读卡器，eSATA，1394，PCIe接口（可选）
读卡器 : 9合1SD读卡器（可选）
模拟音频 : 立体声、麦克风
后置接口 PS2接口 : 可选
串行接口 : 可选
USB3.2 GEN2 Type-C×2
网络接口 : 双万兆 (RJ45)
IEEE 1394 : 扩展卡口
模拟音频 : 集成声卡 3口
连接线 专用屏蔽电缆（信号电缆和电源电缆）
资料袋 使用手册、光盘1张、机械键盘、鼠标、装箱单、产品合格证等
服务器集群：服务器集群就是指将很多服务器集中起来一起进行同一种服务，在客户端看来就像是只有一个服务器。集群可以利用多个计算机进行并行计算从而获得很高的计算速度，也可以用多个计算机做备份，从而使得任何一个机器坏了整个系统还是能正常运行。
服务器负载均衡：
负载均衡
（Load
Balancing）
建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
分布式服务器：
所谓分布式资源共享服务器就是指数据和程序可以不位于一个服务器上，而是分散到多个服务器，以网络上分散分布的地理信息数据及受其影响的数据库操作为研究对象的一种理论计算模型服务器形式。分布式有利于任务在整个计算机系统上进行分配与优化，克服了传统集中式系统会导致中心主机资源紧张与响应瓶颈的缺陷，解决了网络GIS
中存在的数据异构、数据共享、运算复杂等问题，是地理信息系统技术的一大进步。
这个三种架构都是常见的服务器架构，集群的主要是IT公司在做，可以保障重要数据安全；负载均衡主要是为了分担访问量，避免临时的网络堵塞，主要用于电子商务类型的网站；分布式服务器主要是解决跨区域，多个单个节点达到高速访问的目前，一般是类似CDN的用途的话，会采用分布式服务器。
纯手工打字，希望可以帮的到你！
也称为 Warren (兔子窝) 模式。实现 rabbitMQ 的高可用集群，一般在并发和数据量不高的情况下，这种模式非常的好用且简单。
也就是一个主/备方案，主节点提供读写，备用节点不提供读写。如果主节点挂了，就切换到备用节点，原来的备用节点升级为主节点提供读写服务，当原来的主节点恢复运行后，原来的主节点就变成备用节点，和 activeMQ 利用 zookeeper 做主/备一样，也可以一主多备。
HaProxy 配置:
listen rabbitmq_cluster
bind 0.0.0.0:567 # 配置 tcp 模式
mode tcp # 简单的轮询
balance roundrobin # 主节点 roundrobin 随机
server 你的76机器 hostname 192.168.11.76:5672 check inter 5000 rise 2 fall 2
server 你的77机器 hostname 192.168.11.77:5672 backup check inter 5000 rise 2 fall 2 # 备用节点
注意了，上面的 rabbitMQ 集群节点配置 # inter 每隔 5 秒对 mq 集群做健康检查， 2 次正确证明服务可用，2 次失败证明服务器不可用，并且配置主备机制
远程模式可以实现双活的一种模式，简称 shovel 模式，所谓的 shovel 就是把消息进行不同数据中心的复制工作，可以跨地域的让两个 MQ 集群互联，远距离通信和复制。
Shovel 就是我们可以把消息进行数据中心的复制工作，我们可以跨地域的让两个 MQ 集群互联。
如图所示，有两个异地的 MQ 集群（可以是更多的集群），当用户在地区 1 这里下单了，系统发消息到 1 区的 MQ 服务器，发现 MQ 服务已超过设定的阈值，负载过高，这条消息就会被转到 地区 2 的 MQ 服务器上，由 2 区的去执行后面的业务逻辑，相当于分摊我们的服务压力。
在使用了 shovel 插件后，模型变成了近端同步确认，远端异步确认的方式，大大提高了订单确认速度，并且还能保证可靠性。
如上图所示，当我们的消息到达 exchange，它会判断当前的负载情况以及设定的阈值，如果负载不高就把消息放到我们正常的 warehouse_goleta 队列中，如果负载过高了，就会放到 backup_orders 队列中。backup_orders 队列通过 shovel 插件与另外的 MQ 集群进行同步数据，把消息发到第二个 MQ 集群上。
这是 rabbitMQ 比较早期的架构模型了，现在很少使用了。
shovel 集群的配置，首先启动 rabbitmq 插件，命令如下:
rabbitmq-plugins enable amqp_client
rabbitmq-plugins enable rabbitmq_shovel
在 /etc/rabbitmq/ 目录下创建 rabbitmq.config 文件。注意，我们源服务器和目的地服务器都使用这个相同的配置文件。
具体配置如下
非常经典的 mirror 镜像模式，保证 100% 数据不丢失。在实际工作中也是用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。
mirror 镜像队列，目的是为了保证 rabbitMQ 数据的高可靠性解决方案，主要就是实现数据的同步，一般来讲是 2 - 3 个节点实现数据同步。对于 100% 数据可靠性解决方案，一般是采用 3 个节点。
集群架构如下
如上图所示，用 KeepAlived 做了 HA-Proxy 的高可用，然后有 3 个节点的 MQ 服务，消息发送到主节点上，主节点通过 mirror 队列把数据同步到其他的 MQ 节点，这样来实现其高可靠。
也是实现异地数据复制的主流模式，因为 shovel 模式配置比较复杂，所以一般来说，实现异地集群的都是采用这种双活 或者 多活模型来实现的。这种模式需要依赖 rabbitMQ 的 federation 插件，可以实现持续的，可靠的 AMQP 数据通信，多活模式在实际配置与应用非常的简单。
rabbitMQ 部署架构采用双中心模式(多中心)，那么在两套(或多套)数据中心各部署一套 rabbitMQ 集群，各中心的rabbitMQ 服务除了需要为业务提供正常的消息服务外，中心之间还需要实现部分队列消息共享。
多活集群架构如下:
federation 插件是一个不需要构建 cluster ，而在 brokers 之间传输消息的高性能插件，federation 插件可以在 brokers 或者 cluster 之间传输消息，连接的双方可以使用不同的 users 和 virtual hosts，双方也可以使用不同版本的 rabbitMQ 和 erlang。federation 插件使用 AMQP 协议通信，可以接受不连续的传输。federation 不是建立在集群上的，而是建立在单个节点上的，如图上黄色的 rabbit node 3 可以与绿色的 node1、node2、node3 中的任意一个利用 federation 插件进行数据同步。
如上图所示，federation exchanges 可以看成 downstream 从 upstream 主动拉取消息，但是并不是拉取所有消息，必须是在 downstream 上已经明确定义 Bingdings 关系的 exchange，也就是有实际的物理 queue 来接收消息，才会从 upstream 拉取消息到 downstream 。
它使用 AMQP 协议实现代理间通信，downstream 会将绑定关系组合在一起，绑定/解绑命令将发送到 upstream 交换机。因此，federation exchange 只接收具有订阅的消息。
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）