《Redis核心技术与实战》图解
2022-04-24 09:59:50 4 举报AI智能生成
登录查看完整内容
作为KV数据库，redis在互联网行业应用十分广泛，面试高频知识点，redis在CPU使用、内存组织、持久化和网络通信方面的设计非常经典，非常值得学习
作者其他创作
大纲/内容
简单动态字符串
整数数组
双向链表
跳表
散列表
压缩列表
消息队列
Stream
数据结构
ZSet
Set
Hash
List
String
基本数据类型
二值场景，比如签到
BitMap
基数统计
HyperLogLog
LBS
GEO
时间序列
RedisTimeSeries
扩展数据类型
自定义数据类型
数据类型
链式哈希
哈希冲突
哈希表1和哈希表2，默认写哈希表1，满了后扩容哈希表2、哈希表1转移到更大容量的哈希表2
原理
每次请求执行
定时执行
渐进式rehash
rehash
全局哈希表
键K&值V存储结构
IO多路复用（epoll）
IO模型
命令
AOF日志内容
先执行命令，后写AOF日志
后写
同步写，主线程执行
Always
先写AOF文件缓冲区，定时入盘
Everysec
先写AOF文件缓冲区，交给OS入盘
No
写回策略（appendfsync）
子进程执行bgrewriteaof
重写期间，写命令往两个AOF文件缓冲区写
可靠性保证
内存页表（虚拟内存和物理内存的映射）的拷贝，实例越大，内存页表越大
fork子进程
huge page 建议关闭
写时复制
阻塞点
AOF重写
AOF
压缩后的二进制数据
RDB日志内容
save主线程
fork bgsave 子进程(默认)
同AOF重写
RDB
RDB间隔期间记录AOF
最终是一个混合RDB的AOF文件
混合
持久化
主库提供读写，从库提供读
读写分离
replicaof
子进程执行
RDB文件（全量同步）
主从建立连接后创建
replication buffer（增量同步）
同步内容
1、主从建立连接，协商同步，主库生成RDB，从库记录主机信息和复制进度信息
2、发送RDB文件，从库先删库后回放RDB
3、发送replication buffer，从库加载replication buffer
同步步骤
主从同步
一直存在，主库会一直写
调整参数repl_backlog_size大小
环形结构，存在覆写的可能
如果出现覆写，必须执行一次全量同步
对比offset，进行增量同步
找到主从差异后，最终还是发送replication buffer
repl_backlog_buffer
网络断连
级联复制
主-从-从模式
主库假死
假设从库有 K 个，可以将 min-slaves-to-write 设置为 K/2+1（如果 K 等于 1，就设为 1），
主库能进行数据同步的最少从库数量
min-slaves-to-write
将 min-slaves-max-lag 设置为十几秒（例如 10～20s）
主从库间进行数据复制时，从库给主库发送 ACK 消息的最大延迟（以秒为单位）
min-slaves-max-lag
脑裂
监控主从复制差异，超过阈值便取消从库的连接，恢复后再连接
同步延迟
主从不一致
主从时钟保持一致
使用EXPIREAT/PEXPIREAT
过期延后
redis3.2以上版本
删除策略
读过期数据
protected-mode no
bind 配置项设置为其它哨兵实例的 IP 地址
cluster-node-timeout（10-20s）
配置不合理
故障
可能存在的问题
主从模式
管理主从
主观下线
quorum
客观下线（真下线）
周期性给主从发送PING，down-after-milliseconds时间内响应
监控主从
1、去除已断开连接的从库
2、去除断连超过一定次数的从库
候选者
slave-priority
优先级
比较offset
复制进度
越小越优先
runID
规则
选新主
基于pub/sub，哨兵发布，客户端订阅
主库下线事件
从库重新配置事件
新主库事件
哨兵定制了很多频道供客户端订阅
客户端主动查询
通知客户端
任务
读请求正常，写请求失败
1、拿到半数以上投票
2、票数大于等于quorum
leader选举
主从切换
哨兵配置主库信息
主库发现机制
基于pub/sub，主库发布，哨兵订阅
哨兵发现机制
哨兵给主库发送INFO命令获取从库列表
从库发现机制
客户端配置哨兵集群信息，而不是主从库信息
哨兵配置信息要保持一致
至少3个哨兵组成集群
哨兵集群
1、越大，误判率越低，影响业务越久
2、越小，影响业务越短，误判率越高
down-after-milliseconds配置
哨兵模式
核心思想：数据分散保存在多个实例中
16384个哈希槽
key根据CRC16算法得到对应的哈希槽
自动分配
手动分配
16384个哈希槽分布在不同的redis实例
PING
PONG
Gossip 协议通信
每个实例互相拥有各自的哈希槽信息，去中心化
客户端缓存哈希槽和实例的映射关系
redis实例新增删除
负载均衡
哈希槽重新分配
会触发客户端的映射更新
MOVED
ASK
ASKING
相关命令
重定向机制
需要开发支持集群的客户端
集群规模上限1000个实例
避免
拆分
bigkey
CLUSTER SLOTS
CLUSTER SETSLOT
CLUSTER GETKEYSINSLOT
MIGRATE
迁移
Slot分配不均衡
key中需要参与计算的部分加上花括号
不同key拥有相同的部分，可以通过Hash Tag分配到同一个实例中
Hash Tag
数据量倾斜
针对只读热点数据，增加副本，key加随机前缀，分配到不同实例
针对读写热点数据，只能增加资源
热点数据
数据访问倾斜
数据倾斜
Cluster
基于redis的二次开发产品
codis-server集群
代理层，客户端与此交互
codis-proxy集群
配置中心
zk集群
web可视化运维
codis dashboard&codis fe
四大组件
1024个哈希槽
dashboard
哈希槽分配
dashboard将哈希槽和server的映射关系存储到zk集群
proxy将哈希槽和server的映射关系缓存到本地
key根据CRC32算法得到具体的哈希槽，根据映射关系得到具体的server，由proxy代理请求
数据分布和路由
新增server
新增proxy
扩容
server阻塞
同步迁移
server不阻塞，异步等到目标server的ACK确认
迁移的数据设置为只读
临时过期时间
拆分指令
bigkey迁移优化
异步迁移
扩容和迁移
针对每个server增加哨兵主从
可靠性
Codis
切片集群
pthread_create创建子线程处理异步任务
推荐UNLINK
bigkey的删除
在 FLUSHDB 和 FLUSHALL 命令后加上 ASYNC 选项
清空数据库
AOF日志写
Redis异步线程（4.0）
多个物理核，利用超线程技术，每个物理核可以包含2个逻辑核
多核架构
几个物理核组成一个socket，共享一个L3
CPU socket
一个应用程序访问所在 Socket 的本地内存和访问远端内存的延迟并不一致
NUMA 架构
逻辑核共享物理核的L1、L2
L1、L2物理核私有
L3物理核共享
三级缓存
避免 Redis 总是在不同 CPU 核上来回调度执行
taskset
把网络中断程序和 Redis 实例绑在同一个 CPU Socket 上
避免 Redis 跨 CPU Socket 访问网络数据
查看核编号，便于准备绑核
lscpu
产生CPU竞争
绑定物理核而非逻辑核
优化源码
方案
风险
redis绑核
多核CPU
不够大且又不连续的一系列内存
固定大小分配
内存分配器策略
数据所需大小和分配的大小不一致
数据的修改删除
来源
合理
1<mem_fragmentation_ratio<=1.5
重启redis实例（不推荐）
开启自动碎片整理
activedefrag
内存碎片的字节数阈值
active-defrag-ignore-bytes
内存碎片空间占操作系统比例阈值
active-defrag-threshold-lower
用 CPU 时间的比例下限阈值
active-defrag-cycle-min
用 CPU 时间的比例上限阈值
active-defrag-cycle-max
碎片整理
mem_fragmentation_ratio>1.5
INFO memory命令
判断
内存碎片
暂存客户端发送的命令数据，或者是服务器端返回给客户端的数据结果
主从节点间进行数据同步时，用来暂存主节点接收的写命令和数据
场景
服务端处理过慢
溢出
已使用大小
qbuf
剩余大小
qbuf-free
查看缓冲区CLIENT LIST
无法调整大小，默认1G
避免 bigkey
避免redis主线程阻塞
注意点
输入缓冲区
OK和错误信息
固定大小16K
返回bigkey大量数据
产线禁止使用
monitor命令
client-output-buffer-limit配置
缓冲区设置太小
动态大小
输出缓冲区
缓冲区
单个命令实现多个命令
Lua脚本
原子操作
类似begin和commit
MULTI开启事务，后续的操作会先放入队列，EXEC真正执行操作
MULTI、EXEC
入队报错，保证
执行报错，不保证
实例宕机，开启AOF时保证，不开启不保证
原子性
执行报错不保证，其他保证
一致性
WATCH机制保证
隔离性
由于redis持久化机制不保证数据不丢失，因此不保证
持久性
ACID
redis事务
noeviction
volatile-random
volatile-ttl
volatile-lru
volatile-lfu
allkeys-random
allkeys-lru
allkeys-lfu
淘汰策略
只读缓存
可靠性高
同步直写
低延迟
异步写回
读写缓存
缓存类型
缓存一致性
缓存默认值或者空值
布隆过滤器
访问不存在的key
缓存穿透
热点数据不设置过期时间
热点数据过期
缓存击穿
过期时间加盐
非核心数据直接返回预定信息，核心数据查询数据库
服务降级
大量key同时过期
熔断、限流
主从集群
实例宕机
缓存雪崩
缓存
PX，增加锁失效时间，防止占用过久
区分客户端加锁，解锁时进行匹配，防止误解锁
SETNX
加锁
lua脚本
解锁
单个redis
思想：让客户端和多个独立的 Redis 实例依次请求加锁，如果客户端能够和半数以上的实例成功地完成加锁操作，那么我们就认为，客户端成功地获得分布式锁了，否则加锁失败
1、获取客户端时间
2、客户端按顺序依次向 N 个 Redis 实例执行加锁操作
3、一旦客户端完成了和所有 Redis 实例的加锁操作，客户端就要计算整个加锁过程的总耗时。
加锁步骤
客户端从超过半数（大于等于 N/2+1）的 Redis 实例上成功获取到了锁
客户端获取锁的总耗时没有超过锁的有效时间
加锁成功条件
执行N个解锁的Lua脚本
Redlock
多个redis
分布式锁
有序
消息需要有唯一ID
消费端支持幂等
可重复消费
消息可靠性
三大保证
有序性保证
先进先出
生产者保证消息的唯一ID
LPUSH
存
消费者需要不断循环主动获取
RPOP
阻塞式获取
BRPOP
备份消息
可靠性的保证
BRPOPLPUSH
取
不支持多个消费者
基于LIST
保证有序，自动生成唯一ID
ID规则：毫秒戳+当前毫秒戳的序号，如：1599203861727-0
XADD
可以按照ID读取
支持阻塞式读取
XREAD
创建消费组
XGROUP
消费组读取消息
XREADGROUP
内部队列留存消息，收到XACK后删除
查询每个消费组内所有消费者已读取但尚未确认的消息
XPENDING
向消息队列确认消息处理已完成
XACK
基于Streams（redis 5.0）
瞬时并发量访问大
读多写少
特征
商品详情静态化，CDN、浏览器缓存等加速访问
秒杀前
查询库存和扣减库存在redis中操作，并保证原子操作
利用分布式锁，保证只有一个客户端能查询库存扣减库存
秒杀中
退单、下单、支付、出库、物流等在数据库执行
秒杀后
阶段
秒杀
Bitmap
map存储结构
注册中心
zset
限流
数据库
应用场景
io-threads-do-reads yes
io-threads 6
并行的网络IO
IO多线程
服务端监测客户端读取的key是否有修改，发生变化便给客户端发送invalidate消息
读一次，监测并在修改时反馈一次
CLIENT TRACKING ON|OFF
普通模式
客户端注册希望监听的key的前缀
服务端广播给所有注册的客户端
CLIENT TRACKING ON BCAST PREFIX user
广播模式
Tracking功能
客户端缓存
创建用户并分配权限
权限控制ACL
字节数组形式进行编码，需要解码
RESP2.0
直接通过不同的开头字符，区分不同的数据类型
RESP3.0
redis6.0新特性
传统DRAM内存
直接持久化保存数据
读写速度接近DRAM
大容量
优点
不持久化
Memory模式
App Direct 模式
AEP内存工作模式
NVM内存
Jedis
Redisson
lettuce
Java客户端
REDIS
收藏
收藏
0 条评论
回复 删除
下一页
