Redis扩展

Redis扩展

Redis发布订阅

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

**模型介绍：**消息发布者将消息内容发送到队列中，消息订阅者从队列中获取消息。

命令

测试

订阅端：

127.0.0.1:6379> SUBSCRIBE ztx    #订阅我的频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ztx"
3) (integer) 1

1) "message"
2) "ztx"
3) "hello"

1) "message"
2) "ztx"
3) "time to lunch"

发送端：

127.0.0.1:6379> PUBLISH ztx "hello"
(integer) 1
127.0.0.1:6379> PUBLISH ztx "time to lunch"
(integer) 1
127.0.0.1:6379> 

主从复制

概念

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

主从复制的主要作用：

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务，分担服务器负载。

因为会宕机，所以使用一台redis是万万不能的

环境配置

只配置从库 不配置主库

127.0.0.1:6379> info replication   #查看当前库的信息
# Replication
role:master   #角色
connected_slaves:0  #没有从机
master_replid:41f83498335ce9145c9c6c76174ca7afb20b5e8e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

因为没有多套服务器，所以我使用了在同一服务器下用四套配置文件启动redis 使用cp命令来拷贝配置文件 然后再具体地修改拷贝出来地配置文件

查看redis开启情况

[root@rope bin]# ps -ef|grep redis
root      2228     1  0 12:23 ?        00:00:01 redis-server 127.0.0.1:6379
root      2234     1  0 12:24 ?        00:00:00 redis-server 127.0.0.1:6380
root      2240     1  0 12:24 ?        00:00:00 redis-server 127.0.0.1:6381
root      2270  2146  0 12:42 pts/1    00:00:00 grep --color=auto redis

一主二从

默认情况下，每台Redis服务器都是主节点；一般配置从机

认老大！一主(79)二从(80 81)

127.0.0.1:6381> SLAVEOF 127.0.0.1 6379
OK

细节

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

复制原理

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

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

只要是重新连接到master，一次完全同步将被自动执行。

哨兵模式

自动选举老大

监控主机是否故障，如果故障了根据投票数自动将库转换为主库。

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

缓存穿透与雪崩

缓存穿透

概念

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

解决方案

布隆过滤器

这种数据结构对所有可能查询的参数以hash形式存储，在控制层先进性校验，不符合则丢弃，从而避免了对底层存储结构的查询压力。

缓存击穿

概念

缓存击穿是指一个key非常热点，在不停的扛着大并发，大并发集中于这一点进行访问，当这个key失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。

解决方案

设置热点数据永不过期

加互斥锁

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

缓存雪崩

概念

缓存雪崩是指在某一时段，缓存集中过期失效

解决方案

加redis服务器

降流降级

当缓存集体失效后，通过加锁或者队列来控制数据库写缓存的线程数量

数据预热

这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

概念

缓存雪崩是指在某一时段，缓存集中过期失效

解决方案

加redis服务器

降流降级

当缓存集体失效后，通过加锁或者队列来控制数据库写缓存的线程数量

数据预热

模拟，设置不同的过期时间，让缓存失效时间尽量均匀。