Redis笔记，涵盖了 Redis 所有知识点，拿走不谢( 二 ) _Redis

这时候如果允许短期的数据不?致不会影响业务，那么只要下次更新时可以成功，能保证最终?致性就可以，那么可以不用再做处理。
如果还要再完美，可以捕捉删除缓存异常增加重试，对耗时敏感的可以进行异步补偿重试，即放到mq里面监听，但是这样对业务侵入性比较大，也可以采用监听MySQL binlog日志的方式进行重试。
十、布隆过滤器

文章插图

原理：
一个元素被加入到集合时，通过k个哈希函数将这个元素映射成一个位数组中的k个点，把它们设置为1 。
检索时，看这些位置是不是为1就知道这个元素在不在集合中了，如果都是1则可能存在，如果有一个是0则一定不存在。
缺点：

存在误判的肯定，可通过建立白名单来存储误判的元素
删除困难，初始化要把所有合法元素加到过滤器中，删除时设置为0可能会影响其他元素的判断，可通过Count Bloom Filter

十一、高并发更新同一个key问题

使用zookeeper分布式锁保证线程安全
如果也要更新数据库，涉及到双写，就会出现数据一致性问题，可以参考上面的删除key
如果不能删除key，则在更新缓存时比较数据的更新时间

十二、持久化方式：RDB（全量持久化）

记录内存快照的方式
使用bgsave，fork一个子进程进行，不会阻塞set操作，类似于GC的守护进行
Copy On Write，写时复制机制，备份的时候发生写入操作，则备份的是写入之前的数据，所以会有数据丢失
定期进行，一般是5分钟一次，断电可能会丢失较多数据
恢复块、备份久
可能把RDB快照文件定期放到远程存储，一般做冷备
RDB备份的文件体积小，恢复很快

十三、持久化方式：AOF（增量持久化）

日志追加的方式，类似于MySQL innoDB引擎中redo.log，备份当前操作命令
恢复慢、备份块
会不会丢失数据取决于Appendfsync配置，配置为实时备份则每次写操作都会备份，性能低，一般是配置为每秒一次，这样最多是丢失一秒的数据
适合做灾备
随着时间增长，AOF文件会越来越大，Redis提供了日志重写功能，可以压缩命令，重写后新的AOF文件仅包含旧AOF文件命令的最小集合
AOF备份的文件体积大，即使经过重写，仍然很大，恢复很慢

Redis 4.0后使用了RDB+AOF混合持久化模式，生成RDB文件重新记录，这时AOF日志不再是全量的，而是增量的日志记录，体积很小。
十四、Redis过期策略
Redis需要删除失效的数据以清空内存，过期策略就是怎么删除过期数据。

定期删除：默认每隔100ms随机抽取部门设置了过期时间的key，检查key是否失效，失效了就删除。（不全部检查是因为效率低，类似于MySQL全表扫描）
惰性删除：当应用程序来查key的时候，检查到key失效就会删除，未失效就返回。

Redis使用定期删除+惰性删除，能保证最终一定会删除过期的key，但是定期删除会有漏网之鱼，而应用程序又很久没来查询就会导致长时间滞留在内存之中，这时需要用到内存淘汰机制。
十五、Redis内存淘汰机制
FIFO：First In First Out，先进先出
LRU：Least Recently Used，最近最少使用，从时间上看很久没有使用的被淘汰
LFU：Least Frequently Used，最不经常使用，从次数上看使用得最少的被淘汰