一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第27天，点击查看活动详情。
提到热点数据，无非就是说访问量比较大，一提到访问量比较大，大家第一个会想到使用缓存。
举个例子，为什么缓存也不可靠，假如有四个商品库，分别是 DB_0、DB_1、DB_2、DB_3。假如发起查询请求，根据商品 ID 查询某个商品，不管这个查询是不是热点，对于像商品详情页这种访问量非常高的这个场景来说，我们都倾向于把商品的一部分数据放到缓存当中，缓存一般缓存数据库当中所有的数据，这个实现方式是我们开发当中最常使用的方式。
问题来了，如果每台物理数据库，它的数据量是 100 万条。这个架构似乎看起来还是可行的。当每一个分库当中有 1000 万条数据，此时总共就有 4000 万条数据，这个勉强还有接受。
像阿里云这样的电商的数据都是以亿为单位，对于这样的数据量来说，还可以用一个中心化的缓存来把这些数据全部都存储上吗？不用等热点数据出现，普普通通的数据量就会把缓存的这种架构模式给它击垮。
在真正的高并发场景下面，我们使用怎么样的方式呢？缓存其实也是可以做分区的，根据不同的查询维度，可以把不同的数据缓存在不同的缓存分区当中，这是我们在生产环境当中常用的一个场，这样实现方式可以把普通的商品缓存存储问题给解决了。
假设在电商平台上销售一个全民抢购的商品，这个电商平台搭建三个缓存服务，分别是 cache_0、cache_1、cache_2，大家试想一下，全民抢购的商品被路由到这三片缓存当中的 cache_1 中，如此一来，cache_1 中这一片缓存将会承载一场大的访问压力，有可能就会形成一个单点故障。在平日里，缓存的吞吐量好像还挺优秀的，与数据库相比确实优秀，但是在双十一这种促销活动中这个缓存的吞吐量优秀吗？
对于这种场景，如果查询请求永远被路由到了一片缓存当中，缓存很有可能就宕机了。因此，查询请求就会直接击穿到后台的数据库当中。
如果把数据库和缓存分别看作一个数据存储点，其实这个就相当于是单点故障，缓存只要一失效，数据库就立马宕机。
我们来想一下，怎么去优化，怎么去调整这样的架构，可以让它去处理这样的热点数据。
数据隔离的必要性
假设此时热点请求命中三个中的某个缓存服务上，从数据隔离的这种思路来看，如果把当前的这个热点抢购的数据从正常商品的缓存当中把它单独抽取出来，形成了一个独立的缓存存储区域，这样即使这个热点抢购失效了，依然可以保证其他的普通商品、其他的业务场景是可以正常运作的。这就是数据隔离的必要性。
在超高并发应用场景的架构和技术选型当中，很多时候我们都要对这种热点数据采取一个隔离的方案。有可能在接口层面隔离，底层数据层面隔离。总之，要把访问频次异常之高的这些数据单独抽取出来。
我们这里介绍一个思路，接下来的问题是什么？我们知道要把它抽取出来，但是知道要把它给抽取到哪里吗？
热点数据特性
热点有两个特性，在做这种架构推理的时候，要从解决的这个场景的现象推理出解决方案。
热点数据有两个非常鲜明的特征：
第一个，数量非常的少。比如我们的这个秒杀场景，那你参与秒杀的商品，它的个数在你所有普通商品的个数当中，它其实只占非常少的一部分。
第二个，访问频次比较高，也就是 QPS 非常高。
存储方案
基于这两个特性，思考一下，存储方案是什么？把热点存储到哪？
由于它的数量非常少，就决定着可以存储的地方的限制也比较少，可以把它存储在很多的地方。常用的存储方案：
第一个，热点散裂。
第二个，热点库，把热点数据单独的放到了一个库当中，技术实施成本比较低，应用也相对广泛。
第三个，多级缓存。但是这个多级缓存可不是 Redis 之外再套一层 Redis，可不是这种层层嵌套。这个多级缓存是我们在互联网的超高并发应用下，解决像秒杀之类的业务场景的一个杀手锏。
