热点缓存的架构优化
使用缓存集群的时候,最怕的就是热key、大value这两种问题。热key问题,指的就是缓存集群中的某个key在瞬间被数万甚至十万的并发请求打爆。大value问题,指的是某个key对应的value可能有gb级别的大小,导致查询value的时候会引发网络相关的故障问题。这里说一下热key问题。 为什么要使用缓存集群 简单来说,假设你手头上有个系统,它本身是集群部署的,然后后面有一套缓存集群,这个集群不管你用Redis Cluster,还是Memcached,或者是公司自研缓存集群,都可以。 那么这套系统用缓存集群做什么呢?很简单,在缓存放一些平时不怎么变动的数据,然后用户在查询大量的、平时不怎么变动的数据的时候,就可以直接访问缓存而不需要访问数据库了。缓存集群的并发能力很强,而且读缓存的性能也很高。举个例子,假设每秒钟有2万的请求,但是其中的90%都是读请求,那么每秒钟1.8万的请求都是在读一些不太变化的数据,而不是写数据。此时,如果你把数据都放在数据库里,然后每秒钟发送2万个请求到数据库上读写数据,显然是不合适的,因为如果要数据库能承载每秒2万个请求的话,很可能就需要搞分库分表+读写分离。比如,你需要分出来3个主库去承载每秒2000的写入请求,然后每个主库挂3个从库,一个9个从库去承载每秒1.8万的读请求。那么这样你就需要一共是12台高配置的数据库服务器,成本非常高,而且很不合适。