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的逆操作。
文章结束，感谢观看