Redis专题（1）：构建知识图谱

 

Redis是干嘛用的？

Redis可以用作持久化的存储吗？

Redis怎么进行持久化操作呢？

Redis的内存淘汰机制有哪些？

我们还可以用Redis做哪些事情？分别利用了Redis的哪个指令？

思考：不知道这些常用工具的底层实现是什么。

一、Redis是什么

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI 、C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

这里我引用了Redis教程里对Redis的描述，很官方，但是很标准。 可基于内存亦可持久化的日志型、Key-Value数据库。 我认为这个描述很贴切很全面。

1.1 Redis的行业地位

Redis是互联网技术领域使用最为广泛的存储中间件，因超高的性能、完美的文档、多方面的应用能力以及丰富完善的客户端支持在存储方面独当一面，广受好评，尤其以其性能和读取速度而成为了领域中最受青睐的中间件。基本上每一个软件公司都会使用Redis，其中包括很多大型互联网公司，比如京东、阿里、腾讯、github等。因此，Redis也成为了后端开发人员必不可少的技能。

1.2 知识图谱

在我看来，学习每一项技术，都需要有一个清晰的脉络和结构，不然你也不知道自己会了哪些、还有多少没学会。就像一本书，如果没有目录章节，也就失去了灵魂。

因此我试图总结出Redis的知识图谱，也称为脑图，如下图所示，可能知识点不是很全，后续会不断更新补充。

 

本系列文章的知识点也会和这个脑图基本一致，本文先介绍Redis的基本知识，后续文章会详细介绍Redis的数据结构、应用、持久化等多个方面。

二、Redis优点

2.1 速度快

作为缓存工具，Redis最广为人知的特点就是快，到底有多快呢？Redis单机qps（每秒的并发）可以达到110000次/s，写的速度是81000次/s。 那么，Redis为什么这么快呢？

  • 绝大部分请求是纯粹的内存操作，非常快速；
  • 使用了很多查找操作都特别快的数据结构进行数据存储，Redis中的数据结构是专门设计的。如HashMap，查找、插入的时间复杂度都是O(1)；
  • 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁、释放锁操作，没有因为可能出现死锁而导致的性能消耗；
  • 用到了非阻塞I/O多路复用机制。

2.2 丰富的数据类型

Redis有5种常用的数据类型：String、List、Hash、set、zset，每种数据类型都有自己的用处。

2.3 原子性，支持事务

Redis支持事务，并且它的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。

2.4 丰富的特性

Redis具有丰富的特性，比如可以用作分布式锁；可以持久化数据；可以用作消息队列、排行榜、计数器；还支持publish/subscribe、通知、key过期等等。当我们要用中间件来解决实际问题的时候，Redis总能发挥出自己的用处。

三、Redis和Memcache对比

Memcache和Redis都是优秀的、高性能的内存数据库，一般我们说到Redis的时候，都会拿Memcache来和Redis做对比。（为什么要做对比呢？当然是要衬托出Redis有多好，没有对比，就没有伤害~）对比的方面包括：

3.1 存储方式

  • Memcache把数据全部存在内存之中，断电后会挂掉，无法做到数据的持久化，且数据不能超过内存大小。

  • Redis有一部分数据存在硬盘上，可以做到数据的持久性。

3.2 数据支持类型

  • Memcache对数据类型支持相对简单，只支持String类型的数据结构。

  • Redis有丰富的数据类型，包括：String、List、Hash、Set、Zset。

3.3 使用的底层模型

  • 它们之间底层实现方式以及与客户端之间通信的应用协议不一样。

  • Redis直接自己构建了VM机制 ，因为一般的系统调用系统函数，会浪费一定的时间去移动和请求。

3.4 存储值大小

  • Redis最大可以存储1GB，而memcache只有1MB。

看到这里，会不会觉得Redis特别好，全是优点，完美无缺？其实Redis还是有很多缺点的，这些缺点平常我们该如何克服呢？

四、Redis存在的问题及解决方案

4.1 缓存数据库的双写一致性的问题

问题：一致性的问题是分布式系统中很常见的问题。一致性一般分为两种：强一致性和最终一致性，当我们要满足强一致性的时候，Redis也无法做到完美无瑕，因为数据库和缓存双写，肯定会出现不一致的情况，Redis只能保证最终一致性。

解决：我们如何保证最终一致性呢？

  • 第一种方式是给缓存设置一定的过期时间，在缓存过期之后会自动查询数据库，保证数据库和缓存的一致性。

  • 如果不设置过期时间的话，我们首先要选取正确的更新策略：先更新数据库再删除缓存。但我们删除缓存的时候也可能出现某些问题，所以需要将要删除的缓存的key放到消息队列中去，不断重试，直到删除成功为止。

4.2 缓存雪崩问题

问题： 缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决：

  • 设置缓存过期时间的时候加一个随机值。
  • 设置多级缓存，缓存1设置缓存时间，缓存2不设置，1过期后直接返回缓存2，并且启动一个进程去更新缓存1和2。
  • 如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
  • 设置热点数据永远不过期。

4.3 缓存穿透问题

问题： 缓存穿透是指一些非正常用户(黑客)故意去请求缓存和数据库中都没有的数据，导致所有的请求都集中到到数据库上，从而导致数据库连接异常。 

解决:

  • 利用互斥锁。缓存失效的时候，不能直接访问数据库，而是要先获取到锁，才能去请求数据库。没得到锁，则休眠一段时间后重试。

  • 采用异步更新策略。无论key是否取到值，都直接返回。value值中维护一个缓存失效时间，缓存如果过期，异步起一个线程去读数据库，更新缓存。需要做缓存预热(项目启动前，先加载缓存)操作。

  • 提供一个能迅速判断请求是否有效的拦截机制。比如利用布隆过滤器，内部维护一系列合法有效的key，迅速判断出请求所携带的Key是否合法有效。如果不合法，则直接返回。

  • 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；

4.4 缓存击穿

问题： 缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

解决:

  • 设置热点数据永远不过期。
  • 加互斥锁。

4.5 缓存的并发竞争问题

问题：

缓存并发竞争的问题，主要发生在多线程对某个key进行set的时候，这时会出现数据不一致的情况。

比如Redis中我们存着一个key为amount的值，它的value是100，两个线程同时都对value加100然后更新，正确的结果应该是变为300。但是两个线程拿到这个值的时候都是100，最后结果也就是200，这就导致了缓存的并发竞争问题。

解决：

  • 如果多线程操作没有顺序要求的话，我们可以设置一个分布式锁，然后多个线程去争夺锁，谁先抢到锁谁就可以先执行。这个分布式锁可以用zookeeper或者Redis本身去实现。
  • 可以利用Redis的incr命令。
  • 当我们的多线程操作需要顺序的时候，我们可以设置一个消息队列，把需要的操作加到消息队列中去，严格按照队列的先后执行命令。

五、Redis的过期策略

定期删除 + 惰性删除的过期策略+内存淘汰机制

如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时大量过期key堆积在内存里，导致redis内存块耗尽了，就走内存淘汰机制。

 

redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的 key。除了定时遍历之外，它还会使用惰性策略来删除过期的 key，所谓惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除。定时删除是集中处理，惰性删除是零散处理。

通过配合使用这两种删除策略，服务器可以很好地合理使用cpu时间和避免浪费内存空间之间取得平衡。

Redis对于过期键有三种清除策略：

  • 被动删除：惰性删除是被动删除策略。当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key
  • 主动删除：定时删除和定期删除是主动删除策略。由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key
  • 当前已用内存超过maxmemory限定时，触发主动清理策略

Redis随着数据的增多，内存占用率会持续变高，我们以为一些键到达设置的删除时间就会被删除，但是时间到了，内存的占用率还是很高，这是为什么呢？

5.1 定期删除

Redis 默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。

  1. 从过期字典中随机 20 个 key；
  2. 删除这 20 个 key 中已经过期的 key；
  3. 如果过期的 key 比率超过 1/4，那就重复步骤 1；

同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，默认不会超过 25ms。

如果某一时刻，有大量key同时过期，Redis 会持续扫描过期字典，造成客户端响应卡顿，因此设置过期时间时，就尽量避免这个问题，在设置过期时间时，可以给过期时间设置一个随机范围，避免同一时刻过期。

如何配置定期删除执行时间间隔

redis的定时任务默认是10s执行一次，如果要修改这个值，可以在redis.conf中修改hz的值。

redis.conf中，hz默认设为10，提高它的值将会占用更多的cpu，当然相应的redis将会更快的处理同时到期的许多key，以及更精确的去处理超时。 hz的取值范围是1~500，通常不建议超过100，只有在请求延时非常低的情况下可以将值提升到100。

单线程的redis，如何知道要运行定时任务？

redis是单线程的，线程不但要处理定时任务，还要处理客户端请求，线程不能阻塞在定时任务或处理客户端请求上，那么，redis是如何知道何时该运行定时任务的呢？

Redis 的定时任务会记录在一个称为最小堆的数据结构中。这个堆中，最快要执行的任务排在堆的最上方。在每个循环周期，Redis 都会将最小堆里面已经到点的任务立即进行处理。处理完毕后，将最快要执行的任务还需要的时间记录下来，这个时间就是接下来处理客户端请求的最大时长，若达到了该时长，则暂时不处理客户端请求而去运行定时任务。

 

先说一下时间事件，对于持续运行的服务器来说， 服务器需要定期对自身的资源和状态进行必要的检查和整理， 从而让服务器维持在一个健康稳定的状态， 这类操作被统称为常规操作（cron job）

在 Redis 中， 常规操作由 redis.c/serverCron 实现， 它主要执行以下操作

  • 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。

  • 清理数据库中的过期键值对。

  • 对不合理的数据库进行大小调整。

  • 关闭和清理连接失效的客户端。

  • 尝试进行 AOF 或 RDB 持久化操作。

  • 如果服务器是主节点的话，对附属节点进行定期同步。

  • 如果处于集群模式的话，对集群进行定期同步和连接测试。

Redis 将 serverCron 作为时间事件来运行， 从而确保它每隔一段时间就会自动运行一次， 又因为 serverCron 需要在 Redis 服务器运行期间一直定期运行， 所以它是一个循环时间事件： serverCron 会一直定期执行，直到服务器关闭为止。

在 Redis 2.6 版本中， 程序规定 serverCron 每秒运行 10 次， 平均每 100 毫秒运行一次。 从 Redis 2.8 开始， 用户可以通过修改 hz选项来调整 serverCron 的每秒执行次数， 具体信息请参考 redis.conf 文件中关于 hz 选项的说明

 

 

5.2 定时删除

　　在设置键的过期时间的同时，创建一个定时器( timer ). 让定时器在键的过期时间来临时，立即执行对键的删除操作。

　　这种方式cpu的资源会被大幅度地占据，资源的利用率变低。所以我们选择采用定期删除。

　　但是此种策略对CPU时间是最不友好的。在过期key比较多的情况下，删除过期key这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期key上，无疑会对服务器的响应时间和吞吐量造成影响。

5.3 惰性删除

只有key被操作时(如GET)，REDIS才会被动检查该key是否过期，如果过期则删除之并且返回NIL。

1、这种删除策略对CPU是友好的，删除操作只有在不得不的情况下才会进行，不会其他的expire key上浪费无谓的CPU时间。

2、但是这种策略对内存不友好，一个key已经过期，但是在它被操作之前不会被删除，仍然占据内存空间。如果有大量的过期键存在但是又很少被访问到，那会造成大量的内存空间浪费。expireIfNeeded(redisDb *db, robj *key)函数位于src/db.c。

 

5.4 Redis的内存淘汰机制

Redis的内存淘汰机制一般有6种，如下图所示：

  • noeviction：当内存不足以容纳新写入数据时，新写入操作会报错.（这个一般没人用)
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
  • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。(这个一般没人用)
  • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。（这个一般不太合适）
  • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
  • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

那么我们如何去配置Redis的内存淘汰机制呢？

在Redis.conf中我们可以进行配置

# maxmemory-policy allkeys-lru

aof/rdb和复制功能对过期键的处理

rdb

  • 生成rdb文件：生成时，程序会对键进行检查，过期键不放入rdb文件。
  • 载入rdb文件：载入时，如果以主服务器模式运行，程序会对文件中保存的键进行检查，未过期的键会被载入到数据库中，而过期键则会忽略；如果以从服务器模式运行，无论键过期与否，均会载入数据库中，过期键会通过与主服务器同步而删除。

aof

  • 当服务器以aof持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被删除，那么aof文件不会因为这个过期键而产生任何影响；当过期键被删除后，程序会向aof文件追加一条del命令来显式记录该键已被删除。
  • aof重写过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的aof文件中。

复制

当服务器运行在复制模式下时，从服务器的过期删除动作由主服务器控制：

  • 主服务器在删除一个过期键后，会显式地向所有从服务器发送一个del命令，告知从服务器删除这个过期键;
  • 从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像处理未过期的键一样来处理过期键;
  • 从服务器只有在接到主服务器发来的del命令后，才会删除过期键。

六、小结

本文初探Redis，大概整理出了Redis的知识图谱，对照之下可以发现Redis居然有这么多的知识点需要学习；接着我们分析了Redis的优缺点，知道了其基于内存的高效的读写速度和丰富的数据类型，也分析了Redis面对数据一致性、缓存穿透、缓存雪崩等问题时该如何处理；最后我们了解了Redis的过期策略和缓存淘汰机制。

posted @ 2019-08-01 20:50  qxwang  阅读(78)  评论(0)    收藏  举报