# 一、介绍
- Redis 内存淘汰：原理、策略、配置与最佳实践
- Redis 是内存数据库，所有数据都存储在内存中，而内存资源有限。当 Redis 占用的内存达到预设上限（maxmemory）时，若再接收新的写请求（如 SET、INCR），就需要通过内存淘汰机制清理部分数据，释放内存空间，确保服务正常运行。
- 核心目标：在内存不足时，优先保留 “最有价值” 的数据，淘汰 “无用 / 低价值” 数据，避免因内存溢出导致服务崩溃或写请求失败。

# 二、核心前提：内存上限配置（maxmemory）

内存淘汰的触发条件是「Redis 已用内存 ≥ maxmemory」，因此需先通过配置指定内存上限：

配置文件 redis.conf（永久生效）

```js
maxmemory 4gb  # 限制 Redis 最大使用内存为 4GB（支持 kb/mb/gb 单位）
```
- 默认值：Redis 6.2+ 版本默认 maxmemory 0（不限制内存，会持续占用内存直到系统内存耗尽，不推荐线上使用）；
- 建议值：根据物理内存配置，通常设为物理内存的 70%-80%（如 8GB 物理内存设为 6GB），预留内存给操作系统和 Redis 其他进程（如持久化子进程）。

动态修改（临时生效，重启后失效）

```js
127.0.0.1:6379> CONFIG SET maxmemory 4gb  # 动态设置内存上限
OK
127.0.0.1:6379> CONFIG GET maxmemory  # 查看当前内存上限
1) "maxmemory"
2) "4294967296"  # 单位为字节（4GB = 4*1024*1024*1024）
```

未设置 maxmemory 的风险
- 若不限制内存，Redis 会持续存储数据，直到：
- 系统内存耗尽，触发操作系统的 OOM（Out Of Memory）杀死 Redis 进程；
- 服务器因内存压力过大，导致 Redis 响应延迟飙升，甚至服务不可用。


# 三、内存淘汰的核心逻辑
当 Redis 接收写请求时，执行流程如下：
1. 计算当前已用内存（used_memory）是否 ≥ maxmemory；
2. 若未超过：直接执行写请求；
3. 若已超过：根据配置的「淘汰策略」选择待淘汰的数据；
4. 删除选中的数据（释放内存），并触发对应键的过期回调（若有）、持久化日志（如 AOF 记录 DEL 命令）；
5. 执行当前写请求。


:::warning{title="注意"}
注意：淘汰仅针对「写请求」触发（SET、HMSET、INCR 等），读请求（GET、HGET）不会触发淘汰。
:::

# 四、Redis 内存淘汰策略

Redis 提供 8 种淘汰策略（Redis 4.0+ 新增 2 种 LFU 策略），按「淘汰范围」和「筛选规则」可分为 3 大类：

分类 1：仅淘汰「已过期」的键（过期键集合：设置了 EXPIRE/TTL 的键）

![image.png](/static/img/ce2798f1621063733b77458bced6e379.image.webp)

分类 2：淘汰「所有键」（包括过期键和未过期键）


![image.png](/static/img/a28a7c46fd1af88322b01fe39ee60d82.image.webp)

分类 3：不淘汰任何键（拒绝写请求）

![image.png](/static/img/4a0091a35eb68456cd5d244825b94ff0.image.webp)

10.redis内存淘汰机制

# 一、redis事务
- Redis 事务：定义、特性、用法与核心要点
- Redis 事务是 一组命令的有序集合，核心作用是将多个命令 “打包” 执行 ——要么全部执行，要么全部不执行（部分场景例外），且执行过程中不会被其他客户端的命令打断（串行执行）。
- 它和 MySQL 等关系型数据库的事务有本质区别：Redis 事务更轻量，不支持严格的 ACID 特性（尤其缺乏 “回滚” 机制），核心目标是保证命令的串行执行和批量提交。


- Redis 事务的核心命令
- Redis 事务通过 4 个核心命令实现完整流程，作用如下：
	

	
	
	

| 命令 | 功能描述 |
| --- | --- |
|MULTI	  |  开启事务：之后输入的所有命令都会被 “入队”（暂不执行），返回 QUEUED 标识|
| EXEC |  执行事务：触发队列中所有命令按顺序执行，返回每个命令的执行结果（数组形式）|
| DISCARD |  取消事务：清空命令队列，终止当前事务，不会执行任何入队命令|
|  WATCH| 监视 1 个或多个键：事务执行前，若被监视的键被其他客户端修改，事务会被取消（乐观锁核心） |

事务的完整流程分为 3 步：开启事务 → 命令入队 → 执行 / 取消事务，用实际操作示例说明：

```js
127.0.0.1:6379> MULTI  # 1. 开启事务
OK
127.0.0.1:6379> SET user:1:name "zhangsan"  # 2. 命令入队（暂不执行）
QUEUED
127.0.0.1:6379> SET user:1:age 25
QUEUED
127.0.0.1:6379> GET user:1:name  # 入队查询命令
QUEUED
127.0.0.1:6379> EXEC  # 3. 执行事务，返回所有命令结果
1) OK  # SET user:1:name 的结果
2) OK  # SET user:1:age 的结果
3) "zhangsan"  # GET user:1:name 的结果
```

取消事务
```js
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET k1 v1
QUEUED
127.0.0.1:6379> DISCARD  # 取消事务，队列清空
OK
127.0.0.1:6379> GET k1  # 命令未执行，返回 nil
(nil)
```

# 二、redis持久化

- Redis 是内存数据库，默认情况下数据仅存储在内存中，一旦服务器宕机（如断电、重启），数据会全部丢失。持久化的核心目的是：将内存中的数据定期 / 实时写入磁盘，重启后从磁盘恢复数据，避免数据丢失。
- Redis 提供两种核心持久化机制：RDB（Redis DataBase） 和 AOF（Append Only File），也支持两者结合的混合持久化（Redis 4.0+），适用于不同业务场景。

## RDB 持久化（快照模式）

RDB 是 Redis 的默认持久化方式，核心是：在指定时间点，将内存中的全量数据生成一份二进制快照文件（默认文件名 dump.rdb），写入磁盘。重启时，直接加载该文件到内存，快速恢复数据。

### 触发方式
- SAVE：直接由主进程生成快照，阻塞所有客户端请求，直到快照完成（不推荐线上使用，适用于小内存、测试环境）；
- BGSAVE：后台生成快照（Background Save），主进程不阻塞，通过子进程完成快照（线上推荐使用）。


```js
127.0.0.1:6379> BGSAVE  # 后台生成RDB快照
Background saving started
```

## 自动触发（配置文件 redis.conf）
通过 save <seconds> <changes> 配置 “触发条件”：在 seconds 秒内，数据发生 changes 次修改，自动执行 BGSAVE。
默认配置（可修改）：
    
    
```js
save 900 1    # 900秒（15分钟）内至少1次修改
save 300 10   # 300秒（5分钟）内至少10次修改
save 60 10000 # 60秒（1分钟）内至少10000次修改
```
    
- 优点：
- 恢复速度快：RDB 是二进制全量快照，重启时直接加载到内存，比 AOF 快一个数量级；
- 文件体积小：压缩后的二进制文件，占用磁盘空间少，适合备份（如每天凌晨生成 RDB 快照备份）；
- 性能影响小：快照由子进程完成，主进程仅 fork() 时短暂阻塞，不影响正常服务。
- 缺点：
- 数据丢失风险高：仅记录 “某个时间点” 的快照，若两次快照之间宕机，期间的修改数据会全部丢失（如配置 save 60 10000，则最多可能丢 1 分钟数据）；
- fork() 开销大：若 Redis 内存较大（如 10GB+），fork() 会消耗大量虚拟内存，且可能导致主进程短暂阻塞（毫秒 / 秒级）；
- 不适合实时持久化：无法做到 “秒级” 数据落地，适合对数据一致性要求不高的场景。  
    
   
## AOF 持久化（日志模式）
    
AOF（Append Only File）是增量持久化方式，核心是：将每一条 “写命令”（如 SET、INCR、HMSET）以文本格式追加到 AOF 日志文件（默认 appendonly.aof）中。重启时，Redis 会重新执行 AOF 文件中的所有命令，还原内存数据。    
    
### 工作原理（三步流程）
    
1. 命令追加（Append）：客户端执行写命令后，Redis 先将命令写入内存中的 “AOF 缓冲区”（避免频繁磁盘 IO）；
2. 缓冲区同步（Sync）：根据配置的 “同步策略”，将缓冲区数据刷写到磁盘（核心是平衡性能和数据安全性）；
3. 文件重写（Rewrite）：AOF 文件会随命令增多而膨胀，Redis 会定期 “重写” AOF 文件，删除无效命令（如 SET k1 v1 后又 DEL k1）、合并重复命令（如 INCR k1 3 替代 3 次 INCR k1），压缩文件体积。
    
核心配置（redis.conf）    
```js
appendonly yes  # 默认为 no，改为 yes 启用 AOF    
```
    
### 同步策略
 AOF 缓冲区同步到磁盘的策略，通过 appendfsync 配置，有 3 种选择：   
![image.png](/static/img/cdf7ab17921d2294e9357a413e02799e.image.webp)
    
### 优缺点
优点：
- 数据丢失少：支持秒级 / 零级数据落地（everysec/always），宕机最多丢失 1 秒数据（或零丢失），适合对数据一致性要求高的场景；
- 文件可读性强：AOF 是文本文件，可直接查看命令日志，甚至手动修改（如误删数据后，编辑 AOF 文件删除误操作命令，再重启恢复）；
- 无 fork() 阻塞风险：重写虽用子进程，但主进程仅需处理 “重写缓冲区”，阻塞时间极短（远低于 RDB 的 fork() 开销）。
    
 缺点：
- 恢复速度慢：重启时需重新执行所有命令，若 AOF 文件较大（如 10GB+），恢复时间可能长达分钟级，远慢于 RDB；
- 文件体积大：未重写的 AOF 文件体积远大于 RDB（如频繁修改同一键，会记录大量重复命令），磁盘占用高；
- 性能开销略高：写命令需追加到缓冲区 + 定期刷盘，everysec 模式下性能比 RDB 略低（但可接受），always 模式性能损耗明显。
    
    
    
### 混合持久化（Redis 4.0+，默认启用）
混合持久化是 RDB + AOF 的结合方案：AOF 文件开头存储 “RDB 全量快照”，后面追加 “AOF 增量命令日志”。重启时，先加载 RDB 快照快速恢复全量数据，再重放 AOF 增量命令，补充快照后的修改数据。
    
    
启用混合持久化后（aof-use-rdb-preamble yes），执行 BGREWRITEAOF 或自动重写时，Redis 会：
- 子进程生成 RDB 快照，写入新 AOF 文件开头；
- 主进程将重写期间的增量命令写入 “重写缓冲区”；
- 子进程写完 RDB 后，主进程将缓冲区命令追加到新 AOF 文件；
- 用新 AOF 文件（RDB + 增量命令）替换旧 AOF 文件。    
    
核心优势   
- 恢复速度快：兼顾 RDB 的 “快速加载” 和 AOF 的 “数据完整性”；
- 文件体积小：RDB 部分压缩，AOF 部分仅存增量命令，比纯 AOF 小；
- 数据丢失少：仅丢失 “最后一次重写到宕机” 期间的命令（最多 1 秒，取决于 appendfsync 配置）。
    
:::note{title="注"}
注意：混合持久化的 AOF 文件不再是纯文本（开头是 RDB 二进制数据），无法直接编辑，若需修改，需先禁用混合持久化，重写后再编辑。
:::
    

![image.png](/static/img/025bc918fa7ea85a8907ae6ea38557f9.image.webp)

9.redis的事务和持久化

# 一、操作

![image.png](/static/img/8798635ea6475f4d7dc1c70c57bfb201.image.webp)

# 二、创建用户组
![image.png](/static/img/50158ddf360e369c59165e8acb2146d7.image.webp)

![image.png](/static/img/ece46a58137f598eec953a1225fd22c1.image.webp)

![](https://songxuan.vip/static/img/a8d1e9f415bbd27bafb79a6c9077b551.image.webp)

# 三、创建用户进行授权


![image.png](/static/img/30283e475cce8eb786c0ea951c45418e.image.webp)

![image.png](/static/img/50bf2985c1ba18b2b43c4e927ef12540.image.webp)

![image.png](/static/img/0fb38e3debed87f3d3120f1b1c9546d9.image.webp)


![image.png](/static/img/c17005c9dffd67410ad30c5fade909c2.image.webp)

# 四、测试用户登录
复制登录地址

![image.png](/static/img/0599ec1274d12a2cbd242ff4df62f07c.image.webp)


![image.png](/static/img/04d1eb0f078c2dba7a54c5344cc709dc.image.webp)

成功登录
![image.png](/static/img/09f66b8c21f860b0e89071af6a29fb26.image.webp)


当访问没授权的资源时就会提示

![image.png](/static/img/f5eac6c1f0f1cec1e50cb975bcb95270.image.webp)

5.阿里云访问控制ram

# 一、介绍

| 云存储类型 |  |
| --- | --- |
| 块存储 |云盘(数据盘,系统盘)  |
| nas存储文件存储 |类以于nfs(web配置，命令行进行挂载) 不支持高并发，容量有限|
| oss存储对象存储|类似于文件存储，使用方式程序代码通过接口调用 支持高并发，容量无限|


# nas的使用

![image.png](/static/img/6503c680f96f83be1b51c4b73e4750c8.image.webp)


![image.png](/static/img/a291dd156966bce0b86bf8c80835bfc0.image.webp)

4.阿里云存储

# 一、介绍
在 Ansible 中，Roles（角色） 是一种模块化、结构化的组织方式，用于将复杂的 Playbook 拆分为多个独立的 “功能单元”（如 “部署 Nginx”“配置数据库”“安装 ELK” 等）。它通过固定的目录结构，将任务、变量、模板、文件等按功能分类存放，让代码更清晰、更易复用和维护，尤其适合大型项目、团队协作或需要跨项目复用的场景。

为什么需要 Roles？
- 当 Playbook 用于复杂场景（如部署一个完整的 ELK 集群）时，直接写在单个 YAML 文件中会导致：
- 代码冗长（几百行甚至上千行），难以阅读和修改；
- 功能耦合严重（比如 “安装 Elasticsearch” 和 “配置 Logstash” 的代码混在一起）；
- 无法复用（换一个项目部署 ELK 时，需要重新复制粘贴代码，容易出错）。
- Roles 则通过标准化目录结构解决这些问题：将一个完整功能（如 “部署 Elasticsearch”）拆分为独立角色，每个角色内部包含自己的任务、变量、配置文件等，需要时直接 “调用” 即可。
- Roles 的核心目录结构
- 每个 Role 必须遵循固定的目录结构（Ansible 会自动识别这些目录的作用），典型结构如下：


```js
roles/
└── elasticsearch/  # 角色名称（比如“部署 Elasticsearch”的角色）
    ├── tasks/      # 核心任务（必须有，存放要执行的任务列表）
    │   └── main.yml  # 任务入口文件（Ansible 会自动加载）
    ├── handlers/   # 处理器（存放被 notify 触发的任务，如重启服务）
    │   └── main.yml
    ├── vars/       # 角色专属变量（优先级较高，通常不允许用户修改）
    │   └── main.yml
    ├── defaults/   # 角色默认变量（优先级较低，允许用户在外部覆盖）
    │   └── main.yml
    ├── templates/  # 模板文件（带变量的配置文件，如 elasticsearch.yml.j2）
    ├── files/      # 静态文件（无需渲染的文件，如证书、脚本）
    └── meta/       # 角色元信息（如作者、依赖关系）
        └── main.yml
```

# 二、实操
- 目标场景
- 通过 Roles 实现：
- 在目标主机（elk1组）安装 Nginx；
- 用模板生成 Nginx 配置文件（支持自定义端口）；
- 替换默认首页为带动态内容的 HTML（显示主机名和自定义标题）；
- 配置防火墙允许 Nginx 端口访问；
- 确保 Nginx 服务启动并开机自启。



## 步骤 1：创建项目目录结构

```js
# 创建项目根目录
mkdir -p ~/nginx_role_demo
cd ~/nginx_role_demo

# 创建Roles及子目录（nginx为角色名）
mkdir -p roles/nginx/{tasks,handlers,templates,defaults,files}

# 最终目录结构如下
tree .
.
├── roles/
│   └── nginx/               # 角色名：部署Nginx
│       ├── tasks/           # 任务列表（核心）
│       ├── handlers/        # 处理器（重启服务等）
│       ├── templates/       # 模板文件（带变量）
│       ├── defaults/        # 默认变量（可被覆盖）
│       └── files/           # 静态文件（可选）
└── deploy_nginx.yml         # 主Playbook：调用角色
```

## 步骤 2：编写 Roles 各组件文件
### defaults/main.yml（默认变量，可被外部覆盖）
```js
vi /root/nginx_role_demo/roles/nginx/defaults/main.yml
```

定义 Nginx 端口、首页标题等默认值：

```yml
nginx_port: 80                   # 默认端口
page_title: "Default Web Page"   # 默认首页标题
firewall_service: "firewalld"    # 防火墙服务名（CentOS默认firewalld）
```

### templates/nginx.conf.j2（Nginx 配置模板，用变量定义端口）

模板文件以.j2为后缀，通过{{ 变量名 }}引用变量：

```js
vi /root/nginx_role_demo/roles/nginx/templates/nginx.conf.j2
```
```js
server {
    listen {{ nginx_port }};  # 监听端口（引用defaults中的变量）
    server_name _;

    root /usr/share/nginx/html;
    index index.html;

    # 日志配置
    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;
}
```


### templates/index.html.j2（自定义首页模板，显示主机名和标题）

用{{ ansible_hostname }}（Ansible 内置变量，获取主机名）和自定义标题：

```js
vi /root/nginx_role_demo/roles/nginx/templates/index.html.j2
```
```js

<!DOCTYPE html>
<html>
<head>
    <title>{{ page_title }}</title>
</head>
<body>
    <h1>Welcome to {{ page_title }}!</h1>
    <p>Hostname: {{ ansible_hostname }}</p>  
    <p>Deployed by Ansible Roles.</p>
</body>
</html>
```

### tasks/main.yml（核心任务列表，按顺序执行）

```js
vi /root/nginx_role_demo/roles/nginx/tasks/main.yml
```
定义安装、配置、启动等步骤：
```yml
# 任务1：安装Nginx
- name: 安装Nginx服务
  yum:
    name: nginx
    state: present  # 确保已安装
  tags: install  # 打标签，方便单独执行

# 任务2：复制Nginx配置文件（用templates目录的模板）
- name: 配置Nginx监听端口
  template:
    src: nginx.conf.j2  # 从templates目录加载模板
    dest: /etc/nginx/conf.d/default.conf  # 远程目标路径
    mode: 0644  # 文件权限
  notify: 重启Nginx  # 配置文件变化时，触发handlers重启服务
  tags: config

# 任务3：替换默认首页（用templates目录的模板）
- name: 部署自定义首页
  template:
    src: index.html.j2
    dest: /usr/share/nginx/html/index.html
    mode: 0644
  tags: page

# 任务4：配置防火墙允许Nginx端口访问
- name: 防火墙允许{{ nginx_port }}端口
  firewalld:
    port: "{{ nginx_port }}/tcp"
    permanent: yes  # 永久生效
    immediate: yes  # 立即生效（无需重启防火墙）
    state: enabled
  tags: firewall

# 任务5：确保Nginx服务启动并开机自启
- name: 启动Nginx服务
  service:
    name: nginx
    state: started
    enabled: yes  # 开机自启
  tags: service
```

### handlers/main.yml（处理器：配置变化后重启 Nginx）
仅在被notify触发时执行：

```js
vi /root/nginx_role_demo/roles/nginx/handlers/main.yml
```
```js
# roles/nginx/handlers/main.yml
- name: 重启Nginx
  service:
    name: nginx
    state: restarted
```

## 步骤 3：编写主 Playbook（deploy_nginx.yml）
在项目根目录创建 Playbook，指定目标主机并调用nginx角色，可覆盖默认变量：

```js
vi /root/nginx_role_demo/deploy_nginx.yml
```
```js
# ~/nginx_role_demo/deploy_nginx.yml
- name: 使用Roles部署Nginx服务
  hosts: elk1  # 目标主机组（对应hosts文件中的elk1）
  remote_user: root  # 远程执行用户
  roles:
    - role: nginx  # 调用roles/nginx角色
  vars:
    # 覆盖默认变量：端口改为8080，首页标题改为"ELK Web Server"
    nginx_port: 8080
    page_title: "ELK Web Server"
```

## 步骤 4：执行 Playbook 部署服务
在控制机项目目录下执行命令：

```js
cd ~/nginx_role_demo
ansible-playbook deploy_nginx.yml
```
只要看到都是绿色就没问题了，
![image.png](/static/img/eae140f56deca82ee0d7350c84fc6d98.image.webp)


![image.png](/static/img/cf933709507ea693b5b8479e4cfbb11e.image.webp)
- 执行过程说明：
- Ansible 会先解析deploy_nginx.yml，找到roles: nginx，然后加载roles/nginx/tasks/main.yml中的任务。
- 按顺序执行 “安装 Nginx→配置端口→部署首页→配置防火墙→启动服务”。
- 若 Nginx 配置文件有变化（如端口从默认 80 改为 8080），会触发handlers中的 “重启 Nginx”。

验证
```js
curl 192.168.183.112:8080
```