Redis从入门到实战：进阶篇

之前只是在项目简单使用了Redis(只是充当缓存层实现)，对Redis的体系技术没深入了解，最近时间比较充裕，所以再次复习巩固Redis，然后打算写几篇博客记录以及分享所复习的Redis知识。

1. Redis从入门到实战：入门篇
2. Redis从入门到实战：实战篇
3. Redis从入门到实战：进阶篇
4. Redis从入门到实战：完结篇

Redis从入门到实战：进阶篇

1. Redis事务
2. Redis的发布与订阅
3. Redis持久化机制(RDB+AOF)
4. Redis明明是单线程，为什么性能还那么高(每秒读写10W次等特性)
5. Redis流水线技术(管道)

Redis事务

事务这个词我们应该不陌生了，我们在使用MySQL或者Oracle过程中，都会开启事务，直到SQL执行完毕才会关掉事务。
可以说，事务是一种保证数据安全的机制。在关系型数据库中，事务是一组SQL的集合，要么全部执行成功，要么全部执行失败。
而在Redis中，事务是一组命令的集合，这一组命令会按照顺序在隔离的环境中执行，不受其他客户端发送来的命令打断。
下面给出官方解说

1. 事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 事务是一个原子操作，事务中的命令要么全部被执行，要么全部都不执行。
3. 事务可以一次执行多个命令。MULTI、EXEC、DISCARD和WATCH是Redis事务相关的命令。
4. 可以把Redis事务看成四种阶段：开启事务，命令入队，执行事务，关闭事务。

开启事务

1. multi命令的执行标志着事务开启。

   127.0.0.1:6379> multi
   OK
   

2. multi命令可以将执行该命令的客户端从非事务状态切换至事务状态。

命令入队

1. 当Redis客户端处于非事务状态时，这个客户端的命令会立即被服务器执行。
2. 当Redis客户端切换到事务状态之后，服务器会根据这个客户端发来的命令做出不同的响应。
   如果客户端发送的命令是MULTI、EXEC、DISCARD和WATCH这四个命令中的一个，那么服务器会立即执行这个命令。
   如果客户端发来的命令不是这四个命令，那么服务器不会立即执行这个命令，而是将这个命令放在一个事务队列中，然后向客户端返回QUEUED，表明这个命令被放入事务队列中了。

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set name xxxq
   QUEUED
   

   

   在这里插入图片描述

事务队列

1. 事务队列是一个以先进先出（FIFO）的方式保存入队的命令，较先入队的命令放在队列的前面，较后入队的命令放在队列的后面。

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set name xxxq
   QUEUED
   127.0.0.1:6379> get name
   QUEUED
   127.0.0.1:6379> set author zwq
   QUEUED
   127.0.0.1:6379> get author
   QUEUED
   

2. 服务器将会为上面所执行的命令创建一个队列，如下图所示：

   
   
   

   在这里插入图片描述

执行事务

1. 当一个处于事务状态的客户端向服务器发送EXEC命令时，服务器会立即执行这个命令，然后执行事务队列中保存的所以命令，最后将执行命令的结果返回给客户端。当返回结果给客户端的时候，这个事务也就被关闭了。

   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set name xxxq
   QUEUED
   127.0.0.1:6379> get name
   QUEUED
   127.0.0.1:6379> set author zwq
   QUEUED
   127.0.0.1:6379> get author
   QUEUED
   127.0.0.1:6379> exec
   1) OK
   2) "xxxq"
   3) OK
   4) "zwq"
   127.0.0.1:6379> get name
   "xxxq"
   

watch命令

1. watch命令是一个乐观锁。
2. 它可以在EXEC命令执行前，监视任意数量的数据库键，并在EXEC命令执行时，检查监视的键是否至少有一个已经被修改过了，如果修改过了，服务器将拒绝执行事务，并向客户端返回代表事务执行失败的空回复。
3. 下面举一个例子，我开启两个Redis客户端，第一个客户端使用Watch命令监听name和author两个Key，随后使用multi命令开启事务，之后修改name的值。

   127.0.0.1:6379> watch name author
   OK
   127.0.0.1:6379> multi
   OK
   127.0.0.1:6379> set name xq
   QUEUED
   

   第二个客户端也执行修改name的值。

   127.0.0.1:6379> set name xxxxxq
   OK
   

   然后在第一个客户端执行EXEC命令，发现此次事务执行失败。因为在执行EXEC命令的时候，Watch命令监听到name已经被修改了，Redis认为此次事务已经不安全了，所以就无效化事务队列中的所有命令。最后，name的值为第二个客户端修改的结果。

   
   
   

   在这里插入图片描述

Redis的发布与订阅

1. Redis的发布订阅主要有三个角色：发布者，订阅者，频道(消息的载体)。
2. 频道是消息的载体，发布者可以往特定频道发送消息，订阅者可以订阅（也可以说是监听）特定频道的消息，一旦频道有了新的消息，就会推送给订阅者。
3. 最经典的应用场景就是微博和公众号，任何粉丝只要关注（订阅）了某一个人的微博或者公众号，该微博或者公众号只有有状态更新，都会将消息推送（发布）到粉丝....
4. 命令：subscribe channel [channel..]：如subscribe “chat”表示订阅了"chat"频道。

5. 这里还是打开两个客户端，第一个客户端(订阅者)订阅chat频道(当执行完上面命令的时候，第一个客户端处于监听状态)，第二个客户端(发布者)往chat频道发送消息，然后第一个客户端就会立即收到消息。

   
   
   

   在这里插入图片描述

Redis持久化机制(RDB+AOF)

为什么要将数据持久化？假如Redis服务器重启了一下，这时Redis之前缓存的数据都会消失，就得去MySQL等数据库查询数据，再备份到Redis中，这样会导致程序效率低下。而将Redis数据持久化之后，在重启Redis服务器的时候，只需要将持久化的数据拉取到内存中即可，这对于Redis每秒读写10次不算什么。Redis支持两种持久化方式：RDB，AOF。

RDB

1. RDB（Redis Database）持久化是把当前进程数据生成快照保存在RDB文件的过程。
2. RDB持久化生成的RDB文件是一个经过压缩的二进制文件。
3. 触发RDB持久化过程分为手动触发和自动触发。

手动触发

SAVE命令和BGSAVE命令都可以实现手动触发。

save命令

1. 在客户端中执行save命令，就会触发Redis的持久化，但同时也是使Redis处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。

   
   
   

   在这里插入图片描述

bgsave命令

---

1. 执行bgsave命令，Redis父进程判断当前是否有正在执行的子进程，如RDB/AOF子进程，如果存在直接返回。
2. 如果没有，父进程执行fork操作创建子进程，fork操作会阻塞父进程。父进程fork操作执行完成后，便不再阻塞父进程，可以继续响应其他命令。
3. 子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。

4. 子进程发送信号给父进程表示完成，父进程更新统计信息。

   
   
   

   在这里插入图片描述

自动触发

1. 自动触发的意思是Redis会判断是否满足持久化的条件，满足则自动执行bgsave命令进行持久化。是否满足则是通过Redis核心配置文件redis.conf来配置的。
2. 接下来介绍有关RDB配置的内容：

   # RDB 保存的条件
   save 900 1
   save 300 10
   save 60 10000
   
   # bgsave 失败之后，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件。
   stop-writes-on-bgsave-error yes
   
   # RDB 文件压缩
   rdbcompression yes
   
   # 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
   rdbchecksum yes
   
   # RDB 文件名
   dbfilename dump.rdb
   
   # RDB 文件目录
   dir ./
   

3. save 参数：它是用来配置触发RDB持久化条件的参数，满足保存条件时将会把数据持久化到硬盘，使用的是bgsave命令。
   save m n：是指在 m 秒内，如果有 n 个键发生改变，则自动触发持久化——bgsave命令。
   save 900 1：表示 900 秒内如果至少有 1 个 key 值变化，则把数据持久化到硬盘。
   save 300 10：表示 300 秒内如果至少有 10 个 key 值变化，则把数据持久化到硬盘。
   save 60 10000：表示 60 秒内如果至少有 10000 个 key 值变化，则把数据持久化到硬盘。
4. rdbcompression 参数
   它的默认值是yes表示开启RDB文件压缩，Redis会采用LZF算法进行压缩。如果不想消耗CPU性能来进行文件压缩的话，可以设置为关闭此功能，这样的缺点是需要更多的磁盘空间来保存文件。
5. rdbchecksum 参数
   它的默认值为yes表示写入文件和读取文件时是否开启RDB文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。

RDB文件的载入

1. 如果Redis开启了AOF持久化功能，就会优先使用AOF文件来还原数据库状态，因为AOF文件的更新频率比RDB文件的更新频率高。
2. 只有在AOF持久化关闭的状态时，服务器才会使用RDB文件来还原数据库状态。
3. 服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

RDB的优缺点

1. 优点：RDB文件时一个紧凑的二进制文件，适用备份、全量复制的场景。加载RDB文件恢复数据远远快于AOF文件。
2. 缺点：不能实时持久化，数据丢失的风险高。每次BGSAVE创建子进程属于重量级操作，频繁执行成本高。

AOF

1. AOF（Append Only File）持久化以独立日志方式记录每次写命令，重启时在重新执行AOF文件中的命令达到恢复数据的目的。
2. AOF的主要作用就是解决了数据持久化的实时性。
3. 被写入AOF文件的所有命令都是以Redis的命令请求协议格式保存的，因为Redis命令请求协议格式是纯文本格式，所以我们可以直接打开一个AOF文件观察里面的内容。
4. 默认情况下AOF功能是关闭的。我们需要修改配置文件：appendonly no改为appendonly yes。

AOF工作流程

1. 命令追加：服务器执行完一个写命令后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区末尾。
2. 文件同步：AOF缓冲区根据对应的策略向硬盘做同步操作。
3. 文件重写：随着AOF越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4. 重启加载：当Redis重启时，可以加载AOF文件进行数据恢复。

文件同步策略

1. appendfsync always：每次写入都要同步AOF文件，从效率上看，是最慢的，从安全性上看，是最安全的。
2. appendfsync everysec：每1秒钟同步一次，该策略为AOF的缺省策略。
3. appendfsync no：从不同步。高效但是数据不会被持久化。

Redis明明是单线程，为什么性能还那么高?

1. 纯内存访问，Redis将所有数据放在内存中，内存响应的速度非常快。
2. 非阻塞I/O，Redis使用epoll作为I/O多路复用技术的实现的，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多事件。
3. 单线程避免了线程切换和竞态产生的消耗。

单线程优缺点

1. 单线程可以简化数据结构和算法的实现。
2. 单线程可以避免竞态产生的消耗，锁和线程切换通常是性能杀手。
3. 对于每个命令的执行时间有要求，如果某个命令执行过长，会造成其他命令阻塞，对于Redis这种高性能的服务来说是致命的。

Redis流水线(管道)

1. 以前我们每向Redis服务器发送一个命令的时候，Redis服务器就会执行该命令，然后返回结果给客户端。每一次请求与响应都会消耗一些时间，由于Redis读写速度很快，所有一旦接收到客户端发来的命令，就会立即执行并返回结果。

2. 如果在网络差的情况下，客户端发送命令给服务器需要一些时间，此时Redis服务器一直等待命令的到来，这个原因不是Redis的问题，而是网络差的问题，如果一次性需要发送上百条命令，都会出现上述原因，那么效率是非常差的，所有Redis提供了一个流水线技术，也叫管道，就是能在一次连接上，执行大量的命令，减少客户端与服务器的来回交互次数，大大提升效率。

   
   
   

   在这里插入图片描述
3. 使用Java Jedis模拟批量插入100W条数据时，不使用与使用流水线技术的差距。

   @Test
   public void pipeline(){
       Jedis jedis = new Jedis("localhost",6379);
       //获取流水线
       Pipeline pipelined = jedis.pipelined();
       //获取开始执行时间
       long startTime = System.currentTimeMillis();
       IntStream.range(0,1000000).forEach(it -> pipelined.set("batch"+it,it+""));
       List