rdb与aof需权衡数据可靠性、恢复速度和磁盘压力；默认仅开rdb易致数据丢失。应在redis.conf中同时启用：appendonly yes开启aof，保留save配置（如save 900 1）维持rdb，并注意aof优先加载、文件路径与磁盘空间。
RDB 和 AOF 不是“选一个就行”，而是要根据数据可靠性、恢复速度、磁盘压力这三点来权衡；默认只开 RDB 是最常见也最容易出问题的配置起点。
如何在 redis.conf 中同时启用 RDB 和 AOF
Redis 允许两者共存，但启动时优先加载 AOF —— 这意味着只要 aof_enabled 为 yes，哪怕 rdb_enabled 也开着，redis-server 启动时也会先尝试载入 appendonly.aof。
- 打开 AOF：设置
appendonly yes（默认是no） - 保留 RDB：确保
save配置项未被注释，例如save 900 1（900 秒内至少 1 次修改就触发快照） - AOF 文件名由
appendfilename控制，默认是"appendonly.aof"，别和dbfilename（默认"dump.rdb"）冲突 - 如果改过
dir路径，两个文件都会写到该目录下，注意磁盘空间是否够用
RDB 快照丢失数据的典型场景与规避方式
RDB 的本质是定时 fork 子进程做内存快照，两次快照之间的写操作全靠运气 —— 如果刚好在 save 300 10 触发前宕机，最多丢 5 分钟 + 最近 10 条变更。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 高频写入场景（如秒杀计数器）下，
save配置必须压得更紧，比如save 60 1000（1 分钟内 1000 次修改就快照） - 但要注意：
fork开销随内存增长而陡增，实例占用 10GB 内存时，fork可能卡主进程 100ms+，影响 P99 延迟 - 不要依赖单次 RDB 做灾备 —— 它适合离线备份（比如每天凌晨 cp 一份到对象存储），不适合实时故障恢复
AOF 的 fsync 策略直接影响数据安全与性能
appendfsync 有三个可选值：always、everysec、no。它不控制“是否写日志”，而是控制“何时刷盘”。
-
always：每个写命令后都调fsync()→ 数据最安全，但磁盘 IOPS 会爆表，QPS 明显下降 -
everysec（默认）：写入 OS 缓冲区后返回，后台每秒刷一次盘 → 平衡点，宕机最多丢 1 秒数据 -
no：完全交由 OS 决定 → 性能最好，但崩溃可能丢几十秒数据，不建议生产环境用 - 注意：
bgrewriteaof重写期间，新命令仍会追加到旧 AOF 文件末尾，重写完成才原子替换 —— 所以即使重写卡住，也不影响数据写入
为什么 AOF 文件比 RDB 大、恢复却更慢
AOF 记录的是原始命令（如 INCR counter、LPUSH list a b c），而 RDB 是二进制内存镜像。这意味着：
- 同样一个 list 推入 10 万条数据，AOF 文件里就是 10 万行命令；RDB 就是一段紧凑的序列化结构
- 恢复时 AOF 要逐条解析并执行命令，相当于重放整个写历史；RDB 直接 mmap 加载进内存
- 虽然
bgrewriteaof会压缩冗余操作（比如多次SET同个 key 只留最后一条），但无法消除命令级语义带来的体积膨胀 - 所以线上大流量 Redis 实例，AOF 文件动辄几个 GB，首次加载可能需要几分钟 —— 这期间 Redis 不可服务
真正难处理的不是“怎么配”，而是当实例内存达 20GB+、QPS 过万时，RDB 的 fork 暂停和 AOF 的重写竞争会同时出现，此时必须结合 auto-aof-rewrite-percentage 与 auto-aof-rewrite-min-size 做精细调控，否则容易陷入“刚重写完又触发重写”的循环。
