【Redis进阶】持久化

一、MySQL事务特性及Redis持久化需求

（一）MySQL事务特性

MySQL的事务具有四大核心特性，这些特性对于保证数据库操作的准确性和可靠性至关重要。

• ​​原子性​​：事务中的所有操作要么全部成功，要么全部失败，不会出现部分操作成功的情况。[+例如，在银行转账操作中，从一个账户扣款和向另一个账户加款这两个操作必须作为一个整体执行，要么都成功，要么都失败，以确保账户余额的正确性。
• ​​一致性​​：事务执行前后，数据库必须处于一致的状态，数据的完整性得到保证。[+比如，在电商系统中，用户下单后，库存数量应相应减少，订单状态应变为已支付，这些数据的变化必须保持一致。
• ​​持久性（持久化）​​：事务提交后，其结果是永久性的，即使系统崩溃也不会丢失。[+以电商平台的订单支付为例，一旦用户支付成功，该笔交易记录就会被永久保存，不会因为系统故障而丢失。]
• ​​隔离性​​：多个事务并发执行时，相互之间不干扰，保证数据的独立性。[+例如，在电商系统中，多个用户同时下单购买同一件商品，系统应能正确处理这些并发事务，确保每个用户的订单都能正确生成，不会出现数据混乱的情况。

（二）Redis持久化需求

MySQL的数据存储在硬盘中，天然支持持久化。而Redis的数据存储在内存中，这就需要特殊的持久化策略来实现数据的持久化存储。

​​解决方法​​：当数据存储到内存时，复制一份同时存到硬盘中。当进程/主机重启时，从硬盘中读取数据写入内存中，这样就实现了数据的持久化存储。理论上来说，内存与硬盘中的数据是完全相等的，但有部分差异，这取决于不同的持久化策略。

​​代价​​：付出了额外的空间。不过硬盘资源比较划算，并不会增加很多的成本。

二、Redis持久化策略

（一）RDB（Redis DataBase）

1. 手动触发RDB快照

• ​​save命令​​：执行save命令时，Redis会全力以赴地进行快照操作，期间会阻塞其他Redis操作。这种方式的优点是简单直接，适用于对数据一致性要求极高，且可以接受短暂阻塞的场景。例如，在进行重要数据的备份时，可以使用save命令确保数据的完整性。
• ​​bgsave命令​​：bgsave命令会在后台异步执行快照操作，不会影响Redis服务器处理其他客户端的请求和操作。[+它通过fork系统调用创建子进程来实现持久化，利用“写时拷贝”技术减少内存消耗。当Redis服务器中存储的数据量较大时，使用bgsave命令可以避免阻塞其他操作，提高系统的性能和可用性。

2. 自动触发RDB快照

• 可以通过修改Redis配置文件来设置自动触发的条件，如在指定时间内达到一定数量的写操作。例如，可以设置在1分钟内如果有超过1000次写操作，则自动触发RDB快照。这样可以定期对数据进行备份，确保数据的安全性。
• 执行shutdown命令时，Redis会在关闭前自动执行快照操作（正常关闭）。这样可以在服务器关闭时，确保最新的数据被保存下来，避免数据丢失。
• 在主从节点复制时，主节点会自动触发快照操作，将快照文件内容传输给从节点。这样可以保证主从节点之间的数据一致性，使得从节点能够及时获取到最新的数据。

3. RDB文件相关操作与查看

• ​​bgsave流程​​：

  • 创建子进程进行持久化操作，生成快照到一个新文件，并替换原来的旧文件。
  • 如果使用save操作，则在同一个进程中往同一个文件中写入。

• ​​查看快照更新​​：如果仅查看文件内容可能无法判断是否更新，此时可通过stat （快照文件名）命令查看快照文件的inode编号来确定文件是否不同。inode编号是文件系统中用于标识文件的唯一编号，当文件内容发生变化时，inode编号通常也会改变。因此，通过比较inode编号可以快速判断文件是否被更新。

• ​​Linux文件系统区域划分​​：

  区域	描述
  超级块	存储文件系统的元信息
  inode 区	存储文件的元数据
  block 区	存储文件的数据内容

4. RDB优缺点

RDB的优点是生成的文件紧凑，适合备份和灾难恢复；缺点是可能会丢失最近一次快照以来的数据。例如，如果在12：00进行了RDB快照操作，而在12：01服务器重启，那么在这1分钟内产生的数据将会丢失。

（二）AOF（Append Only File）

1. AOF开启与RDB失效

AOF在默认情况下是关闭的，需要在配置文件中打开。打开后，RDB将不生效，Redis重启时会从aof文件中读取数据到内存中。

2. AOF写入机制与性能影响

• AOF每次操作都以文本形式记录，细节由特殊分隔符分开。
• 引入AOF后，虽增加硬盘操作，但通过缓冲区和顺序写入优化性能。AOF采用顺序写入的方式，相比随机写入，可以大大提高写入性能。同时，通过缓冲区的设计，可以减少对硬盘的直接写入次数，进一步提高系统的性能。

3. AOF刷新策略

• ​​always配置​​：每次写操作都同步到硬盘，数据最安全但性能最低。在这种配置下，每次写操作都会立即写入硬盘，确保数据的实时性和安全性。但是，由于频繁的磁盘I/O操作，会对系统性能产生较大的影响。
• ​​everysec配置​​：每秒同步一次，兼顾性能和数据安全。[+这种配置方式在性能和数据安全之间取得了平衡。每秒将缓冲区中的数据写入硬盘一次，既可以保证数据的及时性，又不会对系统性能造成过大的影响。
• ​​no配置​​：由操作系统决定何时同步，性能最高但数据安全性最低。在这种配置下，Redis会将写操作先缓存在内存中，由操作系统决定何时将数据写入硬盘。这种方式可以提高系统的性能，但是在系统崩溃或断电等情况下，可能会导致数据丢失。

4. AOF文件瘦身机制

• ​​手动触发重写​​：程序员可手动执行重写操作。例如，当发现AOF文件过大时，可以通过手动触发重写来减小文件大小。
• ​​被动触发重写​​：当aof文件达到一定大小时自动触发。例如，可以设置在AOF文件大小超过1GB时，自动触发重写操作。这样可以避免AOF文件过大导致的性能问题。
• ​​重写流程​​：
  • 父进程fork子进程，子进程负责写入新aof文件。
  • 父进程继续接收请求，写入两个缓冲区，一个用于旧aof文件，另一个用于新aof文件。
  • 新aof文件完成后替换旧文件。