如何探测热点key
客户端：例如在客户端设置全局字典（key和调用次数），每次调用Redis命令时，使用这个字典进行记录。缺点是1.无法预知key的个数，存在内存泄露的危险。2.对于客户端代码有侵入，各个语言的客户端都需要维护此逻辑，维护成本较高
服务器：使用monitor命令统计热点key，monitor 命令可以监控到Redis执行的所有命令。但是monitor命令在高并发条件下，会存在内存暴增和影响Redis性能的隐患，所以此种方法适合在短时间内使用。
代理端：基于代理的Redis分布式架构，所有客户端的 请求都是通过代理端完成的。此架构是最适合做热点key统计的，因为代理是所有Redis客户端和服务端的桥梁。但并不是所有Redis都是采用此种架构。
机器：Redis客户端使用TCP协议与服务端进行交互，如果站在机器的角度，可以通过对机器上所有Redis端口的TCP数据包进行抓取完成热点key的统计。此种方法对于Redis客户端和服务端来说毫无侵入，但是开发维护成本高
热点key三种方案
1.拆分复杂数据结构：该热点key可以拆分为若干个新的key分布到不同Redis节点上，从而减轻压力。
2.本地缓存加通知机制：可以将热点key放在业务端的本地缓存中，但当数据更新时，此种模式会造成各个业务端和Redis数据不一致.
3.迁移热点key：以Redis Cluster为例，可以将热点key所在的slot单独迁移到一个新的Redis节点上，但此操作会增加运维成本。
热点key重建优化
·当前key是一个热点key，并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算.
以上两种情况同时出现时，在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。
重建优化
参考：《redis开发与运维》
