解决方法三步走（Tair为例）
1. 热点识别：是读写热点方案的基础；
- 热点可以分为两类（QPS热点和流量热点）
- 服务端每个实例独立统计，在采样的时间周期结束后统一上报，后台计算
- 热点算法(lfu lru)
2. 读热点方案：
- 服务端
- 每个实例在原有的存储之外增加一块新的HotZone区域，用来存储全部的热点数据；
- 每个实例中的热点数据相同；
- 用随机负载均衡读热点数据，这样客户端读热点是会散列到整个集群，不存在单点读热点；
- 客户端
- 初始化时随机选择一个HotZone，在集群配置不变的情况下不会改变选择，即每个客户端只会访问唯一的HotZone区域；
- 访问热key时首先访问HotZone区域，数据不存在则继续请求源数据节点，获取数据后异步将数据存到HotZone节点；
- 客户端本地存一份带过期时间的key，过期后到源数据节点读取，若不是热点了，则恢复常规访问模式。
3. 写热点方案
/待补充/
热点发现四个维度：
- 客户端： 统计汇总
- 代理层： codis twemproxy
- 服务端： 统计单个节点后汇总（tair也是通过服务端独立统计后统一计算）
- monitor命令，redis-faina工具，高并发下会存在内存暴增影响redis性能
- redis-cli -hotkeys参数，redis4.0.3提供热key发现功能
- 机器TCP流量：抓包分析->kafka->flink->res
热点解决方案
- 多副本，服务端分散热点，每个实例都存有相同的热点（redis中可以hotkey+random生成一个新的key，rehash到集群中）
- 多级缓存，客户端分散热点，每个客户端订阅热点channel，更新本地缓存
- 可以思考一下tair的方案是哪一种~~~
参考
理解有误的地方希望可以交流指正
