针对热点商品这些类型的数据，要考虑到访问量比较大，大家首先想到的是缓存，上redis缓存，这点肯定没有错。系统框架如下：?
上图中，先从缓存中获取，没有再到DB获取，并保存到缓存中。但有个问题会产生，热点数据的访问会比较大，如果缓存一旦失效，所有请求同一时刻，会打到DB上面，DB肯定会崩溃。那怎么办呢？
缓存一旦失效，如何重新构建缓存？首先需要避免失效那一刻大量请求同时去重新构建缓存。因为重新构建缓存，需要到数据库DB中获取数据，那一个时刻的所有请求到DB上面。****方案有两种，第一个方案是把请求进入队列中（这个老顾以后会介绍，关于库存一致性的问题中，有涉及到这个知识点）。还有一个方案就比较简单，利用分布式锁，只允许一个请求线程去访问DB，其他请求阻塞，这样就避免了很多请求打到DB上。
具体怎么实现可以看老顾之前的文章【如何利用锁，防止缓存击穿？重构思想的重要性】
这个方案就是利用redis本身的特性，导致的问题是因为缓存失效了，那我们可以让缓存永不过期就行了。这个方案中需要考虑两个情况：
1、热点商品上线前需要预热，也就是在商品正式发布到前端时，需要提前把商品信息进行缓存，避免跟缓存失效的情况一样。 2、更新商品信息机制，如何在商品信息更新后，及时更新缓存中的商品信息。这个也比较简单在更新商品事件中，增加个更新消息，由缓存服务进行消费，更新缓存信息。
上面两个方案是网上经常提到的方案，其实这两个方案会存在一个问题，也就是redis达到了负载极限怎么办？也就是热点商品的访问量，我们的单台redis扛不住了。
小伙伴们会有疑问，redis可以上集群啊，不就解决了吗？
我们先了解一下，redis cluster集群部署方案
上图是redis经典的三主三从集群方案，客户端进行set和get时，都是走的主redis，从redis只是个备份，主要作用是用来做高可用的，如：主redis挂了，从redis顶上。
备注：老顾这里介绍的是redis集群部署方案，如果是之前的redis主从方案，另外讨论
从redis是不负责set和get请求的，即使请求打到从redis节点，从redis也会转发给主redis。而其他的主redis，是用来做数据扩容的。
即就是商品A的信息，只会存在一个主redis中，其他主redis是没有此商品A的信息的，这就是redis集群哈希槽的特点。
也就是小伙伴刚才想到的做redis集群这个方案是不行的，因为热点数据只会在一个主redis中。会存在单台redis负载不足（达到网卡、网络上限。达到这个瓶颈流量代表非常大了）。那怎么办呢？
上面我们提到从redis只不负责读和写请求的，但redis官方提供了一个方法，在操作读请求时，可以先加上readonly命令，这样从redis就可以提供读请求服务了，不需要转发到主redis。
根据这个特性，我们可以对客户端工具进行改造，读请求方法时，加上readonly这个命令，从而实现读写分离，提高了从redis的利用率。
即达到了多台从redis去扛大量请求了，减少了主redis压力。这个方案需要对客户端进行改造，而且redis官方推荐没有必要使用读写分离。
这个方案就是多级缓存的方案，把缓存前置，架构图如下：
面试题文档来啦，内容很多，485页！
由于笔记的内容太多，没办法全部展示出来，下面只截取部分内容展示。
MyBatis 27题 + ZooKeeper 25题 + Dubbo 30题：
Elasticsearch 24 题 +Memcached +?Redis 40题：
Spring 26 题+ 微服务 27题+ Linux 45题：
Java面试题合集：
Redis缓存系列：你所不知道的Redis热点问题以及如何发现热点，老师讲的真棒
原文：https://www.cnblogs.com/hgysvadavvc/p/15311329.html