redis热点缓存优化

一、为什么要用缓存集群

假设系统的QPS是2W，90%是读请求，也就是1.8W是请求读数据，2000是请求写数据。如果没有缓存集群，这2W的QPS都会被请求到数据库上。目前，CPU 2个CPU 24核心 2GHZ，内存 16G swap 15G 硬盘 300G，mysql版本 5.7 QPS：21833，也就是说仅2W的请求，就需要很好的数据库服务器。而且，这么高的QPS到达数据库后，需要设计分库分表，主从设计等，配置一主二从，数据库服务器需要至少3台，开销太大了。

采用缓存集群，假设1.8W请求中，有5%被请求到数据库，数据库整体的并发量在2900左右，一台数据库服务器就完全可以满足需求，整体成本会下降很多。

二、缓存数据热点问题

假设缓存集群有5个实例，每个实例能够满足10万的并发请求，现在有20万请求进来，如果缓存的key平均分布在5个实例上，每个实例也就4万的请求量，远低于10万的限制。但是如果存在某种问题，大量的用户访问同一条缓存数据，这10万请求到到达同一个实例，这个实例就会崩溃。因为这个实例的崩溃，请求就会进入后端服务，如果服务没有做熔断，服务就会崩溃；如果服务有熔断，因为有缓存实例的减少，会导致其他实例压力增大，甚至引起雪崩。

三、怎么发现热点缓存数据

要解决缓存热点数据问题，首先是如何找到热点数据。一般出现缓存热点的时候，每秒并发肯定是很高的，可能每秒都几十万甚至上百万的请求量过来，这都是有可能的。所以，此时完全可以基于大数据领域的流式计算技术来进行实时数据访问次数的统计，比如storm、spark streaming、flink，这些技术都是可以的。然后一旦在实时数据访问次数统计的过程中，比如发现一秒之内，某条数据突然访问次数超过了1000，就直接立马把这条数据判定为是热点数据，可以将这个发现出来的热点数据写入比如zookeeper中。

四、如何处理热点缓存数据

发现了热点数据，就完全可以在JVM层面对这些数据做处理，利用内存的高速解决过热问题。当发现热点数据的时候，可以通过监听znode，将数据再入本地缓存的Map或者cache中。

整体的架构图可以变为（from https://juejin.im/post/5c448670e51d455bd36b67f9）：