一、Jedis的使用

1.修改/usr/local/redis-5.0.4/bin目录下的redis.conf配置文件，然后启动redis服务端

将绑定127.0.0.1注释掉，然后把保护模式关掉

2.创建Maven工程，导入依赖

<dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>3.1.0</version>
</dependency>

3.编写测试类

package com.jedis;import com.alibaba.fastjson.JSON;
import com.pojo.User;
import org.junit.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;public class TestJedis {@Testpublic void test1(){//获得连接对象Jedis jedis = new Jedis("192.168.222.130", 6379);//获得之前redis中存储的数据jedis.set("name","zhangsan");String name = jedis.get("name");System.out.println(name);}@Testpublic void test2(){JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();jedisPoolConfig.setMaxIdle(5000);//最大空闲时间jedisPoolConfig.setMaxTotal(100);//最大连接数JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.222.130", 6379);Jedis jedisPoolResource = jedisPool.getResource();User user = new User(1001,"lisi","123");//将对象转换成json存储jedisPoolResource.set("user", JSON.toJSONString(user));String db_user = jedisPoolResource.get("user");System.out.println(db_user);}
}

二、Redis中的事务

Redis中的事务和MySQL中的事务有本质的区别，Redis中的事务是一个单独的隔离操作，事务中所有的命令都会序列化，按照顺序执行，事务在执行的过程中，不会被其他客户端发来的命令所打断，因为Redis服务端是个单线程的架构，不同的Client虽然看似可以同时保持连接，但发出去的命令是序列化执行的，这在通常的数据库理论下是最高级别的隔离。

Redis中的事务的作用就是串联多个命令，防止别的命令插队。

常用命令：multi、exec、discard、watch、unwacth

当输入multi命令时，之后输入的命令都会被放在队列中，但不会执行，直到输入exec后，Redis会将队列中的命令依次执行，discard用来撤销Exec之前被暂存的命令，并不是回滚。

watch/unwacth

在执行multi之前，先执行watch key1 [key2…] ，watch提供的乐观锁功能（初始时一个版本号，exec之后会更新当前版本号），在你exec的那一刻，如果被watch的键发生过改动，则multi到exec之间的指令全部不执行。

watch表示监控，相当于加锁，但在执行完exec时就会解锁。
unwacth取消所有锁。

Redis中的事务的特性总结

1.单独的隔离操作
事务中的所有命令都会序列化，然后按顺序执行，在执行过程中，不会被其他客户端发送的命令打断。

2.没有隔离级别的概念
队列中的命令没有被提交之前都不会执行。

3.不能保证原子性
Redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，不会回滚。

三、Redis中的持久化

Redis有两种持久化方式：RDB和AOF。

1. RDB（Redis DataBase）

将内存中的数据以快照的方式写入磁盘中，在redis.conf文件中，我们可以找到如下配置：

save 900 1
save 300 10
save 60 10000
配置含义：
900秒内，如果超过1个key被修改，则发起快照保存
300秒内，如果超过10个key被修改，则发起快照保存
60秒内，如果1万个key被修改，则发起快照保存

RDB方式存储的数据会在dump.rdb文件中（在哪个目录启动redis服务端，该文件就会在对应目录下生成），该文件不能查看，如需备份，对Redis操作完成之后，只需拷贝该文件即可（Redis服务端启动时会自动加载该文件）

2. AOF（Append Of File）

AOF默认是不开启的，需要手动开启，同样是在redis.conf文件中开启，如下：

配置文件中的appendonly修改为yes，开启AOF持久化。开启后，启动redis服务端，发现多了一个appendonly.aof文件。
之后任何的操作都会保存在appendonly.aof文件中，可以进行查看，Redis启动时会将appendonly.aof文件中的内容执行一遍。

如果AOF和RDB同时开启，系统会默认读取AOF的数据。

3. 两者的区别

3.1 RDB优点与缺点

优点

如果要进行大规模数据的恢复，RDB方式要比AOF方式恢复速度要快。
RDB是一个非常紧凑(compact)的文件,它保存了某个时间点的数据集，非常适合用作备份，同时也非常适合用作灾难性恢复，它只有一个文件，内容紧凑，通过备份原文件到本机外的其他主机上，一旦本机发生宕机，就能将备份文件复制到redis安装目录下，通过启用服务就能完成数据的恢复。

缺点

RDB这种持久化方式不太适应对数据完整性要求严格的情况，因为，尽管我们可以用过修改快照实现持久化的频率，但是要持久化的数据是一段时间内的整个数据集的状态，如果在还没有触发快照时，本机就宕机了，那么对数据库所做的写操作就随之而消失了并没有持久化本地dump.rdb文件中。

3.2 AOF优点与缺点

优点

AOF有着多种持久化策略：
appendfsync always:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

appendfsync everysec: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

appendfsync no:不同步。

AOF文件是一个只进行追加操作的日志文件，对文件写入不需要进行seek，即使在追加的过程中，写入了不完整的命令（例如：磁盘已满），可以使用redis-check-aof工具可以修复这种问题

Redis可以在AOF文件变得过大时，会自动地在后台对AOF进行重写：重写后的新的AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建AOF文件的过程中，会继续将命令追加到现有的AOF文件中，即使在重写的过程中发生宕机，现有的AOF文件也不会丢失。一旦新AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并对新的AOF文件进行追加操作。

缺点

对于相同的数据集来说，AOF文件要比RDB文件大。
根据所使用的持久化策略来说，AOF的速度要慢于RDB。一般情况下，每秒同步策略效果较好。不使用同步策略的情况下，AOF与RDB速度一样快。

四、Redis中的消息的订阅与发布

subscribe channel 订阅频道 例如：subscribe cctv5
subscribe channel* 批量订阅频道 例如：subscribe cctv* 表示订阅以cctv开头的频道
publish channel content 在指定频道中发布内容 例如：publish cctv5 basketball

同时打开两个客户端，一个订阅频道，一个在频道中发布内容，订阅频道的客户端会接收到消息。

五、使用Redis图形化程序界面

Redis中默认有16个库，可以在不同的库中存储数据，默认使用0号库存储数据，使用select 0-15可以选择不同的库。

安装之后，输入IP地址登录即可看到如下界面：（连接前需要注释掉bind 127.0.0.1）