文章首页 Web开发 Windows开发 编程语言 数据库技术 移动平台 系统服务 微信 设计 布布扣 其他

Redis入门

时间：2020-08-14 20:36:00   收藏：0   阅读：67

NoSQL概述

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

为什么需要NoSQL

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

NoSQL数据库的四大分类

四类NoSQL数据库的比较

技术分享图片

NoSQL数据库的特点

Redis概述

高性能键值对数据库。

支持的键值数据类型

应用场景

Redis的安装和使用

搭建环境

如何在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的数据结构及其常用命令

五种数据类型：

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

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

Redis的数据结构之字符串

存储String的常用命令

Redis的数据结构之Hash

存储hash的常用命令

Redis的数据结构之list

存储list的常用命令
rpoplpush命令的使用场景

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

技术分享图片

Redis的数据结构之Set

存储集合Set的常用命令

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

技术分享图片
技术分享图片
技术分享图片
技术分享图片
技术分享图片

Set的使用场景

Redis的数据结构之Sorted-Set

存储Sorted-Set的常用命令

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

技术分享图片
技术分享图片
技术分享图片
技术分享图片
技术分享图片

Sorted-Set的使用场景

Redis中Keys的通用操作

更多命令请查看(https://www.runoob.com/redis/redis-keys.html).
技术分享图片
技术分享图片
技术分享图片

Redis的特性

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

  2. Redis事务

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

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

Redis事务的命令：

技术分享图片

Redis的持久化

持久化使用的方式：

与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：

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常用的配置项，以及默认值；前面介绍过的这里不再详细介绍。

AOF持久化方式

1. 开启AOF

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

2. 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。
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控制，各个值的含义如下：

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

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

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

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

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

文件重写的触发

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

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

此时服务器执行日志如下：
技术分享图片

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

状态可以通过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常用的配置项，以及默认值；前面介绍过的这里不再详细介绍。

RDB和AOF的优缺点比较

  1. RDB持久化
  1. AOF持久化
    与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，能带来更高的数据安全性，缺点是文件大、恢复速度慢、对性能影响大。

总结

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

原文：https://www.cnblogs.com/xiaozhengtongxue/p/13498642.html

评论（0）
© 2014 bubuko.com 版权所有 - 联系我们:wmxa8@hotmail.com
打开技术之扣，分享程序人生！