LCN29的博客

在 Redis 中, 为了支持高可用, 官方提供了 3 种方式但是主从复制和哨兵模式都有一个问题: 无法水平扩缩容, 而这个问题在集群模式中得到了解决。假设有 3 个 Redis 节点, 所有的数据均匀的分散在 3 个节点中。如果现在需要往里面加入一个新的节点或移出一个已有的节点, 那么就需要对已有的数据做迁移。这个迁移可以说是涉及到所有数据, 这是一个大成本的操作。Redis 为了避免全数据量的迁移, 在集群中引入了一个槽的概念。

Redis Cluster 是 Redis 3.0 提供的一种分布式解决方案, 允许数据在多个节点之间分散存储, 从而实现高可用性和可扩展性。

因为主从复制的过程很复杂, 同时核心逻辑主要集中在这个文件中, 避免篇幅过大, 所以将主从复制中涉及这个文件的代码集中到了另一篇文章。在当前文章主要分析主从复制的大体代码逻辑, 如果需要了解整体的过程, 可以配合这篇文章。

【代码】【Redis】主从复制 - relication 源码分析。

对于 Redis 从节点, 可能因为版本问题, 存在着复制能力不一致的情况, 所以在主从复制开始的阶段, 从节点需要将自身支持的复制能力发送给主节点,(这个缓存区是一个环形的数组, 从头写到尾, 写满了, 重新回到头, 继续写, 新的数据覆盖掉旧的, 同时所有的从节点共用一个缓冲区)。在运行中, 主节点处理完了命令, 会遍历自身维护的所有的从节点, 将自身执行的命令发送给所有状态符合的从节点, 保证数据的一致。主从建立了连接, 主节点会将自身所有的数据生成为一个 RDB 的文件, 然后以。

Reids 主从复制:将一台 Redis 服务器的数据, 复制到其他的 Redis 服务器。前者称为主节点 (master), 后者称为从节点 (slave)。数据的复制是单向的, 只能由主节点到从节点, 同时主节点以写为主 (可写也可以读), 从节点只能读不可写入。

存储在 Redis 中的基本都是键值对, 而这种键值对存储, 同时可以通过 key 快速查询到对应的 value, 最合适的实现就是 HashTable 了。而实现 HashTable 的底层结构，基本就是一个数组或者链表, 同时为了解决 hash 冲突, 数组或链表的每个节点定义为一个链表。Redis 中对 HashTable 的实现也是如此, 大体如下Redis 中实现的 HastTable 叫做 dictht (Dictionary Hash Table)// 存放节点的数组。

在上篇, 我们已经从使用 / 机制 / AOF 过程中涉及的辅助功能等方面简单了解了 Redis AOF。这篇将从源码的形式, 进行深入的了解。

因为 Redis AOF 的实现有些绕, 就分成 2 篇进行分析, 本篇主要是介绍一下 AOF 的一些特性和依赖的其他函数的逻辑,为下一篇 (Redis AOF 源码) 源码分析做一些铺垫。AOF 全称: Append Only File, 是 Redis 提供了一种数据保存模式, Redis 默认不开启。AOF 采用日志的形式来记录每个写操作, 并追加到文件。开启后, 执行更改 Redis 数据的命令时, 就会把命令写入到 AOF 文件中。

备注: 下面二进制之间每 8 位就手动空了一个空格, 只是为了方便理解, 真正写入文件时, 中间是不会有空格的在实际中, Reids 会将数据以二进制的形式写入到文件中, 格式可能如下在开始介绍 Redis 自定义的整数规则前, 先看一个 Redis将数据写入文件的伪代码// 1. 数据的长度在 11 个字节以内 (int 最大值, 21 亿, 10 位数)// 尝试转为 int 写入return;// 2. 开启了 LZF 压缩算法, 同时数据长度大于 20 个字节return;

我们知道 Redis 是一个基于内存的高性能键值数据库, 它支持多种数据结构, 提供了丰富的命令, 可以用来实现缓存、消息队列、分布式锁等功能。而在享受 Redis 带来的种种好处时, 是否曾好奇过 Redis 是如何处理我们发往它的命令的呢？本文将以的形式简单分析一下 Redis 命令处理的过程, 探讨其背后的机制。

现在有多路复用 AeApiState 了, 但是不同的多路复用的 Api 不同, 同样的行为可以有不同的实现, 还是没解决多种实现的问题, 统一的 Api, 底层的屏蔽呢?而 IO 多路复用, 则将监听的操作交由系统进行处理, 自己在处理事务的过程中, 不定时的过来询问有自己关心的事件吗, 有就执行相应的事务, 否则继续处理别的业务。上面都是底层的封装实现, 而到了开发层面, 在使用时, 就很简单了, 完全屏蔽了多路复用的存在, 基于统一的 Api 就能操作自己想要的效果。

官方的介绍ziplist 是一个经过特殊编码的内存高效的双向链表。它同时存储字符串和整数值, 其中整数被编码为实际整数, 而不是一系列字符。它允许在 O(1) 时间内对列表的两边进行 push 和 pop 操作。但是, 因为每个操作都需要重新分配 ziplist 所使用的内存, 所以实际的复杂性与 ziplist 所使用的内存数量有关。ziplist 是一个双向链表。但是它不存储指向上一个链表节点和指向下一个链表节点的指针, 而是存储上一个节点长度和当前节点长度。

可以看到跳表本身的定义很简单header 跳表的头节点tail 跳表的尾节点length 跳表中第一层 (数据最完整的) 的节点长度level 跳表中节点中的最高层数// 跳表的头节点 和 跳表的尾节点// 跳表的节点长度, 只算第一层的节点// 跳表的节点中的最高层数int level;节点的定义也很简单ele 节点存储的数据score 节点的分值backward 节点的前置节点, 主要用于从表尾向表头遍历时使用levels 跳表的特点, 层节点。

在Redis 5.x 版本int (OBJ_ENCODING_INT): 存储 8 个字节的长整型 (long, 2^64 - 1)embstr (OBJ_ENCODING_EMBSTR): 存储小于 44 个字节的字符串raw (OBJ_ENCODING_RAW): 存储大于 44 个字节的字符串 (3.2 版本之前是 39 字节)向 Redis 存入一个 String 类型的值时, Redis 可以根据存储的内容和长度, 自动的在上面 3 种编码中选择其中一个, 用来组织存储的数据。

本文主要是对介绍 Redis 数据类型会涉及到的几个概念做一个简单说明, 方便后面的学习。对了后面的 Redis 的总结, 都是基于版本的进行分析的。