Redis常用指令，jedis与持久化

1.redis常用指令

第一个是key的常用指令，第二个是数据库的常用指令

前面的那些指令都是针对某一个数据类型操作的，现在的都是对所有的操作的

1.key常用指令

key应该设计哪些操作

key是一个字符串，通过key获取redis中保存的数据

对于key自身状态的相关操作，例如：删除，判定存在，获取类型等

对于key有效性控制相关操作，例如：有效期设定，判定是否有效，有效状态的切换等

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

key 基本操作

删除指定key

del key

获取key是否存在

exists key

获取key的类型

type key

排序

sort

改名

rename key newkey
renamenx key newkey

key 扩展操作（时效性控制）

为指定key设置有效期

expire key seconds
pexpire key milliseconds
expireat key timestamp
pexpireat key milliseconds-timestamp

获取key的有效时间

ttl key  # ttl：time to live：存活时间（过期时间）
pttl key

获取key的有效时间

ttl key  # ttl：time to live：存活时间（过期时间）
pttl key

key 扩展操作（查询模式）

查询key

keys pattern

查询模式规则

* 匹配任意数量的任意符号 ? 配合一个任意符号 [] 匹配一个指定符号

keys *  keys    查询所有
it*  keys       查询所有以it开头
*heima          查询所有以heima结尾
keys ??heima    查询所有前面两个字符任意，后面以heima结尾 查询所有以
keys user:?     user:开头，最后一个字符任意
keys u[st]er:1  查询所有以u开头，以er:1结尾，中间包含一个字母，s或t

2.数据库指令

key 的重复问题

假如说十个人同时操作redis，会不会出现key名字命名冲突的问题

一定会，为什么?因为你的key是由程序而定义的。你想写什么写什么，那在使用的过程中大家都在不停的加，早晚有一天会冲突

redis在使用过程中，伴随着操作数据量的增加，会出现大量的数据以及对应的key

我们最好把数据进行一个分类，除了命名规范我们做统一以外，如果还能把它分开，这样是不是冲突的机率就会小一些了

解决方案

redis为每个服务提供有16个数据库，编号从0到15

每个数据库之间的数据相互独立

在对应的数据库中划出一块区域，说他就是几，你就用几那块，同时，其他的这些都可以进行定义，一共是16个，这里边需要注意一点，他们这16个共用redis的内存。没有说谁大谁小，也就是说数字只是代表了一块儿区域，区域具体多大未知。这是数据库的一个分区的一个策略

数据库的基本操作

切换数据库

select index

其他操作

ping

数据移动

move key db

数据总量

dbsize

数据清除

flushdb   # 清除当前库的数据
flushall  # 清除所有库的数据
#flush:冲洗，冲掉

2.jedis

1.jedis概述

对于我们现在的数据来说，它是在我们的redis中，而最终我们是要做程序。那么程序就要和redis进行连接

程序中有数据的时候，我们要把这些数据全部交给redis管理。同时，redis中的数据还能取出来，回到我们的应用程序中

那在这个过程中，在Java与redis之间打交道的这个东西就叫做Jedis

Jedis就是提供了Java与redis的连接服务的，里边有各种各样的API接口，你可以去调用它

Java语言连接redis服务 Jedis（SpringData、Redis 、 Lettuce）

2.操作实现

准备工作

1.导入jar包

下载地址：https://mvnrepository.com/artifact/redis.clients/jedis

2.客户端连接redis

连接redis

Jedis jedis = new Jedis("localhost", 6379);

操作redis

jedis.set("name", "ljb");  jedis.get("name");

关闭redis连接

jedis.close();

代码实现

import redis.clients.jedis.Jedis;import java.util.List;public class JedisTest {public static void main(String[] args) {//1.获取连接对象Jedis jedis = new Jedis("192.168.235.129",6379);//2.执行操作jedis.set("age","39"); // jedis提供的方法与redis命令基本一致String hello = jedis.get("hello");System.out.println(hello);jedis.lpush("list1","a","b","c","d");List<String> list1 = jedis.lrange("list1", 0, -1);for (String s:list1 ) {System.out.println(s);}jedis.sadd("set1","abc","abc","def","poi","cba");Long len = jedis.scard("set1");System.out.println(len);//3.关闭连接jedis.close();}
}

3.Jedis简易工具类开发

前面做的程序还是有点儿小问题，就是我们的Jedis对象的管理是我们自己创建的，真实企业开发中是不可能让你去new一个的，那接下来咱们就要做一个工具类，简单来说，就是做一个创建Jedis的这样的一个工具

JedisPool：Jedis提供的连接池技术

poolConfig:连接池配置对象

host:redis服务地址

port:redis服务端口号

JedisPool的构造器：（源码）

public JedisPool(GenericObjectPoolConfig poolConfig, String host, int port) {this(poolConfig, host, port, 2000, (String)null, 0, (String)null);
}

创建jedis的配置文件：jedis.properties

jedis.host=192.168.235.129 
jedis.port=6379  
jedis.maxTotal=50    #控制一个pool可分配多少个jedis实例
jedis.maxIdle=10     #控制一个pool最多有多少个状态为idle(空闲的)的jedis实例
# 就是说如果没人用jedis，那么这个池子里就只有10个jedis实例
# 如果用的人非常多，但是不会超过50个

创建JedisUtils：使用静态代码块初始化资源

public class JedisUtils {private static int maxTotal;private static int maxIdel;private static String host;private static int port;private static JedisPoolConfig jpc;private static JedisPool jp;static {ResourceBundle bundle = ResourceBundle.getBundle("redis");maxTotal = Integer.parseInt(bundle.getString("redis.maxTotal"));maxIdel = Integer.parseInt(bundle.getString("redis.maxIdel"));host = bundle.getString("redis.host");port = Integer.parseInt(bundle.getString("redis.port"));//Jedis连接池配置jpc = new JedisPoolConfig();jpc.setMaxTotal(maxTotal);jpc.setMaxIdle(maxIdel);jp = new JedisPool(jpc,host,port);}
}

3.持久化

1.持久化概述

自动恢复，其实基于的一个前提就是他提前把你的数据给存起来了。你平常操作的所有信息都是在内存中的，而我们真正的信息是保存在硬盘中的，内存中的信息断电以后就消失了，硬盘中的信息断电以后还可以保留下来

我们将文件由内存中保存到硬盘中的这个过程，我们叫做数据保存，也就叫做持久化

但是把它保存下来不是你的目的，最终你还要把它再读取出来，它加载到内存中这个过程，我们叫做数据恢复

就是我们所说的word为什么断电以后还能够给你保留文件，因为它执行了一个自动备份的过程，也就是通过自动的形式，把你的数据存储起来，那么有了这种形式以后，我们的数据就可以由内存到硬盘上实现保存

什么是持久化

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化

持久化用于防止数据的意外丢失，确保数据安全性

持久化过程保存什么

第一种：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。

第二种：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

2.RDB

1.save指令

手动执行一次保存操作

save

save指令相关配置

设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb

dbfilename filename

设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data

dir path

设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大

rdbcompression yes|no

设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险

rdbchecksum yes|no

2. bgsave指令

当save指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理

此时我们可以使用：bgsave指令，bg其实是background的意思，后台执行的意思

手动启动后台保存操作，但不是立即执行

bgsave

bgsave指令相关配置

后台存储过程中如果出现错误现象，是否停止保存操作，默认yes

stop-writes-on-bgsave-error yes|no

bgsave指令工作原理

当执行bgsave的时候，客户端发出bgsave指令给到redis服务器。

注意，这个时候服务器马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用Linux的fork（分叉）函数创建一个子进程，让这个子进程去执行save相关的操作

此时我们可以想一下，我们主进程一直在处理指令，而子进程在执行后台的保存，它会不会干扰到主进程的执行吗

答案是不会，所以说他才是主流方案。

子进程开始执行之后，它就会创建啊RDB文件把它存起来，操作完以后他会把这个结果返回，也就是说bgsave的过程分成两个过程，

第一个是服务端拿到指令直接告诉客户端开始执行了；

另外一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息

注意：bgsave命令是针对save阻塞问题的优化。redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用

3.save配置自动执行

设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化

save second changes

参数

second：监控时间范围

changes：监控key的变化量

范例：

save 900 1 #900s之内只有有1个key发生改变，就会保存
save 300 10
save 60 10000

RDB三种启动方式对比

方式	save指令	bgsave指令
读写	同步	异步
阻塞客户端指令	是	否
额外内存消耗	否	是
启动新进程	否	是

RDB优点：

RDB是一个紧凑压缩的二进制文件，存储效率较高

RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景

RDB恢复数据的速度要比AOF快很多

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

RDB缺点

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

bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能

Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

3.AOF

为什么要有AOF,这是因为RDB的存储的弊端

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

大数据量下的IO性能较低

基于fork创建子进程，内存产生额外消耗

宕机带来的数据丢失风险

解决思路

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

降低区分数据是否改变的难度，改记录数据为记录操作过程

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

1.AOF概念

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化

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

2.启动AOF相关配置

开启AOF持久化功能，默认no，即不开启状态

appendonly yes|no

AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof

appendfilename filename

AOF持久化文件保存路径，与RDB持久化文件保持一致即可

dir

AOF写数据策略，默认为everysec

appendfsync always|everysec|no

3.AOF执行策略

AOF写数据三种策略(appendfsync)

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

everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据数据准确性较高，性能较高，建议使用，也是默认配置

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

4.AOF重写

场景：AOF写数据遇到的问题，如果连续执行如下指令该如何处理

AOF概述

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积

AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程

简单说就是将对同一个数据的若干个条命令执行结果 转化成 最终结果数据对应的指令进行记录

AOF重写作用

降低磁盘占用量，提高磁盘利用率

提高持久化效率，降低持久化写时间，提高IO性能

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

AOF重写规则

进程内具有时效性的数据，并且数据已超时将不再写入文件

非写入类的无效指令将被忽略，只保留最终数据的写入命令

（如del key1、 hdel key2、srem key3、set key4 111、set key4 222等

如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录）

对同一数据的多条写命令合并为一条命令

如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为：lpush list1 a b c。

为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素

AOF重写方式

手动重写

bgrewriteaof # 这是一个redis指令，不是配置

自动重写

自动重写触发条件设置

auto-aof-rewrite-min-size size   # 达到指定大小就自动重写，size可以指定多少兆：2MB 、 4MB
auto-aof-rewrite-percentage percent  #按照存储占用整体的百分比自动重写，percent指定10%，达到10%就可以自动重写

自动重写触发比对参数（运行指令info Persistence获取具体信息）

aof_current_size  
aof_base_size

5.RDB与AOF区别

持久化方式	RDB	AOF
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高/重量级	低/轻量级
启动优先级	低	高