非关系型数据库，存储键 key 与5种不同类型的值 value 之间的映射，可以将存储在内存的键值对持久化到硬盘，可以使用复制特性来扩展读性能，还可以使用客户端分片扩展写性能。

注：分片是一种将数据划分为多个部分的方法，对数据的划分可以基于键包含的ID、基于键的散列值，或者基于以上两种的某种组合。通过对数据进行分片，用户可以将数据存储到多台机器里面，也可以从多台机器里面获取数据，这种方法在解决某些问题时可以获得线性级别的性能提升

Redis是C语言编写的程序，服务器中含有内核（kernel），多个客户端并发访问Redis。当多个并发客户端在通信时，可能有的客户端发了数据，有的客户端没有发数据，如何达到最快速的知道那个Redis有数据，减少非必要的操纵，底层实现用 epoll，如果内核没有 epoll 会降为 select 或 poll ，这些东西都归属于多路复用器。
通过多路复用器来获得IO事件，有了事件之后调代码，程序自身读写IO叫做同步模型。读取的数据放到内存中进行计算，在IO读取的时候即使通过事件已经知道哪些可读，但Redis是单线程所以底层需要遍历，读取是串行的，计算也是串行的。

1. 对比

VS Memchache
image.jpeg
Memcached 服务器采用 master-woker 模式进行工作，服务端采用 socket 与客户端通讯。主线程、工作线程采用 pipe 管道进行通讯。主线程采用 libevent 监听 listen 、 accept 的读事件，事件响应后将连接信息的数据结构封装起来，根据算法选择合适的工作线程，将连接任务携带连接信息分发出去，相应的线程利用连接描述符建立与客户端的socket连接并进行后续的存取数据操作。
Redis6.0 与 Memcached 多线程模型对比：

  • 相同点：都采用了 master线程-worker 线程的模型。
  • 不同点：Memcached执行主逻辑也是在worker线程里，实现了真正的线程隔离，符合我们对线程隔离的常规理解。而Redis把处理逻辑交还给master线程，虽然一定程度上增加了模型复杂度，但也解决了线程并发安全等问题。

VS MongoDB

memcached只能APPEND命令将数据添加到已有字符串的末尾，将该字符串当做列表使用。通过黑名单（blacklist）隐藏列表里的元素，避免对元素执行读取、更新、写入。

类型 数据存储选项 查询类型 附加功能
Redis 内存存储非关系型数据库 字符串 列表 集合 散列 有序集合
1. 不同数据类型专属命令
1. 批量操作(bulk operation)
1. 不完全(partial)事务支持
1. 发布 / 订阅
1. 主从复制(master/slave replication)
1. 持久化
1. 脚本(存储过程，store procedure)
MongoDB 硬盘存储非关系文档处理
1. 数据库可包含多个表
1. 数据表可包含多个无 schema schema-less 的BSON文档
1. 增删改查
1. 条件查询
1. 支持map-reduce操作
1. 主从复制
1. 分片
1. 空间索引(spatial index)

VS MySQL && PostgreSQL

数据存储选项 查询类型 附加功能
MySQL 支持空间 spatial
1. CURD
1. 内置函数
1. 自定义存储过程
1. 支持ACID（需要使用 InnoDB ）
1. 主从复制和主主复制（master-master replication）
PostgreSQL 支持可定制类型
1. CURD
1. 条件查询
1. 支持ACID
1. 主从复制
1. 由第三方支持多主复制（multi-master replication）

2. 持久化

  • 时间点转储 （point-in-time-dump），“在指定时间段内有指定数量的写操作执行”，这一条件满足时执行，又可以通过调用两条转存储到硬盘（dump-to-disk）命令中任何一条来执行。
  • 将所有修改数据库的命令写入一个只追加（append-only）文件里面，根据数据的重要程度，将只追加写入设置为异步（sync）

扩展Redis的读性能，为Redis提供故障转移（failover）支持，Redis主从复制特性：复制的从服务器连接主服务器，接收主服务器发送的整个数据库的初始副本（copy）；主服务器执行的写命令，都会被发送给所有连接着的从服务器去执行，实现主从数据同步。从服务器不断更新数据，客户端可以访问任意数据库获取数据。

3. 数据类型

**String 字符串** Redis字符串是字节序列。Redis字符串是二进制安全的，意味着有一个已知的长度没有任何特殊字符终止，所以可以存储任何东西，512M为上限；Redis采用结构sdshdr和sds封装了字符串，字符串相关的操作实现在源文件sds.h/sds.c中。

  1. typedef char* sds;
  2. struct sdshdr {
  3.     longlen;
  4.     longfree;
  5.     charbuf[];
  6. }

**List 双向链表** Redis的链表是简单的字符串列表，排序插入。可以添加元素到Redis列表的头部或尾部。list的定义和实现在源文件adlist.h/adlist.c。

typedef struct listIter {
    listNode * next;
    intdirection;
} listIter;

typedef struct list {
    listNode * head;
    listNode * tail;
    void* (*dup)(void* ptr);
    void(*free)(void* ptr);
    int(*match)(void* ptr, void* key);
    unsignedintlen;
    listIteriter;
} list;

**hash表 dict** Redis哈希键值对的集合，Redis的哈希值是字符串和字符串之间的映射，因此他们被用来表示对象。在源文件dict.h/dict.t中实现hashtable的操作。
image.jpeg

**zset 有序集合** Redis的有序集合类似Redis集合，字符串不重复的集合。

typedef struct zskiplistNode {
    struct zskiplistNode * *forward;
    struct zskiplistNode* backward;
    double score;
    rebj* obj;
}zskiplistNode;

typedef struct zskiplist {
    struct zskiplistNode * header,*tail;
    unsigned long length;
    int level;
}zskiplist;

typedef struct zset {
    dict * dict;
    zskiplist* zsl;
}zset;

4. Redis 6.0

4.1. “非”单线程

Redis在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的“单线程”。但如果严格来讲从Redis4.0之后并不是单线程，除了主线程外，它也有后台线程在处理一些较为缓慢的操作，例如清理脏数据、无用连接的释放、大 key 的删除等等。

4.2. Why not

为什么不使用多线程？
官方曾做过类似问题的回复：使用Redis时，几乎不存在CPU成为瓶颈的情况， Redis主要受限于内存和网络。例如在一个普通的Linux系统上，Redis通过使用pipelining每秒可以处理100万个请求，所以如果应用程序主要使用O(N)或O(log(N))的命令，它几乎不会占用太多CPU。
使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗。Redis通过AE事件模型以及IO多路复用等技术，处理性能非常高，因此没有必要使用多线程。单线程机制使得 Redis 内部实现的复杂度大大降低，Hash 的惰性 Rehash、Lpush 等等 “线程不安全” 的命令都可以无锁进行。

4.3. Why

为什么引入多线程？
Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理80,000到100,000 QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。
但随着越来越复杂的业务场景，有些公司动不动就上亿的交易量，因此需要更大的QPS。常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器，但该方案有非常大的缺点，例如要管理的Redis服务器太多，维护代价大；某些适用于单个Redis服务器的命令不适用于数据分区；数据分区无法解决热点读/写问题；数据偏斜，重新分配和放大/缩小变得更加复杂等等。
从Redis自身角度来说，因为读写网络的read/write系统调用占用了Redis执行期间大部分CPU时间，瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:
• 提高网络 IO 性能，典型的实现比如使用 DPDK 来替代内核网络栈的方式
• 使用多线程充分利用多核，典型的实现比如 Memcached。
协议栈优化的这种方式跟 Redis 关系不大，支持多线程是一种最有效最便捷的操作方式。所以总结起来，redis支持多线程主要就是两个原因：
• 可以充分利用服务器 CPU 资源，目前主线程只能利用一个核
• 多线程任务可以分摊 Redis 同步 IO 读写负荷

4.4. Default

默认是否开启多线程？
Redis6.0的多线程默认是禁用的，只使用主线程。如需开启需要修改redis.conf配置文件：io-threads-do-reads yes
image.jpeg

4.5. How

线程数量如何设置？
开启多线程后，还需要设置线程数，否则是不生效的。同样修改redis.conf配置文件
image.jpeg
关于线程数的设置，官方有一个建议：4核的机器建议设置为2或3个线程，8核的建议设置为6个线程，线程数一定要小于机器核数。还需要注意的是，线程数并不是越大越好，官方认为超过了8个基本就没什么意义了。

4.6. 性能提升效果

Redis 作者 antirez 在 RedisConf 2019分享时曾提到：Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云esc进行过测试，GET/SET 命令在4线程 IO时性能相比单线程是几乎是翻倍了。
测试环境：
Redis Server: 阿里云 Ubuntu 18.04，8 CPU 2.5 GHZ, 8G 内存，主机型号 ecs.ic5.2xlarge
Redis Benchmark Client: 阿里云 Ubuntu 18.04，8 2.5 GHZ CPU, 8G 内存，主机型号 ecs.ic5.2xlarge
image.jpeg
说明1：这些性能验证的测试并没有针对严谨的延时控制和不同并发的场景进行压测。数据仅供验证参考而不能作为线上指标。
说明2：如果开启多线程，至少要4核的机器，且Redis实例已经占用相当大的CPU耗时的时候才建议采用，否则使用多线程没有意义。所以估计80%的公司开发人员看看就好。

4.7. 实现机制

image.jpeg
流程描述：

  1. 主线程负责接收建立连接请求，获取 socket 放入全局等待读处理队列。
  2. 主线程处理完读事件之后，通过 RR(Round Robin) 将这些连接分配给这些 IO 线程。
  3. 主线程阻塞等待 IO 线程读取 socket 完毕。
  4. 主线程通过单线程的方式执行请求命令，请求数据读取并解析完成，但并不执行。
  5. 主线程阻塞等待 IO 线程将数据回写 socket 完毕。
  6. 解除绑定，清空等待队列。

image.jpeg
设计特点：

  1. IO 线程要么同时在读 socket，要么同时在写，不会同时读或写。

  2. IO 线程只负责读写 socket 解析命令，不负责命令处理。

    4.8. 并发安全问题

    从上面的实现机制可以看出，Redis的多线程部分只是用来处理网络数据的读写和协议解析，执行命令仍然是单线程顺序执行。所以我们不需要去考虑控制 key、lua、事务，LPUSH/LPOP 等等的并发及线程安全问题。

    4.9. Redis 6.0.1安装

    6.0的正式版为6.0.1，和其他版本的redis没有任何区别。需注意配置多线程数一定要小于cpu核心数，查看核心数量：

    [root@centos7.5 ~]# lscpuArchitecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3

    4.10. 总结

    关于多线程这个特性，在6.0 RC1时，Antirez曾做过说明：
    Redis支持多线程有2种可行的方式：

  3. 第一种就是像“memcached”那样，一个Redis实例开启多个线程，从而提升GET/SET等简单命令中每秒可以执行的操作。这涉及到I/O、命令解析等多线程处理，因此，我们将其称之为“I/O threading”。

  4. 另一种就是允许在不同的线程中执行较耗时较慢的命令，以确保其它客户端不被阻塞，我们将这种线程模型称为“Slow commands threading”。

经过深思熟虑，Redis不会采用“I/O threading”，redis在运行时主要受制于网络和内存，所以提升redis性能主要是通过在多个redis实例，特别是redis集群。接下来我们主要会考虑改进两个方面：

  1. Redis集群的多个实例通过编排能够合理地使用本地实例的磁盘，避免同时重写AOF。
  2. 提供一个Redis集群代理，便于用户在没有较好的集群协议客户端时抽象出一个集群。

补充说明一下，Redis和Memcached一样是一个内存系统，但不同于Memcached。多线程是复杂的，必须考虑使用简单的数据模型，执行LPUSH的线程需要服务其他执行LPOP的线程。
我真正期望的实际是“slow operations threading”，在redis6或redis7中，将提供“key-level locking”，使得线程可以完全获得对键的控制以处理缓慢的操作。

5. IO模型

  1. 同步阻塞IO（Blocking IO）：即传统的IO模型。
  2. 同步非阻塞IO（Non-blocking IO）：默认创建的socket都是阻塞的，非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的NIO并非Java的NIO（New IO）库。
  3. IO多路复用（IO Multiplexing）：即经典的Reactor设计模式，有时也称为异步阻塞IO，Java中的Selector和Linux中的epoll都是这种模型。
  4. 异步IO（Asynchronous IO）：即经典的Proactor设计模式，也称为异步非阻塞IO。

同步和异步的概念描述的是用户线程与内核的交互方式：同步是指用户线程发起IO请求后需要等待或者轮询内核IO操作完成后才能继续执行；而异步是指用户线程发起IO请求后仍继续执行，当内核IO操作完成后会通知用户线程，或者调用用户线程注册的回调函数。
阻塞和非阻塞的概念描述的是用户线程调用内核IO操作的方式：阻塞是指IO操作需要彻底完成后才返回到用户空间；而非阻塞是指IO操作被调用后立即返回给用户一个状态值，无需等到IO操作彻底完成。
另外，Richard Stevens 在《Unix 网络编程》卷1中提到的基于信号驱动的IO（Signal Driven IO）模型，由于该模型并不常用，本文不作涉及。接下来，我们详细分析四种常见的IO模型的实现原理。为了方便描述，我们统一使用IO的读操作作为示例。

5.1. 同步阻塞IO

同步阻塞IO模型是最简单的IO模型，用户线程在内核进行IO操作时被阻塞。
image.jpeg

用户线程通过系统调用read发起IO读操作，由用户空间转到内核空间。内核等到数据包到达后，然后将接收的数据拷贝到用户空间，完成read操作。同步阻塞IO模型伪代码：

{ read(socket, buffer); process(buffer); }

即用户需要等待read将socket中的数据读取到buffer后，才继续处理接收的数据。整个IO请求的过程中，用户线程是被阻塞的，这导致用户在发起IO请求时，不能做任何事情，对CPU的资源利用率不够。

5.2. 同步非阻塞IO

 同步非阻塞IO是在同步阻塞IO的基础上，将socket设置为NONBLOCK。这样做用户线程可以在发起IO请求后可以立即返回。<br /> <br />![image.jpeg](https://cdn.nlark.com/yuque/0/2021/jpeg/21458167/1620286702779-55414e28-5473-43af-b141-5bc63d8e5214.jpeg#align=left&display=inline&height=300&margin=%5Bobject%20Object%5D&name=image.jpeg&originHeight=704&originWidth=1256&size=194994&status=done&style=none&width=535)

由于socket是非阻塞的方式，因此用户线程发起IO请求时立即返回。但并未读取到任何数据，用户线程需要不断地发起IO请求，直到数据到达后，才真正读取到数据，继续执行。同步非阻塞IO模型伪代码：

{ while(read(socket, buffer) != SUCCESS); process(buffer); }

即用户需要不断地调用read，尝试读取socket中的数据，直到读取成功后，才继续处理接收的数据。整个IO请求的过程中，虽然用户线程每次发起IO请求后可以立即返回，但是为了等到数据，仍需要不断地轮询、重复请求，消耗了大量的CPU的资源。一般很少直接使用这种模型，而是在其他IO模型中使用非阻塞IO这一特性。

5.3. IO多路复用*

这是IO模型的一种，即经典的Reactor设计模式，有时也称为异步阻塞IO。
image.jpeg
多路指的是多个socket连接，复用指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll是最新的也是目前最好的多路复用技术。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），且Redis在内存中操作数据的速度非常快（内存内的操作不会成为这里的性能瓶颈），主要以上两点造就了Redis具有很高的吞吐量。
IO多路复用模型是建立在内核提供的多路分离函数select基础之上的，使用select函数可以避免同步非阻塞IO模型中轮询等待的问题。
image.jpeg

用户首先将需要进行IO操作的socket添加到select中，然后阻塞等待select系统调用返回。当数据到达时，socket被激活，select函数返回。用户线程正式发起read请求，读取数据并继续执行。
从流程上来看，使用select函数进行IO请求和同步阻塞模型没有太大的区别，甚至还多了添加监视socket，以及调用select函数的额外操作，效率更差。但是，使用select以后最大的优势是用户可以在一个线程内同时处理多个socket的IO请求。用户可以注册多个socket，然后不断地调用select读取被激活的socket，即可达到在同一个线程内同时处理多个IO请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。select函数伪代码：

{
  select(socket);
  while(1) {
    sockets = select();
    for(socket in sockets) {
      if(can_read(socket)) {
          read(socket, buffer);
          process(buffer);
      }
    }
  }
}

其中while循环前将socket添加到select监视中，然后在while内一直调用select获取被激活的socket，一旦socket可读，便调用read函数将socket中的数据读取出来。
使用select函数的优点并不仅限于此。虽然上述方式允许单线程内处理多个IO请求，但是每个IO请求的过程还是阻塞的（在select函数上阻塞），平均时间甚至比同步阻塞IO模型还要长。如果用户线程只注册自己感兴趣的socket或者IO请求，然后去做自己的事情，等到数据到来时再进行处理，则可以提高CPU的利用率。
IO多路复用模型使用了Reactor设计模式实现了这一机制。
image.jpeg

EventHandler抽象类表示IO事件处理器，它拥有IO文件句柄Handle（通过get_handle获取），以及对Handle的操作handle_event（读/写等）。继承于EventHandler的子类可以对事件处理器的行为进行定制。Reactor类用于管理EventHandler（注册、删除等），并使用handle_events实现事件循环，不断调用同步事件多路分离器（一般是内核）的多路分离函数select，只要某个文件句柄被激活（可读/写等），select就返回（阻塞），handle_events就会调用与文件句柄关联的事件处理器的handle_event进行相关操作。
image.jpeg

通过Reactor的方式，可以将用户线程轮询IO操作状态的工作统一交给handle_events事件循环进行处理。用户线程注册事件处理器之后可以继续执行做其他的工作（异步），而Reactor线程负责调用内核的select函数检查socket状态。当有socket被激活时，则通知相应的用户线程（或执行用户线程的回调函数），执行handle_event进行数据读取、处理的工作。由于select函数是阻塞的，因此多路IO复用模型也被称为异步阻塞IO模型。注意，这里的所说的阻塞是指select函数执行时线程被阻塞，而不是指socket。一般在使用IO多路复用模型时，socket都是设置为NONBLOCK的，不过这并不会产生影响，因为用户发起IO请求时，数据已经到达了，用户线程一定不会被阻塞。
IO多路复用模型伪代码：

void UserEventHandler::handle_event() {
    if(can_read(socket)) {
        read(socket, buffer);
        process(buffer);
    }
}
{
    Reactor.register(new UserEventHandler(socket));
}

用户需要重写EventHandler的handle_event函数进行读取数据、处理数据的工作，用户线程只需要将自己的EventHandler注册到Reactor即可。
Reactor中handle_events事件循环伪代码：

Reactor::handle_events() {
    while(1) {
        sockets = select();
        for(socket in sockets) {
            get_event_handler(socket).handle_event();
        }
    }
}

事件循环不断地调用select获取被激活的socket，然后根据获取socket对应的EventHandler，执行器handle_event函数即可。
IO多路复用是最常使用的IO模型，但是其异步程度还不够“彻底”，因为它使用了会阻塞线程的select系统调用。因此IO多路复用只能称为异步阻塞IO，而非真正的异步IO。

5.4. 异步IO

 “真正”的异步IO需要操作系统更强的支持。在IO多路复用模型中，事件循环将文件句柄的状态事件通知给用户线程，由用户线程自行读取数据、处理数据。而在异步IO模型中，当用户线程收到通知时，数据已经被内核读取完毕，并放在了用户线程指定的缓冲区内，内核在IO完成后通知用户线程直接使用即可。<br />异步IO模型使用了Proactor设计模式实现了这一机制。<br />![image.jpeg](https://cdn.nlark.com/yuque/0/2021/jpeg/21458167/1620286704988-1e5aa9f9-8dcf-457c-93c2-29f67fde8c32.jpeg#align=left&display=inline&height=300&margin=%5Bobject%20Object%5D&name=image.jpeg&originHeight=413&originWidth=1242&size=242918&status=done&style=none&width=902)

Proactor模式和Reactor模式在结构上比较相似，不过在用户（Client）使用方式上差别较大。Reactor模式中，用户线程通过向Reactor对象注册感兴趣的事件监听，然后事件触发时调用事件处理函数。而Proactor模式中，用户线程将AsynchronousOperation（读/写等）、Proactor以及操作完成时的CompletionHandler注册到AsynchronousOperationProcessor。
AsynchronousOperationProcessor使用Facade模式提供了一组异步操作API（读/写等）供用户使用，当用户线程调用异步API后，便继续执行自己的任务。AsynchronousOperationProcessor 会开启独立的内核线程执行异步操作，实现真正的异步。当异步IO操作完成时，AsynchronousOperationProcessor将用户线程与AsynchronousOperation一起注册的Proactor和CompletionHandler取出，然后将CompletionHandler与IO操作的结果数据一起转发给Proactor，Proactor负责回调每一个异步操作的事件完成处理函数handle_event。虽然Proactor模式中每个异步操作都可以绑定一个Proactor对象，但是一般在操作系统中，Proactor被实现为Singleton模式，以便于集中化分发操作完成事件。
image.jpeg

异步IO模型中，用户线程直接使用内核提供的异步IO API发起read请求，且发起后立即返回，继续执行用户线程代码。不过此时用户线程已经将调用的AsynchronousOperation和CompletionHandler注册到内核，然后操作系统开启独立的内核线程去处理IO操作。当read请求的数据到达时，由内核负责读取socket中的数据，并写入用户指定的缓冲区中。最后内核将read的数据和用户线程注册的CompletionHandler分发给内部Proactor，Proactor将IO完成的信息通知给用户线程（一般通过调用用户线程注册的完成事件处理函数），完成异步IO。异步IO模型伪代码：

void UserCompletionHandler::handle_event(buffer) {
    process(buffer);
}
{
    aio_read(socket, new UserCompletionHandler);
}

用户需要重写CompletionHandler的handle_event函数进行处理数据的工作，参数buffer表示Proactor已经准备好的数据，用户线程直接调用内核提供的异步IO API，并将重写的CompletionHandler注册即可。
相比于IO多路复用模型，异步IO并不十分常用，不少高性能并发服务程序使用IO多路复用模型+多线程任务处理的架构基本可以满足需求。况且目前操作系统对异步IO的支持并非特别完善，更多的是采用IO多路复用模型模拟异步IO的方式（IO事件触发时不直接通知用户线程，而是将数据读写完毕后放到用户指定的缓冲区中）。

6. 集群

6.1. Codis

**

6.2. Redis Cluster

**