网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
深入底层三种写回策略,其实调用fsync()函数的时机不同:
- Always 策略就是每次写入 AOF 文件数据后,就执行 fsync() 函数;
- Everysec 策略就会创建一个异步任务来执行 fsync() 函数;
- No 策略就是永不执行 fsync() 函数;
AOF 重写机制
为了避免AOF文件越写越大,提供了AOF重写机制,当文件超过阀值就会启动AOF重写机制,来压缩文件,重写机制的妙处在于,尽管某个键值对被多条写命令反复修改,最终也只需要根据这个「键值对」当前的最新状态,然后用一条命令去记录键值对,代替之前记录这个键值对的多条命令,这样就减少了 AOF 文件中的命令数量。最后在重写工作完成后,将新的 AOF 文件覆盖现有的 AOF 文件。
AOF后台重写
AOF重写很耗时,所以,Redis 的重写 AOF 过程是由后台子进程 *bgrewriteaof* 来完成的,这么做可以达到两个好处:
- 子进程进行 AOF 重写期间,主进程可以继续处理命令请求,从而避免阻塞主进程;
- 子进程带有主进程的数据副本(数据副本怎么产生的后面会说),这里使用子进程而不是线程,因为如果是使用线程,多线程之间会共享内存,那么在修改共享内存数据的时候,需要通过加锁来保证数据的安全,而这样就会降低性能。而使用子进程,创建子进程时,父子进程是共享内存数据的,不过这个共享的内存只能以只读的方式,而当父子进程任意一方修改了该共享内存,就会发生「写时复制」,于是父子进程就有了独立的数据副本,就不用加锁来保证数据安全。
AOF优缺点
AOF(Append-Only File)持久化是 Redis 的一种持久化机制,它将所有的写操作追加到一个文件中,通过重新执行这些写操作来恢复数据。
AOF 持久化的优点包括:
- 数据完整性:AOF 持久化可以保证数据的完整性和持久性,每个写操作都会被追加到文件中,从而避免了数据丢失的风险。
- 灵活性:AOF 持久化采用追加写入的方式,因此可以在不中断服务的情况下进行持久化操作,提供了更好的灵活性。
- 可读性:AOF 文件是一个追加写入的日志文件,可以通过文本编辑器查看其中的写操作,方便进行故障排查和数据恢复。
- 高性能:AOF 持久化的写入性能通常比 RDB(Redis 数据库快照持久化)更高,尤其在写入频率较高的场景下。
AOF 持久化的缺点包括:
- 文件体积较大:AOF 文件相对于 RDB 文件通常会更大,因为它包含了所有的写操作。这可能会占用更多的磁盘空间。
- 恢复速度较慢:由于 AOF 持久化是通过重新执行写操作来恢复数据的,当 AOF 文件较大时,恢复过程可能比 RDB 持久化更慢。
- 可能存在数据冗余:由于 AOF 文件记录了所有的写操作,可能会导致一些数据操作的冗余,尤其是在写入频率较高的情况下。
需要根据具体的业务需求、数据安全性和性能要求来选择合适的持久化方式。可以采用 AOF 持久化来提供更好的数据完整性和灵活性,但也要注意管理 AOF 文件的大小和恢复速度。
使用命令
需要使用CONFIG命令来修改appendonly参数的值(Yes/No)
RDB
- AOF文件的内容是操作命令
- RDB文件的内容是二进制数据
Redis 提供了两个命令来生成 RDB 文件,分别是 save
和 bgsave
,他们的区别就在于是否在「主线程」里执行:
- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和执行操作命令在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
- 执行了 bgsave 命令,会创建一个子进程来生成 RDB 文件,这样可以避免主线程的阻塞;
Redis 的快照是全量快照,也就是说每次执行快照,都是把内存中的「所有数据」都记录到磁盘中。
Redis RDB(Redis Database)是一种快照持久化机制,用于将 Redis 的内存数据保存到磁盘上的二进制文件中。
RDB 持久化的工作原理
- Redis 通过fork一个子进程来执行持久化操作,父进程继续处理客户端请求。
- 子进程将当前的内存数据快照写入到临时文件中。
- 写入完成后,子进程将临时文件重命名为持久化文件(默认名为
dump.rdb
)。 - Redis 将旧的持久化文件(如果存在)替换为新的持久化文件。
执行快照时,数据能被修改吗
执行 bgsave 过程中,Redis 依然可以继续处理操作命令的,也就是数据是能被修改的,关键的技术就在于写时复制技术(Copy-On-Write, COW)。
RDB 持久化是通过将 Redis 的内存数据快照写入磁盘的方式来实现的。为了保证数据的一致性,Redis 在执行 RDB 快照时会使用子进程来处理持久化操作,而父进程继续处理客户端请求。在子进程执行 RDB 快照期间,父进程仍然可以处理客户端的写操作。这意味着,在执行 RDB 持久化期间,Redis 可能会接收到新的写操作,并且这些写操作会修改内存中的数据。然而,这些被修改的数据不会被立即写入到 RDB 文件中。子进程在完成 RDB 持久化后,会将当前内存中的数据快照写入到临时文件中,并将临时文件重命名为持久化文件。因此,在 RDB 快照执行期间,写操作对于持久化操作来说是不可见的。
RDB 持久化的优点
- 性能较高:RDB 持久化是通过将内存数据快照写入磁盘的方式来实现持久化,速度较快,适合大规模数据的备份和恢复。
- 文件体积较小:RDB 文件是二进制格式,相对于 AOF(Append-Only File)持久化产生的日志文件,文件体积较小,节省磁盘空间。
- 恢复速度较快:由于 RDB 文件是 Redis 数据的快照,恢复数据时只需加载 RDB 文件即可,速度较快。
RDB 持久化的缺点
- 可能会丢失数据:RDB 持久化是通过周期性地将内存数据快照写入磁盘来实现的,如果 Redis 在持久化之间发生崩溃,可能会丢失最后一次持久化后的数据。
- 不适合实时备份:RDB 持久化是通过在后台进行快照操作来实现的,不适合实时备份,因此在数据恢复时可能会丢失最新的数据。
需要根据具体的业务需求、数据安全性和性能要求来选择合适的持久化方式。可以使用 RDB 持久化来提供较高的性能和较小的文件体积,但需要注意定期执行持久化操作以避免数据丢失。
混合持久化
aof-use-rdb-preamble yes
混合持久化工作在AOF日志重写过程
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
(https://bbs.csdn.net/topics/618658159)**
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!