一、Redis雪崩、穿透、并发等问题

1.1、缓存雪崩

缓存雪崩指的是：数据未加载到缓存中或缓存同一时间大规模的失效，所有请求都穿透到数据库。最终可能会导致数据库主机CPU和内存负载过高甚至宕机。

🌰举一个雪崩的简单例子：

1、redis集群大面积故障或数据没有预读到缓存中。

2、当大量的请求进来后没有命中缓存将直接穿透到数据库，数据库的压力暴增。

3、如果持续有请求穿透缓存进来，可能很快就会超出数据库当时的设计阈值，直至宕机。

4、由于大量的应用服务依赖数据库和redis的服务，这个时候很快就会变成各服务集群的雪崩，最后整个服务彻底崩溃。

⚠️缓存雪崩解决思路：

📉1、缓存的高可用

缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。（官方推荐Redis Sentinel）

📉2、缓存降级

可以利用ehcache等本地缓存，但主要还是对源服务访问进行限流、资源隔离(熔断)、降级等。

当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。

降级的最终目的是保证核心服务可用，即使是有损的。

比如推荐服务中，很多都是个性化的需求，假如个性化需求不能提供服务了，可以降级补充热点数据，不至于造成前端页面是个大空白。

在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案，比如：

normal：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

warning：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警；

error：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

emergency：比如因为特殊原因数据错误了，此时需要紧急人工降级。

📉3、Redis备份恢复和缓存预热

这两点都是解决在项目第一次启动或者缓存故障后冷启动时缓存中没有任何数据，这时如果是高并发场景下就会出现大量的请求穿透到原始数据库可能导致数据库宕机。

这种比较尴尬的启动即宕机还是很致命的😄。

所以在项目启动前需要将redis的数据备份进行恢复，新项目没有备份的情况下可以使用脚本或者程序逻辑先提前将相关的缓存数据直接加载到缓存系统。

这个是比较简单基础的预热方式，实际生产中可能需要根据以往的日志进行分析按照数据的热度去进行缓存。

📉4、提前演练，防患于未然

最后，建议还是在项目上线前，模拟测试缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前模拟测试，提前发现问题。

⚠️其实最重要的就是这一步：防患于未然，做到心中有数，这样不至于生产环境上出现预料之外的问题而手忙脚乱！

1.2、缓存穿透

缓存穿透指的是：查询的数据本身在数据库中就没有，自然在缓存中也不会有。这样就导致查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过了缓存直接查数据库，这也是经常提的缓存命中率问题。

⚠️缓存穿透解决思路：

1、使用布隆过滤器将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

2、如果一个查询返回的数据为空，我们仍然把这个空结果进行缓存，设置一个过期时间或者当有值的时候将缓存中的值替换掉即可。通过这个直接设置的默认值放到缓存中，这样第二次到缓存中获取就有值，而不会继续访问数据库，这种方法最简单粗暴且实用。

1.3、缓存并发

这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行。

二、Redis为什么是单线程还很快

2.1、Redis很快的原因

1.redis是基于内存的，内存的读写速度非常快（普通单通道DDR3 1600MHz内存的理论读写速度在12.8GB/s 实际读写在5GB/s左右）；

2.redis是单线程的，省去了很多上下文切换线程的时间（线程切换会频繁的记录寄存器的存储和程序计数器存储的指令内容）；

3.redis使用多路复用技术，可以处理并发的连接。非阻塞IO 内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。

下面重点介绍单线程设计和IO多路复用核心设计快的原因。

2.2、为什么Redis是单线程的？

官方说明之前，我先说一下针对现代计算机的工作特点，前人总结的程序设计思路：

高并发，低耗时的情况，建议少线程。
低并发，高耗时的情况：建议多线程。
高并发高耗时，要分析任务类型、增加排队、加大线程数。

1.官方答案

因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2.性能指标

关于redis的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

3.详细原因

1)不需要各种锁的性能消耗

Redis的数据结构并不全是简单的Key-Value，还有list，hash等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在hash当中添加或者删除

一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2)单线程多进程集群方案

单线程的威力实际上非常强大，每核心效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。

所以单线程、多进程的集群不失为一个好的解决方案。

3)CPU消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果CPU成为Redis瓶颈，或者不想让服务器其他CUP核闲置，那怎么办？

可以考虑多起几个Redis进程，Redis是key-value数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些key放在哪个Redis进程上就可以了。

Redis单线程的优劣势

单进程单线程优势代码更清晰，处理逻辑更简单不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗不存在多进程或者多线程导致的切换而消耗CPU

单进程单线程弊端无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；

IO多路复用技术

redis 采用网络IO多路复用技术来保证在多连接的时候， 系统的高吞吐量。

多路-指的是多个socket连接，复用-指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术（nginx也是用的epoll机制实现的多路复用）。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络IO的时间消耗)，且Redis在内存中操作数据的速度非常快(内存内的操作不会成为这里的性能瓶颈)，主要以上两点造就了Redis具有很高的吞吐量。

2.3、Redis高并发快的总结

1. Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。

2. 再说一下IO，Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。

3. Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。

4. 另外，数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

5. 还有一点，Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

🪶上文中的思路不仅仅针对redis、mysql的组合，其他类似的缓存或者场景都可以借鉴。