数据库优化原理解析（一）：让我们从Redis谈起

从Redis说起

MySQL培训为什么说Redis呢，其实现在主流数据库的核心思路大体都一样，无非就是某一种数据库更侧重于某一方向而已，我从Redis引出要讲的东西。

1 Redis有多快

Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写，官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

2 Redis为什么这么快

• 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。
• 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的。
• 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
• 使用多路I/O复用模型，非阻塞IO；
• 使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

2.1 多路I/O复用模型

我首先列取一下几种常见的I/O模型

2.1.1 同步 & 异步

同步与异步是针对多个事件(线程/进程)来说的。

• 如果事件A需要等待事件B的完成才能完成，这种串行执行机制可以说是同步的，这是一种可靠的任务序列，要么都成功，要么都失败。
• 如果事件B的执行不需要依赖事件A的完成结果，这种并行的执行机制可以说是异步的。事件B不确定事件A是否真正完成，所以是不可靠的任务序列。

同步异步可以理解为多个事件的执行方式和执行时机如何，是串行等待还是并行执行。同步中依赖事件等待被依赖事件的完成，然后触发自身开始执行，异步
中依赖事件不需要等待被依赖事件，可以和被依赖事件并行执行，被依赖事件执行完成后，可以通过回调、通知等方式告知依赖事件。

2.1.2 阻塞 & 非阻塞

阻塞与非阻塞是针对单一事件(线程/进程)来说的。

• 对于阻塞，如果一个事件在发起一个调用之后，在调用结果返回之前，该事件会被一直挂起，处于等待状态。
• 对于非阻塞，如果一个事件在发起调用以后，无论该调用当前是否得到结果，都会立刻返回，不会阻塞当前事件。

阻塞与非阻塞可以理解为单个事件在发起其他调用以后，自身的状态如何，是苦苦等待还是继续干自己的事情。非阻塞虽然能提高CPU利用率，但是也带来了系统线程切换的成本，需要在CPU执行时间和系统切换成本之间好好估量一下。

2.1.3 同步阻塞

应用程序执行系统调用，应用程序会一直阻塞，直到系统调用完成。应用程序处于不再消费CPU而只是简单等待响应的状态。当响应返回时，数据被移动到用户空间的缓冲区，应用程序解除阻塞。

2.1.4 同步非阻塞

设备以非阻塞形式打开，I/O操作不会立即完成，read操作可能会返回一个错误代码。应用程序可以执行其他操作，但需要请求多次I/O操作，直到数据可用。

同步非阻塞形式实际上是效率低下的，因为：

• 应用程序需要在不同的任务之间切换。异步非阻塞是你只需要执行当前任务，系统调用会主动通知你，不用频繁切换。
• 数据在内核中变为可用到调用read返回数据之间存在时间间隔，会造成整体数据吞吐量降低

2.1.5 异步非阻塞

应用程序的其他处理任务与I/O任务重叠进行。读请求会立即返回，说明请求已经成功发起，应用程序不被阻塞，继续执行其它处理操作。当read响应到达，将数据拷贝到用户空间，产生信号或者执行一个基于线程回调函数完成I/O处理。应用程序不用在多个任务之间切换。

非阻塞I/O和异步I/O区别在于，在非阻塞I/O中，虽然进程大部分时间不会被block，但是需要不停的去主动check，并且当数据准备完成以后，也需要应用程序主动调用recvfrom将数据拷贝到用户空间；异步I/O则不同，就像是应用程序将整个I/O操作交给了内核完成，然后由内核发信号通知。期间应用程序不需要主动去检查I/O操作状态，也不需要主动从内核空间拷贝数据到用户空间。

非阻塞I/O看起来是non-blocking的，但是只是在内核数据没准备好时，当数据准备完成，recvfrom需要从内核空间拷贝到用户空间，这个时候其实是被block住的。而异步I/O是当进程发起I/O操作后，再不用主动去请求，知道内核数据准备好并发出信号通知，整个过程完全没有block。

2.2 几种常用I/O模型

2.2.1 BIO

阻塞同步I/O模型，服务器需要监听端口号，客户端通过IP和端口与服务器简历TCP连接，以同步阻塞的方式传输数据。服务端设计一般都是 客户端-线程模型，新来一个客户端连接请求，就新建一个线程处理连接和数据传输

当客户端连接较多时就会大大消耗服务器的资源，线程数量可能超过最大承受量

2.2.2 伪异步I/O

与BIO类似，只是将客户端-线程的模式换成了线程池，可以灵活设置线程池的大小。但这只是对BIO的一种优化手段，并没有解决线程连接的阻塞问题。

2.2.3 NIO

同步非阻塞I/O模型，利用selector多路复用器轮询为每一个用户创建连接，这样就不用阻塞用户线程，也不用每个线程忙等待。只使用一个线程轮询I/O事件，比较适合高并发，高负载的网络应用，充分利用系统资源快速处理请求返回响应消息，是和连接较多连接时间I/O任务较短

2.2.4 AIO

异步非阻塞，需要操作系统内核线程支持，一个用户线程发起一个请求后就可以继续执行，内核线程执行完系统调用后会根据回调函数完成处理工作。比较适合较多I/O任务较长的场景。

多路复用的本质是同步非阻塞I/O，多路复用的优势并不是单个连接处理的更快，而是在于能处理更多的连接。

I/O编程过程中，需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。
I/O多路复用技术通过把多个I/O的阻塞复用到同一个select阻塞上，一个进程监视多个描述符，一旦某个描述符就位， 能够通知程序进行读写操作。因为多路复用本质上是同步I/O，都需要应用程序在读写事件就绪后自己负责读写。
最大的优势是系统开销小，不需要创建和维护额外线程或进程。

应用场景
服务器需要同时处理多个处于监听状态或者多个连接状态的套接字
需要同时处理多种网络协议的套接字
一个服务器处理多个服务或协议
目前支持多路复用的系统调用有select, poll, epoll。

下面用图片表示一下他们的区别

3 select和recvfrom

3.1 select

理解了select就抓住了I/O多路复用的精髓，对应的操作系统中调用的则是系统的select函数，该函数会等待多个I/O事件(比如读就绪，写)的任何一个发生，并且只要有一个网络事件发生，select线程就会执行。如果没有任何一个事件发生则阻塞。我们在下面小节中会重点讲述。函数如下：

#include<sys/select.h>
#include<sys/time.h>
int select(int maxfdpl,fd_set *readset,fd_set *writeset,fd_set *exceptset,const struct timeval *timeout);

从这个函数的定义中的参数，我们能够看出它描述的是，当调用select的时候告知内核对那些事件(读就绪，写)感兴趣以及等待多长时间。

为了方便我们理解select调用，可以参照下面这张图，是jdk的基于I/O多路复用技术的NIO实现。重点在于理解Selector复用器。

这张图可以看出阻塞式I/O、非阻塞式I/O、I/O复用、信号驱动式I/O他们的第二阶段都相同，也就是都会阻塞到recvfrom调用上面就是图中“发起”的动作。异步式I/O两个阶段都要处理。这里我们重点对比阻塞式I/O(也就是我们常说的传统的BIO)和I/O复用之间的区别。

阻塞式I/O和I/O复用，两个阶段都阻塞，那区别在哪里呢？就在于上面讲述的Selector，虽然第一阶段都是阻塞，但是阻塞式I/O如果要接收更多的连接，就必须创建更多的线程。I/O复用模式下在第一个阶段大量的连接统统都可以过来直接注册到Selector复用器上面，同时只要单个或者少量的线程来循环处理这些连接事件就可以了，一旦达到“就绪”的条件，就可以立即执行真正的I/O操作。这就是I/O复用与传统的阻塞式I/O最大的不同。也正是I/O复用的精髓所在。

从应用进程的角度去理解始终是阻塞的，等待数据和将数据复制到用户进程这两个阶段都是阻塞的。这一点我们从应用程序是可以清楚的得知，比如我们调用一个以I/O复用为基础的NIO应用服务。调用端是一直阻塞等待返回结果的。
从内核的角度等待Selector上面的网络事件就绪，是阻塞的，如果没有任何一个网络事件就绪则一直等待直到有一个或者多个网络事件就绪。但是从内核的角度考虑，有一点是不阻塞的，就是复制数据，因为内核不用等待，当有就绪条件满足的时候，它直接复制，其余时间在处理别的就绪的条件。这也是大家一直说的非阻塞I/O。实际上是就是指的这个地方的非阻塞。

大致代码如下：

ServerSocketChannel serverChannel = ServerSocketChannel.open();// 打开一个未绑定的serversocketchannel   
Selector selector = Selector.open();// 创建一个Selector
serverChannel .configureBlocking(false);//设置非阻塞模式
serverChannel .register(selector, SelectionKey.OP_READ);//将ServerSocketChannel注册到Selector


while(true) {
  int readyChannels = selector.select();
  if(readyChannels == 0) continue;
  Set selectedKeys = selector.selectedKeys();
  Iterator keyIterator = selectedKeys.iterator();
  while(keyIterator.hasNext()) {
    SelectionKey key = keyIterator.next();
    if(key.isAcceptable()) {
        // a connection was accepted by a ServerSocketChannel.
    } else if (key.isConnectable()) {//连接就绪
        // a connection was established with a remote server.
    } else if (key.isReadable()) {//读就绪
        // a channel is ready for reading
    } else if (key.isWritable()) {//写就绪
        // a channel is ready for writing
    }
    keyIterator.remove();
  }
}

3.2 recvfrom

recvfrom一般用于UDP协议中,但是如果在TCP中connect函数调用后也可以用。用于从（已连接）套接口上接收数据，并捕获数据发送源的地址。也就是我们本文中以及书中说的真正的I/O操作。

4 用户进程和内核

根据网络OSI七层模型和网际网协议族的同比，我们可以知道这里说的用户进程和内核是以传输层为分割线，传输层以上(不包括)是指用户进程，传输层以下(包括)是指内核。上三层，web客户端比如浏览器、web服务器这些都属于应用层，里面跑的程序则是应用进程。下四层处理所有的通信细节，发送数据，等待确认，给无序到达的数据排序等等。这四层也是通常作为操作系统内核的一部分提供。由此可见图1中说的系统调用的地方正是第四层和第五层之间的位置。

为了理解用户进程和内核，再来看一张图，网络数据流向图。也清晰的标明了用户进程和内核的位置。值得注意的一点是客户与服务器之间的信息流在其中一端是向下通过协议栈的，跨越网络后，在另一端是向上通过协议栈的。这张图描述的是局域网内，如果是在广域网那么就是通过很多个路由器承载实际数据流。

5 哈希表概述

首先简单介绍几个概念：哈希表（散列表）、映射、冲突、链地址、哈希函数。

哈希表（Hash table）的初衷是为了将数据映射到数组中的某个位置，这样就能够通过数组下标访问该数据，提高数据的查找速度，这样的查找的平均期望时间复杂度是O(1)的。

例如四个整数 6、7、9、12 需要映射到数组中，我们可以开一个长度为13（C语言下标从0开始）的数组，然后将对应值放到对应的下标，但是这样做，就会浪费没有被映射到的位置的空间。

采用哈希表的话，我们可以只申请一个长度为4的数组，如下图所示：

将每个数的值对数组长度4取模，然后放到对应的数组槽位中，这样就把离散的数据映射到了连续的空间，所以哈希表又称为散列表。这样做，最大限度上提高空间了利用率，并且查找效率还很高。

那么问题来了，如果这四个数据是6、7、8、11呢？继续看图：

7 和 11 对4取模的值都是 3，所以占据了同一个槽位，这种情况我们称为冲突 （collision）。一般遇到冲突后，有很多方法解决冲突，包括但不限于 开放地址法、再散列法、链地址法 等等。 Redis采用的是链地址法，所以这里只介绍链地址法，其它的方法如果想了解请自行百度。

链地址法就是将有冲突的数据用一个链表串联起来，如图所示：

这样一来，就算有冲突，也可以将有冲突的数据存储在一起了。存储结构需要稍加变化，哈希表的每个元素将变成一个指针，指向数据链表的链表头，每次有新数据来时从链表头插入，可以达到插入的时间复杂度保持O(1)。

再将问题进行变形，如果4个数据是 “are”, “you”, “OK”, “？” 这样的字符串，如何进行映射呢？没错，我们需要通过一个哈希函数将字符串变成整数，哈希函数的概念会在接下来详细讲述，这里只需要知道它可以把一个值变成另一个值即可，比如哈希函数f(x)，调用 f(“are”) 就可以得到一个整数，f(“you”) 也可以得到一个整数。

一个简易的大小写不敏感的字符串哈希函数如下：

#include <stdio.h>	
#include "stdafx.h"
#include <iostream>



using namespace std;

unsigned int hashFunction(const unsigned char *buf, int len) {
	unsigned int hash = (unsigned int)5381;                       // hash初始种子，实验值
	while (len--)
		hash = ((hash << 5) + hash) + (tolower(*buf++));          // hash * 33 + c
	return hash;
}
int main() {
	unsigned char a = 'a';
	unsigned char *buf = &a;
	cout << tolower(*buf) << endl;
	int i = hashFunction(buf,10);
	cout << i << endl;
		
	
	system("pause");
	return 0;
}

上述代码涉及到的原理较多，我就不扩展了。

我们看到，哈希函数的作用就是把非数字的对象通过一系列的算法转化成数字（下标），得到的数字可能是哈希表数组无法承载的，所以还需要通过取模才能映射到连续的数组空间中。对于这个取模，我们知道取模的效率相比位运算来说是很低的，那么有没有什么办法可以把取模用位运算来代替呢？

答案是有！我们只要把哈希表的长度 L 设置为2的幂\(L = 2^n\)，那么 L-1 的二进制表示就是n个1，任何值 x 对 L 取模等同于和 (L-1) 进行位与（C语言中的&）运算。公式如下：

# 取模运算转化成位运算 (在不产生溢出的情况下)
a % (2^n) 等价于 a & (2^n - 1)

# 乘法运算转化成位运算 (在不产生溢出的情况下)
a * (2^n) 等价于 a<< n

# 除法运算转化成位运算 (在不产生溢出的情况下)
a / (2^n) 等价于 a>> n
例: 12/8 == 12>>3
a % 2 等价于 a & 1       

6 Redis数据结构定义

6.1 哈希表

/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;	// 哈希表数组(二级指针)
    unsigned long size;	// 哈希表数组的大小
    unsigned long sizemask;	// 用于映射位置的掩码，值永远等于(size-1)
    unsigned long used;	// 哈希表已有节点的数量
} dictht;

• table 是一个数组，数组的每个元素都是一个指向 dict.h/dictEntry 结构的指针；
• size 记录哈希表的大小，即 table 数组的大小，且一定是2的幂；
• used 记录哈希表中已有结点的数量；
• sizemask 用于对哈希过的键进行映射，索引到 table 的下标中，且值永远等于 size-1。具体映射方法很简单，就是对 哈希值 和 sizemask 进行位与操作，由于 size 一定是2的幂，所以 sizemask=size-1，自然它的二进制表示的每一个位(bit)都是1，等同于上文提到的取模；

如图所示，为一个长度为8的空哈希表。

6.2 哈希表节点

哈希表节点用 dict.h/dictEntry 结构表示，每个 dictEntry 结构存储着一个键值对，且存有一个 next 指针来保持链表结构：

typedef struct dictEntry {
    void *key;                  // 键
    union {                     // 值
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;     // 指向下一个哈希表节点，形成单向链表
} dictEntry;

共用体

构造数据类型,也叫联合体

用途：使几个不同类型的变量共占一段内存(相互覆盖)

结构体是一种构造数据类型

用途：把不同类型的数据组合成一个整体-------自定义数据

• key 是键值对中的键；
• v 是键值对中的值，它是一个联合类型，方便存储各种结构；

next 是链表指针，指向下一个哈希表节点，他将多个哈希值相同的键值对串联在一起，用于解决键冲突；如图所示，两个dictEntry 的 key 分别是 k0 和 k1，通过某种哈希算法计算出来的哈希值和 sizemask 进行位与运算后都等于 3，所以都被放在了 table 数组的 3号槽中，并且用 next 指针串联起来。

6.3 字典

Redis中字典结构由 dict.h/dict 表示：

typedef struct dict {
    dictType *type; // 和类型相关的处理函数
    void *privdata;	// 上述类型函数对应的可选参数
    dictht ht[2];	// 两张哈希表，ht[0]为原生哈希表，ht[1]为 rehash 哈希表
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

• type 是一个指向 dict.h/dictType 结构的指针，保存了一系列用于操作特定类型键值对的函数；

• privdata 保存了需要传给上述特定函数的可选参数；

• ht 是两个哈希表，一般情况下，只使用ht[0]，只有当哈希表的键值对数量超过负载(元素过多)时，才会将键值对迁移到ht[1]，这一步迁移被称为 rehash (重哈希)，rehash 会在下文进行详细介绍；

• rehashidx 由于哈希表键值对有可能很多很多，所以 rehash 不是瞬间完成的，需要按部就班，那么 rehashidx 就记录了当前 rehash 的进度，当 rehash 完毕后，将 rehashidx 置为-1；

  typedef struct dictType {
  uint64_t (*hashFunction)(const void *key);
  void *(*keyDup)(void *privdata, const void *key);
  void *(*valDup)(void *privdata, const void *obj);
  int (*keyCompare)(void *privdata, const void *key1, const void *key2);
  void (*keyDestructor)(void *privdata, void *key);
  void (*valDestructor)(void *privdata, void *obj);
  } dictType;

6.4 rehash

随着字典操作的不断执行，哈希表保存的键值对会不断增多（或者减少），为了让哈希表的负载因子维持在一个合理的范围之内，当哈希表保存的键值对数量太多或者太少时，需要对哈希表大小进行扩展或者收缩。

获取Hash表Size

/* Our hash table capability is a power of two */
static unsigned long _dictNextPower(unsigned long size) {
    unsigned long i = DICT_HT_INITIAL_SIZE; //DICT_HT_INITIAL_SIZE默认值为4

    if (size >= LONG_MAX) return LONG_MAX;
    while(1) {
        if (i >= size)
            return i;
        i *= 2;
    }
}

扩大或者缩小Hash表

/* Expand the hash table if needed */
static int _dictExpandIfNeeded(dict *d)
{
    /* Incremental rehashing already in progress. Return. */
    if (dictIsRehashing(d)) return DICT_OK;

    /* If the hash table is empty expand it to the initial size. */
    if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);

    /* If we reached the 1:1 ratio, and we are allowed to resize the hash
     * table (global setting) or we should avoid it but the ratio between
     * elements/buckets is over the "safe" threshold, we resize doubling
     * the number of buckets. */
    if (d->ht[0].used >= d->ht[0].size &&
        (dict_can_resize ||
         d->ht[0].used/d->ht[0].size > dict_force_resize_ratio))
    {
        return dictExpand(d, d->ht[0].used*2);
    }
    return DICT_OK;
}	

哈希表扩展

/* Expand or create the hash table */
int dictExpand(dict *d, unsigned long size)
{
    /* the size is invalid if it is smaller than the number of
     * elements already inside the hash table */
    if (dictIsRehashing(d) || d->ht[0].used > size)
        return DICT_ERR;

    dictht n; /* the new hash table */
    unsigned long realsize = _dictNextPower(size);

    /* Rehashing to the same table size is not useful. */
    if (realsize == d->ht[0].size) return DICT_ERR;

    /* Allocate the new hash table and initialize all pointers to NULL */
    n.size = realsize;
    n.sizemask = realsize-1;
    n.table = zcalloc(realsize*sizeof(dictEntry*));
    n.used = 0;

    /* Is this the first initialization? If so it's not really a rehashing
     * we just set the first hash table so that it can accept keys. */
	// 如果 ht[0] 为空，那么这就是一次创建新哈希表行为
	// 将新哈希表设置为 ht[0] ，然后返回

    if (d->ht[0].table == NULL) {
        d->ht[0] = n;
        return DICT_OK;
    }

    /* Prepare a second hash table for incremental rehashing */
	// 如果 ht[0] 不为空，那么这就是一次扩展字典的行为
	// 将新哈希表设置为 ht[1] ，并打开 rehash 标识
    d->ht[1] = n;
    d->rehashidx = 0;
    return DICT_OK;
}

定时进行rehash

/* Rehash for an amount of time between ms milliseconds and ms+1 milliseconds */
int dictRehashMilliseconds(dict *d, int ms) {
    long long start = timeInMilliseconds();
    int rehashes = 0;

    while(dictRehash(d,100)) {
        rehashes += 100;
        if (timeInMilliseconds()-start > ms) break;
    }
    return rehashes;
}