(三)Redi缓存配置,持久化,订阅发布,主从复制和缓存相关问题以及解决

注:笔记整理来源 B站UP主狂神说Java

Redis

Redis.conf详解

启动通过配置文件！
单位：
1k => 1000 bytes
#1kb => 1024 bytes
#1m => 1000000 bytes
1mb => 10241024 bytes
1g => 1000000000 bytes
1gb => 10241024*1024 bytes

#units are case insensitive so 1GB 1Gb 1gB are all the same.
１．配置文件,unit单位对大小写不敏感

包含 就好比Spring的Import ,include
#include /path/to/local.conf
 include /path/to/other.conf

2.网络配置

//绑定的IP
bind 127.0.0.1
//保护模式
 protected-mode yes
//端口号设置
port 6379

3.通用配置

//以守护进程的方式运行，默认是no,需要手动开启为yes
daemonize yes

//如果以后台方式运行，就需要指定一个pid文件
pidfile /var/run/redis_6379.pid

//日志

#Specify the server verbosity level.
 This can be one of:
#debug (a lot of information, useful for development/testing)
 verbose (many rarely useful info, but not a mess like the debug level)
#notice (moderately verbose, what you want in production probably) 生产环境
 warning (only very important / critical messages are logged)
loglevel notice
logfile ""  //日志的文件位置名

//数据库的数量

databases 16

//是否显示logo

always-show-logo yes

4.快照
持久化，在规定的时间内，执行了多少次操作，则会持久化到文件 .rdb文件　.aof文件
redis是内存数据库，如果没有持久化，那么数据断电即失去

save 900 1    //如果900s内，至少有1个key进行修改，就进行持久化操作
save 300 10     //如果300s内，至少有10个key进行修改，就进行持久化操作
save 60 10000     //如果60s内，至少有10000个key进行修改，就进行持久化操作
以后会自定义这个进行测试！

//持久化出错，是否继续工作
 stop-writes-on-bgsave-error yes

//是否压缩rdb文件,需要消耗cpu资源
rdbcompression yes

//保存rdb文件的时候，进行错误的校验
rdbchecksum yes

//rdb文件保存的目录
dir ./

5.REPLICATION复制(主从复制)

#replicaof <masterip> <masterport>
replicaof<127.0.0.1><6379>

6.SECURITY安全

可以设置redis的密码，默认没有密码．
127.0.0.1:6379> config get requirepass   获取redis密码
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "123"　设置redis密码
OK
127.0.0.1:6379> ping
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth 123     使用密码进行登录
OK
127.0.0.1:6379> ping
PONG
设置完密码需要重启客户端.

7.限制 CLIENTS客户端

#maxclients 10000   最大连接数
#maxmemory <bytes>   最大内存设置
#maxmemory-policy noeviction   内存达到最大的处理策略
         1. volatile-lru :只对设置了过期时间的key进行LRU(默认值)
         2.allkeys-lru :删除lru算法的key
         3.volatile-random :随机删除即将过期的key
         4.allkeys-random :随机删除
         5.volatile-ttl :删除即将过期的
         6.noeviction : 永不过期，报错

8.APPEND ONLY MODE． aof配置

appendonly no //默认不开启aof模式(默认使用rdb方式持久化，大部分情况rdb够用)

appendfilename "appendonly.aof"   文件名(rdb文件的是 .rdb)

#appendfsync always　每次修改，都会sync(消耗性能)
appendfsync everysec 　每秒执行一次sync,可能会丢失这1s的数据
#appendfsync no   不执行同步，这时候操作系统自己同步数据，速度最快
具体在AOF持久化中解释

！

Redis持久化

Redis是内存数据库，如果不将内存的数据库状态保存到磁盘，一旦服务器退出，服务器的数据库状态也会消失．所以redis提供了持久化．

RDB(Redis DataBase)

在指定时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，恢复的时候将快照文件直接读到内存中.
Redis会单独创建(fork)一个子进程来进行持久化，会将数据先写入到一个临时文件，待持久化过程结束了，在用这个临时文件替换上次持久化好的文件．主进程不需要进行任何的IO操作，就保证了极高的性能．
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是很敏感，那么RDB方式比AOF方式更加高效.RDB的缺点是最后一次持久化后的数据可能会丢失(服务器断线).默认使用RDB.
　　rdb保存的文件就是　dump.rdb文件
在这里插入图片描述
有时候需要对dump.rdb文件进行备份！

测试：
save 60 5　　　60秒内保存5次，就会触发rdb操作

RDB触发机制：
1.save的规则满足情况下，会自动触发rdb规则
2.执行flushall命令，也会触发rdb规则
3.退出redis,也会触发rdb规则
备份就自动生成一个dump.rdb文件

如何恢复rdb文件
1.只需要将rdb文件放在redis启动目录(配置文件中配置的rdb目录文件),redis启动时会自动检查dump.rdb，恢复其中的数据．
2.查看需要存在的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"   //如果在这个目录下存在dump.rdb文件，启动时就会自动扫描，恢复数据

优缺点
优点：
１．适合大规模数据的恢复！
２．如果对数据完整性要求不高！可以使用
缺点：
１．需要一定的时间间隔！redis如果意外宕机，这个最后一次修改数据就没了！
２．fork进程会占用内存空间！

AOF(Append Only File)

AOF: 将所有执行的命令都记录下来，history,恢复的时候就把这个文件内容全部在执行一遍．

以日志的形式来记录每个写操作，将redis执行过的所有指令记录下来(读操作不记录)，只需追加文件，不可以改写文件，
redis启动之初会将文件的全部命令执行一遍来构建数据，就是redis重启的话就根据日志文件的内容将写指令执行一次以
完成数据的恢复工作．
AOF保存的文件: appendfilename “appendonly.aof”
在这里插入图片描述
appendonly no //默认不开启，需要手动设置为yes

appendsync always 每次都修改
appendsync everysec 每秒修改
appendsync no 不修改

使用AOF的时候，只需要将appendonly 的值设置为yes 即可．
如果aof文件有错误，redis是启动不起来的！需要修复aof文件: redis-check-aof --fix 文件

优点和缺点
优点:
１．每一次修改都同步，文件的完整性会更好！
２．每秒同步一次，可能会丢失一秒的数据！
３．从不同步：效率最高！

缺点:
１．相对于数据文件来说（内存占用高），aof远远大于rdb,恢复的速度也比rdb慢
２．aof运行效率比rdb慢，所以redis默认为rdb.

扩展：

１．RDB持久化方式能够在指定的时间间隔内对内存的数据进行存储快照
２．AOF持久化操作记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使AOF文件的体积不至于过大．
３．只做缓存，如果只希望数据在服务器运行的时候存在，可以不用持久化４．同时开启两种持久化方式
－在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整．
－RDB的数据不实时，同时使用两者时重启服务器也只会去找AOF文件，那要不要只使用AOF呢？不！　　因为RDB更适合于备份数据库(AOF在不断变化不好备份)，快速重启，而且也不会有AOF可能潜在的Bug.
５．性能建议
－因为RDB文件只用做备用，建议在Slave上持久化RDB文件，而且只要15分钟备份一次即可,只保留save 900 1(15分钟 1次操作就备份)这条规则
－如果是Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒的数据，启动时只需要load自己的AOF文件．代价一：带来了持续的IO
代价二：AOF　rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的．只要硬盘许可，应尽量减少AOF　rewrite的频率，AOF重写的基础大小默认为64M,太小，可以设为5G以上．
－如果不Enable AOF,紧靠Master-Slave Repllcation实现高可用性也可以，能节省一大笔IO,也减少了rewrite时带来的系统波动．代价是如果Master-slave同时宕机，会丢失十几分钟的数据，启动时也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构．

Redis实现订阅发布

Redis发布订阅(pub/sub) 是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息.(微博，微信)
Redis客户端可以订阅任意数量的频道．
订阅/发布消息图：

第一个角色：消息发送者　二：公共频道　三：消息订阅者

下图展示了频道 channel1 ，以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：
在这里插入图片描述
当有新消息通过 PUBLISH 命令发送给频道 channel1 时，这个消息就会被发送给订阅它的三个客户端：

Redis 发布订阅命令

下表列出了 redis 发布订阅常用命令：


1	PSUBSCRIBE pattern [pattern …] 订阅一个或多个符合给定模式的频道。
2	PUBSUB subcommand [argument [argument …]] 查看订阅与发布系统状态。
3	PUBLISH channel message 将信息发送到指定的频道。
4	PUNSUBSCRIBE [pattern [pattern …]] 退订所有给定模式的频道。
5	SUBSCRIBE channel [channel …] 订阅给定的一个或多个频道的信息。
6	UNSUBSCRIBE [channel [channel …]] 指退订给定的频道。

案例：
订阅端:

redis 127.0.0.1:6379> SUBSCRIBE redisChat　　　订阅一个频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redisChat"
3) (integer) 1
//等待消息的推送
1) "message"　　//消息
2) "redisChat"     //频道
3) "Redis is a great caching technique" //内容
1) "message"
2) "redisChat"
3) "Learn redis by runoob.com"

发布端:

redis 127.0.0.1:6379> PUBLISH redisChat "Redis is a great caching technique"
(integer) 1
redis 127.0.0.1:6379> PUBLISH redisChat "Learn redis by runoob.com"
(integer) 1

Redis发布订阅使用场景：
１．实时消息系统！
２．实时聊天（频道当做聊天室，将信息回写给所有人）
３．订阅，关注系统！
稍微复杂的场景：　消息中间件

Redis主从复制

主从复制是指将一台Redis服务器的数据，复制到其他Redis服务器．前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单向的，只能由主节点到从节点．Master以写为主，Slave以读为主.

默认情况下,每台Redis服务器都是主节点，且一个主节点可以有多个从节点(或者没有),但一个从节点只能有一个主节点．

主从复制的作用包括：
１．数据冗余:主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式．
２．故障恢复:当主节点出现问题，可以由从节点提供服务，实现快速的故障恢复，是一种服务的冗余
３．负载均衡:在主从辅助的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务，分担服务器负载，可以提高服务器并发量．
４．高可用基石:主从复制还是哨兵和集群能够实现的基础，因此说主从复制是redis高可用的基础．

一般而言，将Redis运用项目工程中，一台Redis是万万不能的（会宕机）
１．从结构：单个Redis服务器会发生单点故障，并且一台服务器需要处理的请求负载，压力较大
２．从容量：单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G,也不能将所有内存用作Redis存储内存．(一般单台Redis最大使用内存不超过20G)
一般对数据的操作都是读多写少，所以采用主从复制(一主(主服务器用来写)二从(从服务器用来读))

环境配置：
只配置从库，不用配置主库！(Redis默认就是主库)

查看当前库的信息: info replication

#Replication
role:master   角色 master
connected_slave:0   连接的从机
master_replid:   
master_replid2:
master_repl_offset:0
master_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

复制三个redis.conf ,从服务器配置文件需要修改:port ,pidfile ,logfile, dump.rdb文件!

一主(6379)二从(6380,6381):
从机1配置:

127.0.0.1:6380> slaveof host(127.0.0.1)   port(6379)
127.0.0.1:6380> info replication
#Replication role:slave master_host:127.0.0.1 master_port:6379
.....

从机2配置:

127.0.0.1:6381> slaveof host(127.0.0.1)   port(6379)
127.0.0.1:6381> info replication
#Replication
role:slave
master_host:127.0.0.1
master_port:6379
.....

真实的主从配置应该在配置文件中配置，这样的话就是永久的．

#replicaof <masterip> <masterport>
replicaof<127.0.0.1><6379>

细节：

主机可以写，从机不可以写，只能读！　主机中的所有信息和数据都会被从机保存

测试：主机断开连接，从机依旧连接到主机，但是没有写操作了(主机down机)，如果主机回来了，从机依旧可以获取到主机写的东西．(高可用性)

如果使用命令行配置的从机，这时候从机断开连接，从机就会变回主机！只要再次变为从机，数据立马可以得到！
复制原理:
Slave启动成功连接到master后会发送一个sync命令，Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕后，master将传送整个数据文件到slave,并完成一次完全同步！
－全量复制：
而Slave服务在接收到数据库文件数据后，将其存盘并加载到内存中．
－增值复制：
Master继续将新的所收集到的修改命令依次传给slave，完成同步，但是只要是重新连接master,一次完全同步(全量复制)将被自动执行.

Slaveof no one:将从机设置为主机
如果主机断开了连接，可以用Slaveof no one 命令让自己变成主机！这个时候之前断开的主机恢复了，只能重新配置，设置从机．

Redis哨兵模式(公司所有的集群都用哨兵模式)

在主从中自动选举主机．
主从切换技术的方法:当主服务器宕机后，需要手动将从服务器转换为主服务器，人工干预，费时费力，还会造成一段时间内服务不可用．　所以就出现了哨兵模式！
哨兵模式：能够后台监控主机是否故障，如果故障了根据投票数自动将从机设置为主机！
　　是一种特殊的模式，Redis提供了哨兵的命令，哨兵是一个独立的进程．
原理：哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例！
在这里插入图片描述

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

测试：
１．配置哨兵配置文件 sentinel.conf

  #sentinel monitor 被监控的名称  IP地址  端口号  1(数字代表如果主机挂了，slave投票看谁接替成为主机)

sentinel monitor myredis 127.0.0.1 6379
２．启动哨兵！

   redis-sentinel config/sentinel.conf

当主机宕机之后，哨兵会投票选出新主机，当原先主机重新连接，此时原先的主机就会在哨兵模式的操作下，变为新主机的从机！！

哨兵模式的全部配置：
基础配置：

protected-mode no       #关闭保护模式                                                                                                 
port 26479                    #端口                                                                                           
daemonize yes             #使用后台模式启动                                                                                               
pidfile "/var/run/redis-sentinel_26479.pid"                       #进程id文件                                                       
logfile "/usr/local/redis/sentinel/sentinel_26479.log"           #日志文件                                                        
dir "/usr/local/redis/sentinel" 　　　　　　　　　　　　　　#工作目录

核心配置：

sentinel monitor <master-name> <ip> <redis-port> <quorum> 
告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效

sentinel auth-pass <master-name> <password>
 设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。
 
sentinel down-after-milliseconds <master-name> <milliseconds> 
这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒 

sentinel parallel-syncs <master-name> <numslaves> 
 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 
 
sentinel failover-timeout <master-name> <milliseconds> failover-timeout 可以用在以下这些方面：     
	1. 同一个sentinel对同一个master两次failover之间的间隔时间。  
	2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。   
	3.当想要取消一个正在进行的failover所需要的时间。   
	4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。

优点：
１．哨兵集群，基于主从复制模式，所有的主从配置优点全有
２．主从可以切换，故障可以转移，系统的可用性增强
３．哨兵模式就是主从模式的升级，手动到自动，更加健壮！

缺点：
１．Redis不好在线扩容，集群容量一旦达到上限，在线扩容就十分复杂！
２．实现哨兵模式的配置是很麻烦的！里面有很多选择！

缓存穿透及解决方案(本身应在缓存中查询，但查不到数据，缓存被穿透，最后全部到数据库查询)

缓存穿透：key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。
解决：
方案一：采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
方案二：更为简单粗暴的方法。如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
存在的问题：
１．如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为当中有很多空值的键．
２．即使对空值设置了过期时间，还是会存在缓存层和储存层的数据有一段时间窗口的不一致，这对于需要保证一致性的业务有影响．

缓存击穿及解决方案(量太大，缓存过期！)

缓存击穿：key对应的数据存在，但在redis中过期，(key失效的瞬间)此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决：
１．设置热点数据永不过期．
２．加互斥锁：使用分布式锁，保证对于每个key同时只能有一个线程去查询后端服务，其他线程没有获得锁的权限，需要等待．这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大．

缓存雪崩及解决方案 (一个地方崩全局崩)

缓存雪崩：当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。 Redis宕机

解决方案：
１．Redis高可用：既然Redis可能会挂掉，那多设几台Redis，一台挂了，其他几台还可以工作．（异地多活）
２．限流降级：在缓存失效后，通过加锁或者阻塞队列来控制读数据库写缓存的线程数量，比如对某个key只允许一个线程查询数据和写缓存，其他线程进行等待．
３．数据预热：在正式部署之前，先把可能用到的数据先访问一遍，这样部分数据就会加载到缓存中，在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间，让缓存失效的时间点尽量均匀．