2302_77582029的博客

缓存雪崩是指在某个时间段内，缓存中的大量数据同时过期或者失效，导致大量请求直接打到数据库上，造成数据库压力过大，这种情况下，可以通过设置不同的过期时间，使用分布式锁或者热点数据预加载来解决。如果从缓存没有查询到数据，则进行互斥锁的获取，获取互斥锁后，判断是否获得到了锁，如果没有得到，则休眠，过一会再进行尝试，直到获取到锁为止，才能进行查询。如果获取到了锁的线程，再去进行查询，查询后将数据写入 redis，再释放锁，返回数据，利用互斥锁就能保证只有一个线程去执行操作数据库的逻辑，防止缓存击穿。

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。三个主节点会分配槽，处理客户端的命令请求，而从节点可用在主节点故障后，顶替主节点。

为了防止sentinel误判和单点故障，sentinel也应该部署为集群，sentinel多个节点同时监控redis主从架构，一旦有一个sentinel节点发现redis的主节点不在线时的情况，sentinel会与其他的sentinel节点协商，看其他的sentinel节点是否也同样发现redis的主节点不在线，如果sentinel的多个点节点都发现redis的主节点都为离线，那么则判定redis主节点为离线状态，以此方式避免误判，同样也避免了单点故障。也可以在3台不同的服务器上进行搭建redis。

AOF类似于MySQL的二进制日志，记录每一次redis的写操作命令，以顺序IO方式附加在指定文件的尾部，是使用追加方式实现的，这也叫做一种附加日志类型的持久化机制，由于每一次的操作都记录，则会随着时间长而增大文件的容量，AOF不像RDB，RDB是保存数据集的本身。因为redis的主线程是用于处理请求的，所以此时会阻塞所有客户端请求，每次的保存快照都是把内存中的数据完整的保存一份，并非是增量的，如果内存中的数据比较大，而还有大量的写操作请求时，此方式会引起大量的I/O，会导致redis性能下降。

创建一个新的列表，在帮助中并没产明哪个命令用于创建一个新的列表，实际上创建一个新的列表使用LPUSH或RPUSH都可以。在同一个库中（名称空间），键的名称不得重复，如果复制键的名称，实际上是修改键中的值 ##一个库就是一个名称空间。键指向一个列表，而列表可以理解为是一个字符串的容器，列表是由众多元素组成的集合，可以在键所指向的列表中附加一个值。192.168.1.11:6379> lpush ll fda #在原有的列表中的左侧加入一个值。key 过期后将不再可用。

这样对于客户端而言，一切都是透明的。Redis和Memcache类似，但很大程度补偿了Memcache的不足，Redis数据都是缓存在计算机内存中，不同的是，Memcache只能将数据缓存到内存中，无法自动定期写入硬盘，这就表示，一断电或重启，内存清空，数据丢失。当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)没有实现自动进行主备切换，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。