第四天

内容概要

集群原理及搭建
python操作哨兵
python操作集群
缓存优化

集群原理及搭建

做了读写分离，做了高可用，还存在问题

并发量：单机redis qps为10w/s但是我们可能需要百万级别的并发量
数据量: 机器内存16g--256g，如果存500g数据呢

使用集群解决这个问题

解决：加机器，分布式redis cluster 在2015年的3.0版本加入了。满足分布式的需求

数据库的多机数据分布方案

存在问题

假设全量的数据非常大，500g，单机已经无法满足，我们需要进行分区，分到若干个子集中

主流分区方式(数据分片方式)

哈希分布
顺序分布

哈希分布

原理：100个数据分到3个节点上 1-33第一个节点；

34-66第二个节点；67-100第三个节点(很多关系型数据库使用此种方式)

哈希分区：

原理：hash分区，节点取余，假设3台机器，hash(key)%3,落到不同节点上

节点区域分区：扩容缩容麻烦。移动数据--翻倍扩容

总结：

客户端分片，通过hash+取余节点伸缩，数据节点关系发生变化，导致影响数据迁移过大

迁移数量和添加节点数量有关，建议翻倍扩容
一致性哈希分区

每个节点负责一部分数据，对key进行hash，得到结果在node1和node2之间，就放到node2中，顺时针查找

总结：

客户端分片：hash+顺时针(优化区域)

节点伸缩：只影响临近节点，但是还有数据迁移的情况

伸缩：保证最小迁移数据和无法保证负载均衡(这样总共5个节点，数据就不均匀了)，翻倍扩容可以实现负载均衡
虚拟槽(redis)

预设虚拟槽：每个槽映射一个数据子集，一般比节点数大

良好的哈希函数：CRC16

服务端管理节点、槽、数据：如redis cluster(槽的范围0-16383)

redis使用了虚拟槽

对key进行hash得到数字对16383取余--》就知道这个数据是归那个槽管理的--》节点管理那些槽是知道--》数据存到那个节点就知道了

集群搭建

集群：多台计算机共同组成一套体系来对外提供服务集群

节点：某台机器

meet：节点跟节点之间通过meet通信

指派槽：16384个槽分给几个节点

复制：主从复制

高可用：主节点挂掉，从节点顶上去

 rm -rf data*  删除所有data开头的文件夹
 pkill -9 redis 批量删除服务(删除所有redis服务)

搭建步骤

准备6台机器(6个redis-server进程)

第一步：准备6台机器，写6个配置文件

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

第二步骤：快速复制6个配置文件，并修改配置

sed 's/7000/7001/g' 7000.conf > 7001.conf
sed 's/7000/7002/g' 7000.conf > 7002.conf
sed 's/7000/7003/g' 7000.conf > 7003.conf
sed 's/7000/7004/g' 7000.conf > 7004.conf
sed 's/7000/7005/g' 7000.conf > 7005.conf
sed 's/7000/7006/g' 7000.conf > 7006.conf

第三步启动6个服务

redis-server 7000.conf 
redis-server 7001.conf 
redis-server 7002.conf 
redis-server 7003.conf 
redis-server 7004.conf 
redis-server 7005.conf

第四步：-

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

第五步

redis-cli -p 7000 cluster info   # 详细信息
redis-cli -p 7000 cluster nodes  # 节点信息
redis-cli -p 7000 cluster slots  # 查看槽的信息

现在来，测试是不是高可用

我在7002上，我把7002下了，7003是7002的从，看看是不是可以做主备切换

我去把7002下了

我在去把7002提起来

redis集群扩容

先启动redis服务，然后添加到集群

在集群里面看这两台都是master

然后把其中一台设置为另一台的从。

生成两个redis服务的配置文件，用与启两台不同的reids服务

redis-server 7007.conf
redis-server 7006.conf

添加到集群中

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

进入到集群中查看，是否添加成功
然后设置主从 redis-cli -p 7007 cluster replicate e7ae00c03adcccdebbc70a19c46b1a13d09ddf34
迁移槽

主从设置成功

redis集群缩容

先看要下线得机器上有那些槽

我要下7006，去看7006上有那些槽

身上有这些槽

redis-cli --cluster reshard --cluster-from e7ae00c03adcccdebbc70a19c46b1a13d09ddf34 --cluster-to 51785e04db78eb4c58933f0ae749b7813a85ee46 --cluster-slots 1365 127.0.0.1:7000
    
7006往7000上迁移 1365个槽

redis-cli --cluster reshard --cluster-from e7ae00c03adcccdebbc70a19c46b1a13d09ddf34 --cluster-to ef80b25578e2f82cb2b7a2dd33a7b9181b0a3b72 --cluster-slots 1366 127.0.0.1:7001
7006 往 7001上迁移 1366

redis-cli --cluster reshard --cluster-from e7ae00c03adcccdebbc70a19c46b1a13d09ddf34 --cluster-to 97eb57633fd5f6c7916d6282b16aea78eafb1cbe --cluster-slots 1366 127.0.0.1:7002
7006 往 7002上迁移 1366

查看一下 7006的槽

下线的时候先下从在下主

#第二步：下线节点 忘记节点，关闭节点
redis-cli --cluster del-node 127.0.0.1:7000 296a4098b00e013d2b3a68264ad35e044b7d6d60 # 先下从，再下主，因为先下主会触发故障转移
redis-cli --cluster del-node 127.0.0.1:7000 e7ae00c03adcccdebbc70a19c46b1a13d09ddf34

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

python操作哨兵

高可用架构后--》不能直接连某一个主库了--》主库可能会挂掉，后来他就不是主库了

之前学的连接redis的操作，就用不了了

如果连接不上，可能因为端口没开，或者防火墙没关

import redis
# 普通连接
# conn = redis.Redis("10.0.0.200", 6379)
# a = conn.get("name")
# print(a)
# conn.close()

# 连接哨兵
from redis.sentinel import Sentinel

sentinel = Sentinel([
    ("10.0.0.200", 26379),
    ("10.0.0.200", 26380),
    ("10.0.0.200", 26381),
], socket_timeout=5)

# 获取主服务器的地址
master = sentinel.discover_master("mymaster")
print(master)

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

读写分离

# 读写分离

master1 = sentinel.master_for("mymaster", socket_timeout=0.5)
master1.set("func","nn")

slave1 = sentinel.slave_for("mymaster", socket_timeout=0.5)
a = slave1.get("func")
print(a)

python操作集群

"""
一旦搭建了集群，python操作也变了
rediscluster
pip3 install redis-py-cluster

"""
from rediscluster import RedisCluster
# 配节点的主机就行
startup_nodes = [
    {"host": "10.0.0.200", "port": "7000"},
    {"host": "10.0.0.200", "port": "7001"},
    {"host": "10.0.0.200", "port": "7002"},
]

rc = RedisCluster(startup_nodes=startup_nodes)
rc.set("name", "lqz")
print(rc.get("name"))

缓存优化

redis缓存更新策略

redis本身，内存存储，会出现内存不够用，放数据放不进去，有些策略，删除一部分数据，在放新的
LRU/LFU/FIFO算法剔除：例如maxmemory-policy(到了最大内存，对应的应对策略)

LRU -Least Recently Used, 没有被使用时间最长的
LFU -Least Frequenty Used, 一定时间段内使用次数最少的
FIFO -First In First Out  先进先出

缓存击穿，雪崩，穿透

缓存穿透

描述：

缓存穿透是指缓存和数据库中都没有数据，而用户不断发起请求，如发起id为"-1"的数据或id为特别大不存在的数据。这时用户很有可能是攻击者，攻击会导致数据库压力过大。

解决方案:

接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截。
从缓存取不到数据，在数据库中也没有取到，这时也可以将key-value对写成key-null，缓存有效时间可以设置短点，如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击
通过布隆过滤器实现

缓存击穿

描述：
缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期)，这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库中取数据，引起数据库压力瞬间增大，造成过大压力

解决方案：

设置热点数据永不过期

缓存雪崩

描述：

缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。