zhusihua920712的博客

三种更新策略： 先更新数据库，再更新缓存（线程不安全） 1、线程A更新了数据库； 2、线程B更新了数据库； 3、线程B更新了缓存； 4、线程A更新了缓存； 数据库是B写入的值，而缓存中是A写入的旧值 写多读少的场景，频繁写缓存很浪费性能； 先删缓存，再更新数据库（线程不安全） 1、线程A删除了缓存； 2、线程B查询缓存发现不存在； 3、线程B更新了缓存； 4、线程A写入了数据库； 数据库是A写入的值，而缓存中是B写入的旧值 可以使用延时双删策略进行优化； 延时双删： 先删..

缓存穿透 问题原因： 查询一个缓存中和数据库都一定没有的值，有人可以利用不存在的Key发起大量请求，攻击数据库； 解决方案： 数据库如果也查不到这个值，可以往缓存中回写一个空值，设置一个非常短的过期时间，防止同一时间，大量并发请求打到数据库，导致数据库瘫痪； 增加布隆过滤器，类似于hashSet，将所有存在的值放到布隆过滤器里，迅速判断key值的数据是否存在； 缓存击穿 问题原因： 一个非常热点Key，扛着大量的并发请求，某一时刻，Key失效，大量请求打到数据库； 解决方案： 热点Key设

RDB 优点： 结构紧凑，全量备份，适合容灾恢复与备份； 生成RDB文件时，redis会根据主进程fork一个子进程进行保存，主进程还可以继续读写操作； RDB恢复大数据量时比AOF要快； 缺点： 子进程保存RDB文件时，主进程还在继续读写，有可能会丢失数据； AOF redis会将每一个收到的写命令都通过write函数追加到AOF文件； aof触发机制： always：每次修改完同步，性能较差，数据完整性好； everysec：异步，每秒记录，一秒内宕机，会有数据丢失； no：从不同步

5种数据结构： String：简单的KV存储； Hash：存结构化数据； List：有序列表，可以做为消息队列，可以实现区间查询； Set：无序集合，自动去重； ZSet：排序后的Set； 基础知识： Ziplist 压缩列表，redis特有数据结构，list、hash、zset底层数据结构，在元素个数小于某个值时，数据结构会变成ziplist； 为什么压缩列表节省内存？ 记录了每个数据的大小，即偏移量，通过偏移量来取下一个数据，省去了碎片空间，并且省去了头尾指针，共16字节； L.