5-redis高级-python 操作哨兵、redis 集群(扩容成8台机器-4个节点、缩容成6台机器-3个节点)、缓存(缓存更新策略、缓存穿透缓存击穿缓存雪崩)、redis跳跃表、redis入侵

林光虚霁晓

已于 2023-12-08 20:44:35 修改

阅读量537

点赞数 10

分类专栏： redis 文章标签： redis bootstrap 数据库

于 2023-12-06 20:31:50 首次发布

本文链接：https://blog.csdn.net/weixin_44145338/article/details/134840513

版权

redis 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1 哨兵
 1.1 python 操作哨兵

2 redis 集群
 1.2 扩容成8台机器–4个节点
 1.3 缩容成6台机器–3个节点

3 缓存
 3.1 缓存更新策略
 3.2 缓存穿透缓存击穿缓存雪崩

4 redis的跳跃表
 5 redis入侵

1 哨兵

# 主从---》一主多从
	-主库用来写
    -从库用来读
    -主库挂了--》整个系统就不能写数据了
    
#主从复制存在的问题：
 1 主从复制，主节点发生故障，需要做故障转移，可以手动转移：让其中一个slave变成master---》哨兵 高可用
 2 主从复制，只能主写数据，所以写能力和存储能力有限--》集群


# 高可用：服务的高度可用性  公司追求 4个9
	

# 哨兵---》sentinal---》监控主库变化---》如果主库挂了--》自动选择一个从库---》做故障切换---》把从库升级为主库---》还能对外提供服务



# 架构
	3个redis服务---》3台机器
    3个sentinal---》3台机器
    
    启动3个redis-server进程
    启动3个redis-sentinal进程
    
    
# 搭建步骤
	- 先搭建一主两从
    
# 第一步：搭建一主两从
daemonize yes
pidfile /var/run/redis.pid
port 6379
dir "/root/redis/data"
logfile "6379.log"

#第二个是从配置文件
daemonize yes
pidfile /var/run/redis2.pid
port 6378
dir "/root/redis/data"
logfile "6378.log"
slaveof 127.0.0.1 6379
slave-read-only yes

#第三个是从配置文件
daemonize yes
pidfile /var/run/redis3.pid
port 6377
dir "/root/redis/data"
logfile "6377.log"
slaveof 127.0.0.1 6379
slave-read-only yes

# 第二步：启动三个哨兵--》监控一主两从的关系
-然后打开vim sentinel_26739.conf

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

-然后打开vim sentinel_26380.conf
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

-然后打开vim sentinel_26381.conf
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

##### 启动哨兵
redis-sentinel ./sentinel_6379.conf
redis-sentinel ./sentinel_6380.conf
redis-sentinel ./sentinel_6381.conf


#第三步：等待主库挂掉
# 第四步：自动切换主库
# 第五步：以后原来的主库启动，会变为从库

1.1 python 操作哨兵

import redis
from redis.sentinel import Sentinel

# 连接哨兵服务器(主机名也可以用域名)
sentinel = Sentinel([('127.0.0.1', 26379),
                     ('127.0.0.1', 26380),
                     ('127.0.0.1', 26381)],
                    socket_timeout=5)

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

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



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

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

2 redis 集群

# 主从---》提高并发量
# 哨兵----》高可用
# 存在问题
1 并发量：单机redis qps为10w/s,但是我们可能需要百万级别的并发量
2 数据量：机器内存16g--256g，如果存500g数据呢？
# 解决：加机器，分布式
redis cluster 在2015年的 3.0 版本加入了，满足分布式的需求


# 数据分布（分布式数据库：多台机器存储一份数据）
# 哈希分布	数据分散度高，建值分布于业务无关，无法顺序访问，支持批量操作	一致性哈希memcache，redis cluster，其他缓存产品
节点取余分区：
	缺点：节点扩容，添加一个节点，存在问题，很多数据需要偏移，总偏移量要大于80%，推荐翻倍扩容，由3变成6，数据量迁移为50%，比80%降低
    
一致性哈希分区
客户端分片：哈希+顺时针（优化取余）
节点伸缩：只影响临近节点，但是还有数据迁移的情况
伸缩：保证最小迁移数据和无法保证负载均衡（这样总共5个节点，数据就不均匀了），翻倍扩容可以实现负载均衡


虚拟槽分区
    预设虚拟槽：每个槽映射一个数据子集（16384个槽），一般比节点数大
    良好的哈希函数：如CRC16
    服务端管理节点、槽、数据：如redis cluster（槽的范围0–16383）

    5个节点，把16384个槽平均分配到每个节点，客户端会把数据发送给任意一个节点，通过CRC16对key进行哈希对16383进行取余，算出当前key属于哪部分槽，属于哪个节点，每个节点都会记录是不是负责这部分槽，如果是负责的，进行保存，如果槽不在自己范围内，redis cluster是共享消息的模式，它知道哪个节点负责哪些槽，返回结果，让客户端找对应的节点去存
    
服务端管理节点，槽，关系
    
    
    
# 顺序分布	数据分散度易倾斜，建值业务相关，可顺序访问，支持批量操作	BigTable，HBase
顺序分区
# 原理：100个数据分到3个节点上 1--33第一个节点；34--66第二个节点；67--100第三个节点（很多关系型数据库使用此种方式）



# 启动 6个redis节点，一主一从架构  3个节点 存数据，每个有一个从库，做高可用
	
    
# 第一步：写6个redis配置文件
# vim redis-7000.conf
port 7000
daemonize yes
dir "/root/redis/data/"
logfile "7000.log"
dbfilename "dump-7000.rdb"

cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-require-full-coverage yes 

# 第二步：快速生成剩余5个配置文件
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个节点
redis-server ./redis-7000.conf
redis-server ./redis-7001.conf
redis-server ./redis-7002.conf
redis-server ./redis-7003.conf
redis-server ./redis-7004.conf
redis-server ./redis-7005.conf


# 查看集群信息
cluster info
cluster nodes

# 第四步：搭建集群  
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
# yes  同意


# 第五步：测试
	往 7000 上写 set name lqz 这个数据，写不进去
    原因是：name被hash后，得到的槽不归 7000管[0--5460槽]
    返回给我们错误，让我们去7001上写，顺利写进去
    
# 第六步：集群模式连接--->自动切换到不同节点
	 redis-cli -p 7000 -c
    

# 第七：停掉一个主---》原来的从会升级为主

# 第八步：python操作redis集群
# pip3 install redis-py-cluster
from rediscluster import RedisCluster
startup_nodes = [{"host":"127.0.0.1", "port": "7000"},{"host":"127.0.0.1", "port": "7003"},{"host":"127.0.0.1", "port": "7002"}]
rc = RedisCluster(startup_nodes=startup_nodes)
rc.set("foo", "bar")
print(rc.get("foo"))

在这里插入图片描述

1.2 扩成8台机器–4个节点

#1 准备两台机器
sed 's/7000/7006/g' redis-7000.conf > redis-7006.conf
sed 's/7000/7007/g' redis-7000.conf > redis-7007.conf
#2 启动两台机器
redis-server ./redis-7006.conf
redis-server ./redis-7007.conf

# 3 两台机器加入到集群中去
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
        
# 4 让7007复制7006
redis-cli -p 7007 cluster replicate 57bd8b9155c691a388d4d00ac942139776cd29f3
        
# 5 迁移槽
redis-cli --cluster reshard 127.0.0.1:7000 
    -迁移4096个槽
    -7006的机器接收槽
    -all

1.3 缩容成6台机器–3个节点

# 第一步：下线迁槽（把7006的1366个槽迁移到7000上）
redis-cli --cluster reshard --cluster-from 57bd8b9155c691a388d4d00ac942139776cd29f3 --cluster-to a2262cdee20064b2d9c5a179dddf790817567131 --cluster-slots 1365 127.0.0.1:7000
yes

redis-cli --cluster reshard --cluster-from 57bd8b9155c691a388d4d00ac942139776cd29f3 --cluster-to 0a14f626669f79abac038baf5efa74e3f23fe0f3 --cluster-slots 1366 127.0.0.1:7001
yes

redis-cli --cluster reshard --cluster-from 57bd8b9155c691a388d4d00ac942139776cd29f3 --cluster-to 5781867aaefc19c0701998da7663fb9b155bd22f --cluster-slots 1365 127.0.0.1:7002
yes


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

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

3 缓存

3.1 缓存更新策略

# 如果内存中redis数据满了，再继续往里存数据，redis会触发缓存更新的策略
# 有如下几种
LRU/LFU/FIFO算法剔除：例如maxmemory-policy(到了最大内存，对应的应对策略)

# LRU -Least Recently Used,没有被使用时间最长的
# LFU -Least Frequenty User,一定时间段内使用次数最少的
# FIFO -First In First Out，最早放进去的key

3.2 缓存穿透缓存击穿缓存雪崩

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

    

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

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

4 redis的跳跃表

跳跃表（Skip List）是一种有序数据结构，用于实现有序集合（Ordered Set）的数据结构。
在 Redis 中，有序集合就是通过跳跃表来实现的。
跳跃表的主要优势在于它对于有序集合的范围查询提供了较好的性能，并且相对于平衡树等数据结构来说，实现和维护相对简单。

跳跃表的基本结构包含多层，每一层都是一个有序的链表。
最底层包含所有的元素，而每一层都是前一层的子集。
每个节点包含一个分值和一个指向下一层的指针。

Redis 跳跃表的主要特征：
1. **层级结构：** 
	跳跃表包含多个层级，每一层都是一个有序链表。每一层的节点都是下一层节点的指针。
2. **多层索引：** 
	为了提高搜索效率，跳跃表在每一层都设置了一些节点作为索引。
	这些索引节点通过指向下一层的方式，允许跳过一定数量的节点，从而加速搜索。
3. **随机性：** 
	在每一层的创建和插入过程中，通过一定的概率来随机决定是否在当前层创建索引。这个概率通常是 0.25 或 0.5。

跳跃表的时间复杂度：
- **搜索：** O(log N)
- **插入：** O(log N)
- **删除：** O(log N)
这里的 N 是跳跃表中的元素数量。

跳跃表的这些特性使得 Redis 在有序集合的查询方面能够提供良好的性能。
此外，相较于平衡树等结构，跳跃表的实现更为简单，对于工程实践中的高性能要求是一种较好的选择。

5 redis入侵

Redis 入侵指的是未经授权的人或程序以某种方式访问了 Redis 数据库，可能导致信息泄露、数据损坏或者服务被滥用。
这种情况可能发生在恶意攻击者试图利用 Redis 的漏洞、弱密码或者不当配置，或者在网络环境中通过监听或拦截 Redis 数据传输而获得的未经授权的访问权限。

常见的 Redis 入侵可能包括：
1. **未授权访问：** 
	攻击者通过某种方式绕过了认证机制，成功连接到 Redis 服务器。
	这可能是因为弱密码、未启用密码认证，或者通过其他手段绕过了访问控制。
2. **数据泄露：** 
	攻击者通过未经授权的访问获取了 Redis 中的敏感信息，比如用户凭证、业务数据等。
	这可能会导致隐私泄露、敏感数据的非法获取。
3. **滥用 Redis 功能：** 
	攻击者可能会通过未授权的访问，滥用 Redis 提供的一些功能，比如执行危险的命令、修改数据等，导致数据损坏或者服务不正常。

为了防止 Redis 入侵，建议采取以下一些建议：
- **密码认证：** 启用 Redis 的密码认证机制，使用强密码，并且定期更换密码。
- **网络隔离：** 将 Redis 仅绑定在内部网络，避免直接对外开放。
- **更新和升级：** 定期更新 Redis 到最新的版本，以获取最新的安全性修复。
- **访问控制：** 使用 Redis 的访问控制功能，限制连接的 IP 地址或者网段。
- **监控和日志：** 启用 Redis 的监控功能，定期审查 Redis 的日志文件，检测潜在的入侵行为。
- **防火墙：** 使用防火墙设置，只允许来自可信任 IP 地址范围的访问。
- **物理隔离：** 在分布式架构中，通过网络隔离和权限控制，确保只有授权用户可以访问 Redis。
- **定期审查配置：** 定期审查 Redis 的配置文件，确保没有不必要的开放或者不安全的配置。

林光虚霁晓

关注

10
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
5-redis高级-python 操作哨兵、redis 集群(扩容成8台机器-4个节点、缩容成6台机器-3个节点)、缓存(缓存更新策略、缓存穿透缓存击穿缓存雪崩)、redis跳跃表、redis入侵

python 操作哨兵、redis 集群(扩容成8台机器-4个节点、缩容成6台机器-3个节点)、缓存(缓存更新策略、缓存穿透缓存击穿缓存雪崩)、redis跳跃表、redis入
复制链接

扫一扫