Redis知识全景图

两大维度

从系统维度上说，我们需要了解 Redis 的各项关键技术的设计原理。而且，通过对Redis这两个维度的了解，我们可以从中掌握一些优雅的系统设计规范，例如 run-to-complete 模型、epoll 网络模型，这些可以应用到你后续的系统开发实践中

  • 应用维度：主要探索Redis如何应用在各种业务场景中

    • 缓存应用

    • 集群应用

    • 数据结构应用

  • 系统维度：主要探索Redis在系统上做了哪些处理和优化，来使单实例可以达到万级、十万级别的QPS

    • 处理层

    • 内存层

    • 存储层

    • 网络层

三大主线

通过三大让我们更好去学习和使用Redis

  • 高性能主线，包括线程模型、数据结构、持久化、网络框架;

  • 高可靠主线，包括主从复制、哨兵机制;

  • 高可扩展主线，包括数据分片、负载均衡。

内部架构

Redis作为一个键值数据库，我们可以简单的将其分为以下几个模块：

  • 访问框架：网络通信

  • 索引模块：定位kv

  • 操作模块：操作kv

  • 存储模块：持久化

对比

Memcached 和 RocksDB 分别是典型的内存键值数据库和硬盘键值数据库，应用得也非 常广泛。

工具

  • 监控：

    • INFO 命令：Redis 本身提供的 INFO 命令会返回丰富的实例运行监控信息，这个命令是 Redis 监控工 具的基础。

    • Redis-exporter：结合prometheus使用

    • Redis-stat和Redis Live：轻量级监控工具

  • 数据迁移：

    • Redis-shake：先启动 Redis-shake 进程，这个进程模拟了一个 Redis 实例。然后，Redis-shake 进程和数据迁出的源实例进行数据的全量同步。

  • 一致性比对：

    • Redis- full-check：Redis-full-check 的工作原理很简单，就是对源实例和目的实例中的数据进行全量比对， 从而完成数据校验。不过，为了降低数据校验的比对开销，Redis-full-check 采用了多轮 比较的方法。

  • 集群管理：

    • CacheCloud：实现了主从集群、哨 兵集群和 Redis Cluster 的自动部署和管理

附录（了解即可）

Run-to-completion（RTC）模型是一种计算机程序或系统处理任务的方式，它描述了一个事件、请求或者任务从开始执行直到完成整个过程不间断的运行模式。在RTC模型下：

  1. 一次性处理完一个任务：当一个任务或事件被触发时，系统会分配资源来执行这个任务，并确保该任务从头到尾连续地执行，中间不被其他任务打断。

  2. 顺序执行：在单线程环境中，这意味着当前任务必须完全处理完毕后，下一个任务才会开始执行。如果有多个任务排队等待，它们将按照接收的顺序逐个完成。

  3. 无并发：对于每个单独的任务而言，它是原子操作，不会与其他任务同时执行。这种模型尤其适用于简单直接的任务处理，或是对一致性要求较高的场景，因为避免了并发带来的复杂性及同步问题。

  4. 在网络编程和操作系统中：在网络处理器（如路由器或交换机）中，RTC模型意味着每接收到一个数据包就立即创建一个任务上下文来处理这个数据包，直到数据包被完整处理并转发出去为止。

  5. 对比流水线（Pipeline）模型：与之相对的是流水线模型，流水线模型可以将一个大任务分解成多个阶段，各个阶段可能在不同的硬件单元上并行执行，从而提高系统的吞吐量。

epoll 是 Linux 内核提供的一种 I/O 多路复用机制，它是对早期 select 和 poll 模型的改进和增强。在高并发、大量连接的网络服务器场景中，epoll 能够更加高效地处理文件描述符（FD，File Descriptor）事件。

基本原理：

  1. 内核对象：epoll 在内核中维护了一个红黑树数据结构，用于存储感兴趣的文件描述符集合。每个被监控的文件描述符都有一个对应的 epoll 事件结构体（epoll_event），该结构体包含了用户关心的事件类型以及与之关联的数据。

  2. 接口调用：

    • epoll_create()：创建一个 epoll 句柄，返回 epoll 文件描述符。

    • epoll_ctl()：向 epoll 实例添加、修改或删除关注的文件描述符及其事件类型（如读写事件）。

    • epoll_wait()：阻塞等待指定的 epoll 文件描述符上发生的事件，当有文件描述符上的事件发生时，立即返回准备好的文件描述符列表。

  3. 触发模式：

    • 水平触发 (LT)：只要文件描述符处于可读/可写状态，每次调用 epoll_wait 都会报告这个文件描述符。

    • 边沿触发 (ET)：仅当文件描述符状态变化时（从不可读变为可读，或从不可写变为可写）才触发一次事件。这种模式下，程序需要一次性读完所有可读数据或者缓冲区空间耗尽后停止读取，避免丢失事件。

  4. 优势：

    • 效率提升：通过内核内部的数据结构优化，epoll 不再像 select/poll 那样遍历整个文件描述符集来检查是否就绪，而是直接查询已就绪的 FD 列表，大大减少了无谓的系统开销。

    • FD 数量限制：epoll 对待监听的文件描述符数量没有硬性限制（受限于内存），适合大规模并发连接场景。

    • 事件通知机制：epoll 使用就绪队列，只有活跃的 FD 才会被通知到用户空间，降低了上下文切换和 CPU 使用率。

  5. 使用场景：epoll 广泛应用于高性能网络服务器，例如 Web 服务器、数据库服务器、消息队列服务等，特别是在非阻塞I/O模型配合下，可以实现高效且实时的网络通信。