Redis-03

订阅发布

主从复制

概念:
	将一台 Redis 服务器的数据,复制到其他 Redis 服务器. 
	前者称为主节点(master/leader)  --> 以写为主
	后者称为从节点(slave/follower) --> 以读为主
	数据复制是单向的,只能从主节点到从节点.
作用:
	数据冗余 : 实现数据的备份
	故障恢复 : 主节点出现问题,由从节点替代,实现快速恢复
	负载均衡 : 主节点(master/leader)  --> 以写为主 从节点(slave/follower) --> 以读为主
	高可用基石 : 哨兵和集群配置的基础

配置

命令方式

# 主机不用配置

# 查看当前库的信息
info replication
role:master 		# 主机
connected_slaves:0   # 从机数量

# 修改配置文件 保证不和其他 Redis 服务器端口文件等同名
port 6380
pidfile /var/run/redis_6380.pid
logfile "6380"
dbfilename dump6380.rdb

# 开启 Redis 服务器

# 主从配置 命令方式 临时的
192.168.182.132:6380> slaveof 192.168.182.132 6379
192.168.182.132:6381> slaveof 192.168.182.132 6379

# 检查
# 6379
192.168.182.132:6379> info replication
role:master
connected_slaves:2
slave0:ip=192.168.182.132,port=6380,state=online,offset=182,lag=0
slave1:ip=192.168.182.132,port=6381,state=online,offset=182,lag=0
# 6381
192.168.182.132:6381> info replication
role:slave
master_host:192.168.182.132
master_port:6379
# 6380
192.168.182.132:6380> info replication
role:slave
master_host:192.168.182.132
master_port:6379

配置文件

# 主机地址端口 永久配置
replicaof <masterip> <masterport>
# 主机密码
masterauth <master-password>

细节

主机一旦发生增删改操作，那么从机会自动将数据同步到从机中
主机可以写,从机只能读
复制原理
    当从库和主库建立MS(master slaver)关系后，会向主数据库发送SYNC命令
    主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来
    快照完成后,主Redis会将快照文件和所有缓存的写命令发送给从Redis； 从Redis接收到后，会载入快照文件并且执行收
    到的缓存命令；
    主Redis每当接收到写命令时就会将命令发送从Redis，保证数据的一致；【内部完成,所以不支持客户端在从机人为写数
    据。】

主机宕机

# 从机执行语句 自己变成主节点
SLAVEOF NO ONE

哨兵模式

哨兵作为进程 监视所有 Redis 服务
主机宕机,自动切换主机

配置

# 创建 sentinel.conf 文件 并进行修改
# 在配置中输入 sentinel monitor mastername 内网IP(192.168.182.132) 6379 1
# mastername --> 监控主数据的名称，自定义
# 127.0.0.1 --> 监控主数据库的IP;
# 6379 --> 端口
# 1 --> 最低通过票数
sentinel monitor myMaster 192.168.182.132 6379 1 

# 启动
[root@localhost redis]# ./bin/redis-sentinel ./sentinel.conf 
6248:X 18 Sep 2020 03:04:58.585 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
6248:X 18 Sep 2020 03:04:58.585 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=6248, just started
6248:X 18 Sep 2020 03:04:58.585 # Configuration loaded
6248:X 18 Sep 2020 03:04:58.587 * Increased maximum number of open files to 10032 (it was originally set to 1024).
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 5.0.9 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 6248
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

6248:X 18 Sep 2020 03:04:58.591 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
6248:X 18 Sep 2020 03:04:58.593 # Sentinel ID is 6fe5b2e78cb8a202cdcbd96b5325ca13ce94477b
6248:X 18 Sep 2020 03:04:58.594 # +monitor master myMaster 192.168.182.132 6379 quorum 1 主机
6248:X 18 Sep 2020 03:04:58.596 * +slave slave 192.168.182.132:6381 192.168.182.132 6381 @ myMaster 192.168.182.132 6379 # 从机
6248:X 18 Sep 2020 03:04:58.600 * +slave slave 192.168.182.132:6380 192.168.182.132 6380 @ myMaster 192.168.182.132 6379 # 从机

# 杀死主机 
kill -9 3478
# 哨兵变化
6248:X 18 Sep 2020 03:10:03.810 * +slave slave 192.168.182.132:6380 192.168.182.132 6380 @ myMaster 192.168.182.132 6381 # 主机 6381
6248:X 18 Sep 2020 03:10:03.810 * +slave slave 192.168.182.132:6379 192.168.182.132 6379 @ myMaster 192.168.182.132 6381 # 主机 6381
6248:X 18 Sep 2020 03:10:33.814 # +sdown slave 192.168.182.132:6379 192.168.182.132 6379 @ myMaster 192.168.182.132 6381

# 主机恢复后只能成为从机

优缺点

优点：
    1、哨兵集群，基于主从复制模式，所有的主从配置优点，它都有
    2、主从可以切换，故障可以转移，高可用性的系统
    3、哨兵模式就是主从模式的升级，手动到自动，更加健壮
缺点：
	1、Redis不好在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦
	2、哨兵模式的配置繁琐

缓存穿透和雪崩

缓存雪崩(缓存失效)

缓存雪崩通俗简单的理解就是：由于原有缓存失效（或者数据未加载到缓存中），新缓存未到期间（缓存正常从Redis中获取）所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机，造成系统的崩溃。

解决方案: 
	在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查
	询数据和写缓存，其他线程等待。虽然能够在一定的程度上缓解了数据库的压力但是与此同时又降低了系
	统的吞吐量。
	
	分析用户的行为，不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

缓存穿透(找不到)

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中
找不到，每次都要去数据库再查询一遍，然后返回空。这样请求就绕过缓存直接查数据库，这也是经常提的缓
存命中率问题。解决方案: 

	1.如果查询数据库也为空，直接设置一个默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不 
	会继续访问数据库，这种办法最简单粗暴。 

	2.把空结果，也给缓存起来，这样下次同样的请求就可以直接返回空了，既可以避免当查询的值为空时 
	引起的缓存穿透。同时也可以单独设置个缓存区域存储空值，对要查询的key进行预先校验，然后再放 
	行给后面的正常缓存处理逻辑。 

注意：再给对应的ip存放真值的时候，需要先清除对应的之前的空缓存。 

缓存击穿(次数太多)

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。 

热点key
	某个key访问非常频繁，当key失效的时候有大量线程来构建缓存，导致负载增加，系统崩溃。 

解决办法： 
	使用锁，单机用synchronized,lock等，分布式用分布式锁。 

	缓存过期时间不设置，而是设置在key对应的value里。如果检测到存的时间超过过期时间则异步更新 
	缓存。