缓存笔记
redis优点
数据库的数据是存放在瓷盘中的，虽然数据库层也做了对应的缓存，但是只针对查询的内容，一般只有表中的数据不发生变动的情况下，数据库对应的cache才会起作用，但这并不能减少业务系统对数据库的操作的IO压力
热点数据的高速缓存
提高应用的响应速度
极大缓解后端数据库的压力
Memcache和Redis的区别
Memcache
代码层次类似于Hash
- 支持简单数据类型
- 不支持数据持久化存储
- 不支持主从
- 不支持分片
Redis
- 数据类型丰富
- 支持数据磁盘持久化存储
- 支持主从
- 支持分片
为什么Redis这么快
100000+QPS
- 完全基于内存的
- 数据结构简单，对数据的操作也简单
- 采用单线程，单线程也能处理高并发请求，多核可启动多实例
- 使用多路I/O复用模型，即非阻塞IO
传统的阻塞I/O模型
当使用read或者write对某一个文件fd文件进行读写时，如果当前fd不可读或者不可写，整个Redis服务就不会对其他的操作做出响应，导致整个服务不可用。往往多个客户端进行访问的时候就不可行
常用数据类型
String：最基本的数据类型，二进制安全
set name "redis"
get name #"redis"
set count 1
incr count
get count #"2"
## 例如记载访问数量，每用户访问就incr
Hash:String元素组成的字典，适合用于存储对象
hmset info name "Evan" age 25 sex "男"
hget info age #"25"
hset info age 26
hget info age #"26"
List:列表，按照String元素插入顺序排序
lpush list a
lpush list b
lpush list c
lrange list 0 10
# 例子，最新消息排行榜，最新插入的消息，优先展示
Set: String元素组成的无序集合，通过哈希表实现，不允许重复
sadd myset 111 # 1
sadd myset 222 # 1
sadd myset 333 # 1
sadd myset 111 # 0
smembers myset
## 共同关注，喜好等功能
Sorted Set:通过分数来为集合中的成员进行从小到大的排序
zadd myzset 1 a # 1
zadd myzset 3 b # 1
zadd myzset 2 c # 1
zadd myzset 3 d # 1
zrangebyscore myzset 0 10
# 从小打到排序
用于计数的HyperLogLog，用于支持存储地理位置信息的Geo
从海量Key里查询出某一固定前缀的Key
- 摸清数据规模，即问清楚边界
- KEYS pattern：查找所有符合给定模式pattern的key
keys k1* #查询出所有k1打头的数据
KEYS指令一次性返回所有匹配的key
键的数量过大会使服务卡顿
-
SCAN cursor [MATCH pattern] [COUNT count]
无阻塞的提取出指定模式的KEY列表，SCAN执行只会返回少量元素，可用于生产环境
- 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
- 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
- 不保证每次执行都返回某个给定数量的元素，支持模糊查询
- 一次返回的数量不可控，只能是大概率符合count参数
SCAN 0 MATCH k1* COUNT 10
# 从0开始，匹配10条k1打头的key
image.png
返回：一个是游标值，另一个是数据集合
如何通过Redis实现分布式锁
分布式锁需要解决的问题
-
互斥性 任意时刻只能一个客户端获取锁
-
安全性 锁只能被持有的客户端删除，不能被其他客户端删除
-
死锁 获取锁的客户端因为某些原因导致宕机，而未能释放锁
-
容错 当部分节点，如Redis节点宕机的时候，客户端仍然能够获取释放锁
- SETNX key value：如果不存在，则创建并赋值
时间复杂度：O(1)
返回值：设置成功，返回1；设置失败，返回0
SETNX locknx test #1
SETNX locknx task #0
get locknx #test
- EXPIRE key seconds:解决SETNX长期有效问题
EXPIRE locknx 2
SETNX locknx task #1
image.png
setnx命令和expire命令本身是原子性，但是如果代码当中放在一起就不能保证原子性了
- SET key value [EX second] [PX millisecond] [NX|XX]
EX second:设置键的过期时间为second秒
PX millisecond：设置键的过期时间为millisecond毫秒
NX：只有键不存在的时候，才对键进行设置操作
XX: 只在键已经存在时，才对键进行设置操作
SET操作成功后返回OK，失败返回nil
set locktarget 12345 ex 10 nx
image.png
大量key同时过期
集中过期，由于清除大量key很耗时，会出现卡顿现象
解决方案：在设置key的过期时间的时候，给每个key加上随机值
如何使用Redis做异步队列
- 使用List作为队列，RPUSH生产消息，LPOP消费消息
rpush testlist aaa
rpush testlist bbb
rpush testlist ccc
lpop testlist
缺点：没有等待队列里有值就直接消费
弥补：可以通过应用层引入sleep机制去调用LPOP重试
- BLPOP key[key] timeout:阻塞直到队列有消息或者超时
客户端1：
blpop testlist 20
客户端2：
rpush testlist aaa
此时客户端1就会获取消息aaa
- 缺点：只能提供一个消费者消费
pub/sub主题订阅者模式
- 发送者（pub）发送消息，订阅者（sub)接收消息
- 订阅者可以订阅任意数量的频道
image.png
客户端1订阅频道myTopic
subscribe myTopic
image.png
客户端2订阅频道myTopic
image.png
客户端3订阅另一个频道anotherTopic
image.png
客户端4发布消息
publish myTopic "hello" #客户端1，2收到消息，客户端3未收到消息
pub/sub缺点：消息的发布是无状态的，无法保证可达
Redis做持久化
RDB（快照）持久化：保存某个时间点的全量数据快照
[图片上传失败...(image-be6a56-1583057254875)]
900秒内，如果有1条是写入指令，就触发产生一次快照
300秒内，如果有10条是写入指令，就触发产生一次快照
60秒内，如果有10000条是写入指令，就触发产生一次快照
stop-writes-on-bgsave-error
yes代表当备份进程出错的时候，主进程就会禁止写入操作，保证持久化数据的一致性
rdbcompression
yes代表在备份的时候需要将RDB文件进行压缩后才去做保存，建议no，因为Redis本身就属于CPU密集型服务器，在开启压缩的时候会带来更多的CPU消耗，相比硬盘成本，CPU更值钱，如果你需要禁用RDB配置，只需要在save后加上save ""
自动化触发RDB持久化的方式
- 根据redis.conf配置里的
SAVE m n定时触发（用的是BGSAVE） - 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行Shutdown且没有开启AOF持久化
RDB持久化
- 内存数据的全量同步，数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据
AOF持久化：保持写状态
- 记录下除了查询以外的所有变更数据库状态的指令
- 以append的形势追加保存到AOF文件中（增量）
image.png
日志重写解决AOF文件大小不断增大的问题，原理如下：
- 调用fork()，创建一个子进程
- 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
- 主进程持续将新的变动同时写到内存和原来的AOF里
- 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
- 使用新的AOF文件替代掉旧的AOF文件
Redis数据的恢复
image.png
RDB和AOF的优缺点
RDB优点：全量数据快照，文件小，恢复快
RDB缺点：无法保存最近一次快照之后的数据
AOF优点：可读性高，适合保存增量数据，数据不易丢失
AOF缺点：文件体积大，恢复时间长
Redis4.0后，RDB-AOF混合持久化方式，作为默认
- BGSAVE做镜像全量持久化，AOF做增量持久化
Pipeline及主从同步
- Pipeline和Linux的管道类似
- Redis基于请求/响应模型，单个请求处理需要一一作答
- Pipeline批量执行指令，节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
Redis的同步机制
主从同步原理
- 全同步过程
- Salve发送sync命令到Master
- Master启动一个后台进程，将Redis中的数据快照保存到文件中
- Master将保存数据快照期间接收到的写命令缓存起来
- Master完成写文件操作后，将该文件发送方给Salve
- 使用新的AOF文件替代掉旧的AOF文件
- Master将这期间收集的增量写命令发送给Salve
- 增量同步过程
- Master接收到用户的操作指令，判断是否需要传播到Salve
- 将操作记录追加到AOF文件
- 将操作传播到其他Salve：1、对齐主从库；2、往响应缓存写入指令
- 将缓存中的数据发送给Salve
Redis Sentinel
解决主从同步Master宕机后的主从切换问题
- 监控：检查主从服务器是否运行正常
- 提醒：通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移：主从切换
