Redis详细解析(一)

缺乏、安全感 2022-11-15 11:56 165阅读 0赞

##### 一、背景介绍 #####

1.Redis是一个使用ANSI C编写的开源、支持网络、基于内存、可选持久化的高性能键值对数据库。从2009年第一个版本起Redis已经走过了10多个年头，目前Redis仍然是最流行的key-value型内存数据库的之一。  
2.优秀的开源项目离不开大公司的支持，在2013年5月之前，其开发由VMware赞助，而2013年5月至2015年6月期间，其开发由毕威拓赞助，从2015年6月开始，Redis的开发由Redis Labs赞助。  
3.Redis提供了Java、C/C++、C\#、 PHP 、JavaScript、 Perl 、Object-C、Python、Ruby、Erlang、Golang等多种主流语言的客户端，因此无论使用者是什么语言栈总会找到属于自己的那款客户端，受众非常广。

##### 二、Redis支持的数据类型及实现形式？ #####

Redis是基于标准C写的，只有基本的数据类型。  
五种数据类型：字符串String、列表List、哈希Hash、集合Set、有序集合Zset。  
redis底层实现形式：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NjI5Mjc3_size_16_color_FFFFFF_t_70]  
由上我们可以看出，ziplist压缩列表可以作为Zset、Set、List三种数据类型的底层实现，压缩列表是一种为了节约内存而开发的且经过特殊编码之后的连续内存块顺序型数据结构，底层结构还是比较复杂的。

##### 三、Redis的SDS和C字符串比较？ #####

在C语言中使用N+1长度的字符数组来表示字符串，尾部使用’\\0’作为结尾标志，对于此种实现无法满足Redis对于安全性、效率、丰富的功能的要求，因此Redis单独封装了SDS简单动态字符串结构。  
为节省各位时间，直接上干货：  
![在这里插入图片描述][20210401103617756.png]

##### 四、Redis 4.0之前的单线程模式？ #####

本质上Redis并不是单纯的单线程服务模型，一些辅助工作比如持久化刷盘、惰性删除等任务是由BIO线程来完成的，这里说的单线程主要是说与客户端交互完成命令请求和回复的工作线程。至于Antirez大佬当时是怎么想的设计为单线程不得而知，只能从几个角度来分析，来确定单线程模型的选择原因。

###### 1.单线程模式 ######

(1)**CPU并非瓶颈**：多线程模型主要是为了充分利用多核CPU，让线程在IO阻塞时被挂起让出CPU使用权交给其他线程，充分提高CPU的使用率，但是这个场景在Redis并不明显，因为CPU并不是Redis的瓶颈，Redis的所有操作都是基于内存的，处理事件极快，因此使用多线程来切换线程提高CPU利用率的需求并不强烈；

(2)**内存才是瓶颈**：单个Redis实例对单核的利用已经很好了，但是Redis的瓶颈在于内存，设想64核的机器假如内存只有16GB，那么多线程Redis有什么用武之地？

(3)**复杂的Value类型**：Redis有丰富的数据结构，并不是简单的Key-Value型的NoSQL，这也是Redis备受欢迎的原因，其中常用的Hash、Zset、List等结构在value很大时，CURD的操作会很复杂，如果采用多线程模式在进行相同key操作时就需要加锁来进行同步，这样就可能造成死锁问题。这时候你会问：将key做hash分配给相同的线程来处理就可以解决呀，确实是这样的，这样的话就需要在Redis中增加key的hash处理以及多线程负载均衡的处理，从而Redis的实现就成为多线程模式了，好像确实也没有什么问题，但是Antirez并没有这么做，大神这么做肯定是有原因的，果不其然，我们见到了集群化的Redis；

(4)**集群化扩展**：目前的机器都是多核的，但是内存一般128GB/64GB算是比较普遍了，但是Redis在使用内存60%以上稳定性就不如50%的性能了(至少笔者在使用集群化Redis时超过70%时，集群failover的频率会更高)，因此在数据较大时，当Redis作为主存，就必须使用多台机器构建集群化的Redis数据库系统，这样以来Redis的单线程模式又被集群化的处理所扩展了；

(5)**软件工程角度**：单线程无论从开发和维护都比多线程要容易非常多，并且也能提高服务的稳定性，无锁化处理让单线程的Redis在开发和维护上都具备相当大的优势；

(6)**类Redis系统**：Redis的设计秉承实用第一和工程化，虽然有很多理论上优秀的设计模式，但是并不一定适用自己，软件设计过程就是权衡的过程。业内也有许多类Redis的NoSQL，比如360基础架构组开发的Pika系统，基于SSD和Rocks存储引擎，上层封装一层协议转换，来实现Redis所有功能的模拟，感兴趣的可以研究和使用。

###### 2.Redis的文件事件和时间事件 ######

Redis作为单线程服务要处理的工作一点也不少，Redis是事件驱动的服务器，主要的事件类型就是：文件事件类型和时间事件类型，其中时间事件是理解单线程逻辑模型的关键。

**(1)时间事件**  
Redis的时间事件分为两类：  
定时事件：任务在等待指定大小的等待时间之后就执行，执行完成就不再执行，只触发一次；  
周期事件：任务每隔一定时间就执行，执行完成之后等待下一次执行，会周期性的触发；

**(2)周期性时间事件**  
Redis中大部分是周期事件，主要处理辅助任务，周期事件主要是服务器定期对自身运行情况进行检测和调整，从而保证稳定性，这项工作主要是ServerCron函数来完成的，周期事件的内容主要包括：

a.删除数据库的key

b.触发RDB和AOF持久化

c.主从同步

d.集群化保活

e.关闭清理死客户端链接

f.统计更新服务器的内存、key数量等信息

**(3)时间事件的无序链表**  
Redis的每个时间事件分为三个部分：

a.事件ID 全局唯一 依次递增

b.触发时间戳 ms级精度

c.事件处理函数 事件回调函数

时间事件：  
**a**. Redis的时间事件是存储在链表中的，并且是按照ID存储的，新事件在头部旧事件在尾部，但是并不是按照即将被执行的顺序存储的。

**b**. 也就是第一个元素50ms后执行，但是第三个可能30ms后执行，这样的话Redis每次从链表中获取最近要执行的事件时，都需要进行O(N)遍历，显然性能不是最好的，最好的情况肯定是类似于最小栈MinStack的思路，然而Antirez大佬却选择了无序链表的方式。

**c**.选择无序链表也是适合Redis场景的，因为Redis中的时间事件数量并不多，即使进行O(N)遍历性能损失也微乎其微，也就不必每次插入新事件时进行链表重排。

**(4)单线程模式中事件调度和执行**  
Redis服务中因为包含了时间事件和文件事件，事情也就变得复杂了，服务器要决定何时处理文件事件、何时处理时间事件、并且还要明确知道处理时间的时间长度，因此事件的执行和调度就成为重点。

Redis服务器会轮流处理文件事件和时间事件，这两种事件的处理都是同步、有序、原子地执行的，服务器也不会终止正在执行的事件，也不会对事件进行抢占。

**事件执行调度规则**  
文件事件是随机出现的，如果处理完成一次文件事件后，仍然没有其他文件事件到来，服务器将继续等待，在文件事件的不断执行中，时间会逐渐向最早的时间事件所设置的到达时间逼近并最终来到到达时间，这时服务器就可以开始处理到达的时间事件了。

由于时间事件在文件事件之后执行，并且事件之间不会出现抢占，所以时间事件的实际处理时间一般会比设定的时间稍晚一些。

**事件执行调度的代码实现**  
Redis源码ae.c中对事件调度和执行的详细过程在aeProcessEvents中实现，具体代码如下:

int aeProcessEvents(aeEventLoop *eventLoop, int flags)
    { 
      int processed = 0, numevents;
      if (!(flags & AE_TIME_EVENTS) && !(flags & AE_FILE_EVENTS))
        return 0;
    
      if (eventLoop->maxfd != -1 ||
        ((flags & AE_TIME_EVENTS) && !(flags & AE_DONT_WAIT))) { 
        int j;
        aeTimeEvent *shortest = NULL;
        struct timeval tv, *tvp;
    
        if (flags & AE_TIME_EVENTS && !(flags & AE_DONT_WAIT))
          shortest = aeSearchNearestTimer(eventLoop);
        if (shortest) { 
          long now_sec, now_ms;
          aeGetTime(&now_sec, &now_ms);
          tvp = &tv;
          long long ms =
            (shortest->when_sec - now_sec)*1000 +
            shortest->when_ms - now_ms;
    
          if (ms > 0) { 
            tvp->tv_sec = ms/1000;
            tvp->tv_usec = (ms % 1000)*1000;
          } else { 
            tvp->tv_sec = 0;
            tvp->tv_usec = 0;
          }
        } else { 
          if (flags & AE_DONT_WAIT) { 
            tv.tv_sec = tv.tv_usec = 0;
            tvp = &tv;
          } else { 
            tvp = NULL; /* wait forever */
          }
        }
        numevents = aeApiPoll(eventLoop, tvp);
        if (eventLoop->aftersleep != NULL && flags & AE_CALL_AFTER_SLEEP)
          eventLoop->aftersleep(eventLoop);
    
        for (j = 0; j < numevents; j++) { 
          aeFileEvent *fe = &eventLoop->events[eventLoop->fired[j].fd];
          int mask = eventLoop->fired[j].mask;
          int fd = eventLoop->fired[j].fd;
          int fired = 0;
          int invert = fe->mask & AE_BARRIER;
          if (!invert && fe->mask & mask & AE_READABLE) { 
            fe->rfileProc(eventLoop,fd,fe->clientData,mask);
            fired++;
          }
          if (fe->mask & mask & AE_WRITABLE) { 
            if (!fired || fe->wfileProc != fe->rfileProc) { 
              fe->wfileProc(eventLoop,fd,fe->clientData,mask);
              fired++;
            }
          }
          if (invert && fe->mask & mask & AE_READABLE) { 
            if (!fired || fe->wfileProc != fe->rfileProc) { 
              fe->rfileProc(eventLoop,fd,fe->clientData,mask);
              fired++;
            }
          }
          processed++;
        }
      }
      /* Check time events */
      if (flags & AE_TIME_EVENTS)
        processed += processTimeEvents(eventLoop);
      return processed;
    }

时间执行和调度伪码：

def aeProcessEvents()
      #获取当前最近的待执行的时间事件
      time_event = aeGetNearestTimer()
      #计算最近执行事件与当前时间的差值
      remain_gap_time = time_event.when - uinx_time_now()
      #判断时间事件是否已经到期 则重置 马上执行
      if remain_gap_time < 0:
        remain_gap_time = 0
      #阻塞等待文件事件 具体的阻塞等待时间由remain_gap_time决定
      #如果remain_gap_time为0 那么不阻塞立刻返回
      aeApiPoll(remain_gap_time)
      #处理所有文件事件
      ProcessAllFileEvent()
      #处理所有时间事件
      ProcessAllTimeEvent()

可以看到Redis服务器是边阻塞边执行的，具体的阻塞事件由最近待执行时间事件的等待时间决定的，在阻塞该最小等待时间返回之后，开始处理事件任务，并且先执行文件事件、再执行时间事件，所有即使时间事件要即刻执行，也需要等待文件事件完成之后再执行时间事件，所以比预期的稍晚。

##### 五、Redis是如何做持久化的及其基本原理 #####

通俗讲持久化就是将内存中的数据写入非易失介质中，比如机械磁盘和SSD。

在服务器发生宕机时，作为内存数据库Redis里的所有数据将会丢失，因此Redis提供了持久化两大利器：**RDB和AOF**

1.RDB 将数据库快照以二进制的方式保存到磁盘中。

2.AOF 以协议文本方式，将所有对数据库进行过写入的命令和参数记录到 AOF 文件，从而记录数据库状态。

**查看RDB配置：**

[redis@abc]$ cat /abc/redis/conf/redis.conf   
    save 900 1  
    save 300 10  
    save 60 10000  
    dbfilename "dump.rdb" 
    dir "/data/dbs/redis/rdbstro"

**解析：**  
前三行都是对触发RDB的一个条件， 如第一行表示每900秒钟有一条数据被修改则触发RDB，依次类推；只要一条满足就会进行RDB持久化；

第四行dbfilename指定了把内存里的数据库写入本地文件的名称，该文件是进行压缩后的二进制文件；

第五行dir指定了RDB二进制文件存放目录 ；

**修改RDB配置**  
在命令行里进行配置,服务器重启才会生效:

[redis@abc]$ bin/redis-cli
    127.0.0.1:6379> CONFIG GET save 
    1) "save"
    2) "900 1 300 10 60 10000"
    127.0.0.1:6379> CONFIG SET save "21600 1000" 
    OK

**RDB的SAVE和BGSAVE？**  
RDB文件适合数据的容灾备份与恢复，通过RDB文件恢复数据库耗时较短，可以快速恢复数据。

RDB持久化只会周期性的保存数据，在未触发下一次存储时服务宕机，就会丢失增量数据。当数据量较大的情况下，fork子进程这个操作很消耗cpu，可能会发生长达秒级别的阻塞情况。

SAVE是阻塞式持久化，执行命令时Redis主进程把内存数据写入到RDB文件中直到创建完毕，期间Redis不能处理任何命令。

BGSAVE属于非阻塞式持久化，创建一个子进程把内存中数据写入RDB文件里同时主进程处理命令请求。

**AOF详解**  
在使用AOF持久化方式时，Redis会将每一个收到的写命令都通过Write函数追加到文件中类似于MySQL的binlog。换言之AOF是通过保存对redis服务端的写命令来记录数据库状态的。

AOF文件有自己的存储协议格式：

[redis@abc]$ more appendonly.aof 
    *2     # 2个参数
    $6     # 第一个参数长度为 6
    SELECT     # 第一个参数
    $1     # 第二参数长度为 1
    8     # 第二参数
    *3     # 3个参数
    $3     # 第一个参数长度为 4
    SET     # 第一个参数
    $4     # 第二参数长度为 4
    name     # 第二个参数
    $4     # 第三个参数长度为 4
    Jhon     # 第二参数长度为 4

AOF配置：

[redis@abc]$ more ~/redis/conf/redis.conf
    dir "/data/dbs/redis/abcd"           #AOF文件存放目录
    appendonly yes                       #开启AOF持久化，默认关闭
    appendfilename "appendonly.aof"      #AOF文件名称（默认）
    appendfsync no                       #AOF持久化策略
    auto-aof-rewrite-percentage 100      #触发AOF文件重写的条件（默认）
    auto-aof-rewrite-min-size 64mb       #触发AOF文件重写的条件（默认）

当开启AOF后，服务端每执行一次写操作就会把该条命令追加到一个单独的AOF缓冲区的末尾，然后把AOF缓冲区的内容写入AOF文件里，由于磁盘缓冲区的存在写入AOF文件之后，并不代表数据已经落盘了，而何时进行文件同步则是根据配置的appendfsync来进行配置：

**appendfsync选项：always、everysec和no：**  
(1)always：服务器在每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里，保证了数据持久化的完整性，效率是最慢的但最安全的；

(2)everysec：服务端每隔一秒才会进行一次文件同步把内存缓冲区里的AOF缓存数据真正写入AOF文件里，兼顾了效率和完整性，极端情况服务器宕机只会丢失一秒内对Redis数据库的写操作；

(3)no：表示默认系统的缓存区写入磁盘的机制，不做程序强制，数据安全性和完整性差一些。

AOF比RDB文件更大，并且在存储命令的过程中增长更快，为了压缩AOF的持久化文件，Redis提供了重写机制以此来实现控制AOF文件的增长。

**AOF重写实现的理论基础是这样的：**  
(1)执行set hello world 50次

(2)最后执行一次 set hello china

(3)最终对于AOF文件而言前面50次都是无意义的，AOF重写就是将key只保存最后的状态。

(4)重写期间的数据一致性问题

子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 会出现数据库的数据和重写后的 AOF 文件中的数据不一致。

因此Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外， 还会追加到这个缓存中。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NjI5Mjc3_size_16_color_FFFFFF_t_70 1]  
当子进程完成 AOF 重写之后向父进程发送一个完成信号， 父进程在接到完成信号之后会调用信号处理函数，完成以下工作：  
(1)将 AOF 重写缓存中的内容全部写入到新 AOF 文件中  
(2)对新的 AOF 文件进行改名，覆盖原有的 AOF 文件  
(3)AOF重写的阻塞性

整个 AOF 后台重写过程中只有最后写入缓存和改名操作会造成主进程阻塞， 在其他时候AOF 后台重写都不会对主进程造成阻塞， 将 AOF 重写对性能造成的影响降到了最低。

AOF 重写可以由用户通过调用 BGREWRITEAOF 手动触发。  
服务器在 AOF 功能开启的情况下，会维持以下三个变量：

(1)当前 AOF 文件大小

(2)最后一次 重写之后， AOF 文件大小的变量

(3)AOF文件大小增长百分比

每次当 serverCron 函数执行时， 它都会检查以下条件是否全部满足， 如果是的话， 就会触发自动的 AOF 重写:

(1)没有 BGSAVE 命令在进行 防止于RDB的冲突  
(2)没有 BGREWRITEAOF 在进行 防止和手动AOF冲突  
(3)当前 AOF 文件大小至少大于设定值 基本要求 太小没意义  
(4)当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比

**Redis的数据恢复**  
Redis的数据恢复优先级:  
(1) 如果只配置 AOF ，重启时加载 AOF 文件恢复数据；

(2)如果同时配置了 RDB 和 AOF ，启动只加载 AOF 文件恢复数据；

(3)如果只配置 RDB，启动将加载 dump 文件恢复数据。

拷贝 AOF 文件到 Redis 的数据目录，启动 redis-server AOF 的数据恢复过程:Redis 虚拟一个客户端，读取AOF文件恢复 Redis 命令和参数，然后执行命令从而恢复数据，这些过程主要在loadAppendOnlyFile() 中实现。

拷贝 RDB 文件到 Redis 的数据目录，启动 redis-server即可，因为RDB文件和重启前保存的是真实数据而不是命令状态和参数。

**新型的混合型持久化**  
RDB和AOF都有各自的缺点：  
(1)RDB是每隔一段时间持久化一次, 故障时就会丢失宕机时刻与上一次持久化之间的数据，无法保证数据完整性

(2)AOF存储的是指令序列, 恢复重放时要花费很长时间并且文件更大

Redis 4.0 提供了更好的混合持久化选项： 创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件， 其中 RDB 数据位于 AOF 文件的开头， 它们储存了服务器开始执行重写操作时的数据库状态，至于那些在重写操作执行之后执行的 Redis 命令， 则会继续以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 数据之后。

**持久化实战**  
在实际使用中需要根据Redis作为主存还是缓存、数据完整性和缺失性的要求、CPU和内存情况等诸多因素来确定适合自己的持久化方案，一般来说稳妥的做法包括：

(1)最安全的做法是RDB与AOF同时使用，即使AOF损坏无法修复，还可以用RDB来恢复数据，当然在持久化时对性能也会有影响。  
(2)Redis当简单缓存，没有缓存也不会造成缓存雪崩只使用RDB即可。  
(3)不推荐单独使用AOF，因为AOF对于数据的恢复载入比RDB慢，所以使用AOF的时候，最好还是有RDB作为备份。  
(4)采用新版本Redis 4.0的持久化新方案。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NjI5Mjc3_size_16_color_FFFFFF_t_70]: /images/20221022/d970416baaa44bb7a6d9f5e1f85a879b.png
[20210401103617756.png]: /images/20221022/f4ae0619d9b34628be253d2bed3705ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NjI5Mjc3_size_16_color_FFFFFF_t_70 1]: /images/20221022/af7b99d25b4a48afbfbda145a75066ab.png