持久化最终落在盘上
持久化的性能与安全最终由磁盘决定：增量日志的每秒刷盘依赖刷盘延迟是否稳定，快照与日志重写依赖顺序写吞吐。本地固态盘通常优于网络存储，因为网络盘的刷盘长尾抖动会直接变成主线程阻塞与请求超时。
基本信息
| 关注指标 | 刷盘延迟及其分布、写队列深度、云盘突发额度 |
|---|---|
| 相关配置 | 刷盘策略、重写期间是否避让刷盘、数据目录位置 |
| 观测工具 | 系统级磁盘统计工具、磁盘基准测试工具 |
| 侧指标 | INFO persistence 中的刷盘延迟计数与最近写入状态 |
选型与排查
- 新实例选型：按刷盘延迟选盘，而不是只看容量与顺序带宽
- 云盘评估：确认基准性能与突发额度，跑满后延迟会突然抬高
- 延迟排查：业务超时时间点与磁盘写延迟上升是否对齐
- 重写冲突：日志重写期间主线程刷盘被拖慢，表现为周期性抖动
- 目录规划：数据目录与备份目录分盘，避免互相抢占
观测示例
观测示例
iostat -x 1 5 # 观察单请求等待时间与设备饱和度
fio --filename=/data/testfile --rw=randwrite --bs=4k --fsync=1 --runtime=30 --name=fsync-test
redis-cli INFO persistence | grep -E 'aof_last_write_status|aof_delayed_fsync|aof_last_bgrewrite_status'
redis-cli CONFIG GET appendfsync no-appendfsync-on-rewrite dir
mount | grep -E ' /data| /var/lib/redis' # 确认数据目录落在哪块盘上存储信号读法
| 信号 | 含义 | 处置思路 |
|---|---|---|
| 单请求平均等待时间 | 写请求的平均等待 | 长尾上升通常来自存储侧 |
| 设备饱和度 | 磁盘繁忙程度 | 长期接近满载说明已到瓶颈 |
| 被推迟的刷盘次数 | 因重写等原因推迟的刷盘计数 | 持续增长说明刷盘被阻塞 |
| 最近一次日志写入状态 | 增量日志刷盘是否成功 | 出现错误需立即介入，否则持续报错 |
| 云盘突发额度 | 短时高并发能力 | 耗尽后延迟骤增，容量规划要按基准值 |
| 阵列写缓存策略 | 是否启用写回及是否有电池 | 无电池的写回策略在断电时可能丢数据 |
每秒刷盘是默认折中：最坏丢约 1 秒数据，延迟相对可控；每条命令都刷盘最安全但延迟最差；交给操作系统最省心但丢失窗口不可控。选型先看业务能接受多少数据丢失。
重写期间可以让主线程避让刷盘，代价是这段时间的数据安全窗口变大。是否开启按业务容忍度决定，关键链路建议保留刷盘而不是为了平滑延迟放弃落盘保证。
较新版本默认在增量日志文件开头写入一段二进制快照作为前导，直接打开文件看到乱码属于正常现象，不要误判为文件损坏；校验应使用官方提供的日志检查工具。