redis数据持久化机制
文章目录
- redis数据持久化方式
-
- 1.为什么要引入持久化机制
- 2.redis持久化机制
-
- 1.RDB快照:
-
- 1.优点:
- 2.缺点:
- 2.AOF日志方式:
-
- 1.优点:
- 2.缺点
- 3.aof的实现过程
- AOF日志潜在的问题
-
- aof的三种写回策略
- aof重写
- 重写会不会阻塞主线程？
- Redis单线程
- Redis单线程
redis数据持久化方式
1.为什么要引入持久化机制
因为redis是基于内存操作的，数据都是存储在内存上，一旦redis或者服务器发生故障，那么redis的数据库就会丢失
所以redis提供了两种持久化方式，将数据持久化内存上。
2.redis持久化机制
1.RDB快照:
redis会周期性的将内存的数据转化为二进制压缩文件,保存到磁盘上的RDB文件上
1.优点:
-
存储的是二进制压缩文件,相对来说占用内存较少
-
用于恢复大数据时较快,因为他是全量的数据快照
-
适用于数据备份和灾难恢复
2.缺点:
- 可能会造成每个时间节点后的数据全部丢失
- 保存快照时是阻塞式的,可能会对服务器性能造成影响
2.AOF日志方式:
在执行redis命令后使用追加的方式写入AOF文件,只需要下次启动时执行aof日志文件就可以重建数据库再内存中的状态
1.优点:
-
AOF可以更加精确的进行数据持久化,每个写操作都会被记录
-
AOF使用与实时的数据恢复
2.缺点
AOF对比RDB可能会占用更大的内存,因为他记录的每个写操作的文本文件
AOF在回复大量的数据时会比较慢,因为需要逐条操作
3.aof的实现过程
aof是写后日志,先执行redis命令,把数据写入内存,让后才记录日志
原因:如果redis命令执行失败而已经写入了,这样就会造成数据不统一,如果写写入还可能造成服务器阻塞
但是后写入的话如果在写入前就崩溃,那么依旧会出现数据不一致问题.
AOF日志潜在的问题
AOF（Append-Only File）写日志是Redis的持久化机制之一，它记录了每个写操作命令，以追加的方式将命令写入AOF文件。尽管AOF具有许多优点，但也存在一些风险和潜在的问题，需要注意和管理：
1. 磁盘IO开销： AOF日志以追加写入方式工作，每次写入操作都会直接追加到AOF文件末尾。这意味着频繁的写入操作可能会导致磁盘IO开销增加，可能会影响系统的性能和响应时间。
2. 磁盘空间占用： AOF日志记录的是每个写操作命令本身，相比于RDB快照，AOF文件可能会更大。如果写入操作频繁，AOF文件可能会不断增大，占用过多的磁盘空间。
3. 数据一致性： 尽管AOF的先执行命令再记录日志的机制保证了数据一致性，但如果在记录日志前发生服务器崩溃，尚未记录的操作可能会丢失，可能导致数据一致性问题。
4. AOF文件损坏： 由于AOF文件是以文本格式记录的命令，如果AOF文件在写入或存储过程中受到损坏，可能导致数据恢复时出现问题，甚至无法正确恢复数据。
5. AOF重写耗时： AOF重写是为了减小AOF文件的大小，但它是一个耗时的操作，可能会对系统性能产生影响，尤其是在大数据集的情况下。
6. AOF重写可能引发的问题： AOF重写过程中可能会因为各种原因导致数据丢失，例如中断的重写过程、文件系统问题等。在执行AOF重写时，需要谨慎对待，确保数据的完整性。
7. AOF文件合并： 在一些场景下，可能需要将多个AOF文件合并成一个，这样的操作需要小心处理，以避免数据丢失或错误。
8. 硬件故障： 虽然AOF可以提供持久性保证，但硬件故障（例如磁盘故障）可能会导致AOF文件丢失或损坏，需要适当的备份和恢复策略。
为了减轻AOF写日志带来的风险，可以采取一些措施，如选择适当的AOF同步策略、定期备份AOF文件、监控AOF文件的大小和状态、定期执行AOF重写、备份数据等。这些策略可以帮助减少潜在的问题，并提高系统的可靠性。
aof的三种写回策略
1. always（始终同步）： 在这个策略下，每次执行写入操作之后，Redis都会立即将写入操作刷新到磁盘，确保写入操作已经持久化。虽然这种方式能够提供最高的数据保证，但也是性能开销最大的一种方式，因为每次写入操作都会引起磁盘IO。
优点：
- 最高的数据保证，即使系统崩溃，也只会丢失上一个写入操作。
缺点：
- 性能开销较大，频繁的磁盘IO可能影响系统的性能和响应时间。
2. everysec（每秒同步）： 在这个策略下，Redis会每秒一次将AOF缓冲区中的写入操作批量刷新到磁盘上的AOF文件。这样可以在一定程度上平衡数据保证和性能。
优点：
- 较高的数据保证，每秒一次的同步保证了不会丢失过多的写入操作。
- 性能开销相对较低，因为是每秒一次的批量刷新。
缺点：
- 在一秒内的操作可能会丢失。
3. no（不同步）： 这个策略下，Redis不会主动将AOF缓冲区中的写入操作刷新到磁盘，而是由操作系统来决定何时将数据写入磁盘。这是性能开销最小的方式，但数据持久性相对较低。
优点：
- 最小的性能开销，几乎不会影响系统的响应时间。
- 最高的性能表现，写入操作不会导致频繁的磁盘IO。
缺点：
- 数据持久性较低，如果系统崩溃，可能会丢失多个写入操作。
aof重写
AOF（Append-Only File）重写是为了减小AOF文件的大小，避免AOF文件不断增大导致的磁盘空间占用问题。AOF重写是一种以全量的方式生成新的AOF文件，其中记录的是一个数据集的写入操作，这个数据集的大小通常比原始AOF文件小很多
-
触发重写： AOF重写可以手动触发，也可以根据配置自动触发。当满足一定条件（例如AOF文件大小超过指定百分比或最小大小）时，Redis会启动AOF重写过程。
-
后台进程启动： 当AOF重写触发时，Redis会启动一个子进程，这个子进程会负责执行AOF重写操作。
-
创建数据集快照： 在子进程中，Redis会创建一个数据集的内存快照，即内存中数据在某个时间点的快照。
-
遍历数据集： 子进程开始遍历数据集中的键，并将写操作转换成命令序列。
-
生成新AOF文件： 子进程会将遍历期间生成的命令序列追加到新的AOF文件中，这个新文件是紧凑的，只包含了数据集在某个时间点的写入操作。
-
替换原AOF文件： 当新的AOF文件生成完成后，子进程会将原始的AOF文件替换为新的AOF文件。这一步通常很快，因为新的AOF文件相对较小。
-
主线程继续服务： 在AOF重写过程中，主线程仍然可以继续处理客户端请求，响应读取操作等，不会被阻塞。
重写的aof文件对比
[]:
[]:
重写会不会阻塞主线程？
AOF重写不会阻塞Redis的主线程。Redis的AOF重写是作为一个后台进程（子进程）来执行的，不会影响主要的服务线程。
AOF重写过程中，Redis会创建一个子进程来遍历数据集，将写操作转换为命令序列，并生成新的AOF文件。主线程仍然可以继续处理客户端请求，响应读取操作等。
这种设计使得Redis能够在不中断服务的情况下执行AOF重写，从而减少对系统的影响。但需要注意的是，虽然AOF重写不会阻塞主线程，但它仍然是一个资源密集型操作，可能会占用较多的CPU和内存资源，因此在进行AOF重写时，需要考虑系统的资源情况，避免影响其他业务操作。
Redis单线程
Redis能够在不中断服务的情况下执行AOF重写，从而减少对系统的影响。但需要注意的是，虽然AOF重写不会阻塞主线程，但它仍然是一个资源密集型操作，可能会占用较多的CPU和内存资源，因此在进行AOF重写时，需要考虑系统的资源情况，避免影响其他业务操作。
Redis单线程
redis单线程,但是这些都是需要同时执行,redis使用了多进程,子进程专门为了做这些活动.