一、Tomcat
（一）WEB 技术
1.前端三大核心技术
（1）HTML
超文本标记语言（HTML）的本质与核心总结：
HTML 并非传统意义上的编程语言，而是一种专门用于构建网页的标记语言。其核心思想在于"超文本"，即它超越了纯文本的限制，不仅能呈现文字本身，还能通过特定语法定义文本的格式（如颜色、大小、字体），并能无缝嵌入图片、音频、视频等多媒体非文本内容。
HTML 的功能主要由一个个标签（标记）来实现。这些标签分工明确、各司其职，构成了网页的骨架------有的负责定义网页的元信息，有的负责结构化文本，有的负责插入多媒体，还有的负责搭建整体的网页布局。因此，任何一个 HTML 文件本质上都是由格式标签与实际数据（内容）组合而成的文档。
为了呈现出超文本定义的排版格式（如图片、表格、字体样式），必须依赖专门的解读软件浏览器。超文本的诞生是为了解决纯文本显示单调的问题，追求更好的视觉效果。而为了让这些内容能被远程分享和获取，人们又制定了 HTTP协议，规定了数据在网络中的传输规则，使得浏览器能够请求并接收网页，最终将"好看"的文档连接成全球共享的万维网。
（2）CSS
随着网页对视觉效果的需求日益增长，HTML 被迫不断加入样式功能而变得臃肿，这促使了专门负责样式的 CSS（层叠样式表）诞生。1994年 W3C 成立后，CSS 设计小组全体加入并推动标准研发，微软随后也参与其中。CSS 1.0于1996年12月发布，1998年5月推出 CSS 2.0。此后的 CSS 3采用模块化思想，在 CSS 2基础上对各功能模块分别进行增强和陆续发布。然而，由于不同浏览器厂商使用不同的渲染引擎，对 CSS 标准的支持程度存在差异，导致同一份网页在不同浏览器中的布局和样式表现不一致，这使得跨浏览器保持统一的视觉效果成为前端开发中长期存在的挑战。
（3）JavaScript
JavaScript（简称JS）是一种动态、弱类型的脚本解释性语言，与 HTML、CSS 并列为三大 WEB 核心技术，几乎被所有主流浏览器支持。
1994年，网景公司推出 Netscape Navigator 浏览器并占据市场主导地位，为了满足网页动态化的需求，于1995年9月发布 LiveScript，同年12月更名为 JavaScript。同期，微软在IE中推出 JScript以抗衡。
1997年，ECMA（欧洲计算机制造商协会）制定了 ECMAScrip t标准，JavaScript 和 JScript 均成为该标准的实现。
2008年后，Chrome 浏览器搭载的 V8 引擎发布，它通过本地编译和深度优化，使 JS 运行速度堪比二进制程序。V8 引擎用 C++ 开发，可嵌入任何 C++ 程序。2009年，基于 V8 的 Node.js 诞生，并创建了 npm 包管理系统。自此，JavaScript 实现了在服务器端的大规模应用，成为唯一能够前后端通用的编程语言。
同步
在同步交互中，用户每次提交请求（如注册表单）后，浏览器都必须等待服务器返回一个全新的完整 HTML 页面并重新渲染。这种机制导致了三个核心问题：一是用户体验差，页面会强制刷新导致输入内容丢失；二是资源浪费严重，为了更新局部信息却要传输整个页面，消耗了不必要的网络带宽和渲染性能；三是效率低下，整体过程笨重且不友好。这也间接引出了对这种落后交互方式进行改进的必要性。
异步
Ajax 并非一项全新的发明，而是一种技术的重新组合与发现。它的核心思想起源于1998年微软的Outlook Web Access 团队，早期经历了 iframe 标签和笨重的 ActiveX 插件的探索。1999年，微软推出的 XMLHttpRequest 组件被大多数浏览器支持，为 Ajax 的普及奠定了基础。
Ajax 的全称是"Asynchronous JavaScript And XML"（异步JavaScript和XML）。其最大价值在于改变了传统网页必须重载整个页面的同步交互模式：通过浏览器内置的 XMLHttpRequest 对象，JavaScript 可以在后台与服务器进行少量数据交换，实现网页的局部异步更新。虽然早期常结合XML 格式，但现在更多使用 JSON。
这项技术不仅极大地推动了 JavaScript 的发展，更重要的是实现了前后端开发的彻底分离，改变了传统的 Web 开发模式，深远地影响了整个互联网行业。
（二）WEB 框架
1.web 资源和访问
从静态服务器请求 HTML、CSS、JS 等文件发送到浏览器端，浏览器端接收后渲染在浏览器上从图片服务器请求图片资源显示。
从业务服务器访问动态内容，动态内容是请求后有后台服务访问数据库后得到的，最终返回到浏览器端。
为了提升加载性能和用户体验，移动 App 通常会内置 HTML 和 JS 文件在本地，而非每次启动都从静态服务器下载。这样做主要是为了规避现代前端工程中JS文件过多或过大的问题，减少网络传输开销。在实际运行中，App 采用按需加载策略：仅在有需要时才从图片服务器请求静态资源，从业务服务器请求动态数据。面对多样化的用户需求，大部分实时内容仍需由后端提供，因此业务服务器往往是由一组服务器组成的集群，以支撑高并发和复杂业务逻辑，保障服务的稳定与高效。
2.后台应用架构
（1）单体架构
核心特征：
all in one：所有功能模块（商品、订单、支付、库存、登录等）都放在同一个工程中，统一打包（如jar/war）部署，运行在同一个进程内。
部署方式：通常先部署到一台服务器，若负载不足则通过水平复制（多份部署）+ 负载均衡来扩展。
优点：
易于开发和测试，部署方便。
扩展简单：复制应用多份即可。
缺点：
耦合度高：模块间相互依赖，修改或升级某一功能（如支付）必须重新打包部署整个应用。
容错性差：任何一个模块出问题（如内存泄漏）都可能导致全站不可访问。
维护困难：项目庞大时，代码管理、团队协作难度大。
发布效率低：每次发布都需要停服重启，影响业务连续性。
典型代表：
开源：Tomcat、Jetty、Glassfish
商用：WebLogic、WebSphere、Jboss
（2）微服务
微服务架构是 SOA（面向服务架构）的一种具体实现和子集，其核心是将传统的一站式应用按业务边界拆分为多个独立服务，每个服务只专注于单一业务功能，实现彻底解耦。从技术角度看，每个微服务都是一个独立的进程，可自行启动或销毁，能够独立部署到生产环境；多个服务共同构成分布式系统，各自可使用独立的数据库，服务之间采用基于 HTTP 的 RESTful API 等轻量级通信机制进行交互。
微服务设计思想也深刻影响了企业研发团队的组织架构，改变了传统的水平团队模式（前端、后端、DBA 各成团队），更倾向于垂直架构------按业务划分团队，如用户业务由一个团队全栈负责，支付业务由另一个团队全栈负责。当然，实际企业中并不会拆分得绝对，垂直架构更多是一种理想模式。微服务有多种实现框架（如 Spring Cloud、Dubbo 等），不同的应用架构对应着不同的部署方式。
（3）微服务优缺点
优点：
微服务架构的核心优势在于其小而专、松耦合的设计理念。每个服务只聚焦单一业务功能，代码规模小、内聚性强，易于开发者理解、修改和维护。这种独立性使得开发效率显著提升，小团队（2-5人）可以独立负责一个服务，无需跨团队协作即可实现价值。在技术层面，微服务允许不同服务使用不同的编程语言和技术栈，便于融合最新技术；同时实现了前后端分离，服务只关注业务逻辑，易于与第三方集成。部署方面，微服务支持独立的持续集成和自动部署（如通过 Jenkins 等工具），每个服务可以独立发布、升级或回滚，互不影响。存储上，每个服务可根据需要选择独立数据库或统一数据库，灵活性高。
缺点：
然而，微服务也带来了显著的复杂性提升。将一个完整的项目拆分为多个独立工程后，开发、测试、运维、监控的难度都大幅增加。分布式环境下，跨服务的数据一致性成为挑战，需要引入分布式事务和异步补偿机制，增加了设计和开发成本。开发人员和运维人员必须掌握分布式系统的相关知识，对技术能力要求更高。此外，服务间的通信延迟、故障处理、调用链追踪等问题都需要额外处理。需要强调的是，微服务并非适用于所有场景------对于小型应用而言，盲目拆分只会徒增维护和开发成本，得不偿失。
常见的微服务框架：
Dubbo
阿里开源贡献给了 ASF ，目前已经是 Apache 的顶级项目
一款高性能的 Java RPC 服务框架，微服务生态体系中的一个重要组件
将单体程序分解成多个功能服务模块，模块间使用 Dubbo 框架提供的高性能 RPC 通信
内部协调使用 Zookeeper，实现服务注册、服务发现和服务治理
Spring cloud
一个完整的微服务解决方案，相当于 Dubbo 的超集
微服务框架，将单体应用拆分为粒度更小的单一功能服务
基于 HTTP 协议的 REST(Representational State Transfer 表述性状态转移）风格实现模块间通信
（三）Tomcat 的功能介绍
Tomcat 是一个免费、开源的轻量级 Web 应用服务器，由 Apache 软件基金会（ASF）管理。它起源于 Sun 公司的一个 Servlet 参考实现项目（Java Web Server），由 James Duncan Davidson开发，1999年贡献给 ASF 并与 JServ 项目合并，最终开源成为顶级项目。
核心特性：
主要功能：作为 Servlet 和 JSP 容器，同时具有处理 HTML 页面的能力。
规范实现：仅实现了Java EE 规范中与 Servlet、JSP 相关的部分，是 Java EE 的不完整实现。
适用场景：广泛应用于中小型系统和并发访问用户不是很多的场合。
版本演进：
Tomcat 3.0（1999年）：初始版本，实现了 Servlet 2.2 和 JSP 1.1 规范
Tomcat 4.x：内建 Catalina（Servlet容器）和 Jasper（JSP引擎）
当前版本：正式版已更新至9.0.x，但企业中主流仍使用8.x和7.x版本
资源链接：
官网文档：https://tomcat.apache.org/tomcat-8.5-doc/index.html
帮助文档：https://cwiki.apache.org/confluence/display/tomcat/
1.Tomcat 的文件结构和组成
目录结构：
2.Tomcat 的启动文件
主配置文件路径：/usr/local/tomcat/conf/tomcat.conf
启动脚本文件：
（四）结合反向代理实现 Tomcat 部署
1.常见部署方式
standalone 模式，Tomcat 单独运行，直接接受用户的请求，不推荐。
反向代理，单机运行，提供了一个 Nginx 作为反向代理，可以做到静态由 nginx 提供响应，动态jsp代理给 Tomcat：
（LNMT）Linux + Nginx + MySQL + Tomcat
（LAMT）Linux + Apache（Httpd）+ MySQL + Tomcat
前置一台 Nginx，给多台 Tomcat 实例做反向代理和负载均衡调度，Tomcat 上部署的纯动态页面更
适合：
（LNMT）Linux + Nginx + MySQL + Tomcat
多级代理：
（LNNMT）：Linux + Nginx + Nginx + MySQL + Tomcat
2.利用 nginx 反向代理实现
利用 nginx 反向代理功能，实现图中的代理功能，将用户请求全部转发至指定的同一个 tomcat 主机。
利用 nginx 指令 proxy_pass 可以向后端服务器转发请求报文,并且在转发时会保留客户端的请求报文中的 host 首部
3.实现 Tomcat 中的负载均衡
动态服务器的问题，往往就是并发能力太弱，往往需要多台动态服务器一起提供服务。如何把并发的压力分摊，这就需要调度，采用一定的调度策略，将请求分发给不同的服务器，这就是 Load Balance 负载均衡。
当单机 Tomcat，演化出多机多级部署的时候，一个问题便凸显出来，这就是 Session。而这个问题的由来，都是由于 HTTP 协议在设计之初没有想到未来的发展。
（1）HTTP 的无状态
HTTP 协议本身是无状态的，服务器无法识别两次请求是否来自同一个浏览器。
解决方案：
首次请求：浏览器第一次请求服务器时，服务器生成一个唯一的 SessionID 并返回给浏览器。
存储 SessionID：浏览器将 SessionID 保存在 Cookie 中（通常为临时存储，浏览器关闭即消失）。
后续请求：浏览器每次 HTTP 请求都会携带该 SessionID，服务器通过比对 ID 来识别用户。
生命周期：Session 通常保存在服务器内存中（未持久化则易丢失），且有过期时间；过期后服务器会重新生成新的 SessionID。
特殊情况：更换浏览器会获得新的 SessionID。
（2）HTTP 的有连接
HTTP 协议依赖于 TCP，是面向连接的，通信前需要进行三次握手建立连接，通信结束后需要四次挥手断开连接。
（3）HTTP 的短连接
HTTP/1.1之前：每个请求都需要独立创建和销毁 TCP 连接，连接创建销毁成本高，对服务器压力大。
HTTP/1.1及以后：支持并默认开启 keep-alive（长连接）机制。一个 TCP 连接打开后会保持一段时间，浏览器再次访问该服务器时可复用该连接，从而减轻服务器压力，提高效率。
注意：当使用 HAProxy 或 Nginx 等做负载均衡时，如果请求被调度到不同的 Tomcat 服务器上，且 Session 未共享，会导致找不到 SessionID 的问题。此外，即使 Session 被持久化，如果服务器故障且未恢复，也无法使用这些 SessionID。
（五）Memcached
1.简介
基本特性：
Memcached 是一款基于 Key-Value 的内存缓存系统，只支持能序列化的数据类型，不支持数据持久化（无 RDB 和 AOF）。单个 key 最大支持 1MB 存储对象，超过可通过客户端压缩或拆分处理。
高性能机制：
借助 libevent 库实现高效读写，该库统一封装了 Linux 的 epoll、BSD 的 kqueue 等事件处理接口，即使连接数增加也能保持高性能，支持 Linux、BSD、Solaris 等操作系统。
数据一致性保障：
虽无持久化，但可通过集群同步实现数据一致：
集群中各节点数据保持一致
单节点故障不影响整体可用
故障节点恢复后可自动从正常节点同步数据
内存管理：
采用 slab/page 机制：每次申请 1MB 内存作为一个 slab（page）进行存储管理。
应用场景与支持：
最佳实践：适合保存用户 Session，实现分布式环境下的 Session 共享
多语言支持：提供 Java、C、Python、PHP、C#、Ruby、Perl 等多种开发语言接口
2.操作命令
五种基本 memcached 命令执行最简单的操作。包括：set、add、replace、get、delete
前三个命令是用于操作存储在 memcached 中的键值对的标准修改命令,都使用如下所示的语法：
command <key> <flags> <expiration time> <bytes>
<value>
参数说明如下：
command set/add/replace
key key 用于查找缓存值
flags 可以包括键值对的整型参数，客户机使用它存储关于键值对的额外信息
expiration time 在缓存中保存键值对的时间长度（以秒为单位，0 表示永远）
bytes 在缓存中存储的字节数
value 存储的值（始终位于第二行）
增加 key，过期时间为秒，bytes 为存储数据的字节数
add key flags exptime bytes
（六）session 共享服务器
1.msm 介绍
项目概述：MSM 是一个开源项目，旨在将 Tomcat 的 Session 数据存储到 Memcached 中，从而实现高可用环境下的 Session 共享。项目早期托管于 Google Code，现已在 GitHub 上维护。
版本支持：支持 Tomcat 6.x、7.x、8.x、9.x 等多个主流版本。
核心组件：
Session 管理类：针对不同 Tomcat 版本提供特定的管理器 Jar 包，例如通用包 memcached-session-manager-2.3.2.jar 和对应 Tomcat 9 的 memcached-session-manager-tc9-2.3.2.jar。
序列化工具：负责 Session 数据的序列化与反序列化，官方推荐使用 Kryo。
客户端驱动：作为连接缓存服务器的驱动，支持 spymemcached (对应 Memcached) 和 jedis (对应 Redis)。
部署位置：需要将上述 Jar 包放置在 webapp/WEB-INF/lib/ 目录下。
2.安装
参考链接: https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
将 spymemcached.jar、memcached-session-manage、kyro 相关的 jar 文件都放到 Tomcat 的 lib目录中，这个目录是 $CATALINA_HOME/lib/ ，对应本次安装就是 /usr/local/tomcat/lib。
t1 和 m1 部署可以在一台主机上，t2 和 m2 部署也可以在同一台。
当新用户发请求到 Tomcat1 时, Tomcat1 生成 session 返回给用户的同时,也会同时发给memcached2 备份。即 Tomcat1 session 为主 session，memcached2 session 为备用 session，使用 memcached 相当于备份了一份 Session
如果 Tomcat1 发现 memcached2 失败,无法备份 Session 到 memcached2,则将 Sessoin备份存放在 memcached1 中
（七）Tomcat 实验
1.Tomcat 安装部署
下载安装包：
部署：
启动：
制作启动脚本：
安转好主机 rs2 的环境后，上传启动脚本
2.Tomcat+memcached 实现 session 会话零丢失
Tomcat 加载模块：
安装 memcache（两台主机均要）：
配置 Tomcat（两台主机均要）：
