Redis缓存整理总结

Posted 2021-04-07 架构师

架构师（JiaGouX）

我们都是架构师！
架构未来，你来不来？

原文：blog.csdn.net/m0_47439033/article/details/105815145

   

Redis

---

CAP理论

• 一致性（Consistency）：从数据层面来看的一致性

• 可用性（Availability）：从系统层面的可用性

• 分区容错性（Partition tolerance）：从网络层面的容错性

随着读多写少场景的出现，导致需要读取数据的时间变慢，为了提升性能，出现了数据库缓存技术，对数据库的读取进行分离。web2.0时代，网民的生产力大增，存储总量也在增加，目前还是读多写少模式，原有的缓存技术显然不能满足写的压力，所以，出现了分库分表，实现读写分离。其中比较常用的一种缓存技术是用Redis做缓存

什么是Redis

Redis是一个基于内存且支持持久化的key-value的NoSQL数据库，其中每个key和value都是使用对象表示的，具有以下特征：多样数据类型、持久化、主从同步

Redis持久化机制

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

实现：单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程写入到临时文件中，持久化的过程结束了，再用这个临时文件替换上次的快照文件，然后子进程退出，内存释放。

两种持久化机制

• RDB : redis默认的持久化方式，按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期

• AOF : Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于mysql的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容

两种同时开启时，数据恢复redis会优先选择AOF

缓存雪崩，缓存穿透，缓存预热等问题

缓存雪崩

缓存雪崩可以理解为原有的缓存失效，新缓存未到期间，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃

解决方法
最多的解决方案就是加锁或者队列的方式来保证不会有太多的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开

缓存穿透

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

解决方法

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

• 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴

补充：布隆过滤器：本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构，特点是高效地插入和查询，可以用来告诉你 “某样东西一定不存在或者可能存在”，布隆过滤器是一个 bit 向量或者说 bit 数组
bitmap：Bit-map就是用一个bit位来标记某个元素对应的Value， 而Key即是该元素。由于采用了Bit为单位来存储数据，因此在存储空间方面，可以大大节省

缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据
解决思路

• 直接写个缓存刷新页面，上线时手工操作下

• 数据量不大，可以在项目启动的时候自动进行加载

• 定时刷新缓存

缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种

1. 定时去清理过期的缓存

2. 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）

以参考日志级别设置预案：

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

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

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

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

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略

热点数据和冷数据

热点数据，缓存才有价值，对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存了，不仅占用内存，而且价值不大
对于热点数据，比如一个导航产品，将导航信息缓存以后，可能读取数百万次，数据更新前至少读取两次，缓存才有意义，这个是最基本的策略，如果缓存还没起到作用就失效了，那就没太大的价值了

Memcacge和Redis的区别有哪些

1. 存储方式：Memecache把数据全部存在内存中，断电后会挂掉，数据不能超过内存大小，Redis有部分存在硬盘上，redis可以持久化数据

2. 数据支持类型memcached所有的值均是简单的字符串，redis作为代替者，支持更丰富的数据类型，提供list，set, zset，hash等数据结构的存储

3. 使用底层模型不同，他们之间底层实现方式以及客户端之间的通信的应用协议不一样，Redis直接自己构建了VM机制，因为一般的系统调用系统函数，会浪费一定的时间去移动和请求

4. value值大小不同，redis最大可以达到512M， memcache只有1M

5. redis的速度比memcached快很多

6. Redis支持数据的备份，即master-slave模式的数据备份

单线程的Redis为什么这么快

1. 纯内存操作

2. 单线程操作，避免了频繁的上下文切换

3. 采用了非阻塞IO多路复用机制

redis的数据类型以及使用场景

1. String
   这个其实没啥好说的，最常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

2. hash
   这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

3. list
   使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。本人还用一个场景，很合适—取行情信息。就也是个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。

4. set
   因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
   另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

5. sorted set
   sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。

Redis内部结构

• dict 本质上是为了解决算法中的查找问题（Searching）是一个用于维护key和value映射关系的数据结构，与很多语言中的Map或dictionary类似

• sds 就等同于char * 它可以存储任意二进制数据，不能像C语言字符串那样以字符’\0’来标识字符串的结 束，因此它必然有个长度字段

• skiplist （跳跃表） 跳表是一种实现起来很简单，单层多指针的链表，它查找效率很高，堪比优化过的二叉平衡树，且比平衡树的实现

• quicklist zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来

• ziplist 压缩表 ziplist是一个编码后的列表，是由一系列特殊编码的连续内存块组成的顺序型数据结构

redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略
为什么不用定时删除策略
定时删除，用一个定时器来负责监视Key，过期则自动删除。虽然内存及时释放，但是十分消耗CPU的资源。在大并发请求下，CPU要将时间应用在处理请求上，而不是删除key，因此没有采用这个策略

定期删除+惰性删除是如何工作的
定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

内存淘汰机制设置
在redis.conf中配置

 
   
   
 

  
    
    
  
 
   
 
    
 
     
 
    
 
    
maxmemory-policy volatile-lru
 
   
 
   
   
 

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

• no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错

Redis常见性能问题和解决方案

1. Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件

2. 如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次

3. 为了主从复制的速度和连接的稳定性， Master 和 Slave 最好在同一个局域网内

4. 尽量避免在压力很大的主库上增加从库

5. 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <-
   Slave3…

Redis事务

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的
Redis会将一个事务中的所有命令序列化，然后按顺序执行。
1.redis 不支持回滚“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
2.如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
3.如果在一个事务中出现运行错误，那么正确的命令会被执行。

1. MULTI命令用于开启一个事务，它总是返回OK。MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。

2. EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。当操作被打断时，返回空值 nil 。

3. 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。

4. WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。

Redis的三种集群

主从复制

主从复制原理：

• 从服务器连接主服务器，发送SYNC命令；

• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；

• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；

• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照； 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；

• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）

• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

主从复制优缺点：

优点：

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离

• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成

• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。
哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

1. 监控主服务器和从服务器是否正常运行。

2. 主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

• 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。

• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）

• 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态

• 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）

• 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。

• 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
  若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

哨兵模式的优缺点
优点：

• 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

• 主从可以自动切换，系统更健壮，可用性更高。

缺点：Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

Redis-Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。

• 节点的fail是通过集群中超过半数的节点检测失效时才生效。

• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

·END·

---

架构师

我们都是架构师！

关注架构师(JiaGouX)，添加“星标”

获取每天技术干货，一起成为牛逼架构师

技术群请加若飞：1321113940 进架构师群

投稿、合作、版权等邮箱：[e-mail]