删除Key的命令会阻塞Redis吗

会！
当你试图删除一个非常大的key时。例如，如果你有一个包含数百万个元素的列表或集合或者很大的String，并且你试图用一个DEL命令来删除它，那么这个操作可能会花费一些时间，并在此期间阻塞其他操作。

为什么当Key非常大的时候redis会阻塞？
Redis是单线程的，这意味着它一次只能执行一个操作。当你要求Redis删除一个大的key时，这个操作可能会花费一些时间。在这个时间内，Redis不能处理其他任何操作，因此会出现阻塞。
这是因为在Redis中，删除一个key需要遍历并释放key所关联的所有内存。如果key关联的数据结构非常大（例如，一个包含数百万个元素的列表或集合），那么遍历和释放内存的过程就会耗费更多的时间。在这个过程中，Redis不能处理其他操作，因此会出现阻塞。
为了避免这种阻塞，Redis 4.0引入了UNLINK命令。当你使用UNLINK命令删除一个key时，Redis会立即返回，并在后台异步删除key。这样，即使你正在删除一个大的key，其他的Redis操作也不会被阻塞。但是，UNLINK命令不能保证立即删除key，如果你需要立即删除key，你仍然需要使用DEL命令。

Redis 主从、哨兵、集群架构的优缺点

• 监控：哨兵会不断的检查master和slave是否按照预期工作
• 自动故障恢复：如果master故障了，就选取一个slave来“当老大”，即使故障修复了也不会换回来。
• 通知：在选出新的master后，需要让其他的slave和客户端与新的master通信，那么就需要哨兵在执行故障转移的时候，通知其他的slave和客户端。

哨兵节点（sentinel）也是redis的实例，对每一个主从redis节点监听
客户端直接访问哨兵节点。
如果主节点挂了
哨兵会监视到，然后从从节点中选取一个作为主节点。并且把这个新的主节点告诉客户端。
主从切换的时候不需要运维介入，全程自动化。
切换的过程虽然自动化，但是没有那么快，如果在这个过程中访问可能会瞬断/报错。

单节点实际支持的并发只有10万。大公司满足不了并发。
单节点不宜设置过大<10G，太大会影响数据恢复或主从同步的效率

Redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片的特性。
假设存储100G的数据，总的缓存数据分片存储（一个主节点30G,30G,40G），可以现行扩容到上万个节点，但是官方推荐不超过1000个。

瞬断的问题：假设一个主节点挂了，那么会选取一个从节点作为主节点，访问当前主节点的数据会瞬断，但是如果访问的数据在其他主从节点就不会瞬断，因此还存在瞬断，但是概率降低了。

redis集群中一个master挂了,怎么选举新的master

在Redis集群中,当一个master节点宕机或者不可达时,会从它的slave节点中选出一个新的master节点接替它,具体的选举过程如下:

1. 发现故障

集群中的每个节点会定期使用ping消息检测相邻节点是否可达。如果一个节点检测到master节点失败,会将这个master标记为PFAIL状态。

2. 选举投票

检测到故障的slave节点会向集群内的所有master节点发送投票消息,请求将自己设置为新的master。

3. 处理投票

收到投票请求的master节点会比较所有候选slave,根据slave优先级、偏移量（offset）、运行时长等来选出最合适的那个slave。

4. 响应投票

集群中的所有master节点向该slave发送确认消息,同意其成为新的master。

5. 配置更新

该slave在收到超过半数（包括自己的主节点 ）master的确认后,会将自己的配置切换为master,包括生成新的节点ID。(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)

6. 主从切换

原来的slave会向新的master发送SYNC命令,成为其slave。新的master会更新原来master的slot信息。

至此,选举完成,这个slave已切换成新的master,原有的master节点也从集群中移除。这保证了集群的高可用性。
整个重新选举的时间通常在1-2秒,对客户端无感知。Redis集群能够自动快速完成故障转移和新master的选举。

Redis集群数据hash分片算法

Redis集群将所有数据划分为16384个槽位（slot）

Redis执行命令有死循环阻塞bug

RANDOMKEY
从当前数据库中返回（不删除）一个key。

#数据库不为空
redis> MSET fruit "apple" drink "beer" food "cookies" #设置多个key
OK

redis> RANDOMKEY
"fruit"

redis> RANDOMKEY
"food"

redis> KEYS *   #查看数据库内所有key，证明RANDOMKEY 并不删除key
1) "food"
2) "drink"
3) "fruit"

Redis对于过期Key的处理策略是惰性删除的方式，RANDOMKEY在随机拿到一个key时，首先会检查key是否过期，如果过期，就会删除这个key，因为这个key被删除了，RANDOMKEY无法把当前key作为正确结果输出，因此会再次查找下一个随机key。如果有大量key已经过期还未来得及被清理调，那么会一直去寻找没有过期的key，这个过程可能会持续很久，因此会影响redis性能。
Redis 在复制过程中使用的是异步复制机制，主服务器将命令发送给从服务器，但从服务器并不会中断正在执行的查询命令来执行主服务器发送的删除命令。相反，从服务器会继续处理当前的查询命令，保持与主服务器的同步，并且只有在查询命令执行完毕后，才会开始执行主服务器发送的删除命令。
如果在从节点（slave）上执行RANDOMKEY，那么问题会更严重，
slave自己是不会清理过期key，当一个key要过期时，master会先清理删除它，之后master向slave发送一个DEL命令，告诉slave也删除key以此达到主从库的数据一致性。
因此在redis中存在大量过期key的情况下，在slave身上执行RANDOMKEY取到随机但是过期的key不会删除它，而是继续寻找不过期的key，由于大量key都已过期，因此大概率陷入死循环状态。
这其实是Redis的一个Bug，这个bug一直持续到5.0才被修复。
修复的解决方案就是在slave中的查找次数做出限制。

一次线上事故，Redis主从切换导致了缓存雪崩

假设slave的机器时钟比master走得快很多，比如主服务器12点，此时从服务器已经1点了。
此时master中一些没有过期的key，在slave的视角就是过期的，如果此时进行主从切换操作，把时间快的从服务器换到主服务器上，新主服务器就会开始大量清理过期key，引发缓存雪崩。
一定要保证主从服务器时钟的一致性。