Redis笔记 - 03

太过爱你忘了你带给我的痛 2023-06-12 05:26 4阅读 0赞

> **Redis服务器中的数据库**

Redis服务器中也有数据库这么一个概念。如果不指定具体的数量，默认会有16个数据库。 数据库与数据库之间的数据是**隔离**的。

在数据库中所有键值对的存储结构为哈希表，如下所示：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzZFhU_size_16_color_FFFFFF_t_70][]

Redis的数据库就是使用字典(哈希表)来作为底层实现的，对数据库的增删改查都是构建在字典(哈希表)的操作之上的。

**过期策略：**

*  定时删除(对内存友好，对CPU不友好)，到时间点上就把所有过期的键删除了。
 *  惰性删除(对CPU极度友好，对内存极度不友好)，每次从键空间取键的时候，判断一下该键是否过期，如果过期就删除。
 *  定期删除(折中)，每隔一段时间去删除过期键，限制删除的执行时长和频率。

Redis采用的是惰性删除+定期删除两种策略，所以说，在Redis里边如果过期键到了过期的时间了，未必被立马删除！

**内存淘汰机制：**

如果定期删除漏掉了很多过期key，也没及时去查(没走惰性删除)，大量过期key堆积在内存里，导致redis内存块耗尽了，我们可以设置内存最大使用量，当内存使用量超出时，会施行数据淘汰策略。为了提高缓存命中率，需要保证缓存数据都是热点数据。可以将内存最大使用量设置为热点数据占用的内存量，然后启用allkeys-lru淘汰策略，将最近最少使用的数据淘汰。

<table> 
 <thead> 
  <tr> 
   <th style="width:252px;">策略</th> 
   <th style="width:622px;">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="width:252px;">volatile-lru</td> 
   <td style="width:622px;">从已设置过期时间的数据集中挑选最近最少使用的数据</td> 
  </tr> 
  <tr> 
   <td style="width:252px;">volatile-ttl</td> 
   <td style="width:622px;">从已设置过期时间的数据集中挑选将要过期的数据</td> 
  </tr> 
  <tr> 
   <td style="width:252px;">volatile-random</td> 
   <td style="width:622px;">从已设置过期时间的数据集中任意选择数据</td> 
  </tr> 
  <tr> 
   <td style="width:252px;">allkeys-lru</td> 
   <td style="width:622px;">从所有数据中挑选最近最少使用的数据</td> 
  </tr> 
  <tr> 
   <td style="width:252px;">allkeys-random</td> 
   <td style="width:622px;">从所有数据中任意选择数据</td> 
  </tr> 
  <tr> 
   <td style="width:252px;">noeviction</td> 
   <td style="width:622px;">禁止驱逐数据</td> 
  </tr> 
 </tbody> 
</table>

> **Redis持久化**

Redis是基于内存的，如果不想办法将数据保存在硬盘上，一旦Redis重启(退出/故障)，内存的数据将会全部丢失。我们肯定不想Redis里头的数据由于某些故障全部丢失(导致所有请求都走MySQL)，即便发生了故障也希望可以将Redis原有的数据恢复过来，这就是持久化的作用。

Redis提供了两种不同的持久化方法来讲数据存储到硬盘里边：

*  RDB(基于快照)，将某一时刻的所有数据保存到一个RDB文件中。
 *  AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到AOF文件中。

**RDB(快照持久化)**

RDB持久化可以手动执行，也可以根据服务器配置定期执行。RDB持久化所生成的RDB文件是一个经过压缩的二进制文件，Redis可以通过这个文件还原数据库的数据。

![20191101111700560.png][]

生成RDB文件时会阻塞Redis服务器进程，服务器不能接收任何请求，直到RDB文件创建完毕为止。

Redis服务器在启动的时候，如果发现有RDB文件，就会自动载入RDB文件。

除了手动调用`SAVE`或者`BGSAVE`命令生成RDB文件之外，我们可以使用配置的方式来定期执行：在默认的配置下，如果以下的条件被触发，就会执行`BGSAVE`命令。

*  save 900 1              \#在900秒(15分钟)之后，至少有1个key发生变化
 *  save 300 10            \#在300秒(5分钟)之后，至少有10个key发生变化
 *  save 60 10000        \#在60秒(1分钟)之后，至少有10000个key发生变化

总结：通过手动调用`SAVE`或者`BGSAVE`命令或者配置条件触发，将数据库某一时刻的数据快照，生成RDB文件实现持久化。

**AOF(文件追加)**

AOF是通过保存Redis服务器所执行的写命令来记录数据库的数据的。

![20191101111638137.png][]

AOF持久化功能的实现可以分为3个步骤：

*  命令追加：命令写入aof\_buf缓冲区
 *  文件写入：调用flushAppendOnlyFile函数，考虑是否要将aof\_buf缓冲区写入AOF文件中
    
     *  flushAppendOnlyFile函数的行为由服务器配置的**appendfsyn选项**来决定的：
        
         *  appendfsync always       \# 每次有数据修改发生时都会写入AOF文件
         *  appendfsync everysec   \# 每秒钟同步一次，该策略为AOF的默认策略
         *  appendfsync no         \# 从不同步。高效但是数据不会被持久化。
 *  文件同步：考虑是否将内存缓冲区的数据真正写入到硬盘

**AOF重写**

AOF重写由Redis自行触发(参数配置)，也可以用`BGREWRITEAOF`命令手动触发重写操作。要值得说明的是：AOF重写不需要对现有的AOF文件进行任何的读取、分析。AOF重写是通过读取服务器当前数据库的数据来实现的！

**AOF后台重写**

Redis将AOF重写程序放到子进程里执行(`BGREWRITEAOF`命令)，像`BGSAVE`命令一样fork出一个子进程来完成重写AOF的操作，从而不会影响到主进程。

AOF后台重写是不会阻塞主进程接收请求的，新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致！

为了解决数据不一致的问题，Redis服务器设置了一个AOF重写缓冲区，这个缓存区会在服务器创建出子进程之后使用。

**RDB和AOF对过期键的策略**

RDB持久化对过期键的策略：

*  执行`SAVE`或者`BGSAVE`命令创建出的RDB文件，程序会对数据库中的过期键检查，已过期的键不会保存在RDB文件中。
 *  载入RDB文件时，程序同样会对RDB文件中的键进行检查，过期的键会被忽略。

RDB持久化对过期键的策略：

*  如果数据库的键已过期，但还没被惰性/定期删除，AOF文件不会因为这个过期键产生任何影响(也就说会保留)，当过期的键被删除了以后，会追加一条DEL命令来显示记录该键被删除了
 *  重写AOF文件时，程序会对RDB文件中的键进行检查，过期的键会被忽略。

复制模式：主服务器来控制从服务器统一删除过期键(保证主从服务器数据的一致性)

**RDB和AOF选择**

*  DB和AOF并不互斥，它俩可以同时使用。
 *  RDB的优点：载入时恢复数据快、文件体积小。
 *  RDB的缺点：会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。)
 *  AOF的优点：丢失数据少(默认配置只丢失一秒的数据)。
 *  AOF的缺点：恢复数据相对较慢，文件体积大

如果Redis服务器同时开启了RDB和AOF持久化，服务器会优先使用AOF文件来还原数据(因为AOF更新频率比RDB更新频率要高，还原的数据更完善)

可能涉及到RDB和AOF的配置：

redis持久化，两种方式
    1、rdb快照方式
    2、aof日志方式
    
    ----------rdb快照------------
    save 900 1
    save 300 10
    save 60 10000
    
    stop-writes-on-bgsave-error yes
    rdbcompression yes
    rdbchecksum yes
    dbfilename dump.rdb
    dir /var/rdb/
    
    -----------Aof的配置-----------
    appendonly no # 是否打开 aof日志功能
    
    appendfsync always #每一个命令都立即同步到aof，安全速度慢
    appendfsync everysec
    appendfsync no 写入工作交给操作系统，由操作系统判断缓冲区大小，统一写入到aof  同步频率低，速度快
    
    
    no-appendfsync-on-rewrite yes 正在导出rdb快照的时候不要写aof
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb 
    
    
    ./bin/redis-benchmark -n 20000

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2FzZFhU_size_16_color_FFFFFF_t_70]: /images/20230531/464cdfb8853f42409e7a30a7521092df.png
[20191101111700560.png]: /images/20230531/3b0da4ca8e41436d9eefa94d4a8eb77d.png
[20191101111638137.png]: /images/20230531/ece8db26b47c4057a4602c0710cd03c4.png