一、key通用指令

  • key特征：key是一个字符串，通过key 获取redis中保存的数据
  • 对于key自身状态的相关操作，例如：删除，判定存在，获取类型等
  • 对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

  • 对于key快速查询操作，例如：按指定策略查询key

    1、key基本操作

  • 删除指定的key

    • del key
  • 获取key 是否存在
    • exists key
  • 获取key的类型
    • type key

2、key拓展操作

  • 为指定的key 设置有效期
    • expire ``key seconds
    • **pexpire**``** **``**key milliseconds** 【毫秒单位】
    • **exprieat**``** **``**key timestamp ** 【使用时间戳的形式】
    • **pexpireat**``** **``**key milliseconds-timestamp**
  • 获取key的有效时间
    • **ttl**``**key** 【秒单位 返回-2 表示已经消失，-1表示存在但是没有时间限制，有时间返回时间限制】
    • **pttl**``**key** 【毫秒单位】
  • 切换key从时效性转换为永久性
    • **persist**``**key**
  • 查询key
    • **keys**``**pattern ** 【keys * 查询所有的key】
    • 查询模式规则：

*号匹配任意数量的任意符号， ？ 匹配一个任意符号， [] 匹配一个指定符号
未命名图片.png

3、key其他操作

  • 为key改名
    • **rename**``**key newkey** 【如果newkey存在 就覆盖】
    • **renamenx**``**key newkey** 【如果newkey 存在 就不改了】
  • 对所有key排序
    • **sort** 【对set 或者 list/zset类型的数据进行排序】

  • 其他key 通用操作

    • **help @generic**

      4、数据库通用指令

  • key重复的问题

    • key是由程序员定义的
    • redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据和对应的key
    • 数据不区分种类，类别混杂在一起，极易出现重复或冲突
  • 解决方案
    • redis为每个服务提供有16个数据库，编号从0-15
    • 每个数据库之间的数据相互独立
  • 切换数据库
    • **select index** 【0 - 15之间】
  • 其他操作
    • **quit **【退出】
    • **ping **【测试连接】
    • **echo message** 【输出message】
  • 数据移动
    • **move key db** 【把key 移动到 对应的库 db写index即可】
  • 数据清除
    • **dbsize**【获取当前数据库有几个key】
    • **flushdb**【清除当前数据库所有key】
    • **flushall**【清除所有数据库的key】

二、Jedis

java连接redis服务

1、依赖

  1. <dependency>
  2.   <groupId>redis.clients</groupId>
  3.   <artifactId>jedis</artifactId>
  4.   <version>2.9.0</version>
  5. </dependency>

2、HelloWorld

  1. import redis.clients.jedis.Jedis;
  3. /**
  4.  * @date: 2021/1/31   12:25
  5.  * @author: 易学习
  6.  */
  7. public class HelloWorld {
  8.     public static void main(String[] args) {
  9.         // 1.连接redis
  10.         Jedis jedis = new Jedis("localhost",6379);
  11.         // 2.操作redis
  12.         jedis.set("name","zhangsan");
  13.         String name = jedis.get("name");
  14.         System.out.println(name);
  15.         // 3.关闭连接
  16.         jedis.close();
  17.     }
  18. }
  • 连接redis
    • **J**``**edis jedis = new Jedis("localhost",6379);**
  • 操作redis
    • **jedis.set("name","zhangsan");**
  • 关闭redis连接
    • **jedis.close();**

3、redis工具类

使用hutool即可

三、高级-持久化- RDB

切换到redis的目录下：
redis-server —port 6380 【启动6380端口】
redis-cli -p 6380 【连接6380端口的redis】
通过配置文件的方式启动
redis-server kconfig/redis.conf 【后面是配置文件的路径】
创建一个配置文件
切换到自己想要的目录下： touch redis-端口号.conf

  1. port 6379
  2. daemonize yes
  3. logfile "6379.log"
  4. dir /usr/local/bin/data

1、Redis持久化

  • 什么是持久化
    • 利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制成为持久化。
  • 为什么需要进行持久化
    • 防止数据的意外丢失，保证数据安全性
  • 持久化过程保存什么
    • 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据 RDB
    • 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。 AOF

未命名图片.png

2、RDB

2.1、save指令

**save **指令，执行保存 【不要用 以后使用 bgsave】
注意：需要是root用户开启的redis-server 服务
Linux查看进程指令
**ps -aux | grep redis**
Linux杀死进程指令
**kill -9 xxxx**

2.2、RDB启动方式 —- save指令相关配置 【配置文件里的】

  • dbfilename dump.rdb
    • 说明：设置本地数据库文件名，默认值为dump.rdb
    • 经验：通常设置为dump-端口名.rdb
  • dir
    • 说明：设置存储rdb文件的路径
    • 经验：通常设置成存储空间比较大的目录中，目录名称为data
  • rdbcompression yes
    • 说明：设置存储值本地数据库是 是否压缩数据 默认为yes 采用LZF压缩
    • 经验：通常默认为开启状态，如果设置为no，可以节省CPU运行时间，但会是存储的文件变大（巨大）

  • rdbchecksum yes

    • 说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行
    • 经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险
      1. port 6379
      2. daemonize yes
      3. logfile "6379.log"
      4. dir /usr/local/bin/data
      5. dbfilename dump-6379.rdb

  • 注意：如果修改了配置文件，需要使用 kill 命令将之前的redis命令杀死，

  • 重新启动redis【配置文件的方式启动】 redis-server config/redis-6379.conf
  • 使用该配置文件启动的时候，数据就会带着回来了

注意：save指令的执行会阻塞当前redis服务器，知道当前RDB过程完成为止，有可能会造成长时间阻塞，**线上环境不建议使用**

2.3、gbsave指令

数据量过大，使用save保存会造成效率上的问题，如何解决？

  • 后台执行
  • 谁：redis操作者（用户） 发起指令；redis服务器控制指令执行
  • 什么时间：即时（发起） 合理的时间（执行）
  • 干什么事情：保存数据

**bgsave**
未命名图片.png
作用：

  • 手动启动后台保存操作，但不是立即执行，而是redis在合理的时间自动执行


bgsave 命令原理**
未命名图片.png

bgsave的配置

  • 和save的四个配置相同，都可以使用

多一个配置：**stop-writes-on-bgsave-error yes**

  • 后台存储过程中如果出现错误现象，是否停止保存操作
  • 经验：通常默认为开启状态

2.4、反复执行保存指令，忘记了怎么办？不知道数据产生了多少变化，何时保存？

解：自动执行
redis服务器发起指令（基于条件）满足条件就保存数据
配置文件里这么写：
**save **``second changes
作用：满足限定时间范围内的key的变化数量达到指定数量及进行持久化
参数：

  • **second**:监控时间范围
  • **changes**：监控key的变化量

位置：
在conf 文件中进行配置
范例：

  • **save 900 1** 【900 秒钟有1 个key变化了 就保存 [频度偏低]】
  • **save 300 10**
  • **save 60 10000**

2.5、save配置原理

未命名图片.png

2.6、RDB三种启动方式对比：

未命名图片.png

2.7、RDB优点

  • RDB是一个紧凑压缩的二进制文件，存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景。
  • RDB恢复数据的速度要比AOF块很多

  • 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。

    2.8、RDB缺点：

  • RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据.

  • bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能。
  • Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象。

四、高级-持久化- AOF

1、RDB存储的弊端

  • 存储数据量较大，效率jioa存储数据量较大，效率较低

基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低

  • 大数据量下的IO性能较低
  • 基于fork创建子进程，内存产生额外消耗

  • 宕机带来的数据丢失风险

    2、解决RDB存储弊端思路

  • 不写全数据，仅记录部分数据

  • 改记录数据为记录过程

  • 对所有操作均进行记录，排除丢失数据的风险

    3、AOF概念

  • AOF（append only file） 持久化：以独立日志的方式记录每次写命令，重启时在重新执行AOF文件中命令达到恢复数据的目的，与RDB相比可以简单描述为 改记录数据为记录数据产生的过程

  • AOF的主要作用是解决恶略数据持久化的实时性，目前已经是Redis持久化的主流方式

4、AOF写数据过程

未命名图片.png

5、AOF写数据的三种策略

**always**（每次）

  • 每次写入操作 都 同步到AOF文件中，数据零误差，性能较低，不建议使用。

**everysec **（每秒）

  • 每秒将缓存区中国的指令同步到AOF文件中，数据准确性较高，性能较高，在系统突然宕机的情况下丢失一秒内的数据 (高并发下 1秒可能有上千个指令)。 建议使用 同时也是默认配置

**no **（系统控制）

  • 由操作系统控制每次同步到AOF文件的周期，整体过程不可控。

6、AOF功能开启

  • 配置
    • **appendonly **``yes|no

  • 作用：

    • 是否开启AOF持久化功能，默认为不开启状态

  • 配置

    • **appendfsync **``always|everysec|no

  • 作用：

    • AOF写数据策略

  • 配置

    • **appendfilename**`` appendonly-6379.aof
  • 作用：
    • 指定aof的文件名

未命名图片.png

7、AOF重写概念和命令

未命名图片.png

7.1、AOF重写：

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结 果转化成最终结果数据对应的指令进行记录。

7.2、AOF重写作用：

  • 降低磁盘占用量，提高磁盘利用率
  • 提高持久化效率，降低持久化写时间，提高IO性能

  • 降低数据恢复用时，提高数据恢复效率

    未命名图片.png

    7.3、AOF重写规则：

  • 进程内已超时的数据不再写入文件

  • 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
    • 如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
  • 对同一数据的多条写命令合并为一条命令
    • 如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
    • 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

8、AOF重写方式

  • 手动重写（执行指令）
    • **bgrewriteaof**
  • 自动重写 (配置文件)
    • **auto-aof-rewrite-min-size**``** size**
    • **auto-aof-rewrite-percentage**``** percentage**

未命名图片.png

9、RDB和AOF区别：

未命名图片.png

五、RDB和AOF选择之惑

  • 对数据非常敏感，建议使用默认的AOF持久化方案
    • AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出 现问题时，最多丢失0-1秒内的数据。
    • 注意：由于AOF文件存储体积较大，且恢复速度较慢
  • 数据呈现阶段有效性，建议使用RDB持久化方案
    • 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段 点数据恢复通常采用RDB方案
    • 注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
  • 综合比对
    • RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
    • 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
    • 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
    • 灾难恢复选用RDB
    • 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量

      1、持久化应用场景

      未命名图片.png