Redisson、Jedis、Lettuce
缓存失效策略
**主动失效**
系统有一个主动检查缓存是否失效的机制
比如通过定时任务或者单独的线程不断的去检查缓存队列中的对象是否失效
优点是能够避免内存的浪费；缺点是会占用额外的CPU时间。
**被动失效**
请求访问缓存对象的时候才去检查缓存是否失效
优点是系统占用的CPU时间更少；缺点是长期不被访问的缓存对象不会被系统清除，一直占用内存
缓存淘汰策略
**FIFO**
先进先出策略；一般用链表实现。
**LRU**
最近最久未使用淘汰策略；常见的是通过优先队列来实现。
**LFU**
最近最少使用淘汰策略；常见的是通过优先队列来实现。
缓存穿透、缓存击穿、缓存雪崩的区别
缓存穿透
缓存的值为空、null；导致系统以为没取到值
访问DB和缓存都不存在的数据（比如访问id= -1的数据），导致每次访问DB
解决：放入一个特殊对象（比如特定的无效对象，当然比较好的方式是使用包装对象）、也可以采用特殊值（比如-1代表不存在）
缓存击穿
在缓存失效的瞬间大量请求，造成DB的压力瞬间增大
解决：查DB，更新缓存时用锁锁住服务，防止请求穿透直达DB
缓存雪崩
大量缓存同时失效；比如同一时间过期，同一时间大量新缓存涌入，大量旧的被淘汰，造成服务瞬间性能急剧下降
解决：过期时间使用基本时间加上随机时间，增加缓存服务器。
布隆过滤器
将可能查询的key以哈希的方式存储起来，以后的查询在控制层进行效验，不符合的就丢弃。
缓存的存储策略
出现的问题
当采用hash/n 取模方式确定cache服务器节点。这时如果出现某节点宕机，或需要增加节点。n+1那么全部缓存都失效了
一致性hash算法（分布式缓存、分布式Session、负载均衡策略）
定义
服务器编码的hash值对232取余，根据余数将服务器映射到对应hash环的点上，存储数据key的hash值对232取余，并映射到相同hash环的点上。从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上
缺点：数据倾斜（哈希偏斜）问题；在服务节点太少时，容易因为节点分部不均匀而造成数据倾斜（被缓存的对象大部分集中缓存在某一台服务器上）
解决：引入虚拟节点，多个虚拟节点映射一个真实节点（环上节点多了，分布也就均匀了）
如何保证读写一致性
先更新数据库，再删除缓存
更新DB成功，删除缓存失败或者还没有来得及删除，其他线程从缓存中读取到的就是旧值，还是会发生不一致。
解决：消息队列；但是问题更多，怎么保证消息不丢失、消息的延迟也会带来短暂的不一致性，不过这个延迟相对来说还是可以接受的。不推荐
先删缓存，再更新数据库
线程1 删缓存，正准备更新DB时；线程2进来查缓存无数据，将DB的旧数据查出并更新缓存，这时线程2才更新DB成功。
解决：延迟双删。 删缓存，更新DB，隔一段时间再删缓存
因为缓存的写入通常要远远快于数据库的写入，所以在实际中(数据库 => 缓存)的方案是优于(缓存 => 数据库)的。
为什么是删除，而不是更新缓存？
如果数据库1小时内更新了1000次，那么缓存也要更新1000次，但是这个缓存可能在1小时内只被读取了1次，那么这1000次的更新有必要吗？
1、延迟双删
2、给缓存数据加上过期时间
3、如有需要: 在更新缓存前加分布式锁，保证同一时间只运行一个请求更新缓存，当然锁会影响写入的性能。
mysql缓存
建议不要使用查询缓存，因为查询缓存往往弊大于利。
查询缓存失效非常频繁，当执行insert/update/delete操作或close之后，缓存都会被清空，对于更新压力大的数据库，缓存使用效率非常低，
MySQL 8.0 版本直接将查询缓存的整块功能删掉了，也就是说 8.0 开始彻底没有这个功能了
除非是静态表（配置表）、官网等查询多的表适合使用查询缓存。
redis，数据库引擎用MyISAM
一级缓存失效的四种情况：
1.sqlSession不同。
2.sqlSession相同，查询条件不同。因为缓存条件不同，缓存中还没有数据。
3.sqlSession相同，在两次相同查询条件中间执行过增删改操作。（因为中间的增删改可能对缓存中数据进行修改，所以不能用）
4.sqlSession相同，手动清空了一级缓存。
