目录
一. Redis配置文件
①可以include引入其他的配置文件组合成一个
②NETWORK
-
bind 0.0.0.0 绑定的IP protected-mode yes 是否是收保护 port 6379 端口号 daemonize yes 是否是守护进程(是否可以后台运行) pidfile /var/run/redis_6379.pid 制定的PID loglevel notice 日志级别,根据级别输出不同的日志 logfile "" 日志的文件路径 databases 16 数据库数量 always-show-logo yes 是否显示logo
③快照 SNAPSHOTTING——> RDB文件
save 900 1 如果在900秒内,有一条数据放生了变化,则会进行持久化
stop-writes-on-bgsave-error yes 如果持久化出错了,是否继续工作
rdbcompression yes 是否需要压缩RDB文件,会消耗CPU的资源
dir ./ rdb文件的保存目录,默认是在当前路径
④主从复制 REPLICATION
⑤安全 SECURITY
requirepass root #设置密码
⑥限制
maxmemory-policy noeviction #最大内存策略
- noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。 大多数写命令都会导致占用更多的内存(有极少数会例外, 如 DEL )。
- allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
- volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
- allkeys-random: 所有key通用; 随机删除一部分 key。
- volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
- volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。
⑦持久化 APPEND ONLY MODE
appendonly no #默认不开启AOF模式
appendfilename "appendonly.aof" #持久化的文件名
# appendfsync always 每次修改都会同步
appendfsync everysec 每隔一秒,同步一次
# appendfsync no 不同步
二. Redis的持久化
Redis是内存数据库,如果不进行持久化,就会丢失
2.1 RDB
Redis的默认持久化方式,会将持久化文件存为一个RDB文件,在恢复至直接用该文件读取到内存
当满足配置快照的触发操作时,Redis就会自动进行RDB文件的快照存储
配置文件中默认的路径是在当前路径,默认的文件名是:dump.rdb
原理:
通过创建一个fork子进程,将内存中的数据写入磁盘。先写入一个临时文件,等持久化完成后,在用这个临时文件替换上一次保存的RDB文件。完成持久化。
整个过程中,主进程是不需要任何IO操作的。比AOF持久化性能高,但是缺点是最后一次持久化的数据可能是丢失的。因为没有出发RDB操作,最新的持久化文件并不是所有的内存集。
使用:
配置文件中修改策略:save 60 5 #表示如果60秒内有5个KEY值被更新,则触发执行RDB,更新dump文件
当执行flushAll时,也会自动生成RDB文件。
Redis关机时SHUTDOWN,也会生成RDB文件,但是kill -9 是不会自动执行RDB文件的
恢复:
将需要恢复的内存数据RDB文件,放在Redis的启动目录,Redis在启动时,会自动监测并执行dump.rdb文件,恢复数据
优点:
对数据的完整性要求不高
适合大量数据的恢复
缺点:
可能会导致最后一次修改的数据修饰
fork子进程需要占用一定的内存空间
2.2 AOF
以日志的形式记录每个写操作。
AOF的持久化备份是将Redis执行的的所有指令记录下来(读指令不记录),只许追加文件不可以改写文件,Redis启动的时候,会将AOF的持久化文件执行一次,也就是会将所有的指令从头到尾执行一遍。如果数据量很大,则执行起来将会比较耗时。
当文件达到默认值(64m配置文件中的)后,会进行重写操作,像RDB一样,fork一个进程,临时文件的方式重写AOF文件。
开启使用:
将配置文件中的appendonly yes 修改为YES就可以启用AOF的持久化功能了。
可以设置一些记录规则,此时AOF功能就启动了
此时启动Redis服务后,就会发现
如果AOF文件被损坏或者有错误,Redis启动会失败。此时就需要用Redis-check-aof工具来完成Redis的修复
redis-check-aof --fix appendonly.aof
优点和缺点
- 如果每次命令都同步的话,能够保证数据的完整性,但是会损失性能
- 相比于RDB,AOF文件大得多,而且执行恢复的效率也比RDB文件差
三. Redis的订阅发布
Redis支持类似MQ一样的发布订阅功能。Redis提供一个队列存储消息,生产者将消息发布,多个订阅了该channel的消费者都会受到消息,Redis也可以像MQ一样,订阅能够匹配通配符的概念,例如:msg.* 就能够接受到msg.*所有channel的消息了
原理:
Redis维护了一个字典,该字典的内容就是所有的channel,每一个channel都存放了一个链表,链表的内容就是所有订阅该channel的客户端。生产者将消息发布时,存放在channel中,然后循环发送到每一个客户端。完成发布订阅功能。
应用:
实时消息、聊天室、订阅、关注系统等。
四. Redis集群的搭建
4.1 主从复制
Redis的主从复制就是一个master节点,多个slave节点。master节点负责写入数据,slave节点负责读取数据
4.1.1 为何要搭建主从复制
- 一台Redis服务器是存在性能瓶颈的。搭建主从复制模式后,可以在多台Redis上通过负载均衡策略实现多台服务器提供读取。减少了压力。
- 一般主从复制也是一种持久化的方式,将某一台slave节点服务器配置持久化策略,一般用的是RDB持久化。
- 如果只有一台Redis的话,很有可能会发生单点故障,配置主从模式,能够保证Redis的高可用性,如果master节点Redis宕机后,可以通过切换节点的方式,完成主从切换。
4.1.2 搭建配置
不需要特意设置master节点,因为默认就是master,只需要修改为salve即可。
设置了主从模式后,默认主节点可以写,slave节点执行写入会报错。并且默认slave会自动复制主节点的全部信息
查询Redis的主从节点信息:info replication
搭建主从模式的Redis:可以在一台服务器搭建多个Redis服务,或者在多台服务器搭建多个Redis:
默认Redis服务启动就是master,所以只需要将需要设置的salve进行修改即可。
- 首先启动多个Redis服务
- 启动客户端后,通过命令:SLAVEOF host port #直接将当前的Redis服务设置为该IP的slave节点,但是是临时的。(如果master服务器有密码的话,则需要在配置文件中将:masterauth 123456 密码添加一下就好了),服务重启后,主节点连接会消失
- 通过修改配置文件的方式,将Redis设置为slave:此方式为永久的
在需要进行设置为salve节点的Redis服务配置文件REPLICATION模块中,修改如下内容:
①replicaof 124.71.112.168 6379
②masterauth root
完成!启动Redis服务后,就是该服务器的slave节点啦
结果:
4.1.3 复制原理
slave连接上master主节点后,会发送一个同步命令,masterRDB文件传输给salve节点,将master的所有数据进行同步,当master节点数据发生变动时,salve也会同步增量同步
- 全量复制:slave接收到master发送过来的全量数据文件时,将其存盘全量复制到内存中
- 增量复制:master与slave连接后,master会继续将收集到的命令依次传给slave,完成同步。
- salve只要重新连接master, 会一次性完成全量复制,自动执行
4.1.4 手动配置为master
讲一个slave节点手动配置为master节点,可以通过SLAVEOF ONE ONE将当前salve设置为手动的。
但是不会用,会用的是通过哨兵模式自动将salve替换为master节点。
4.2 哨兵模式:主从切换
当master节点故障宕机后,通过策略自动将某个slave节点切换为master节点。从Redis2.8后有了哨兵模式(sentinel),完成主从的自动切换。
哨兵是一个独立的进程
原理:是通过发送命令,等待Redis服务器的响应,监测Redis的实例是否是正常运行。类似于进行心跳检测。
原理剖析:
一般在使用Redis集群时,哨兵进程也会配置多个。用于哨兵之间相互监测以及监测Redis实例的作用:
当某个master节点宕机后,其中多个哨兵无法接收到该实例的响应时。哨兵之间会对slave节点进行一次投票。将票数多的slave节点进行故障转移。设置为master节点。然后通过发布订阅模式,让各个哨兵把新的master节点切换为主机。实现主从自动切换。
如果宕机的实例重新启动后,会默认作为slave从机使用。
使用:
Redis的安装路径中有个redis-sentinel,就是哨兵模式的启动进程文件。同时哨兵的启动需要配置文件:sentinel.conf
如果要配置多个哨兵,就需要在多个Redis实例上启动多个哨兵进程即可
启动: redis-sentinel sentinel.conf
核心配置文件:
1、sentinel monitor <master-name> <ip> <port> <quorum> #配置即可使用
master-name:redis主节点昵称。
ip:redis主机ip。
port:redis主机端口。
quorum:哨兵判断主节点是否发生故障的票数。如果设置为2,表示2个哨兵节点认为主节点发生了故障,一般设置为:哨兵节点数/2+1。
2、sentinel down-after-milliseconds <master-name> <times>
哨兵会定期的向redis节点发送ping命令来判断redis是否可达,若超过指定的times毫秒内还未得到pong回复,则判读该redis不可达。
3、sentinel parallel-syncs <master-name> <nums>
当redis主节点挂了后,哨兵会选出新的master,此时,剩余的slave会向新的master发起同步数据,这个设置表示允许并行同步的slave个数。
4、sentinel failover-timeout <master-name> <times>
进行故障转移时,如果超过设置的times毫秒,表示故障转移失败。
5、sentinel auth-pass <master-name> <password>
如果redis主节点设置了密码,则需要进行这个配置。
简单使用:
编写配置文件sentinel.conf,启动哨兵进程后,主节点宕机,slave节点会自动切换为主节点。切换后,哨兵的配置文件也会自动修改为最新主节点的IP与端口
4.3 springboot中配置Redis的集群读写分离
4.4 缓存穿透与缓存雪崩
- 缓存穿透(无效数据)
缓存穿透就是如果用户请求的数据不存在,缓存中不存在,数据库中也不存在,此处如果有大量的客户端请求发出来。则会穿过缓存直达数据库,导致数据库可能出现的异常崩溃。
解决方案:
- 使用布隆过滤器
- 将空对象添加到缓存
- 缓存雪崩(缓存失效)
热点数据或者大量数据出现缓存过期、Redis宕机,期间大量请求访问,导致缓存不存在,直接击穿访问到了数据库。导致数据库崩溃
解决方案: