Redis进阶知识一览

Redis的持久化机制

RDB: Redis DataBase

1. 什么是RDB
   RDB∶每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存。如果宕机重启，那么内存里的数据肯定会没有的，那么再次启动redis后，则会恢复。

2. 备份与恢复
   内存备份-->磁盘临时文件
   临时文件-->恢复到内存

3. RDB优劣势

   • 优势
     1. 每隔一段时间备份，全量备份
     2. 灾备简单，可以远程传输
     3. 子进程备份的时候，主进程不会有任何io操作（不会有写入修改或删除），保证备份数据的的完整性
     4. 相对AOF来说，当有更大文件的时候可以快速重启恢复
   • 劣势
     1. 发生故障时，有可能会丢失最后一次的备份数据
     2. 子进程所占用的内存比会和父进程一模一样，这会造成CPU负担
     3. 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。

4. RDB的配置

   1. 保存位置，可以在redis.conf自定义∶/user/local/redis/working/dump.rdb
   2. 保存机制∶

save 900 1       # 如果1个缓存更新，则15分钟后备份save 300 10      # 如果10个缓存更新，则5分钟后备份save 60 10000    # 如果10000个缓存更新，则1分钟后备份

3. stop-writes-on-bgsave-error
   • yes∶如果save过程出错，则停止写操作
   • no∶ 可能造成数据不一致
4. rdbcompression
   • yes∶开启rdb压缩模式
   • no∶关闭，会节约cpu损耗，但是文件会大，道理同nginx
5. rdbchecksum
   • yes∶使用CRC64算法校验对rdb进行数据校验，有10%性能损耗
   • no∶不校验

总结
RDB适合大量数据的恢复，但是数据的完整性和一致性可能会不足

AOF: Append Only File

??RDB会丢失最后一次备份的rdb文件，但是其实也无所谓，其实也可以忽略不计，毕竟是缓存，丢了就丢了，但是如果追求数据的完整性，那就的考虑使用AOF了。
AOF特点

1. 以日志的形式来记录用户请求的写操作。读操作不会记录，因为写操作才会存存储。
2. 文件以追加的形式而不是修改的形式。
3. redis的aof恢复其实就是把追加的文件从开始到结尾读取执行写操作。

优势

1. AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。所以AOF可以每秒备份一次，使用fsync操作。
2. 以log日志形式追加，如果磁盘满了，会执行redis-check-aof 工具
3. 当数据太大的时候，redis可以在后台自动重写aof。当redis继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端的读写操作。
4. AO日志包含了所有写操作，会更加便于redis的解析恢复。

劣势

1. 相同的数据，同一份数据，AOF比RDB大
2. 针对不同的同步机制，AOF会比RDB慢，因为AOF每秒都会备份做写操作，这样相对与RDB来说就略低。 每秒备份fsync没毛病，但是如果客户端的每次写入就做一次备份fsync 的话，那么redis的性能就会下降。
3. AOF发生过bug，就是数据恢复的时候数据不完整，这样显得AOF会比较脆弱，容易出现bug，因为AOF没有RDB那么简单，但是呢为了防止bug的产生，AOF就不会根据日的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠了。

AOF的配置

# AOF 默认关闭，yes可以开启appendonly no# A0F 的文件名appendfilename "appendonly.aof"# no∶不同步# everySec∶每秒备份，推荐使用# always∶每次操作都会备份，安全并且数据完整，但是慢性能差appendfsync everysec# 重写的时候是否要同步，no可以保证数据安全no-appendfsync-on-rewrite no# 重写机制∶避免文件越来越大，自动优化压缩指令，会fork一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的aof文件不会被读取使用，类似rdb# 当前A0F文件的大小是上次AOF大小的100% 并且文件体积达到64m，满足两者则触发重写auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

到底采用RDB还是AOF呢?

1. 如果你能接受一段时间的缓存丢失，那么可以使用RDB
2. 如果你对实时性的数据比较care，那么就用AOF
3. 使用RDB和AOF结合一起做持久化，RDB做冷备，可以在不同时期对不同版本做恢复，AOF做热备，保证数据仅仅只有1秒的损失。当AOF破损不可用了，那么再用RDB恢复，这样就做到了两者的相互结合，也就是说Redis恢复会先加载AOF，如果AOF有问题会再加载RDB，这样就达到冷热备份的目的了。

Redis 缓存过期处理与内存淘汰机制

计算机内存有限，越大越贵，Redis的高并发高性能都是基于内存的，用硬盘的话GG。

已过期的key如何处理?
设置了expire的key缓存过期了，但是服务器的内存还是会被占用，这是因为redis所基于的两种删除策略。
redis有两种策略∶

1. （主动）定时删除
   • 定时随机的检查过期的key，如果过期则清理删除。（每秒检查次数在redis.conf中的hz配置）
2. （被动）惰性删除
   • 当客户端请求一个已经过期的key的时候，那么redis会检查这个key是否过期，如果过期了，则删除，然后返回一个nil。这种策略对cpu比较友好，不会有太多的损耗，但是内存占用会比较高。

所以，虽然key过期了，但是只要没有被redis清理，那么其实内存还是会被占用着的。

那么如果内存被Redis缓存占用满了咋办?
内存占满了，可以使用硬盘，来保存，但是没意义，因为硬盘没有内存快，会影响redis性能。所以，当内存占用满了以后，redis提供了一套缓存淘汰机制∶ ME MORY MANAGEMENT。
maxmemory ∶当内存已使用率到达，则开始清理缓存

* noeviction∶旧缓存永不过期，新缓存设置不了，返回错误* allkeys-lru∶清除最少用的旧缓存，然后保存新的缓存（推荐使用）* allkeys-random∶在所有的缓存中随机删除（不推荐）* volatie-lru∶在那些设置了expire过期时间的缓存中，清除最少用的旧缓存，然后保存新的缓存* volatile-random∶在那些设置了expire过期时间的缓存中，随机删除缓存* volatile-ttl∶在那些设置了expire过期时间的缓存中，删除即将过期的

哨兵模式

Master挂了，如何保证可用性，实现继续读写
什么是哨兵？
Sentinel（哨兵）是用于监控Redis集群中Master状态的工具，是 Redis 高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务; 当某个master服务宕机后，会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。示例图：

配置哨兵监控master
创建并且配置sentinel.conf∶

• 普通配置

port 26379pidfile "/usr/local/redis/sentinel/redis-sentinel.pid"dir "/usr/local/redis/sentinel"daemonize yes protected-mode nologfile "/usr/local/redis/sentinel/redis-sentinel.1og"

• 核心配置

# 配置哨兵sentinel monitor mymaster 127.0.0.1 6379 2 #密码sentinel auth-pass <master-name> <password># master被sentinel认定为失效的间隔时间sentinel down-after-milliseconds mymaster 30000 # 剩余的slaves重新和新的master做同步的并行个数sentinel parallel-syncs mymaster 1# 主备切换的超时时间，哨兵要去做故障转移，这个时候哨兵也是一个进程，如果他没有去执行，超过这个时间后，会由其他的哨兵来处理sentinel failover-timeout mymaster 180000

启动哨兵x3
redis-sentinel sentinel.conf

测试

1. master挂了，看slave是否成为master
2. master恢复，观察slave状态

结论：master挂了以后，由于哨兵监控，剩余slave会进行选举，选举后其中一个成为master，当原来的master恢复后，他会成为slave。

一般master数据无法同步给slave的方案检查为如下∶

1. 网络通信问题，要保证互相ping通，内网互通。
2. 关闭防火墙，对应的端口开放（虚拟机中建议永久关闭防火墙，云服务器的话需要保证内网互通）。
3. 统一所有的密码，通过逐台检查机器以防某个节点被遗漏。

哨兵信息检查

查看相关信息

# 查看reminis-master下的master节点信息sentinel master reminis-master# 查看reminis-master下的slaves节点信息sentinel slaves reminis-master# 查看reminis-master下的哨兵节点信息sentinel sentinels reminis-master

SpringBoot集成Redis哨兵-配置

配置如下：

spring:  redis:    database: 1     password: reminis     sentinel:    master: reminis-master    nodes: 192.168.32.10:26379,192.168.32.12:26379,192.168.32.13:26379

Redis集群

前面我们一起学习了主从复制以及哨兵，他们可以提高读的并发，但是单个master容量有限，数据达到一定程度会有瓶颈，这个时候可以通过水平扩展为多master-slave成为集群。那么这一节开始我们就一起来学习redis-cluster∶他可以支撑多个master-slave，支持海量数据，实现高可用与高并发。

哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实是异步复制吧，这个时候master挂了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。

特点：

1. 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在于一个集群环境中，他们彼此之间可以交互和通信，比如ping pong。那么这些关系都会保存到某个配置文件中，每个节点都有，这个我们在搭建的时候需要做配置的。
2. 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
3. 某个节点挂了，也是通过超过半数的节点来进行的检测，客观下线后主从切换，和我们之前在哨兵模式中提到的是一个道理。
4. Redis中存在很多的插槽，又可以称之为槽节点，用于存储数据，这个先不管，后面再说。

集群容错

构建Redis集群，需要至少3个节点作为master，以此组成一个高可用的集群，此外每个master都需要配备一个slave，所以整个集群需要6个节点，这也是最经典的Redis集群，也可以称之为三主三从，容错性更佳。所以在搭建的时候需要有6台虚拟机。请各自准备6台虚拟机，可以通过克隆去构建，使用单实例的Redis 去克隆即可。

• 集群也可以在单服务器构建，称之为伪集群，但是生产环境肯定是真的，所以建议用6台。
• 克隆后务必关闭Redis。

构建Redis集群

redis.conf 配置

# 开启集群模式cluster-enabled yes# 每一个节点需要有一个配置文件，需要6份。每个节点处于集群的角色都需要告知其他所有节点，彼此知道，这个文件用于存储集群模式下的集群状态等信息，这个文件是由redis自己维护，我们不用管。如果你要重新创建集群，那么把这个文件删了就行cluster-config-file nodes-201.conf # 超时时间，超时则认为master宕机，随后主备切换cluster-node-timeout 5000 # 开启AOF appendonly yes

启动6个redis实例

1. 启动6台
2. 如果启动过程出错，把rdb等文件删除清空

创建集群

##### 注意1∶如果你使用的是redis3.x版本，需要使用redis-trib.rb来构建集群，最新版使用C语言来构建了，这个要注意# 注意2∶以下为新版的redis构建方式##### 创建集群，主节点和从节点比例为1，1-3为主，4-6为从，1和4.2和5 3和6分别对应为主从关系，这也是最经典用的最多的集群模式redis-cli --cluster create ip1:port1 ip2:port2 ip3:port 3 ip4:port4 ip5:port5 ip6:port6 --cluster-replicas 1

slots槽，用于装数据，主节点有，从节点没有

检查集群信息:redis-cli--cluster check 192.168.25.64:6380

总结

最后，让我们来看一下下方的思维导图进行梳理内容：

复习

1. 本阶段开篇讲述了分布式相关，其实分布式和集群的概念在前期就介绍过了，不同的节点做着不同的事，就是分布式，不同的节点做着相同的事就是集群。那么Redis是NoSql，不仅仅是sql，功能更强劲，可以作为缓存写入内存，提供高速访问，为数据库做了一道屏障，保护数据库，把热点数据放入缓存，从而提升项目的并发量与吞吐量。
2. 介绍完Redis后我们又一起搭建了单机单实例版的Redis，需要注意，Redis虽然可以在win或mac上搭建，但是企业里都是linux，所以我们一定要使用linux来搭建和配置。
3. Redis提供命令行客户端工具，也就是redis-cli进入命令行后可以进行相应的操作，我们讲述了五大数据类型，分别为∶string，list，hash，set与zset。每个数据类型包含了一些操作指令，这些没有必要去死记硬背，遇到了，就去查一下api,百度一下即可。
4. Redis是单线程的，但是他的性能却很高，在这里我们讲述了Redis的单线程模型，这一点往往在面试过程中会被问到。
5. 当单机的Redis安装配置完毕以后，我们整合到了项目中，结合了SpringBoot，优化了首页的轮播图与分类，因为这些完全可以放入缓存，没有必要去查询数据库。当然，对干前期单体阶段的购物车，我们结合了redis实现了分布式购物车，如此，不论用户在任何电脑访问，都能看到曾经的购物车数据，并且我们也实现了登录后的同步购物车功能。
6. Redis可以实现类似于MQ的发布与订阅，是属于生产者与消费者模式，但是正所谓专人做专事，发布订阅机制没有必要用Redis来实现，企业里都是使用的MQ。
7. Redis的持久化机制，RDB与AOF，这两种模式大家一定要知道他们之间的区别，一个是全量备份，一个是增量定时，各有各的好，也有缺点，面试过程中会被问到。
8. 单机Redis存在单点故障与读并发量的限制，所以可以通过主从与哨兵来实现，主从解决读写分离，并且一主多从能够提升读的并发。哨兵提供监控机制，一旦主挂了，备则上位成为主，如此实现高可用。
9. 在Redis中可以设置无磁盘化，如果磁盘比较慢，可以打开，但是一般来说，服务器都会采用ssd，尤其针对数据存储类的。
10. 当key过期了，你会发现内存占用率还是很高，这是因为redis的机制，有被动主动之分。这一点在面试中可能会被问到哟。此外，对于内存写满后的kev淘汰机制，我们也在这里提到过，不同的策略都可以配置。
11. Redis除了单机与哨兵模式外，还能搭建集群，最经典的还属三主三从，搭建完毕后我们还整合了SpringBoot，其实由于springboot的yml配置特性，大大的减少了配置项，如果你使用springmvc，xml中的配置会有很多，而yml中的配置也就2-3行的事。
12. 对于缓存来说，我们还需要预防缓存穿透与雪崩，穿透的话一般来说只需要针对空值缓存就行，过期时间设置5-10分钟，这样就流量就不会打在数据库上导致死机宕机。雪崩其实也可以做到提前预防，那就是用到过期时间的key，时间全部错开，此外，有些数据可以做永久保存的话那就直接保存好了，这样就不会造成大面积的key失效了。
13. 最后有一点还需要说的，就是当一次请求过来，如果查询的key比较多，能做到批量就批量，如果是循环查询缓存的话，一来吞吐量低，而来比较low。