一、缓存之王Caffeine的三大核心结构
(1)、为什么能够实现最高400wqps超高吞吐超高并发，和超高并发的数据结构有关系
①、striped buffer条带环形队列：使用在缓存读日志(读操作) 高并发读队列场景
②、海量任务调度5级时间轮：使用在海量缓存记录过期管理场景
③、JCTool的Mpsc超高性能无锁队列：使用在缓存写日志(写操作)高并发写入队列场景。
二、hotKey出现典型业务场景，解决方案
预期外的访问量抖增，如突然出现的爆款商品，访问量暴涨的热点新闻，直播间某大主播搞活动大量的刷屏点赞。
原因分析：
数十万的访问请求同一个key，流量集中打在一个缓存节点机器，这个缓存机器很容易被打到物理网卡，宽带，CPU的极限，从而导致缓存访问变慢，卡顿。从而导致分布式缓存性能变差，缓存击穿，缓存雪崩的问题。因为hotkey的吞吐量实在太大，物理资源是有限的。
普通hotkey的场景：
可以提前评估出hotkey的场景
比如一些Saas系统中，部门组织机构数据，租户基础数据
对于重要节假日，线上促销活动，集中推送这些提前已知的事情
解决方案：
①、多副本的方案：可以将这些热key进行分散处理，比如一个热key的名字叫做hotkey，可以分散为hotkey1,hotkey2,hotkey3,...hotkeyn,这n个key分散存在多个缓存节点。
然后client端请求时，随机访问其中某个后缀的hotkey，这样就可以把热key的请求打散，避免一个缓存节点过载。
②、本地缓存HotKey，通过发布订阅解决数据一致性问题，提前进行本地缓存的预加载。用户的访问的时候尽量命中本地缓存。这时就不会访问分布式缓存。这就不存在物理资源不够的情况
需要解决两个问题：
本地缓存的预热
通过发布订阅解决本地缓存解决redis,db数据一致性问题
突发性Hotkey场景：
不可以提前评估出hotkey场景：
预期外的访问量抖增，如突然出现的爆款商品，访问量暴涨的热点新闻，直播间某大主播搞活动大量的刷屏点赞。
比如最近新闻，新发表的微博被访问的频率最高，而比较久远的之前的新闻，微博被访问的频率就会小很多。而在突发事件发生时，大量的用户同时去访问这个突发热点信息，访问这个hotkey。
这个突发热点信息所在的缓存节点就很容易出现过载和卡顿现象，甚至会出现crash崩溃。
hotkey引发缓存系统异常，主要因为突发热门事件发生时，超大量的请求访问热点事件对应的key，比如微博中数十万，数百万的用户同时去吃一个新瓜。
解决方案：
①、多副本的方案：可以将这些热key进行分散处理，比如一个热key的名字叫做hotkey，可以分散为hotkey1,hotkey2,hotkey3,...hotkeyn,这n个key分散存在多个缓存节点。
然后client端请求时，随机访问其中某个后缀的hotkey，这样就可以把热key的请求打散，避免一个缓存节点过载。
②、本地缓存HotKey，通过发布订阅解决数据一致性问题，提前进行本地缓存的预加载。用户的访问的时候尽量命中本地缓存。这时就不会访问分布式缓存。这就不存在物理资源不够的情况
关键点在于hotkey在线计算和识别
方案：流式计算框架：storm/flink：在核心的底层原理参考storm
高并发的hotkey计算中间件：基于时间窗原理实现的，京东双十一所采用的方案，经过生产考验的。
