⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.jianshu.com/p/0a1c9fc23c01 「MicroStone123」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注**微信公众号：【芋道源码】**有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

一、redis简介

Redis 是C语言开发的一个开源高性能键值对的内存数据库，可以用来做数据库、缓存、消息中间件等场景，是一种NoSQL(not-only sql,非关系型数据库)的数据库

二、Redis特点

优秀的性能，数据是存储在内存中，读写速度非常快，可支持并发10W QPS
单线程但进程，是线程安全的，采用IO 多路复用制
可作为分布式锁
支持五种数据类型
支持数据持久化到磁盘
可以作为消息中间件使用，支持消息发布及订阅

二、数据类型

下表是我列举的五种数据类型的特性及其使用场景

三、缓存

数据缓存是Redis最重要的一个场景，为缓存而生，在springboot中，一般有两种使用方式：

直接通过RedisTemplate使用
通过Spring Cache集成Redis(也就是注解的方式)

四、使用缓存遇到的问题

1 数据一致性

在分布式环境下，缓存和数据库很容易出现数据一致性问题，如果项目对缓存的要求是强一致性，那就不要使用缓存。

我们只能在项目中使用策略降低缓存与数据库一致性的概率，是无法保障两者的强一致性，一般策略包括缓存更新机制，更新数据库后及时更新缓存、缓存失败时增加重试机制

2 缓存雪崩

在了解雪崩溃之前，我们先了解什么是缓存雪崩现象，假设A系统每秒需要处理5000个请求，但数据库每秒只能处理4000个请求，某一天，缓存机器出现了宕机，挂了，这时候所有的请求一下子全部落在数据库上，数据库肯定扛不住，报警挂掉了，这时候如果没有采取缓存设施，数据库又急着用，重新重启数据库，刚重启完成(有可能没启动完)，请求又来，数据库立马挂掉。这就是雪崩事件，是Redis缓存中最致命问题之一(有一个是穿透)。大家可以看看下图

出现雪崩事件后不要急不要慌，我们可以在事故前中后三个方面来思考解决方案

事故前：redis高可用方案，主从+哨兵，集群方案，避免全盘崩溃
事故中：较少数据库的压力，本地Ehcache缓存+限流及降级，避免超过数据库承受压力
事故后：做redis持久化，一旦Redis重启，可从磁盘中快速恢复数据

我们来看看改造后的数据流程，假设用户A发送一个请求，系统先请求本地Ehcache是否有数据，如果没有再去Redis请求数据，如果没有再去数据库请求数据，获取到数据后同步到Ehcache和redis

限流组件的作用：可以设置每秒请求数次，有多少通过请求，剩余的未通过的可以走降级处理，返回一些默认的值，或者友情提示等默认操作。具体流程可以看看下图：

这样做的好处是:

数据库安全：在限流组件可用的情况下，数据库不会挂掉，限流根据确保了每秒多少请求能通过。
部分请求可以被处理：数据库没挂，就意味着至少2/5的请求可以被处理掉
高峰时期部分请求无法处理到，需要用户多次点击，因为只有2/5的请求被处理，剩下的请求，用户刷不出来界面，需要多点击几次
redis设置的缓存失效时间不是设置成同一个时间，可根据功能、业务、请求接口灵活设置缓存时间：setRedis（key, value, time+Math.random()*10000）;

3 缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，用户(黑客)不断发起请求，导致请求直接查询数据库，这种恶意行为攻击场景的会直接导致数据库挂掉，数据流程如下图所示

image

处理这种情况相对比较简单点，这种情况是绕过redis或本地缓存直接到达数据库，可以采取以下方案：

在请求接口层可以做一些校验，比如用户签权、参数校验，不合法的请求直接return，
还可以针对有效id做认证或直接拦截，不符合的id直接过滤或采用统一key保存到redis，下次不合法的id请求时，直接到缓存中获取数据
采用redis的高级接口Bloom Filter，利用高效的数据结构和算法快速判断出你这个 Key 是否在数据库中存在，不存在你 return 就好了，存在你就去查 DB 刷新 KV 再 return

4 缓存击穿

上面讲的穿透是针对大面积数据请求，那么击穿是针对一点(一个key)来来导致redis异常，但某个key是非常热点，请求非常频繁，处于集中式访问现象，当这个key失效(过期)时，大量的请求就会击穿了缓存，直接请求数据库，就像在屏障中凿开了一个洞。

不同场景下缓存击穿解决方案

数据基本不变：热点数据value基本不更新时，可以设置成永不过期
数据更新不频繁：缓存刷新流程耗时较少时，可采用redis、zookeeper等分布式中间件的分布式互斥锁或者本地互斥锁保证少量的请求能请求到数据库并重新更新缓存，其他的流程等锁释放后才可以访问新缓存
数据更新频繁：采用定时线程，在缓存过期前主动重新构建缓存或延长过期时间，保证所有的请求能一直访问缓存

五、为什么Redis会如此快

Redis官方介绍可以达到10W+的QPS，这个数据不比MEMCache差，而且Redis 是单进程单线程的模型，完全基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈是内存及网络带宽，有以下特点：

使用类似于HashMap的原理，HashMap的查询及操作的时间复杂度是O(1)，且绝大多数请求是纯碎的内存操作，数据存在内存中
数据结构简单，对数据操作也简单，基于KV
不错死锁现象采用单线程操作，避免了不必要的上下文切换及竞争条件，不存在CPU切换现象，也就不存在考虑各种锁的问题
使用非阻塞IO，多路复用IO模型

六、Redis淘汰策略

volatile为前缀的策略都是从已过期的数据集中进行淘汰。
allkeys为前缀的策略都是面向所有key进行淘汰。
LRU（least recently used）最近最少用到的。
LFU（Least Frequently Used）最不常用的。
它们的触发条件都是Redis使用的内存达到阈值时。

七、Redis持久化

Redis 持久化策略有两种：

RDB：快照形式是直接把内存中的数据保存到一个 dump 的文件中，定时保存，保存策略。
AOF：把所有的对 Redis 的服务器进行修改的命令都存到一个文件里，命令的集合。Redis 默认是快照 RDB 的持久化方式。

如果非常关心你的数据，但仍然可以承受数分钟内的数据丢失，那么可以额只使用 RDB 持久。

AOF 将 Redis 执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能，不知道你是否可以接受。

数据库备份和灾难恢复：定时生成 RDB 快照非常便于进行数据库备份，并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度快。

当然了，Redis 支持同时开启 RDB 和 AOF，系统重启后，Redis 会优先使用 AOF 来恢复数据，这样丢失的数据会最少。

八、Redis 主从复制

从节点执行 slaveofmasterIP，保存主节点信息。
从节点中的定时任务发现主节点信息，建立和主节点的 Socket 连接。
从节点发送 Ping 信号，主节点返回 Pong，两边能互相通信。
连接建立后，主节点将所有数据发送给从节点（数据同步）。
主节点把当前的数据同步给从节点后，便完成了复制的建立过程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

九、Redis哨兵模式

我们先说说主从复制会存在问题：

一旦主节点宕机，从节点晋升为主节点，同时需要修改应用方的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
原生复制的弊端在早期的版本中也会比较突出，比如：Redis 复制中断后，从节点会发起 psync。
此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时，可能会造成毫秒或秒级的卡顿。

哨兵的架构模式如下：

该系统可以执行以下四个任务：

监控：不断检查主服务器和从服务器是否正常运行。
通知：当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本向管理员或者其他应用程序发出通知。
自动故障转移：当主节点不能正常工作时，Sentinel 会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点，这样人工干预就可以免了。
配置提供者：在 Redis Sentinel 模式下，客户端应用在初始化时连接的是 Sentinel 节点集合，从中获取主节点的信息。

芋道源码 —— 纯源码解析博客

一文读懂Redis