Redis

Redis诞生背景

关系型数据库据中一大半操作都是读操作,而且经常都是重复查询一个东西,这浪费了数据库很多时间去进行磁盘I/O.这也是后续很多内存数据库崛起的背景.

学习CPU给数据库也加一个缓存,诞生了Redis.应用程序从mysql查询到的数据,先在redis登记,后续再有读请求,先在redis进行查询.redis把数据都存储在内存内存中不需要进行磁盘I/O,所以速度极快.为Mysql减轻了很大的负担.

Redis缓存管理机制

防止缓存无限制增加,给缓存增加一个超时时间,超出超时时间的内容进行清空.

考虑到缓存中存了大量数据,全面扫描一次进行清理需要很长时间,严重影响接受新的请求,所以Redis采取随机选取部分进行清理.

但是概率上会存在部分数据可能长时间不被清理掉.于是在原来定期删除的基础之上,增加:原来已经超期的键值,如果遇到查询请求,则立即进行删除.这是被动式触发,如果不查询就不会删除,因此叫惰性删除.

还会有一部分数据既逃离了随机删除算法也逃离了惰性删除,慢慢的可用的内存空间则会越来越少,(或者设置过期时间很长,还没来得及清理,内存就吃满了),-出现内存淘汰策略

结合以上策略,可以不用担心内存爆满的问题

定时删除 + 惰性删除 + 内存淘汰

缓存穿透:如果查询数据不存在,那么redis也没办法缓存,所以同样的请求来了,每次还是需要mysql进行查询,(如果存在大量重复的恶意或者批量查询,严重影响数据库性能)

热点数据过期,被redis删除,但是删除后短时间内大量请求,就会都到mysql服务器

缓存雪崩:如果一大批数据同时或者一起过了有效期,又发生了很多对这些数据的请求,比起缓存穿透规模更大

解决缓存雪崩的方案:让应用程序对缓存过期时间设置的长一点均匀一点,不让缓存一起过期.把键值的过期时间随机一下+热点数据永不过期

Redis持久化存储机制

Redis为基于内存的,进程服务down掉内容丢失.需要做持久化存储

持久化方案:RDB持久化是将全部数据记录定时dump到磁盘上进行持久化，恢复数据通过读取原始数据加载到内存恢复数据，数据恢复快，效率高，但是数据容易丢失（数据同步有时间间隔）.

为了节约空间,二进制格式生成RDB文件,但是数据量大,全部备份时间成本较高,不能太频繁备份.如果一直都是读取操作没有写入操作,也不需要重复备份.提供周期性备份参数.即使断电或者服务器宕机,可以在启动的时候读取备份文件,恢复状态

RDB的问题:数据丢失问题

AOF持久化是将操作日志追加形式写入文件，恢复数据通过命令恢复数据，缓存一致性更高，牺牲性能.

Mysql中的BinLog => AOF

多久进行一次写入呢? 建立临时缓冲区aof_buf 再择机将临时缓冲区内容写入文件

但是随着时间推移,AOF备份文件越来越大,加载分析越来越慢

AOF重写:去除冗余指令给AOF文件瘦身,- 工作量太大

指令合并

Redis哨兵与高可用

即使有了缓存持久化管理,但是也要考虑redis稳定性高可用问题

命令传播:主节点将命令传播给从节点

考虑到子节点掉线,数据同步问题

从节点中选择一个管理员,不负责数据的读写,只负责协调各个节点,称为哨兵Sentinel

哨兵每隔10s中用info命令去询问主节点,主节点回复都有哪些从节点,哨兵则每隔一秒用ping命令与各个子节点交互.如果发现主节点掉线,这时候判定为主观下线,多个哨兵一起判定,如果都认为下线则是客观下线

故障转移选择新的主节点

Redis集群工作原理

主从复制+哨兵可以解决高可用问题,但是不能解决数据量大的问题

变成集群解决数据量大的问题

存储公平问题  -hash随机性