I/O模型

基本IO模型：

基于epoll的单线程模型
O(N)O(N)O(N)复杂度的数据容易阻塞，提高效率大量采用哈希技术

redis为每个客户端保留了一个指令队列，客户端的指令通过队列来排队进行顺序处理，FIFS（first in first server）先到先服务。同样的，redis也为每个客户端关联一个相应队列，redis服务器通过响应队列，把指令的回复结果返回给客户端。

客户端服务：

每个客户端有自己的指令队列，FIFO
么个客户端有自己的相应队列，发送请求回复的

定时任务：

时间堆模型，最先超时的放在堆顶
执行完定时任务，下次超时时间设置为最近的那个的定时时间
epoll的IO阻塞时间是由时间堆最小的过期时间

RESP作为解析协议

该协议解析效果好，实现简单；
换行太多。

持久化

快照全量备份

定义
某个时刻的状态全量备份到磁盘中。

快照备份的方式

fork子进程，读写数据并写入磁盘
子进程是COW（Copy On Write）的，所以不发生写的地方，都会原样复制
如果有写的请求，OS会复制对应的内存页，此时备份的数据会有不一致
重启时，直接加载磁盘数据，速度非常快

关于fork系统调用和COW，可以参考以下几篇文章：

https://www.geeksforgeeks.org/fork-system-call/
https://www.reddit.com/r/compsci/comments/31szui/trying_to_understand_fork_and_copyonwrite_cow/

save # 阻塞的方式全量备份，此时不能提供读写服务
bgsave # 增量备份

AOF增量备份

AOF保留的是redis服务器的顺序指令序列，AOF只记录对内存进行修改的指令序列。如果AOF记录了自redis启动以来所有修改性的指令，那么可以重放这些指令来恢复整个redis的状态。但是这种方式非常慢，而且占用空间多。Redis收到指令后，先进行逻辑和参数校验，没问题后就立即把该指令存储到AOF日志中；即先执行指令，再存盘，这是为了保证速度。

AOF持久化需要借助fsync函数。AOF的指令是先存储到内核的缓冲区中，然后由内核异步刷新到AOF文件中。如果此时出现服务器宕机的情况，则数据丢失。fsync函数会强制把数据刷新到磁盘中，但是磁盘IO比较慢；所以生产环境下一般是定时执行该函数。

bgrewriteaof可以对AOF日志进行瘦身。原理是，开辟子进程遍历内存，转换一系列的redis操作指令，之后把指令序列化到日志文件中。序列化完毕后，将操作期间发生增量的AOF日志追加到新的AOF日志文件中。

定义
追加指令集的方式备份，保留redis对内存修改的指令序列。

操作方式

记录所有改变内存状态的指令
重放指令逐步回复redis的状态
保存了大量的指令集和操作数据，日志文件过多，恢复速度慢
bgrewriteaof对AOF日志瘦身。原理：
- fork子进程遍历内存
- 转换操作指令
- 指令序列化到日志文件中。
- 序列化完毕后，期间发生的操作继续追加新的AOF日志

运维和混合持久化

实际生产环境中，一般采用主从机制，主节点不会进行持久化，而是从节点执行。但是如果出现网络分区等，或者主节点宕机，此时有数据丢失。所以要做好监控工作。

混合持久化原理：

先快照存储
在快照的基础上追加AOF日志。
重启的加载快照，
逐步增量释放AOF内容

管道

管道的本质是，通过减少网络数据包传递次数，进而减少IO时间。

首先要明确读写操作发生耗时的地方：

写操作：进程把数据写入内核的缓冲区，OS异步把缓冲区的数据发送给目标机器。如果缓冲区满，则写操作阻塞，这是耗时的地方。
读操作：进程从内核的缓冲区读取数据，如果缓冲区是空的，则读操作阻塞，这是耗时的地方。

一个指令涉及到读写的过程，所以一般耗时是在读的地方，网络中传输一个指令耗时基本等于读的耗时。因此多个指令压缩到一起，则会减少读的次数，也就是减少数据包的传递次数，减少整体时间。

事务

SQL的事务包含4个特性：

原子性：要么全做，要么全部不做
一致性：数据库从一个状态转换到另一个状态
隔离性：事务执行的时候不能被打断
持久性：事务的操作产生持久的影响

redis的事务仅仅支持隔离性。如果执行事务操作，需要以MULTI开头，EXEC结尾。只有redis接收到EXEC时，才依次执行命令。事务在执行的时候，不能被打断。如果某一条执行失败，只会报错，不影响其它的命令执行。

watch用于修改某个key前关注该key。如果watch一个key之后，在对该key执行某个命令的时候，key的值发生变化，则指令执行失败，这是redis的乐观锁机制。

乐观锁和悲观锁简介：

悲观锁：每次操作变量时，都假设有其他用户会更改，因此操作前一定加锁，redis的分布式锁就是悲观锁。
乐观锁：每次操作前，假设其它用户都不会改变值，操作不会上锁，只是判断下是否被其他用户更改了。

悲观锁数据安全，乐观锁吞吐量高。

发布订阅机制

定义：

客户端向redis服务器发送订阅消息的请求，之后阻塞等待服务器的消息通知；
订阅消息后，客户端不能进行其他操作。
利用了消息多播机制。

模式订阅：客户端订阅符合匹配模式的主题，有数据时，redis服务器会推送对应的数据

缺陷：不保证消息可靠性，redis服务器推送后，不会接收客户端的ack。

小对象压缩和内存回收机制

redis在数据较少的时候，会采用压缩的数据结构节省空间；当数据量上来时，自动转换存储结构。

redis不会立刻回收空闲的内存，这些内存在新的数据到来时，会重新利用，提高速度。

redis使用jemalloc作为默认的内存分配库。

redis笔记3 持久化、管道、事务、发布订阅和内存回收相关推荐

redis的源码编译安装+发布订阅+RDB持久化
redis的源码编译安装+发布订阅+RDB持久化转载于:https://www.cnblogs.com/zwq-/p/10420455.html
pyRedis - 操作指南:增/删/改/查、管道与发布订阅功能
文章目录 1 redis docker 部署与安装 2 py - redis的使用 2.1 redis的连接 2.2 常规属性查看 2.2.2 关于删除 2.3 STRING 字符串的操作 2.4 H ...
Redis 高级特性（2）—— 发布订阅模式
Redis 高级特性 -- 发布订阅 1. 发布-订阅介绍 "发布-订阅"模式包含两种角色,分别为发布者和订阅者.订阅者可以订阅一个或者若干个频道(channel),而发布者可以向 ...
Redis精通系列——Pub/Sub（发布订阅）
本文已收录于专栏 <Redis精通系列> 上千人点赞收藏,全套Redis学习资料,大厂必备技能! 目录 1.简介 2.实例演示 2.1 普通订阅 2.2 模式订阅 3.Pub/Sub为 ...
Redis 笔记（08）— 事务（一次执行多条命令、命令 watch/multi/exec/discard、错误处理）
1. 事务概念 Redis 中的事务 (transaction)是一组命令的集合.事务同命令一样是 Redis 的最小执行单位,一个事务中的命令要么都执行,要么都不执行.事务的原理是先将属于一个事务的 ...
redis进阶之实现消息队列发布/订阅模式使用（七）
Redis发布订阅 Redis 发布订阅(pub/sub)是一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息.微信. 微博.关注系统! Redis 客户端可以订阅任意数量的频道. ...
java基础巩固-宇宙第一AiYWM：为了维持生计，Redis基础Part6(Redis的应用场景、Redis是单线程的速度还快、Redis线程模型：Reactor模式、事件、发布订阅、管道)~整起
PART1-1:为什么Redis是单线程的 Redis单线程是指: Redis的网络IO和键值对读写是由一个线程来完成的.这也是 Redis 对外提供键值存储服务的主要流程.Redis的其他功能,比如 ...
Redis发布订阅机制
1. 什么是Redis Redis是一个开源的内存数据库,它以键值对的形式存储数据.由于数据存储在内存中,因此Redis的速度很快,但是每次重启Redis服务时,其中的数据也会丢失,因此,Redis也 ...
Redis 发布订阅，小功能大用处，真没那么废材！
假设我们有这么一个业务场景,在网站下单支付以后,需要通知库存服务进行发货处理. 上面业务实现不难,我们只要让库存服务提供给相关的给口,下单支付之后只要调用库存服务即可. 后面如果又有新的业务,比如说积 ...

redis笔记3 持久化、管道、事务、发布订阅和内存回收