redis哨兵、集群、缓存穿透、击穿、雪崩

redis哨兵、集群、缓存穿透、击穿、雪崩

1 redis 哨兵

#主从复制存在的问题：
-1 主从复制，主节点发生故障，需要做故障转移，可以手动转移：让其中一个slave变成master
	-哨兵---》高可用，一旦主库挂掉，从库变为主库，自动做
-2 主从复制，只能主写数据，所以写能力和存储能力有限
	-集群---》分散存储
    
    
# 高可用--哨兵原理
    1 多个sentinel发现并确认master有问题
    2 选举触一个sentinel作为领导
    3 选取一个slave作为新的master
    4 通知其余slave成为新的master的slave
    5 通知客户端主从变化
    6 等待老的master复活成为新master的slave
    
    
# 哨兵类似于一个redis服务，要监听端口，有配置文件，也可以被客户端链接
# 配置文件 建在redis目录下
port 26379  #端口：26379
daemonize yes #否要用守护线程的方式启动。默认no
dir data #rdb文件存在当前目录，多个哨兵不能放在一个目录
protected-mode no #有没有密码
bind 0.0.0.0 #不写监听127.0.0.1  0.0.0.0任意地址都可访问
logfile "redis_sentinel_26379.log" #日志文件

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

# sentinel monitor <master-name> <ip> <redis-port> <quorum>
告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时（一般一半+1），master才算真正失效
    
# 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所配置的规则来了。





#### 高可用架构的搭建步骤
# 已经搭建好了一主两从的架构
# 编辑3个哨兵配置文件
port 26379
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel_26379.log"

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000


#第二个
port 26380
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel_26380.log"
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

## 第三个配置文件
port 26381
daemonize yes
dir data
protected-mode no
bind 0.0.0.0
logfile "redis_sentinel_26381.log"

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000

# 使用配置文件启动哨兵
./src/redis-sentinel sentinel_26379.conf
./src/redis-sentinel sentinel_26380.conf
./src/redis-sentinel sentinel_26381.conf


###停掉主，会自动切换
info


#python连接
import redis
from redis.sentinel import Sentinel

# 连接哨兵服务器(主机名也可以用域名)

#连接的是哨兵的地址
sentinel = Sentinel([('10.0.0.101', 26379),
                     ('10.0.0.101', 26380),
                     ('10.0.0.101', 26381)
		     ],
                    socket_timeout=5)

print(sentinel)
# 获取主服务器地址
# 去找名字为mymaster的master
master = sentinel.discover_master('mymaster')
print(master)

# 获取从服务器地址
slave = sentinel.discover_slaves('mymaster')
print(slave)



##### 读写分离
# 获取主服务器进行写入
# master = sentinel.master_for('mymaster', socket_timeout=0.5)
# w_ret = master.set('foo', 'bar')

# slave = sentinel.slave_for('mymaster', socket_timeout=0.5)
# r_ret = slave.get('foo')
# print(r_ret)

2 redis 集群

# 集群分区方案
	-顺序分区：数据分散度容易倾斜，顺序访问，批量操作，关系型数据库经常使用此方式
    -哈希分区：无法顺序访问，分散度高不宜倾斜
    	-节点取余 ：推荐翻倍扩容，缩容
        -一致性hash ：顺时针，优化取余
        -虚拟槽--->redis集群--》16384个槽
        
        
# redis集群原理
假设5个节点，把16384个槽平均分配到每个节点，客户端会把数据发送给任意一个节点，通过CRC16对key进行哈希对16383进行取余，算出当前key属于哪部分槽，属于哪个节点，每个节点都会记录是不是负责这部分槽，如果是负责的，进行保存，如果槽不在自己范围内，redis cluster是共享消息的模式，它知道哪个节点负责哪些槽，返回结果，让客户端找对应的节点去存
服务端管理节点，槽，关系




#redis集群架构过程
先要有节点
meet 相互通信
指派槽
数据复制
高可用（节点挂掉，从节点顶上）


#配置开启节点
# 1 配置
port ${port}
daemonize yes
dir "/opt/redis/redis/data/"
logfile "${port}.log"

#masterauth  集群搭建时，主的密码
cluster-enabled yes  # 开启cluster
cluster-node-timeout 15000 # 故障转移，超时时间 15s
cluster-config-file nodes-${port}.conf  # 给cluster节点增加一个自己的配置文件
cluster-require-full-coverage no  #只要集群中有一个故障了，整个就不对外提供服务了，这个实际不合理，假设有50个节点，一个节点故障了，所有不提供服务了；，需要设置成no,必须设置从库

2.1 搭建

vim redis_7000.conf
port 7000
daemonize yes
dir "/root/s19/redis-5.0.7/data"
logfile "7000.log"
dbfilename "dump-7000.rdb"
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-require-full-coverage yes



# 快速生成其他配置
sed 's/7000/7001/g' redis-7000.conf > redis-7001.conf
sed 's/7000/7002/g' redis-7000.conf > redis-7002.conf
sed 's/7000/7003/g' redis-7000.conf > redis-7003.conf
sed 's/7000/7004/g' redis-7000.conf > redis-7004.conf
sed 's/7000/7005/g' redis-7000.conf > redis-7005.conf

# 启动6个节点
./src/redis-server ./redis-7000.conf
ps -ef |grep redis
./src/redis-server ./redis-7001.conf
./src/redis-server ./redis-7002.conf
./src/redis-server ./redis-7003.conf
./src/redis-server ./redis-7004.conf
./src/redis-server ./redis-7005.conf


## 客户端链接上的命令：
cluster nodes 
cluster info:

# 快速搭建集群
redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
                        
                        
                        
                        
## 集群扩容
sed 's/7000/7006/g' redis-7000.conf > redis-7006.conf
sed 's/7000/7007/g' redis-7000.conf > redis-7007.conf
./src/redis-server ./redis-7006.conf
./src/redis-server ./redis-7007.conf


### 方式一
在7000上执行
redis-cli -p 7000 cluster meet 127.0.0.1 7006
redis-cli -p 7000 cluster meet 127.0.0.1 7007
### 方式二
redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000

# 让7007做为7006的从
redis-cli -p 7007 cluster replicate 0ee8ebaede3a3f65de57c8443082547d3efd55d8


#分槽
./src/redis-cli --cluster reshard 127.0.0.1:7000
    
    
    
    
    
# 缩容

# 下线迁槽（把7006的1366个槽迁移到7000上）
redis-cli --cluster reshard --cluster-from 0ee8ebaede3a3f65de57c8443082547d3efd55d8 --cluster-to 24a7ff58d9ce9ca3d9d44874a9d83784bcac639e --cluster-slots 1366 127.0.0.1:7000
yes

redis-cli --cluster reshard --cluster-from 0ee8ebaede3a3f65de57c8443082547d3efd55d8 --cluster-to 8bffd1758091236005a09fe695435154ccefe74d --cluster-slots 1366 127.0.0.1:7005
yes
redis-cli --cluster reshard --cluster-from 0ee8ebaede3a3f65de57c8443082547d3efd55d8 --cluster-to 0a122d418d6386c4ef1f6b6ea69e5c967adaf0da --cluster-slots 1365 127.0.0.1:7002
yes
# 忘记节点，关闭节点
redis-cli --cluster del-node 127.0.0.1:7000 a44672ed51398e19f746646ffccb726a2d4fa914  # 先下从，再下主，因为先下主会触发故障转移
redis-cli --cluster del-node 127.0.0.1:7000 0ee8ebaede3a3f65de57c8443082547d3efd55d8
# 

# 关掉其中一个主，另一个从立马变成主顶上， 重启停止的主，发现变成了从

3 缓存优化和使用

# 双写一致性 mysql和redis数据是否一致
	-定时更新
    -增数据删缓存
    -增数据改缓存 
# 缓存更新策略 LRU（没有被使用时间最长的） 、LFU（一定时间内使用最少的）、FIFO（先进先出）
	-LRU -Least Recently Used,没有被使用时间最长的
    	># LRU配置
        >maxmemory-policy:volatile-lru
        >（1）noeviction: 如果内存使用达到了maxmemory，client还要继续写入数据，那么就直接报错给客户端
        >（2）allkeys-lru: 就是我们常说的LRU算法，移除掉最近最少使用的那些keys对应的数据，ps最长用的策略
        >（3）volatile-lru: 也是采取LRU算法，但是仅仅针对那些设置了指定存活时间（TTL）的key才会清理掉
        >（4）allkeys-random: 随机选择一些key来删除掉
        >（5）volatile-random: 随机选择一些设置了TTL的key来删除掉
        >（6）volatile-ttl: 移除掉部分keys，选择那些TTL时间比较短的keys
    -LFU -Least Frequenty User,一定时间段内使用次数最少的
    ># LFU配置 Redis4.0之后为maxmemory_policy淘汰策略添加了两个LFU模式：
    >volatile-lfu：对有过期时间的key采用LFU淘汰算法
    >allkeys-lfu：对全部key采用LFU淘汰算法
    ># 还有2个配置可以调整LFU算法：
    >lfu-log-factor 10
    >lfu-decay-time 1
    ># lfu-log-factor可以调整计数器counter的增长速度，lfu-log-factor越大，counter增长的越慢。
    ># lfu-decay-time是一个以分钟为单位的数值，可以调整counter的减少速度
        -FIFO -First In First Out
    -LIRS (Low Inter-reference Recency Set)是一个页替换算法，相比于LRU(Least Recently Used)和很多其他的替换算法，LIRS具有较高的性能。这是通过使用两次访问同一页之间的距离（本距离指中间被访问了多少非重复块）作为一种尺度去动态地将访问页排序，从而去做一个替换的选择
    
     
    
    

###  缓存穿透
#描述：
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
#解决方案：
1 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
3 通过布隆过滤器实现 查询的id放在布隆过滤器 有就继续往后走，没有就返回


### 缓存击穿
#描述：
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力
#解决方案：
设置热点数据永远不过期。

 
### 缓存雪崩
#描述：
缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
# 解决方案：
1 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
3 设置热点数据永远不过期。