分布式缓存之redis知识点

不念不忘少年蓝@ 2023-06-15 04:49 8阅读 0赞

#### 数据类型 ####

字符串string、散列hash、列表list、集合set、有序集合zset、位图bitmap、基数统计HyperLogLogs、消息队列Streams

基本数据类型底层的数据结构不是固定的，会根据数据情况进行调整。

--------------------

#### 底层数据结构 ####

redis使用c语言实现，以下的数据结构都是底层通过c语言定义的结构。

##### hashtable #####

字典结构。字典结构类似hashMap，使用哈希表，通过数组存储节点，每一个键值对节点都是一个`disEntry`结构，包含指向下一个键值对的指针。每来一个键值对通过计算hash值命中数组位置，如果hash冲突则利用disEntry结构，通过`链地址法`进行连接解决冲突。redis会维护哈希表的容量在一个合理的范围内，当数组容量过大或过小时通过rehash进行扩容或缩减，rehash的方式时将哈希表上的数据rehash放到一个新的哈希表，等到全部迁移完成，将原哈希表的丢弃使用新的哈希表。  
**使用的数据类型：**

*  redis的`key-value`形式就是通过字典结构存储的，
 *  `hashMap`键值对大于512个或某个键值对的键或值的字符串长度超过64字节时使用。
 *  `set`数据类型数据量较多或者有非整数的数据时使用

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-srCawbk4-1585712365653)(evernotecid://EA56B0F8-13B5-4B11-8191-1E827D9FC2A6/appyinxiangcom/22897236/ENResource/p12)\]

##### SDS #####

`字符串类型`的value采用SDS结构存储，类似java的list结构，通过字节数组存储数据，且数组长度是动态可变的。  
字符串编码有三种分别为`int编码、embstr编码、raw编码`。  
编码的区别：int编码用于value为`纯数字`的的情况，embstr编码用于字符串`小于等于44字节`的，raw编码用于字符串`大于44字节`的。

##### LinkedList #####

维护一个双向链表，与java的linkedlist类似，维护头尾节点，节点维护前继节点和后继节点指针,增加删除操作比较方便。`redis 3.2之前list类型`底层数据比较多时使用此数据类型。

##### ziplist #####

压缩链表，列表包含少数据量时会使用压缩链表，即占用空间较少时使用，通过使用`连续的内存空间`存储数据，相对LinkedList省掉前继节点和后继节点`节省空间`，但是`更新效率低`，会导致更新时引发`连环更新`（删除一个节点，其他位置也要迁移），有点类似java的arrayList。  
**使用的数据类型**

*  `redis 3.2之前list类型`底层数据比较少时使用。
 *  `hash类型`键值对小于512个，所有键值对的键或值的字符串长度不超过64字节时使用。
 *  `Zset类型`数据量比较小时使用

##### quicklist #####

快速列表,`redis 3.2`之后新增的数据结构，`结合压缩列表和双向列表`，3.2之后list类型底层使用此数据结构。该结构同样维护一个双向链表，不同的是单节点上不是单个数据，而是多个数据压缩到一个节点上,单个节点上的存储数据量少，采用ziplist的形式存储。

##### inset #####

通过数组实现，`set类型`数据都为int类型且数据量不多时通过此结构保存

##### skipList #####

跳跃表,支持快速查询、插入、删除等操作。一层一层建立索引，每级的索引数递减，每层索引上的查找使用二分法查找，增删查时间复杂度平均0(logN），`实现比红黑树相对简单`，避免红黑树旋转，`zset类型`底层使用此数据类型，效率高且支持排序，`支持范围查询`。  
\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xC8qfXim-1585712365656)(evernotecid://EA56B0F8-13B5-4B11-8191-1E827D9FC2A6/appyinxiangcom/22897236/ENResource/p13)\]

<table> 
 <thead> 
  <tr> 
   <th>类型</th> 
   <th>结构</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>list</td> 
   <td>LinkedList（3.2前数据较多时）、ziplist（3.2前数据较少时）、quicklist（3.2之后使用）</td> 
  </tr> 
  <tr> 
   <td>key-value</td> 
   <td>hashtable</td> 
  </tr> 
  <tr> 
   <td>string</td> 
   <td>SDS</td> 
  </tr> 
  <tr> 
   <td>hash</td> 
   <td>hashtable(键值对超过512、value超过64字节)、ziplist（小于512）</td> 
  </tr> 
  <tr> 
   <td>set</td> 
   <td>hashtable(非整数时或数据太多时)、inset（存数字set）</td> 
  </tr> 
  <tr> 
   <td>zset</td> 
   <td>ziplist(数据量比较小时使用)、skipList</td> 
  </tr> 
  <tr> 
   <td>bitmap</td> 
   <td>数组</td> 
  </tr> 
 </tbody> 
</table>

--------------------

#### 单线程模型 ####

redis基于单线程实现。网络通信基于epoll实现`非阻塞io多路复用`，并将epoll的read、write、close等转换成事件回调处理。使用单线程避免了多线程环境线程上下文切换、竞争共享资源需要用锁导致的性能损耗、开发逻辑相对比较简单。之所以采用单线程，除了以上原因，还有就是redis都是基于内存操作，性能瓶颈主要在网络传输时延和带宽限制，如果性能瓶颈出现在多核cpu上也可以在单机器部署多个实例利用cpu性能。`如果单个命令执行时间过长，会影响其他命令的阻塞。`

#### pipelining ####

redis客户端普通的get set请求都需要等待服务端响应后才能接收响应，而redis的pipelining会将多个请求通过一次tcp连接发到服务端，服务端会将部分请求放到内存队列中，处理后通过一次tcp连接将多个命令执行结果返回。redis各个语言client都支持pipelining，命令行客户端则不支持，因为命令行客户端每执行一条命令都要等待上一条命令执行结束。  
**优点**：减少了网络通信次数，批量处理避免每个命令执行都要等待上次执行结束造成的阻塞，`极大提高吞吐量`。  
**缺点**：无法在执行单个命令后立即获取到执行结果，相当于批量执行后才可以获取到执行结果。  
**注意**:由于redis服务端处理多个连接需要暂时缓存到内存队列，因此会占用一定内存，所以要考虑server的物理内存情况，及网络接口的缓冲能力。对需要进行批量操作，且对命令实时性要求不高可以采用。

#### qps ####

redis是单纯内存操作，理论上基于内存操作可以达到上百万的qps，但是考虑到受到机器带宽、存在网络传输时延、连接数等等的影响，会有所降低。以下附上官方测试结果，使用`pipelining`可以达到几十万的qps，而不使用pipelining由于受到redis客户端吞吐量限制，也能达到10多w的qps。  
[官方测试][Link 1]

#### 如何提高redis性能 ####

1.  redis的瓶颈大多数存在于带宽、网络延迟等，比如1kb的字符串传输，如果要达到10w的qps，那么需要大概800mbps的带宽，传输效率才能跟上(100m/s)。因此可以提升带宽。
2.  cpu选择可以趋向大缓存快速cpu，多核不是考虑的因素。
3.  不建议搭到虚拟机上。
4.  主从、redis的服务端客户端要搭载内网中，降低网络时延
5.  持久化最好不在master上进行，rdb模式的持久化要写内存快照，会`阻塞进程的工作`(`bgsave的fork阶段也会阻塞，并且bgsave过程如果一直变动数据，会造成不断复制数据页，也会有一定的性能损耗`)，当快照比较大时对性能影响是非常大的，会间断性暂停服务;AOF文件过大会影响Master重启的恢复速度。因此持久化`可以在单独的slave上执行，且该slave不对外提供业务`。
6.  客户端可以配置读写分离
7.  redis集合的数据不要太大，最好分集合。

--------------------

#### 持久化 ####

持久化分为两种方式，分为RDB和AOF

##### RDB #####

rdb是通过将当前进程的数据生成快照保存到磁盘过程，触发方式分为`手动触发`和`自动触发`。

*  手动触发：通过`save`命令和`bgsave`命令触发，save命令不建议使用，触发生成快照时会`阻塞整个进程，直到快照生成结束`，严重影响性能。bgsave命令则是通过`fork`系统函数创建子进程，由子进程进行持久化操作。bgsave只会在`fork阶段会阻塞进程`，相对save性能有很大的优化。fork函数创建子进程会与父进程共享内存，基于`copy on write写时复制机制`,出现数据变动再复制一份数据页更改数据，因此子进程和父进程相互独立不会影响相互的内存数据。所以`bgsave保存的快照是执行fork时的redis进程内存信息,快照生成后会替换原有的rbd文件`。
 *  自动触发: 1.在redis`配置文件中增加save m n配置`，表示m秒内存在n次修改时自动触发bgsave,可以配置多个规则。2.`从节点进行全量复制时`（比如slave第一次连接master），master会触发bgsave生成rdb文件发给slave。3. `执行debug reload重新加载redis时`会触发bgsave。4. `执行shutdown命令时`，如果不是使用aof持久化则自动执行bgsave。

rdb文件名和保存目录可以通过配置文件配置，rdb文件可以通过配置对生成的文件进行压缩，降低磁盘占用。

**rbd优点缺点**：适合全量复制和备份，`redis加载rbd恢复数据的速度快`。缺点是`无法做到实时复制`，fork操作不可频繁执行，会影响redis性能。

##### AOF #####

针对RDB无法实时复制的问题，redis提供AOF方式持久化，将每次命令的执行写到日志中，恢复数据时根据日志命令执行进行数据恢复。  
**执行流程**：redis接收到命令时，会将命令通过系统调用`write函数`将命令写到文件缓冲区（`delayed writer机制`），缓冲区根据配置的策略刷盘（不直接往硬盘文件写是因为避免每次都进行磁盘io）。当文件达到一定程度的大小则会进行`文件重写`，达到压缩文件的目的。

**缓存区的数据刷到硬盘的时机**:redis支持三种配置，分别为`always、no、everysec`,默认为everysec。

*  always：每次写入命令都同步aof文件，会导致写入操作的性能依赖磁盘的io性能。违背redis基于内存操作的高性能，不建议配置。`性能最差，安全性最高。`
 *  no:完全依赖操作系统的刷盘。操作系统会在缓存区满了之后再将数据同步到文件中，刷盘次数最少，`性能最优`，但是一但机器断电，缓冲区的数据都会丢失，`安全性差`。
 *  everysec:默认的配置，每秒调用一次系统函数`fsync`进行刷盘，理论上最多只会丢失一秒的数据。`性能和安全性都兼顾，建议用此配置`。

**文件重写**：随着命令的写入，文件会越来越大，因此在文件达到一定程度后会进行文件重写，文件重写会`排除掉已经超时的数据、合并集合操作命令、去除无效命令(对某个key的赋值实际上只有最后一次设值有效)`。文件重写除了`降低文件占用空间还可以让aof被redis加载时更快`。触发文件重写分为两种：手动触发和自动触发。

*  手动触发重写：手动触发可以调用bgrewriteaof命令。
 *  自动触发重写：自动触发通过配置auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定触发时机。auto-aof-rewrite-min-size为触发重写的aof文件大小，`默认为64m`。auto-aof-rewrite-percentage为当前aof超过上次重写的文件大小的比例，`默认为100`，表示超过上次重写的100%即2倍时，触发重写。`两个条件同时满足才会触发重写`。

文件重写过程中新的数据会写到缓冲区中，文件重写结束后，再将缓冲区的数据与重写后的新文件数据合并。

--------------------

#### 缓存删除 ####

缓存删除分为三种情况，分别为被动删除、主动删除、缓存淘汰。

##### 被动删除 #####

操作某个key时，如果`发现这个key已经超时则会删除该key`，并且无效操作（除了set）。这个方式性能较好，不用去扫描key去排查，但是却会导致有些key已经过期而一直占用着内存。

##### 主动删除 #####

redis默认每秒运行10次触发主动删除，可以通过配置。主动删除会随机获取100个设置了过期时间的key，删除过期了的key，如果删除的key超过了25%，则重复这个操作。相当于随机求概率，确保超时的key数量大致不超过设置了过期时间的key的25%。

##### 缓存淘汰 #####

redis可以设置最大内存大小`maxmemory`，当redis的内存超过这个内存大小时，会触发缓存淘汰，且在超过maxmemory大小后，对于所有的读写请求都会触发缓存淘汰，可能**会导致请求有所延迟**，`建议不要配置maxmemory，或者配置确保不要触发，可以通过提高主动删除的频率或者扩容解决`。maxmemory设置为0表示不限制。缓存淘汰不会一次性针对所有的key进行处理，默认会选择5个key,然后选5个key中最符合条件（如果在所有key中找符合策略的key是不现实的，性能低），通过缓存淘汰策略处理这些key进行删除，key的个数可以通过`maxmemory-samples`参数配置。淘汰策略可以通过`maxmemory-policy`参数配置。

**缓存淘汰策略**

*  volatile-lru：从`已设置过期时间`的数据集中挑选`最近最少使用`的数据淘汰
 *  volatile-ttl：从`已设置过期时间`的数据集中挑选`将要过期的数据`淘汰
 *  volatile-random：从`已设置过期时间`的数据集中`随机选择`数据淘汰
 *  allkeys-lru：从数据集中(包含未设置过期时间的)挑选`最近最少使用`的数据淘汰
 *  allkeys-random：从数据集中(包含未设置过期时间的)`随机选择`数据淘汰
 *  no-enviction：`禁止`删除数据

`redis4新增lfu策略`，即淘汰最近最少使用频次的数据。由于lru可能存在一种情况，有个数据访问很频繁，但是相比其他键最后一次访问的时间久，从而导致热数据被淘汰。

*  volatile-lfu:从`已设置过期时间`的数据集中挑选`最近最少使用频次`的数据淘汰
 *  allkeys-lfu：从数据集中挑选`最近最少使用频次`的数据淘汰

**Redis lru实现**  
lru为最近最少使用，redis会维护一个24位的全局时钟，相当于系统当前的时间戳，当新增key的时候会把全局时钟赋给每个key对象中存储的内部时钟，更新和获取会更新这个时间，redis通过随机获取几个key，从这几个key中选出与全局时钟相隔最久的key就行删除。（`与传统的lru实现不一样，传统的lru会维护一个双向队列，每次访问到移到队尾，最近最少访问的就在堆头`）

**Redis lfu实现**  
lfu为最近最少使用频次，如果使用lfu，则对象中的24位时钟会变成两个部分，前16位当作时钟，后8位表示访问频次。访问频次不是每次访问就加1，而是通过访问一定程度后，才会增加频次，如果隔几分钟没有访问，则会降低这个访问频次。两个参数可以调整频次的计算。`lfu-log-factor`计算因子，影响频次的增长速度，越大频次增长的越慢。`lfu-decay-time`单位是分钟，表示隔几分钟没访问就要降低频次。新分配的key默认频次为5，防止频次过低直接被删除。  
[官方文档][Link 2]

--------------------

##### 业务层缓存优化 #####

**缓存穿透**：指的是缓存和数据库都不存在的数据，用户每次发起请求都命中到数据库，导致数据库压力太大。解决方案是将该参数对应的值存个短时间的空值，这样用户下次请求就直接命中缓存，返回空。  
但是也会导致产生大量无效key,通过布隆过滤器填入key，保证key不是无效key，虽然不一定准确，存在hash冲突，但是可以保证一定程度有效性,过滤掉部分请求。

**缓存击穿**：并发量很高时需要考虑。指的是当缓存失效和重新查库设置缓存的间隙，有很多并发的请求进来，都去查库，导致请求都命中数据库。解决方案：可以通过加锁解决，在重新查库设置缓存的操作前加锁，其他请求要去查库时拿锁失败进入阻塞，等待缓存设置完直接查询缓存返回。或者热数据设置不过期。  
**缓存雪崩**：1. 缓存都设置同个时间过期，导致突发请求到直接命中数据库。解决方案：缓存过期时间不设置固定时间，可以设置在一个范围时间内波动。设置热点数据不过期。2. redis挂了，导致流量全部到数据库。保证可用性，redis数据持久化，避免同时失效，本地缓存，限制流量。  
**热数据预加载**：在项目发布前，如果有已知的热数据，可以先把热数据加载到缓存中，项目提供服务后，用户的请求直接命中缓存，不用去查库。

--------------------

#### 高可用架构 ####

redis实现高可用，包含主从、哨兵sentinel、redis-cluster集群

##### 主从 #####

redis分为`master、slave`。当slave连接上master后会发送`sync`命令到master，master接收到命令后执行`bgsave`生成`rdb`文件，并将新的写命令存储到缓冲区，rdb文件生成后，master将rdb文件发送给slave，并发送缓冲区中的写命令。slave丢弃旧数据载入快照，完成载入后开始接收命令请求，执行缓冲区的写命令。之后master每接收到一条写命令，就发送给slave执行。

**优点**:可以进行读写分离，降低master的读压力。slave可以接受其他slave的连接和同步请求，可以降低master的同步压力。  
**缺点**:不具备自动容错和恢复功能，主从宕机会导致前端请求部分失败，需要手动切换客户端的ip。主机宕机，有部分数据未能及时同步到从库，主从切换后数据不一致。  
**主从不一致的情况**  
过期时间不一致的问题。主从同步期间执行了`expire`,expire的本质是`当前时间戳加上过期时间`，如果在`同步期间这个命令传到从库`，会等到`同步结束再执行`，那么当前时间戳加上过期时间就会有延迟，延迟了`同步所耗费的时间`。本质上虽然master在删除key时会同步给从库，但是`如果这个key没有及时被删除`，而master在接受访问请求时会判断已经过期不让访问，但是slave的过期时间延迟了，则slave可以访问这个key，就导致不一致。`expireat`可以解决这个问题，expireat是直接指定过期的时间戳的，所以没有问题。`一般只有对过期时间要求比较严苛的场景才需要考虑`

##### 哨兵sentinel #####

redis主从模式下，如果master出错，需要手动切换主从，因此redis提供了哨兵工具进行自动化系统监控和故障恢复功能，哨兵的功能包括监控主从是否正常，主出现故障时进行主从切换。哨兵模式本身也需要保证高可用，因此要保证至少需要有三个哨兵实例实现集群。

**sentinel判断节点故障的方式:**  
master下线分为主观下线和客观下线，slave和Sentinel只有主观下线，不会协商。  
**主观下线**，sentinel默认`1秒`会发送一次ping到master、slave、其他哨兵节点做`心跳检测`，当这些节点超过`down-after-milliseconds`参数指定的时间还没回复时或者没有正确回复时，该sentinel则主观认为该节点故障。  
**客观下线**：redis基于`gossip`协议去中心化思想，sentinel采用redis的`发布订阅模式`相互通信，每个sentinel都订阅名为`__sentinel__:hello`的渠道，且每`2秒`发布一次监控的节点信息、master配置信息到该channel。sentinel主观认为某节点已经故障，当该sentinel通过渠道接收到配置的`quorum`票数的sentinel认为该节点已经故障，则客观认为该节点故障。

**master故障转移**  
当sentinel客观认为master已经故障，则会发送is-master-down-by-addr命令给其他sentinel,让自己成为`leader`并执行failover.该sentinel需要获得`超过半数`并且大于`quorum`数的sentinel授权，避免并发多个sentinel进行failover。当sentinel节点被选举为leader后会进行故障转移，此时会为该master进行failover分配一个`版本号(用于确认配置的新旧)`。leader选择一个slave节点发送`SLAVEOF NO ONE`命令升级为master节点，通知其他从节点指向新的主节点，通知客户端master节点已经替换。在完成故障转移后leader会将新的master配置发布到channel中，其他sentinel发现`配置的版本号比当前的维护的配置的版本号高，会替换成新的配置文件`。failover-timeout参数可以设置故障转移的超时时间，如果故障转移超过这个时间，则授权过本次failover的sentinel会再一次为该master进行failover。

**故障转移slave节点的选择**

1.  过滤掉被认为主观下线的slave节点
2.  从slave中选择节点优先级最高的
3.  选择复制偏移量最大，复制最完整的节点
4.  运行id最小的从节点。

**slave节点和Sentinel节点的自动发现**  
sentinel不用配置其他Sentinel节点的地址，而是通过2秒一次发布订阅方式在channel通道通信，从而发现其他的Sentinel节点。同时也不用配置slave节点的地址，sentinel配置了master的地址，会通过`10秒一次`发送`info命令`给master和salve节点获取基本信息。通过这样的机制，有新的slave节点和Sentinel节点加入集群都会被自动发现。当master被标记为客观下线后，发送info命令的频率会变成`1秒一次`。

**TILT Sentinel保护模式**  
Sentinel的运行依赖系统时间，因此如果`系统时间出现意外变动`或者`进程被阻塞`等，都会导致Sentinel做出错误判断。因此Sentinel内置一个计时器，正常大约100毫秒会中断一次，通过当前系统时间和上一次中断的系统时间比较，如果这个时间超过2秒或者为负数，那么此时会进入TILT模式，此时仍旧会监控master，但是在集群中不会再起作用，不对is-master-down-add-addr请求做响应。因为它变得不可信了，直到保持`30秒`的正常计数才会退出TILT模式。

**参数配置**  
以下两个参数确保master网络异常后，不会继续写数据，两个条件不满足都会拒绝客户端请求。  
min-slaves-to-write 1 master最少要保证能往1个slave写数据  
min-slaves-max-lag 10 最长没有与slave同步数据的时间

##### redis-cluster集群 #####

redis-cluster相当于redis的分布式方案，redis的数据被拆分到多台redis实例上，cluster会通过计算key的hash值与`16384`相与计算命中到哪个桶。每个redis实例负责存储16384内的部分桶数据。  
**客户端连接只需要连接任意一个redis实例**，每个实例上包含一个cluster,存储key的时候会通过计算命中的桶由相应的节点处理。  
**redis实例之间的通信基于gossip协议**,认定一个节点宕机需要半数以上的节点认同。  
**节点的主从结构**，为了提高每个节点的可用性，每个节点可以配置主从结构，在主节点宕机后启动从节点。

--------------------

##### redis发布订阅PUB/SUB #####

类似简单版的消息队列，不提供消息持久化、事务、消息重试等等，简单的发布订阅。客户端往channel发布消息，订阅了该channel的客户端都会受到消息。Sentinel就是通过该形式通信。

--------------------

##### 事务 #####

redis支持简单的事务，通过MULTI命令开启事务，EXEC命令提交事务，在事务中执行的命令会在EXEC命令执行后才一起执行。`redis事务不支持回滚`，但是会`分析语法错误`，如果某个命令是错误的，那么redis会报错，且事务里的命令`都不会执行`，而如果是运行时才能知道的错误，比如对一个普通的key做集合的add操作，那么事务中可以正确执行的命令不会受到影响，即事务中只有报错的那条命令不会正确执行。如果要处理回滚，只能用户自己根据每条命令的执行结果自己做反操作回滚。

--------------------

##### SETNX做分布式锁 #####

SETNX 全称是SET if Not exists，即如果key不存在才能设值成功，成功返回1，失败返回0。该命令是原子操作的，即多线程操作不会有线程不安全问题。利用此特性可以用于做限时的分布式锁。

--------------------

##### jedis、Redisson、Lettuce #####

java操作redis的框架，jedis提供比较全面的redis命令支持，命令与api一致。Redisson和Lettuce支持异步通信，封装性比较高提供了全面的分布式锁方案，部分redis命令不支持。

#### 更新库应该删除缓存 不要更新缓存 ####

并发时，如果a先更新库，b再更新库，然后b更新缓存，a再更新缓存，就会导致缓存的是脏数据。

#### 怎么保证缓存和数据库的数据一致性 ####

*  如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，就去数据库中读取数据写入缓存，此时缓存中为脏数据。
 *  如果先写了库，在删除缓存前宕机了，没有删除掉缓存，则也会出现数据不一致情况。

1.  采取懒加载、双删的机制。懒加载即数据更新直接删除缓存而不是更新缓存，查询数据的时候再触发把数据加载到缓存。双删即先删除缓存，再更新数据库，再删除缓存。`注意`:第二次删除缓存要延迟一点时间，因为可能你第一次删除缓存后、更新数据库数据前，其他应用读取了脏数据在内存中，如果此时更新数据库后立马再删除缓存，其他应用可能在这个间隙又把数据更新到缓存。所以要`延迟执行`,可以通过mq延迟队列延迟执行，或者在内存中线程池延迟执行，看具体业务。
2.  如果第二次删除失败了呢？

*  设置超时时间，等缓存过期就失效，会有一段时间错误数据
 *  业务端重试或者中间件重试。  
    （1）业务端重试就是在业务代码取发送mq消息，另一端去消费重试。但是会侵入业务代码。  
    （2）中间件就是去订阅binlog文件，监听sql的更新，去删除缓存，失败了再发mq再消费重试。（删除缓存是幂等操作，可以重复执行）

[Link 1]: https://redis.io/topics/benchmarks
[Link 2]: https://redis.io/topics/lru-cache