Redis(03)发布订阅&主从复制&缓存穿透和雪崩

本文主要是介绍Redis(03)发布订阅&主从复制&缓存穿透和雪崩，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

发布订阅模式 

主从复制:　指一台redis服务器的数据复制到其他的redis服务器, 前者为主节点(master), 后者为从节点(slave),用于数据库的读写分离, master写, slave读(同步master数据)

主从复制的作用: 1.数据冗余　2.故障恢复　3.负载均衡　4.高可用(集群) 

一般情况下, 不能只有一台redis(宕机后数据丢失), 最好是三台以上组成一个集群(一主二从), 原因如下

　　1.从结构上, 单个redis服务器会发送单点故障, 且一台服务器要处理所有请求, 负载压力过大

　　2.从容量上, 单个redis服务器内存有限, 就算有256G的内存也不应该全部作为redis的缓存, 一般redis占用内存不超过 20G

一般的电商网站都是  "读多写少" 因此使用读写分离会大大的减少单个redis的压力

redis集群环境配置(这里是单机开启多个redis一般都是多台机器多个redis)

　　1. 先开启一个redis-server守护进程  再info replication 查看当前服务器的信息, 可以看到, redis服务器默认自己就是主节点, 接着显示从节点的数量

　　2. cp redis6379.conf 复制两份成 redis6380.conf 和 redis6381.conf, 并把其中 80 和 81 的conf文件所绑定的端口更改成对应不同的端口, 生成的日志文件也要命名成 6379.log ,6380.log 和 6381.log,    pidflie进程名称也要分别改名如 /var/run/redis_63**.pid, 和 dbfilename的rdb文件也要改成dump6379.rdb

　　3.开启三连接, 每个连接都开启redis,都选择不同的配置文件,开启服务器后通过redis-cli连接对应端口的redis使用 slaveof [ip] [port] 指定一个服务器为主节点, 然后自身作为从节点, 这里使用命令来配置主从节点只是临时的,当从节点重启后配置恢复默认, 真实情况只有使用配置文件配置这样才会永久

　　4.配置文件配置主从节点:  配置文件中有一个 replication <masterip> <masterport>是注释掉的, 删除#号后, 因为默认本机就是主节点, 所以只需要配置从节点的配置文件就行了, 如果主节点有密码则需要加上 masterauth <master-password>

　　5.配置好主从节点后, 只有主节点能写, 从节点只读,不能写, 当主节点宕机后从节点依旧无法写,当主节点重启恢复后, 从节点依旧连接到指定端口的主节点

复制原理:

　　slave启动成功连接到master后会发送一个sync同步命令

　　master收到命令后, 启动后台的存盘进程, 同时收集所有接受到修改数据的命令, 在后台进程执行完毕之后, master将传送整个数据数据文件到slave,并完成一次同步

　　全量复制:  slave在收到数据文件后, 将其存盘并加载到内存中

　　增量复制:　master继续收集所有修改数据的命令依次传给slave,完成同步

　　只要slave成功连接master,就一定会自动执行一次全量复制

redis哨兵模式

　　如果没有哨兵模式, 主从切换需要手动切换主从,这很费时, 切换过程中还会导致一定时间内服务不可用, 所以redis2.8后正式提供了Sentinel哨兵模式

　　哨兵模式是一种特殊的模式,首先redis提供了哨兵的命令, 哨兵是一个独立的进程, 作为进程,他独立运行, 其原理是哨兵通过发送命令, 等待redis服务器响应, 从而监控运行的多个redis服务器 　redis有个自带的redis-sentinel快速启动方法, 

　　然而单个哨兵进程对redis服务器进行监控, 可能会出现问题, 为此可以使用多个哨兵进行监控,哨兵之间也会互相监控, 这样就形成了多哨兵模式

　　当哨兵监控的master宕机后, 系统并不会马上进行failover过程, 当有两个以上的哨兵都监控不到master的存在后,就会进行对从节点的投票,谁的票数多就会切换成主节点

　　当主节点宕机后,从节点已被哨兵切换成新的主节点, 这时如果主节点重启后,会被哨兵切换成从节点并加入到新的主节点 

　　如何开启哨兵:

　　　　1.配置哨兵配置文件 sentinel.conf , 配置内容 sentinel monitor [被监控名称] hostip port 1, 1代表票数,主机宕机后根据投票算法只投一票给任意从节点

　　　　2.启动哨兵 redis-sentinel [configpath]/sentinel.conf

 redis缓存穿透和雪崩

　　缓存穿透: 用户查询数据会先访问缓存,当缓存查询没有命中则会直接访问到持久化层数据库, 但如果访问持久化层数据库并发量过大,就会对数据库造成很大的压力, 这就称为缓存穿透,　解决方案:　使用布隆过滤器,是一种数据结构, 对所有查询的参数以hash形式存储, 在控制层先进行校验,不符合则丢弃, 从而避免了持久化层的查询压力

　　缓存击穿: 大量用户并发的同时访问一个key, 当key在缓存失效时,持续的大并发会击破缓存,直接请求在数据库上, 可能会导致服务器宕机

　　　　　　   解决方案: 缓存不过期或加互斥锁(当缓存key失效后,只能有一个线程访问该key)

　　缓存雪崩:　指某一时间段缓存集体过期失效, 或 redis宕机,断网, 

　　　　　　　解决方案: redis高可用, 多增设几台redis, 这样一台宕机后其他还可以继续工作

　　　　　　　　　　　  限流降级, 　在缓存失效后通过加锁或者队列开控制写缓存的线程数

　　　　　　　　　　　   数据预热　 在正式部署之前先把部分可能大量访问的数据都先访问一遍, 这样数据就会加载到缓存中

这篇关于Redis(03)发布订阅&主从复制&缓存穿透和雪崩的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！