Redis底层原理--04. Redis 功能的实现

发表于 2020-12-08 分类于 Redis

功能的实现

1. 事务

1.1 事务的命令

事务的命令包括 MULTI 、 DISCARD 、 EXEC 和 WATCH

1.2 事务的使用

MULTI
SET key001 1
GET key001 
EXEC

redis 功能实现

事务队列是一个数组，每个数组项是都包含三个属性：

要执行的命令（cmd）。
命令的参数（argv）。
参数的个数（argc）。

redis 功能实现

1.3 带 WATCH 的事务

WATCH 命令用于在事务开始之前监视任意数量的键：当调用 EXEC 命令执行事务时，如果任意一个被监视的键已经被其他客户端修改了，那么整个事务不再执行，直接返回失败.

客户端 1:

## 执行失败的命令
redis> WATCH name
OK
redis> MULTI
OK
redis> SET name peter
QUEUED
redis> EXEC
(nil)

客户端 2:

## 执行失败的命令
redis> WATCH name
OK
redis> MULTI
OK
redis> SET name peter
QUEUED
redis> EXEC
(nil)

时间	客户端A	客户端B
T1	WATCH name
T2	MULTI
T3	SET name peter
T4		SET name john
T5	EXEC

1.4 Watch 命令的实现

监控 Key 的实现：

redis 功能实现

获得 Key 监视的客户端
如果 Key 有修改， Redis 会修改客户端的 REDIS_DIRTY_CAS 选项

redis 功能实现

在上图中，如果某个客户端对 key1 进行了修改（比如执行 DEL key1 ），那么所有监视 key1 的客户端，包
括 client2 、 client5 和 client1 的 REDIS_DIRTY_CAS 选项都会被打开，当客户端 client2
、 client5 和 client1 执行 EXEC 的时候，它们的事务都会以失败告终。

1.5 事务的 ACID 的性质

A 原子性 C 一致性 I 隔离性 D 持久性

原子性

单个 Redis 的习性是原子性的，Redis 没有对事务做任何维持原子性的操作。如果 Redis 事务在执行过程中， Redis 被停止，Redis不会对重试和回滚。

一致性

一致性的问题可以分为三个步骤考虑：入队错误、执行错误、 Redis 进程被终结。

入队列错误

在命令入队的过程中，如果客户端向服务器发送了错误的命令，比如命令的参数数量不对，等等，那么服务器将向客户端返回一个出错信息，并且将客户端的事务状态设为REDIS_DIRTY_EXEC 。当客户端执行 EXEC 命令时， Redis 会拒绝执行状态为 REDIS_DIRTY_EXEC 的事务，并返回失败信息。

执行错误

如果命令在事务执行的过程中发生错误，比如说，对一个不同类型的 key 执行了错误的操作，那么 Redis 只会将错误包含在事务的结果中，这不会引起事务中断或整个失败，不会影响已执行事务命令的结果，也不会影响后面要执行的事务命令，所以它对事务的一致性也没有影响。

Redis 进程被终结

内存模式：如果 Redis 没有采取任何持久化机制，那么重启之后的数据库总是空白的，所
以数据总是一致的
RDB 模式：在执行事务时， Redis 不会中断事务去执行保存 RDB 的工作，只有在事务执行之后，保存 RDB 的工作才有可能开始。所以当 RDB 模式下的 Redis 服务器进程在事务中途被杀死时，事务内执行的命令，不管成功了多少，都不会被保存到 RDB 文件里。
恢复数据库需要使用现有的 RDB 文件，而这个 RDB 文件的数据保存的是最近一次的数据库快照（snapshot），所以它的数据可能不是最新的，但只要 RDB 文件本身没有因为其他问题而出错，那么还原后的数据库就是一致的。
AOF 模式：因为保存 AOF 文件的工作在后台线程进行，所以即使是在事务执行的中途，保存 AOF 文件的工作也可以继续进行，因此，根据事务语句是否被写入并保存到 AOF文件，有以下两种情况发生：
- 1 如果事务语句未写入到 AOF 文件，或 AOF 未被 SYNC 调用保存到磁盘，那么当进被杀死之后， Redis 可以根据最近一次成功保存到磁盘的 AOF 文件来还原数据库，只要 AOF 文件本身没有因为其他问题而出错，那么还原后的数据库总是一致的，但其中的数据不一定是最新的。
- 2 如果事务的部分语句被写入到 AOF 文件，并且 AOF 文件被成功保存，那么不完整的事务执行信息就会遗留在 AOF 文件里，当重启 Redis 时，程序会检测到 AOF 文件并不完整， Redis 会退出，并报告错误。需要使用 redis-check-aof 工具将部分成功的事务命令移除之后，才能再次启动服务器。还原之后的数据总是一致的，而且数据也是最新的（直到事务执行之前为止）

隔离性

Redis 的一个实例是单进程的程序，并且它保证在执行事务是，不会对事务中断，所以 Redis 的事务总是带有隔离性的。

持久性

因为事务不过是用队列包裹起了一组 Redis 命令，并没有提供任何额外的持久性功能，所以事务的持久性由 Redis 所使用的持久化模式决定

在单纯的内存模式下，事务肯定是不持久的。
在 RDB 模式下，服务器可能在事务执行之后、 RDB 文件更新之前的这段时间失败，所以 RDB 模式下的 Redis 事务也是不持久的。
在 AOF 的 “总是 SYNC ” 模式下，事务的每条命令在执行成功之后，都会立即调用 fsync 或 fdatasync 将事务数据写入到 AOF 文件。但是，这种保存是由后台线程进行的，主线程不会阻塞直到保存成功，所以从命令执行成功到数据保存到硬盘之间，还是有一段非常小的间隔，所以这种模式下的事务也是不持久的。

其他 AOF 模式也和“总是 SYNC ”模式类似，所以它们都是不持久的

2. 订阅与发布

2.1 频道的订阅与信息发送

订阅的模型：

redis 功能实现

频道支持模糊的匹配：

redis 功能实现

当有信息发送到 tweet.shop.kindle 频道时，信息除了发送给 clientX 和 clientY 之外，还会发送给订阅 tweet.shop.* 模式的 client123 和 client256

2.2 订阅模式数据结构

struct redisServer {
// ...
	list *pubsub_patterns;
// ...
};

typedef struct pubsubPattern {
  redisClient *client;
  robj *pattern;
} pubsubPattern;

client 属性保存着订阅模式的客户端，而 pattern 属性则保存着被订阅的模式。每当调用 PSUBSCRIBE 命令订阅一个模式时，程序就创建一个包含客户端信息和被订阅模式的 pubsubPattern 结构，并将该结构添加到 redisServer.pubsub_patterns 链表中

redis 功能实现

3. 慢日志

3.1 慢日志数据结构

typedef struct slowlogEntry {
// 命令参数
robj **argv;
// 命令参数数量
int argc;
// 唯一标识符
long long id; /* Unique entry identifier. */
// 执行命令消耗的时间，以纳秒（1 / 1,000,000,000 秒）为单位
long long duration; /* Time spent by the query, in nanoseconds. */
// 命令执行时的时间
time_t time; /* Unix time at which the query was executed. */
} slowlogEntry;

// 记录服务器状态的 redis.h/redisServer 结构里保存了几个和慢查询有关的属性：
struct redisServer {
// ... other fields
// 保存慢查询日志的链表
list *slowlog; /* SLOWLOG list of commands */
// 慢查询日志的当前 id 值
long long slowlog_entry_id; /* SLOWLOG current entry ID */
// 慢查询时间限制
long long slowlog_log_slower_than; /* SLOWLOG time limit (to get logged) */
// 慢查询日志的最大条目数量
unsigned long slowlog_max_len; /* SLOWLOG max number of items logged */
// ... other fields
};

redis 功能实现