Redis底层原理--04. Redis 功能的实现
功能的实现
1. 事务
1.1 事务的命令
事务的命令包括 MULTI 、 DISCARD 、 EXEC 和 WATCH
1.2 事务的使用
MULTI
SET key001 1
GET key001
EXEC
事务队列是一个数组，每个数组项是都包含三个属性：
- 要执行的命令（cmd）。
- 命令的参数（argv）。
- 参数的个数（argc）。
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 的实现：
- 获得 Key 监视的客户端
- 如果 Key 有修改， Redis 会修改客户端的
REDIS_DIRTY_CAS选项
在上图中，如果某个客户端对 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 频道的订阅与信息发送
订阅的模型：
频道支持模糊的匹配：
当有信息发送到 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 链表中
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
};