1. redis的应用场景 [1]
1.1 热点数据的缓存 ---> 访问速度快、支持的数据类型比较丰富;
1.2 限时业务的运用 ---> 可以使用expire命令设置一个键的生存时间,到时间后redis会删除它;
1.3 计数器相关问题 ---> incrby命令可以实现原子性的递增;
1.4 排行榜相关问题 ---> 关系性数据库在排行榜方面查询速度普遍偏慢,剋借助redis的DSortedSet进行热点数据的排序;
1.5 分页、模糊查询 ---> ZRANGEBYLEX key min max [LIMIT offset count]
2. redis支持的数据类型(重点)[2]
Redis支持五种数据类型:string(字符串)、hash(哈希)、list(列表)、set(集合) 及zset(sorted set:有序集合)。
3. zset跳表的数据结构(重点)[3]
跳表:链表加多级索引的结构;
跳表的作用:提高效率;
4. redis的数据过期策略(重点)[4]
定时删除、惰性删除、定期删除;
5. redis的LRU过期策略的具体表现 [5]
6. 如何解决redis缓存雪崩,缓存穿透问题 [6]
缓存穿透:恶意访问缓存中不存在的key,导致大量请求直接落到数据库中;
缓存雪崩:缓存在同一时间大量键过期(失效),接着来一大波请求瞬间落在了数据库中导致连接异常;
7. redis的持久化机制(重点)
RDB持久化机制,对redis中的数据执行周期性的持久化;
AOF机制对每条写入命令作为日志,以append_only的模式写入一个日志文件中,在redis重启的时候,可以通过回放AOF日志中的写入指令来重新构建整个数据集;
7.1 比较
> RDB数据做冷备,在最坏的情况下,提供数据恢复的时候,速度比AOF快;
> RDB,每次写,都是直接写redis内存,只是在一定的时候,才会将数据写入磁盘中;
> AOF,每次都是要写文件的,虽然可以快速写入os cache中,但是还是有一定的时间开销的,速度肯定比RDB略慢一些;
> 相对于AOF持久化机制来说,直接基于RDB数据文件来重启和恢复redis进程,更加快速;
RDB | AOF | |
优点 | 1.RDB会生成多个数据文件,每个数据文件都代表了 某一个时刻中redis的数据 2. RDB对redis对外提供的读写服务,影响非常小,可 以让redis保持高性能 3. 相对于AOF持久化机制来说,直接基于RDB数据文件 来重启和恢复redis进程,更加快速 | 1.AOF可以更好的保护数据不丢失 2.AOF日志文件以append-only模式写入 3. AOF日志文件即使过大的时候,出现后台重写操作, 也不会影响客户端的读写 4. AOF日志文件的命令通过非常可读的方式进行记录, 这个特性非常适合做灾难性的误删除的紧急恢复 |
缺点 | 1. 如果想要在redis故障时,尽可能少的丢失数据,那么 RDB没有AOF好 2. RDB每次在fork子进程来执行RDB快照数据文件生成 的时候,如果数据文件特别大,可能会导致对客户端提供 的服务暂停数毫秒,或者甚至数秒 | 1.对于同一份数据来说,AOF日志文件通常比RDB数据 快照文件更大 2. 对于同一份数据来说,AOF日志文件通常比RDB数据 快照文件更大 3. 以前AOF发生过bug,就是通过AOF记录的日志,进行 数据恢复的时候,没有恢复一模一样的数据出来 4. 唯一的比较大的缺点,其实就是做数据恢复的时候,会 比较慢,还有做冷备,定期的备份,不太方便,可能要自己 手写复杂的脚本去做,做冷备不太合适 |
7.2 总结
总结 | 1.不要仅仅使用RDB,因为那样会导致你丢失很多数据 2.也不要仅仅使用AOF,因为那样有两个问题,第一,你通过AOF做冷备,没有RDB做冷备, 来的恢复速度更快; 第二,RDB每次简单粗暴生成数据快照,更加健壮,可以避免AOF这种复 杂的备份和恢复机制的bug 3. 综合使用AOF和RDB两种持久化机制,用AOF来保证数据不丢失,作为数据恢复的第一选择; 用RDB来做不同程度的冷备,在AOF文件都丢失或损坏不可用的时候,还可以使用RDB来进行快 速的数据恢复 |
8. redis的管道pipeline
数据包从客户端传输到服务端,以及客户端从服务端获得相应都需要花费一些时间。这段时间就成为往返时延(Round Trip Time),管道可以一定程度上缩短往返时间,提高性能;
【注】
> 原子性操作
> redis的 SortedSet 操作
> 关系型数据库 与 非关系型数据库 的区别
【参考文献】
[1] https://www.jianshu.com/p/40dbc78711c8
[2] https://www.php.cn/redis/421950.html
[3] https://www.jianshu.com/p/c706d050d2f8
[4] https://blog.csdn.net/Shreck66/article/details/88665882
[5] https://www.jianshu.com/p/c8aeb3eee6bc
[6] https://blog.csdn.net/fanrenxiang/article/details/80542580