400W级qps本地缓存Caffeine初探：
同一key的场景：每秒操作/查询的次数
与ConcurrentHashMap和guava做对比，Caffeine:吞吐量接近400w/qps
不同key的场景：
Caffeine:吞吐量接近200w/qps
本地缓存的使用场景：
在高并发应用当中，首先会使用分布式缓存：分布式缓存的两大问题：
首先Java应用作为客户端，它会访问分布式缓存，如果分布式缓存没有就回原到db，
然后再存储到redis。mysql的吞吐量是1.5k-2k的并发量,单节点redis有5w的吞吐
量，不至于发生DB的雪崩，和打挂。
前提：所有的key分布在比较均匀的。但是大部分在生产环境情况下流量是不均匀
的。
1、hotkey：突发性的hotkey导致对于分布式缓存性能变差，缓存击穿，缓存雪崩
的问题.
①、缓存穿透：我们查DB和缓存的数据都不存在，这样每次请求直接打到数据
库，就好像缓存有和没有都一样，数据库的穿透，db当中都没有数据， 数据库集
群发生雪崩，最终导致服务雪崩。
②、缓存击穿：我们出现了一个并发访问量比较大的key在某个时间过期，导致所
有的请求直接打到DB上当这个key在失效的瞬间，大量的请求就击穿了缓存，直接
请求到数据库，数据库集群发生雪崩，最终导致服务雪崩。
③、缓存雪崩：某一时刻发生大规模的缓存失效，例如缓存服务宕机，大量的请求
达到数据库，导致数据库雪崩，最终导致服务雪崩。
热key带来的问题：
①、热key占用大量的Redis CPU的时间，使其性能变差，并影响其他请求。
②、当一个hot key在失效的瞬间，大量的请求就击穿了缓存，就直接请求到数据
库，DB打垮，数据库的雪崩。服务的雪崩。hotkey和普通的key的缓存击穿不一
样。因为流量很大，很容易导致数据库雪崩。
③、热key的请求压力数量超出Redis的承受压力，造成缓存响应严重变慢，甚至缓
存无响应，甚至发生雪崩，DB打挂，并影响导致平台整体的雪崩，甚至其他的系
统都雪崩。
2、bigkey：极个别的数据量非常大的key
