如有侵权，请联系～
如有错误，也欢迎批评指正～
本篇文章大部分是来自学习《Redis实战》的笔记

1、持久化

redis提供了两种方式进行持久化到磁盘。一种是快照【RDB】：他可以将某一时刻的所有数据都保存到磁盘中；另一种是只追加文件【AOF】：把写命令保存到磁盘中。这两种持久化方式可以单独使用某一种，也可以同时使用。

1.1 快照持久化

redis可以通过创建快照获取内存中某一时刻的数据副本，可以对快照进行备份存储到磁盘或者将备份复制到其他的服务器上从而创建一样的数据。但是在新的快照文件创建保存完之前，只有redis、操作系统或者硬件有一个崩溃，那么最近的快照之后的数据将会丢失。

创建快照的方式：

• 客户端向redis服务端发起bgsave命令。redis服务端会fork一个子进程负责将快照写入磁盘，父进程则继续处理命令
• 客户端向redis服务端发起save命令。redis服务端在快照没有创建完之前不会执行其他的请求。这种方式不常用，只有内存不足的情况下或者阻塞等待持久化也没事的情况
• 用户设置了save配置选项。例如 save 60 1000，60秒内有1000次写入的条件满足之后，redis就会自动触发bgsave命令
• redis收到shutdown命令关闭服务器的请求时，会执行save命令，阻塞所有客户端，save命令执行完毕之后就会关闭服务器
• 当一个redis服务器连接另一个redis服务器，通过向对方发送sync命令进行复制的时候，如果主服务器没有正在或者刚执行完的bgsave操作，主服务器就会执行bgsave命令

基于上述说的rdb会存在最近一次数据丢失的问题，因此，rdb这种方式不适用于那种不能接受数据丢失的应用，只适合丢失一部分数据也不会造成问题。

redis的rdb文件每次写入都会把之前的rdb从磁盘中删除么？

会的。RDB持久化过程中关于文件写入的大致流程：

1. 创建临时文件：当触发RDB快照保存操作时，Redis不会直接覆盖现有的RDB文件，而是首先创建一个临时文件来存储新的数据库快照。这个临时文件通常命名为类似于dump.rdb.tmp。
2. 数据写入临时文件：Redis会将当前内存中的所有数据序列化并写入到上述提到的临时文件中。这一步确保了即使在写入过程中出现错误或中断，原有的RDB文件也不会被破坏或丢失。
3. 替换旧文件：一旦所有的数据都被成功写入临时文件并且文件关闭后，Redis才会尝试用这个新生成的临时文件去替换原来的RDB文件。这种替换通常是通过操作系统级别的重命名操作完成的，这样可以保证原子性，即要么完全更新为新版本，要么保持不变。
4. 清理工作：如果替换过程顺利完成，则原有的RDB文件会被移除；而如果由于某些原因导致替换失败（例如权限问题），那么临时文件会被保留下来，但原始的RDB文件仍然可用，从而确保了数据的安全性和一致性。

1.2 AOF持久化

AOF持久化就是将写命令追加到AOF文件的末尾，Redis到时候只需要重放一次AOF的命令即可恢复所有数据。针对于持久化的频率，可以通过appendfsync选项配置进行设置。如下是appendfsync的值：

选项	同步频率
always	redis的每个写入命令都会同步的写入到磁盘，这样会严重降低redis的速度， 增加磁盘的写入频率从而降低磁盘的寿命
everysec	每秒同步一次，显示的将多个写命令同步到磁盘。综合性能和数据安全，推荐使用
no	同步的时机完全交给操作系统来控制

1.3 重写/压缩AOF文件

Redis的AOF持久化有很多优点：可以将持久化的窗口降低到1秒，并且持久化的时间短。但是缺点也很明显：虽然redis不断运行，写入命令越来越多，导致aof文件不断增加，占用空间大；当机器重启或者增加从节点进行还原数据集也会很慢。

为了解决这个问题，redis提供了bgwriteaof命令。这个命令会通过移除 AOF 文件中的冗余命令来重写(rewrite )AOF文件，使 AOF文件的体积变得尽可能地小。Redis会创建一个子进程，然后由子进程负责对AOF文件进行重写。可以通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size两个选项进行控制压缩重写AOF文件的频率。

可以参考文献：redis相关问题

除了持久化到磁盘以外，对持久化的文件进行备份也是有必要的，例如备份到不同的服务器上。

2、复制

复制可以让其他服务器拥有一个不断地更新的数据副本，从而使得拥有数据副本的服务器可以用于处理客户端发送的读请求。

在从服务器上配置slaveof host port，redis服务器就可以根据IP和端口号连接主服务器。

2.1 Redis复制的启动过程

从服务器连接主服务器的步骤：

在进行主从复制的时候，主服务器仍然对外提供服务，处理请求命令。如果服务器的内存不足创建子进程或者缓冲区，或者带宽不足，可能会影响请求的效率。一般主服务器的内存只使用50%～65%，留30%～45%的内存用作创建子进程和缓存区。

如果有多个从服务器连接同一个主服务器的时候：

• 前一个从服务器第三步还没执行完，则这个服务器也会使用同一个rdb文件和缓冲区
• 如果前一个已经执行完第五步，那么这个新连接就从第一步开始

大部分情况，我们期望尽可能减少Redis复制所需要的工作，尽可能同时。但是如果同步多个服务器可能会占用大量的带宽，从而影响主服务器接受请求命令。

哨兵模式：在切换主服务器的时候也会涉及到复制问题。

2.2 主从链

创建多个从服务器可能会造成网络不可用，原因如上带宽问题，因此诞生了主从链。从服务器对从服务器进行复制在操作上和从服务器对主服务器进行复制的唯一区别在于：如果从服务器X拥有从服务器Y，那么当从服务器X在执行步骤4时，它将断开与从服务器Y的连接，导致从服务器Y需要重新连接并重新同步(resync)。

当读请求的重要性明显高于写请求的重要性，并且读请求的数量远远超出一台Redis 服务器 可以处理的范围时，用户就需要添加新的从服务器来处理读请求。随着负载不断上升，主服务器 可能会无法快速地更新所有从服务器，或者因为重新连接和重新同步从服务器而导致系统超载。 为了缓解这个问题，用户可以创建一个由Redis 主从节点(master/slavenode)组成的中间层来分担主服务器的复 制工作：

3、处理系统故障

3.1 验证快照文件和AOF文件

无论是快照持久化还是AOF持久化，都提供了在遇到系统故障时进行数据恢复的工具。Redis提供了两个命令行程序redis-check-aof和redis-check-dump，它们可以在系统故障发生之后，检查AOF文件和快照文件的状态，并在有需要的情况下对文件进行修复。

程序修复AOF文件的方法非常简单:它会扫描给定的AOF文件，寻找不正确或者不完整的命令，当发现第一个出错命令的时候，程序会删除出错的命令以及位于出错命令之后的所有命令，只保留那些位于出错命令之前的正确命令。在大多数情况下，被删除的都是AOF文件末尾的不完整的写命令。

目前并没有办法可以修复出错的快照文件。尽管发现快照文件首个出现错误的地方是有可能的，但因为快照文件本身经过了压缩，而出现在快照文件中间的错误有可能会导致快照文件的剩余部分无法被读取。

4、事务

Redis的事务以特定的命令MULTI为开始，之后跟着多个命令，最后以EXEC命令结束。
事务示例：

WATCH key1
MULTI
SET key1 newValue
SET key2 newValue
EXEC

以下是这些命令的简要说明：

1. MULTI 命令
   MULTI 命令用于标记一个事务块的开始。在执行了 MULTI 命令之后，所有的 Redis 命令都会被记录到一个待执行的队列中，但不会立即执行，而是等待 EXEC 命令的执行。

2. EXEC 命令
   EXEC 命令用于执行所有之前通过 MULTI 命令放入队列中的命令。如果事务中的所有命令都被正确执行，那么 EXEC 命令会返回一个数组，包含了所有命令的返回值。如果事务在执行过程中遇到错误（例如语法错误），则整个事务会被放弃，之前的命令都不会被执行。

3. DISCARD 命令
   DISCARD 命令用于取消一个事务，它清空之前通过 MULTI 命令放入队列中的所有命令。如果在一个事务已经开始但还没有调用 EXEC 或 DISCARD 的情况下发生错误，可以调用 DISCARD 来放弃事务。

4. WATCH 命令
   WATCH 命令是一个乐观锁，用于在事务执行前监视一个或多个键。如果在 EXEC 执行时，被监视的键至少有一个已经被其他客户端改变，则整个事务不会执行，EXEC 命令将返回 nil 表示事务失败。这通常用于在并发环境下保证数据的一致性。

4.1 java中的redis事务使用

import redis.clients.jedis.Jedis;
import redis.clients.jedis.Transaction;public class RedisOptimisticLockExample {public static void main(String[] args) {try (Jedis jedis = new Jedis("localhost", 6379)) {String key = "balance";int valueToAdd = 10;// 监视键"balance"jedis.watch(key);int currentBalance = Integer.parseInt(jedis.get(key));if (currentBalance < 100) {// 开启事务Transaction transaction = jedis.multi();transaction.incrBy(key, valueToAdd);// 提交事务if (transaction.exec() != null) {System.out.println("事务执行成功，余额增加了：" + valueToAdd);} else {System.out.println("事务执行失败，可能是监视的键发生了变化。");}} else {System.out.println("当前余额已足够，无需增加。");}// 取消监视键jedis.unwatch();} catch (Exception e) {e.printStackTrace();}}
}