持久化

RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程 都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的。

这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork

Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

配置

保存的文件：

命令：

save	# 立即保存生成rdb快照文件
save 120 10 # 120秒内修改10次则触发RDB

如何触发RDB快照

1、配置文件中默认的快照配置，建议多用一台机子作为备份，复制一份 dump.rdb

2、命令save或者是bgsave

• save 时只管保存，其他不管，全部阻塞

• bgsave，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过 lastsave

命令获取最后一次成功执行快照的时间。

3、执行 flushall 命令，也会产生 dump.rdb 文件，但里面是空的，无意义 !

4、关闭 redis（执行 shutdown命令）的时候也会产生 dump.rdb 文件！

优点

• 适合大规模的数据恢复

• 对数据完整性和一致性要求不高更适合使用

• 节省磁盘空间

• 恢复速度快

缺点

• Fork 的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• 虽然 Redis 在 fork 时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。

• 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

总结

AOF

以日志的形式来记录每个写操作，将 Redis 执行过的所有指令（成功执行的写命令）记录下来，是以追加的方式写入文件 ，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

配置

**开启方法：**把 appendonly 改为 yes，重启生效

1. 对于事务中的命令，只有有成功执行了的写命令，才会进行追加写到日志文件中（包括 multi exec等命令）

2. 只有在重启之后才会生成日志文件，并且在日志文件存在的情况下进行追加写的操作。（如果重启之后删除该日志文件，执行非读指令也不会生成该日志文件）

保存的日志文件

AOF 持久化流程

（1）客户端的请求写命令会被 append 追加到 AOF 缓冲区内；

（2）AOF 缓冲区根据 AOF 持久化策略 [ always,everysec,no ] 将操作 sync 同步到磁盘的 AOF 文件中；

（3）AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；

（4）Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的；

AOF 和 RDB同时开启，redis听谁的？

AOF 和 RDB 同时开启，系统默认取 AOF 的数据（数据不会存在丢失）

AOF同步频率设置

• appendfsync always

始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好

• appendfsync everysec

每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

• appendfsync no

Redis 不主动进行同步，把同步时机交给操作系统。

AOF 启动/修复/恢复

正常恢复：

• 启动：修改默认的 appendonly no，改为yes

• 将有数据的 aof 文件复制一份保存到对应目录（config get dir）

• 恢复：重启 redis 然后重新加载

异常恢复：

• 启动：设置Yes

• 故意破坏 appendonly.aof 文件！(重启 redis 会报错)

• 修复： ==redis-check-aof --fix appendonly.aof== 进行修复

• 恢复：重启 redis 然后重新加载

优点

• 备份机制更稳健，丢失数据概率更低。

• 可读的日志文本，通过操作AOF稳健，可以处理误操作

缺点

• 比起 RDB占用更多的磁盘空间。（体积更大）

• 恢复备份速度慢。（恢复速度更慢）

• 每次读写都同步的话，有一定的性能压力。（性能相对较差）

• 存在个别 Bug ，造成无法恢复。

发布订阅

定义

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。

Redis 客户端可以订阅任意数量的频道。

命令

测试

# 订阅者
127.0.0.1:6379> SUBSCRIBE chatRoom
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "chatRoom"
3) (integer) 1

# 发布者
127.0.0.1:6379> PUBLISH chatRoom "hello,jiutian"
(integer) 1
127.0.0.1:6379> PUBLISH chatRoom "hello,redis"
(integer) 1

# 订阅者
127.0.0.1:6379> SUBSCRIBE chatRoom
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "chatRoom"
3) (integer) 1
1) "message"
2) "chatRoom"
3) "hello,jiutian"
1) "message"
2) "chatRoom"
3) "hello,redis"

原理

Redis 是使用 C 实现的，通过分析 Redis 源码里的 pubsub.c 文件，了解发布和订阅机制的底层实现，籍此加深对 Redis 的理解。

Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能。 通过 SUBSCRIBE 命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个 channel ，而字典的值则是一个链表，链表中保存了所有订阅这个 channel 的客户端。SUBSCRIBE 命令的关 键，就是将客户端添加到给定 channel 的订阅链表中。

通过 PUBLISH 命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的 channel 字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。

Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，可以设定对某一个
key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应 的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

主从复制

概念

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

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

1、**数据冗余：**主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2、**故障恢复：**当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

3、**负载均衡：**在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

4、**高可用基石：**除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是
Redis 高可用的基础。

环境配置

基本配置

在一台机子上配置多个Redis 步骤：

1、拷贝多个 redis.conf 文件

2、指定端口 6379，依次类推

3、开启 daemonize yes

4、Pid文件名字 pidfile /var/run/redis_6379.pid , 依次类推

5、Log文件名字 logfile "6379.log" , 依次类推

6、Dump.rdb 名字 dbfilename dump6379.rdb , 依次类推

配从库不配主库，从库配置：

slaveof 主库ip 主库端口 # 配置主从 (针对从机)
# 每次与 master 断开之后，都需要重新连接，可以配置进 redis.conf 文件中

Info replication # 查看信息

配好如图（一主二从）：

说明：

• 主机可读可写，而从机只能读
• 主机如果挂了，从机仍然连接着，并能读数据
• 主机重启恢复，从机也能读到主机写入的数据
• 从机挂了，需要重连，成为从机（Slave) 后也能读到主机中的数据
• 从机中的数据是从主机复制过来的，并持久化了，所以从机重启之后若不再是从机（Slave) 也有之前的数据。

谋朝篡位

一主二从的情况下，如果主机断了，从机可以使用命令 SLAVEOF NO ONE 将自己改为主机！这个时 候其余的从机链接到这个节点。对一个从属服务器执行命令 SLAVEOF NO ONE 将使得此从属服务器关闭复制功能，并转变回主服务器，但是原来同步所得的数据集不会被丢弃。

层层链路（薪火相传）

前一个 Slave 可以作为后一个Slave的Master，Slave 同样可以接收其他 slaves 的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻 master 的写压力！

复制原理

• Slave 启动成功连接到 master 后会发送一个 sync 命令 。

• Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行

• 完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。

• 全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。

• 增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步 。

• 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行 。

哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵） 架构来解决这个问题。

谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独 立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

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

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行 failover过程，仅仅是哨兵1主观的认 为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover [ 故障转移 ] 操作。

切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换为主机，这个过程称为 客观下线。

测试

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

   # sentinel monitor 被监控主机名字 ip port 投票数
   # 其中 mymaster 为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量
   sentinel monitor mymaster 127.0.0.1 6379 1
   

2. 开启哨兵

redis-sentinel jtconfig/sentinel.conf

3. master 挂掉

master 挂掉之后会选举从机充当master。

4. master 重启

重启后之前的master会成为新的master的slave。

复制时延

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

故障恢复

• 优先级在redis.conf中默认：slave-priority 100，值越小优先级越高

• 偏移量最大是指获得原主机数据最全的

• 每个redis实例启动后都会随机生成一个40位的runid

总结

哨兵模式的优缺点

优点

1. 哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。

2. 主从可以切换，故障可以转移，系统可用性更好。

3. 哨兵模式是主从模式的升级，系统更健壮，可用性更高。

缺点

1. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

2. 实现哨兵模式的配置也不简单，甚至可以说有些繁琐

哨兵配置说明

# Example sentinel.conf 

# 哨兵sentinel实例运行的端口 默认26379 
port 26379 

# 哨兵sentinel的工作目录 
dir /tmp 

# 哨兵sentinel监控的redis主节点的 ip port 
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。 
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum> 
sentinel monitor mymaster 127.0.0.1 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 
# sentinel auth-pass <master-name> <password> 
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd 

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 
# sentinel down-after-milliseconds <master-name> <milliseconds> 
sentinel down-after-milliseconds mymaster 30000 

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长， 但是如果这个数字越大，就意味着越多的slave因为replication而不可用。 可以通过将这个值设为1 来保证每次只有一个slave 处于不能处理命令请求的状态。 
# sentinel parallel-syncs <master-name> <numslaves> 
sentinel parallel-syncs mymaster 1 

# 故障转移的超时时间 
failover-timeout 可以用在以下这些方面： 
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。 
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的 master那里同步数据时。 
#3.当想要取消一个正在进行的failover所需要的时间。 
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超 时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了 
# 默认三分钟 
# sentinel failover-timeout <master-name> <milliseconds> 
sentinel failover-timeout mymaster 180000 

# SCRIPTS EXECUTION 

#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮 件通知相关人员。 
#对于脚本的运行结果有以下规则： 
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10 
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。 
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。 
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等 等），将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常 运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果 sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执 行的，否则sentinel无法正常启动成功。
#通知脚本 
# sentinel notification-script <master-name> <script-path> 
sentinel notification-script mymaster /var/redis/notify.sh 

# 客户端重新配置主节点参数脚本 
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已经发生改变的信息。 
# 以下参数将会在调用脚本时传给脚本: 
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> 
# 目前<state>总是“failover”, 
# <role>是“leader”或者“observer”中的一个。 
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的 slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。 
# sentinel client-reconfig-script <master-name> <script-path> 
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

缓存穿透和雪崩

缓存穿透

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

大量请求的 key 根本不存在于缓存中（不是过期），导致请求直接到了数据库上。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案

1.缓存空对象

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

但是这种方法会存在两个问题：

1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键；

2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。

2.布隆过滤器

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

3.设置可访问的名单（白名单）

使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。

4.进行实时监控

当发现Redis的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

缓存击穿

概述

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。

解决方案

1.预先设置热门数据

在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的时长。

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

2.实时调整

现场监控哪些数据热门，实时调整key的过期时长。

3.加互斥锁

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

使用锁步骤如下：

（1） 在缓存失效的时候（判断拿出来的值为空），不是立即去load db。

（2） 先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key

（3） 当操作返回成功时，再进行load db的操作，并回设缓存,最后删除mutex key；

（4） 当操作返回失败，证明有线程在load db，当前线程睡眠一段时间再重试整个get缓存的方法。

缓存雪崩

概念

缓存雪崩，是指在某一个极短的时间段内，缓存集中过期失效。

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

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

解决方案

1.构建多级缓存架构，redis高可用

这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建集群。 nginx缓存 + redis缓存 +其他缓存（ehcache等）

2.限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key同时只允许一个线程查询数据和写缓存，其他线程等待。

3.数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

4.设置过期标志更新缓存

记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。