Redis核心机制（一）

目录

Redis的特性

1.速度快

2.以键值对方式进行存储

3.丰富的功能

4.客户端语言多

5.持久化

6.主从复制

7.高可用和分布式

 Redis使用场景

Redis核心机制——持久化

RDB

bgsave执行流程

​编辑

AOF

AOF重写流程

3.混合持久化（RDB+AOF） 

Redis核心机制——事务

事务介绍（和MySQL对比）

事务操作

---

Redis的特性

1.速度快

Redis读写命令的速度非常快：

Redis的所有数据都是存储到内存中的。

Redis使用单线程，预防了多线程产生的竞争问题。

2.以键值对方式进行存储

Redis是基于<key,value>的形式进行存储数据的，Redis中的值不仅可以是字符串，还支持多种数据结构：字符串（string）、列表（list）、哈希（hash）、集合（set）、有序集合（zset）、位图（Bitmap）、GEO（地理信息位置）。

3.丰富的功能

提供了键过期功能，可以实现缓存

提供了发布订阅功能，可以实现消息队列

支持Lua脚本，可以利用Lua创造出新的Redis命令

提供了简单的事务，支持打包命令

提供了流水线功能，客户端命令批次到达Redis，减少网络的开销

4.客户端语言多

Redis提供了简单的TCP通信协议，很多编程语言可以很方便地接入到Redis，并且由于Redis收到社区和各大公司的认可，支持Redis客户端语言也非常多，几乎涵盖了主流编程语言：C、C++、Java、Python等 

5.持久化

Redis虽然将读写数据都是到内存中，一旦服务器关闭，数据都会丢失，Redis提供了RDB和AOF两种持久化机制，使用这两种机制就可以将内存的数据保存到硬盘中，保证了数据的可持久性。 

6.主从复制

Redis提供了复制功能，实现了多个相同数据的Redis副本，复制是分布式Redis的基础。

7.高可用和分布式

 Redis提供了哨兵模式，保障Redis节点故障发现和故障自动转移。也提供了Redis集群，真正的分布式实现，提供了高可用、读写和容量拓展。

 Redis使用场景

1.缓存（验证码）

Redis提供了过键值过期时间的设置，提供了内存淘汰策略。

2.排行榜系统（积分排名）

Redis提供了列表和有序集合的结构

3.计数器应用（点赞，浏览量）

Redis天然提供了技术功能

Redis核心机制——持久化

RDB

RDB持久化就是将当前进程数据以生成快照保存到硬盘中，触发RDB分为自动触发和手动触发。

手动触发：使用save命令，此时会阻塞当前Redis服务器，直到RDB执行完毕，此时对内存影响较大，基本不采用这种方式去手动进行触发RDB操作。使用bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在创建子进程阶(fork)，时间很短。

自动触发：Redis运行时会自动触发持久化机制。通过配置文件进行触发，通过修改配置文件中的save选项，save m n表示m秒内数据发生n次修改，自动进行RDB持久化。从节点进行全量复制操作时，主节点自动进行RDB持久化，随后将RDB文件内容发送给从节点。执行shoutdown命令关闭Redis时，执行RDB持久化。

bgsave执行流程

Redis执行bgsave命令，父进程判断是否存在其他正在执行的子进程，RDB/AOF子进程，如果存在bgsave命令直接返回。 

父进程执行fork创建子进程，fork过程中父进程会阻塞。

创建子进程完成后bgsave会返回信息通知父进程不在阻塞，继续响应其他命令。

子进程创建RDB文件，根据父进程内存生成的临时快照文件对原有文件进行替换。

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

优缺点：RDB是一个紧凑压缩的二进制文件,代表

AOF

AOF持久化以日志的形式将每次执行的命令记录下来，重启服务器时执行AOF文件的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性。

AOF工作流程：

1.所有写入的命令会追加到aof_buf（缓冲区）中。

2.AOF缓冲区根据对应策略向硬盘做同步操作。

3.随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩目的。

4.当Redis服务器启动时，可以加载AOF文件进行数据恢复。 

Redis使用单线程进行命令的响应，如果每次都将数据直接写入硬盘会使性能下降，此时可以先将数据写入缓冲区中，然后在一同写入硬盘中，有效减少IO次数，提高性能。

随着命令不断写入AOF文件，这个文件会越来越大，AOF文件会进行重写，压缩文件体积。即进程内已超时数据不会写入文件，重复，失败的命令不会写入文件，多条操作合并为一条。 

AOF重写触发时机：手动触发，调用bgrewriteaof命令。自动触发：根据配置文件进行指定，如触发重写时AOF的最小文件大小，AOF占用大小相较于上次重写时增加的比例。

AOF重写流程

1.执行 AOF重写请求

如果当前请求正在执行AOF重写，请求不执行。如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成后执行。

2.父进程执行fork创建子进程。

3.重写

a.主进程fork之后，继续响应其他命令。所有修改操作都会写入AOF缓冲区，然后同步到硬盘

b.子进程只有执行fork之前的所有内存信息，父进程中需要将fork之后这段时间的修改操作写入AOF重写缓冲区中。

4.子进程根据内存快照，将命令合并到新的AOF文件中。

5.子进程重写完成。

a.新文件写入后，子进程发送信号给父进程。

b.父进程把AOF重写缓存区临时保存的命令追加到AOF文件中

c.用新的AOF文件代替老的AOF文件。

3.混合持久化（RDB+AOF） 

结合RDB和AOF文件特点，使用RDB文件+AOF增量文件存放在一起，即RDB持久化时，执行的命令使用AOF进行记录。

Redis核心机制——事务

事务介绍（和MySQL对比）

Redis事务和MySQL的事务概念上类似，都是把一系列操作打包在一起，批量执行。

原子性

Redis不支持回滚操作，只能将操作打包进行批量执行。

一致性

不保证数据一致性，Redis不支持回滚操作，不能保证数据前后一致性。

隔离性

没有隔离级别，Redis是单线程模型，不会并发执行事务。

持久性

不需要持久性，数据保存在内存中，是否开启持久化，是Redis服务器的事情，和事务无关。

Redis事务本质是在服务器上内置了一个“事务队列”，客户端在事务中进行一个操作，会将这个命令发送给服务器，服务器放到“事务队列”中（但是并不会立即执行），收到EXEC命令后，才会真正执行队列中的所有操作。正因如此，Redis的事务相比于MySQL来说，是弱化很多的，，只能保证事务中的操作是“连续的”，不会被别的客户端”加塞“。

事务操作

MULTI：开启事务

EXEC：真正执行事务

DISCARD：放弃当前事务，此时直接清空事务队列，之前的操作都不会真正执行到。

WATCH：在执行事务的时候，如果某个事务中修改的值被别的客户端修改，此时就容易出现数据不一致的情况。watch在客户端上监控一组具体的key。

当开启事务时，如果对watch的key进行修改，就会记录当前key的“版本号”，在真正提交事务的时候，如果发现服务器上的key版本号已经超过了事务开始时的版本号，就会让事务执行失败。(事务中的所有操作都不执行)

UNWATCH：取消对key的监控，相当于watch的逆操作。

文章结束，感谢观看