redis热点key的解决

热Key的解决办法

1、如果热点key的QPS过高，单机是扛不住的，要做一个读写分离（主库用来写，从库用来读），再加一个从库。

2、

但是如果热key本身的数量是比较少的，可以考虑做一个多级缓存，可以添加一个本地缓存。

 本地缓存也是一个最常用的解决方案，既然我们的一级缓存扛不住这么大的压力，就再加一个二级缓存吧。由于每个请求都是由service发出的，这个二级缓存加在service端是再合适不过了，因此可以在服务端每次获取到对应热key时，使用本地缓存存储一份，等本地缓存过期后再重新请求，降低redis集群压力。
 

 利用二级缓存

比如利用ehcache，或者一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中。
针对这种热key请求，会直接从jvm中取，而不会走到redis层。
假设此时有十万个针对同一个key的请求过来,如果没有本地缓存，这十万个请求就直接怼到同一台redis上了。
现在假设，你的应用层有50台机器，OK，你也有jvm缓存了。这十万个请求平均分散开来，每个机器有2000个请求，会从JVM中取到value值，然后返回数据。避免了十万个请求怼到同一台redis上的情形。 

3、但是面对可能突然成为热Key的问题，本地缓存缓存不了所有的商品。那么这里可能就要用到热key的探查技术，这样本地就能值缓存热key。之前看过某公司的分享，他们是在客户端和redis之间添加了一层proxy，这个proxy会去做所有key的访问频率统计，如果发现哪个Key达到了热key的标准就会推送到客户端的SDK上，客户端拿到这些key之后就会做一个本地缓存。阿里云的redis是自带了这个功能，有一层proxy自动去检测热key，但是它检测到热key后是直接缓存在proxy里面而不是推送给客户端。

为什么在proxy里面统计这个热key不在客户端里面统计

在集群环境下，所有的流量都分散了，那么客户端对热key的检测就没那么灵敏真实了。另外，让客户端去统计热key的话客户就要去存所有key的一个相关统计情况，这也会很占用我们客户端的内存，我们还是本着最小粒度原则——一个服务只做一件事，我们用proxy来做这件事，如果哪天proxy成为了瓶颈我们就横向扩展proxy，这样性价比也会比较高。客户端那边会根据key的hash来决定每个请求具体落在了哪一个proxy上，这样每个proxy对每个key的流量感知都会变得更加敏感。

上面提到了用本地缓存，那如果redis的数据和本地缓存的数据不一致会带来什么问题，怎么办？

我们选择用了本地缓存，就相当于默认了缓存的时效性，值得注意的是我们不要根据缓存去做一些逻辑的判断。比如像先读后写数据库的操作，如果我们读到的是redis上的数据，我们只能用reidis的一些原子操作，比如原子增，原子减，sentx这些操作来判断之后要不要进行一些新的操作。如果我们是以数据库的数据为准的话我们就不能用redis的数据来判断，我们要数据库的事务、乐观锁这些执行情况来做判断，就是要记住缓存只能用来查不能用来做判断。