Redis进阶

目录

一、持久化（重点）

RDB （Redis DataBase）

触发机制

如何恢复rdb文件？

AOF（Append Only File）

二、Redis发布订阅

命令

测试

原理

三、Redis主从复制（重点)

概念

主从复制的作用主要包括:

环境配置

启动三个redis服务

设置一主二从

复制原理

四、哨兵模式详解

概述

节点下线

Leader选举

故障转移

配置哨兵

哨兵模式全部配置

五、Redis缓存穿透和雪崩

缓存穿透（查不到）

概念

解决方案

2、缓存空对象

缓存击穿（量太大，缓存过期）

概述

解决方案

缓存雪崩

概述

解决方案

一、持久化（重点）

Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能!Redis 提供两种持久化机制 RDB 和 AOF 机制

RDB （Redis DataBase）

RDB 就是快照/内存快照，RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis会单独创建（fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
rdb保存的文件是dump.rdb 都是在我们的配置文件中快照中进行配置的!

触发机制

• 1、save的规则满足的情况下，会自动触发rdb规则
• 2、执行flushall命令，也会触发我们的rdb规则!
• 3、退出redis，也会产生rdb文件!

备份就自动生成一个dump.rdb

如何恢复rdb文件？

只需要将rdb文件放在我们redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据!

查看需要存在的位置
127.0.0.1:6379>config get dir

1) "dir"
2) "/usr/local/bin"  # 如果在这个目录下存在 dump. rdb 文件，启动就会自动恢复其中的数据

优点:

• 1、适合大规模的数据恢复!
• 2、对数据的完整性要不高!

缺点∶

• 1、需要一定的时间间隔进程操作!如果redis意外宕机了，这个最后一次修改数据就没有的了!
• 2、fork进程的时候，会占用一定的内容空间!

AOF（Append Only File）

将我们的所有命令都记录下来，history，恢复的时候就把这个文件全部在执行一遍

appendonly no

默认是不开启的，我们需要手动进行配置!我们只需要将appendonly改为yes就开启了aof !
重启，redis就可以生效了!

如果这个aof文件有错，这时候redis是启动不起来的，我们需要修复这个aof文件redis给我们提供了一个工具redis-check-aof --fix
示例：破坏appendonly.aof文件

如果文件正常，重启就可以直接恢复了!

优点：

• （1）数据安全， AOF 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 AOF 文件中一次。
• （2）通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
• （3） AOF 机制的 rewrite 模式。 AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall )

缺点：

• （1） AOF 文件比 RDB 文件大，且恢复速度慢。
• （2）数据集大的时候，比 RDB 启动效率低。
• 可能阻塞其他操作： 由于写操作命令执行成功后才记录到 AOF 日志，所以不会阻塞当前命令的执行，但因为 AOF 日志也是在主线程中执行，所以当 Redis 把日志文件写入磁盘的时候，还是会阻塞后续的操作无法执行。

扩展∶
1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化
4、同时开启两种持久化方式

• 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
• RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段

5、性能建议

• 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
• 如果使用 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
• 如果不使用AOF，仅靠Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉(断电)，会丢失十几分钟的数据，启动脚本也要比较两个MasterlSlave中的RDB文件，载入较新的那个，微博就是这种架构。

二、Redis发布订阅

Redis 发布订阅(publsub)是一种消息通信模式∶发送者(pub)发送消息，订阅者(Sub)接收消息。微信、微博、关注系统!Redis客户端可以订阅任意数量的频道。
订阅/发布消息图:
第一个:消息发送者，第二个:频道 ，第三个∶消息订阅者
下图展示了频道channel1，以及订阅这个频道的三个客户端―—client2、 client5和client1之间的关系:

当有新消息通过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端:

命令

这些命令被广泛用于构建即时通信应用，比如网络聊天室(chatroom)和实时广播、实时提醒等。

测试

订阅端∶
127.0.0.1:6379> SUBSCRIBE channel  #订阅一个频道channel

Reading messages. . . (press ctr1-c to quit)
1)"subscribe"
2) "channel"

3) (integer) 1

# 等待读取推送的信息

1) "megsage"  # 消息
2)"channel"    #哪个频道的消息

3) "hello,channel" #消息的具体内容

1) "message "
2) "channel"

3) "hello,redis"
发送端︰
127.0.0.1:6379>PUBLISH channel "hello,channel"  #发布者发布消息到频道!

(integer) 1
127.0.0.1:6379>PUBLISH channel "hello, redis"   # 发布者发布消息到频道!

(integer) 1

原理

 使用场景∶

• 1、实时消息系统!
• 2、事实聊天!（频道当做聊天室，将信息回显给所有人即可!)
• 3、订阅，关注系统都是可以的!

稍微复杂的场景我们就会使用消息中间件MQ ( )

三、Redis主从复制（重点)

概念

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower);数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。默认情况下，每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的作用主要包括:

1、数据冗余:主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复︰当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复;实际上是一种服务的冗余。
3、负载均衡∶在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载;尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
4、高可用(集群)基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的(宕机），原因如下∶
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大;2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。对于这种场景，我们可以使如下这种架构︰

主从复制，读写分离! 80%的情况下都是在进行读操作!减缓服务器的压力!架构中经常使用!一主二从!只要在公司中，主从复制就是必须要使用的，因为在真实的项目中不可能单机使用Redis !

环境配置

只配置从库，不用配置主库

 复制三个配置文件，然后修改对应的信息【端口号、pid、log文件名字、dump.rdb名字】

修改vim redis79.conf

logfile "6379.log"

dbfilename dump6379.rdb

修改vim redis80.conf

port 6380

pidfile /var/run/redis_6380.pid

logfile "6380.log"

dbfilename dump6380.rdb

 修改vim redis81.conf

port 6381

pidfile /var/run/redis_6381.pid

logfile "6381.log"

dbfilename dump6381.rdb

启动三个redis服务

//分别启动三个
redis-server config/redis79.conf
redis-server config/redis80.conf
redis-server config/redis81.conf

设置一主二从

  6381配置相同，省略

真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的!
那如何在配置文件中配置呢？在配置文件中修改下面内容，在启动时自动就是从机

测试∶主机断开连接，从机依旧连接到主机的，但是没有写操作，这个时候，主机如果回来了，从机依旧可以直接获取到主机写的信息!-----如果是使用命令行，来配置的主从，从机这个时候如果重启了，就会变回主机!只要变为从机，立马就会从主机中获取值!

复制原理

Slave启动成功连接到master后会发送一个sync同步命令，Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制:而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制:Master继续将新的所有收集到的修改命令依次传给slave，完成同步
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行!我们的数据一定可以在从机中看到!
 

谋朝篡位：如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机!其他的节点就可以手动连接到最新的这个主节点(手动)!如果这个时候老大修复了，那就重新连接!

四、哨兵模式详解

(自动选举老大的模式)

概述

主从切换技术的方法是︰当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵）架构来解决这个问题。
谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用。这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
 

节点下线

• 主观下线

  • 即 Sentinel 节点对 Redis 节点失败的偏见，超出超时时间认为 Master 已经宕机。

  • Sentinel 集群的每一个 Sentinel 节点会定时对 Redis 集群的所有节点发心跳包检测节点是否正常。如果一个节点在 down-after-milliseconds 时间内没有回复 Sentinel 节点的心跳包，则该 Redis 节点被该 Sentinel 节点主观下线。

• 客观下线

  • 所有 Sentinel 节点对 Redis 节点失败要达成共识，即超过 quorum 个统一。

  • 当节点被一个 Sentinel 节点记为主观下线时，并不意味着该节点肯定故障了，还需要 Sentinel 集群的其他 Sentinel 节点共同判断为主观下线才行。

  • 该 Sentinel 节点会询问其它 Sentinel 节点，如果 Sentinel 集群中超过 quorum 数量的 Sentinel 节点认为该 Redis 节点主观下线，则该 Redis 客观下线。

Leader选举

• 选举出一个 Sentinel 作为 Leader：集群中至少有三个 Sentinel 节点，但只有其中一个节点可完成故障转移.通过以下命令可以进行失败判定或领导者选举。

• 选举流程

  1. 每个主观下线的 Sentinel 节点向其他 Sentinel 节点发送命令，要求设置它为领导者.

  2. 收到命令的 Sentinel 节点如果没有同意通过其他 Sentinel 节点发送的命令，则同意该请求，否则拒绝。

  3. 如果该 Sentinel 节点发现自己的票数已经超过 Sentinel 集合半数且超过 quorum，则它成为领导者。

  4. 如果此过程有多个 Sentinel 节点成为领导者，则等待一段时间再重新进行选举。

故障转移

• 转移流程

  1. Sentinel 选出一个合适的 Slave 作为新的 Master(slaveof no one 命令)。

  2. 向其余 Slave 发出通知，让它们成为新 Master 的 Slave( parallel-syncs 参数)。

  3. 等待旧 Master 复活，并使之称为新 Master 的 Slave。

  4. 向客户端通知 Master 变化。

• 从 Slave 中选择新 Master 节点的规则(slave 升级成 master 之后)

  1. 选择 slave-priority 最高的节点。

  2. 选择复制偏移量最大的节点(同步数据最多)。

  3. 选择 runId 最小的节点。

Sentinel 集群运行过程中故障转移完成，所有 Sentinel 又会恢复平等。Leader 仅仅是故障转移操作出现的角色。

配置哨兵

1、配置哨兵配置文件vim sentinel.conf

# sentinel monitor 被监控的名称 host port quorum

sentinel monitor myredis 127.0.0.1 6379 1  # 1 用来投票时用

2、启动哨兵 

redis-sentinel config/sentinel.conf

3、哨兵日志，主机挂了，自动选择另一个主机

如果主机此时回来了，只能归并到新的主机下，当做从机，这就是哨兵模式的规则!
优点:

• 1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有
• 2、主从可以切换，故障可以转移，系统的可用性就会更好
• 3、哨兵模式就是主从模式的升级，手动到自动，更加健壮!

缺点︰

• 1、Redis不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦!
• 2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择!

哨兵模式全部配置

五、Redis缓存穿透和雪崩

Redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时，它也带来了一些问题。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。如果对数据的一致性要求很高，那么就不能使用缓存。
另外的一些典型问题就是，缓存穿透、缓存雪崩和缓存击穿。目前，业界也都有比较流行的解决方案。

缓存穿透（查不到）

概念

缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（例如商品秒杀!)，于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
 

解决方案

1、布隆过滤器

布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力;

2、缓存空对象

当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源;
但是这种方法会存在两个问题:

• 1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键;
• 2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（量太大，缓存过期）

概述

微博热搜--服务器宕机（60s过期，60.1s恢复，0.1s的时间由于巨大的冲击瞬间砸在服务器上）

缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

解决方案

1、设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key过期后产生的问题。

2、加互斥锁
分布式锁:使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

概述

缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis宕机!
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把数据库压垮。
比如双十一：停掉一些服务（不可退款）（保证主要服务可用）

解决方案

1、redis高可用
这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。
2、限流降级
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
3、数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。