【分布式技术架构】「Tomcat技术专题」 探索Tomcat集群架构原理和开发分析指南

简介: 【分布式技术架构】「Tomcat技术专题」 探索Tomcat集群架构原理和开发分析指南

Tomcat集群原理

通过Nginx负载均衡进行请求转发

Tomcat集群能带来什么

  • 提高服务的性能, 并发能力, 以及高可用性
  • 提供项目架构的横向扩展能力

Tomcat集群产生什么问题

  • Session登录信息存储以及读取的问题
  • 服务器定时任务并发的问题

Tomcat 单服务体系架构

在这个架构图中,一层Nginx,首先Nginx主要职责给Tomcat一层反向代理。

此外,Nginx还可以FTPServer指定的目录再做一层目录转发,保证上传上去的图片实时可以通过http协议访问到。单服务架构先不用考虑集群碰到的各种问题

Tomcat集群"简单版"

比如,我们的登录的时候登录了A服务器,session信息存储到A服务器上了,假设我们使用的负载均衡策略是ip hash,那么登录信息还可以从A服务器上访问,但是这个有可能造成某些服务器压力过大,某些服务器又没有什么压力,这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈,并且请求不够分散。

首先要解决Session共享的问题

这时候我们使用轮询或者最小连接负载均衡策略,就导致了,第一次访问A服务器,第二次可能访问到B服务器,这个时候存储在A服务器上的session信息在B服务器上读取不到。

典型负载均衡策略分析

打个比方,我们有轮询,权重,地址散列,地址散列又分为原ip地址散列hash,目标ip地址散列hash,最少连接,加权最少连接,还有继续升级的很多种策略

  • 轮询:优点:实现简单,缺点:不考虑每台服务器处理能力
  • 权重:优点:考虑了服务器处理能力的不同
  • 地址散列:优点:能实现同一个用户访问同一个服务器
  • 最少连接:优点:使集群中各个服务器负载更加均匀
  • 加权最少连接:在最少连接的基础上,为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重,计算出来的值小的服务器优先被选择。
Session管理-Session Sticky粘滞会话:

对于同一个连接中的数据包,负载均衡会将其转发至后端固定的服务器进行处理。

解决了我们session共享的问题,但是它有什么缺点呢?

  • 一台服务器运行的服务挂掉,或者重启,上面的 session 都没了
  • 负载均衡器成了有状态的机器,为以后实现容灾造成了羁绊
Session管理-Session 复制

就是每一个Tomcat都存储我们的Session,不同的tomcat之间进行拷贝复制。

解决了我们session共享的问题,但是它有什么缺点呢?

  • 应用服务器间带宽问题,因为需要不断同步session数据
  • 大量用户在线时,服务器占用内存过多
Session管理-基于Cookie

主要用于我们将session会话如同token一般存储在我们的前端

解决了我们session共享的问题,但是它有什么缺点呢?

  • cookie 的长度限制
  • cookie存于浏览器,安全性是一个问题
Session管理-Session 服务器

就是通过一个专门管理session会话的管理器服务,进行集中化存储和管理session

解决了我们session共享的问题,这种方案需要思考哪些问题呢?保证 session 服务器的可用性,session服务器单点如何解决?

  • 我们在写应用时需要做调整存储session的业务逻辑
  • 打个比方,我们为了提高session server的可用性,可以继续给session server做集群

Tomcat单机部署多应用

  1. 解压2个tomcat, 分别命名为tomcatA和tomcatB
  2. 分别设置2个tomcat的URIEncoding, 将tomcat的conf/server.xml里的port修改为两个不同端口。

设置tomcat的环境变量

tomcatA的环境变量和以往一样, 不做改变

设置tomcat的环境变量

sudo vim /ect/profile

在profile文件里新增

javascript

复制代码

export CATALINA_BASE=/Users/tomcat/apache-tomcat-9.0.21
export CATALINA_HOME=/Users/tomcat/apache-tomcat-9.0.21
export TOMCAT_HOME=/Users/tomcat/apache-tomcat-9.0.21

javascript

复制代码

export CATALINA_2_BASE=/Users/tomcat/tomcat2
export CATALINA_2_HOME=/Users/tomcat/tomcat2
export TOMCAT_2_HOME=/Users/tomcat/tomcat2
强制保存退出

继续配置tomcatB下的catalina.sh里的内容,

cd tomcat目录,在# OS specific support. $var must be set to either true or false.下加入。

ini

复制代码

sudo vi catalina.sh
export CATALINA_BASE=$CATALINA_2_BASE
export CATALINA_HOME=$CATALINA_2_HOME
执行刷新环境变量

source /etc/profile

使环境变量生效, 执行

echo $CATALINA_2_BASE

如果有输出, 即环境变量已经生效

/Users/tomcat/tomcat2

分别进入两个tomcat下的bin目录启动tomcat, 正常即可

配置nginx

修改host

sudo vim /etc/hosts

所谓tomcat集群,就是可以向外提供并行服务的多台机器,任何一台服务器宕机,其它服务器可以替代它向外提供服务,而不影响用户访问。

nginx是一个常用的反向代理服务,可自定义模块,实现请求转发及负载均衡(根具体采用策略有关)。为了tomcat集群的高可用性,还需要实现nginx的双机热备。

一,如果仅是对外提供一个页面访问,不用区分单一用户(不区分每个访问session,不涉及用户权限,用户资料等内容),仅仅配置nginx负载均衡策略即可。

nginx负载均衡策略主要分一下四种:
1)、轮询(默认)每个请求按时间顺序逐一分配到不同的后端服务器,如果后端服务器宕机,能自动剔除。
2)、ip_hash 每个请求按访问ip的hash结果分配,这样每个访客固定访问一个后端服务器。
3)、fair 按后端服务器的响应时间来分配请求,响应时间短的优先分配。
4)、url_hash 按访问url的hash结果来分配请求,使每个url定向到同一个后端服务器,后端服务器为缓存时比较有效。

二,如果涉及到用户session,做一些鉴权缓存、存放临时信息时,就必须做tomcat的session共享。

目前可参考到的session共享方式主要分为两种。

1)利用tomcat自带的组播机制,实现session复制。

对tomcat及应用的若干配置文件进行配置即可实现,网上有很多资料可参考。但这种方式些弊端,看过一些资料,不建议用session复制的方式。在实际使用过程中,也发现有存在session莫名失踪的现象。

2)利用第三方机制存储session。

比较常见的是tomcat集成memcached服务器来存储session。实际项目中,我们采用过利用redis实现session存储,redis高效的存取性能为高效的访问提供了保障,但是目前redis的集群功能似乎没有发布,如何解决redis的单点故障需要研究。

小结:是否实现session共享与nginx的负载策略有很大关系。比如采用轮询策略,就必须实现session共享,因为客户端会访问到每台服务器;而如果采用ip_hash策略,就可以不用考虑session共享的问题了,但是ip_hash有些缺陷使它不能随便使用(如多台pc使用同一个外网ip)。

最近发现一个nginx的粘连模块(类似session粘连),可以看做nginx的第5种均衡策略。它利用客户端cookie,对其写入一个route参数,每次访问可以根据route的值,固定的访问一台服务器,解决的session共享的问题。

相关文章
|
8月前
|
人工智能 Kubernetes 数据可视化
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
本文回顾了一次关键词监测任务在容器集群中失效的全过程,分析了中转IP复用、调度节奏和异常处理等隐性风险,并提出通过解耦架构、动态IP分发和行为模拟优化采集策略,最终实现稳定高效的数据抓取与分析。
156 2
Kubernetes下的分布式采集系统设计与实战:趋势监测失效引发的架构进化
|
7月前
|
监控 Java API
Spring Boot 3.2 结合 Spring Cloud 微服务架构实操指南 现代分布式应用系统构建实战教程
Spring Boot 3.2 + Spring Cloud 2023.0 微服务架构实践摘要 本文基于Spring Boot 3.2.5和Spring Cloud 2023.0.1最新稳定版本,演示现代微服务架构的构建过程。主要内容包括: 技术栈选择:采用Spring Cloud Netflix Eureka 4.1.0作为服务注册中心,Resilience4j 2.1.0替代Hystrix实现熔断机制,配合OpenFeign和Gateway等组件。 核心实操步骤: 搭建Eureka注册中心服务 构建商品
1195 3
|
10月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
8月前
|
消息中间件 负载均衡 中间件
⚡ 构建真正的高性能即时通讯服务:基于 Netty 集群的架构设计与实现
本文介绍了如何基于 Netty 构建分布式即时通讯集群。随着用户量增长,单体架构面临性能瓶颈,文章对比了三种集群方案:Nginx 负载均衡、注册中心服务发现与基于 ZooKeeper 的消息路由架构。最终选择第三种方案,通过 ZooKeeper 实现服务注册发现与消息路由,并结合 RabbitMQ 支持跨服务器消息广播。文中还详细讲解了 ZooKeeper 搭建、Netty 集群改造、动态端口分配、服务注册、负载均衡及消息广播的实现,构建了一个高可用、可水平扩展的即时通讯系统。
941 0
|
5月前
|
缓存 Cloud Native 中间件
《聊聊分布式》从单体到分布式:电商系统架构演进之路
本文系统阐述了电商平台从单体到分布式架构的演进历程,剖析了单体架构的局限性与分布式架构的优势,结合淘宝、京东等真实案例,深入探讨了服务拆分、数据库分片、中间件体系等关键技术实践,并总结了渐进式迁移策略与核心经验,为大型应用架构升级提供了全面参考。
|
5月前
|
存储 NoSQL 前端开发
【赵渝强老师】MongoDB的分布式存储架构
MongoDB分片通过将数据分布到多台服务器,实现海量数据的高效存储与读写。其架构包含路由、配置服务器和分片服务器,支持水平扩展,结合复制集保障高可用性,适用于大规模生产环境。
448 1
|
6月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
6月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
9月前
|
监控 算法 关系型数据库
分布式事务难题终结:Seata+DRDS全局事务一致性架构设计
在分布式系统中,CAP定理限制了可用性、一致性与分区容错的三者兼得,尤其在网络分区时需做出取舍。为应对这一挑战,最终一致性方案成为常见选择。以电商订单系统为例,微服务化后,原本的本地事务演变为跨数据库的分布式事务,暴露出全局锁失效、事务边界模糊及协议差异等问题。本文深入探讨了基于 Seata 与 DRDS 的分布式事务解决方案,涵盖 AT 模式实践、分片策略优化、典型问题处理、性能调优及高级特性实现,结合实际业务场景提供可落地的技术路径与架构设计原则。通过压测验证,该方案在事务延迟、TPS 及失败率等方面均取得显著优化效果。
488 61
|
10月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
3451 57