# 一、Dify知识库使用
创建一个知识库

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

然后点击这里配置好自己一个embedding的模型
![image.png](/static/img/e2794515e4440c1b9f472b865db00e6c.image.webp)


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

然后等待解析

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

然后解析成功后，回去跟聊天助手进行关联配置

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


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

然后发布更新

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

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

6.Dify部署知识库

# 一、介绍
Dify(Define + Modify) 是一个开源的大语言模型 (LLM) 应用开发平台，融合了后端即服务 (BaaS) 与 LLMOps 理念，旨在帮助开发者 (包括非技术人员) 快速构建、部署和管理生产级的 AI 应用。

核心特点：
- 无需编程或低代码，通过可视化界面 "搭积木" 式开发 AI 应用
- 支持从原型设计到生产部署的完整生命周期管理
- 同时服务开发者和企业用户，降低 AI 应用开发门槛
# 二、去github下载dify
地址：https://github.com/mixun/dify/

下载好后上传到服务器。

然后进行解压


```js
unzip dify-main.zip
```

然后进去docker的目录，把.env.example改成.env

```js
cd /AI/dify-main/docker
```

```js
cp  .env.example  .env
cp middleware.env.example middleware.env
```
然后启动

```js
docker compose up -d 
```
等待拉取镜像启动
![image.png](/static/img/64c18b07181f3d2a657e9d928f0820ab.image.webp)

# 三、dify配置AI大模型

设置管理员账号登录
![image.png](/static/img/8ff34d80105230ee72811eb2f9aa618c.image.webp)

然后点击右上角设置-模型供应商-然后选择ollama

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

安装好后进行配置

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


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


# 四、创建一个聊天助手

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


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

5.Dify的安装

# 一、介绍
- 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)