WAL日志必须通过fdatasync()（而非仅fwrite()或fflush()）确保持久化，否则崩溃会丢数据；高频fsync()是性能瓶颈，应采用异步批量刷盘（如环形缓冲区+独立I/O线程），并严格处理fsync()失败及目录同步。
WAL日志写入时，fwrite() 之后不立刻 fsync() 会丢数据
WAL（Write-Ahead Logging）的核心语义是：日志必须先于数据落盘，且事务提交前日志必须持久化。这意味着 fwrite() 写入用户缓冲区、甚至 write() 进内核页缓存都不够——只有 fsync() 或 fdatasync() 成功返回，才算满足 WAL 持久性要求。很多团队在压测中发现“日志写了但崩溃后丢失”，问题就出在这里：只调了 fwrite() + fflush()，没调 fsync()。
频繁 fsync() 是 WAL 性能瓶颈的主因
每次 fsync() 都触发一次强制刷盘，涉及内核脏页回写、I/O 调度、磁盘物理寻道（尤其机械盘），延迟常达毫秒级。若每条 WAL 记录都 fsync()，吞吐直接掉两个数量级。PostgreSQL 默认启用 synchronous_commit = on，正是靠它保障强一致性，但也因此把 WAL 写入变成串行瓶颈。
-
fsync()开销大，但不可省；关键在于“谁来调、何时调、调几次” - 用
fdatasync()替代fsync()可跳过 inode 元数据刷新，在多数文件系统（ext4/xfs）下性能提升 10%~30%，且对 WAL 安全无影响（WAL 文件本身不依赖元数据变更） - 避免在循环里对同一
FILE*频繁fflush()+fsync()：每次fflush()触发write()系统调用，叠加fsync()就是双倍开销 - 更高效的做法是：攒一批日志（比如 16KB），
fwrite()后只做一次fflush()+fdatasync()
异步批量刷盘才是高吞吐 WAL 的正解
真正的平衡点不在“少调 fsync”，而在“让 fsync 不阻塞主线程”。muduo 日志模块和自研 WAL 库都采用类似模式：业务线程只负责把日志拷贝进环形缓冲区（lock-free），由独立 I/O 线程聚合写入 + 批量 fdatasync()。这样既保证每批日志最终落盘，又把系统调用开销摊薄。
- 聚合时机建议双条件触发：
buffer.size() >= 64KB或time_since_last_sync >= 1ms，兼顾延迟与吞吐 - 不要用
setvbuf(stream, buf, _IOFBF, size)自定义大缓冲区来“减少 fsync 次数”——这反而增加单次刷盘压力，且缓冲区生命周期难管理 - 若使用
O_DSYNC标志打开文件（如open("wal.log", O_WRONLY | O_APPEND | O_DSYNC)），则每次write()都隐式同步，性能比手动fdatasync()更差，不推荐 - 务必在
rename()切换 WAL 文件后，对目录 fd 调用一次fsync()（如fd = open(".", O_RDONLY); fsync(fd); close(fd);），否则重命名操作可能未落盘，崩溃后找不到新日志文件
fsync() 失败必须处理，不能静默忽略
很多人把 fsync() 当作“尽力而为”，返回 -1 就 log 一句完事。但在 WAL 场景下，fsync() 失败意味着日志未持久化，此时继续提交事务等于主动放弃一致性。正确做法是：
立即学习“C++免费学习笔记（深入）”；
- 检查
errno：常见有EIO（磁盘故障）、ENOSPC（磁盘满）、EROFS（文件系统只读） - 遇到
ENOSPC必须立即触发告警并停止写入，不能靠“清空旧日志”自救——WAL 文件滚动本身也依赖fsync() - 若业务允许降级，可切换到
sync_file_range()（Linux）做非阻塞刷脏页，但需配合监控确认刷盘进度，不能替代fdatasync()
最易被忽略的是：WAL 的可靠性不取决于单次 fwrite() 是否成功，而取决于 fdatasync() 的调用节奏、错误响应策略，以及目录项同步这个“隐形步骤”。任何想绕过 fsync() 类系统调用的优化，本质都是在赌硬件不掉电、磁盘不坏、内核不崩——生产环境里，这种赌注代价太高。
