Redis 分布式锁:
1.互斥性 任意时刻只能有一个客户端访问。
2.安全性 只能持有该锁的客户端删除锁
3.死锁 当持有该所的主机发生宕机 被删除 其他客户端无法获取该锁导致死锁
4.容错 宕机了 ?(本机还是其他机器)客户端能获取锁释放锁
创建锁
setnx locanx test 创建锁
get locanx 获得locanx 锁
expire locknx 2 设置锁过期时间
缺点:
原子性得不到满足
如果程序在加锁后挂掉 就会死锁
设置key 过期时间
Set key value [EX seconds][PX milliseconds] [NX|XX]
- EX second :设置键的过期时间 为秒
- PX millisecond :设置键的过期时间为 毫秒milliseconds
- NX 只在键不存在是,才对间进行设置操作
- XX:只在键已经存在时,才对键进行设置操作
- SET 操作成功完成时,返回OK,否则返回nil
问题:如果同时有大量key 过期 会造成redis卡顿 该如何解决?
答:生成随机过期时间 key
如何使用Redis 做异步队列
使用List 作为队列,RPUSH生产消息,LPOP消费信息
缺点:
没有等待队列里有值就去消费
弥补:
可以使用在应用层引入Sleep机制去调用LPOP重试
rpush [name] [msg] 添加队列消息
lpop [name] 不阻塞队列
blpop [name] [waitingtime] 阻塞队列
如何多次被消费 发布订阅?
subscribe [name] 订阅平道
publish [name] [msg] 推送消息
无状态 推送消息后是无法 确定客户端有没有接收到的
Redis 做持久化
RDB(快照)持久化:保存某个时间点的全量快照。
- SAVE:阻塞Redis的服务进程,知道RDB文件被创建完成。
- BGSAVE:Fork出一个子进程来创建RDB文件,不阻塞主进程。
自动化触发RDB持久化方式 - 根据redis.conf配置里的SAVE m n 定时触发(BGSAVE)
- 主从复制时,主节点自动触发
- 执行Debug Reload
- 执行Shutdown切没有开启AOF持久化
RDB持久化
缺点: - 内存数据全量同步,数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失当前至最近一次期间的快照数据
AOF(Append-Only-File)持久化 - 记录下除了查询意外所有变更数据库状态的指令
- 以append的形式追加保存到AOF文件中(增量)
RDB和AOF的有缺点 - RDB优点:全量数据快照,文件小,恢复快
- RDB缺点:无法保存最近一次快照后的数据
- AOF优点:可读性高,适合保存增量数据,数据不易丢失
- AOF缺点:文件体积大,恢复时间长
RDB-AOF混合持久化方式 - BGSAVE做全量持久化,AOF做增量持久化
为什么使用pipeline?
- PIPline 和 linux 管道类似 通过命令读取文件 传输到redis中(cat /tmp/redisTest.txt | 路径/redis-5.0.0/src/redis-cli -h 主机ip -p 端口号 —pipe)
- Redis 基于请求/响应模型,单个请求处理需要–应答
Redis主从同步
全同步过程
- Salve发送sync命令道Master
- Master启动一个后台进程,将Redis中的数据快照保存到文件中 。
- Master 将保存数据快照期间接收到的命令缓存起来
- Master 完成写操作文件后,将该文件发送给Salve
- 使用新的AOF文件替换掉就得AOF文件
- Master 将这期间的文件 收集到的 增量AOF文件发送给Salve端
增量同步过程 - Master 接收到用户的操作命令,判断是否需要传播道slave
- 将操作记录追加到AOF文件
- 将操作传播传播到其他Slave:1、对齐主从库; 2.往响应缓存写入指令
- 将缓存中的数据发给Salve
Redis Sentinel
解决主从同步Master 当即后的主从切换问题 - 监控:检查主从服务器是否运行正常
- 提醒:通过API向管理员或者其他应用程序发送故障通知
- 自动发故障迁移:主动切换
流言协议Gossip
在杂乱无章中寻求一致 -
每个节点都随机与对方通信,最终所有节点的状态达成一致 - 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证消息一定会换递给所有节点,但最终会趋于一致
Redis的集群原理
如何从海量数据里快速找到所需?
