你的系统有热点缓存问题吗？如何为系统设计缓存架构？

目录

（1）为什么要用缓存集群
（2）20万用户同时访问一个热点缓存
（3）基于流式计算的缓存热点自动发现
（4）热点缓存自动加载为JVM本地缓存
（5）限流熔断保护
（6）总结

这篇文章，跟大家讲讲站在一个程序员的角度，自己的后台架构应该如何抗住一天3个热点涌入的巨大流量！

（1）为什么要用缓存集群

其实使用缓存集群的时候，最怕的就是热key、大value这两种情况，那啥叫热key大value呢？

简单来说，热key，就是你的缓存集群中的某个key瞬间被数万甚至十万的并发请求打爆。大value，就是你的某个key对应的value可能有GB级的大小，导致查询value的时候导致网络相关的故障问题。

我们先来看看下面一幅图，假设你手头有个系统，他本身是集群部署的，然后后面有一套缓存集群，这个集群不管你用redis cluster，还是memcached，或者是公司自研缓存集群，都可以。

那么，这套系统用缓存集群干什么呢？

很简单，在缓存里放一些平时不怎么变动的数据，然后用户在查询大量的平时不怎么变动的数据的时候，不就可以直接从缓存里走了吗？

缓存集群的并发能力是很强的，而且读缓存的性能是很高的。举个例子，假设你每秒有2万请求，但是其中90%都是读请求，那么每秒1.8万请求都是在读一些不太变化的数据，而不是写数据。

那此时你把这些数据都放在数据库里，然后每秒发送2万请求到数据库上读写数据，你觉得合适吗？

当然不合适了，如果你要用数据库承载每秒2万请求的话，那么不好意思，你很可能就得搞分库分表 + 读写分离。

比如你得分3个主库，承载每秒2000的写入请求，然后每个主库挂3个从库，一共9个从库承载每秒1.8万的读请求。

这样的话，你可能就需要一共是12台高配置的数据库服务器，这是很耗费钱的，成本非常高，很不合适。

大家看看下面的图，来体会下这种情况。