Update Redis.md

Snailclimb · Snailclimb · commit 6f9613509a7c · 2020-06-30T23:19:15.000+08:00
diff --git a/docs/database/Redis/Redis.md b/docs/database/Redis/Redis.md
@@ -115,6 +115,19 @@ Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支
 
 相信看了上面的对比之后，我们已经没有什么理由可以选择使用 Memcached来作为自己项目的分布式缓存了。
 
+### 缓存数据的处理流程是怎样的？
+
+作为暖男一号，我给大家画了一个草图。
+
+![正常缓存处理流程](https://static01.imgkr.com/temp/bc0cfbc9911148eeb0542d84a049d9f2.png)
+
+简单来说就是:
+
+1. 如果用户请求的数据在缓存中就直接返回。
+2. 缓存中不存在的话就看数据库中是否存在。
+3. 数据库中存在的话就更新缓存中的数据。
+4. 数据库中不存在的话就返回空数据。
+
 ### 为什么要用 Redis/为什么要用缓存？
 
 *简单，来说使用缓存主要是为了提升用户体验以及应对更多的用户。*
@@ -135,7 +148,7 @@ Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支
 
 **高并发：**
 
-一般像 MySQL这类的数据库的 QPS 大概都在 1w 左右（4核8g） ，但是使用 Redis 缓存之后很容易达到 10w+。
+一般像 MySQL这类的数据库的 QPS 大概都在 1w 左右（4核8g） ，但是使用 Redis 缓存之后很容易达到 10w+，甚至最高能达到30w+（就单机redis的情况，redis 集群的话会更高）。
 
 >  QPS（Query Per Second）：服务器每秒可以执行的查询次数；
 
@@ -216,6 +229,8 @@ sinterstore key1 key2 key3     将交集存在key1内
 
 ### Redis 设置过期时间
 
+*一般情况下，我们设置保存的缓存数据的时候都会设置一个过期时间。*
+
 Redis 中有个设置时间过期的功能，即对存储在 Redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。
 
 我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。
@@ -322,45 +337,25 @@ Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。
 
 > 1. Redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。（来自[issue:关于 Redis 事务不是原子性问题](https://github.com/Snailclimb/JavaGuide/issues/452) ）
 
-### 缓存雪崩和缓存穿透问题解决方案
-
-#### **缓存雪崩**
-
-**什么是缓存雪崩？**
-
-简介：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。
-
-**有哪些解决办法？**
+### 缓存穿透
 
-（中华石杉老师在他的视频中提到过，视频地址在最后一个问题中有提到）：
+#### 什么是缓存穿透？
 
-- 事前：尽量保证整个 Redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
-- 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 崩掉
-- 事后：利用 Redis 持久化机制保存的数据尽快恢复缓存
+缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。
 
-![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-25/6078367.jpg)
+#### 缓存穿透情况的处理流程是怎样的？
 
-#### **缓存穿透**
+如下图所示，用户的请求最终都要跑到数据库中查询一遍。
 
-**什么是缓存穿透？**
+![缓存穿透情况](./images/redis/缓存穿透情况.png)
 
-缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。下面用图片展示一下(这两张图片不是我画的，为了省事直接在网上找的，这里说明一下)：
-
-**正常缓存处理流程：**
-
-<img src="https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/正常缓存处理流程-Redis.png" style="zoom:50%;" />
-
-**缓存穿透情况处理流程：**
-
-<img src="https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/缓存穿透处理流程-Redis.png" style="zoom:50%;" />
-
-一般 MySQL 默认的最大连接数在 150 左右，这个可以通过 `show variables like '%max_connections%';`命令来查看。最大连接数一个还只是一个指标，cpu，内存，磁盘，网络等无力条件都是其运行指标，这些指标都会限制其并发能力！所以，一般 3000 个并发请求就能打死大部分数据库了。
-
-**有哪些解决办法？**
+#### 有哪些解决办法？
 
 最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
 
-**1）缓存无效 key** : 如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。
+**1）缓存无效 key** 
+
+如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下：`SET key value EX 10086`。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。
 
 另外，这里多说一嘴，一般情况下我们是这样设计 key 的： `表名:列名:主键名:主键值`。
 
@@ -387,12 +382,60 @@ public Object getObjectInclNullById(Integer id) {
 }
 ```
 
-**2）布隆过滤器：**布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，我会先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。总结一下就是下面这张图(这张图片不是我画的，为了省事直接在网上找的)：
+**2）布隆过滤器**
+
+布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。
+
+具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。
+
+加入布隆过滤器之后的缓存处理流程图如下。
 
-<img src="https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-11/布隆过滤器-缓存穿透-Redis.png" style="zoom:50%;" />
+![image](https://static01.imgkr.com/temp/e384cec584314b019de6e3a39ee56425.png)
+
+但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： **布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。**  
+
+*为什么会出现误判的情况呢?我们还要从布隆过滤器的原理来说！*
+
+我们先来看一下，**当一个元素加入布隆过滤器中的时候，会进行哪些操作：**
+
+1. 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
+2. 根据得到的哈希值，在位数组中把对应下标的值置为 1。
+
+我们再来看一下，**当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：**
+
+1. 对给定元素再次进行相同的哈希计算；
+2. 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。
+
+然后，一定会出现这样一种情况：**不同的字符串可能哈希出来的位置相同。** （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）
 
 更多关于布隆过滤器的内容可以看我的这篇原创：[《不了解布隆过滤器？一文给你整的明明白白！》](https://github.com/Snailclimb/JavaGuide/blob/master/docs/dataStructures-algorithms/data-structure/bloom-filter.md) ，强烈推荐，个人感觉网上应该找不到总结的这么明明白白的文章了。
 
+### 缓存雪崩
+
+#### 什么是缓存雪崩？
+
+我发现缓存雪崩这名字起的有点意思，哈哈。
+
+实际上，缓存雪崩描述的就是这样一个简单的场景：**缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。** 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。
+
+举个例子：系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问，都要走数据库。
+
+还有一种缓存雪崩的场景是：**有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。** 这样的情况，有下面几种解决办法：
+
+举个例子 ：秒杀开始12个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是12个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。
+
+#### 有哪些解决办法？
+
+Redis服务不可用：
+
+1. 采用Redis集群，避免单机出现问题整个缓存服务都没办法使用。
+2. 限流，避免同时处理大量的请求。
+
+热点缓存失效：
+
+1. 设置不同的失效时间比如随机设置缓存的失效时间。
+2. 缓存永不失效。
+
 ### 如何解决 Redis 的并发竞争 Key 问题
 
 所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！
