热Key问题
热key问题就是，突然有几十万的请求去访问redis上的某个特定key。那么，这样会造成流量过于集中，达到物理网卡上限，从而导致这台redis的服务器宕机。
如何发现热key
- 凭借业务经验，进行预估哪些是热key
- 在客户端进行收集
在操作redis之前，加入一行代码进行数据统计。 - 在Proxy层做收集
- 用redis自带命令
- monitor命令，该命令可以实时抓取出redis服务器接收到的命令，然后写代码统计出热key是啥。但是该命令在高并发的条件下，有内存增暴增的隐患，还会降低redis的性能。
- hotkeys参数，redis 4.0.3提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。但是该参数在执行的时候，如果key比较多，执行起来比较慢。
- 自己抓包评估
热key解决
利用二级缓存
比如利用ehcache，或者一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中。备份热key
在key上加上随机数，在多个redis上都存一份。
业内解决方案
有赞透明多级缓存解决方案（TMC）
- Jedis-Client： Java 应用与缓存服务端交互的直接入口，接口定义与原生 Jedis-Client 无异；
- Hermes-SDK：自研“热点发现+本地缓存”功能的SDK封装， Jedis-Client 通过与它交互来集成相应能力；
- Hermes服务端集群：接收 Hermes-SDK 上报的缓存访问数据，进行热点探测，将热点 key 推送给 Hermes-SDK 做本地缓存；
- 缓存集群：由代理层和存储层组成，为应用客户端提供统一的分布式缓存服务入口；
- 基础组件： etcd 集群、 Apollo 配置中心，为 TMC 提供“集群推送”和“统一配置”能力；
读写分离架构
架构中个节点的作用：
1）SLB层做负载均衡
2）Proxy层做读写分离自动路由
3）Master负责写
4）ReadOnly节点负责读请求
5）Slave节点和Master节点做高可用
热点数据解决方案
Proxy架构的主要优点有：
1）Proxy缓存热点，读能力可水平扩展
2）DB自动计算热点Key
3）对客户端完全透明，不需要做任何兼容
DB计算热点时，主要运用的方法和优势有：
1）基于统计阀值的热点统计。
2） 基于统计周期的热点统计。
3） 基于版本号实现的无需重置初值统计方法。
留言
