在《Redis数据结构》中我们说到Redis的Soted Set类型底层使用的是ziplist以及skiplist，然后在Redis7.0的时候正式使用listpack替换了ziplist，本文主要简单说下skiplist，观关于ziplist以及listpack可以看看《Redis数据结构-ZipList与ListPack》这篇文章。

什么时候使用skiplist

在Redis中只有Sorted Set使用到了skiplist。skiplist在查找、删除、添加等操作的时间复杂度都是O(log₂N)，这就是跳跃表的优点，其缺点就是需要的存储空间比较大，属于用空间换时间的类型。

在Redis的配置文件中我们可以看到这么两个配置：

# 与Hash以及List类型类似，为了节省大量空间，# Sorted Set在存储时也会被特殊编码。这种编码仅在Sorted Set的长度和元素低于以下限制时使用：# ==============================Redis6.0==============================zset-max-ziplist-entries 128zset-max-ziplist-value 64# ==============================Redis7.0==============================zset-max-listpack-entries 128zset-max-listpack-value 64

这里使用Redis7.0来测试，首先将配置zset-max-listpack-entries改小一点方便测试，这里我们改成3：

127.0.0.1:6379> CONFIG SET zset-max-listpack-entries 3OK127.0.0.1:6379> ZADD zset1 1 a 2 b 3 c(integer) 3127.0.0.1:6379> OBJECT ENCODING zset1"listpack"127.0.0.1:6379> ZADD zset1 4 d(integer) 1127.0.0.1:6379> OBJECT ENCODING zset1"skiplist"

可以看到这里元素数量超过3后，编码方式就从listpack变成了skiplist，然后我们再将配置zset-max-listpack-value改成5：

127.0.0.1:6379> CONFIG SET zset-max-listpack-value 5OK127.0.0.1:6379> ZADD zset2 1 a(integer) 1127.0.0.1:6379> OBJECT ENCODING zset2"listpack"127.0.0.1:6379> ZADD zset2 1 abcdefg(integer) 1127.0.0.1:6379> OBJECT ENCODING zset2"skiplist"

同理当我们添加的元素长度超过5后，编码方式也会从从listpack变成了skiplist。

skiplist是什么

单向链表

首先我们先来看一个单向链表，即使这个链表中的数据都是有序的，但是当我们想要查找某一个数据的时候，也只能遍历这个链表，时间复杂度是O(n)，比如在下面这个链表中，想要查找39，则需要遍历8次才行。

我们都知道数组以及链表它们都有自己的优缺点，那有没有办法搞一种数据结构，使得链表的遍历也能快呢？

既然链表遍历慢，时间复杂度是O(n)，那尝试给链表加个索引是否能变快呢？这里将上面的链表稍微改造一下，我们在每个节点上新增一个指针down，并且垂直扩充链表，最后可以得到下面这样一个数据结构：

这样就相当于增加一个“捷径”（多级索引），减少了遍历的次数，这个时候我们仅仅只需要查找2次就可以查找到39，但是相对的维护这么一个结构也增加了内存空间的消耗。

skiplist

从上面我们就可以得知，skiplist实际就是一个用空间换时间的数据结构，skiplist提取出链表中的关键节点（索引），先在关键节点上面查找，再进入下层链表查找，这样提取出多层的关键节点，最后就形成了跳跃表（skiplist）。

时间复杂度

如果一个链表有N个节点，那么skiplist里会有多少级索引呢？

按照上面的结构来推算：

1. 第一级索引大约有$N\over2$个节点。
2. 第二级索引大约有$N\over4$个节点。
3. 第三级索引大约有$N\over8$个节点。

依次类推，所以我们可以知道第M级索引将大约有$\frac{N}{2^M}$。假设索引的最高级T，只有两个节点（头节点和尾节点），通过这个公式我们可以得知，$\frac{N}{2^T}=2$，所以最后我们可以得知最高级$T=\log(2^{N})-1$，如果包含原始的链表，那么整个skiplist的高度就是$\log(2^N)$。

所以skiplist的时间复杂度也就是O(log₂N)。

空间复杂度

相对于一个普通单向链表，一个skiplist需要额外存储多级索引，那这些额外的索引需要消耗多少空间呢？

这里还是假设有一个长度为N的单向链表，根据上面我们得知从第一级索引开始每层的节点数分别是：$N\over2$、$N\over4$、$N\over8$…$8$、$4$、$2$，每往上一层，节点就少一半，直到最后只剩下2个节点。就是一个等比数列。那么这些索引的总和也就是$\frac{N}{2}+\frac{N}{4}+\frac{N}{8}+...+8+4+2=n-2$，所以我们可以得知skiplist的空间复杂度就是O(N)，也就是说如果将包含N个节点的单向链表构造成skiplist，还需要额外再使用接近N个节点的存储空间。

结构设计

在源码server.h第930行可以看到定义了一个叫zskiplist的结构：

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

1. *header：指向头节点的指针，可以通过这个指针在O(1)的时间复杂度内定位到头节点。
2. *tail：指向尾节点的指针，可以通过这个指针在O(1)的时间复杂度内定位到头节点。
3. length：记录了skiplist的长度，也就是skiplist包含的节点数量（不包括头节点），可以在O(1)的时间复杂度内返回skiplist长度。
4. level：记录了skiplist的最大层数，可以在O(1)的时间复杂度内最大层数。

节点的结构

而skiplist的节点的结构则在源码server.h第920行：

typedef struct zskiplistNode {    /* 成员对象 */    sds ele;    /* 分值 作为索引 */    double score;    /*后退指针，用于从后往前遍历使用 */    struct zskiplistNode *backward;    /* 节点的层结构 数组 */    struct zskiplistLevel {        /* 前指针 */        struct zskiplistNode *forward;        /* 跨度，用来确定本节点再链表中的排位  zrank */        unsigned long span;    } level[];} zskiplistNode;

1. ele：每个节点保存的成员对象，在同一个skiplist中，每个节点保存的成员对象必须是唯一的，但是多个节点保存的score（分值）却可以是相同的。

   score（分值）相同的节点将按照成员对象在字典排序中的大小来进行排序，成员对象较小的节点会排在前面，而成员对象较大的节点则会排在后面。

2. score：在skiplist中，每个节点按各自所保存的分值从小到大排列。

3. *backward：指向位于当前层的前一个节点，在从后往前遍历时使用。与前进指针所不同的是每个节点只有一个后退指针，因此每次只能后退一个节点。

4. zskiplistLevel：节点的层结构，每个层结构都有两个属性分别是*forward和span（前进指针和跨度）：

   1. *forward：用来访问位于表尾方向的其他节点
   2. span：记录了*forward（前进指针）所指向节点和当前节点的距离（也就是跨度越大，距离越远）。

结构图

那么在Redis中，skiplist的结构就是这样的：

在《Reids数据结构》这篇文章中，我们说到了Redis中的Set数据类型底层是使用的intset或者hashtable数据结构，本文简单说下intset，关于hashtable可以看看这篇文章：《Redis数据结构-HashTable》。

Redis在什么时候使用intset呢？

简单说如果Set中的元素都是整数类型且元素个数小于等于配置项set-max-intset-entries，那就用intset，反之hashtable。

下面我们将set-max-intset-entries修改为3方便测试：

127.0.0.1:6379> config set set-max-intset-entries 3OK127.0.0.1:6379> SADD k1 1 2 3(integer) 3127.0.0.1:6379> OBJECT ENCODING k1"intset"127.0.0.1:6379> SADD intset 4(integer) 1127.0.0.1:6379> OBJECT ENCODING intset"hashtable"

可以看到当k1的元素个数超过3之后，编码方式从intset变为了hashtable。

同理集合中包含非整数元素也会使用hashtable：

127.0.0.1:6379> config set set-max-intset-entries 3OK127.0.0.1:6379> SADD k2 1 2 a(integer) 3127.0.0.1:6379> OBJECT ENCODING k2"hashtable"

结构设计

在源码intset.h第35行可以看到intset的结构是这样的：

typedef struct intset {    uint32_t encoding;    uint32_t length;    int8_t contents[];} intset;

1. encoding：编码方式，共支持三种范围：
   1. INTSET_ENC_INT16：占用2个字节，存储范围为[-2^16^,2^16^-1]。
   2. INTSET_ENC_INT32：占用4个字节，存储范围为[-2^32^,2^32^-1]。
   3. INTSET_ENC_INT64：占用8个字节，存储范围为[-2^64^,2^64^-1]。
2. length：存储元素个数。
3. contents[]：指向实际存储数值的连续内存区域（也就是一个数组），intset的每个元素都是contents[]数组的一个数组项，每个项在数组中升序排列，且数组中不包含任何重复项。（虽然这里将contents[]属性声明为int8_t类型的数组，但实际上contents[]数组并不保存任何int8_t类型的值，contents[]数组的真正类型取决于encoding属性的值）。

常用操作

intset的升级（扩容）

前面说到了contents[]的元素类型是由encoding来决定的，那么假设当前contents[]里的元素类型是int32（INTSET_ENC_INT32），然后插入一个新的数据，但是类型是int64（INTSET_ENC_INT64），会发生什么呢？

在源码intset.c第159行有个函数intsetUpgradeAndAdd，这个函数就是用来执行intset的升级的：

/* 升级intset并插入给定整数。 */static intset *intsetUpgradeAndAdd(intset *is, int64_t value) {    /* 当前的编码方式 */    uint8_t curenc = intrev32ifbe(is->encoding);    /* 使用要添加的新值获取新的编码方式 */    uint8_t newenc = _intsetValueEncoding(value);    int length = intrev32ifbe(is->length);    /* 确定数据添加的位置 */    int prepend = value < 0 ? 1 : 0;    /* 首先设置新的类型并调整大小 */    is->encoding = intrev32ifbe(newenc);    is = intsetResize(is,intrev32ifbe(is->length)+1);    /* 从后往前升级，这样就不会覆盖值。比如原本集合有1、2、3、4、5、6INTSET_ENC_INT16，新加入的65538则需要用INTSET_ENC_INT32。      * 注意：“prepend”变量用于确保intset的开头或结尾有一个空的位置。 */    while(length--)        _intsetSet(is,length+prepend,_intsetGetEncoded(is,length,curenc));    /* 将待添加的value添加到首部或者尾部, 因为是扩容所以value是大于原有最大值或小于最小值。 */    if (prepend)        _intsetSet(is,0,value);    else        _intsetSet(is,intrev32ifbe(is->length),value);    /* 长度加1*/    is->length = intrev32ifbe(intrev32ifbe(is->length)+1);    return is;}

如果在一个int32类型的intset中新增一个int64类型的值，那么整个intset里面的元素类型都会变成int64，这个过程主要分为三步：

1. 根据新增的元素的类型，扩展contents[]的空间大小，并为新元素分配空间。
2. 将contents[]当前的所有元素，都转换为和新增元素相同的类型，然后将类型转换后的元素放置到正确的位上，且在放置的过程中还要保证原本数组的有序性。
3. 最后修改encoding以及length长度加1。

注意：intset升级后不会再次降级，这里主要是考虑到资源消耗问题，没有必要在降级。

添加

intset的添加元素操作的源码在intset.c第206行的*intsetAdd函数：

/* 在 intset 中插入一个整数 */intset *intsetAdd(intset *is, int64_t value, uint8_t *success) {    /*获取合适的编码方式*/    uint8_t valenc = _intsetValueEncoding(value);    uint32_t pos;    if (success) *success = 1;    /* 如果需要升级编码，则进行升级。     * 如果我们需要升级，我们知道这个值应该被追加（如果 > 0）或预置（如果 < 0），      * 因为它在现有值的范围之外。 */    if (valenc > intrev32ifbe(is->encoding)) {        /* 这里执行intset的升级以及添加 */        return intsetUpgradeAndAdd(is,value);    } else {        /* 如果集合中已经存在值，则中止。使用了二分查询。         * 这个调用将使用正确的位置填充“pos”，以便在找不到值时插入值。*/        if (intsetSearch(is,value,&pos)) {            if (success) *success = 0;            return is;        }        /*调整集合大小*/        is = intsetResize(is,intrev32ifbe(is->length)+1);        if (pos < intrev32ifbe(is->length)) intsetMoveTail(is,pos,pos+1);    }    /* 真正执行写入集合的函数 */    _intsetSet(is,pos,value);    /* 长度加1*/    is->length = intrev32ifbe(intrev32ifbe(is->length)+1);    return is;}

删除

删除操作的源码在intset.c第236行的intsetRemove函数中：

/* 从intset中删除整数 */intset *intsetRemove(intset *is, int64_t value, int *success) {    uint8_t valenc = _intsetValueEncoding(value);    uint32_t pos;    if (success) *success = 0;    /* 当给定值处于当前集合的编码范围且存在集合当中 */    if (valenc <= intrev32ifbe(is->encoding) && intsetSearch(is,value,&pos)) {        uint32_t len = intrev32ifbe(is->length);        /* 可以删除 */        if (success) *success = 1;        /* 用尾部覆盖值并更新长度 */        if (pos < (len-1)) intsetMoveTail(is,pos+1,pos);        is = intsetResize(is,len-1);        /*长度减1*/        is->length = intrev32ifbe(len-1);    }    return is;}

查找

一般查找操作（比如返回一个元素）、判断是否存在、查找位置的操作都是调用intset.c第56行的函数_intsetGetEncoded：

/* 返回给定编码的位置pos的值 */static int64_t _intsetGetEncoded(intset *is, int pos, uint8_t enc) {    int64_t v64;    int32_t v32;    int16_t v16;    if (enc == INTSET_ENC_INT64) {        memcpy(&v64,((int64_t*)is->contents)+pos,sizeof(v64));        memrev64ifbe(&v64);        return v64;    } else if (enc == INTSET_ENC_INT32) {        memcpy(&v32,((int32_t*)is->contents)+pos,sizeof(v32));        memrev32ifbe(&v32);        return v32;    } else {        memcpy(&v16,((int16_t*)is->contents)+pos,sizeof(v16));        memrev16ifbe(&v16);        return v16;    }}

创建一个intset

要创建一个intset，调用的是intset.c第98行中的*intsetNew函数：

/* 创建一个空的intset */intset *intsetNew(void) {    /* 分配内存 */    intset *is = zmalloc(sizeof(intset));    /* 默认编码是INTSET_ENC_INT16 */    is->encoding = intrev32ifbe(INTSET_ENC_INT16);    /* 长度初始为0 */    is->length = 0;    return is;}

在《Reids数据结构》这篇文章中，我们说到了Redis的List数据类型底层的数据结构是使用的quicklist，本文简单说下quicklist。

Redis在版本7.0的时候已经将quicklist的节点从ziplist换成了listpack，关于ziplist以及listpack可以看看这篇文章：《Redis数据结构-ZipList与ListPack》。本文主要以quicklist的节点是ziplist来说明。

首先quicklist是一个双向链表结构，像是ziplist以及linkedlist的集合体，每个节点就是一个个ziplist，然后每个节点使用双向指针连接起来。

结构设计

在源码quicklist.h第105行可以看到quicklist的结构是这样定义的：

/* quicklist是一个 40字节的结构体（在 64 位系统上），用于描述 quicklist。 * 'count' 是所有节点中的总entry数。 * 'len' 是quicklist节点的数目。 * 'compress' 是一个数字，表示不压缩的 quicklist 节点数（如果压缩功能被禁用，则为 0）。 * 'fill' 是用户请求（或默认）的填充因子。 * 'bookmarks' 是一个可选特性，用于重新分配此结构体时使用，以避免不使用时占用内存。*/typedef struct quicklist {    quicklistNode *head;    quicklistNode *tail;    unsigned long count;        /* 所有 ziplist 中的entry数 */    unsigned long len;          /* quicklistNode 的数量 */    int fill : QL_FILL_BITS;              /* 每个节点的填充因子 */    unsigned int compress : QL_COMP_BITS; /* 深度不压缩的末尾节点；0=禁用 */    unsigned int bookmark_count: QL_BM_BITS;    quicklistBookmark bookmarks[];} quicklist;

• *head：表示指向头节点的指针。
• *tail：表示指向尾节点的指针。
• count： 所有ziplist中的entry数量总和。
• len：quicklist中quicklistNode的个数。
• fill：每个节点的填充因子，存放list-max-ziplist-size配置项的值。
• compress： 每个节点的压缩深度设置，存放list-compress-depth配置项的值。
• bookmarks：是一个可选特性，用于重新分配此结构体时使用，以避免不使用时占用内存。

quicklistNode的结构

quicklistNode的结构同样在源码quicklist.h中：

/* 我们使用bit filed（位域）将quicklistNode限制在32字节。 * count：16 位，最大值为 65536（max zl bytes 为 65k，因此实际最大值 < 32k）。 * encoding：2 位，RAW=1、LZF=2。 * container：2 位，NONE=1、ZIPLIST=2。 * recompress：1 位，bool，如果节点临时解压缩以供使用，则为 true。 * attempted_compress：1 位，boolean，用于测试时验证。 * extra：10 位，用于未来的自由使用；填充剩余的 32 位 */typedef struct quicklistNode {    struct quicklistNode *prev;    struct quicklistNode *next;    unsigned char *zl;    unsigned int sz;             /* ziplist 大小（以字节为单位） */    unsigned int count : 16;     /* ziplist 中项目的计数 */    unsigned int encoding : 2;   /* RAW==1 或 LZF==2 */    unsigned int container : 2;  /* NONE==1 或 ZIPLIST==2 */    unsigned int recompress : 1; /* 是否对节点进行了临时解压缩 */    unsigned int attempted_compress : 1; /* 节点无法压缩；太小 */    unsigned int extra : 10; /* 更多位用于未来使用 */} quicklistNode

• *prev：表示指向前一个节点的指针。

• *next：表示指向后一个节点的指针。

• *zl：数据指针。如果当前节点的数据没有压缩，那么它指向一个ziplist结构；否则，它指向一个quicklistLZF结构。

• sz：表示*zl指向的ziplist大小（包括zlbytes, zltail, zllen, zlend和各个数据项），单位是字节，。

  注意：如果ziplist被压缩了，sz的值依然还是压缩之前的ziplist的大小。

• count：表示ziplist中entry节点数量。只有16bit。

• encoding：表示ziplist是否被压缩以及使用的什么压缩算法，1代表没有压缩，2代表使用的LZF压缩算法压缩的。

• container：预留字段，原本是用来表示quicklist节点是直接存数据还是使用ziplist（或者其他数据结构），但是Redis6.0的实现里，这个值固定为2。

• recompress：表示是否对节点进行了临时解压缩，比如当我们使用类似lindex这样的命令查看了某一项本来压缩的数据时，需要把数据暂时解压，这个时候就设置recompress=1做一个标记，等有机会再把数据重新压缩。

上面说到*zl还可能指向一个quicklistLZF结构，这个结构的源码在quicklist.h第64行：

/* quicklistLZF 是一个 4+N 字节的结构体，其中包含了 'sz' 和 'compressed' 两个字段。 * 'sz' 表示 'compressed' 字段的字节长度。 * 'compressed' 是一个 LZF 压缩过的数据，它的总长度为 'sz' 字节。 * 注意：quicklistNode->zl 压缩后的长度存储在 quicklistLZF->sz 中。 * 当 quicklistNode->zl 被压缩时，node->zl 指向 quicklistLZF */typedef struct quicklistLZF {    unsigned int sz; /* LZF 大小，以字节为单位 */    char compressed[];} quicklistLZF;

• sz：表示compressed字段的字节长度。
• compressed：是一个LZF压缩过的数据，它的总长度为sz个字节。

在《Reids数据结构》这篇文章中，说到了在Redis6中List、Sorted Set以及Hash底层都使用了ziplist这一数据结构，并在Redis7后新增了一个数据结构listpack替换了ziplist，这里再简单说下ziplist和listpack。

Redis在什么时候使用ziplist或者listpack

这里我们使用Hash这个数据类型来举例，首先在Redis6的配置文件中，我们可以看到两个配置项分别是：

# 当哈希表的条目数量较少且最大条目不超过一个给定的阈值时，# 哈希表会使用一种内存高效的数据结构进行编码。可以使用以下指令配置这些阈值。hash-max-ziplist-entries 512hash-max-ziplist-value 64

• hash-max-ziplist-entries：使用ziplist保存时哈希集合中的最大元素个数。
• hash-max-ziplist-value：使用ziplist保存时哈希集合中单个元素的最大长度。

简单说这两个配置就是表示Hash类型键的字段个数小于hash-max-ziplist-entries并且每个字段名和字段值的长度小于hash-max-ziplist-value时，Redis才会使用OBJ_ENCODING_ZIPLIST来存储，上面的两个条件任意一项不满足都会转变为使用OBJ_ENCODING_HT。

下面我们在Redis6中测试一下：

1. 首先可以看到hash-max-ziplist-entries和hash-max-ziplist-value默认值分别是512和64，这里为了方便测试，我们把这两个配置改小，改成2和4，分别表示这个哈希集合中最大元素是2，单个元素的最大长度是4。

   127.0.0.1:6379> CONFIG GET hash-max-ziplist-entries1) "hash-max-ziplist-entries"2) "512"127.0.0.1:6379> CONFIG GET hash-max-ziplist-value1) "hash-max-ziplist-value"2) "64"127.0.0.1:6379> CONFIG SET hash-max-ziplist-entries 2OK127.0.0.1:6379> CONFIG SET hash-max-ziplist-value 4OK

2. 然后来验证hash-max-ziplist-entries（最大元素个数），这里创建一个key名为user，它有两个字段name和age，查看编码仍然还是ziplist。但是当我们再多加一个字段gender后，编码变成了hashtable。

   127.0.0.1:6379> HSET user name jack age 18(integer) 2127.0.0.1:6379> OBJECT ENCODING user"ziplist"127.0.0.1:6379> HSET user name jack age 18 gender male(integer) 1127.0.0.1:6379> OBJECT ENCODING user"hashtable"

3. 同理来验证hash-max-ziplist-value（单个元素最大长度），这里创建一个key名为student，它有一个字段name，值为jack长度为4，最后查看编码是ziplist。但是修改值为jackson后，长度变成了7，再次查看编码已经变成了hashtable。

   127.0.0.1:6379> HSET student name jack(integer) 0127.0.0.1:6379> OBJECT ENCODING student"ziplist"127.0.0.1:6379> HSET student name jackson(integer) 0127.0.0.1:6379> OBJECT ENCODING student"hashtable"

注意：一旦ziplist转换成了hashtable，Hash类型编码就会一直使用hashtable了，不会再次转换回来。

同理在Redis7中也有类似的配置项，只是换成了listpack：

# 当哈希表的条目数量较少且最大条目不超过给定的阈值时，# 它们会使用一种内存高效的数据结构进行编码。可以使用以下指令配置这些阈值。hash-max-listpack-entries 512hash-max-listpack-value 64

ziplist

上面说到Redis6的Hash类型在底层是用的ziplist这个数据结构，那这个ziplist是什么呢？

在源码ziplist.c的头部有着这么一段注释：

/* ziplist是一个经过特殊编码的双向链表，旨在提高内存效率。 * 存储字符串和整数值，其中整数被编码为实际整数而不是一系列字符。  * 允许在O(1)时间内在列表的任一侧进行push和pop操作。  * 但是由于每个操作都需要重新分配ziplist使用的内存，因此实际复杂性与ziplist使用的内存量有关。*/

也就是说不同的数据类型在ziplist里由不同的编码方式（可以理解为压缩数据）。但是随着数据量的增加，查询时间复杂度也在增加，因为只有对头尾节点的操作是O(1)复杂度，其他节点都是O(N)。

结构设计

通常说到链表，不管是单向或者双向链表，在节点中都是由前/后节点指针的，但是ziplist中的节点并没由指针，这是为什么呢？

这主要是因为ziplist是Redis为了节约内存而开发的，它一个是由连续内存块组成的顺序型数据结构，也就是说它是存储在连续的内存上的。ziplist的整体结构如下：

    4 bytes   4 bytes   2 bytes                                 1 byte# +---------+---------+---------+---------+---------+---------+---------+# | zlbytes | zltail  |  zllen  |  entry  | ......  |  entry  |  zlend  |# +---------+---------+---------+---------+---------+---------+---------+

• zlbytes：是一个uint_32_t（32位无符号整型），用来记录整个ziplist占用的内存字节数，计算zlend的位置或者对ziplist内存重新分配时会用到。有个好处就是和之前说到的SDS里面保存一个len来记录字符串长度类似，即获取大小的时候不需要再次遍历计算了，直接获取zlbytes就行了。
• zltail：是一个uint_32_t（32位无符号整型），用来记录ziplist尾节点距离ziplist起始位置有多少字节，通过这个偏移量，就可以不用遍历整个ziplist也可以找到尾节点的位置。
• zllen：是一个uint_16_t（16位无符号整型），记录了ziplist中entry的数量，uint_16_t最大是2¹⁶，但是Redis是这么做的，当entry数量超过最大值后，zllen会被固定成2¹⁶-1，之后如果要获取entry数量那就需要遍历一遍了。
• entry：ziplist的每一个节点，真正用来存储数据的结构，长度由保存的内容来决定。
• zlend：是一个uint_8_t（8位无符号整型），固定为0xFF（十进制表示255），用来标记压缩列表的末端。

entry的结构

在源码ziplist.c第37行中有这么一段注释：

/* ZIPLIST ENTRIES * =============== * * 每个entry节点都包含一些元数据，这些元数据包含两个信息： * 1. 存储了前一个节点的长度，以便能够从后向前遍历列表。 * 2. 提供了entry节点的编码方式。可以用来表示节点类型（整数或者字符串），如果是字符串，还可以表示字符串的有效长度。 * 所以一个完整的`entry`节点的结构如下： * * +-----------+-----------+-----------+ * |  prevlen  |  encoding | entrydata | * +-----------+-----------+-----------+ * * 有时候，编码方式encoding代表了entry节点本身（比如对于比较小的整数），在这种情况下，entrydata部分是不存在的： * * +-----------+-----------+ * |  prevlen  |  encoding | * +-----------+-----------+ * */

所以entry结构分两种情况：

1. 第一种情况：

   1. prevlen：记录前一个节点的长度。
   2. encoding：记录当前节点实际数据的类型和长度。
   3. entrydata：记录当前节点实际的数据。

2. 第二种情况：

   1. prevlen：记录前一个节点的长度。

   2. encoding：在entry节点中存储的是比较小的int类型时，encoding和entrydata会合并在encoding中表示，此时没有entrydata字段。

prelen

prelen的编码分为两种情况：

1. 当前一个entry节点长度小于254的时候，prelen的长度为1个字节，值就是前一个entry节点的长度。
2. 当前一个entry节点长度大于等于254的时候，prelen用5个字节来表示，其中第一个字节固定为254（FE）作为标识，剩余的四个字节则用来表示前一个entry的实际大小。

所以prelen的编码可以是：

/* * <prevlen from 0 to 253> <encoding> <entry> */

或者前一个节点长度大于等于254的时候：

/* * 0xFE <4 bytes unsigned little endian prevlen> <encoding> <entry> */

encoding

encoding的编码取决于保存的内容，前两位表示类型，比如前面两位都是1，即11，则表示整数，除此之外的其他都表示字符串。

1. 当保存的是字符串的时候，有3种编码方式：
   • |00pppppp| ：此时长度是1字节，后6位用来存储字符串长度。所以长度不能超过63。
   • |01pppppp|qqqqqqqq|：此时长度是2字节，后14位用来存储字符串长度，长度不能超过16383。
   • |10000000|qqqqqqqq|rrrrrrrr|ssssssss|ttttttt|：此时长度是5字节，后面的32位用来存储字符串长度，长度不能超过2³² - 1。
2. 当保存的是整数的时候，有6种编码方式：
   • |11000000|：3个字节，后2个字节表示一个int16_t。
   • |11010000|：5个字节，后4个字节表示一个int32_t。
   • |11100000|：9个字节，后8个字节表示一个int64_t。
   • |11110000|：4个字节，后3个字节表示一个24 bit带符号。
   • |11111110|：2个字节，后1个字节表示一个8 bit带符号。
   • |1111xxxx|：1个字节，[0,12]的无符号整数，编码后的值实际上是1到13，因为0000和1111不能用，所以要从编码后的4位值中减去1才能得到正确的值。

|11111111|则表示zlend，用来表示ziplist的结尾。

zlentry源码

在源码ziplist.c第284行可以看到zlentry的结构如下：

/* 我们使用这个函数来接收关于 ziplist 条目的信息。 * 注意这不是数据实际上的编码方式，只是我们得到的填充信息，以便更轻松地操作。*/typedef struct zlentry {    unsigned int prevrawlensize; /* 编码前一个节点的长度需要的字节 */    unsigned int prevrawlen;     /* 前一个节点占用的长度 */    unsigned int lensize;        /* 用于编码此节点类型/长度的字节数。 例如，字符串使用 1、2 或 5 个字节的头。整数总是使用单个字节。*/    unsigned int len;            /* 表示实际条目所需的字节数。对于字符串，这只是字符串长度，而对于整数，它取决于数字范围，可能是 1、2、3、4、8 或 0（对于 4 位即时整数） */    unsigned int headersize;     /* 当前节点的头部大小（prevrawlensize + lensize）即非数据域的大小。 */    unsigned char encoding;      /* 根据条目编码设置为 ZIP_STR_* 或 ZIP_INT_*。但是对于 4 位即时整数，它可以假定一个范围的值，并且必须进行范围检查。 */    unsigned char *p;            /* 指向条目的起始点，即指向前一个条目长度字段。 */} zlentry;

连锁更新

连锁更新是什么呢？首先连锁更新是ziplist一个比较大的缺点，Redis7.0将ziplist更新位listpack的重要原因就是这个。

上面我们说到了ziplist的每个操作（新增或者修改）都需要重新分配ziplist的内存空间。试想一下每当我们新增一个节点，都可能导致prevlen发生变化，从而引起连锁更新问题，导致每个元素的空间都需要重新分配，这会造成性能下降的问题。

这里假如我们有一个ziplist，现在有A、B、C、D四个节点，这四个的长度都刚好是253字节，按照前面我们说的prelen的编码情况，它们的prelen肯定都是1字节。然后我们要新增一个长度大于等于254字节的节点E（加到A前面），那么节点A的prelen则需要变为5个字节，而由于A的长度已经是253字节了，加上这个变化后的prelen，长度已经超过254，所以后面的节点B也需要跟着变化，依次类推。这便是连锁更新问题，这里举例只用了4个节点，实际应用中如果节点数量很多，那么则会造成很多性能消耗。

#                       +-----+# +-----+               |  E  | 254 bytes# |  A  | 253 bytes     +-----+# +-----+               |  A  | 原本刚好253字节，但是前一个节点的长度超过254，prelen变成5个字节，加上本身的253字节，自己也超过了254字节# |  B  | 253 bytes     +-----+# +-----+==============>|  B  | 同理节点A超过了254字节，B的prelen也变成5字节，自身长度也超过254字节# |  C  | 253 bytes     +-----+   # +-----+               |  C  | 同理节点B超过了254字节，C的prelen也变成5字节，自身长度也超过254字节# |  D  | 253 bytes     +-----+# +-----+               |  D  | 同理节点C超过了254字节，D的prelen也变成5字节，自身长度也超过254字节#                       +-----+

相关问题

为什么ziplist特别节省内存

首先说ziplist节省内存是对于普通的List数组，数组的每个元素占用内存都是一样的而且是取决于最大的那个元素。所以ziplist增加了encoding字段，用来针对不同的encoding来细化存储大小。最后ziplist使用prelen这个字段记录上一个节点的长度，解决了遍历的问题。

为什么ziplist要这样重新设计

1. 首先是普通的单向链表或者双向链表的节点都会有一个或两个指针用来指向前后节点，在存储数据特别小的时候，可能数据本身还没有指针占用的空间大。然而从上面我们得知ziplist并没有维护指针，而是保存了前一个节点的长度和当前节点的长度，虽然牺牲了读取性能但是获得了更多的存储空间，也就是常说的时间换空间。

2. 链表在内存中一般不是连续的内存空间，遍历相对来说比较慢。一般数组遍历是根据数组里面存储的数据类型来找到下一个元素的（比如int类型的数组访问下一个元素每次只需要移动一个sizeof(int)就可以），而ziplist的每个节点的长度是可以不一样的，对于不同长度的节点又不可能直接sizeof(entry)，所以ziplist将一些必要的偏移量信息记录在了每一个节点里面。

   sizeof()实际上就是获取数据在内存中所占用的空间，单位是字节。

3. ziplist还有zlbytes以及zllen，前面也说到了分别用来记录ziplist的大小以及节点数量，那么有个好处就是（和SDS里面保存一个len来记录字符串长度类似）：获取ziplist大小以及节点数量的时候不需要再次遍历计算了。

   注意：节点数量超过uint_16_max（2¹⁶）个后还是需要重新遍历。

listpack

前面说到ziplist，但是ziplist有个致命的缺点就是新增和修改元素可能导致连锁更新，这也是Redis7.0新增listpack替换ziplist的原因。那么listpack是什么呢？

Redis作者在github上是这样介绍的：

一个listpack被编码成一个单一线性块的内存。它有一个固定长度的6个字节的头部（与ziplist的10个字节不同，因为我们不再需要一个指向最后一个元素开头的指针）。头部后面直接就是 listpack的元素。理论上，这个数据结构不需要任何终止符，但是出于某些考虑，提供了一个特殊的条目，用于标记listpack的结尾，形式为单个字节，其值为FF（255）。终止符的主要优点是能够在不持有（并在每次迭代时比较）listpack结尾地址的情况下扫描listpack，并且容易识别listpack是否格式正确或缩短。

结构设计

listpack结构如下：

      4 bytes        2 bytes                                                     1 byte# +--------------+--------------+--------------+--------------+--------------+-----------------+# |   totbytes   | num-elements |     entry    |    ......    |    entry     |listpack-end-byte|# +--------------+--------------+--------------+--------------+--------------+-----------------+

• tot-bytes：是一个uint_32_t（32位无符号整型），表示listpack的总字节数（包括头部本身和终止符），也就是说listpack最多占用4294967295bytes。这基本上是保存listpack所需的总分配大小，当需要时，允许跳到结尾以从最后一个元素向前扫描listpack。
• num-elements：是一个uint_16_t（16位无符号整型），表示listpack包含的元素总数。 和ziplist的zllen同理，最多记录uint_16_max（2¹⁶）个元素，超过则固定为2¹⁶-1，此时要获取数量则需要遍历listpack。

entry的结构

Redis作者在github上是这样介绍的：

listpack中的每个元素都具有以下结构：

+----------+----------+----------+| encoding | element  |  element ||  type    |  data    |  tot-len |+----------+----------+----------+|                                |+--------------------------------+      (This is an element)

元素的类型（encoding-type）和元素的总长度（element-tot-len）始终存在。

• encoding-type：当前元素的编码类型，会对不同长度的整数和字符串进行编码。
• element-data：实际存储的元素数据。
• element-tot-len：元素的总长度（encoding-type+element-data的总长度），代表当前节点的回朔起始地址长度的偏移量。

在源码listpack.h第49行是这样定义的：

/* listpack中的每一个节点，不是String就是int. */typedef struct {    /* When string is used, it is provided with the length (slen). */    unsigned char *sval;    uint32_t slen;     /* 当使用integer时，“sval”为 NULL，lval 保存该值。*/    long long lval;} listpackEntry;

对比ziplist，listpack中的每个节点记录的是当前节点的长度，而不是前一个节点的长度。

ziplist和listpack的区别

1. listpack相对于ziplist，它的每个节点中不在包含前一个节点的长度，从而避免的连锁更新的问题。
2. listpack相对于ziplist，没有了zltail（尾节点距离ziplist起始位置有多少字节），解决ziplist内存长度限制的问题。但一个listpack最大内存使用不能超过1GB。

参考文章

• https://pdai.tech/md/db/nosql-redis/db-redis-x-redis-ds.html
• https://blog.csdn.net/m0_51504545/article/details/117391204

在《Reids数据结构》这篇文章中，我们说到了Redis中的Set和Hash数据类型底层都使用到了hashtable这个数据结构以及Redis的key-value数据库有一个全局哈希表，这里简单说下关于hashtable的结构。

Redis中的hashtable

hashtable在Redis中被称为dictionary（字典），是一个数组+链表的结构，正是因为这样hashtable查询数据的时间复杂度是O(1)。简单说就是将key通过Hash函数的计算，就能定位数据在表中的位置，通过索引值就可以直接在数组中获取到数据。既然是哈希表那肯定是有哈希冲突的，在数据逐渐增加的情况下，哈希冲突的可能性也在增加。Redis采用了链式哈希来解决哈希冲突，在不扩容哈希表的前提下，将具有相同哈希值的数据串起来，形成链接起，以便这些数据在表中仍然可以被查询到。（其实就是数组+链表，有点类似Java中的HashMap）。

结构设计

简单来说可以理解成Redis有dictht这么一个结构，这个结构就是一个数组，而数组中的元素则是dictEntry，每个dictEntry元素都有一个指针*next指向哈希冲突的下一个节点形成一个链表。

# dictht数组#   +-----------+#   | dictEntry |#   +-----------+         +-----------+         +-----------+#   | dictEntry |-------->| dictEntry |-------->|  ......   |#   +-----------+         +-----------+         +-----------+#   | dictEntry |#   +-----------+#   | dictEntry |#   +-----------+         +-----------+         +-----------+         +-----------+#   | dictEntry |-------->| dictEntry |-------->| dictEntry |-------->|  ......   |#   +-----------+         +-----------+         +-----------+         +-----------+#   | dictEntry |#   +-----------+#   | dictEntry |#   +-----------+

在Redis6.0的源码dict.h第72行中是这样定义dictht的:

/* 这是我们哈希表的结构。每个字典都有两个这样的结构，因为我们实现了增量式重新哈希，用于旧表和新表。*/typedef struct dictht {    /* 哈希表的数组 */    dictEntry **table;    /* 哈希表的大小 */    unsigned long size;    /* 用来计算索引值的哈希表大小掩码 */    unsigned long sizemask;    /* 已经使用了的节点数量 */    unsigned long used;} dictht;

从源码dict.h第50行中可以看到这个dictht就是一个数组，里面的元素就是指向dictEntry的指针。dictEntry的结构如下：

typedef struct dictEntry {    /* 键值对中的key */    void *key;    /* 键值对中的value */    union {        void *val;        uint64_t u64;        int64_t s64;        double d;    } v;    /* 指向下一个节点 */    struct dictEntry *next;} dictEntry;

可以看到dictEntry结构里面不仅仅有key和value的指针，还有一个指向下一个节点的指针*next，这就是上面说到的用来解决哈希冲突的链式哈希。如果计算出来哈希相同，那么直接在相同的dictEntry里将下一个节点的指针指向冲突的节点就行了。

但是随着数据量的增加，这个链表可能会越来越长，这就会导致查询时间也随着增加，因为链表的遍历时间复杂度是O(N)，那Redis是怎么解决这个问题的呢？在源码dict.h第79行中可以看到还有一个结构体dict，在这个结构里面定义了两个哈希表：

typedef struct dict {    dictType *type;    void *privdata;    /* 两个哈希表，交替使用 */    dictht ht[2];    /* 用来记录字典是否处于rehashing过程中（如果 rehashidx == -1 则表示没有进行 rehashing）*/    long rehashidx;     /* 用来记录当前正在运行的迭代器数量。 */    unsigned long iterators; } dict;

rehash

为什么Redis在dict结构要定义两个哈希表呢？

从上面我们知道，随着数据量增加，Redis中的链式哈希中链表长度也会越来越长，这也使得遍历的时间增加，为了解决这个问题，Redis会进行rehash操作，可以理解为给哈希表扩容，这样来减少哈希冲突，也就变向的减少了链表长度。

Redis中rehash的过程可以分为三个步骤：

1. 首先给ht[1]分配空间，一般是当前哈希表ht[0]的两倍。
2. 把ht[0]的数据迁移到ht[1]中。（Redis大部分操作是单线程的，这里Redis采用了渐进式rehash操作。）
3. 迁移完成后，ht[0]的空间会被释放，并把ht[1]设置给ht[0]，然后在ht[1]创建一个空白的哈希表，为下次rehash做准备。

渐进式rehash

上面Redis在rehash过程中的第2步存在一个问题，那就是Redis大部分操作还是单线程的，这个过程可能会阻塞其他操作，如果是在数据量很大的时候，那可能会花很长时间来完成。所以Redis采用了渐进式rehash操作，简单说就是在每次操作的时候顺便copy到新的哈希表，而且Redis本身也有定时任务来处理。

在这个过程中，Redis中实际同时存在着两个哈希表（ht[0]和ht[1]），所以在这期间对于哈希表的查询操作会在这两张表上进行。比如想要查询一个key，那么Redis会先在ht[0]上查询，如果没有才会到ht[1]上查询。但是这个时候新增的key，也会直接保存到新的哈希表ht[1]中去，而对于ht[0]，不会在添加任何地key上去，这样慢慢地ht[0]就会变成空的哈希表。

rehash触发条件

Redis什么时候才会进行rehash呢？

扩容

在源码dict.c第958行有这么一个函数_dictExpandIfNeeded：

/* 如果需要，扩展哈希表 */static int _dictExpandIfNeeded(dict *d){    /* 如果正在rehash那么就直接返回 */    if (dictIsRehashing(d)) return DICT_OK;    /* 如果哈希表为空，则将其扩展到初始大小 */    if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);    /* 如果哈希表ht[0]中保存的key个数与哈希表大小的比例已经达到1:1，即保存的节点数已经大于等于哈希表大小，     * 并且当前redis的服务允许执行rehash（此时Redis没有在执行`bgsave`或者`bgrewiteaof`命令的时候）。     * 或者保存的节点数与哈希表大小的比例超过了安全阈值（默认值为5），     * 则将哈希表大小扩容为原来的两倍 */    if ((dict_can_resize == DICT_RESIZE_ENABLE &&         d->ht[0].used >= d->ht[0].size) ||        (dict_can_resize != DICT_RESIZE_FORBID &&         d->ht[0].used / d->ht[0].size > dict_force_resize_ratio)){        return dictExpand(d, d->ht[0].used*2);    }    return DICT_OK;}

从上面源码中的注释可以看到rehash触发条件主要有两个：

1. 当used>=size（哈希表中已经使用了的节点数量大于等于哈希表的大小）并且此时Redis没有在执行bgsave或者bgrewiteaof命令时，会触发rehash。
2. 或者当used/size>dict_force_resize_ratio（哈希表中已经使用了的节点数量和哈希表的大小的比例超过5）时，不管此时Redis是否在执行bgsave或者bgrewiteaof命令，都会强制进行rehash操作。

缩容

在数据量增加的时候，Redis会进行rehash，这个时候是扩容2倍，那么当数据减少的时候呢？

Redis在数据量减少的时候也会进行缩容，以便节约空间。在源码server.c第1700行有databasesCron这么一个函数用来处理Redis数据库中我们需要增量执行的“后台”操作，例如活动键过期、resize、rehash等。这里主要看resize部分：

void databasesCron(void) {    /* 通过随机抽样使键过期。对于Slave服务器来说不需要，因为Master服务器会同步DEL命令。*/        if (server.active_expire_enabled) {        if (iAmMaster()) {            activeExpireCycle(ACTIVE_EXPIRE_CYCLE_SLOW);        } else {            expireSlaveKeys();        }    }    /* 逐步对键进行碎片整理。 */    activeDefragCycle();    /* 在没有BGSAVE或者BGREWRITEAOF执行时，对哈希表进行 rehash */    if (!hasActiveChildProcess()) {        /* 使用全局计数器，这样如果在给定的DB上停止计算，我们就能在下一个定时任务从后续的DB开始*/        static unsigned int resize_db = 0;        static unsigned int rehash_db = 0;        int dbs_per_call = CRON_DBS_PER_CALL;        int j;        /* 不能超过拥有的DB最大数量 */        if (dbs_per_call > server.dbnum) dbs_per_call = server.dbnum;        /* Resize调整大小 */        for (j = 0; j < dbs_per_call; j++) {            tryResizeHashTables(resize_db % server.dbnum);            resize_db++;        }        /* Rehash */        if (server.activerehashing) {            for (j = 0; j < dbs_per_call; j++) {                int work_done = incrementallyRehash(rehash_db);                if (work_done) {                    /* 如果已经rehash了一部分，在这里停止并在下一个计划循环中继续进行。*/                    break;                } else {                    /* 如果这个DB不需要rehash，接着尝试下一个*/                    rehash_db++;                    rehash_db %= server.dbnum;                }            }        }    }}

可以看到缩容的时候也会选在没有bgsave或者bgrewiteaof执行的时候。可以看到主要是tryResizeHashTables这个函数在调整大小，这个函数源码在server.c第1436行：

int htNeedsResize(dict *dict) {    long long size, used;    size = dictSlots(dict);    used = dictSize(dict);    return (size > DICT_HT_INITIAL_SIZE &&            (used*100/size < HASHTABLE_MIN_FILL));}/* 如果哈希表中已用槽位的百分比达到 HASHTABLE_MIN_FILL，我们会重新调整哈希表的大小，以节省内存 */void tryResizeHashTables(int dbid) {    if (htNeedsResize(server.db[dbid].dict))        dictResize(server.db[dbid].dict);    if (htNeedsResize(server.db[dbid].expires))        dictResize(server.db[dbid].expires);}

HASHTABLE_MIN_FILL和DICT_HT_INITIAL_SIZE分别定义在server.h第168行和dict.h第76行中：

/* 每个hashtable的初始大小 */#define DICT_HT_INITIAL_SIZE     4/* 哈希表参数 */#define HASHTABLE_MIN_FILL        10      /* 最小哈希表填充 10% */

可以看到HASHTABLE_MIN_FILL和DICT_HT_INITIAL_SIZE分别是10和4，那么从htNeedsResize就可以得知当哈希表的大小大于初始容量且保存的key数量与哈希表的大小的比例小于0.1的时候需要缩容。

Redis中的String类型有有三种编码方式：int、embstr、raw。

• int：保存long型（长整型）的64位（8个字节）有符号整数。范围是[-2^63^,2^63^-1]，也就是[-9223372036854775808,9223372036854775807]，最多19位。

  注意：只有整数才会使用int，如果是浮点数，Redis内部其实是先将浮点数转化为字符串值之后再保存。

  127.0.0.1:6379> SET k1 1.1111111OK127.0.0.1:6379> OBJECT ENCODING k1"embstr"

• embstr：代表embstr格式的SDS（Simple Dynamic String-简单动态字符串），保存长度小于44字节的字符串。embstr（embedded string），顾名思义表示嵌入式的String。

• raw：保存长度大于44字节的字符串。

下面我们测试3个key：

• k1的长度为9，可以看到编码方式是int。
• k2长度大于19，编码方式则为embstr。
• k3的长度大于44，编码方式则为raw。

127.0.0.1:6379> SET k1 123456789OK127.0.0.1:6379> OBJECT ENCODING k1"int"127.0.0.1:6379> SET k2 123456789123456789123OK127.0.0.1:6379> OBJECT ENCODING k2"embstr"127.0.0.1:6379> SET k3 123456789123456789123456789123456789123456789123456789123456789123456789123456789OK127.0.0.1:6379> OBJECT ENCODING k3"raw"

SDS（Simple Dynamic String-简单动态字符串）

上面我们说到了SDS（Simple Dynamic String-简单动态字符串）。那么它是什么呢？

Redis是用C语言实现的，但是它没有直接使用C语言的char*字符数组来实现字符串，而是自己封装了一个名为SDS（Simple Dynamic String-简单动态字符串）的数据结构来表示字符串，也就是 Redis的String数据类型的底层数据结构是SDS。

Redis中所有的key以及所有值对象中包含的字符串对象底层都是由SDS实现的。

SDS结构设计

源码sds.h中是这样写的：

/* Note: sdshdr5 is never used, we just access the flags byte directly. * However is here to document the layout of type 5 SDS strings. */struct __attribute__ ((__packed__)) sdshdr5 {    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */    char buf[];};struct __attribute__ ((__packed__)) sdshdr8 {    uint8_t len; /* used */    uint8_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};//和上面的不同只有len和alloc，也就是长度不同而已struct __attribute__ ((__packed__)) sdshdr16 {    uint16_t len; /* used */    uint16_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};//和上面的不同只有len和alloc，也就是长度不同而已struct __attribute__ ((__packed__)) sdshdr32 {    uint32_t len; /* used */    uint32_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};//和上面的不同只有len和alloc，也就是长度不同而已struct __attribute__ ((__packed__)) sdshdr64 {    uint64_t len; /* used */    uint64_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};

• len：直接记录字符串的长度，这样在获取字符串长度的时候直接返回这个字段的值即可，时间复杂度是O(1)。

• alloc：分配给字符数组的空间长度。可以通过alloc-len计算出剩余的空间大小，在修改字符串的时候，可以判断剩余空间是否满足，不满足的话，会自动将SDS扩容至修改所需要的大小。所以使用SDS既不需要手动修改SDS的空间大小，也不会出现前面所说的缓冲区溢出的问题。

• flags：这个就是用来表示不同类型的SDS。从上面的源码可以看到一共设计了5种类型：sdshdr5、sdshdr8、sdshdr16、sdshdr32和sdshdr64。

  可以看到不同长度的SDS结构基本一样，只有sdshdr5不一样，但是注释中也说了不会使用到。

• buf[]：字符数组，用来保存实际数据。不仅可以保存字符串，也可以保存二进制数据。

Redis为什么要自己设计一个SDS

Redis选择自己设计一个SDS结构来表示字符串，那是否说明C语言中char*字符数组存在一些缺陷？

首先C语言的字符串其实就是一个字符数组，即数组中每个元素是字符串中的一个字符。

# +-----+-----+-----+-----+-----+------+# |  R  |  E  |  D  |  I  |  S  |  \0  |# +-----+-----+-----+-----+-----+------+

1. C语言中获取字符串长度的时间复杂度为O(n)。
2. 还有就是除了字符串的末尾之外，字符串里面不能含有\0字符，否则最先被程序读入的\0字符将被误认为是字符串结尾，这个限制使得C语言的字符串只能保存文本数据，不能保存像图片、音频、视频文化这样的二进制数据。
3. 字符串操作函数不高效且不安全，比如有缓冲区溢出的风险，有可能会造成程序运行终止。

SDS和C语言中的char*对比：

3个编码方式的源码分析

当我们使用Redis的String类型的命令（比如SET k1 v1）来设置值的时候，Redis底层是怎么处理的呢？

源码t_string.c中有个函数setCommand(client *c)是这样写的：

/* SET key value [NX] [XX] [KEEPTTL] [GET] [EX <seconds>] [PX <milliseconds>] *     [EXAT <seconds-timestamp>][PXAT <milliseconds-timestamp>] */void setCommand(client *c) {    robj *expire = NULL;    int unit = UNIT_SECONDS;    int flags = OBJ_NO_FLAGS;    if (parseExtendedStringArgumentsOrReply(c,&flags,&unit,&expire,COMMAND_SET) != C_OK) {        return;    }    c->argv[2] = tryObjectEncoding(c->argv[2]);    setGenericCommand(c,flags,c->argv[1],c->argv[2],expire,unit,NULL,NULL);}

可以看到上面代码中第#10行调用了一个名为tryObjectEncoding的函数，也就是尝试对数据编码，这个函数的源码在object.c中，如下：

/*尝试将字符串对象编码以节省空间*/robj *tryObjectEncoding(robj *o) {long value;sds s = o->ptr;size_t len;    /* 确保这是一个字符串对象，因为我们只在这个函数中编码字符串对象。     * 其他类型使用编码内存效率高的表示形式，但由其类型的命令来处理。*/serverAssertWithInfo(NULL,o,o->type == OBJ_STRING);    /* 只为仍由实际字符数组表示的RAW或EMBSTR编码的对象尝试一些专门的编码。*/if (!sdsEncodedObject(o)) return o;    /* 编码共享对象是不安全的：共享对象可以在Redis的“对象空间”中的任何地方共享，并可能出现在未处理的地方。     * 我们只将它们作为键空间中的值来处理。*/    if (o->refcount > 1) return o;    /* 检查是否可以将此字符串表示为长整数。请注意，我们确信长于20个字符的字符串不能表示为32位或64位整数。*/    len = sdslen(s);    if (len <= 20 && string2l(s,len,&value)) {        /* 表示这个对象可以被编码为long并尝试使用共享对象。* 请注意，在使用maxmemory时，我们避免使用共享整数，* 这是因为每个对象都需要一个私有的LRU字段，以便LRU算法能够正常工作。*/        if ((server.maxmemory == 0 ||            !(server.maxmemory_policy & MAXMEMORY_FLAG_NO_SHARED_INTEGERS)) &&            value >= 0 &&            value < OBJ_SHARED_INTEGERS){            decrRefCount(o);            return shared.integers[value];        } else {            if (o->encoding == OBJ_ENCODING_RAW) {                sdsfree(o->ptr);                o->encoding = OBJ_ENCODING_INT;                o->ptr = (void*) value;                return o;            } else if (o->encoding == OBJ_ENCODING_EMBSTR) {                decrRefCount(o);                return createStringObjectFromLongLongForValue(value);            }        }    }    /* 如果字符串很小且仍以RAW编码，则尝试更高效的EMBSTR编码。     * 在此表示中，对象和SDS字符串在同一块内存中分配，以节省空间和缓存未命中。 */    if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT) {        robj *emb;        if (o->encoding == OBJ_ENCODING_EMBSTR) return o;        emb = createEmbeddedStringObject(s,sdslen(s));        decrRefCount(o);        return emb;    }    /* 不能编码这个对象，最后尝试一下，至少优化SDS字符串内部 */    trimStringObjectIfNeeded(o, 0);    /* 返回原始对象。 */    return o;}

INT编码

当字符串键值的内容可以用一个64位有符号的整形来表示的时候，Redis会将键值转换为long型来存储，此时对应的就是OBJ_ENCODING_INT编码类型。

在源码server.h中可以看到Redis启动的时候会预先建立10000个分别存储[0,9999]的redisObject作为共享对象，也就是说当我们使用SET命令的时候，如果值在[0,9999]之间的话，则可以直接指向共享对象而不需要建立新对象，此时的键值不占空间。

/* Static server configuration */#define OBJ_SHARED_INTEGERS 10000

EMBSTR编码

可以看到上面源码中的第#40行，对于长度小于OBJ_ENCODING_EMBSTR_SIZE_LIMIT（44），Redis会采用OBJ_ENCODING_EMBSTR的方式，embedded string表示嵌入式String：从内存结构上来讲，就是SDS结构体和它对应的redisObject对象分配在同一块连续的内存空间，就像字符串SDS嵌入在redisObject对象之中一样。

然后在上面的第#43调用了一个函数createEmbeddedStringObject来创建一个EmbStr对象，其源码也是在object.c中如下：

/* 如果字符串对象比OBJ_ENCODING_EMBSTR_SIZE_LIMIT小，则使用EMBSTR编码创建字符串对象，否则使用RAW编码。 * 当前的限制为44，是为了使我们分配的最大字符串对象作为EMBSTR仍适合于jemalloc的64字节arena。*/#define OBJ_ENCODING_EMBSTR_SIZE_LIMIT 44/* 创建一个字符串对象，其编码为OBJ_ENCODING_EMBSTR，即sds字符串实际上是一个不可修改的字符串，分配在与对象本身相同的块中。*/robj *createEmbeddedStringObject(const char *ptr, size_t len) {    robj *o = zmalloc(sizeof(robj)+sizeof(struct sdshdr8)+len+1);    struct sdshdr8 *sh = (void*)(o+1);    o->type = OBJ_STRING;    o->encoding = OBJ_ENCODING_EMBSTR;    o->ptr = sh+1;    o->refcount = 1;    if (server.maxmemory_policy & MAXMEMORY_FLAG_LFU) {        o->lru = (LFUGetTimeInMinutes()<<8) | LFU_INIT_VAL;    } else {        o->lru = LRU_CLOCK();    }    sh->len = len;    sh->alloc = len;    sh->flags = SDS_TYPE_8;    if (ptr == SDS_NOINIT)        sh->buf[len] = '\0';    else if (ptr) {        memcpy(sh->buf,ptr,len);        sh->buf[len] = '\0';    } else {        memset(sh->buf,0,len+1);    }    return o;}

RAW编码

当字符串的长度大于OBJ_ENCODING_EMBSTR_SIZE_LIMIT的时候，Redis则会将编码方式改为OBJ_ENCODING_RAW格式，这和OBJ_ENCODING_EMBSTR编码方式的不同之处在于：此时SDS的内存和其依赖的redisObject的内存就不再连续了。

注意这里存在一个问题：在没有超过OBJ_ENCODING_EMBSTR_SIZE_LIMIT的时候，还是变成了RAW编码。

127.0.0.1:6379> SET k1 abcOK127.0.0.1:6379> OBJECT ENCODING k1"embstr"127.0.0.1:6379> APPEND k1 def(integer) 6127.0.0.1:6379> get k1"abcdef"127.0.0.1:6379> OBJECT ENCODING k1"raw"

因为embstr的实现是只读的，在对embstr对象进行修改的时候（比如上面操作的APPEND），都会先转化成RAW然后在修改。所以只要是修改embstr编码的数据，修改后无论其长度是多少，其编码方式一定是RAW。

编码转变的流程图

结论

在Redis的String类型的底层数据结构中只有整数才会使用int编码方式，对于浮点数Redis内部实际上会先把浮点数转化成字符串之后再保存。

而embstr和raw编码其实都是SDS（Simple Dynamic String-简单动态字符串），这是Redis内部自己定义的一种结构。

这三种编码方式的区别是：

• INT

  #  redisObject# +------------+# |    type    |=====>(REDIS_STRING)# +------------+# |  encoding  |=====>(OBJ_ENCODING_INT)# +------------+# |    lru     |# +------------+# |  refcount  |# +------------+# |  ptr(123)  |# +------------+

• EMB

  #  redisObject# +------------+# |    type    |=====>(REDIS_STRING)# +------------+# |  encoding  |=====>(OBJ_ENCODING_EMBSTR)# +------------+# |    lru     |# +------------+# |  refcount  |# +------------+# |    ptr     |# +------------+# |    len     |# +------------+# |   alloc    |# +------------+# |   flags    |# +------------+# | buf("abc") |# +------------+

• RAW

  #  redisObject# +------------+# |    type    |=====>(REDIS_STRING)# +------------+# |  encoding  |=====>(OBJ_ENCODING_RAW)# +------------+# |    lru     |# +------------+# |  refcount  |            SDS# +------------+      +-------------+# |    ptr     |=====>|     len     |# +------------+      +-------------+#                     |    alloc    |#                     +-------------+#                     |    flags    |#                     +-------------+#                     |buf("xyz...")|#                     +-------------+

通常我们都说Redis快，都是说它是基于内存的数据库。但是仅仅是这样吗？

实际上Redis快的原因除了它本身是基于内存的数据库之外，实际上还有一个重要因素那就是它实现的数据结构。注意：【这里说到的数据结构并不是指Redis的数据类型（String、List、Hash、Set、Zset），而是这些数据类型底层依赖的数据结构。】

Redis的五个基本数据类型和底层数据结构的关系

Redis经过多个版本的迭代更新，底层数据结构也发生了变化。

在Redis3.0的时候，5个基本数据类型对应的底层数据结构分别是：

在数据结构发生变化之后：

可以看到，有很多底层使用了两种数据结构，比如Set在元素较少，且都是数字的情况下会使用整数列表，数据增加会变成哈希表。

Redis的键值对数据库是怎么实现的

在Redis中key就是字符串对象，但是value可以是字符串对象，也可以是集合数据类型的对象，比如List对象、Hash对象、Set对象和Zset对象。比如这里新增几个key然后使用type命令即可查看value的类型，可以发现这些类型分别是string、hash以及list。

127.0.0.1:6379> SET k1 v1OK127.0.0.1:6379> HSET student name jack age 13(integer) 2127.0.0.1:6379> RPUSH list v1 v2 v3 v4(integer) 4127.0.0.1:6379> type k1string127.0.0.1:6379> type studenthash127.0.0.1:6379> type listlist

全局哈希表

Redis中key是如何保存的呢？

在Redis中，其实是使用了一个哈希表保存所有键值对，每一个key经过Redis内部的hash算法之后都会计算出一个地址，这个地址就对应一个哈希桶了，使用哈希表的最大的好处就是查找的时间复杂度只有O(1)。哈希表其实就是一个数组，数组中的元素叫做哈希桶。

#+--------+--------+--------+--------+--------+--------+--------+--------+--------+#|  Hash  |  Hash  |  Hash  |  Hash  |  Hash  |  Hash  |  Hash  |  Hash  |  Hash  |#| Bucket | Bucket | Bucket | Bucket | Bucket | Bucket | Bucket | Bucket | Bucket |#+--------+--------+--------+--------+--------+--------+--------+--------+--------+

但是说到hash算法必然有哈希冲突存在，那怎么解决呢？Redis使用了链表来解决这个问题（有点类似Java中的HashMap）。

#   +------------+#   | HashBucket |#   +------------+         +------------+         +------------+#   | HashBucket |-------->|  KeyValue  |-------->|   ......   |#   +------------+         +------------+         +------------+#   | HashBucket |#   +------------+#   | HashBucket |#   +------------+         +------------+         +------------+         +------------+#   | HashBucket |-------->|  KeyValue  |-------->|  KeyValue  |-------->|   ......   |#   +------------+         +------------+         +------------+         +------------+#   | HashBucket |#   +------------+#   | HashBucket |#   +------------+#   | HashBucket |#   +------------+

当这个链表中的元素越来越多之后，一个哈希桶所对应的链表会越来越长，一个链表上的遍历时间复杂度是O(n)，会严重影响性能。Redis为了处理这个问题会有一个rehash操作。大概就是会在内部重新建一个长度为原始长度2倍的空哈希表，然后原哈希表上的元素重新rehash到新的哈希表中去，然后我们使用新的哈希表即可。但是Redis大部分操作还是单线程的，这个过程可能会阻塞其他操作，如果是在数据量很大的时候，那可能会花很长时间来完成。所以Redis采用了渐进式rehash操作，简单说就是在每次操作的时候顺便copy到新的哈希表，而且Redis本身也有定时任务来处理。

哈希桶又是如何保存key的呢？

哈希桶存放的是指向键值对数据的指针（dictEntry），这样通过指针就能找到键值对数据，然后因为键值对的值可以保存字符串对象和集合数据类型的对象，所以键值对的数据结构中并不是直接保存值本身，而是保存了*key和*val指针，分别指向了实际的key对象和value对象，这样一来，即使值是集合数据，也可以通过*val指针找到。dictEntry源码结构如下：

struct dictEntry {    void *key;    union {        void *val;        uint64_t u64;        int64_t s64;        double d;    } v;    struct dictEntry *next;     /* 哈希桶里面的下一个entry */    void *metadata[];                                           };

RedisObject

上面说到了dictEntry，dictEntry中的*key和*val指针指向的是Redis对象（redisObject），Redis中key和value对象都是redisObject。

struct redisObject {    unsigned type:4;        /* 对象的类型，包括：OBJ_STRING、OBJ_LIST、OBJ_HASH、OBJ_SET、OBJ_ZSET等*/    unsigned encoding:4;    /* 具体对应的数据结构*/    unsigned lru:LRU_BITS;  /* 淘汰策略LRU和LFU会用到*/    int refcount;           /* 引用计数，当refcount为0的时候，表示该对象已经不被任何对象引用，可以被淘汰了*/    void *ptr;              /* 指向对象实际的数据结构的指针*/};

为了便于操作，Redis采用redisObject结构来统一五种不同的数据类型，这样所有的数据类型就都可以以相同的形式在函数间传递而不用使用特定的类型结构。同时，为了识别不同的数据类型，redisObject中定义了type和encoding两个字段来对不同的数据类型加以区分。

RedisObject中每个字段的含义：

1. type表示具体的数据类型

2. encoding表示该类型的物理编码方式，同一种数据类型可能会有不同的编码方式（比如String类型就有三种编码方式，分别有：int、embstr、raw）。

   /* Objects encoding. Some kind of objects like Strings and Hashes can be * internally represented in multiple ways. The 'encoding' field of the object * is set to one of this fields for this object. */#define OBJ_ENCODING_RAW 0     /* Raw representation */#define OBJ_ENCODING_INT 1     /* Encoded as integer */#define OBJ_ENCODING_HT 2      /* Encoded as hash table */#define OBJ_ENCODING_ZIPMAP 3  /* No longer used: old hash encoding. */#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */#define OBJ_ENCODING_ZIPLIST 5 /* No longer used: old list/hash/zset encoding. */#define OBJ_ENCODING_INTSET 6  /* Encoded as intset */#define OBJ_ENCODING_SKIPLIST 7  /* Encoded as skiplist */#define OBJ_ENCODING_EMBSTR 8  /* Embedded sds string encoding */#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of listpacks */#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree of listpacks */#define OBJ_ENCODING_LISTPACK 11 /* Encoded as a listpack */

3. lru则是用于淘汰策略的字段，具体可以看这里。

4. refcount则表示对象的引用计数。

5. ptr则是指向对象实际的数据结构的指针。

DEBUG OBEJECT

上面我们说到了同一种数据类型可能会有不同的编码方式。那怎么确定使用的是哪种编码方式呢？

Redis提供了DEBUG OBEJECT命令，DEBUG OBEJECT是一个调试命令，可以查看key的详细信息，其不应该在客户端使用。直接使用会返回error。

127.0.0.1:6379> DEBUG OBJECT key(error) ERR DEBUG command not allowed. If the enable-debug-command option is set to "local", you can run it from a local connection, otherwise you need to set this option in the configuration file, and then restart the server.

这里根据报错信息可以看到，想要使用这个命令还需要修改一个配置enable-debug-command为local，修改需重启Redis。

然后开始测试，首先创建两个key分别使用命令：

127.0.0.1:6379> SET k1 v1OK127.0.0.1:6379> SET COUNT 100OK127.0.0.1:6379> type k1string127.0.0.1:6379> type COUNTstring

可以看到这里个key的类型都是String，然后我们再使用DEBUG OBEJECT查看key的详细信息：

127.0.0.1:6379> DEBUG OBJECT k1Value at:0xffff87135d38 refcount:1 encoding:embstr serializedlength:3 lru:2460675 lru_seconds_idle:113127.0.0.1:6379> DEBUG OBJECT COUNTValue at:0xffff871147b0 refcount:2147483647 encoding:int serializedlength:2 lru:2460514 lru_seconds_idle:279

可以这两个key的类型虽然都是String，但是它们的编码方式却是不同的，分别是int和embstr。

Redis数据结构解析

更多关于Redis的底层的数据结构解析可以看这里：

• 《Redis数据结构-SDS》
• 《Redis数据结构-HashTable》
• 《Redis数据结构-ZipList与ListPack》
• 《Redis数据结构-QuickList》
• 《Redis数据结构-IntSet》
• 《Redis数据结构-SkipList》

• Redis7 新特性

  Redis7和之前的redis版本保持一致稳定。一部分新特性如下：

  新特性	描述
  多AOF文件支持	7.0版本中的一个比较大的变化就是aof文件由一个变成了多个，主要分为两种类型：基本文件（base files）。增量文件（incr files）。在此之外还引入了一个清单文件（mainfest）用于跟踪文件以及文件的创建和应用顺序（恢复）。
  config命令增强	对于Config Set和Get命令，支持在一次调用过程中传递多个配置参数。例如现在可以在执行一次Config Set命令中更改多个参数：config set maxmemory 10000001 maxmemory-clients 50% port 6399
  限制客户端内存使用Client-eviction	一旦Redis连接较多，再加上每个连接的内存占用都比较大的时候，Redis总连接内存占用可能会达到maxmemory的上限，可以增加允许限制所有客户端的总内存使用量配置项，配置文件中对应的配置项：maxmemory-clients 1g``maxmemory-clients 10%可以使用两种配置方式，分别是指定具体内存大小和基于maxmemory的百分比。
  listpack紧凑列表调整	listpack是用来替代ziplist的新数据结构，在7.0版本已经没有ziplist的配置了（6.0版本仅部分数据类型作为过渡阶段在使用）listpack已经替换了ziplist类似hash-max-ziplist-entries的配置
  访问安全性增强ACLV2	在redis.conf配置文件中，protected-mode默认为yes，只有当希望客户端在没有授权的情况下可以连接到Redis Server的时候可以修改为protected-mode no
  Redis Functions	Redis函数，一种新的通过服务端脚本扩展Redis的方式，函数与数据本身一起存储。
  RDB保存时间调整	持久化文件RDB的保存规则发生改变，尤其是时间记录频度变化。
  命令新增和改动	Zset（有序集合）增加ZMPOP，BZMPOP，ZINTERCARD等命令。SET（集合）增加SINTERCARD命令。LIST（列表）增加LMPOP，BLMPOP，从提供的键名列表中的第一个非空列表键中弹出一个或多个元素。
  性能资源利用率、安全等改进	自身底层部分优化改动，Redis核心在许多方面进行了重构和改进。主动碎片整理V2：增强版主动碎片整理，配合Jemalloc版本更新，更快更智能，延时更低。HyperLogLog改进：在Redis5.0中，HyperLogLog算法得到改进，优化了计数统计时的内存使用效率，7.0更加优秀，更好的内存统计报告。

为什么使用索引

索引是存储引擎用于快速找到数据记录的一种数据结构，就好比一本字典的目录，通过目录中找到对应的页码，就可以快速定位想要查找的内容。在MySQL中也是类似的原理，在进行数据查找的时候，首先查看查询条件是否命中某条索引，符合则使用索引查找相关数据，如果不符合则需要全表扫描，也就是一条条地查找记录，直到找到与条件符合的记录。

索引的优点和缺点

索引的概述

MySQL官方对索引的定义是：索引（Index）是帮助MySQL高效获取数据的数据结构。

索引的本质：索引是数据结构。可以简单理解为：排好序的快速查找数据结构，满足特定的查找算法。这些数据结构以某种方式指向数据，这样就可以在这些数据结构的基础上实现高级查找算法。

索引实在存储引擎实现的，因此每种存储引擎的索引不一定完全相同，并且每种存储引擎不一定支持所有索引类型。同时存储引擎可以定义每个表的最大索引数和最大索引长度。所有存储引擎支持每个表至少16个索引，总索引的长度至少为256字节。有些存储引擎支持更多的索引数和更大的索引长度。

索引的优点

1. 可以提高查找的速度，降低IO成本，这也是使用索引的主要原因。
2. 通过创建唯一索引，可以保证数据库表中每一行的数据的唯一性。
3. 在实现数据的参考完整性方面，可以加速表和表之间的连接。也就是说，对于有依赖关系的子表和父表的联合查询时，可以提高查询速度。
4. 在使用分组和排序子句进行数据查询的时候，可以显著减少查询中分组和排序的时间，降低CPU消耗。

索引的缺点

上面说到了索引有很多优点，主要就是提高查询速度，那么索引有哪些缺点呢？

索引的缺点主要体现在下面几个方面：

1. 创建索引和维护索引需要耗费时间，并且随着数据量的增加，对应耗费的时间也会增加。
2. 索引需要占用磁盘空间，除了数据表占数据空间之外，每一个索引还要占用一定的物理空间，存储在磁盘上，如果存在大量索引，索引文件可能比数据文件更快到达最大尺寸。
3. 虽然索引大大提高了查询速度，但是同时也会降低更新表的速度。比如当对表中的数据进行增加、修改、删除的时候，索引也要动态地维护，这样也就是降低了数据地维护速度。

所以在使用索引的时候，需要综合考虑索引的优点以及缺点。

注意：索引可以提高查询速度，但是会影响插入、修改的速度。在这种情况下可以考虑先把索引删除，然后更新数据，最后再创建索引。

InnoDB中索引的推演

在使用索引之前的查找

假设有一个查询的SQL语句，如下：

SELECT 字段列表 FROM 表名 WHERE 字段名 = xxx;

在一个页中的查找

假设目前表中的记录比较少，所有的记录都可以被放到一个页中，在查找记录的时候可以根据搜索条件的不同分为两种情况：

• 以主键为搜索条件：可以在目录中使用二分法快速定位到对应的槽，然后再遍历该槽对应分组中的记录即可快速找到指定的记录。
• 以其他列（字段）作为搜索条件：因为在数据页中并没有对非主键列建立所谓的页目录，所以我们无法通过二分法快速定位相应的槽。这种情况下只能从最小记录开始依次遍历单链表中的每条记录，然后对比每条记录是不是符合搜索条件。很显然，这种方式的效率是非常低的。

在很多页中查找

大部分情况下我们表中存放的记录是非常多的，需要很多数据页来存储这些记录。在很多页中查找记录的话大致可以分为两个步骤：

1. 定位到记录所在的页。
2. 从所在的页内查找相应的记录。

在没有索引的情况下，不论是根据主键列或者其他非主键列查找，由于我们并不能快速的定位到记录所在的页，所以只能从第一个页沿着双向链表一直往下找，然后根据上面说到的在一个页中查找的方式来查找记录。

因为要遍历所有的数据页，所以这种方式显然是非常耗时的。如果这个表的数据量非常大呢，比如有1亿条记录，那么这个时候索引就应运而生了。

设计索引

首先我们创建一个表index_demo：

mysql> CREATE TABLE index_demo(  a INT,  b INT,  c CHAR(1),  PRIMARY KEY (`a`)) ROW_FORMAT=COMPACT;Query OK, 0 rows affected (1.15 sec)mysql> DESCRIBE index_demo;+-------+---------+------+-----+---------+-------+| Field | Type    | Null | Key | Default | Extra |+-------+---------+------+-----+---------+-------+| a     | int     | NO   | PRI | NULL    |       || b     | int     | YES  |     | NULL    |       || c     | char(1) | YES  |     | NULL    |       |+-------+---------+------+-----+---------+-------+3 rows in set (0.17 sec)

这个表中有2个INT类型的列，1个CHAR(1)类型的列，规定字段a为主键，最后这个表使用COMPACT行格式来实际存储记录。那么这个表index_demo的行格式的示意图可以是：

这些分别代表：

• record_type：表示记录的类型，比如0表示普通记录、2表示最小记录、3表示最大记录、1暂时没用，后面会说到。
• next_record：表示下一条记录地址相对于本条记录地址的偏移量，我们用箭头来表明下一条记录。
• filed：这里只记录了在index_demo这张表中的三个列，分别是a、b、c。
• Extra：除了上面的3种信息以外的所有信息，包括其他隐藏列的值以及记录的额外信息。

那么对于有一些记录的示意图可以是下面这样：

一个简单的索引的设计方案

为什么根据一些搜索条件查询时需要遍历所有数据页呢？这是因为每个页中的记录并没有规律，所以并不知道搜索条件会匹配哪些页中的记录，所以不得不依次遍历所有数据页。

那么如果我们想要快速定位到记录在哪些数据页怎么做呢？我们可以建立一个目录来快速定位记录所在的数据页。

建立这个目录必须要完成下面这些事：

1. 下一个数据页中数据记录的主键值必须大于上一个页中数据记录的主键值：

   这里我们假设每个数据页最多可以存放3条记录（实际上一个数据页很大可以存放很多记录）。此时我们根据这个假设在上面创建的表index_demo中插入3条记录：

   mysql> INSERT INTO index_demo VALUES(1,4,'u'),(3,9,'d'),(5,3,'y');Query OK, 3 rows affected (1.29 sec)Records: 3  Duplicates: 0  Warnings: 0

   那么这些记录已经按照主键值的大小串联成了一个单向链表了，那么上面的示意图就可以是：

   

   此时我们再来插入一条记录：

   mysql> INSERT INTO index_demo VALUES(4,4,'a');Query OK, 1 row affected (1.12 sec)

   因为上面我们假设了一个页中最多只能存放3条记录，那么这个时候就不得不再分配一个新的页：

   

   这里注意一下，新分配的数据页的编号可能并不是连续的。它们只是通过维护着上一个页和下一个页的编号而建立了链表关系。

   另外这里页9中的记录最大主键值是5，而我们新插入的主键值是4，因为4<5，所以这里并不符合下一个数据页中记录的主键值必须大于上一个页的主键值的要求，所以在上面我们插入了一个主键值为4的新纪录的时候需要有一个记录的移动。也就是说要把页9中主键值为5的记录移动到页30中去，然后再把主键值为4的记录插入到页9中去，过程如下：

   

   这个过程表明了在对页中的记录进行增删改操作的过程中，我们必须通过一些比如记录移动的操作来始终保持这个状态一直成立，这个状态也就是：下一个数据页中记录的主键值必须大于上一个页中记录的主键值。这个过程称为页分裂。

2. 给所有页建立一个目录项：

由于数据也的编号可能是不连续的，所以在向index_demo表中插入许多条记录后，可能是这样的效果：

因为这些16kb的页在物理存储上是不连续的，所以如果想从这么多页中根据主键值快速定位某些记录所在的页，那么就需要给他做个目录，每个页都对应一个目录项，每个目录项又包括下面两个部分：

• 页的记录中最小的主键值，用key来表示。
• 用page_no来表示页号。

所以上面几个页的目录就像这样：

比如这里的页5，对应第三个目录项，在这个目录项中包含这个这个页的页号5还有这个页中最小的主键值12。接下来我们只需要把这几个目录项在物理存储器上连续存储（比如：数组），就可以实现根据主键快速查找某条记录的功能了。比如这里我们想要查找主键值为20的记录，可以分为下面两步：

1. 先在目录项中根据二分法快速确定出这个记录在第三个目录项，（因为12<20<209），那么它对应的页是页5。
2. 再根据上面说到的在页中查找记录的方式在页5中定位具体的记录。

InnoDB中的索引方案

迭代1次：目录项记录的页

上面说到了一个简易的索引方案，是因为我们为了根据主键值进行查找时使用二分法快速定位具体的目录项而假设所有目录项都可以在物理存储器上连续存储，但是这样做存在几个问题：

• InnoDB是使用页来作为管理存储空间的基本单位，最多能保证16kb的连续存储空间，而随着表中记录数量的增多，需要非常大的连续存储空间才能把所有的目录项都放下，这样对于记录数量非常多的表不太现实。
• 我们常常会对表中的记录进行增删，假如我们把上面页30中的记录都删除了，那也就是说第二个目录项也就没有存在的必要了，这样就需要把后面的目录项全部往前面移动一下，这样做的效率将会非常差。

所以我们需要一种可以灵活管理所有目录项的方式。我们发现目录项其实和记录长的差不多，只不过目录项中的两个页是主键和页号而已，为了和记录做一下区分，我们把这些用来表示目录项的记录称为目录项的记录。

那么InnoDB是怎么区分一条记录是数据记录还是目录项记录的呢？

可以使用记录头信息里的record_type属性，当表示目录项记录的时候，它的每个值表示：

• 0：普通数据记录。
• 1：目录项记录。
• 2：最小记录。
• 3：最大记录。

那么上面的目录项以及数据记录的结构会变成这样：

从图中可以看出来，我们新分配了一个编号为40的页来专门存储目录项记录。这里再次强调目录项记录和普通的数据记录的不同点：

• 目录项记录的record_type=1，而普通记录的record_typ=0。
• 目录项记录只有主键值和页的编号两个列，而普通的记录的列是自己定义的，可能存在很多列，另外还有InnoDB自己添加的隐藏列。

记录头信息里还有一个叫min_rec_mask的属性，只有在存储目录项记录的页中的主键值最小的目录项记录的min_rec_mask值为1，其他别的记录的min_rec_mask值都是0。

相同点：两者用的是一样的数据页，都会为主键值生成Page Directory（页目录），从而在按照主键值进行查找时可以使用二分法来加快查询速度。

比如现在以查找主键为20的记录为例，根据某个主键值去查找记录的步骤就可以大致拆分成下边两步：

1. 先找到存储目录项记录的页，也就是在页40中通过二分法快速定位到对应目录项，因为12<20<209，所以可以定位到对应的记录所在的页就是页5。
2. 再到存储记录的页5中根据二分法快速定位到主键值为20的记录。

迭代2次：多个目录项记录的页

虽然说目录项记录中只存储主键值和对应的页号，比数据记录需要的存储空间小了很多了，但是不管怎么说一个页只有16kb的大小，能存放的目录项记录也是有限的，那如果表中的数据太多，以至于一个数据页不足以存放所有的目录项记录呢？

这里我们假设一个存储目录项记录的页最多只能存放4条目录项记录，所以如果再向上图中插入一条主键值为350的记录的话，那就需要分配一个新的存储目录项记录的页：

从图中可以看出，我们插入了一条主键值为350的记录之后需要两个新的页：

• 为存储该数据记录而新生成了页44。
• 因为原先存储目录项记录的页40的容量已满（前边假设只能存储4条目录项记录），所以不得不需要一个新的页50来存放页44对应的目录项。

现在因为存储目录项记录的页不止一个，所以如果我们想根据主键值查找一条数据记录大致需要3个步骤，还是以查找主键值为20的记录为例：

1. 确定目录项记录页：我们现在的存储目录项记录的页有两个，即页40和页50，又因为页40表示的目录项的主键值的范围是[1,350)，页50表示的目录项的主键值不小于350，所以主键值为20的记录对应的目录项记录在页5中。
2. 通过目录项记录页确定数据记录真实所在的页。在一个存储目录项记录的页中通过主键值定位一条目录项记录的方式说过了。
3. 在真实存储数据记录的页中定位到具体的记录。

迭代3次：目录项记录页的目录页

问题来了，在这个查询步骤的第1步中我们需要定位存储目录项记录的页，但是这些页是不连续的，如果我们表中的数据非常多，则会产生很多存储目录项记录的页，那么我们怎么根据主键值快速定位一个存储目录项记录的页呢？

我们可以为这些存储目录项记录的页在生成一个更高级的目录（开始套娃），就像是一个多级目录一样，大目录里面嵌套小目录，小目录里面才是实际的数据，所以现在每个页的示意图可以是这样的：、

如图，我们生成了一个存储更高级目录项的页70，这个页中的两条记录分别代表页40和页50，如果数据记录的主键值在[1,350)之间，则到页40中查找更详细的目录项记录，如果主键值>=350的话，就到页50中查找更详细的目录项记录。

随着表中记录的增加，这个目录的层级会继续增加，如果简化一下，那么我们可以用下边这个图来描述它：

这个数据结构，它的名称是B+树。

B+Tree

不论是存放数据记录的数据页们还是目录项记录的数据页，我们都把它们存放到B+数这个数据结构中了，所以我们页称这些数据页为节点。从上面的图中可以看出，我们的实际数据记录，其实都存放在B+数的最底层的节点上，这些节点也被称为叶子节点，其余用来存放目录项的节点称为非叶子节点或者内节点，其中B+树最上层的节点称为根节点。

一个B+树的节点其实可以分成很多层，规定最下边的那层，也就是存放我们数据记录的那层为第0层，之后依次往上加。之前我们做了一个非常极端的假设：存放数据记录的页最多存放3条记录，存放目录项记录的页最多存放4条记录。但是实际上真实环境中一个页存放的记录数量是非常大的，假设所有存放数据记录的叶子节点代表的数据页可以存放100条数据记录 ，所有存放目录项记录的内节点代表的数据页可以存放1000条目录项记录，那么：

• 如果B+树有1层：也就是只有1个用于存放数据记录的节点，最多能存放100条记录。
• 如果B+树有2层：最多能存放1000×100=10,0000条记录。
• 如果B+树有3层：最多能存放1000×1000×100=1,0000,0000条记录。
• 如果B+树有4层：最多能存放1000×1000×1000×100=1000,0000,0000条记录。相当多的记录！

你的表里能存放100000000000条记录吗？所以一般情况下，我们用到的B+树都不会超过4层，所以我们通过主键值去查找某条记录最多只需要做4个页面内的查找（查找3个目录项页和一个数据记录页），又因为在每个页面内有所谓的Page Directory（页目录），所以在页面内也可以通过二分法实现快速定位记录。

常见的索引概念

按照物理实现方式，索引可以分为2种，聚簇（聚集）和非聚簇（非聚集）索引。非聚集索引也可以称为二级索引或者辅助索引。

聚簇索引

聚簇索引并不是一种单独的索引类型，而是一种数据存储方式（所有的数据记录都存储在了叶子节点），也就是所谓的索引即数据，数据即索引。

术语“聚簇”表示数据行和相邻的键值聚簇地存储在一起。

特点

1. 使用记录主键值的大小进行记录和页的排序，这包括三个方面的含义：
   1. 页内的记录是按照主键大小的顺序排成一个单向链表。
   2. 每个存放数据记录的页也是根据页中数据记录的主键大小顺序排成一个双向链表。
   3. 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的主键大小顺序排成一个双向链表。
2. B+树的叶子节点存储的是完整的数据记录，所谓完整的数据记录，就是指这个记录中存储了所有列的值（包括隐藏列）。

我们把具有这两种特性的B+树称为聚簇索引，所有完整的数据记录都存放在这个聚簇索引的叶子节点处。这种聚簇索引并不需要我们在MySQL语句中显式地使用INDEX语句去创建，InnoDB存储引擎会自动地为我们创建聚簇索引。

优点

• 数据访问更快，因为聚簇索引将索引和数据保存在同一个B+树中，因此从聚簇索引中获取数据比非聚簇索引更加的快。
• 聚簇索引对于主键的排序查找和范围查找速度非常快。
• 按照聚簇索引排列顺序，查询显示一定范围数据的时候，由于数据都是紧密相连，数据库不用从多个数据块中提取数据，所以节省了大量的io操作。

缺点

• 插入速度严重依赖于插入顺序，按照主键的顺序插入是最快的方式，否则将会出现页分裂，严重影响性能。因此，对于InnoDB表，我们一般都会定义一个自增的ID列为主键。
• 更新主键的代价很高，因为将会导致被更新的行移动。因此，对于InnoDB表，我们一般定义主键为不可更新。
• 二级索引访问需要两次索引查找 ，第一次找到主键值，第二次根据主键值找到行数据。

限制

• 对于MySQL数据库来说，目前只有InnoDB存储引擎支持聚簇索引，而MyISAM并不支持聚簇索引。
• 由于数据物理存储排序方式只能有一种，所以每个MySQL的表只能有一个聚簇索引。一般情况下就是该表的主键。
• 如果一个表没有定义主键，InnoDB会选择非空的唯一索引代替。如果没有这样的索引，InnoDB会隐式的定义一个主键来作为聚簇索引。
• 为了充分利用聚簇索引聚簇的特性，所以InnoDB表的主键列尽量选用有序的顺序id，而不建议用无序的id。比如UUID、MD5、HASH、字符串列作为主键从而无法保证数据的顺序增长。

二级索引（辅助索引、非聚簇索引）

上面说到的聚簇索引只能在搜索条件是主键的时候才能发挥作用，因为B+树中的数据都是按照主键进行排序的。那如果想要以别的列作为搜索条件怎么办呢？

我们可以多建几个B+树，不同的B+树中的数据采用不同的排序规则。比如用b列的大小作为数据页、页中记录的排序规则，再建立一个B+树，如下：

这个B+树和上面说到的聚簇索引有几个不一样的地方：

1. 使用记录b列的大小进行记录和页的排序，这包括三个方面的含义：
   1. 页内的记录是按照b列的大小顺序排成一个单向链表。
   2. 每个存放数据记录的页也是根据页中记录的b列的大小顺序排列成一个双向链表。
   3. 存放目录项记录的页分为不同的层次，在同一层次中的页也是根据页中目录项记录的b列大小顺序排成一个双向链表。
2. B+树的叶子节点存放的不是完整的数据记录，而只是b列+主键这两个列的值。
3. 目录项记录不再是主键+页号的搭配，而是变成了b列+页号。

所以如果现在想要通过b列的值查找某些记录的话就可以使用上面刚刚建好的这个B+树了。这里以查找b列的值为4的记录为例，其查找过程如下：

1. 确定目录项记录页：根据根页面，也就是页33，可以快速定位到目录项记录所在的页为页44（因为2<4<9）。
2. 通过目录项记录页确定数据记录真实所在的页：在页44中可以快速定位到实际存储数据记录的页，但是由于b列并没有唯一性约束，所以b列值为4的记录可能分布在多个数据页中，又因为2<4<=4，所以确定了实际的记录在页10和页47中.
3. 在实际存储数据记录的页中定位到具体的记录：在页10和页47中定位到具体的记录。
4. 回表：但是这个B+树的叶子节点中的记录只存储了b和a（主键）两个列，所以必须还要再根据主键值去聚簇索引中再查找一遍完整的数据记录。

回表

根据上面这个以b列大小排序的B+树只能确定要查找记录的主键值，所以如果想根据b列的值查找到完整的数据记录的话，仍然需要到聚簇索引中再查一遍，这个过程称为回表。也就是根据b列的值查询一条完整的数据记录需要使用到2个B+树。

为什么还需要一次回表操作呢？直接把完整的数据记录放到叶子节点不行吗？

如果把完整的数据记录放到叶子节点确实不用回表了。但是太耗费空间了，相当于每建立一个B+树都需要把所有的数据记录再都拷贝一遍。

因为这种按照非主键列建立的B+树需要一次回表操作才能定位到完整的数据记录，所以这样的B+树才会被称为二级索引，或者辅助索引。由于使用的是b列的大小作为B+树的排序规则，所以也称这个B+树是为b列建立的索引。

非聚簇索引的存在不影响数据在聚簇索引中的组织，所以一张表可以有多个非聚簇索引。

联合索引

也可以同时以多个列的大小作为排序规则，也就是同时为多个列建立索引，比如想让B+树按照b和c列的大小进行排序，这个包含两层含义：

• 先把每个记录和页按照b列进行排序。
• 在记录的b列相同的情况下，采用c列进行排序。

具体可以看下面的示意图：

如图所示，需要注意下面几点：

1. 每条目录项记录都是由b，c和页号这三个部分组成，每条记录先按照b列的值排序，如果记录的b列相同，则按照c列排序。
2. B+树叶子节点处的数据记录是由b，c，和主键a列组成的。

注意一点：以b和c列的大小为排序规则建立的B+树称为联合索引，本质上也是一个二级索引。但是和分别为b，c列建立一个二级索引是不同的，具体如下：

• 建立联合索引只会建立如上图一样的1个B+树。
• 为b和c列分别建立二级索引会分别以b和c列的大小为排序规则建立2个B+树。

InnoDB的B+树索引的注意事项

根页面万年不动

在上面介绍B+树索引的时候，是先把数据记录的叶子节点画出来，然后接着往上推画出存储目录项记录的内节点，但是实际上B+树的形成过程是下面这样的：

1. 每当为某个表创建一个B+树索引（聚簇索引不是人为创建的，是默认就有的）的时候，都会为这个索引创建一个根节点页面。一开始表中没有数据的时候，每个B+树对应的根节点中既没有数据记录，也没有目录项记录。
2. 随后向表中插入数据记录的时候，先把数据记录存储到这个根节点中。
3. 当根节点中的可用空间使用完之后继续插入记录，此时会将根节点中的所有记录复制到一个新分配的页，比如页a中，然后对这个新页进行页分裂操作，得到另外一个新页页b，这个时候新插入的记录根据键值（也就是聚簇索引中的主键值，二级索引中对应的索引列的值）的大小就会被分配到页a或者页b中，而根节点便升级为存储目录项记录的页。

特别注意：一个B+树索引的根节点从诞生开始，便不会再移动。这样只要对某个表建立一个索引，那么它的根节点的页号便会被记录到某个地方，然后凡是InnoDB存储引擎需要用到这个索引的时候，都会从这个固定的地方取出根节点的页号，从而使用这个索引。

内节点中目录项记录的唯一性

上面说到了B+树索引的内节点中目录项记录的内容是索引列+页号的搭配，但是这个搭配对于二级索引来说不太严谨，还是以上面的index_demo表为例，假设这个表中的数据是这样的：

如果二级索引中目录项记录的内容只是索引列+页号的话，那么为b列建立索引后B+树应该是如下这样：

如果这个时候想插入一个记录的话，比如列a、b、c的值分别为9、1、c，那么在修改这个为b列建立的B+树的时候会出现一个大问题：由于页5中存储的目录项记录是由b列+页号组成的，页5中的两条目录项记录对应的b列的值都是1，而新插入的这个数据的b列也是1，那么这个数据应该放到页11还是页29中呢？

为了解决这个问题，也就是能确定新插入的记录应该插入到哪个页中，则需要保证在B+树的同一层内节点的目录项记录除了页号这个字段以外是唯一的。所以对于二级索引的内节点的目录项记录的内容实际上是由三个部分构成的：

1. 索引列的值
2. 主键值
3. 页号

也就是把主键值也添加到二级索引内节点的目录项记录了，这样就可以保证B+树每一层节点中每条目录项记录除页号这个字段以外是唯一的，所以为b列建立的二级索引实际上应该是这样子的：

这样的话再插入记录（9，1，'c'）的时候，由于页5中存储的目录项记录都是由b列+主键+页号的值构成的，可以先把新纪录的b列的值和页5中每个目录项记录的b列值做比较，相同的话，接着再比较主键值，因为B+树同一层中不同目录项记录b列+主键值肯定是不一样的，所以最后肯定能定位唯一的一条目录项记录。最后，上面说到的问题，这个新加入的记录应该被插入到页29中。

一个页最少存储2条记录

一个B+树只需要很少的层级就可以轻松存储数亿条记录，查询速度相当不错，这是因为B+树本质上就是一个大的多层级目录，每经过一个目录时都会过滤掉许多无效的子目录，直到最后访问到存储真实数据的目录。那如果一个大的目录中只存放一个子目录是什么样的效果呢？

也就是目录层级会非常之多，而且最后的那个存放真实数据的目录中只能存放一条记录。所以InnoDB的一个数据页至少可以存放两条记录。

MyISAM中的索引方案

B树索引适用的存储引擎如下：

索引/存储引擎	MyISAM	InnoDB	Memory
B-Tree索引	✅	✅	✅

即使多个存储引擎支持同一种类型的索引，但是它们的实现原理也是不一样的。InnoDB和MyISAM默认索引是B树索引，而Memory默认的索引是Hash索引。MyISAM引擎适用B+树作为索引的结构，叶子节点的data域存放的是数据记录的地址。

MyISAM索引的原理

上面我们说到了InnoDB中索引即数据，也就是说聚簇索引的那个B+树的叶子节点中已经把所有完整的数据记录都包含了，而MyISAM的索引方案虽然也是使用的树形结构，但是其索引和数据却是分开存储的：

• 将表中的记录按照记录的插入顺序单独存储在一个文件中，其被称为数据文件。这个文件并不划分为若干个数据页，而是有多少记录就往这个文件中存多少记录就可以了。由于插入数据的时候并没有刻意地按照主键大小排序，所以并不能在这些数据上使用二分法进行查找。
• 使用MyISAM存储引擎地表会把索引信息另外存储到一个称为索引文件的另外一个文件中。MyISAM会单独为表的主键创建一个索引，只不过在索引的叶子节点中存储的不是完整的数据记录，而是主键值+数据记录地址的组合。

下面是MyISAM索引的原理图：

这里假设表一共由三列，假设Col1是主键，上图就是MyISAM表的主索引，从图中可以看出MyISAM的索引文件仅仅保存数据记录的地址。在MyISAM中，主键索引和二级索引在结构上没有任何的区别，只是主键索引要求key是唯一的，而二级索引的key则可以重复。如果在Col2上建立一个二级索引，则结构如下：

同样都是一个B+树，data域保存数据记录的地址。因此MyISAM中索引检索的算法是：

1. 首先按照B+树搜索算法搜索索引，如果指定的Key存在，则取出其data域的值，然后用data域的值为地址，读取相应的数据记录。

MyISAM和InnoDB对比

MyISAM的索引方式都是非聚簇的，和InnoDB包含1个聚簇索引是不同的。两种引擎中索引的区别：

1. 在InnoDB存储引擎中，我们只需要根据主键值对聚簇索引进行一次查找就能找到对应的记录，而在MyISAM中却需要进行一次回表操作，意味着MyISAM中建立的索引相当于全部都是二级索引。
2. InnoDB的数据文件本身就是索引文件，而MyISAM索引文件和数据文件是分离的 ，索引文件仅保存数据记录的地址。
3. InnoDB的非聚簇索引的data域存储相应记录主键的值，而MyISAM索引记录的是地址。换句话说，InnoDB的所有非聚簇索引都引用主键作为data域。
4. MyISAM的回表操作是十分快速的，因为是拿着地址偏移量直接到文件中取数据的，反观InnoDB是通过获取主键之后再去聚簇索引里找记录，虽然说也不慢，但还是比不上直接用地址去访问。
5. InnoDB要求表必须有主键，而MyISAM可以没有。如果没有显式指定，则MySQL系统会自动选择一个可以非空且唯一标识数据记录的列作为主键。如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整型。

总结

通过上面的了解，我们知道了InnoDB的索引实现之后：

1. 举例1：很容易明白为什么不建议使用过长的字段作为主键，因为所有二级索引都引用主键索引，过长的主键索引会使二级索引变得非常大。
2. 举例2：用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一个B+树，非单调的主键会造成在插入新纪录的时候，数据文件为了维持B+树的特性而频繁的分裂调整，十分低效，所以使用自增字段作为主键却是一个很好的选择。

索引的代价

索引虽然是个好东西，但是并不能随便建，它在空间和时间上都有一定的消耗：

1. 空间上的代价：每建立一个索引都要为它建立一个B+树，每一个B+树的每一个节点都是一个数据页，一个页默认会占用16kb的存储空间，一个很大的B+树由许多数据页组成，也就是很大的一片存储空间。
2. 时间上的代价：每次对表中的数据进行增、删、改操作时。都需要修改每个B+树索引。且上面说到了B+树的每一层节点都是按照索引列值从小到大顺序排序组成的双向链表。不论是叶子节点中的记录，还是内节点中的记录都是按照索引列的值从小到大的顺序形成的单向链表。而增、删、改操作可能会对节点和记录的排序造成破坏，所以存储引擎需要额外的时间进行一些记录移位、页面分裂、页面回收等操作来维护好节点和记录的排序。如果我们建立了许多索引，每个索引对应的B+树都要进行相关的维护操作，会给性能拖后腿。

MySQL数据结构选择的合理性

从MySQL的角度来说，不得不考虑的一个现实问题就是磁盘I/O。如果能让索引的数据结构尽量减少硬盘的I/O操作，所消耗的时间也就越小。可以说磁盘的I/O操作次数对索引的使用效率至关重要。

查找都是索引操作，一般来说索引非常大，尤其是关系型数据库，当数据量比较大的时候，索引的大小有可能几个G甚至更多，为了减少索引在内存中的占用，数据库索引是存储在外部磁盘上的。当利用索引查询的时候，把索引全部加载到内存是不现实的，所以只能逐一加载，那么MySQL衡量查询效率的标准就是磁盘IO次数。

Hash结构

Hash本身是一个函数，又被称为散列函数，它可以帮助我们大幅提升检索数据的效率。Hash算法是通过某种确定性的算法（比如MD5、SHA1、SHA2、SHA3）将输入变成输出。相同的输入永远可以得到相同的输出，假设输入内容有微小偏差。在输出中通常会有不同的结果。比如想要验证两个文件是否相同，那么不需要把两份文件拿来对比，只需要用Hash函数计算出对应的结果，然后对比两个文件的计算结果即可。

加速查询速度的数据结构，常见的有两类：

• 树：比如平衡二叉搜索树。查询、插入、修改、删除的平均时间复杂度都是$O(log_2^N)$。
• 哈希：比如HashMap，查询、插入、修改、删除的平均时间复杂度都是$O(1)$。

采用Hash进行查询的效率非常高，基本上一次查询就可以找到数据，而B+树需要自顶向下一次查找，多次访问节点才能找到数据，中间需要多次IO操作，从效率来说Hash比B+树更快。

既然Hash结构的效率这么高，那为什么MySQL的索引结构还要设计成树形的呢？

1. Hash索引仅能满足（=、<、>、IN）查询。如果进行范围查询，哈希型的索引，时间复杂度会退化为$O(N)$，而树形的有序特性，依然可以保持$O(log_2^N)$的高效率。
2. Hash索引还有一个缺陷，数据的存储是没有顺序的，在ORDER BY的情况下，使用Hash索引还需要对数据重新排序。
3. 对于联合索引的情况，Hash值是将联合索引键合并之后一起计算的，无法对单独的一个键或者几个索引键进行查询。
4. 对于等值查询来说，通常Hash索引的效率更高，不过也存在一种情况，就是索引列的重复值如果很多（Hash冲突），效率就会降低。这是因为遇到Hash冲突时，需要遍历桶中的行指针来进行比较，找到查询的关键字，非常耗时。所以Hash索引通常不会用到重复值多的列上，比如列为性别、年龄的情况等。

Hash索引适用的存储引擎

Hash索引的适用性

Hash索引存在着很多的限制，相比之下在数据库中B+树索引的使用面会更广，不过也有一些场景采用Hash索引效率更高，比如在键值型（key-value）数据库中（Redis存储的核心就是Hash表）。

MySQL中的Memory存储引擎支持Hash索引，如果我需要用到查询临时表时，就可以选择Memory存储引擎，把某个字段设置为Hash索引，比如字符串类型的字段，进行Hash计算后长度可以缩短到几个字节。当字段的重复度低，而且经常需要进行等值查询的时候，采用Hash索引是个不错的选择。

另外InnoDB本身不支持Hash索引，但是提供自适应Hash索引（Adaptive Hash Index）。如果一个数据经常被访问，当满足一定条件时候，就会将这个数据页的地址存放到Hash表中。这样下次查询的时候，就可以直接找到这个页面所在的位置。这样让B+树也具备了一定的Hash索引的优点。

采用自适应Hash索引的目的是方便根据SQL的查询条件加速定位到叶子节点，特别是B+树比较深的时候，通过自适应Hash索引可以明显提高数据的检索效率。

可以通过innodb_adaptive_hash_index变量来查看是否开启了自适应Hash索引，比如：

mysql> SHOW variables LIKE '%adaptive_hash_index';+----------------------------+-------+| Variable_name              | Value |+----------------------------+-------+| innodb_adaptive_hash_index | ON    |+----------------------------+-------+1 row in set (0.01 sec)

二叉搜索树

//TODO

在《MySQL-逻辑架构》这篇文章中我们知道，MySQL服务端主要有查询缓存、语法解析、连接池、优化器这写模块。执行SQL时，是按照优化器生成的执行计划来执行的。实际上是根据这个计划调用存储引擎的API来执行的，最后返回结果就行了。

MySQL中有存储引擎这样一个概念，简单来说就是指表的类型。存储引擎在以前都是叫做表处理器，只是后来才改名叫做存储引擎。其主要功能就是接收命令，然后对表进行读写操作。这里以MySQL8.0.31为例，我们可以使用SHOW engines;来查看MySQL中的存储引擎。

mysql> SHOW engines;+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| ndbcluster         | NO      | Clustered, fault-tolerant tables                               | NULL         | NULL | NULL       || FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       || MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         || InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        || PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         || MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         || ndbinfo            | NO      | MySQL Cluster system information storage engine                | NULL         | NULL | NULL       || MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         || BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         || CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         || ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+11 rows in set (0.00 sec)

设置存储引擎

设置系统默认存储引擎

我们可以使用下面两个命令来查看默认的存储引擎：

• SHOW variables LIKE '%storage_engine%';：

  mysql> SHOW variables LIKE '%storage_engine%';+---------------------------------+-----------+| Variable_name                   | Value     |+---------------------------------+-----------+| default_storage_engine          | InnoDB    || default_tmp_storage_engine      | InnoDB    || disabled_storage_engines        |           || internal_tmp_mem_storage_engine | TempTable |+---------------------------------+-----------+4 rows in set (0.00 sec)

• SELECT @@default_storage_engine;：

  mysql> SELECT @@default_storage_engine;+--------------------------+| @@default_storage_engine |+--------------------------+| InnoDB                   |+--------------------------+1 row in set (0.00 sec)

如果在创建表的语句中没有显式指定表的存储引擎的话，那就会默认使用InnoDB作为表的存储引擎。 如果我们想改变表的默认存储引擎的话，可以使用下面的命令：

mysql> SET DEFAULT_STORAGE_ENGINE=MyISAM;Query OK, 0 rows affected (0.00 sec)mysql> SELECT @@default_storage_engine;+--------------------------+| @@default_storage_engine |+--------------------------+| MyISAM                   |+--------------------------+1 row in set (0.00 sec)

或者修改配置文件：

default-storage-engine=MyISAM

修改配置文件后需要重启MySQL。

设置表的存储引擎

存储引擎是负责对表中的数据进行提取和写入工作的，我们可以为不同的表设置不同的存储引擎 ，也就是说不同的表可以有不同的物理存储结构，不同的提取和写入方式。

创建表时指定存储引擎

当我们创建表的时候没有指定表的存储引擎，那么MySQL的表默认会使用InnoDB。但是如果想要指定存储引擎则可以这样写：

CREATE TABLE 表名(建表语句;) ENGINE = 存储引擎名称;

修改表的存储引擎

对于已经创建好的表，则可以这样修改表的存储引擎：

ALTER TABLE 表名 ENGINE = 存储引擎名称;

存储引擎简介

前面我们看到了一堆的存储引擎，它们分别有什么作用呢？这里简单介绍一下。

1. InnoDB引擎：具备外键支持功能的事务存储引擎。
2. MyISAM引擎：主要的非事务处理存储引擎。
3. Archive引擎：用于数据存档。
4. Blackhole引擎：丢弃写操作，读操作会返回空内容。
5. CSV引擎：存储数据时，以逗号分隔各个数据项。
6. Memory引擎：置于内存的表。
7. Federated引擎：访问远程表。
8. Merge引擎：管理多个MyISAM表构成的表集合。
9. NDB引擎：MySQL集群专用存储引擎。

引擎对比

MySQL中同一个数据库，不同的表可以选择不同的存储引擎。如下表对常用存储引擎做出了对比：

MyISAM和InnoDB

MyISAM和InnoDB到底选择哪个比较好呢？

MySQL5.5之前的默认存储引擎是MyISAM，之后改为了InnoDB。下面让我们对比下二者：

在《MySQL-逻辑架构》这篇文章中说到了MySQL的逻辑架构，那么MySQL的SQL执行流程是怎么样的呢？

从MySQL的逻辑架构可以看出MySQL中的SQL执行流程可以是这样的：

MySQL查询的执行流程

1.查询缓存

因为查询缓存的效率并不高，所以在后面的版本（MySQL8.0）之后就抛弃了这个功能。

MySQL收到一个查询请求之后，会先查询缓存看看之前是否执行过这条语句。相当于将之前执行的SQL以及结果以key-value的形式缓存在内存中，key就是查询SQL，value就是查询的结果。

• 如果在缓存中查询到了这个SQL，那么缓存中的结果就会直接返回给客户端。
• 如果在缓存中没有查询到这个SQL，那么就会继续后面的执行，执行完成后，本次查询也会被保存在缓存中去。

为什么MySQL8.0之后要抛弃缓存呢？

1. 在MySQL中缓存的不是查询计划，而是将查询的结果缓存。也就是说只有完全相同的查询操作才会命中缓存。比如两个查询SQL在任何字符上的不同（空格、注释、大小写等），都会导致缓存不能命中。所以MySQL中的缓存命中率并不高。比如下面两个SQL就是不同的，第二个SQL比第一个多出了一个空格：

   SELECT id FROM t_user;SELECT id FROM  t_user;

2. 如果查询SQL中包含某些系统函数、用户自定义变量以及函数、系统表（比如mysql、information_schema、performance_schema库中的表），那这个SQL是不会被缓存的。

   比如系统函数NOW()，每次调用都是获取最新的当前时间，想象一下，如果缓存了这个结果，那么第二次命中的时候，那应该返回什么呢？

3. 既然是缓存，那缓存都是由失效时间的。MySQL的缓存系统会检测涉及到的每一张表，只要该表的结构或者数据被修改，比如使用了INSERT、UPDATE、DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或者DROP DATABASE等语句，那么涉及到该表的所有缓存都将变为无效并从缓存中删除。对于更新修改较多的数据库来说，这样的缓存命中率将会非常低。

什么时候使用缓存比较好？

一般建议在静态表使用缓存，静态表一般指极少更新的表，比如系统的配置表、字典表。MySQL提供了选择按需使用缓存的方式，可以将my.cnf（配置文件）中的配置query_cache_type设置为DEMAND，表示当SQL语句中有SQL_CACHE关键词的时候才会缓存。配置如下：

# 0：关闭查询缓存# 1：表示开启查询缓存# 2：表示按需使用即上面说到的DEMANDquery_cache_type=2

在SQL中则这样使用：

SELECT SQL_CACHE * FROM dict WHERE id = 5

2.解析器

在解析中对SQL语句进行语法分析、语义分析。

1. 词法分析：首先MySQL需要识别出来SQL语句中的字符串分别是什么，代表什么。比如MySQL从SELECT这个关键字识别出来，这是一个查询SQL。

2. 语法分析：根据词法分析的结果，语法解析器（比如Bison）会根据语法规则，判断这个SQL语句是否满足MySQL的语法。

   1. 如果语句有问题，那么就会收到You have an error in your SQL syntax错误，比如下面这样：

      mysql> SELECT * FRO test;ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FRO test' at line 1

   2. 如果语句是没有问题的，则会生成这样的一个语法树：

下面则是解析器分析SQL的过程和步骤：

3.优化器

在优化器中会确定SQL语句的执行路径，比如是根据全表检索还是根据索引检索等等。经过了上面的解析器，MySQL就已经知道这个SQL是做什么的了。在开始执行之前，还需要经过优化器的处理。

一条SQL可以有很多种执行方式，最后都会返回相同的结果。优化器的作用就是找到这些执行方式中最好的一个。比如：

• 优化器在表里面有多个索引的时候，决定使用哪个索引。
• 在一个SQL有多表关联（JOIN）的时候决定每个表的连接顺序。
• 还有表达式简化、子查询转为连接、外连接转为内连接等等。

比如下面的这个SQL中有两个表的JOIN：

SELECT * FROM t_user JOIN t_order ON t_user.id = t_order.idWHERE t_user.username='张三' and t_order.order_no='2022013000001';

• 方案1：可以先从t_user表里面查询出username=='张三'的记录的ID，然后再根据ID关联到表t_order，再判断t_order中的order_no是否等于2022013000001。
• 方案2：可以先从t_order表里面查询出order_no='2022013000001'的记录的ID，然后再根据ID关联到表t_user，再判断t_user中的username是否等于张三。

上面两个执行方法的逻辑结果都是一样的，但是执行的效率会不同，而优化器的作用就是决定使用哪一种方案。优化器阶段完成后，这个SQL的执行方案也就确定下来了，最后进入执行器的阶段。

在优化器中又可以分为逻辑查询优化阶段以及物理查询优化阶段：

1. 逻辑查询优化：就是通过改变SQL语句的内容来是SQL查询更加高效，同时为物理查询优化提供更多的候选执行计划。通常采用的方式则是对SQL语句进行等价变换，对查询进行重写，而查询重写的数学基础就是关系代数。对条件表达式进行等价谓词重写、条件简化，对视图进行重写，对子查询进行优化，对连接语义进行了外连接消除、嵌套连接消除等等。
2. 物理查询优化：是基于关系代数进行的查询重写，而关系代数的每一步都对应着物理计算，这些物理计算往往存在多种算法，因此需要计算各种物理路径的代价，从中选择代价最小的最为执行计划。在这个阶段里面，对于单表和多表连接的操作，需要高效地使用索引来提升查询效率。

4.执行器

截止到这里，还没实际地读写真实的表，仅仅只是产出了一个执行计划。所以这里就进入了执行器的阶段。

在实际执行之前需要判断用户是否具备相应的权限。如果没有权限则返回错误，如果有权限则执行并返回结果（在MySQL8.0之前如果设置开启了缓存，这里还会将结果缓存起来）。

如果有权限，则打开表继续执行。打开表的时候，执行器就会根据表定义的引擎，调用存储引擎的API对表进行读写。存储引擎API只是抽象的接口，其下面还有一个存储引擎层，具体实现还是要看表选择的存储引擎。

比如在表t_user中，id字段没有索引，那么执行器的执行流程是：

1. 调用存储引擎的API获取这个表的第一行，判断id是不是1，如果不是则跳过，如果是则保存这行到结果集中。
2. 调用存储引擎的API获取下一行，重复和第1步相同的判断逻辑，直到获取到最后一行。
3. 执行器将上面所有满足条件的行组成结果集返回给客户端。

执行流程简单总结

根据上面可以得出，SQL语句在MySQL中的流程可以简单的表示为SQL语句->查询缓存->解析器->优化器->执行器：

SQL执行原理

上面的结构图很复杂，我们只需要获取最核心的部分：SQL的执行原理。不同的DBMS的SQL执行原理是相通的，只是各有各的实现路径。下面将分别从MySQL8.0以及MySQL5.7来说明MySQL的SQL执行原理。

MySQL8.0

既然一条SQL语句在MySQL服务中会经过不同的模块，那就让我们来看看在不同的模块中，SQL执行所使用的资源（时间）是怎么样的？如何在MySQL中对一条SQL语句的执行时间进行分析？

1.确认profiling是否开启

使用SELECT @@profiling;或者SHOW variables LIKE 'profiling';查看是否开启计划。开启计划可以使MySQL收集在SQL执行时所使用的资源情况，比如下面这样可以查看：

mysql> SELECT @@profiling;+-------------+| @@profiling |+-------------+|           0 |+-------------+1 row in set, 1 warning (0.00 sec)mysql> SHOW variables LIKE 'profiling';+---------------+-------+| Variable_name | Value |+---------------+-------+| profiling     | OFF   |+---------------+-------+1 row in set (0.00 sec)

可以看到默认profiling是等于0的，也就是关闭的，如果需要打开，那么修改为1即可：

mysql> SET profiling=1;Query OK, 0 rows affected, 1 warning (0.00 sec)mysql> SELECT @@profiling;+-------------+| @@profiling |+-------------+|           1 |+-------------+1 row in set, 1 warning (0.00 sec)mysql> SHOW variables LIKE 'profiling';+---------------+-------+| Variable_name | Value |+---------------+-------+| profiling     | ON    |+---------------+-------+1 row in set (0.00 sec)

2.多次执行相同SQL查询

然后在这里任意执行一个SQL查询：

SELECT * FROM user

3.查看profiles

查看当前会话所产生的所有profiles：

mysql> SHOW profiles;+----------+------------+-----------------------+| Query_ID | Duration   | Query                 |+----------+------------+-----------------------+|        1 | 0.00017025 | SELECT @@profiling    ||        2 | 0.00077750 | SHOW databases        ||        3 | 0.00014850 | SELECT DATABASE()     ||        4 | 0.00173225 | SHOW tables           ||        5 | 0.00050050 | SELECT * FROM user    ||        6 | 0.00034925 | SELECT * FROM user    |+----------+------------+-----------------------+

4.查看profile

显示执行计划，查看程序的执行步骤，使用SHOW profile查看：

mysql> SHOW profile;+--------------------------------+----------+| Status                         | Duration |+--------------------------------+----------+| starting                       | 0.000075 || Executing hook on transaction  | 0.000005 || starting                       | 0.000007 || checking permissions           | 0.000005 |//权限检查| Opening tables                 | 0.000051 |//打开表| init                           | 0.000005 |//初始化| System lock                    | 0.000008 |//锁系统| optimizing                     | 0.000004 |//优化查询| statistics                     | 0.000015 |//统计| preparing                      | 0.000018 |//准备| executing                      | 0.000096 |//执行| end                            | 0.000004 || query end                      | 0.000003 || waiting for handler commit     | 0.000009 || closing tables                 | 0.000009 || freeing items                  | 0.000027 || cleaning up                    | 0.000010 |+--------------------------------+----------+17 rows in set, 1 warning (0.00 sec)

也可以查询指定的Query ID，比如：

mysql> SHOW profile for QUERY 6;+--------------------------------+----------+| Status                         | Duration |+--------------------------------+----------+| starting                       | 0.000075 || Executing hook on transaction  | 0.000005 || starting                       | 0.000007 || checking permissions           | 0.000005 || Opening tables                 | 0.000051 || init                           | 0.000005 || System lock                    | 0.000008 || optimizing                     | 0.000004 || statistics                     | 0.000015 || preparing                      | 0.000018 || executing                      | 0.000096 || end                            | 0.000004 || query end                      | 0.000003 || waiting for handler commit     | 0.000009 || closing tables                 | 0.000009 || freeing items                  | 0.000027 || cleaning up                    | 0.000010 |+--------------------------------+----------+17 rows in set, 1 warning (0.00 sec)

查询 SQL 的执行时间结果和上面是一样的。 此外，还可以查询更丰富的内容：

mysql> SHOW profile cpu,block io for QUERY 6;+--------------------------------+----------+----------+------------+--------------+---------------+| Status                         | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |+--------------------------------+----------+----------+------------+--------------+---------------+| starting                       | 0.000075 | 0.000050 |   0.000024 |            0 |             0 || Executing hook on transaction  | 0.000005 | 0.000004 |   0.000000 |            0 |             0 || starting                       | 0.000007 | 0.000001 |   0.000006 |            0 |             0 || checking permissions           | 0.000005 | 0.000005 |   0.000000 |            0 |             0 || Opening tables                 | 0.000051 | 0.000033 |   0.000018 |            0 |             0 || init                           | 0.000005 | 0.000000 |   0.000005 |            0 |             0 || System lock                    | 0.000008 | 0.000007 |   0.000001 |            0 |             0 || optimizing                     | 0.000004 | 0.000004 |   0.000000 |            0 |             0 || statistics                     | 0.000015 | 0.000009 |   0.000006 |            0 |             0 || preparing                      | 0.000018 | 0.000012 |   0.000006 |            0 |             0 || executing                      | 0.000096 | 0.000060 |   0.000036 |            0 |             0 || end                            | 0.000004 | 0.000004 |   0.000000 |            0 |             0 || query end                      | 0.000003 | 0.000000 |   0.000003 |            0 |             0 || waiting for handler commit     | 0.000009 | 0.000006 |   0.000003 |            0 |             0 || closing tables                 | 0.000009 | 0.000003 |   0.000006 |            0 |             0 || freeing items                  | 0.000027 | 0.000020 |   0.000006 |            0 |             0 || cleaning up                    | 0.000010 | 0.000004 |   0.000006 |            0 |             0 |+--------------------------------+----------+----------+------------+--------------+---------------+17 rows in set, 1 warning (0.00 sec)

MySQL5.7

在Mysql5.7中重复上面的操作，发现前后两次相同的sql语句，其执行的查询过程仍然是相同的。并没有使用到之前说的缓存，这是怎么回事呢？

这里我们需要显式开启查询缓存模式。在MySQL5.7中如下设置：

1. 修改配置文件，在my.cnf中新增一行：

   # 0：关闭查询缓存# 1：表示开启查询缓存# 2：表示按需使用即上面说到的DEMANDquery_cache_type=1

   这里我们直接设置全部开启即可。

2. 重启mysql服务。

然后我们重复上面8.0的操作，分别查看两个完全相同的SQL的profile，即可看见使用到了缓存。

MySQL是一个典型的C/S架构，也就是Client/Server结构，服务端就是mysqld。不论客户端进程和服务器进程是采用的哪种方式通信，最后实现的效果都是：客户端进程向服务器进程发送一段文本（SQL语句），服务器进程处理后再向客户端进程发送一段文本（处理结果）。

这里以一个查询请求作为实例，MySQL服务端处理请求的流程图如下：

上面我们列举了一个MySQL查询的流程图，那么MySQL的具体的逻辑架构图如下：

连接器（Connectors)

Connectors指的就是不同编程语言中和SQL的交互。MySQL首先是一个网络应用程序，在TCP之上定义了自己的应用层协议。所以要使用MySQL，我们可以编写代码和MySQL建立TCP连接，之后按照其定义好的协议进行交互。或者比较方便的办法就是调用SDK，比如Native API、JDBC、PHP等各个语言的MySQL Connector，或者通过ODBC。但是通过SDK来访问MySQL，本质上还是在TCP连接上通过MySQL的协议来和其交互。

MySQL服务端结构

从上面的图中我们可以看到MySQL服务端的结构大致可以分为连接层、服务层以及引擎层这三层。

连接层

客户端访问MySQL服务器之前，首先第一件事就是建立TCP连接，当经过三次握手连接建立成功后，MySQL服务器对TCP传输过来的账号密码做身份认证、权限获取。

• 用户名或密码不对：客户端会收到一个Access denied for user错误，客户端程序结束执行。
• 用户名和密码正确：会从权限表查出账号拥有的权限和连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限。

那么一个系统只能和MySQL服务建立一个连接吗？只能有一个系统和MySQL服务建立连接吗？

答案是否定的，多个系统都可以和MySQL建立连接，每个系统建立的连接当然也不只是一个。所以为了解决TCP连接的无限创建和TCP频繁创建销毁带来的资源开销以及性能下降等问题，MySQL服务使用了TCP连接池来限制连接数量，采用长连接模式复用TCP连接。

TCP连接收到请求后，必须要分配一个线程专门和客户端交互。所以还会有一个线程池，来完成后面的流程。每个连接从线程池中获取线程，节省了创建和销毁线程的开销。

以上的内容都可以归纳到MySQl的连接层中。所以连接层的职责就是负责认证、管理连接、获取权限信息。

服务层

服务层主要是来完成大多数的核心功能的，比如SQL接口、查询缓存、SQL的分析和优化以及部分内置函数的执行。所有跨存储引擎的功能也在服务层实现，比如过程以及函数等。

在服务层中，MySQL服务会解析查询并且创建相应的内部解析树，对其完成相应的优化：比如确定查询表的顺序，是否利用索引等，最后生成相应的执行操作。

如果是SELECT语句，服务器还会查询内部的缓存。如果缓存空间足够大，这样在解决大量读操作的环境中能很好的提升性能。

SQL Interface（SQL接口）

• 接收用户的SQL命令，并且返回用户需要查询的结构。比如SELECT...FROM...就是调用的SQL Interface。
• MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口。

Parser（解析器）

• 在解析器中对SQL语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的。
• 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法后，MySQL还会对SQL查询进行语法上的优化，进行查询重写。

Optimizer（查询优化器）

• SQL语句在语法解析之后、查询之前会使用Optimizer（查询优化器）来确定SQL语句的执行路径，生成一个执行计划。

• 这个执行计划表明应该使用哪些索引来查询（全表检索或索引检索）、表之间的连接顺序如何。最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并且将结果返回给用户。

• 使用选取-投影-连接策略进行查询。比如：

  SELECT id,name FROM t_user WHERE age = 18;

  1. 选取：先根据WHERE进行选取，而不是将表全部查询出来以后再过滤。
  2. 投影：先根据id和name进行属性投影，而不是将属性全部查询出来之后再过滤掉。
  3. 连接：将上面两个条件连接起来生成最终的查询结果。

Caches & Buffers（缓存组件）

• MySQL内部维护着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果。如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化以及执行的整个过程了，会直接将结果返回给客户端。
• 这个缓存机制是由一系列小缓存组成的：比如表缓存、记录缓存、key缓存、权限缓存等等。
• 缓存是可以在不同的客户端之间共享的。

🚨从MySQL5.7.20开始，不再推荐使用查询缓存，并且在MySQL8.0中删除了这个机制。

引擎层

和其他的数据库相比，MySQL有一点与众不同，它的架构可以在多种不同的场景中应用并且发挥良好的作用，主要体现在存储引擎的架构上，插件式的存储引擎架构将查询处理和其他的系统任务以及数据的存储相分离。这种架构可以根据业务的需求以及实际需要选择适合的存储引擎。同时开源的MySQL还允许开发人员开发自己的存储引擎。

插件式的存储引擎层，真正地负责了MySQL中数据地存储和提取，对物理服务器级别维护的底层数据执行操作。服务器通过API与存储引擎进行通信，而不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。

在MySQL8.0.31中默认支持的存储引擎如下：

mysql> SHOW ENGINES;+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+| ndbcluster         | NO      | Clustered, fault-tolerant tables                               | NULL         | NULL | NULL       || FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       || MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         || InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        || PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         || MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         || ndbinfo            | NO      | MySQL Cluster system information storage engine                | NULL         | NULL | NULL       || MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         || BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         || CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         || ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+11 rows in set (0.00 sec)

存储层

所有的数据、数据库/表的定义、表的每一行内容、索引都是存在文件系统上的，以文件的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB，也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使这样做没有必要了。在文件系统之下，可以使用本地磁盘，也可以使用DAS、NAS、SAN等各种存储系统。

总结

开篇提到的架构图可以简化为下面这样：

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件，主要以流量为切入点，从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。

基本概念

资源

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

规则

围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

Sentinel的组件由两个部分组成

核心库（客户端）

不依赖任何框架/库，能够运行于所有的Java环境，同时对Dubbo/SpringCloud等框架也有较好的支持。

控制台（Dashboard）

基于SpringBoot开发，打包后可以直接运行，不需要额外的Tomcat等应用容器。

流控规则

• 资源名：唯一名称，默认请求路径。
• 针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认为default（不区分来源）。
• 阈值类型/单机阈值：
  • QPS（每秒的请求数量）：当调用该API的QPS达到阈值的时候，进行限流。
  • 线程数：当调用该API的线程数达到阈值的时候，进行限流。
• 是否集群：不需要集群
• 流控模式：
  • 直接：API达到限流条件的时候，直接限流。
  • 关联：当关联的资源达到阈值的时候，就限流自己。
  • 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）【API级别的针对来源】。
• 流控效果：
  • 快速失败：直接失败，抛异常。
  • Warm Up：根据codeFactor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长。大达到设置的QPS阈值。
  • 排队等候：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效。

降级规则

• RT（平均响应时间，秒级）：平均响应时间超出阈值且在时间窗口内通过的请求>=5，两个条件同时满足后触发降级。窗口期过后关闭断路器，RT最大4900（更大的需要通过-Dcsp.sentinel.statistic.max.rt=xxxx 才能生效）。
• 异常比例（秒级）：QPS>=5异常比例（秒级统计）超过阈值时，触发降级；时间窗口结束后，关闭降级。
• 异常数（分钟级）：异常数（分钟统计）超过阈值时，触发降级；时间窗口结束后，关闭降级。

Sentinel熔断降级会在调用链路中的某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其他的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为时抛出DegradeException）。Sentinel的断路器是没有半开状态的。

半开状态即系统自动去检测是否请求有异常，没有异常就关闭断路器恢复使用，有异常则继续打开断路器。

首先是来自Redis官网的分布式锁的说明：

在不同进程必须以互斥的方式使用共享资源的环境中，分布式锁是一个非常有用的元素。

有许多库和博客文章描述如何使用Redis实现DLM（分布式锁管理器），但每个库都使用不同的方法，并且许多库使用简单的方法。与稍微复杂的方法相比，保证较低的设计。

我们提出了一种名为Redlock的算法，它实现了一个DLM，我们认为比普通的单实例方法更安全。我们希望社区能够对其进行分析、提供反馈，并将其用作实现更复杂或替代设计的起点。

为什么基于故障转移的实现是不够的？

在《Redis实现分布式锁》这篇文章中，自己实现了一个分布式锁，但是还是存在一定的问题。Redis官网是这样说的。

让我们分析一下大多数基于Redis的分布式锁库的当前情况：

使用Redis锁定资源的最简单方法是在实例中创建一个键。通常使用Redis过期功能创建带有有限存活时间的键，以便最终会释放它。当客户端需要释放资源时，它会删除该键。

表面上这很有效，但存在一个问题：就是架构中的单点故障。如果Redis主服务器崩溃会怎样呢？那就添加一个副本！并在主服务器不可用时使用它。但不幸的是，通过这样做，我们无法实现互斥的安全属性，因为Redis复制是异步的。

这个模型存在竞争条件：

1. 客户端A在主服务器上获取锁。
2. 写入键的过程在传输到副本之前，主服务器崩溃了。
3. 副本被提升为主服务器。
4. 客户端B获取了与客户端A持有的同一资源的锁。安全性被破坏！

有时，在特殊情况下，例如在出现故障时，多个客户端同时持有锁是完全可以接受的。如果是这种情况，则可以使用基于复制的解决方案。否则，我们建议实现本文档中描述的解决方案。

简单说就是：线程A首先获取锁成功了，将键写入了Redis的Master，但是在Master同步数据到Slave之前，Master宕机了。这个时候触发了故障转移，Slave成为新的Master（但是这个Slave并没有之前线程A写入的键），此时线程B来了，尝试获取锁，因为Slave中没有之前线程A写入的键，所以这里线程B理所当然的获取到了锁。那么这时问题出现了，线程A和线程B同时获取到了锁。

RedLock的算法设计理念

Redis提供了RedLock算法，用来实现基于多个实例的分布式锁。锁变量由多个实例维护，即使有实例发生了故障，锁变量任然时存在的，客户端还是可以完成锁操作。RedLock算法是实现高可靠分布式锁的一种有效解决方案，可以在实际开发中使用。

官网的介绍是：

在算法的分布式版本中，我们假设有N个Redis主节点。这些节点是完全独立的，因此我们不使用复制或任何其他隐式协调系统。我们已经描述了如何在单个实例中安全地获取和释放锁。我们认为算法将使用此方法在单个实例中获取和释放锁。在我们的示例中，我们将N设置为5，这是一个合理的值，因此我们需要在不同的计算机或虚拟机上运行5个Redis主节点，以确保它们以几乎独立的方式发生故障。

设计理念

该方案也是基于（SET加锁、Lua脚本解锁）进行改良的，所以大致方案如下：

假设有N个Redis主节点，例如N = 5，这些节点都是完全独立的，不使用复制或者任何其他隐式协调系统，为了获取到锁，客户端执行以下操作：

1. 以毫秒为单位获取当前时间。
2. 顺序尝试在所有N个实例中获取锁，使用相同的键名和随机值。在第2步中，设置每个实例中的锁时，客户端使用一个相对于总锁自动释放时间很小的超时时间来获取锁。例如，如果自动释放时间为10秒，则超时时间可以在 [5,50]毫秒范围内。这可以防止客户端尝试与已经宕机的Redis节点通信时长时间被阻塞：如果一个实例不可用，我们应该尽快尝试与下一个实例通信。
3. 客户端通过从步骤1中获取的时间戳中减去当前时间来计算获得锁所用的时间。当且仅当客户端能够在大多数实例（至少3个）中获得锁时，并且获得锁所用的总时间少于锁的有效时间时，才认为已经获得了锁。
4. 如果成功获得了锁，则其有效时间被视为初始有效时间减去步骤3中计算出的时间。
5. 如果客户端由于某种原因未能获得锁（无法锁定N/2+1实例或有效时间为负），则将尝试解锁所有实例（即使客户端认为自己无法锁定某些实例）。

该方案是为了解决数据不一致的问题，直接舍弃了异步复制而只是用Master节点，同时因为舍弃了Slave，又为了保证可用性，引入了N个节点。

Redisson介绍

Redisson是Java的Redis客户端之一，提供了一些API来方便的操作。它是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。一个基于Redis实现的分布式工具，有基本分布式对象和高级又抽象的分布式服务，为每个试图再造分布式轮子的程序员带来了大部分分布式问题的解决办法。

简单使用Redisson的分布式锁

GitHub上关于分布式锁的介绍

创建一个配置类

@Configurationpublic class RedissionConfig {    @Bean    public RedissonClient getRedisson() {        Config config = new Config();        config.useSingleServer().                setAddress("redis://127.0.0.1:6371").                setPassword("123456");        config.setCodec(new JsonJacksonCodec());        return Redisson.create(config);    }}

在业务代码中使用

@Resourceprivate RedissonClient redissonClient;@Overridepublic void deduct(Long id) {    RLock lock = redisson.getLock("LockName");    try{        lock.lock();        //抢到锁则执行业务    }catch (Exception exception){        exception.printStackTrace();    }finally {        lock.unlock();    }}

Redisson分布式锁源码分析

这里可以先看看自己基于Redis实现一个简单的分布式锁。

自动续期

如果Redis上的分布式锁过期了，但是业务逻辑还没有处理完怎么办呢？

Redisson是这样做的：额外开了一个线程，定期检查业务线程是否还持有锁，如果还持有的话则延长过期时间。Redisson使用了Watch Dog来定期检查（每1/3的锁时间检查一次）。

Redisson的GitHub是这样描述的：

大家都知道，如果负责储存这个分布式锁的Redisson节点宕机以后，而且这个锁正好处于锁住的状态时，这个锁会出现锁死的状态。为了避免这种情况的发生，Redisson内部提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。默认情况下，看门狗的检查锁的超时时间是30秒钟，也可以通过修改Config.lockWatchdogTimeout来另行指定。

tryAcquireAsync

加锁的逻辑会进入到org.redisson.RedissonLock#tryAcquireAsync方法中，在获取锁成功之后会进入org.redisson.RedissonBaseLock#scheduleExpirationRenewal：

private <T> RFuture<Long> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {    RFuture<Long> ttlRemainingFuture;    if (leaseTime > 0) {        ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);    } else {        ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,                TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);    }    CompletionStage<Long> f = ttlRemainingFuture.thenApply(ttlRemaining -> {        // lock acquired        if (ttlRemaining == null) {            if (leaseTime > 0) {                internalLockLeaseTime = unit.toMillis(leaseTime);            } else {                scheduleExpirationRenewal(threadId);            }        }        return ttlRemaining;    });    return new CompletableFutureWrapper<>(f);}protected void scheduleExpirationRenewal(long threadId) {    ExpirationEntry entry = new ExpirationEntry();    ExpirationEntry oldEntry = EXPIRATION_RENEWAL_MAP.putIfAbsent(getEntryName(), entry);    if (oldEntry != null) {        oldEntry.addThreadId(threadId);    } else {        entry.addThreadId(threadId);        try {            renewExpiration();        } finally {            if (Thread.currentThread().isInterrupted()) {                cancelExpirationRenewal(threadId);            }        }    }}

Redis除了用来作为缓存，还有哪些其他的用途呢？

1. 分布式锁：在分布式系统中，为了保证数据的正确性，经常需要使用分布式锁。Redis提供了setnx和expire等操作，可以实现分布式锁的功能。使用Redis作为分布式锁可以有效地解决多个进程或者多台机器之间的竞争问题，从而提高系统的稳定性和可靠性。

2. 分布式Session：在Web应用中，为了保证用户的登录状态，经常需要使用会话管理。Redis提供了String和Hash等数据结构，可以方便地实现会话管理的功能。使用Redis作为会话管理存储可以有效地提高系统的性能和可扩展性。

3. 全局唯一ID：Redis可以通过Incr等操作实现全局唯一Id的生成。具体实现方式是在Redis中创建一个计数器，每当需要生成新的全局唯一Id时，对计数器进行自增，将自增后的值作为新的全局唯一Id返回。

4. 计数器：在很多应用场景中，需要对某些数据进行计数。Redis提供了Incr和Decr等操作，可以方便地实现计数器的功能。同时，Redis还提供了HyperLogLog数据结构，可以实现一些基数统计的功能。使用Redis作为计数器可以有效地提高系统的性能和可扩展性。

5. 地理位置：Redis提供了Geo数据结构，可以实现一些基于地理位置的应用，比如附近的人等。使用Redis作为地理位置存储可以有效地提高系统的可扩展性和可维护性。

   除此之外，Redis还提供了很多其他的数据结构和操作，如Set、Sorted Set、Hash等。可以根据具体的需求选择合适的数据结构和操作。

6. 轻量级的消息队列：在分布式系统中，消息队列是一种常见的解决方案。Redis提供了List数据结构，我们可以通过LeftPush和RightPop等操作来实现消息队列的功能。此外，Redis还提供了pub/sub模式，可以实现消息的订阅和发布。使用Redis作为消息队列可以有效地解耦系统各个模块之间的依赖关系，从而提高系统的可靠性和可维护性。

除此之外，Redis还提供了很多其他的数据结构和操作，如Set、Sorted Set、Hash等。可以根据具体的需求选择合适的数据结构和操作。

什么是分布式锁

要介绍分布式锁，首先要提到与分布式锁相对应的是线程锁、进程锁。

• 线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如synchronized是共享对象头，显示锁Lock是共享某个变量（state）。
• 进程锁：为了控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁。
• 分布式锁：当多个进程不在同一个系统中(比如分布式系统中控制共享资源访问)，用分布式锁控制多个进程对资源的访问。

分布式锁需要具备的条件

一个靠谱的分布式锁需要具备以下条件：

1. 互斥性：同一时刻只能有一个客户端持有锁，其他客户端无法获取锁。
2. 可重入性：允许同一个客户端在持有锁的情况下再次获取锁，避免死锁。
3. 高可用性：当锁服务器出现故障时，需要有备用服务器来提供锁服务。
4. 容错性：当一个客户端持有锁的时间超过一定阈值时，需要自动释放锁，避免死锁。

除此之外，分布式锁的设计中还可以/需要考虑：

1. 加锁解锁的同源性：A加的锁，不能被B解锁。
2. 获取锁是非阻塞的：如果获取不到锁，不能无限期等待。
3. 高性能：加锁解锁是高性能的。

分布式锁的实现方案

1. 基于数据库的实现方案：
   1. 基于数据库表（锁表，很少使用）。
   2. 乐观锁（基于版本号）。
   3. 悲观锁（基于排它锁）。
2. 基于Redis实现分布式锁：
   1. 单个Redis实例：setnx（key,当前时间+过期时间）+ Lua。
   2. Redis集群模式：Redlock。
3. 基于ZooKeeper的实现方案:当一个进程或线程需要访问共享资源时，先在ZooKeeper中创建一个临时节点，并将该节点作为锁。其他进程或线程尝试创建同名节点时，由于该节点已存在，创建操作将失败，从而实现了对共享资源的访问控制。当进程或线程完成对共享资源的访问后，删除该节点，释放锁。
4. 基于 Consul 实现分布式锁

实现一个简单的分布式锁

业务场景

假设一个商品扣减库存的场景，库存数据就存放在Redis了。首先是Service的实现：

@Overridepublic void deduct(Long id) {    String key = "storage:" + id;    //查询Redis里面的库存    int storage = Optional.ofNullable(redisTemplate.opsForValue().get(key)).map(Integer::parseInt).orElse(0);    //判断库存是否足够    if(storage>0){        //扣减库存        redisTemplate.opsForValue().set(key,String.valueOf(storage-1));    }}

具体业务就是根据一个库存Id，从Redis查询到剩余库存然后判断是否大于0，最后扣除库存保存到Redis。

使用setnx实现简单分布式锁

这里是存在线程安全问题的，高并发下极有可能出现”超卖“现象，这里我们使用分布式锁来解决，从上文得知，Redis可以使用setnx来实现分布式锁，那么代码可以改成如下：

@Overridepublic void deduct(Long id) {    String key = "storage:" + id;    String redisLockKey = "redisLock:storage";    String uuId = UUID.randomUUID().toString();    String lockId = uuId + Thread.currentThread().getId();    try{        //尝试抢占锁        Boolean hasLock = redisTemplate.opsForValue().setIfAbsent(redisLockKey,lockId);        //这里如果没有抢到锁则重试        if(Boolean.FALSE.equals(hasLock)){            //暂停20ms，然后递归重试            TimeUnit.MICROSECONDS.sleep(20);            deduct(id);        }else{            //抢到锁则执行业务            //查询Redis里面的库存            int storage = Optional.ofNullable(redisTemplate.opsForValue().get(key)).map(Integer::parseInt).orElse(0);            //判断库存是否足够            if(storage>0){                //扣减库存                redisTemplate.opsForValue().set(key,String.valueOf(storage-1));            }        }    }catch (Exception exception){        exception.printStackTrace();    }finally {        //关闭资源，释放锁        redisTemplate.delete(redisLockKey);    }}

测试上面的代码后并没有出现”超卖“，但是上面的代码还是存在一定的问题的：

• 递归的次数：这里使用递归在高并发的场景下很容易导致SOF。

使用自旋来重试获取锁

@Overridepublic void deduct(Long id) {    String key = "storage:" + id;    String redisLockKey = "redisLock:storage";    String uuId = UUID.randomUUID().toString();    String lockId = uuId + Thread.currentThread().getId();    try{        //尝试抢占锁，自旋        while(Boolean.FALSE.equals(redisTemplate.opsForValue().setIfAbsent(redisLockKey, lockId))) {            //暂停20ms            TimeUnit.MICROSECONDS.sleep(20);        }        //抢到锁则执行业务        //查询Redis里面的库存        int storage = Optional.ofNullable(redisTemplate.opsForValue().get(key)).map(Integer::parseInt).orElse(0);        //判断库存是否足够        if(storage>0){            //扣减库存            redisTemplate.opsForValue().set(key,String.valueOf(storage-1));        }    }catch (Exception exception){        exception.printStackTrace();    }finally {        //关闭资源，释放锁        redisTemplate.delete(redisLockKey);    }}

这里我们使用自旋来代替了上面的递归，避免了上面的SOF的出现，但是这里还是存在一些问题的，想想如果线程的关闭资源之前，服务器挂掉了，那么这个key将会一直存在，其他线程永远获取不了锁。那么怎样才能使这个key不一直存在呢，这里我们可以给这个key加上过期时间，这样就算没有关闭资源，那这个key还是会自动过期删除的。

redisTemplate.opsForValue().setIfAbsent(redisLockKey,lockId,10L,TimeUnit.SECONDS)

这里不能分开使用expire方法，因为如果不保证原子性的话，还是会出现上述问题。

防止误删Key

上面我们设置了key的过期时间来保证在没有释放锁的情况下使key过期来自动删除，但是上面过期时间是写死的，实际这个具体时间是没有办法保证的。

假设这里两个线程A和B，A先抢到了锁并开始执行业务，但是A执行的时间没法保证，所以当某一次A的执行时间超过了设置的过期时间时，这里一直在自旋重试的B则会马上获取到锁，这里当B还在执行业务的同时，A线程执行完了然后释放锁（实际上释放的时B加的锁）。根据上面提到的分布式锁需要具备锁的同源性，所以这里违背了分布式锁的设计原则。

那么如何解决这个问题呢？首先我们就需要保证每个线程只能删除自己的key，可以在删除key的同时增加一个判断，判断当前key所对应的value是否是自己的。

//关闭资源，释放锁if(lockId.equalsIgnoreCase(redisTemplate.opsForValue().get(redisLockKey))){redisTemplate.delete(redisLockKey);}

使用Lua保证原子性

上面我们使用Redis的setnx实现了一个简单的分布式锁，但是实际还存在很多的问题，比如在最后释放锁的时候是不能保证原子性的。所以这里采用Lua来保证原子性。

什么是Lua脚本

Lua是一种轻量小巧的脚本语言，用标准的C语言编写并以源代码形式开放，设计目的时为了嵌入到程序之中，从而为应用程序提供灵活的扩展和定制功能。

Lua的特性

• 轻量级：使用标准C语言编写，编译后仅仅一百多k，可以很方便的嵌入到别的程序里面。
• 可扩展：Lua提供了非常易于使用的扩展接口和机制：由宿主语言（通常时C或者C++）提供这些功能，Lua可以就像时本来内置的功能一样来使用它们。

Redis中使用Lua

Redis中执行Lua可以通过两种方式：

• EVAL：将Lua脚本或命令直接使用Redis执行。
• EVALSHA：相当于把脚本或命令保存到redis中，然后使用一串sha码调用（可以理解为调用函数）

eval

命令的使用：

EVAL script numkeys [key [key ...]] [arg [arg ...]]

1. script：是一段Lua5.1脚本程序。脚本内容就是要执行的lua脚本内容。
2. numkeys：指定后续参数有几个key，即：key [key …]中key的个数。如没有key，则为0。
3. key [key …] ：key列表，作为参数传递给Lua语言，lua中是用KEYS[n]来获取对应的参数表示在脚本中所用到的那些Redis键（key）。在Lua脚本中通过KEYS[1], KEYS[2]获取。
4. arg [arg …]：参数列表是传递给Lua语言，可填可不填，lua中使用ARGV[n]来获取对应的参数。

比如：

> EVAL "return" 0 hello"hello"

使用Lua脚本解决不能保证原子性的问题

修改上面代码中的finally代码块为即可保证释放锁时候的原子性：

finally {    //关闭资源，释放锁，使用Lua脚本来保证原子性    String luaScript = "if redis.call('get',KEYS[1]) == ARGV[1] then" +                            " return redis.call('del',KEYS[1]) " +                        "else " +                            "return 0" +                        "end";    List<String> keys = new ArrayList<>() {{        add(redisLockKey);    }};    DefaultRedisScript<Boolean> redisScript = new DefaultRedisScript<>(luaScript, Boolean.class);    Boolean result = redisTemplate.execute(redisScript, keys, lockId);}

可重入的分布式锁

什么是可重入锁

可重入锁还可以叫做递归锁，它是指同一个线程在外层方法获取锁的时候，再次进入该方法内层调用的方法时可以自动获取锁（这里前提是同一把锁），不会因为之前已经获取过该锁还没释放而阻塞。可重入锁的一个优点就是在一定程度上防止了死锁。

简单说就是一个线程中的多个流程可以获取在不释放锁的情况下可以获取同一把锁。

可重入锁的种类

1. 隐式锁：synchronized，synchronized实现可重入锁是通过使每个锁对象拥有一个锁计数器和一个指向持有该锁的线程的指针：
   1. 当执行monitor enter的时候，如果目标锁对象的计数器为0，那么说明它没有被其他线程所持有，Java虚拟机会将该锁对象的持有线程设置为当前线程，并且将其计数器加1。
   2. 在目标锁对象的计数器不为0的情况下，如果锁对象的持有线程是当前线程，那么Java虚拟机可以将其计数器再加1，否则需要等待其他线程释放锁。
   3. 当执行monitor exit时，Java虚拟机则需要将锁对象的计数器减1。计数器为0则代表锁已经被释放。
2. 显式锁：比如Lock中的ReentrantLock。

简单来说实现一个可重入锁（可以参考synchronized以及JUC中的AQS），当线程再次获取同一把锁时判断当前锁是否被同一个线程获取了，如果是则当前线程便可以直接获得该锁，否则需要等待其他线程释放锁才行。

基于Redis实现可重入锁

在实现之前，还有一个计数器的问题，显然继续使用setnx并不能满足这一条件，那么要基于Redis实现一个可重入的分布式锁还能用Redis的什么数据类型呢？

我们可以使用Hash这个数据类型来实现：

HSET RedisLock xxxxxxxx:1 1

也就是Hset 锁名称 全局唯一Id:线程Id 计数器（线程加锁的次数）。

修改业务代码为：

@Overridepublic void deduct(Long id) {    String key = "storage:" + id;    Lock lock = distributedLockFactory.createLock(DistributedLockFactory.LockType.REDIS);    try{        lock.lock();        //抢到锁则执行业务        //查询Redis里面的库存        int storage = Optional.ofNullable(redisTemplate.opsForValue().get(key)).map(Integer::parseInt).orElse(0);        //判断库存是否足够        if(storage>0){            //扣减库存            redisTemplate.opsForValue().set(key,String.valueOf(storage-1));        }        testReentrant();    }catch (Exception exception){        exception.printStackTrace();    }finally {        lock.unlock();    }}@Overridepublic void testReentrant() {    Lock lock = distributedLockFactory.createLock(DistributedLockFactory.LockType.REDIS);    try {        lock.lock();    }finally {        lock.unlock();    }}

基于JUC的Lock接口来实现RedisLock：

public class RedisLock extends AbstractDistributedLock {    private final RedisTemplate<String,Object> redisTemplate;    private final long expireTime;    private final String LOCK_NAME = "RedisLock";    public RedisLock(RedisTemplate<String, Object> redisTemplate,String uuid) {        this.redisTemplate = redisTemplate;        this.expireTime = 50L;        super.lockId = uuid+":"+Thread.currentThread().getId();    }    @Override    public void lock() {        while(Boolean.FALSE.equals(tryLock())){            try {                TimeUnit.MILLISECONDS.sleep(60);            } catch (InterruptedException e) {                throw new RuntimeException(e);            }        }    }    @Override    public boolean tryLock() {        String luaScript = "if redis.call('EXISTS',KEYS[1]) == 0 or redis.call('HEXISTS',KEYS[1],ARGV[1]) == 1 then" +                                "redis.call('HINCRBY',KEYS[1],ARGV[1],1)"+                                "redis.call('EXPIRE',KEYS[1],ARGV[2])"+                                "return 1"+                            "else"+                                "return 0"+                            "end";        return Boolean.TRUE.equals(redisTemplate.execute(new DefaultRedisScript<>(luaScript, Boolean.class), List.of(LOCK_NAME), lockId, String.valueOf(expireTime)));    }    @Override    public void unlock() {        String luaScript = "if redis.call('HEXISTS',KEYS[1],ARGV[1]) == 0 then" +                                "return nil"+                            "else if redis.call('HINCRBY',KEYS[1],ARGV[1],-1) == 0 then"+                                "return redis.call('DEL',KEYS[1])"+                            "else"+                                "return 0"+                            "end";        redisTemplate.execute(new DefaultRedisScript<>(luaScript, Long.class), List.of(LOCK_NAME), lockId);    }}

首先缓存双写一致性是指缓存和数据库中的数据保持一致。当修改数据库中的数据时，需要同时修改缓存中的数据，以保证两者的一致性。如果只修改了数据库中的数据，而没有及时更新缓存，会导致缓存中的数据与数据库中的数据不一致，进而影响系统的正确性和性能。

一般使用缓存的流程可以是这样：

主要步骤就是先查询缓存看是否存在数据，存在则直接返回，不存在再去查询数据库，数据库中不存在的话也直接返回，存在的话则回写缓存并且返回。

四种更新策略

先更新数据库，再更新缓存（❌不推荐）

该策略会导致两种问题出现：

更新数据库成功，更新缓存失败

比如有个商品的库存为1，有订单来了需要扣库存，如果先更新数据库为0，再更新缓存，但是更新数据库成功了而更新缓存时失败，这样就会导致缓存中库存依然是1没有扣减，数据库中库存扣减成功为0，这样的数据库与缓存的不一致问题。后续就会读到缓存中的脏数据。

多个线程同时更新导致不一致

比如A，B两个线程，假如A在更新完数据库后还没来得及更新缓存，此时B已经更新数据库并且更新了缓存，最后A才更新缓存，将会是下面这种情况，最终还是导致了数据库和缓存的不一致问题：

先更新缓存，再更新数据库（❌不推荐）

多个线程同时更新导致不一致

比如A，B两个线程，假如A在更新完缓存后还没来得及更新数据库，此时B已经更新缓存并且更新了数据库，最后A才更新数据库，将会是下面这种情况，最终还是导致了数据库和缓存的不一致问题：

先删除缓存，再更新数据库（❌不推荐）

读写请求并发的情况下，在写线程删除缓存后且更新数据库的事务提交之前，这时读线程进来了，读线程此时查不到缓存，就去数据库里查到了旧数据然后将数据放入缓存。这种情况下，直到下一次新的写操作进来之前，缓存中的数据将一直是脏数据。

如上图所示，开始时数据库和缓存值都是100，写线程在失效缓存成功后（数据库值为100，缓存没有值），读线程此时请求发现缓存数据为空的话，就会从数据库中读取旧值放入到缓存中（数据库和缓存值都是100），最后写线程在将值写入数据库（数据库值为80，缓存没有100），这样就导致了不一致的问题。另外，数据库如果采用的是主从复制+读写分离的架构，读线程读出来的数据也有可能是主从未同步完成造成的脏数据。

针对这样的情况可以采用延时双删的策略来有效避免，可以在更新完数据库后使用线程休眠一段时间，再次删除缓存：

cache.delKey(key);db.update(data);Thread.sleep(xxx);cache.delKey(key);

主要是在写请求更新完数据库后休眠一段时间（休眠时间=读数据耗时+主从同步耗时），然后再删除一次缓存，将可能由并发读请求带来的脏数据失效掉。这种通过延时双删的方式需要线程休眠，因此很显然会降低系统吞吐量，并不是一种比较好的解决方式，也可以采用异步删除的方式。当然也可以设置缓存过期时间，到期后缓存自动失效，但这样做需要系统能够容忍一段时间的数据不一致。

先更新数据库，再删除缓存（⚠️推荐）

实际上这种方式也存在数据不一致的情况。

1. 读线程发起查询请求，此时缓存恰好失效了（可能是到期了），直接到数据库查询，查到了数据还没有来得及去设置缓存。（此时数据库值为100缓存没有值）
2. 写线程要更新值，先更新数据库，再失效缓存。（此时数据库值为80缓存没有值）
3. 读线程这时才设置缓存。（此时数据库值为80缓存值为100）

这样的话最终还是会导致缓存和数据库不一致，主要就是因为缓存突然失效了，而且还要保证写线程的更新操作比读线程的查询并且更新缓存的操作还要快。（实际上这种情况发生的概率很低）要发生这种情况的前提条件是写数据库要先于读数据库完成，一般而言数据库的读相比于写耗时更短，这种前提条件成立的概率很低。采用上文提到的延时双删方法可以达到最终一致。

比较于上面的先删除缓存再更新数据库，先更新数据库再失效缓存依然会有问题，但是概率非常低。

导致不一致的原因

• 逻辑失败造成的数据不一致：在并发的情况下，无论是先删除缓存后更新数据库，还是先更新数据库后失效缓存，都会有数据不一致的情况，主要是由读写请求在并发情况下的操作时序导致的，这种特殊时序造成的不一致称之为“逻辑失败”，解决这种因为并发时序导致的不一致，核心的解决思想是将操作进行串行化。
• 物理失败造成的数据不一致：先更新数据库后删除缓存，如果删除缓存操作出现失败，也会出现数据不一致的情况。但是数据库更新以及缓存操作不适合放到一个事务中，一般来说，如果使用分布式缓存有网络传输的耗时，如果这个耗时较长，那么将更新数据库以及失效缓存放到一个事务中，就会造成事务耗时过长，很快耗尽数据库的连接池，严重的降低系统性能，导致系统崩溃。像这种因为操作失败导致的数据不一致称之为“物理失败”，大多数物理失败的情况可以用重试的方案解决。

最终保证一致性的方案

主要分为以下几步：

1. 更新数据库数据。
2. 数据库会将操作信息写入Binlog日志当中。
3. 订阅程序提取出所需要的数据以及key。
4. 另起一段非业务代码，获得该信息。
5. 尝试删除缓存操作。
6. 如果删除缓存操作失败，将这些信息发送至消息队列。
7. 重新从消息队列中获得该数据，重试删除操作。

采用这种方案，业务系统只负责处理业务逻辑，更新MySQL，完全不用管如何去更新缓存。而负责更新缓存的服务，把自己伪装成一个MySQL的从节点，从MySQL接收Binlog，解析Binlog之后，可以得到实时的数据变更信息，然后根据这个变更信息去更新缓存。这个方案的缺点是，实现缓存更新服务有点儿复杂，毕竟解析Binlog文件还是很麻烦的。

MoreKey问题

假如现在Redis服务上有100W条记录，如何遍历？keys *可以吗？

模拟大量的key

首先要在Redis里面插入100W条记录，这里先生成一个临时文件使用命令：

for((i=1;i<=100*10000);i++); do echo "set k$i v$i" >>/tmp/redisTest.txt; done;

等待完毕后使用more查看文件内容：

root@zygzyg:~# more /tmp/redisTest.txt set k1 v1set k2 v2set k3 v3set k4 v4set k5 v5set k6 v6set k7 v7set k8 v8...

可以看到命令已经成功的写入文件(大概耗时几秒钟吧)。

批量执行命令

上面已经生成了一个有100W条命令的文件，那么如何将这些记录写入Redis呢？这里可以使用Redis管道（Redis Pipline）。

这里使用Pipline即可将redisTest.txt中的命令写入Redis。

root@3581da7bfc4e:/data#cat /tmp/redisTest.txt | redis-cli -h 127.0.0.1 -p 6379 --pipeAll data transferred. Waiting for the last reply...Last reply received from server.errors: 0, replies: 1000000

这里可以看到已经成功写入100W条记录了，使用DBSIZE查看：

127.0.0.1:6379> DBSIZE(integer) 1000000

测试keys *

127.0.0.1:6379> keys * ......1000000) "k375734"1000001) "k911335"1000002) "k702315"1000003) "k538803"1000004) "k254614"(113.48s)

可以看到这里耗时有113秒左右，由于Redis执行命令是单线程的，也就是说这里的keys *执行返回之前该线程是处于阻塞状态的。所以keys *这个命令有致命的弊端，在实际生产中最好是不要使用。

⚠️这个命令没有offset、limit参数，也就是一旦执行就会查出所有满足条件的key，由于Redis执行命令是单线程的，它的所有操作都是原子的，而keys算法是遍历算法，复杂度是O(n)，如果Redis中有百万级或者千万级以上的key，这个指令就会导致Redis服务阻塞，所有读写Redis的其他指令都会被迫延迟甚至超时报错，可能会引起缓存雪崩、数据库压力飙升甚至宕机。

禁用Redis命令

既然这些命令在生产上容易出现问题，那么如何在生产上限制这些命令的使用呢？

可以通过Redis配置redis.conf来禁用这些命令

# It is also possible to completely kill a command by renaming it into# an empty string:# 简答说就是将想要禁用的命令后面配置为空字符串即可# rename-command CONFIG ""rename-command KEYS ""rename-command FLUSHALL ""rename-command FLUSHDB ""

通过上述配置就可以禁用KEYS、FLUSHALL、FLUSHDB命令了，再次使用会报如下错误：

127.0.0.1:6379> keys *(error) ERR unknown command 'keys', with args beginning with: '*' 127.0.0.1:6379> FLUSHALL(error) ERR unknown command 'FLUSHALL', with args beginning with: 127.0.0.1:6379> FLUSHDB(error) ERR unknown command 'FLUSHDB', with args beginning with: 

SCAN命令

既然KEYS *会造成阻塞，那么该如何遍历呢？Redis还提供了SCAN命令，有点类似于MySQL中的limit，但是并不是完全相同。

SCAN cursor [MATCH pattern] [COUNT count]

• cursor：游标。
• pattern：匹配的模式。
• count：指定从数据集里面返回多少元素，默认是10。

它是基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历，不保证每次执行都返回某个给定数量的元素，支持模糊查询一次返回的数量不可控，只能是大概率符合count参数。

127.0.0.1:6379> SCAN 0 MATCH k* COUNT 101) "196608"2)  1) "k176810"    2) "k738876"    3) "k689302"    4) "k526619"    5) "k600652"    6) "k152020"    7) "k289919"    8) "k819980"    9) "k98466"   10) "k755213"   11) "k10086"127.0.0.1:6379> SCAN 196608 MATCH k* COUNT 101) "425984"2)  1) "k181985"    2) "k870789"    3) "k535112"    4) "k990462"    5) "k591390"    6) "k188791"    7) "k917745"    8) "k483131"    9) "k511975"   10) "k273108"   11) "k479350"

SCAN的遍历顺序

SCAN的遍历顺序非常特别，它不是从第一维数组的第零位一直遍历到末尾，而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历，是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏。

BigKey问题

多大的Key算BigKey呢？严格来说真正大的应该是key对应的value。可以参考《阿里云Redis开发规范》：

string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。

反例：一个包含200万个元素的list。

非字符串的bigkey，不要使用del删除，使用hscan、sscan、zscan方式渐进式删除，同时要注意防止bigkey过期时间自动删除问题(例如一个200万的zset设置1小时过期，会触发del操作，造成阻塞，而且该操作不会不出现在慢查询中(latency可查)，查找方法和删除方法。

那么BigKey会造成哪些问题呢？

BigKey会造成哪些问题

1. 如果是集群模式下，无法做到负载均衡，导致请求倾斜到某个实例上，而这个实例的QPS会比较大，内存占用也较多；对于Redis单线程模型又容易出现CPU瓶颈，当内存出现瓶颈时，只能进行纵向扩容。
2. 涉及到大key的操作，尤其是使用hgetall、lrange 0 -1、get、hmget 等操作时，网卡可能会成为瓶颈，也会到导致堵塞其它操作，QPS就有可能出现突降或者突升的情况，趋势上看起来十分不平滑，严重时会导致应用程序连不上，实例或者集群在某些时间段内不可用的状态。
3. 假如这个key需要进行删除操作，如果直接进行DEL操作，被操作的实例会被阻塞，导致无法响应应用的请求，而这个Block的时间会随着key的变大而变长。

BigKey是如何产生的

一般来说，bigkey是由于程序员的程序设计不当，或对数据规模预料不清楚造成的：

1. 社交类：粉丝列表，如果某些明星或大V，粉丝逐渐增加。一定会造成BigKey。
2. 统计类：如果按天存储某项功能或网站的用户集合，除非没几个人用，否则必定是bigkey。
3. 缓存类：作为数据库数据的冗余存储，这种是redis的最常用场景，但有2点要注意：
   1. 是不是有必要把所有数据都缓存？
   2. 有没有相关关联的数据？

举个例子，该同学把某明星一个专辑下的所有视频信息都缓存成了一个巨大的json，这个json达到了6MB。

BigKey如何发现

1. redis-cli--bigkeys

   redis-cli原生自带–bigkeys功能，可以找到某个实例5种数据类型(String、hash、list、set、zset)的最大key。

   其好处有能给出每种数据结构TOP 1的BigKey，同时还能给出每种数据类型的键值个数和平均大小。

   不足之处有，当想要查询大于10kb的所有key时，–bigkeys就无能为力了，这时可以用memory useage来计算每个键值对的字节数。

   root@3581da7bfc4e:/data# redis-cli --bigkeys# Scanning the entire keyspace to find biggest keys as well as# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec# per 100 SCAN commands (not usually needed).[00.00%] Biggest string found so far '"k176810"' with 7 bytes[42.58%] Biggest string found so far '"Test"' with 19 bytes[100.00%] Sampled 1000000 keys so far-------- summary -------Sampled 1000004 keys in the keyspace!Total key length in bytes is 6888908 (avg len 6.89)Biggest string found '"Test"' has 19 bytes0 lists with 0 items (00.00% of keys, avg size 0.00)0 hashs with 0 fields (00.00% of keys, avg size 0.00)1000004 strings with 6888925 bytes (100.00% of keys, avg size 6.89)0 streams with 0 entries (00.00% of keys, avg size 0.00)0 sets with 0 members (00.00% of keys, avg size 0.00)0 zsets with 0 members (00.00% of keys, avg size 0.00)

   如果加上 -i 0.1，那么每隔100条scan命令就会休眠0.1秒，这要QPS就不会剧烈抬升，但是扫描的时间会变长。

2. memory useage

   命令MEMORY USAGE 给出一个key和它值在内存中占用的字节数，返回的结果是key的值以及为管理该key分配的内存总字节数，对于嵌套数据类型，可以使用选项SAMPLES，其中COUNT表示抽样的元素个数，默认值为5。当需要抽样所有元素时，使用SAMPLES 0

   127.0.0.1:6379> MEMORY USAGE Test(integer) 48

3. 在redis实例上执行bgsave，然后对dump出来的rdb文件进行分析，找到其中的大KEY。

BigKey如何删除

DEL命令在删除单个集合类型的Key时，命令的时间复杂度是O(M)，其中M是集合类型Key包含的元素个数。

DEL keyTime complexity: O(N) where N is the number of keys that will be removed. When a key to remove holds a value other than a string, the individual complexity for this key is O(M) where M is the number of elements in the list, set, sorted set or hash. Removing a single key that holds a string value is O(1).

生产环境中遇到过多次因业务删除大Key，导致Redis阻塞，出现故障切换和应用程序雪崩的故障。

1. String：一般使用DEL，如果过于庞大则使用UNLINK。

2. Hash：通过hscan命令，每次获取少量字段，再用hdel命令，每次删除1个字段，《阿里云Redis开发手册》中的Java代码：

   public void delBigHash(String host, int port, String password, String bigHashKey) {    Jedis jedis = new Jedis(host, port);    if (password != null && !"".equals(password)) {        jedis.auth(password);    }    ScanParams scanParams = new ScanParams().count(100);    String cursor = "0";    do {        ScanResult<Entry<String, String>> scanResult = jedis.hscan(bigHashKey, cursor, scanParams);        List<Entry<String, String>> entryList = scanResult.getResult();        if (entryList != null && !entryList.isEmpty()) {            for (Entry<String, String> entry : entryList) {                jedis.hdel(bigHashKey, entry.getKey());            }        }        cursor = scanResult.getStringCursor();    } while (!"0".equals(cursor));    //删除bigkey    jedis.del(bigHashKey);}

3. List：使用ltrim渐进式删除，直到全部删除完成，《阿里云Redis开发手册》中的Java代码：

   public void delBigList(String host, int port, String password, String bigListKey) {    Jedis jedis = new Jedis(host, port);    if (password != null && !"".equals(password)) {        jedis.auth(password);    }    long llen = jedis.llen(bigListKey);    int counter = 0;    int left = 100;    while (counter < llen) {        //每次从左侧截掉100个        jedis.ltrim(bigListKey, left, llen);        counter += left;    }    //最终删除key    jedis.del(bigListKey);}

4. Set：使用sscan每次获取部分元素，再使用srem命令删除每个元素，《阿里云Redis开发手册》中的Java代码：

   public void delBigSet(String host, int port, String password, String bigSetKey) {    Jedis jedis = new Jedis(host, port);    if (password != null && !"".equals(password)) {        jedis.auth(password);    }    ScanParams scanParams = new ScanParams().count(100);    String cursor = "0";    do {        ScanResult<String> scanResult = jedis.sscan(bigSetKey, cursor, scanParams);        List<String> memberList = scanResult.getResult();        if (memberList != null && !memberList.isEmpty()) {            for (String member : memberList) {                jedis.srem(bigSetKey, member);            }        }        cursor = scanResult.getStringCursor();    } while (!"0".equals(cursor));    //删除bigkey    jedis.del(bigSetKey);}

5. ZSet：使用zscan每次获取部分元素，再使用ZREMRANGEBYRANK命令删除每个元素，《阿里云Redis开发手册》中的Java代码：

   public void delBigZset(String host, int port, String password, String bigZsetKey) {    Jedis jedis = new Jedis(host, port);    if (password != null && !"".equals(password)) {        jedis.auth(password);    }    ScanParams scanParams = new ScanParams().count(100);    String cursor = "0";    do {        ScanResult<Tuple> scanResult = jedis.zscan(bigZsetKey, cursor, scanParams);        List<Tuple> tupleList = scanResult.getResult();        if (tupleList != null && !tupleList.isEmpty()) {            for (Tuple tuple : tupleList) {                jedis.zrem(bigZsetKey, tuple.getElement());            }        }        cursor = scanResult.getStringCursor();    } while (!"0".equals(cursor));        //删除bigkey    jedis.del(bigZsetKey);}

BigKey生产调优

为了解决redis使用del命令删除大体积的key，或者使用flushdb、flushall删除数据库时，造成redis阻塞的情况，在redis 4.0引入了lazyfree机制，可将删除操作放在后台，让后台子线程(bio)执行，避免主线程阻塞。

redis.conf文件里Lazy Freeing的相关说明:

• Redis有两个用于删除键的原语。一个称为DEL，是对象的阻塞删除。这意味着服务器停止处理新命令以同步方式回收与对象相关联的所有内存。如果删除的键与小对象相关联，则执行DEL命令所需的时间非常快，可与大多数其他O(1)或O(log_N)命令相媲美。但是，如果键与包含数百万元素的聚合值相关联，则服务器可能会阻塞很长时间（甚至几秒钟）以完成操作。

• Redis提供了非阻塞删除原语，例如UNLINK（非阻塞DEL）和FLUSHALL和FLUSHDB命令的ASYNC选项，以便在后台回收内存。这些命令在恒定时间内执行。另一个线程将尽可能快地逐步释放对象。

• DEL、UNLINK和FLUSHALL、FLUSHDB的ASYNC选项由用户控制。由应用程序的设计决定何时使用哪个。但是，Redis服务器有时必须删除键或刷新整个数据库作为其他操作的副作用。具体来说，Redis在以下场景中独立于用户调用删除对象：

  1. 当因为maxmemory和maxmemory策略配置而需要为新数据腾出空间以避免超过指定的内存限制时，会发生清除操作。
  2. 因为过期:当具有关联的生存时间的键必须从内存中删除时。
  3. 因为命令的副作用，该命令将数据存储在可能已经存在的键上。例如，当RENAME命令被另一个命令替换时，它可能会删除旧键内容。同样，SUNIONSTORE或具有STORE选项的SORT可能会删除现有键。SET命令本身会删除指定键的任何旧内容，以便用指定字符串替换它。
  4. 当副本与其主服务器执行完全重新同步时，会发生清除操作，以便加载刚刚传输的整个数据库内容。

• 在所有上述情况下，默认情况是以阻塞方式删除对象，就像调用DEL一样。但是，您可以针对每种情况进行特定配置，以便以非阻塞方式释放内存，就像调用UNLINK一样，使用以下配置指令:

  # 针对redis内存使用达到maxmeory，并设置有淘汰策略时；在被动淘汰键时，是否采用lazy free机制；lazyfree-lazy-eviction yes# 针对设置有TTL的键，达到过期后，被redis清理删除时是否采用lazy free机制；此场景建议开启，因TTL本身是自适应调整的速度。lazyfree-lazy-expire yes# 针对有些指令在处理已存在的键时，会带有一个隐式的DEL键的操作。如rename命令，当目标键已存在,redis会先删除目标键，如果这些目标键是一个big key,那就会引入阻塞删除的性能问题。 此参数设置就是解决类问题，建议可开启。lazyfree-lazy-server-del yes# 针对slave进行全量数据同步，slave在加载master的RDB文件前，会运行flushall来清理自己的数据场景,# 参数设置决定是否采用异常flush机制。如果内存变动不大，建议可开启。可减少全量同步耗时，从而减少主库因输出缓冲区爆涨引起的内存使用增长。replica-lazy-flush yes

• 还可以通过以下配置指令将DEL命令的默认行为修改为与UNLINK完全相同，以便在无法轻松替换用户代码DEL调用为UNLINK调用的情况下使用：

  lazyfree-lazy-user-del yes

• FLUSHDB、FLUSHALL、SCRIPT FLUSH和FUNCTION FLUSH支持异步和同步删除，可以通过将[SYNC|ASYNC]标志传递到命令中来控制。当没有传递标志时，将使用此配置来确定数据是否应异步删除:

  lazyfree-lazy-user-flush yes

要说Redis是单线程还是多线程实际要看实际版本

Redis的版本有很多，其架构也是不一样的。

• 在Redis3的时候是单线程。
• 从Redis4开始，严格意义上来说已经不是单线程了，而是负责处理客户端请求的线程是单线程，但是开始加了点多线程的东西。
• Redis6和Redis7彻底的用上了多线程。

Redis中有几个里程碑式的重要版本:

怎么理解Redis是单线程的呢？

Redis的单线程主要是指Redis的网络IO和键值对读写是由一个线程来完成的，Redis在处理客户端的请求时包括获取（Socket读）、解析、执行、内容返回（Socket写）等都是由一个顺序串行的主线程处理，这就是所谓的”单线程“。这也是Redis对外提供键值存储服务的主要流程。

• Redis采用Reactor模式的网络模型，对于一个客户端请求，主线程负责一个完整的处理过程

但是Redis的其他功能，比如持久化RDB、AOF、异步删除、集群数据同步等等其实都是由额外的线程来完成的。Redis命令工作线程是单线程的，但是对于整个Redis来说，实际是多线程的。

为什么Redis使用单线程依然很快？

• 基于内存操作：Redis的所有数据都在内存中，因此所有的运算都是内存级别的。
• 数据结构简单：Redis的数据结构是专门设计的，这些简单的数据结构的查找和操作的时间复杂度大部分都是O(1)。
• 多路IO复用和非阻塞IO：Redis使用IO多路复用功能来监听多个Socket连接客户端，这样就可以使用一个线程连接来处理多个请求，减少线程切换带来的开销。同时也避免了IO阻塞操作。
• 避免上下文切换：因为是单线程模型，所以避免了不必要的上下文切换和多线程竞争。省去了多线程切换带来的时间和性能上的消耗，而且单线程不会导致死锁问题发生。

Redis如何利用多核CPU呢？

官网是这么回答的：

Redis很少出现CPU成为瓶颈的情况，通常Redis要么是内存首先，要么是网络受限。

例如：使用在平均Linux系统上运行的流水线Redis每秒可以发送100万个请求，因此如果您的应用程序主要使用O(N)或O(log(N))命令，则几乎不会使用太多CPU。

但是，要最大化CPU使用率，您可以在同一台计算机上启动多个Redis实例，并将它们视为不同的服务器。在某些时候，单个计算机可能已经不够了，因此如果要使用多个CPU，则可以开始考虑更早地进行分片的某种方式。

从4.0版本开始，Redis开始具有更多线程。目前，这仅限于在后台删除对象和阻止通过Redis模块实现的命令。对于随后的版本，计划是使Redis越来越多线程化。

官网的大致意思就是说Redis是基于内存操作的，因此它的瓶颈应该是服务器的内存或者网络带宽而并非是CPU，既然CPU不是瓶颈，那么自然就采用单线程的方案了，况且使用多线程比较麻烦。但是在Redis4.0中开始支持多线程了，比如后台删除、备份等功能。

Redis在4.0之前一直采用单线程的原因主要有3个

1. 使用单线程模型让Redis的开发和维护更简单，因为单线程模型方便开发和调试。
2. 即使使用单线程模型也能并发处理多客户端的请求，主要就是使用了IO多路复用和非阻塞IO。
3. 对于Redis来说，主要性能瓶颈是内存或者网络带宽而并非CPU。

为什么Redis后面开始使用多线程呢？

正常情况下使用del指令可以很快的删除数据，但是当被删除的key是一个非常大的对象时（比如包含了上万个元素的hash集合），那么del指令就会造成Redis主线程阻塞。

那么如何解决Redis删除大key时的阻塞问题呢？使用惰性删除可以有效地避免这个问题：

比如当删除一个很大的key的时候，因为单线程导致阻塞卡顿，所以Redis4.0中新增了多线程模块(此版本的多线程主要是为了解决删除数据效率比较低的问题)，主要有这么几个命令：

1. UNLINK KEY
2. FLUSHDB ASYNC
3. FLUSHALL ASYNC

这里其实就是把删除工作交给了子线程异步来完成了。

因为Redis是使用单个线程处理请求，Redis作者一直强调“Lazy Redis is better Redis”，而Lazy Free的本质就是把某些Cost（主要时间复杂度，占用主线程CPU时间片）较高操作，从Redis主线程剥离出来让bio子线程来处理，极大地减少主线程阻塞地时间。从而减少删除大key导致地性能和稳定性问题。

Redis6.0之后真正地加入了多线程

Redis6.0之后，最受关注的特性第一个就是多线程。

因为Redis一直被熟知地就是单线程，虽然有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF重写）。但是真正从网络IO到实际读写命令地处理都是由单个线程完成的。

随着网络硬件的性能提升，Redis的性能瓶颈有时也会出现在网络IO上，也就是说单个主线程的处理请求的速度跟不上网络硬件的速度。

为了应对这个问题：Redis6.0之后采用了多个IO线程来处理网络请求，提高网络请求处理的并行度。

但是Redis的多IO线程只是用来处理网络请求的，对于读写操作命令Redis仍然采用单线程处理，主要是因为：

• Redis处理请求时，网络处理经常成为瓶颈，而通过多个IO线程并行处理网络请求，可以提升服务的整体处理性能。
• 继续使用单线程处理读写命令操作，就不用为了保证Lua脚本、事务的原子性，额外开发多线程互斥加锁机制，这样一来就简化了Redis的实现。

主线程和IO线程是怎么协作完成请求处理的呢？

主要有四个阶段：

1. 阶段一：服务端和客户端建立Socket连接，并分配处理线程

   首先主线程负责接收建立连接请求，当有客户端请求和服务建立Socket连接时，主线程会创建和客户端的连接，并把Socket放入全局等待队列中。紧接着，主线程通过轮询的方法把Socket连接分配给IO线程。

2. 阶段二：IO线程读取并解析请求

   主线程一旦把Socket分配给IO线程，就会进入阻塞状态，等待IO线程完成客户端请求读取和解析。因为有多个IO线程在并行处理，所以这个过程很快就能完成。

3. 阶段三：主线程执行请求的操作

   等到IO线程解析完毕，主线程还是会以单线程的方式执行这些读写命令。

4. 阶段四：IO线程回写Socket和主线程清空全局队列

   当主线程执行完毕读写命令后，会把需要返回的结果写入缓冲区，然后主线程会阻塞并等待IO线程把这些结果回写到Socket中，并返回给客户端。和IO线程读取、解析请求一样，IO线程回写到SOcket时也是有多个线程在并发执行，所以回写Socket的速度也很快。等待IO线程回写完毕，主线程会清空全局队列，等待客户端的后续请求。

具体流程如下图所示：

IO多路复用

Unix网络编程中的五种IO模型

File Descriptor

Linux系统中一切皆文件，文件描述符（File Descriptor简称FD），句柄。

文件描述符（File Descriptor）是计算机科学中的一个术语，是一个用于表述指向文件的引用的抽象化概念。文件描述符在形式上是一个非负整数。实际上它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在程序设计中，文件描述符这一概念往往只适用于UNIX、LINUX这样的操作系统。

IO多路复用简单理解

IO多路复用是一种同步的IO模型，实现一个线程监视多个文件句柄。

• 一旦某个文件句柄就绪就能够通知到对应的应用程序进行相应的读写操作。
• 没有文件句柄就绪时就会阻塞应用程序，从而释放CPU资源。

IO多路复用字面意思可以理解为：

所以IO多路复用就是一个或者一组线程处理多个TCP连接，使用单进程就能够实现同时处理多个客户端的连接，无需创建或者维护过多的进程/线程。

一句话就是一个服务端进程可以同时处理多个套接字描述符。

实现IO多路复用的模型有3种：可以分为select->poll->epoll三个阶段来描述。

IO多路复用简单流程

将用户Socket对应的文件描述符（File Descriptor）注册进epoll，然后epoll监听哪些Socket上有消息到达，这样就避免了大量的无用操作。此时的Socket应该采用非阻塞模式。这样整个过程只有在调用select、poll、epoll的时候才会阻塞，收发客户端消息是不会阻塞的，整个进程或者线程就被充分利用起来，这就是事件驱动，所谓的reactor反应模式。

单个线程通过记录跟踪每一个Socket（IO流）的状态来同时管理多个IO流，一个服务端进程可以同时处理多个套接字描述符，目的是尽量多的提高服务器的吞吐能力。

总结

客户端请求服务端时，实际就是在服务端的Socket文件中写入客户端对应的文件描述符（File Descriptor），如果有多个客户端同时请求服务端，为每次请求都分配一个线程的话，这样就会比较耗费服务端资源。所以只使用一个线程来监听多个文件描述符，就是IO多路复用。采用IO多路复用技术可以让单个线程高效的处理多个连接请求。

从Redis6.0开始，就新增了多线程的功能来提高IO的读写性能，它的主要思路就是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使多个Socket的读写并行化了，采用IO多路复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗），将最耗时的Socket读取、请求解析、写入单独地外包出去，剩下的命令执行仍然由主线程串行执行。

• 网络IO操作变成多线程化，其他核心部分仍然是线程安全的，是个不错的折中办法

Redis是否默认开启了多线程

如果在实际应用中，发现Redis服务的CPU开销不大但是吞吐量却没有提升，可以考虑使用Redis的多线程机制，加速网络处理，从而提升吞吐量。

在Redis6.0之后多线程机制默认是关闭的，如果需要使用多线程功能，则需要在配置文件redis.conf中完成两个设置：

# Redis大部分是单线程的，但有一些线程操作，例如UNLINK、缓慢的I/O访问和其他一些事情是在子线程上执行的。# 现在，可以将Redis客户端套接字的读写处理在不同的I/O线程中。由于写入是如此缓慢，通常Redis用户使用流水线技术来加速每个核心的Redis性能，并产生多个实例以进行更好的扩展。# 使用I/O线程可以轻松地将Redis的速度提高两倍，而不需要使用流水线技术或实例分片。# 默认情况下，IO线程是禁用的，我们建议仅在具有4个或更多核心的机器上启用IO线程，留下至少一个备用核心。使用超过8个线程不太可能有太大帮助。# 我们还建议仅在实际存在性能问题的情况下使用线程化I/O，Redis实例能够使用相当大的CPU时间百分比，否则使用此功能没有意义。# 因此，例如，如果您有一个四核心的CPU，尝试使用2或3个I/O线程，如果您有8个核心，则尝试使用6个线程。要启用I/O线程，请使用以下配置指令：io-threads 4# 将io-threads设置为1将像往常一样使用主线程。# 启用I/O线程时，我们仅在写入时使用线程，即将write(2)系统调用线程化并将客户端缓冲区传输到套接字。但是也可以通过将以下配置指令设置为yes来启用读取和协议解析的多线程化：io-threads-do-reads no

❗**注意：**通常情况下，线程读取没有太大帮助。

1. 此配置指令不能通过CONFIG SET在运行时更改。另外，当启用SSL时，此功能不起作用。
2. 如果要使用redis-benchmark测试Redis，请确保运行基准测试也是多线程模式，使用--threads选项匹配上面配置的Redis线程的数量，否则将无法体现提升。

单体应用被拆分成微服务应用，原来的多个模块被拆分成多个独立的应用，分别使用多个独立的数据源，业务操作需要调用多个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没有办法保证。

简介

Seata是一款开源的分布式事务解决方案，旨在解决分布式事务场景下的数据一致性问题。Seata提供了一系列的技术手段，如TC（事务协调者）、TM（事务管理器）、RM（资源管理器）等，来确保分布式事务的正确性和一致性。

Seata的工作原理是通过TC来协调各个RM，实现全局事务的管理。当一个分布式事务开始时，TM会向TC注册一个全局事务，然后TC会向各个RM注册分支事务。在分支事务执行完成后，RM会将事务执行结果通知TC，TC会根据所有分支事务的执行结果来决定是否提交或回滚全局事务。

Seata支持多种分布式事务模式，如AT模式、TCC模式、Saga模式等。同时，Seata还提供了一些高级功能，如分布式锁、分布式ID、分布式事务日志等，以满足不同场景下的需求。

• TC（Transaction Coordinator，事务协调者）是全局事务的协调者，负责协调各个RM的工作。当一个分布式事务开始时，TM会向TC注册一个全局事务，然后TC会向各个RM注册分支事务。在分支事务执行完成后，RM会将事务执行结果通知TC，TC会根据所有分支事务的执行结果来决定是否提交或回滚全局事务。
• TM（Transaction Manager，事务管理器）负责全局事务的注册和提交/回滚。当一个分布式事务开始时，TM会向TC注册一个全局事务，然后根据事务的执行结果来决定是否提交或回滚全局事务。
• RM（Resource Manager，资源管理器）负责本地事务的执行和管理。当TC向RM注册分支事务后，RM会执行分支事务并将执行结果报告给TC，然后根据TC的指示来提交或回滚本地事务。

Seata的处理流程

1. TM向TC注册全局事务，全局事务创建成功并生成一个全局唯一的XID。
2. XID在微服务调用链路的上下文中传播。
3. RM向TC注册分支事务，将其纳入XID对应全局事务的管辖。
4. TM向TC发起针对XID的全局提交或回滚决议。
5. TC调度XID下管辖的全部分支事务完成提交或者回滚请求。

安装Seata

安装之前

Seata分TC、TM和RM三个角色，TC（Server端）为单独服务端部署，TM和RM（Client端）由业务系统集成。本文使用docker安装。

安装之前按照官网的说法Seata Server 1.5.0版本开始，配置文件改为application.yml，所以在使用自定义配置的时候，需要先把原生配置拷贝出来。

为了获取seata server 1.5.0的配置文件，我们需要先启动一个seata server 1.5.0的服务，然后再从启动的容器实例中把默认的配置文件复制出来，再进行修改。

1. 先启动一个容器

   version: "3.8"services:  seata-server:    image: seataio/seata-server:${latest-release-version}    container_name: seata-server    ports:      - "7091:7091"      - "8091:8091"

2. 从容器中将配置文件拷贝到一个临时目录

   docker cp seata-server:/seata-server/resources /tmp  

3. 后续使用拷贝出来的application.yml配置文件即可。

修改配置文件

这里使用Nacos为注册中心以及配置中心。修改seata.config以及seata.registry 。

server:  port: 7091spring:  application:    name: seata-serverlogging:  config: classpath:logback-spring.xml  file:    path: ${user.home}/logs/seata  extend:    logstash-appender:      destination: 127.0.0.1:4560    kafka-appender:      bootstrap-servers: 127.0.0.1:9092      topic: logback_to_logstashconsole:  user:    username: seata    password: seataseata:  config:    # support: nacos, consul, apollo, zk, etcd3    type: nacos    nacos:      server-addr: nacos-server:8848      namespace: seata-server      group: SEATA_GROUP      usernam: nacos      password: nacos      data-id: seataServer.properties  registry:    # support: nacos, eureka, redis, zk, consul, etcd3, sofa    type: nacos    nacos:      application: seata-server      server-addr: nacos-server:8848      group: SEATA_GROUP      namespace: seata-server      # tc集群名称      cluster: default      username: nacos      password: nacos#  store:#    # support: file 、 db 、 redis#    mode: file#  server:#    service-port: 8091 #If not configured, the default is '${server.port} + 1000'  security:    secretKey: SeataSecretKey0c382ef121d778043159209298fd40bf3850a017    tokenValidityInMilliseconds: 1800000    ignore:      urls: /,/**/*.css,/**/*.js,/**/*.html,/**/*.map,/**/*.svg,/**/*.png,/**/*.ico,/console-fe/public/**,/api/v1/auth/login

在nacos配置中心上创建配置文件

此处dataId为seataServer.properties

修改nacos上的配置

这里我使用的是mysql8，官方提供了建表脚本文件。

store.mode=db#-----db-----store.db.datasource=druidstore.db.dbType=mysql# 需要根据mysql的版本调整driverClassName# mysql8及以上版本对应的driver：com.mysql.cj.jdbc.Driver# mysql8以下版本的driver：com.mysql.jdbc.Driverstore.db.driverClassName=com.mysql.cj.jdbc.Driverstore.db.url=jdbc:mysql://mysql:3306/seata-server?useUnicode=true&characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useSSL=falsestore.db.user= 用户名store.db.password=密码# 数据库初始连接数store.db.minConn=1# 数据库最大连接数store.db.maxConn=20# 获取连接时最大等待时间 默认5000，单位毫秒store.db.maxWait=5000# 全局事务表名 默认global_tablestore.db.globalTable=global_table# 分支事务表名 默认branch_tablestore.db.branchTable=branch_table# 全局锁表名 默认lock_tablestore.db.lockTable=lock_table# 查询全局事务一次的最大条数 默认100store.db.queryLimit=100# undo保留天数 默认7天,log_status=1（附录3）和未正常清理的undoserver.undo.logSaveDays=7# undo清理线程间隔时间 默认86400000，单位毫秒server.undo.logDeletePeriod=86400000# 二阶段提交重试超时时长 单位ms,s,m,h,d,对应毫秒,秒,分,小时,天,默认毫秒。默认值-1表示无限重试# 公式: timeout>=now-globalTransactionBeginTime,true表示超时则不再重试# 注: 达到超时时间后将不会做任何重试,有数据不一致风险,除非业务自行可校准数据,否者慎用server.maxCommitRetryTimeout=-1# 二阶段回滚重试超时时长server.maxRollbackRetryTimeout=-1# 二阶段提交未完成状态全局事务重试提交线程间隔时间 默认1000，单位毫秒server.recovery.committingRetryPeriod=1000# 二阶段异步提交状态重试提交线程间隔时间 默认1000，单位毫秒server.recovery.asynCommittingRetryPeriod=1000# 二阶段回滚状态重试回滚线程间隔时间  默认1000，单位毫秒server.recovery.rollbackingRetryPeriod=1000# 超时状态检测重试线程间隔时间 默认1000，单位毫秒，检测出超时将全局事务置入回滚会话管理器server.recovery.timeoutRetryPeriod=1000

docker-compose.yml文件

version: "3.8"services:  seata1:    image: seataio/seata-server:latest    container_name: seata1    ports:      - "7091:7091"      - "8091:8091"    environment:      - STORE_MODE=db      # 以SEATA_IP作为host注册seata server,可选, 指定seata-server启动的IP, 该IP用于向注册中心注册时使用, 如eureka等      - SEATA_IP=${seata_ip}      # 可选, 指定seata-server启动的端口, 默认为 8091           - SEATA_PORT=8091    volumes:      - "/usr/share/zoneinfo/Asia/Shanghai:/etc/localtime"        #设置系统时区      - "/usr/share/zoneinfo/Asia/Shanghai:/etc/timezone"  #设置时区      # 假设我们通过docker cp命令把资源文件拷贝到相对路径`./seata-server/resources`中      - "./seata-server/resources:/seata-server/resources"  seata2:    image: seataio/seata-server:latest    container_name: seata2    ports:      - "7092:7091"      - "8092:8092"    environment:      - STORE_MODE=db      # 以SEATA_IP作为host注册seata server,可选, 指定seata-server启动的IP, 该IP用于向注册中心注册时使用, 如eureka等      - SEATA_IP=${seata_ip}      # 可选, 指定seata-server启动的端口, 默认为 8091        - SEATA_PORT=8092    volumes:      - "/usr/share/zoneinfo/Asia/Shanghai:/etc/localtime"        #设置系统时区      - "/usr/share/zoneinfo/Asia/Shanghai:/etc/timezone"  #设置时区      # 假设我们通过docker cp命令把资源文件拷贝到相对路径`./seata-server/resources`中      - "./seata-server/resources:/seata-server/resources"

踩坑：

1. services.seata.environment 下的SEATA_IP不填写的话，会默认将容器IP注册到Nacos，可能导致网络不通。

2. services.seata.environment 下SEATA_PORT，这里特别注意下，当时没有仔细看官网的环境变量描述，直接拷贝了docker-compose.yml，以为这个配置的仅仅是注册到nacos的端口，实际上也是seata服务启动的端口，官网上集群配置第二个是错的。直接启动客户端，总是会连不上第二个seata，客户端日志会打印出这个日志：

   can not connect to xxx.xxx.xxx.xxx:8092 cause:can not register RM,err:register RMROLE error, errMsg:null

   官网的配置：

   
   这里官网上配置启动端口为8092，注册到nacos的端口也是8092 ，但是实际上seata在容器内启动的端口是8091 ，这里导致我就是连不上第二台服务。

配置客户端

Maven依赖

<dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>    <version>${seata.version}</version></dependency>

客户端application.yml配置

seata:  enabled: true  tx-service-group: test_tx_group  service:    vgroup-mapping:      test_tx_group: default  registry:    type: nacos          #注册中心    nacos:      server-addr: ${spring.cloud.nacos.discovery.server-addr}      group: SEATA_GROUP      namespace: seata-server      cluster: default  config:    type: nacos          #配置中心    nacos:      server-addr: ${spring.cloud.nacos.discovery.server-addr}      namespace: seata-server      group: SEATA_GROUP      data-id: seataServer.properties

Seata原理

1. TM开启分布式事务（TM向TC注册全局事务记录）。
2. 按业务场景，编排数据库，服务等事务内资源（RM向TC汇报资源准备状态）。
3. TM结束分布式事务，事务一阶段结束（TM通知TC提交/回滚分布式事务）。
4. TC汇总事务信息，决定分布式事务是提交还是回滚。
5. TC通知所有RM提交/回滚资源。

AT模式是怎么做到对业务无侵入的

事务一阶段

在第一阶段，Seata会拦截业务SQL：

1. 解析SQL语义，找到业务SQL要更新的业务数据，在业务被更新之前，将其保存为“before image”。
2. 执行业务SQL更新业务数据，在业务数据更新之后。
3. 其保存为“after image”，最后生成行锁。

以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

事务二阶段

二阶段提交

在二阶段如果没有异常，顺利提交的话。以为在一阶段，业务SQL已经提交到了数据库，所以Seata框架只需要将一阶段保存的快照数据和行锁删除掉，完成数据清理即可。

二阶段回滚

二阶段如果是回滚的话，seata就需要回滚一阶段已经执行的业务SQL，还原业务数据。其回滚方式便是使用“before image”来还原业务数据。但在还原之前要先校验脏写，对比“数据库当前的业务数据”和after image。如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

Redis的最大占用内存

如何查看Redis最大占用内存？

在配置文件中可以找到配置项maxmemory <bytes>：

# 设置内存使用限制为指定的字节数。# 当达到内存限制时，Redis将根据所选的淘汰策略尝试删除键。## 如果Redis无法根据策略删除键，或者策略设置为“noeviction”，Redis将开始# 对使用更多内存的命令（如SET，LPUSH等）回复错误，并将继续回复只读命令（如GET）。## 当使用Redis作为LRU或LFU缓存，或者设置实例的硬内存限制时，此选项通常很有用（使用“noeviction”策略）。## 警告：如果将副本附加到具有maxmemory的实例，# 需要用于馈送副本的输出缓冲区的大小会从已使用的内存计数中减去，# 以便网络问题/重新同步不会触发循环，其中键被清除，# 反过来，副本的输出缓冲区用DEL清除被清除的键，触发更多键的删除，# 依此类推，直到完全清空数据库。## 简而言之...如果您有附加的副本，则建议您设置较低的maxmemory限制，# 以便系统上有一些空闲RAM可供副本输出缓冲区使用# （但是如果策略是“noeviction”，则不需要这样做）。## maxmemory <bytes>

如果不设置maxmemory或者设置为0（默认就是0），那么在64位操作系统下则不限制内存大小，在32位操作系统下最多能使用3GB的内存。可以使用info memory查看Redis内存使用情况。

Redis是如何删除数据的

Redis过期键的删除策略

如果一个键过期了，那Redis是不是在它过期时马上就从内存中删除它呢？

三种删除策略

立即删除

Redis不可能时时刻刻遍历所有被设置的过期时间的key来检测数据是否已经达到过期时间，然后对它进行删除。立即删除能保证内存中数据的最大新鲜度，因为这样可以保证key在过期后马上被删除，其占用的内存也会随之释放。但是这样对CPU不太友好。因为删除操作会占用CPU的时间，如果刚好碰上了CPU很忙的时候，比如正在做交集或者排序统计的时候，会给CPU造成额外压力，产生大量性能消耗，同时还会影响数据的读取操作。

立即删除对CPU不友好，用CPU性能换内存空间。

惰性删除

数据到达过期时间了，不做处理，等到下一次访问该数据的时候，如果没有过期则返回数据，如果发现过期了，则删除数据并返回数据不存在。这样做的缺点就是对内存不友好。如果一个key已经过期了，但是它实际还保存在Redis的内存中，其占用的内存不会释放，比如Redis中有大量的过期键，而这些过期键有恰好没有被访问到的话，那么这些key也许永远也不会被删除（除非手动删除），这种情况甚至可以看作内存泄漏（一堆垃圾数据占用大量内存），服务器又不会主动去释放它们，这样对于依赖内存的Redis来说肯定是不好的。可以使用lazyfree-lazy-eviction yes开启惰性删除。

惰性删除对内存不友好，用内存空间换CPU性能。

定期删除

定期删除则是上面两种策略的折中，定期删除就是每隔一段时间执行一次删除过期键的操作并通过限制删除操作执行时长和频率来减少删除键对CPU的影响。

周期性轮询Redis库中的时效性，采用随机抽取的策略，利用过期数据占比的方式控制删除频度：

1. 特点1：CPU性能占用设置有峰值，检测频度可自定义设置。
2. 特点2：内存压力不是很大，长期占用内存的冷数据会被持续清理。

比如Redis默认每隔100ms就检查是否有过期的key，有的话就删除（🚨注意这里Redis并不是每隔100ms就将所有key检查一次而是随机地抽取来检查）。因此如果只是采用这种策略地话会导致很多key不会被删除。

定期删除策略地难点就是确定删除操作执行地时长和频率：

• 如果删除操作执行的次数太多或者执行的时间太长，那么就会和立即删除的缺点一样了。
• 如果删除操作执行的次数太少或者执行的时间太短，那么就会和惰性删除的缺点一样了。

所以如果要使用惰性删除的话，服务器必须根据使用情况，合理地设置删除操作的执行时长和频率。

定期删除是一个折中的方法，但是也会存在漏网之鱼。

淘汰策略

上面说到了三种删除策略，都存在一定的缺陷，那么Redis有更好的方案吗？

淘汰策略有哪些

在Redis中一共有8种淘汰策略，默认的是noeviction（不删除任何数据）。

可以从两个维度（过期键中筛选或所有键中筛选）以及四个算法（LRU、LFU、Random、ttl）来区分其余7个淘汰策略。

淘汰策略的作用分别是什么

在Redis配置文件中是这样描述淘汰策略的：

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory# is reached. You can select one from the following behaviors:## volatile-lru -> Evict using approximated LRU, only keys with an expire set.# allkeys-lru -> Evict any key using approximated LRU.# volatile-lfu -> Evict using approximated LFU, only keys with an expire set.# allkeys-lfu -> Evict any key using approximated LFU.# volatile-random -> Remove a random key having an expire set.# allkeys-random -> Remove a random key, any key.# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)# noeviction -> Don't evict anything, just return an error on write operations.## LRU means Least Recently Used# LFU means Least Frequently Used## Both LRU, LFU and volatile-ttl are implemented using approximated# randomized algorithms.## Note: with any of the above policies, when there are no suitable keys for# eviction, Redis will return an error on write operations that require# more memory. These are usually commands that create new keys, add data or# modify existing keys. A few examples are: SET, INCR, HSET, LPUSH, SUNIONSTORE,# SORT (due to the STORE argument), and EXEC (if the transaction includes any# command that requires memory).## The default is:## maxmemory-policy noeviction

MAXMEMORY策略：当达到maxmemory时，Redis将选择怎么删除键。可以从以下行为中选择一个：

• noeviction：默认策略，不淘汰数据；大部分写命令都将返回错误（DEL等少数除外）。
• allkeys-lru：从所有数据中根据LRU算法挑选数据淘汰。
• volatile-lru：从设置了过期时间的数据中根据LRU算法挑选数据淘汰。
• allkeys-random：从所有数据中随机挑选数据淘汰。
• volatile-random：从设置了过期时间的数据中随机挑选数据淘汰。
• volatile-ttl：移除剩余时间最短（TTL最小）的键。
• allkeys-lfu：从所有数据中根据LFU算法挑选数据淘汰（4.0及以上版本可用）。
• volatile-lfu：从设置了过期时间的数据中根据LFU算法挑选数据淘汰（4.0及以上版本可用）。

LRU（Least Recently Used）表示最近最少使用，LFU（Least Frequently Used）表示最少使用频率。LRU、LFU和volatile-ttl都使用近似随机算法实现。
注意：使用上述任何策略时，当没有适当的键可用于淘汰时，Redis将对需要更多内存的写操作返回错误。这些通常是创建新键、添加数据或修改现有键的命令。一些示例包括：SET、INCR、HSET、LPUSH、SUNIONSTORE、SORT（由于SCORE参数）和EXEC（如果事务包含任何需要内存的命令）。

怎样选择使用哪种淘汰策略

• 在所有key都是最近经常使用的情况，那么就选择allkeys-lru，如果不确定使用哪种策略的话，推荐使用allkeys-lru。
• 如果所有key的访问频率都是差不多的，那么可以选择allkeys-random策略。
• 如果对数据有足够的了解，能够为key指定hint（通过expire/ttl指定），那么可以选择volatile-ttl。

LRU以及LFU算法

LRU算法

原生的LRU算法

LRU（Least Recently Used）最近最少使用。优先淘汰最近未被使用的数据，其核心思想是：如果数据最近被访问过，那么将来被访问的几率也更高。LRU底层结构是hash表+双向链表。hash表用于保证查询操作的时间复杂度是O(1)，双向链表用于保证节点插入和节点删除的时间复杂度是O(1)。

为什么是双向链表而不是单链表呢？单链表可以实现头部插入新节点、尾部删除旧节点的时间复杂度都是O(1)，但是对于中间节点时间复杂度是O(n)，因为对于中间节点c，我们需要将该节点c移动到头部，此时只知道他的下一个节点，要知道其上一个节点需要遍历整个链表，时间复杂度为O(n)。

• LRU GET操作：如果节点存在，则将该节点移动到链表头部，并返回节点值。
• LRU PUT操作：
  1. 节点不存在，则新增节点，并将该节点放到链表头部。
  2. 节点存在，则更新节点，并将该节点放到链表头部。

Redis的近似LRU算法

Redis为什么不使用原生的LRU算法呢？

Redis不使用原生LRU算法的主要原因有：

• 原生LRU算法需要双向链表来管理数据，需要额外内存。
• 数据访问时涉及数据移动，有性能损耗。
• Redis现有数据结构需要改造。

Redis使用LRU算法来淘汰过期的缓存数据，以保持内存的整洁和高效。但是LRU算法的实现需要耗费大量的时间和空间，因为它需要跟踪每个缓存数据最后一次被访问的时间戳。为了解决这个问题，Redis使用了一种近似LRU算法，它通过一些简单的逻辑来实现近似LRU算法的效果，同时减少了空间和时间的开销。

Redis的近似LRU算法逻辑

1. 第一次淘汰：随机抽取maxmemory-samples（在配置文件中修改，默认为5）个数据放入待淘汰数据池（evictionPoolEntry）。

   修改maxmemory-samples配置为10的话将非常接近原生LRU效果，但是更消耗CPU。可以参考官方的说明。

   

2. 第二次淘汰：还是随机抽取maxmemory-samples个数据，但是只要数据比待淘汰数据池（evictionPoolEntry）中的任意一个数据的lru小，则将该数据放入至待淘汰数据池。

3. 执行淘汰：挑选待淘汰数据池中lru最小的一条数据进行淘汰。

Redis的近似LRU算法的缺陷

假设现在又三个key分别是A、B、C，在一段时间T内A被访问了6次，B被访问了4次，C被访问了2次，如下所示，从左往右表示时间，|表示开始和结束、-表示一个单位的时间。

|----A----A----A----A-----A---A-------------||-----B--------B----B----------------B------||-------------------C---------------------C-|

当系统内存达到限制，触发LRU算法的时候，开始淘汰key的时候，如果按照LRU算法的逻辑（最近最少使用），那么被淘汰的概率将是A>B>C。然而实际上A的访问次数却是最多的，当我们并不希望A被淘汰，而是希望淘汰的概率是C>B>A的时候，使用LRU算法显然不太合适。淘汰算法的本意是保留那些将来最有可能被再次访问的数据，而LRU算法只是预测最近被访问的数据将来最有可能被访问到。所以在Redis4.0的时候推出了LFU算法（Least Frequently Used）。

LFU算法

LFU（Least Frequently Used）是Redis4.0引入的淘汰算法，它通过key的访问频率、访问时间比较来淘汰key，重点突出的是Frequently Used。

因为LFU算法是根据数据访问的频率来选择被淘汰数据的，所以LFU算法会记录每个数据的访问次数。当一个数据被再次访问时，就会增加该数据的访问次数。但是，访问次数和访问频率这两者并不完全相同。访问频率是指在一定时间内的访问次数。比如现在有两个key分别是A、B。A在15min内被访问了60次，B在5min内被访问了30次。如果是看访问次数的话，毫无疑问A肯定大于B，但是如果是计算访问频率的话，A被访问的频率则是4次/min，而B则是6次/min。所以B的访问频率是肯定大于A的。先被淘汰的key应该是A而不是B。

LFU算法的实现逻辑

在LFU算法中，为每个key维护一个计数器。每次key被访问的时候，计数器增大。计数器越大，可以说明访问越频繁。但是这样做存在一定的问题，上面也说到了访问次数和访问频率并不完全相同。所以只是简单的增加计数器的方法并不完美。访问模式是会频繁变化的，一段时间内频繁访问的key一段时间之后可能会很少被访问到，只增加计数器并不能体现这种趋势。

在Redis中key的对象是redisObject，结构如下：

typedef struct redisObject {    unsigned type:4;    unsigned encoding:4;    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or                            * LFU data (least significant 8 bits frequency                            * and most significant 16 bits access time). */    int refcount;    void *ptr;} robj;

源码中的注释也说到了24bits的lru:LRU_BITS是用来记录LRU time的，然后LFU策略同样可以使用这个字段，但是是分为16bit和8bit来使用，前16bit用来记录最近一次计数器降低的时间Last decr time，单位是分钟，后8bit记录计数器数值counter。

16 bits       8 bits+----------------+--------++ Last decr time | LOG_C  |+----------------+--------+

所以当LFU策略筛选数据时，Redis会在候选集合中，根据lru:LRU_BITS字段的后8bit选择访问次数最少的数据进行淘汰。当访问次数相同时，再根据lru:LRU_BITS字段的前16bit值大小，选择访问时间最久远的数据进行淘汰。可以看到Redis只使用了8bit来记录数据的访问次数，但是8bit记录的最大值是255，当访问量大的时候，如果每次访问都加1，那么很快就会达到最大值255，这时可能大多数数据都是255的访问次数，这样就都会使用前16bit来进行淘汰了，相当于退化成LRU了。但是Redis使用了另外一种计数规则，这个规则还可以使用配置项来控制计数器的增加速度。

# lfu-log-factor 10# lfu-decay-time 1

• lfu-log-factor：用计数器counter当前的值乘以配置项lfu-log-factor再加1，再取其倒数，得到一个p值。然后，把这个p值和一个取值范围在(0,1)间的随机数r值比大小，只有当p>r的时候计数器才会加1。也就是lfu-log-factor越大，counter增长的越慢。配置文件中还列举了使用不同的lfu-log-factor时counter增长情况：

  # +--------+------------+------------+------------+------------+------------+# | factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |# +--------+------------+------------+------------+------------+------------+# | 0      | 104        | 255        | 255        | 255        | 255        |# +--------+------------+------------+------------+------------+------------+# | 1      | 18         | 49         | 255        | 255        | 255        |# +--------+------------+------------+------------+------------+------------+# | 10     | 10         | 18         | 142        | 255        | 255        |# +--------+------------+------------+------------+------------+------------+# | 100    | 8          | 11         | 49         | 143        | 255        |# +--------+------------+------------+------------+------------+------------+

  可以看到counter增长与访问次数呈现对数增长的趋势，随着访问次数越来越大，counter增长的越来越慢。

• lfu-decay-time：用来控制访问次数衰减。LFU策略会计算当前时间和数据最近一次访问时间的差值，并把这个差值换算成以分钟为单位。然后再把这个差值除以lfu-decay-time值，所得的结果就是数据counter 要衰减的值。

lfu-log-factor设置越大，递增概率越低，lfu-decay-time设置越大，衰减速度会越慢。

在应用LFU策略时，一般可以将lfu-log-factor设置为10。 如果业务应用中有短时高频访问的数据的话，建议把lfu-decay-time设置为1。可以快速衰减访问次数。

LRU和LFU算法的区别

总体来说，LRU算法适合用于数据访问具有时间局部性的场景，即最近访问的数据在不久的将来可能再次被访问，而LFU算法适合用于数据访问具有空间局部性的场景，即访问频率高的数据在不久的将来仍然会被频繁访问。