Redis详解-持续更新中

傷城~ 2023-01-23 05:58 15阅读 0赞

### Redis详解 ###

*  1. Redis概述
 *   *  1.1 什么是Redis
     *  1.2 Redis支持的数据类型
     *  1.3 Redis持久化
     *  1.4 Redis应用场景
     *  1.5 Redis数据淘汰策略（8种）
     *  1.5 Redis过期删除策略
     *  1.6 缓存穿透，击穿，雪崩是什么？解决方案
     *  1.7 Redis的zest跳表
     *  1.8 Redis，memcache，MongoDB区别
 *  2. Redis客户端
 *   *  2.1 Redis可视化客户端
     *  2.2 Redis Desktop Manager
     *  2.3 Redis Client
 *  3. Redis原理

# 1. Redis概述 #

## 1.1 什么是Redis ##

基于内存的，Key-Value形式的非关系型数据库。  
读写速度非常快，每秒可达到10万+的QPS。下边是官方说法。

Redis(Remote Dictionary Server) Redis 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API 的非关系型数据库。
    
    传统数据库遵循 ACID 规则。而 Nosql（Not Only SQL 的缩写，是对不同于传统的关系型数据库的数据库管理系统的统称） 一般为分布式而分布式一般遵循 CAP 定理。
    
    与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存，每秒可以处理超过 10 万次读写操作，是已知性能最快的 Key-Value 数据库。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务、持久化、LUA 脚本、LRU 驱动事件、多种集群方案。

github 源码：[https://github.com/antirez/redis][https_github.com_antirez_redis]  
redis官网：[https://redis.io/][https_redis.io]  
redis教程：[https://www.redis.com.cn/redis-intro.html][https_www.redis.com.cn_redis-intro.html]

## 1.2 Redis支持的数据类型 ##

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。
    
    String（字符串）
    string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
    
    Hash（哈希）
    Redis hash 是一个键值(key=>value)对集合。
    Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。
    
    List（列表）
    Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部或者尾部。
    
    Set（集合）
    Redis的Set是string类型的无序集合。
    集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
    
    ZSet(sorted set：有序集合)
    Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
    不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
    zset的成员是唯一的,但分数(score)却可以重复。

## 1.3 Redis持久化 ##

持久化的目的：
    持久化的目的主要是做灾难恢复，数据恢复。由于Redis的数据全都放在内存里面，如果Redis挂了，没有配置持久化的话，重启的时候数据会全部丢失。 突然间，大量的请求过来，缓存全都无法命中，造成缓存雪崩，mysql无法承载大量的请求，造成整个系统崩溃。如果把Redis持久化做好，即使Redis故障了，也能够立即重启，对外提供服务。
     
    Redis持久化分为两种：
    RDB持久化： 在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储 。
    AOF持久化： AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。            
            如果同时使用RDB和AOF 两种持久化机制，那么在 redis 重启的时候，会使用 AOF 来重新构建数据，因为 AOF 中的数据更加完整。
    
    RDB持久化的配置：
         Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
     　save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
       save 300 10             #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
       save 60 10000           #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
    AOF持久化配置：
      在Redis的配置文件中存在三种同步方式，它们分别是：
      appendfsync always      #每次有数据修改发生时都会写入AOF文件。
      appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。
      appendfsync no            #从不同步。高效但是数据不会被持久化。
     
    RDB和AOF的优缺点#
    RDB的优缺点：
    一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数 据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
    相对于 AOF 持久化机制来说，直接基于 RDB 数据文件来重启和恢复 redis 进程，更加快速。
    RDB 对 redis 对外提供的读写服务，影响非常小，可以让 redis 保持高性能，因为 redis 主进程只需要 fork 一个子进程，让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
    对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
    如果想要在 redis 故障时，尽可能少的丢失数据，那么 RDB 没有 AOF 好。一般来说，RDB 数据快照文件，都是每隔 5 分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。
    RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。
     
    AOF的优缺点：
    AOF 可以更好的保护数据不丢失，一般 AOF 会每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。
    AOF 日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损。 如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题。
    AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log 的时候，会对其中的指令进行压缩，创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候，再交换新老日志文件即可。 因此在进行rewrite切换时可以更好的保证数据安全性。
    AOF以一个格式清晰、易于理解的日志文件用于记录所有的修改操作， 非常适合做灾难性的误删除的紧急恢复。 比如有人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝 AOF 文件，将最后一条flushall命令给删了，然后再将该aof文件放回去，就可以通过恢复机制，自动恢复所有数据。
    对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
    AOF 开启后，支持的写 QPS 会比 RDB 支持的写 QPS 低， 因为 AOF 一般会配置成每秒 fsync 一次日志文件。
    类似 AOF 这种较为复杂的基于命令日志 / merge / 回放的方式，比基于 RDB 每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有 bug。
    如何选择？#
    
    RDB和AOF如何选择？
     不要仅仅使用 RDB，因为那样会导致你丢失很多数据；
    也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；
    redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

## 1.4 Redis应用场景 ##

redis应用场景总结redis平时我们用到的地方蛮多的，下面就了解的应用场景做个总结：
    
    1、热点数据的缓存
    由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据，另外结合expire，我们可以设置过期时间然后再进行缓存更新操作，这个功能最为常见，我们几乎所有的项目都有所运用。
    
    2、限时业务的运用
    redis中可以使用expire命令设置一个键的生存时间，到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。
    
    3、计数器相关问题
    redis由于incrby命令可以实现原子性的递增，所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
    
    4、排行榜相关问题
    关系型数据库在排行榜方面查询速度普遍偏慢，所以可以借助redis的SortedSet进行热点数据的排序。
    在奶茶活动中，我们需要展示各个部门的点赞排行榜， 所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash,通过zrangebyscore就可以按照点赞数获取排行榜，然后再根据username获取用户的hash信息，这个当时在实际运用中性能体验也蛮不错的。
     
    5、分布式锁 
    这个主要利用redis的setnx命令进行，setnx："set if not exists"就是如果不存在则成功设置缓存同时返回1，否则返回0 ，这个特性在俞你奔远方的后台中有所运用，因为我们服务器是集群的，定时任务可能在两台机器上都会运行，所以在定时任务中首先 通过setnx设置一个lock，如果成功设置则执行，如果没有成功设置，则表明该定时任务已执行。 当然结合具体业务，我们可以给这个lock加一个过期时间，比如说30分钟执行一次的定时任务，那么这个过期时间设置为小于30分钟的一个时间 就可以，这个与定时任务的周期以及定时任务执行消耗时间相关。
    当然我们可以将这个特性运用于其他需要分布式锁的场景中，结合过期时间主要是防止死锁的出现。

## 1.5 Redis数据淘汰策略（8种） ##

redis5.0之前是6种淘汰策略，5.0之后新增了两个淘汰策略，总共8种。

volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。
    volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰。
    volatile-random：从已设置过期时间的数据集中任意选择数据淘汰。
    volatile-lfu：从已设置过期时间的数据集挑选使用频率最低的数据淘汰。
    
    allkeys-lru：从数据集中挑选最近最少使用的数据淘汰
    allkeys-lfu：从数据集中挑选使用频率最低的数据淘汰。
    allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
    
    no-enviction（驱逐）：禁止驱逐数据，这也是默认策略。意思是当内存不足以容纳新入数据时，新写入操作就会报错，请求可以继续进行，线上任务也不能持续进行，采用no-enviction策略可以保证数据不被丢失。
    
    ---------------------------------------------------------
    缓存内存三种淘汰策略中有FIFO、LRU、LFU
    
    FIFO是最简单的淘汰策略，遵循着先进先出的原则。
    LRU（Least Recently Used）表示最近最少使用，该算法根据数据的历史访问记录来进行淘汰数据，其核心思想是“**如果数据最近被访问过，那么将来被访问的几率也更高**”。
    LFU（Least Frequently Used）表示最不经常使用，它是根据数据的历史访问频率来淘汰数据，其核心思想是“如果数据过去被访问多次，那么将来被访问的频率也更高”。
    
    LRU和LFU算法都是在Redis内存占用满的情况下的淘汰策略

## 1.5 Redis过期删除策略 ##

在Redis中过期的key不会立刻从内存中删除，而是会同时以下面两种策略进行删除：
    
    惰性删除：当key被访问时检查该key的过期时间，若已过期则删除；已过期未被访问的数据仍保持在内存中，消耗内存资源；
    定期删除：每隔一段时间，随机检查设置了过期的key并删除已过期的key；维护定时器消耗CPU资源；
    
    Redis每10秒进行一次过期扫描：
    随机取20个设置了过期策略的key；
    检查20个key中过期时间中已过期的key并删除；
    如果有超过25%的key已过期则重复第一步；
    
    这种循环随机操作会持续到过期key可能仅占全部key的25%以下时，并且为了保证不会出现循环过多的情况，默认扫描时间不会超过25ms；
    
    官方文档：https://redis.io/commands/expire#expire-accuracy

## 1.6 缓存穿透，击穿，雪崩是什么？解决方案 ##

设计一个缓存系统，不得不考虑：缓存穿透，缓存击穿与缓存失效时的雪崩效应。
    在缓存系统中，前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。
    
    缓存穿透
    描述：
    缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求。由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
    解决方案：
    1、接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
    2、缓存null。从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。
    
    缓存击穿
    描述：
     缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
    解决方案：
    1、设置热点数据永不过期。
    2、接口限流与熔断，降级。重要的接口一定要做好限流策略，防止用户恶意刷接口，同时要降级准备，当接口中的某些 服务  不可用时候，进行熔断，失败快速返回机制。
    3、布隆过滤器。bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小，
    4、加互斥锁
    互斥加锁就是缓存中存在直接返回，缓存中不存在时需要先获取锁才能到数据库查询，从数据库查询到数据更新缓存并返回结果，剩下的其他线程从缓存中读取。
    
    缓存雪崩
    缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。
    和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
    解决方案：
    1、缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
    2、如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
    3、设置热点数据永远不过期。

## 1.7 Redis的zest跳表 ##

1. 跳跃表是有序集合（zset）的底层实现之一；
    2. 由zskiplist和zskiplistNode组成；
    3. 每个跳跃表节点的层数都是1-32之间的随机数（每创建一个节点的时候，程序会随机生成一个数[1-32]作为level数组的大小）；
    4. 同一个跳跃表中，多个节点可以包含相同的分值，但节点的成员对象是唯一的；
    5. 按分值排序，若分值相同就按成员对象大小排序。

## 1.8 Redis，memcache，MongoDB区别 ##

Redis是一个开源（BSD许可），内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列代理。
    Memcached是一个自由开源的，高性能，分布式内存对象缓存系统。
    MongoDB是一个基于分布式文件存储的数据库,文档型的非关系型数据库，与上面两者不同。
     
    1.性能上：
         性能上都很出色，具体到细节，由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。
    前两者性能差不多，大于 Mongodb。
     
    2.内存空间和数据量大小：
         MemCached可以修改最大内存，采用LRU算法。Redis增加了VM的特性，突破了物理内存的限制。（2.4后取消
     　 MongoDB 适合大数据量的存储，依赖操作系统 VM 做内存管理，吃内存也比较厉害，服务不要和别的服务在一起。
     
    3.操作便利上：
         MemCached数据结构单一，仅用来缓存数据，而Redis支持更加丰富的数据类型，也可以在服务器端直接对数据进行丰富的操作,这样可以减少网络IO次数和数据体积。
     　 Mongodb 支持丰富的数据表达，索引，最类似关系型数据库，支持的查询语言非常丰富。
     
    4.可靠性上：
         MemCached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的。Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价。
     　 MongoDB 从 1.8 版本开始采用 binlog 方式支持持久化的可靠性。
     
    5.应用场景：
         Memcached：动态系统中减轻数据库负载，提升性能；做缓存，适合多读少写，大数据量的情况（如人人网大量查询用户信息、好友信息、文章信息等）。
         Redis：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统（如新浪微博的计数和微博发布部分系统，对数据安全性、读写要求都很高）。
     　 MongoDB:主要解决海量数据的访问效率问题。 
     
    需要慎重考虑的部分
     
    1.Memcached单个key-value大小有限，一个value最大只支持1MB，而Redis最大支持512MB
    2.Memcached只是个内存缓存，对可靠性无要求；而Redis更倾向于内存数据库，因此对对可靠性方面要求比较高
    3.从本质上讲，Memcached只是一个单一key-value内存Cache；而Redis则是一个数据结构内存数据库，支持五种数据类型，因此Redis除单纯缓存作用外，还可以处理一些简单的逻辑运算，Redis不仅可以缓存，而且还可以作为数据库用
    4.新版本（3.0）的Redis是指集群分布式，也就是说集群本身均衡客户端请求，各个节点可以交流，可拓展行、可维护性更强大。
    5. MongoDB不支持事务。

# 2. Redis客户端 #

## 2.1 Redis可视化客户端 ##

Redis的可视化客户端目前较流行的有两个：Redis Desktop Manager 、 Redis Client 。  
Redis官网地址：[https://www.redis.com.cn/][https_www.redis.com.cn]

## 2.2 Redis Desktop Manager ##

一款基于Qt5的跨平台Redis桌面管理软件  
支持: Windows 7+, Mac OS X 10.10+, Ubuntu 14+  
特点： C++ 编写，响应迅速，性能好。但不支持数据库备份与恢复。  
下载地址：[http://docs.redisdesktop.com/en/latest/install/\#windows][http_docs.redisdesktop.com_en_latest_install_windows]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70]![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 1]

## 2.3 Redis Client ##

项目简介：　使用Java编写，功能丰富，缺点是性能稍差，网络不好时，会不时断线。  
下载地址：[https://github.com/caoxinyu/RedisClient/tree/windows/release][https_github.com_caoxinyu_RedisClient_tree_windows_release]

# 3. Redis原理 #

[https_github.com_antirez_redis]: https://github.com/antirez/redis
[https_redis.io]: https://redis.io/
[https_www.redis.com.cn_redis-intro.html]: https://www.redis.com.cn/redis-intro.html
[https_www.redis.com.cn]: https://www.redis.com.cn/
[http_docs.redisdesktop.com_en_latest_install_windows]: http://docs.redisdesktop.com/en/latest/install/#windows
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20210713113824413.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L20wXzM3NTgzNjU1_size_16_color_FFFFFF_t_70 1]: /images/20221004/78cd50c315b2410aba9de08c49e4f56b.png
[https_github.com_caoxinyu_RedisClient_tree_windows_release]: https://github.com/caoxinyu/RedisClient/tree/windows/release