Redis入门

NoSQL概述

NoSQL = Not Only SQL，非关系型的数据库。

为什么需要NoSQL

  1. 高并发读写
  2. 海量数据的高效率存储和访问
  3. 高可扩展性和高可用性

NoSQL数据库的四大分类

  • 键值（key-value）存储
  • 列存储
  • 文档数据库
  • 图形数据库

四类NoSQL数据库的比较

NoSQL数据库的特点

  • 易扩展
  • 大数据量，高性能
  • 灵活的数据模型
  • 高可用

Redis概述

高性能键值对数据库。

支持的键值数据类型

  • 字符串类型(String)
  • 列表类型(list)
  • 散列类型(hash)
  • 集合类型(Set)
  • 有序集合类型(ZSet)

应用场景

  • 缓存：最主要的应用场景
  • 任务队列
  • 网站访问统计
  • 应用排行榜
  • 数据过期处理
  • 分布式集群架构中的session分离
  • ...

Redis的安装和使用

搭建环境

  • 虚拟机：VMware 10.0.2
  • Linux系统：CentOS-6.5
  • SSH客户端：SecureCRT 7.3, SecureFX 7.3

如何在Linux(Centos环境)下安装、启动和关闭Redis

Jedis入门

Jedis介绍

Jedis的使用

开发工具：IDEA。 新建Maven项目。

在pom.xml文件引入依赖
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
</dependency>

<!--后面用到了@Test注解，所以这里引入junit依赖-->
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.12</version>
    <scope>compile</scope>
</dependency>
测试连接
@Test
public void demo1(){
    //1.设置IP地址和端口
    Jedis jedis = new Jedis("10.3.11.185",6379);
    //2.保存数据
    jedis.set("name","imooca");
    //3.获取数据
    String value = jedis.get("name");
    System.out.println(value);
    //4.释放资源
    jedis.close();
    }
以连接池方式连接
@Test
//以连接池方式连接
public void demo2(){
    //获得连接池的配置对象
    JedisPoolConfig config = new JedisPoolConfig();

    //设置最大连接数
    config.setMaxTotal(30);

    //设置最大的空闲连接数
    config.setMaxIdle((10));

    //获得连接池
    JedisPool jedisPool = new JedisPool(config,"10.3.11.185",6379);

    //获得核心对象
    Jedis jedis = null;
    try {
        //通过连接池获得连接
        jedis = jedisPool.getResource();

        //设置数据
        jedis.set("name","张三");
        //获取数据
        String value = jedis.get("name");
        System.out.println(value);
    }catch (Exception e){
        e.printStackTrace();
    }finally {
        //释放资源
        if(jedis != null){
            jedis.close();
        }
        if(jedisPool != null){
            jedisPool.close();
        }
    }
}


Redis的数据结构及其常用命令

五种数据类型：

  • 字符串（String）
  • 字符串列表（list）
  • 哈希（hash）
  • 字符串集合（set）
  • 有序字符串集合（sorted set/ zset）

Redis是高性能键值对(key-value)数据库.

key定义的注意点：
  1. 不要过长：最好不要超过1024个字节，不然不仅会消耗内存，而且会降低查找的效率
  2. 不要太短：会降低可读性
  3. 最好要有统一的命名规范
在redis目录下键入 # ./bin/redis-cli 开启Redis客户端，进入命令行输入模式。

Redis的数据结构之字符串

  • 二进制安全的，存入和获取的数据相同
  • Value最多可以容纳的数据长度是512M
存储String的常用命令

Redis的数据结构之Hash

  • 可以看成是String key和String value的map容器
  • 每一个Hash可以存储4294967295个键值对
存储hash的常用命令
  • 赋值：hset key field value, hmset key field1 value1 [field2 value2]
  • 取值: hget key field, hmget key field1 [field2], hgetall key
  • 删除：hdel key field1 [field2], del key
  • 增加数字：hincrby key field increment, hincrbyfloat key field increment
  • 自学命令: hlen key, hkeys key


Redis的数据结构之list

  • ArrayList使用数组
  • LinkedList使用双向链表方式
  • 双向链表中增加数据
  • 双向链表中删除数据
存储list的常用命令
  • 两端添加：lpush key value1 [value2], rpush key value1 [value2], lpushx key value, rpushx key value
  • 两端弹出: lpop key, rpop key, lrem key count value
  • 查看列表: lrange key start stop
  • 获取列表中元素个数: llen key
  • 扩展命令:rpoplpush source destination 更多请参考(https://www.runoob.com/redis/redis-lists.html)。





rpoplpush命令的使用场景

例如：list1是生产消费队列，list2常用于备份数据。解决的问题：consumer pop之后，还没处理完就挂了。解决办法：consumer pop之后先放到list2，处理完再从list2删掉。

Redis的数据结构之Set

  • 和List类型不同的是，Set集合中不允许出现重复的元素
  • Set可包含的最大元素数量是4294967295
存储集合Set的常用命令
  • 添加/删除元素：sadd key member1 [member2], spop key, srem key member1 [member2]
  • 获得集合中的元素：scard key, smembers key, srandmember key [count]
  • 集合中的差集运算: sdiff key1 [key2], sdiffstore destination key1 [key2],
  • 集合中的交集运算: sinter key1 [key2], sinterstore destination key1 [key2]
  • 集合中的并集运算: sunion key1 [key2], sunionstore destination key1 [key2]
  • 扩展命令: sismember key member, smove source destination member, sscan key cursor [MATCH pattern] [COUNT count]

更多请参考(https://www.runoob.com/redis/redis-sets.html).





Set的使用场景
  • 跟踪一些唯一性数据：比如说访问某一博客的唯一IP地址，只需要存入Set就可以保证唯一性。
  • 用于维护数据对象之间的关联关系：比如将所有购买所有某一商品的用户id存储到一个Set中，将所有购买另一商品的用户Id存储到另一Set中，要求同时购买了两种商品的用户，只要求两个Set的交集即可。

Redis的数据结构之Sorted-Set

  • Sorted-Set与Set的区别: 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的,但分数(score)却可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。 集合中最大的成员数为4294967295。
  • Sorted-Set中的成员在集合中的位置是有序的
存储Sorted-Set的常用命令
  • 添加元素：zadd key score1 member1 [score2 member2],
  • 删除元素：zrem key member [member...], zremrangebylex key min max, zremrangebyrank key start stop, zremrangebyscore key start stop
  • 获得元素: zcard key, zrevrange key start stop[withscores]
  • 范围查询：zcount key min max,
  • 扩展命令：zscore key member, zrevrank key member, zrank ket member

详细请参考(https://www.runoob.com/redis/redis-sorted-sets.html)。





Sorted-Set的使用场景
  • 如大型在线游戏积分排行榜，分数变化可以用zadd命令更新，用zrange命令获取排行榜

Redis中Keys的通用操作

  • keys * 查询所有Key
  • keys my? 查询以my开头的Key
  • del my1 my2 my3 删除my1 my2 my3
  • exists my1 查看Key是否存在
  • rename key1 key2 重命名key1为key2
  • expire key1 1000 为KEY设置过期时间

更多命令请查看(https://www.runoob.com/redis/redis-keys.html).


Redis的特性

  1. 多数据库：最多支持16个数据库，下标从0-15，默认为0号库。

  2. Redis事务

事务中，所有命令都会串行执行，事务执行期间，redis不会为其它的客户端提供服务，从而保证命令原子化执行。单个Redis命令的执行是原子性的，但Redis没有在事务上增加任何维持原子性的机制，因此Redis事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量执行脚本并非原子化的操作，中间某条指令的失败并不会导致前面已做的指令的回滚，也不会造成后续的指令不做。

Redis事务的命令：

  • discard：回滚事务，放弃执行事务块内的所有命令
  • exec：执行所有事务块内的命令，执行事务（提交事务）
  • multi：标记一个事务块的开始，即开启事务
  • unwatch：取消watch命令对所有key的监视
  • watch key [key ...]：监视一个（或多个）key，如果在事务执行之前这个（或这些）事务被其他命令所改动，那么事务将被打断。

Redis的持久化

持久化使用的方式：

  • RDB持久化：将当前进程中的数据生成快照保存到硬盘中（因此也被称为快照持久化），保存的文件后缀是rdb；当Redis重新启动时，可以读取快照文件恢复数据
  • AOF持久化：RDB是将进程数据写入文件，而AOF持久化（即Append Only File持久化），则是将Redis执行的每次写命令记录到单独的日志文件中（有点像M有SQL的binlog）；当Redis重启时再次执行AOF文件中的命令来恢复数据。
  • 无持久化
  • 同时使用RDB和AOF

与RDB相比，AOF的实时性更好，因此已经成为主流的持久化方案。

RDB持久化方式

1. 触发条件

RDB持久化的触发分为手动触发和自动触发两种。

（1）手动触发

save命令和bgsave命令都可以生成RDB文件。
save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。

而bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。

此时服务器执行日志如下：

bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用；后文中也将只介绍bgsave命令。此外，在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化；下面介绍自动触发RDB持久化的条件。

（2）自动触发

save m n
自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。

例如，查看redis的默认配置文件(Linux下为redis根目录下的redis.conf)，可以看到如下配置信息：

其中save 900 1的含义是：当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsave；save 300 10和save 60 10000同理。当三个save条件满足任意一个时，都会引起bgsave的调用。

save m n的实现原理:

Redis的save m n，是通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。

serverCron是Redis服务器的周期性操作函数，默认每隔100ms执行一次；该函数对服务器的状态进行维护，其中一项工作就是检查 save m n配置的条件是否满足，如果满足就执行bgsave。

dirty计数器是Redis服务器维持的一个状态，记录了上一次执行bgsave/save命令后，服务器状态进行了多少次修改(包括增删改)；而当save/bgsave执行完成后，会将dirty重新置为0。

例如，如果Redis执行了set mykey helloworld，则dirty值会+1；如果执行了sadd myset v1 v2 v3，则dirty值会+3；注意dirty记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。

lastsave时间戳也是Redis服务器维持的一个状态，记录的是上一次成功执行save/bgsave的时间。

save m n的原理如下：每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件满足，就进行bgsave。对于每一个save m n条件，只有下面两条同时满足时才算满足：
（1）当前时间-lastsave > m
（2）dirty >= n

其他自动触发机制:

除了save m n 以外，还有一些其他情况会触发bgsave：

  • 在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行bgsave命令，并将rdb文件发送给从节点
  • 执行shutdown命令时，自动执行rdb持久化，如下图所示：
2. 执行流程

前面介绍了触发bgsave的条件，下面将说明bgsave命令的执行流程，如下图所示：

图片中的5个步骤所进行的操作如下：

  1. Redis父进程首先判断：当前是否在执行save，或bgsave/bgrewriteaof（后面会详细介绍该命令）的子进程，如果在执行则bgsave命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
  2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的，Redis不能执行来自客户端的任何命令
  3. 父进程fork后，bgsave命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令
  4. 子进程创建RDB文件，根据父进程内存快照生成临时快照文件，完成后对原有文件进行原子替换
  5. 子进程发送信号给父进程表示完成，父进程更新统计信息
3. RDB文件

RDB文件是经过压缩的二进制文件，下面介绍关于RDB文件的一些细节。

存储路径

RDB文件的存储路径既可以在启动前配置，也可以通过命令动态设定。

配置：dir配置指定目录，dbfilename指定文件名。默认是Redis根目录下的dump.rdb文件。

动态设定：Redis启动后也可以动态修改RDB存储路径，在磁盘损害或空间不足时非常有用；执行命令为config set dir {newdir}和config set dbfilename {newFileName}。如下所示(Windows环境)：

RDB文件格式
RDB文件格式如下图所示（图片来源：《Redis设计与实现》）：

其中各个字段的含义说明如下：

  1. REDIS：常量，保存着”REDIS”5个字符。
  2. db_version：RDB文件的版本号，注意不是Redis的版本号。
  3. SELECTDB 0 pairs：表示一个完整的数据库(0号数据库)，同理SELECTDB 3 pairs表示完整的3号数据库；只有当数据库中有键值对时，RDB文件中才会有该数据库的信息(上图所示的Redis中只有0号和3号数据库有键值对)；如果Redis中所有的数据库都没有键值对，则这一部分直接省略。其中：SELECTDB是一个常量，代表后面跟着的是数据库号码；0和3是数据库号码；pairs则存储了具体的键值对信息，包括key、value值，及其数据类型、内部编码、过期时间、压缩信息等等。
  4. EOF：常量，标志RDB文件正文内容结束。
  5. check_sum：前面所有内容的校验和；Redis在载入RBD文件时，会计算前面的校验和并与check_sum值比较，判断文件是否损坏。

压缩
Redis默认采用LZF算法对RDB文件进行压缩。虽然压缩耗时，但是可以大大减小RDB文件的体积，因此压缩默认开启；可以通过命令关闭：

需要注意的是，RDB文件的压缩并不是针对整个文件进行的，而是对数据库中的字符串进行的，且只有在字符串达到一定长度(20字节)时才会进行。

4. 启动时加载

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AOF的优先级更高，因此当AOF开启时，Redis会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动载入。服务器载入RDB文件期间处于阻塞状态，直到载入完成为止。

Redis启动日志中可以看到自动载入的执行：

Redis载入RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

5. RDB常用配置总结

下面是RDB常用的配置项，以及默认值；前面介绍过的这里不再详细介绍。

  • save m n：bgsave自动触发的条件；如果没有save m n配置，相当于自动的RDB持久化关闭，不过此时仍可以通过其他方式触发
  • stop-writes-on-bgsave-error yes：当bgsave出现错误时，Redis是否停止执行写命令；设置为yes，则当硬盘出现问题时，可以及时发现，避免数据的大量丢失；设置为no，则Redis无视bgsave的错误继续执行写命令，当对Redis服务器的系统(尤其是硬盘)使用了监控时，该选项考虑设置为no
  • rdbcompression yes：是否开启RDB文件压缩
  • rdbchecksum yes：是否开启RDB文件的校验，在写入文件和读取文件时都起作用；关闭checksum在写入文件和启动文件时大约能带来10%的性能提升，但是数据损坏时无法发现
  • dbfilename dump.rdb：RDB文件名
  • dir ./：RDB文件和AOF文件所在目录

AOF持久化方式

1. 开启AOF

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：appendonly yes

2. 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。
AOF的执行流程包括：

  • 命令追加(append)：将Redis的写命令追加到缓冲区aof_buf；
  • 文件写入(write)和文件同步(sync)：根据不同的同步策略将aof_buf中的内容同步到硬盘；
  • 文件重写(rewrite)：定期重写AOF文件，达到压缩的目的。

（1）命令追加(append)
Redis先将写命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO成为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点；具体格式略。在AOF文件中，除了用于指定数据库的select命令（如select 0 为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

（2）文件写入(write)和文件同步(sync)
Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write函数和fsync函数，说明如下：

为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

AOF缓存区的同步文件策略由参数appendfsync控制，各个值的含义如下：

  • always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。
  • no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。
  • everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

（3）文件重写(rewrite)
随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。

文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作!

关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些实现中，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行。

文件重写之所以能够压缩AOF文件，原因在于：

  • 过期的数据不再写入文件
  • 无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(sadd myset v1, del myset)等等
  • 多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3。不过为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset类型的key，并不一定只使用一条命令；而是以某个常量为界将命令拆分为多条。这个常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定义，不可更改，3.0版本中值是64。

通过上述内容可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

文件重写的触发

文件重写的触发，分为手动触发和自动触发：

手动触发：直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞。

此时服务器执行日志如下：

自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数，以及aof_current_size和aof_base_size状态确定触发时机。

  • auto-aof-rewrite-min-size：执行AOF重写时，文件的最小体积，默认值为64MB。
  • auto-aof-rewrite-percentage：执行AOF重写时，当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。
    其中，参数可以通过config get命令查看：

状态可以通过info persistence查看：

只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。
自动触发bgrewriteaof时，可以看到服务器日志如下：

文件重写的流程

文件重写流程如下图所示(图片来源：http://www.cnblogs.com/yangmingxianshen/p/8373205.html)：

关于文件重写的流程，有两点需要特别注意：(1)重写由父进程fork子进程进行；(2)重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

对照上图，文件重写的流程如下：

  1. Redis父进程首先判断当前是否存在正在执行 bgsave/bgrewriteaof的子进程，如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。前面曾介绍过，这个主要是基于性能方面的考虑。
  2. 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。

3.1. 父进程fork后，bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
3.2. 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区(图中的aof_rewrite_buf)保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewirte_buf两个缓冲区。
4. 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
5.
5.1. 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
5.2. 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
5.3. 使用新的AOF文件替换老文件，完成AOF重写。

3. 启动时加载

前面提到过，当AOF开启时，Redis启动时会优先载入AOF文件来恢复数据；只有当AOF关闭时，才会载入RDB文件恢复数据。

当AOF开启，且AOF文件存在时，Redis启动日志：

当AOF开启，但AOF文件不存在时，即使RDB文件存在也不会加载(更早的一些版本可能会加载，但3.0不会)，Redis启动日志如下：

文件校验

与载入RDB文件类似，Redis载入AOF文件时，会对AOF文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)，且aof-load-truncated参数开启，则日志中会输出警告，Redis忽略掉AOF文件的尾部，启动成功。aof-load-truncated参数默认是开启的：

伪客户端

因为Redis的命令只能在客户端上下文中执行，而载入AOF文件时命令是直接从文件中读取的，并不是由客户端发送；因此Redis服务器在载入AOF文件之前，会创建一个没有网络连接的客户端，之后用它来执行AOF文件中的命令，命令执行的效果与带网络连接的客户端完全一样。

4. AOF常用配置总结

下面是AOF常用的配置项，以及默认值；前面介绍过的这里不再详细介绍。

  • appendonly no：是否开启AOF
  • appendfilename "appendonly.aof"：AOF文件名
  • dir ./：RDB文件和AOF文件所在目录
  • appendfsync everysec：fsync持久化策略
  • no-appendfsync-on-rewrite no：AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡
  • auto-aof-rewrite-percentage 100：文件重写触发条件之一
  • auto-aof-rewrite-min-size 64mb：文件重写触发提交之一
  • aof-load-truncated yes：如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件

RDB和AOF的优缺点比较

  1. RDB持久化
  • 优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。
  • 缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。
  1. AOF持久化
    与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，能带来更高的数据安全性，缺点是文件大、恢复速度慢、对性能影响大。

总结

本文讲述了Redis的安装和使用，Jedis的入门，Redis的数据结构及其命令以及Redis的持久化等内容。还有Redis主从复制、哨兵、集群等Redis进阶内容，学完再更。

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/xiaozhengtongxue/p/13498642.html