Redis入门到精通
2022-11-29 15:37:14 0 举报
AI智能生成
登录查看完整内容
Redis入门到精通
作者其他创作
大纲/内容
save
配置触发
shutdown指令
flushall指令
bgsave指令
非阻塞
save指令
阻塞
触发时机
文件小,备份恢复快
主线程不需要跟磁盘IO,性能快
优势
数据安全性低
消耗CPU
劣势
优劣势
RDB快照(Redis Database)
appendfsync always 表示每次写入都执行fsync(刷新)函数 性能会非常非常慢 但是非常安全
appendfsync everysec 每秒执行一次fsync函数 可能丢失1s的数据
appendfsync no 由操作系统保证数据同步到磁盘,速度最快
持久化时机
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
重写时机
RDB+AOF
重写优化
重写
安全性非常高,默认也只会有1s丢失
可读性相对高
数据文件比rdb大,加载数据慢
7.0以下版本,重写期间会有2次IO,占用大量内存
Append Only File
持久化
数据备份
负载
传的repid跟master不相等
相差的offse在replication_backlog_buffer找不到
条件
master收到请求:bgSave生成RDB文件给slave
新的指令通过client-output-buffer-limit保存
slave发起
全量同步
传的repid跟master相等
相差的offse在replication_backlog_buffer能找到
增量同步
指令异步同步给slave
master发起
指令同步
主从数据一致性保证
主从
主观下线
客观下线
发现故障
raft选择sentinel进行故障转移
转移故障
断开时间
replica-priority
offset
Run ID
哪个slave成为master
自动故障转移
客户端直接配置sentinel地址
配置提供
分区容错性导致多个master出现
多个master都写入数据
网络恢复,会丢失之前master写入的数据
数据丢失场景
脑裂
哨兵sentinel
每个master都会有slave并且可以自动故障转移
备份
不同的key对应不同的master实例
更灵活的数据分片
节点扩容、缩容不需要更改所有数据
虚拟槽
分片
cluster
集群
Redis高可用篇
使用key的时候判断是否过期
被动过期
1.扫描设置了过期时间的key-expires
2.根据hash桶维度扫描,最多扫20(可配)key为止
3.删除扫到的key中过期的key
4.删除比例如果超过10%(可配)
5.每执行16次会进行时间判断
定时任务ServerCron方法 hz配置执行频率
定期过期
过期策略
空间是否满足新的key,如果满足不淘汰
策略是否为novication,如果是不淘汰
1.判断是否需要淘汰
2.判断当前空间是否满足新的key
maxmemory-samples:5(默认)
3.取样数据
4.循环取样数据
配置淘汰算法
maxmemory-policy
5.根据淘汰算法得到key的淘汰值:ide 越大越容易淘汰
将取样数据放入淘汰池
不适合淘汰的从池子移除
1.取样的数据比淘汰池中的数据更容易淘汰
2.淘汰池未满,直接插入
6.塞入淘汰池 pool
7.从淘汰池中实现末尾淘汰,释放数据内存空间
淘汰流程
所有key
allkeys
设置了过期时间的key
volatile
淘汰范围
random
server.lrulock-redisObject.lru
server.lrulock>=redisObject.lru
server.lrulock-redisObject.lru+24bit的最大值
server.lrulock<redisObject.lru
最久未使用越容易淘汰
lru
解决时效性问题
lfu-decay-time 1 多少分钟没操作减少一次
16bit时间得到对象多少分钟没访问
如果小于5,必+1
已有counter越大,几率越低
lfu-log-factor越大,几率越低
大于5 小于255
=255 不加次数
8bitcounter够不够
counter·越小越容易淘汰
redisObject.lru=16bit时间+8bitCount
次数越少越容易淘汰
lfu
过期时间越小越容易淘汰
ttl
淘汰算法
淘汰策略
Redis内存管理篇
主从同步
Redis数据丢失场景分析
并发导致的数据库跟DB的数据不一致
设置过期时间
Mysql canel同步
保证最终一致性即可
数据一致性
布隆过滤器
布谷鸟过滤器
redis跟DB都没有,请求都会进入DB
缓存穿透
互斥锁
单个key过期或者redis没有,产生大量并发
缓存击穿
保证Redis的高可用
互斥加锁
DB集群提高可用性
缓存雪崩
Redis缓存场景分析
慢日志查询
大key查询
Redis调优
Redis场景篇
2个ht,非扩容的时候,只有ht[0]有数据
在持久化,已用数据>分配数量*5
不在持久化,已用数据>=分配数量
扩容时机
持久化会使用copy-on-write技术占有大量内存,扩容也需要大量内存,资源协调
扩容机制
Redis命令执行是单线程,不会有循环链问题,性能比尾插高
头插链地址法
hash冲突解决
指令执行执行hash桶的数据迁移
定时任务执行hash桶数据迁移
渐进式rehash
Redis数据字典dictht
牺牲空间换时间
SDS
String
hash-max-ziplist-value 64
hash-max-ziplist-entries 512
连锁更新问题、只适合数据量小的场景
节省内存
zipList
ditcht
Hashes
一定程度上解决zipList连锁更新带来的性能问题
分段zipList
quicklist
Lists
必须是整数类型
set-max-intset-entries 512
时间O(n),也只适合数量小场景
有序集合
intset
dictht
Sets
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
空间换时间
skipList
Sorts set
不同数据类型Value的数据结构
Redis数据结构篇
保证多个指令的原子性,但是不能拿到中间结果做业务处理
multi、exec/DISCARD
事务
不能保证原子性,减少网络开销次数提升性能
pipelining
保证多个指令的原子性
lua脚本
subscribe/psubscribe、publish
发布与订阅
高级功能
lua+hash实现可重入
Semaphore+发布订阅
自旋等待
hashWheelTimer定时续期
看门狗自动时间续期
往多个实例加锁,过半成功
尽可能减少Redis的不可靠性
联锁
Redission分布式锁
Redis高阶使用篇
Redis由来
基于内存
命令执行单线程
k、v结构、底层数据结构支持
多路IO复用
速度快
主从复制
高可用、分布式部署
Redis特性
Redis简介
缓存
session
缓存存储类相关场景
所有数据类型都可以实现
分布式可重入锁
对象类数据存储
购物车
抽奖
集合操作:交集、差集、并集
关注/点赞
排行榜
高性能位图操作
有序列表
阻塞队列、堆栈
基本应用场景
hashes
bitMap
sets
lists
Redis基础使用篇
Redis入门到精通
0 条评论
回复 删除
下一页