Skip to content

Commit 1819ec4

Browse files
committed
fix(redis): correct appendfsync always description - main thread fsync, not background thread
1 parent 2a19e80 commit 1819ec4

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/database/redis/redis-persistence.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -194,7 +194,7 @@ AOF 工作流程图如下:
194194

195195
在 Redis 的配置文件中存在三种不同的 AOF 持久化方式( `fsync`策略),它们分别是:
196196

197-
1. `appendfsync always`:主线程调用 `write` 执行写操作后,会立刻调用 `fsync` 函数同步 AOF 文件(刷盘)。主线程会阻塞,直到 `fsync` 将数据完全刷到磁盘后才会返回。这种方式数据最安全,理论上不会有任何数据丢失。但因为每个写操作都会同步阻塞主线程,所以性能极差。
197+
1. `appendfsync always`:主线程调用 `write` 执行写操作后,会立即调用 `fsync` 函数同步 AOF 文件(刷盘),期间主线程阻塞,直到 `fsync` 将数据完全刷到磁盘后才会返回`always` 策略由**主线程直接执行 fsync**,而非后台线程。这种方式数据最安全,理论上不会有任何数据丢失。但因为每个写操作都会同步阻塞主线程,所以性能极差。
198198
2. `appendfsync everysec`:主线程调用 `write` 执行写操作后立即返回,由后台线程( `aof_fsync` 线程)每秒钟调用 `fsync` 函数(系统调用)同步一次 AOF 文件(`write`+`fsync``fsync`间隔为 1 秒)。这种方式主线程的性能基本不受影响。在性能和数据安全之间做出了绝佳的平衡。不过,在 Redis 异常宕机时,通常可能丢失最近 1 秒内的数据。
199199

200200
> **生产级真相(2 秒丢失与阻塞风险)**

0 commit comments

Comments
 (0)