缓存应用架构:
常见流程如:
4 穿透存储层
5 回种
7 熔断
memcache和redis的区别
memcache:代码层次类似hash
支持简单数据类型
不支持数据结构化存储
不支持主从
不支持分片
redis:
数据类型丰富
支持数据磁盘持久化存储
支持主从
支持分片
为什么redis能这么快
10W+QPS qps即query per second 每秒内查询次数
完全基于内存,绝大部分请求是纯粹的内存操作,执行效率高
数据结构简单,对数据操作也简单
采用单线程,单线程也能处理高并发请求,想多核也可启动多实例
使用多路I/O复用模型,非阻塞IO
多路I/O复用模型
FD:file descriptor ,文件描述符
一个打开的文件通过唯一的描述符进行引用,该描述符是打开文件的元数据到文件本身的映射
传统的阻塞I/O模型
Redis采用的I/O多路复用函数:epoll,kqueue(mac),evport(linux),select
因地制宜
优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现
以时间复杂度为o(n)的select作为保底
基于react设计模式监听I/O事件
Redis的数据类型
供用户使用的数据类型
1.String:最基本的数据类型,二级制安全 k-v键值对 值512M
set name "redis"
get name
2.Hash:String元素组成的字典,适合用于存储对象
hash映射表
hmset lilei name "lilei" age 26 title "senior"
hget lilei age
3.List:列表,按照String元素插入顺序排序
lpush mylist aaa
lpush mylist bbb
lpush mylsit ccc
lrange mylist 0 10
4.Set:String元素组成的无序集合,通过哈希表实现,不允许重复
sadd myset 111
sadd myset 222
smembers myset
5.Sorted Set:通过分数来为集合中的成员进行从小到大的排序
zadd myzset 3 adb
zadd myzset 1 abd
zadd myzset 2 abb
zrangebyscore myzset 0 10
6.用于计数的HyperLogLog,用于支持存储地理位置信息的Geo
底层数据类型基础
1.简单动态字符串
2.链表
3.字典
4.跳跃表
5.整数集合
6.压缩列表
7.对象
从海量key里查询出某一固定前缀的key
留意细节
摸清数据规模,即问清楚边界
使用keys对线上的业务的影响
KEYS pattern:查找所有符合给定模式pattern的key
KEYS指令一次性返回所有匹配的key
键的数量过大会使服务卡顿
SCAN cursor pattern count(推荐)
基于游标的迭代器,需要基于上一次的游标延续之前的迭代
以0作为游标开始一次新的迭代,直到命令返回游标0完成一次遍历
不保证每次执行都返回某个给定数量的元素,支持模糊查询
一次返回的数量不可控,只能是大概率符合count参数
scan 0 match k1* count 10
如何通过redis实现分布式锁
控制分布式系统或不同系统之间共同访问共享资源的一种锁的实现
分布式锁需要解决的问题
互斥性
安全性
死锁
容错
SETNX key value :如果key不存在,则创建并赋值
时间复杂度o(1)
setnx locknx test
如何解决SETNX长期有效的问题
EXPIRE key seconds
设置key的生存时间,当key过期时(生存时间为0),会被自动删除
缺点:原子性不能满足
expire locknx 2
setnx locknx task
SET key value seconds miliseconds NX|XX
EX second:设置键的过期时间为second秒
PX millisecond:设置键的过期时间为millisecond毫秒
NX:只在键不存在时,才对键进行设置操作
XX:只在键已经存在时,才对键进行设置操作
SET操作成功完成时,返回ok,否则返回nil
大量的key同时过期的注意事项
集中过期,由于清除大量的key很耗时,会出现短暂的卡顿现象
解决方案:在设置key的过期时间的时候,给每个key加上随机值
如何使用redis做异步队列
1.使用List作为队列,RPUSH生产消息,LPOP消费消息
缺点:没有等待队列里有值就直接消费
弥补:可以通过在应用层引入sleep机制去调用LPOP重试
blpop testlist 30
rpush testlist aaa
2.pub/sub:主题订阅者模式
发送者(pub)发送消息,订阅者(sub)接受消息
订阅者可以订阅任意数量的频道
subscribe myTopic
publis myTopic "hao nan ya"
pub/sub的缺点
消息的发布时无状态的,无法保证可达
RDB持久化
一、RDB(快照)持久化:保存某个时间点的全量数据快照
SAVE:阻塞Redis的服务器进程,直到RDB文件被创建完毕
BGSAVE:Fork出一个子进程来创建RDB文件,不阻塞服务器进程
RDB持久化缺点:
1.内存数据的全量同步,数据量大会由于I/O而严重影响性能
2.可能会因为redis挂掉而丢失从当前至最近一次快照期间的数据
vim redis.conf
/save
rdbcompression yes
save ""
cd src
lastsave
bgsave
手工方式触发rdb持久化:
通过java定时器定期吊起redis save指令去备份rdb文件,并按照时间戳存储某个时间点的文件
自动化触发RDB持久化的方式
1.跟进redis.conf配置里SAVE m n定时触发(用的是BGSAVE)
2.主从复制,主节点自动触发
3.执行debug reload
4.执行shutdown且没有开启AOF持久化
BGSAVE原理:
1.判断子进程有没有save或bgsave
2.没有则执行源码底层的rbdSaveBackground
3.系统调用fork():创建进程,实现了copy-on-write
copy-on-write优化策略:
如果有多个调用者同时要求相同资源,他们会共同获取相同的指针指向相同的资源,直到某个调用者试图修改资源的内容时,系统才会真正复制一份专用副本给该调用者,而其他调用者所见到的最初的资源仍然保持不变
二、AOF(Append-Only-File)持久化:保存写状态
记录下除了查询以外的所有变更数据库状态的指令
以append的形式追加保存到AOF文件中(增量)
vim redis.conf
appendonly yes
appendfsync always/everysec(每秒)/no
.redis-cli
config set appendonly yes
日志重写解决AOF文件大小不断增大的问题,原理如下:
1.调用fork(),创建一个子进程
2.子进程把新的AOF写到一个临时文件里,不依赖原来的AOF文件
3.主进程持续将新的变动同时写到内存和原来的AOF里
4.主进程获取子进程重写AOF的完成信号,往新AOF同步增量变动
5.使用新的AOF文件替换掉旧的AOF文件
RDB和AOF文件共存情况下的恢复流程
存在AOF则优先加载AOF
RDB和AOF的优缺点
RDB优点:全量数据快照,文件小,恢复快
RDB缺点:无法保存最近一次快照子后的数据
AOF优点:可读性高,适合保存增量数据,数据不易丢失
AOF缺点:文件体积大,恢复时间长
三、RDB-AOF混合持久化方式
BGSAVE做镜像全量持久化,AOF做增量持久化
使用Pipeline的好处
1.Pipeline和liunx的管道类似
2.Redis基于请求/响应模式,单个请求处理需要一一应答
3.Pipeline批量执行指令,节省多次IO往返的时间
4.有顺序依赖的指令建议分批发送
Redis的同步机制
主从同步原理
全同步流程
1.Salve发送sync命令到Master
2.Master启动一个后台进程,将Redis中的数据快照保存到文件中
3.Master将保存数据快照期间接收到的写命令缓存起来
4.Master完成写操作后,将该文件发送给Salve
5.使用新的AOF文件替换掉旧的AOF文件
6.Master将这期间收集的增量写命令发送给Salve端
增量同步过程:
1.Master接收到用户的操作指令,判断是否需要传播到slave
2.将操作记录追加到AOF文件
3.将操作传播到其他Slave:1、对齐主从库;2、往响应缓存写入指令
4.将缓存中的数据发送给slave
Redis Sentinel
解决主从同步Master宕机后的主从切换问题:
1.监控:检查主从服务器是否运行正常
2.提醒:通过api向管理员或者其他应用程序发送故障通知
3.自动故障迁移:主从切换
留言协议Gossip (也应用在区块链点对点去中心化)
在杂乱无章中寻求一致
1.每个节点都随机地与对方通信,最终所有节点的状态达成一致
2.种子节点定期随机向其他节点发送节点列表以及需要传播的消息
3.不保证信息一定会传递所有节点,但是最终会趋于一致
Redis的集群原理
如何从海量数据里快速找到所需?
分片:按照某种规则去划分数据,分散存储在多个节点上
常规的按照哈希划分无法实现节点的动态增减
一致性哈希算法:对2^32取模,将哈希值空间组织成虚拟的圆环
将数据key使用相同的哈希函数hash计算出哈希值
hash环的数据倾斜问题:数据量小的时候
引入虚拟节点解决数据倾斜的问题