redis作为当下web编程必不可少的服务，它的特点的是显而易见，相对memcached而言，做缓存，重启数据不丢失，非常好用。那么问题来了，它是怎么做到的呢？
RDB
RDB就是持久化的一种手段，把内存中数据在某些条件下写到磁盘中去。那么在哪些条件下写入呢？不可能无脑写入，来一个写一个，影响性能，也不能等老半天才写一个，万一中间宕机了，数据全丢失，还不如用memcached。在redis的配置里有着这样的一段配置：
save 900 1
save 300 10
save 60 10000
很关键的一段配置，这时RDB持久化的核心。意思是：
1.如果900秒时，有1个key变化（插入或者更新），我就同步到磁盘一下
2.如果300秒时，有10个key变化（插入或者更新），我就同步到磁盘一下
3.如果60秒时，有10000个key变化（插入或者更新），我就同步到磁盘一下
这些时间点和变化的数量是怎么知道的，这时有另外两个极为关键的东西，一个叫dirty计数器，一个叫lastsave（上次save的时间），dirty计数器专门记录从上次save后变化key的数量，lastsave记录执行save的时间，举个例子刚开始时间是time1，dirty是0，这时有20个key发生了变化，dirty是20，然后现在的时间是time2，time2-time1 >= 300,满足第二个条件，这时内存中的数据会save一下，同时dirty清为0，然后再等待条件触发。
如果我60秒内有10万个key，那么问题来了，一下大量磁盘io来临，这时redis主进程就会阻塞，期间的所有的命令都不执行，这哪能行，于是就来了一个叫bgsave的，它是redis主进程fork出来的一个子进程，专门执行rdb的持久化工作的。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
保存的文件格式是二进制格式的，万一数据库宕机，恢复不需要人为干预，redis会自动读取磁盘文件。
AOF
与RDB不同，AOF存储的是你执行的命令，当aof功能打开的时候，执行的更新命令不会直接写到aof文件中去，而是先写到一个aof buf中，我们知道不能一直往buf中写，buf也是内存啊，那么何时才能同步到磁盘中去呢？redis中也有这样一段配置
appendfsync always
appendfsync everysec
appendfsync no
意思是：
1.只要有更新的命令我就同步
2.如果上次同步时间距离现在超过一秒就同步
3.不同步，等待操作系统自己判断（什么时候我有空我才同步）
分析下，第一种io频繁，io压力大，但丢失数据的概率最小，第二种io压力不是很大，最多也就丢失1秒左右的数据，第三中io压力很小，丢失数据概率太大。综合考虑，一般第二种。但还有个问题，我执行了100次INCR num，按道理num就是100，aof中也有100个同样的命令，没毛病，那么请问执行100次INCR num和SET num 100有什么区别，同样的结果前者多了99倍的空间，很浪费啊，于是就出现了AOF重写，它是怎么做到的。很简单：首先从数据库读取现在的值，然后用一条记录代替，这就是AOF重写的原理。重写很花时间，所以也是子进程来处理。重写的过程中，如果有新的命令来临怎么办，老办法，写buf缓冲，重写完成后，把buf中的命令追加到新的aof中，然后用新的aof替代老的aof，就实现了重写。
本文来自redis教程，欢迎学习。
