超详细redis知识点归纳

概念：以日志形式记录每一次对redis的写命令，可以通过重复执行记录的命令来进行数据恢复

AOF的重写机制：AOF提供了重写机制，去除无用指令以及合并多条指令达到压缩的目的。
更小的文件也意味着更快的加载速度。重写机制不会阻塞redis

缺点:
1.AOF文件记录的更详尽，意味着文件占用空间更大
2.AOF数据恢复的速度相对于RDB更慢
3.有一个罕见的BUG导致数据无法完全一致的恢复，但是暂未在实际使用中发现

优点
1.AOF默认一秒钟执行一次fsync操作，即使发生故障，最多也只是丢失那没来得及写入日志的一秒钟的命令数据
2.AOF对误操作有更强的容错性，由于AOF是逐条命令的记录，因此当发生灾难性的数据误操作时（比如清库），只要这个时候AOF还没被重写（重写机制），先把redis停掉，然后把AOF文件拷贝出来，将最后的误操命令（比如清库的FLUSHALL）删除，然后用修改后的AOF做数据恢复即可。

概念：生成某个时刻的redis数据快照，直接加载快照进行数据恢复

优点
1.数据恢复数据相对AOF更快

缺点
1.因为是某个时刻的快照，在这个时刻和下一个备份点之间插入的数据会丢失。不适用于对数据丢失敏感的场景。
2.RDB需要经常fork()创建子进程来保存快照，创建的过程是阻塞的重量级的操作。如果数据量过大，会造成redis有短暂的无响应状态。

复制ID：master节点的数据集的I一个随机字符串ID，标记了某个master节点的数据集.当一个master节点重启或者一个slave节点升级为master节点时，会重新生成新的复制ID

偏移量：理解成数据的版本号。每次写数据，偏移量都会递增。偏移量一致，则表示数据同步一致。

全量复制：顾名思义，使用RDB做master的完全拷贝。一般发生在新slave节点启动或旧slave节点重连且无法满足增量复制条件的时候

增量复制：master向slave发送每一次写操作的命令，是主从复制优先尝试的方式

全量复制的过程
1.master节点执行BGSAVE命令fork()子进程，生成RDB快照。同时在缓存新进来的写命令
2.master将快照发送给slave
3.slave收到RDB加载并刷新数据
4.master将缓存的新命令以命令流的形式发送给slave完成数据的完全同步

积压区缓存的判断过程
（1）主从分别维护一个seq，主每次完成一个请求便seq+1，从每同步完后更新自己seq；
（2）从每次打算同步时都是携带着自己的seq到主，主将自身的seq与从做差结果与积压缓冲区大小比较，如果小于积压缓冲区大小，直接从积压缓冲区取相应的操作进行部分重同步；
（3）否则说明积压缓冲区不能够cover掉主从不一致的数据，进行全量同步。

How Redis replication works
Replication ID explained

redis主从复制原理

概念：最简单的模式，一个集群中有且只有一个主节点，主节点可读写，从节点只读。主节点下线，影响写服务，不影响读服务。

数据同步机制：当slave启动后，主动向master发送SYNC命令。master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。slave接收到快照文件和命令后加载快照文件和缓存的执行命令。复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

缺陷：master挂掉后不能对外提供写服务（salve不会自动升级为master）。因此主从模式，只提供了读写分离的特性，不满足高可用

自动故障切换机制：
1.当一个master被大多数sentinel标记为主观下线时，这个master从主观下线标记变为客观下线标记，failover故障切换机制会被触发
2.投票产生领头sentinel:每个发现master客观下线的sentinel都会要求其他sentinel将自己选为领头，去执行故障迁移；投票采用先到先得策略，已经给某个候选人投过票的sentinel，不再接受其他候选人的投票请求
3.选举Slave升级为master:在淘汰已线下、超时、响应慢的slave节点后，领头sentinel先后根据节点的优先级、复制偏移量(标记了slave复制了多少master数据)、进程id选择最优的Slave成为新的master，将原master和其下的slave全部归为新master的slave
4.更新节点配置信息

概念：基于主从模式，多了哨兵的角色。Sentinel由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。

缺陷：（其实是单master的缺陷）
1.每个节点保存的数据都一样，存在冗余，造成内存浪费。
2.因为每个节点保存的数据都一样，master的最大存储容量决定了整个集群的容量，上限有限
3.如果数据量较大，故障恢复会需要比较长的时间。

参考链接：

优点：高可用、可扩展。横向扩容可支持海量数据

概念：基于主从模式+哨兵模式，引入分片的设计，通过hash计算，将数据分开存储对应节点负责的槽（slot）

参考链接：

优点：通过VIP的漂移实现主备切换，提供不间断的读写服务。实现简单，成本低

缺陷：单机吞吐量有限

缓存击穿

缓存雪崩

缓存穿透

缓存淘汰策略

前提条件：有N个互相完全独立的master节点（节点完全互相独立，之间不存在主从复制或其他集群协调机制）

算法过程：
1.获取当前毫秒级时间
2.依次尝试对这个N个节点加锁。在尝试加锁的时候应该设置一个加锁的超时时间，这个超时时间应该小于锁的失效时间，避免redis节点已经挂掉了，锁都达到失效时间了，客户端还在等待加锁结果。如果redis没有在超时时间内响应，客户端应该放弃该节点，尝试下一个节点的加锁。
3.当且仅当超过 N/2+1个节点加锁成功时，进入第四步
4.客户端使用当前时间，减掉第一步的时间，得到整个加锁尝试过程耗时。如果加锁的耗时小于锁的失效时间，那么就认为加锁成功。
5.如果客户端尝试加锁失败（少于半数节点被加锁或加锁耗时超过了锁的有效期），那么客户端会休眠一段随机时间后，重新尝试加锁

1.redis加锁的时候，为啥既要key又要value呢？而且value通常是一个随机字符串？

2.客户获取锁失败后，在重试加锁之前，为何必须等待一段随机时间？

3.单redis节点实现的简单分布式锁是否可应用于强一致性的场景？