一、redis雪崩、击穿、穿透
1.1 Redis 缓存雪崩（Cache Avalanche）
1.1.1 核心现象与级联故障机制
级联故障定义：当 Redis 集群中的 Master 节点因瞬时压力过大而宕机，哨兵机制会选举新的 Master，但新 Master 因无法承受原有 Master 的全部瞬时流量而再次宕机，形成多米诺骨牌效应，最终导致整个集群不可用。
流量冲击模拟：以 Nginx 为例，若 45 万并发由 3 台 Nginx 处理（每台 15 万），当一台宕机后，剩余两台需各承担 22.5 万并发（超过单机 20 万上限），导致剩余节点相继崩溃。
1.1.2 主要诱因分析
服务器物理故障：服务器宕机或物理损坏导致节点不可用。
服务异常停止：Redis 服务进程因资源耗尽或配置错误而异常退出。
网络异常：网络分区或延迟导致节点间通信中断，引发哨兵误判并触发主备切换，但新主节点无法承受瞬时流量。
1.1.3 解决方案
架构层面：升级为 Redis Cluster 模式，实现多主多从，分散压力；增加服务器数量以提升整体承载能力。
策略层面：设置 Key 的过期时间随机化，避免大量 Key 同时过期；利用互斥锁（Mutex Lock）或分布式锁控制数据库重建缓存的并发数。
降级措施：实施熔断降级机制，在检测到系统压力过大时，暂时屏蔽部分非核心功能或直接返回预设值，保护底层数据库。
1.2 Redis 缓存击穿（Cache Breakdown）
1.2.1 问题成因
热点 Key 失效：某个高并发访问的热点 Key（如秒杀商品）在过期瞬间，大量请求同时到达，导致数据库瞬时压力激增。
1.2.2 解决方案
设置永不过期：对于核心热点数据，直接设置 Key 为永不过期（TTL 设为 -1），通过后台异步更新策略来维护数据一致性。
互斥锁重建：在缓存失效时，使用分布式锁控制只有一个线程去数据库查询并重建缓存，其他线程等待或返回旧值。
1.3 Redis 缓存穿透（Cache Penetration）
1. 3.1 问题本质
无效请求攻击：恶意请求或程序 Bug 导致频繁查询数据库中不存在的数据（如 ID 为负数或空值），Redis 无法命中，导致每次请求都直达数据库，造成资源浪费。
1.3.2 防御方案
缓存空对象：对于查询结果为空的 Key，在 Redis 中缓存一个空值（如 Null）并设置较短的过期时间，避免频繁穿透。
参数校验：在接口入口处进行严格的参数校验，如 ID 小于等于 0 的直接拒绝，拦截无效请求。
布隆过滤器（Bloom Filter）：利用二进制数组提前判断数据是否存在，若不存在则直接拦截，适用于高安全场景。
二、Docker 容器化部署优势
2.1 传统服务升级痛点与蓝绿发布策略
2.1.1 传统部署痛点
流程繁琐：传统部署需经历下载新包、解压、编译、流量切换（Graceful Shutdown）等多个步骤，操作复杂且容易出错。
环境依赖强：强依赖服务器环境，迁移和回滚困难。
2.1.2 Docker 解决方案
一键更新：利用 Docker 镜像和容器编排技术，可以实现"一条命令"完成所有服务器的业务版本更新与部署，极大提升效率。
环境一致性：通过镜像封装应用及其运行环境，确保开发、测试、生产环境的一致性。
2.2 Docker 容器技术优势与微服务解耦
2.2.1 容器化部署的效率革命
秒级启动与隔离：Docker 容器将应用封装在独立空间内，通过进程隔离实现多实例并行运行，避免了端口冲突，部署时间从分钟级缩短至秒级。
环境一致性保障：容器镜像包含了应用运行所需的所有依赖，解决了"开发环境正常，生产环境异常"的问题，实现了跨环境的一致性。
2.2.2 微服务与容器的协同效应
独立部署与更新：微服务架构将单体应用拆分为独立功能模块（如支付、乘车码），配合容器技术可实现单个服务的独立打包、部署与更新，无需整体重启。
资源利用率提升：容器轻量级的特性允许在同一台宿主机上密集部署多个微服务实例，有效提升了物理服务器的资源利用率。
2.3 虚拟化技术原理与资源管理
2.3.1 虚拟化技术的产生背景
资源利用率低下：早期服务器性能过剩，业务负载低，导致服务器资源利用率极低（如仅 20%），造成巨大的资产浪费。
成本控制需求：高昂的硬件成本与低下的利用率促使企业寻求技术手段来提高服务器资源的利用效率。
2.3.2 虚拟化的核心实现机制
软件模拟硬件：虚拟化技术通过在物理硬件之上安装虚拟化软件（Hypervisor），模拟出多个独立的虚拟硬件环境，从而实现在单一物理机上运行多个操作系统。
资源隔离与复用：通过对 CPU、内存、存储等物理资源的抽象与隔离，实现了多租户的资源共享与安全管理，解决了早期服务器"摸鱼"的问题。
2.4 虚拟化技术与原理
2.4.1 虚拟化的定义与目的
核心定义：虚拟化是一种通过软件模拟硬件功能的技术，旨在解决服务器资源利用率低（如仅20%）及维护成本高的问题。
实现方式：通过安装虚拟化软件（如VMware），在一台物理服务器上创建多个相互隔离的独立操作系统环境，实现资源的统一管理。
2. 4.2 云计算与虚拟化的关联
云服务本质：公有云（如阿里云ECS）的本质是大型IDC数据中心通过虚拟化技术将物理资源池化，用户按需申请资源，实现多租户共享同一物理机资源。
资源隔离：不同用户申请的ECS实例虽然可能位于同一物理机，但通过虚拟化技术实现了操作系统级别的隔离，互不影响。
2.4.3 核心组件与资源管理
虚拟机监视器（Hypervisor） ：作为虚拟化软件的核心组件，负责管理系统资源（CPU、内存、磁盘、网络），并将其精细化分配给各个虚拟机使用。
资源分配机制：Hypervisor将物理资源视为"蛋糕"，通过切分和隔离机制，确保每个虚拟机获得指定的资源配额，并保证数据安全。
2.5 容器化技术与轻量化对比
2.5.1 容器与虚拟化的关系
技术分支：容器技术本质上是虚拟化的一种分支，但相较于传统虚拟化，容器技术更为轻量级和简单易用。
架构差异：传统虚拟化包含完整的操作系统内核，而容器直接共享宿主机的Linux内核，仅包含应用运行所需的文件系统（Rootfs）。
2.5.2 轻量化优势体现
资源占用：容器镜像体积极小（如CentOS仅204MB），启动速度快（秒级），而虚拟机需包含完整操作系统（GB级别），启动耗时分钟级。
适用场景：容器适用于快速测试、微服务部署等场景，一条命令即可完成环境搭建与运行，用完即删，资源消耗极低。
2.5.3 核心特性对比
隔离级别：容器实现进程级别的隔离，安全性相对较弱；虚拟机实现内核级别的完整操作系统隔离，安全性更强。
性能损耗：容器直接调用宿主机资源，几乎无额外性能损耗；虚拟机需通过Hypervisor层转发，存在一定的性能损耗。
2.6 Docker核心架构与概念
2.6.1 三大核心概念
镜像（Image） ：类似操作系统的ISO镜像，是一个只读的模板文件，用于创建容器。
容器（Container）： 基于镜像创建的运行实例，是镜像运行时的持续状态。
**仓库（Registry）：**用于存放镜像的仓库，类似于YUM仓库，分为公有仓库（Docker Hub）和私有仓库。
2.6.2 Docker组件架构
客户端（Client）： 用户通过命令行或Web界面与Docker交互。
守护进程（Docker Daemon） ：运行在宿主机后台的进程，负责管理Docker对象（镜像、容器、网络等）。
容器运行时（Runtime） ：负责容器的实际运行环境。
三、Docker 架构原理与工作流程
3.1原理与工作流程
3.1.1 核心组件与状态
三大核心概念：Docker 生态包含镜像（Image，即模板文件）、容器（Container，即运行实例）和镜像仓库（Registry，即模板存储中心） 。
容器运行时状态：容器运行时的生命周期包含创建状态、运行状态和关闭状态，其中运行状态是容器持续运行的核心阶段。
3.3.2 客户端与服务端交互流程
C/S 架构模型：Docker 采用客户端-服务端架构，客户端（CLI 或 Web 控制台）发送指令给服务端（Docker Daemon），由服务端负责执行具体操作。
镜像拉取与运行机制：当执行 `docker run` 命令时，服务端首先检查本地是否存在指定镜像，若无则从远程仓库（默认为 Docker Hub）拉取，随后创建并启动容器。
3.2 Docker 环境部署与配置实战
3.2.1 基础环境安装与源配置
YUM 源替换：由于 Docker 官方源访问不稳定，需将 YUM 源替换为清华大学镜像源，以加速依赖包的下载。
版本选择与安装：演示了安装 Docker CE（社区免费版）20.10.18 版本的具体命令，并强调了企业版（EE）与社区版的区别。
3.2.2 镜像加速器配置
配置镜像加速：为解决 Docker Hub 拉取镜像缓慢的问题，需在 `/etc/docker/daemon.json` 文件中配置国内镜像加速器地址（如阿里云、华为云）。
配置生效验证：配置完成后需重启 Docker 守护进程，并通过拉取 `hello-world` 镜像验证加速器是否生效。
3.3 RuoYi 项目快速部署实战
3.3.1 多组件容器化部署
全栈服务启动：利用 Docker 快速拉取并运行了 MySQL 5.7、Redis、Java 后端及 Nginx 前端镜像。
资源占用优势：在仅 1.78G 内存的环境下，成功运行了包含数据库、缓存、后端和前端的完整项目，证明了容器的轻量级特性。
3.3.2 部署效率对比
时间效率提升：相较于传统环境搭建耗时 1-2 小时，利用 Docker 完成整个项目的部署仅需约 6 分钟，极大提升了部署效率。
四、Docker 命令
4.1 Docker 镜像管理
4.1.1 镜像生命周期管理
查看与下载：`docker images` 用于查看本地镜像列表（含名称、标签、ID、大小）；`docker pull` 用于从仓库拉取镜像，支持指定版本标签。
删除操作：`docker rmi` 用于删除镜像，若镜像已被容器使用，必须先删除容器或使用 `-f` 强制删除。
导入导出：`docker save -o` 将镜像导出为 tar 包，`docker load -i` 将 tar 包导入还原为镜像，支持多镜像打包导出。
4.1.2 镜像信息探查
元数据查看：`docker inspect` 命令以 JSON 格式展示镜像的详细信息，包括构建历史、环境变量及启动配置。
启动配置解析：重点解析了 `CMD` 和 `EntryPoint` 的作用，两者均为容器启动后的第一个进程任务，`EntryPoint` 通常用于环境检测，`CMD` 用于指定默认启动命令。
4.2 Docker 容器管理
4.2.1 容器运行与状态监控
运行参数详解：`docker run` 命令中，`-i` 保持标准输入打开，`-t` 分配伪终端（通常组合为 `-it` 用于交互），`-d` 使容器在后台以守护进程运行。
状态查看：`docker ps` 仅查看运行中的容器，`docker ps -a` 查看所有状态的容器（含已停止）。
4.2.2 容器交互与文件传输
进入容器：推荐使用 `docker exec -it` 进入容器，该方式类似 SSH 连接，退出时不会终止容器进程；而 `attach` 命令退出时会关闭容器进程。
文件传输：`docker cp` 命令用于容器与宿主机之间的文件互传，语法类似 `scp` 命令。
4.3 核心机制与注意事项
4.3.1 CMD 命令覆盖机制
覆盖逻辑：`docker run` 命令末尾指定的命令会覆盖镜像中定义的 `CMD`。例如，若运行 Nginx 容器时指定 `/bin/bash`，会覆盖默认的 Nginx 启动命令，导致服务无法自动启动。
风险提示：在运行服务类容器（如 Nginx）时，若需保留原有服务启动逻辑，应避免在 `run` 命令末尾添加自定义命令。
4.3.2 删除约束与冲突处理
删除依赖：删除镜像前需确保无容器依赖，否则需先删除容器或使用 `rmi -f` 强制删除。
命名冲突：创建容器时若指定名称（`--name`），需确保名称唯一，否则会因名称冲突导致创建失败。
总结
bash
缓存雪崩：
主要是服务器或者集群异常，导致没法正常工作，然后集群一台一台接连失效，导致流量打到mysql上的现象
诱因： 服务器宕机（物理上）
解决：
代码业务：优化key的请求策略以及数据库内分布式锁的机制
key 过期时间/淘汰策略： 随机过期时间，尽量不要设置为同时过期
集群方向：高可用（主从模式---》cluster模式） 增加服务器数量
expire teacher 100 80000~160000
容器是什么? 干嘛的？ 怎么用的？
### 容器是什么?
我们从宏观上来看，容器就是一个应用服务，更多意义上，像是一个管理其他应用服务的工具
容器可以把其他的应用服务，装在一个内部空间中，以容器进程的方式进行管理，可以做到快速启动、升级以及管理策略
### 干嘛的？
把服务程序的控制管理变的简易化，轻量化
"Docker 容器引擎"是容器技术中的一个产品，也是当前主流的容器技术
### 怎么实现的？？
虚拟化
什么是虚拟化，虚拟化能干嘛
诱因：早年间，服务器的"资源利用率"很低（1d 20%不到的时间在工作，其他时间在摸鱼）
为了能够充分的提高服务器的利用率，研发了一款技术：虚拟化，以此来"提高服务器资源的利用率"问题
技术研究的方向是什么
① 从宏观上来看，就是使用软件"模拟"硬件功能
安装软件--》可以管理和自主分配系统的资源给不同的操作系统环境使用
② 虚拟化，不仅可以模拟操作系统，还可以对系统的资源进行精细化的合理分配
比如CPU 、 MEM 、 磁盘 、网络 、I/O
虚拟化中有一个非常重要的组件：hypervisor ，可以管理系统资源并分配给对应的OS操作系统使用，并且相互隔离
和容器有什么关系？？
容器属于虚拟化的一种技术，但是相对传统意义上而言的虚拟化，容器技术更为的轻量级和简单易用。
⭐⭐⭐容器和虚拟机的区别（面试题）
容器 虚拟机
启动速度 秒级 分钟级
占用空间 轻量级 重量级
隔离级别 进程隔离 内核隔离
安全性 较弱 较强
扩展能力 方便 比较麻烦
资源损耗 几乎无 有一定的性能损耗
容器和虚拟化的本质区别：
① 虚拟机是完整独立的操作系统，拥有完整的系统内核
② 容器的系统内核是和Linux 系统共用的
分解：
操作系统内核文件分为： bootfs（相同的部分） 和rootfs （个性化的部分）