Redis学习笔记

持久机制

rdb快照(snapshot)：默认情况下，redis将快照保存在名字为dump.rdb的二进制文件中，可以配置在"N秒有M个改动"自动保存一次，比如说 :save 60 100 意思就是在60秒内，至少有100个修改，就回执行一次保存。rdb快照还可以手动执行save或者bgsave命令来手动保存。此命令会将redis当前内中中的数据快照保存至一个新的rbd文件，并覆盖原有的快照文件。

aof(append-only file):会将每条修改命令保存至appendonly.aof文件中，此功能不会默认开启，需要配置 appendonly yes来打开此功能，备份机制有三个选项分别是

appendfsync always ：每次有新命令追加到 AOF 文件时就执行一次 fsync ，非常慢，也非常安全。

appendfsync everysec ：每秒 fsync 一次，足够快，并且在故障时只会丢失 1 秒钟的数据。

appendfsync no ：从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择。

       推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

 

 

RDB和AOF对比

命令	RDB	AOF
启动优先级	低	高
体积	大	小
恢复速度	快	慢
数据安全性	容易丢数据	根据策略决定

在Redis4.0后推出了 混合持久化通过 aof‐use‐rdb‐preamble yes 此配置来开启(必须要先开启aof)。 AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将 重写 这一刻之前的内存做RDB快照处理，并且将RDB快照内容和 增量的AOF修改内存数据的命令存在一 起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改 名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

 

 

Redis主从原理

salve连接上master后，会发送一个PSYNC命令给master请求复制数据。master收到PSYNC命令后会执行gbsave生成一份快照发给savle(在生成快照这个期间，会有一个 replication buffer来存储新来的命令，master将快照发送完成给savle后，会将这个buffer的数据也发给savle)。后面就是一直长连接，将master执行的命令发一份给savle。                                                                                                              

 

部分数据复制恢复机制(也就是savle宕机后的恢复机制)

当savle从新连接到master后，savles发送PSYNC的同事会带上一个偏移量offset，如果master节点能从自己的 replication buffer中能定位到这个偏移量则会将这个偏移量的后面的数据同步给savles，如果找不到则会全量复制。  

主从风暴

多个从节点同时复制主节点导致主节点压力过大。

解决方案：让部分从节点与从节点(与主节点同步)同步数据

 

Redis集群原理

redis将所有的数据划分为16384个槽位(slots)，每个节点都负责一部分，槽位信息存储在节点中，当有客户端来连接redis时，会先拿取一份槽位信息缓存起来，这样当要查找某个key时，会在客户端进行一次 槽位定位算法来算出所在的槽位，定位到具体是属于哪个节点。

槽位定位算法：使用CRC16算出一个整数，然后取模(也就是取余[16384])

 

Redis集群选举原理

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master 可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1.savle发现自己的master状态为FAIL

2.将自己记录的集群currentEpoch加1(类似一个版本号)，并广播FAILOVER_AUTH_REQUEST 信息

3.其他master节点收到该信息，会判断这个请求是否合法，如果合法会发送FAILOVER_AUTH_ACK(这里只会回复一次)

4.收集其他master节点返回FAILOVER_AUTH_ACK的数量

5.slave收到 超过半数master的ack 后变成新Master(这里解释了集群为什么至少需要三个主节点），如果每个savle收到的ack相同，则重新执行一遍流程，直到选举成功

6.选举成功后，广播自己当前节点的元信息

从节点发现主节点FAIL后，并不是马上就选举的，而是有一段延时。(这样做是防止其他savle还未发现master已经FAIL了)

 

 

延迟计算公式(各版本可能会有差异)：

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方 式下，持有最新数据的slave将会首先发起选举（理论上）。

 

脑裂导致数据丢失问题

 

master收到新的数据后，还未及时同步给savle节点，导致丢失数据。

解决方式： min ‐ replicas ‐ to ‐ write 1    // 写数据成功最少同步的 slave 数量，这个数量可以模仿大于半数机制配置，比如 集群总共三个节点可以配置 1 ，加上 leader 就是 2 ，超过了半数

注意：此配置可能会影响可用性，比如savle要是少于一个，就算master没宕机，可能也会影响使用