Redis对外暴露最基本的5种结构，比如String、List、Set、ZSet和Hash，而每种结构在底层又能通过不同的数据结构来实现。在service.h中定义了底层使用的数据结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/* 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  /* Encoded as zipmap */
#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */
#define OBJ_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
#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 ziplists */
#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree of listpacks */

对于List，在Redis中的相关代码在t_list.c，在3.0及之前的版本中，对于list的调用为如下代码：

1
2
3
4
5
6
7

if (subject->encoding == REDIS_ENCODING_ZIPLIST) {
    //something
} else if (subject->encoding == REDIS_ENCODING_LINKEDLIST) {
    //something
} else {
    redisPanic("Unknown list encoding");
}

即对于3.0及之前版本，对于list在底层存在两种不同的实现方式，ziplist以及linkedlist，但是在3.2版本开始，对于list的调用变成了如下形式：

1
2
3
4
5

if (subject->encoding == OBJ_ENCODING_QUICKLIST) {
    //something
} else {
    serverPanic("Unknown list encoding");
}

显然，在3.2及之后的版本，Redis使用了quicklist这个新的实现方式来替换以前的ziplist以及linkedlist。

linkedlist

linkedlist即经典的双链表，其定义在3.0及之前版本的adlist.h文件中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/* Node, List, and Iterator are the only data structures used currently. */

typedef struct listNode {
    struct listNode *prev;
    struct listNode *next;
    void *value;
} listNode;

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

每个node包含了三个部分，指向前一个节点和后一个节点的指针，以及一个数据值。而一个list包含了指向首尾的指针、整个list的长度，以及三个函数指针，用来复制节点的值、释放节点的值，以及比较节点内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

#define REDIS_LRU_BITS 24
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;

typedef char *sds;

struct sdshdr {
    unsigned int len;
    unsigned int free;
    char buf[];
};

显然，linkedlist在频繁前后端插入情况下表现良好，但是查找效率比较低，并且比较耗内存。

ziplist

在Redis源码中，ziplist的实现在ziplist.c文件中，一开头就介绍了，ziplist是一种特殊编码的节省内存空间的双链表，能以O(1)的时间复杂度在两端push和pop数据，具有如下结构：

<zlbytes><zltail><zllen><entry><entry><zlend>

• zlbytes是一个unsigned integer，保存ziplist占用的总内存空间，在重新分配内存时，借助这个字段可以不用遍历整个ziplist；
• zltail是指向最后一个entry的偏移量，这样对于尾部的操作不用去遍历所有entry；
• zllen固定两个字节长度，表示entry的数量，最大能表示2^16-2个entry，如果超过了，则其值为2^16-1，需要遍历entry才能知道具体的数量；
• zlend固定一个字节，值固定为255，表示ziplist的结尾。

zlbytes、zltail、zllen统称为ziplist的header，其空间总占用定义如下：

1

#define ZIPLIST_HEADER_SIZE     (sizeof(uint32_t)*2+sizeof(uint16_t))

新建一个空的ziplist的代码如下：

1
2
3
4
5
6
7
8
9
10

/* Create a new empty ziplist. */
unsigned char *ziplistNew(void) {
    unsigned int bytes = ZIPLIST_HEADER_SIZE+1;
    unsigned char *zl = zmalloc(bytes);
    ZIPLIST_BYTES(zl) = intrev32ifbe(bytes);
    ZIPLIST_TAIL_OFFSET(zl) = intrev32ifbe(ZIPLIST_HEADER_SIZE);
    ZIPLIST_LENGTH(zl) = 0;
    zl[bytes-1] = ZIP_END;
    return zl;
}

entry的定义如下：

1
2
3
4
5
6
7

typedef struct zlentry {
    unsigned int prevrawlensize, prevrawlen;
    unsigned int lensize, len;
    unsigned int headersize;
    unsigned char encoding;
    unsigned char *p;
} zlentry;

prevrawlen和len均采用变长编码的方式来存储数据。

其中prevrawlen表示前一个节点的长度，prevrawlensize用来表示prevrawlen的大小，有1字节和5字节两种。如果prevrawlen小于254字节，则只需要一字节来保存，如果大于等于254字节，则需要5字节保存，第一个字节被置为254，其余4字节用来保存实际长度；len为当前节点长度 lensize为编码len所需的字节大小；headersize为当前节点的header大小；encoding为节点的编码方式；*p为指向节点的指针。

redis通过如下的代码来获取prevrawlen和prevrawlensize。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/* Encode the length of the previous entry and write it to "p". Return the
 * number of bytes needed to encode this length if "p" is NULL. */
static unsigned int zipPrevEncodeLength(unsigned char *p, unsigned int len) {
    if (p == NULL) {
        return (len < ZIP_BIGLEN) ? 1 : sizeof(len)+1;
    } else {
        if (len < ZIP_BIGLEN) {
            p[0] = len;
            return 1;
        } else {
            p[0] = ZIP_BIGLEN;
            memcpy(p+1,&len,sizeof(len));
            memrev32ifbe(p+1);
            return 1+sizeof(len);
        }
    }
}

对于lensize和len，这二者的值和entry内存储的类型有关。如果存储string，则前两个bit位用来存储string的编码方式，后面跟上实际的长度。如果存储integer，则前两个bit位置为1，随后两个bit位指定integer的类型。具体如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

* |00pppppp| - 1 byte
*      String value with length less than or equal to 63 bytes (6 bits).
* |01pppppp|qqqqqqqq| - 2 bytes
*      String value with length less than or equal to 16383 bytes (14 bits).
* |10______|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| - 5 bytes
*      String value with length greater than or equal to 16384 bytes.
* |11000000| - 1 byte
*      Integer encoded as int16_t (2 bytes).
* |11010000| - 1 byte
*      Integer encoded as int32_t (4 bytes).
* |11100000| - 1 byte
*      Integer encoded as int64_t (8 bytes).
* |11110000| - 1 byte
*      Integer encoded as 24 bit signed (3 bytes).
* |11111110| - 1 byte
*      Integer encoded as 8 bit signed (1 byte).
* |1111xxxx| - (with xxxx between 0000 and 1101) immediate 4 bit integer.
*      Unsigned integer from 0 to 12. The encoded value is actually from
*      1 to 13 because 0000 and 1111 can not be used, so 1 should be
*      subtracted from the encoded 4 bit value to obtain the right value.
* |11111111| - End of ziplist.

从ZIP_DECODE_LENGTH可以看出具体的解码过程和每个字段的存储位置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

/* Different encoding/length possibilities */
#define ZIP_STR_MASK 0xc0
#define ZIP_INT_MASK 0x30
#define ZIP_STR_06B (0 << 6)
#define ZIP_STR_14B (1 << 6)
#define ZIP_STR_32B (2 << 6)

/* Extract the encoding from the byte pointed by 'ptr' and set it into
 * 'encoding'. */
#define ZIP_ENTRY_ENCODING(ptr, encoding) do {  \
    (encoding) = (ptr[0]); \
    if ((encoding) < ZIP_STR_MASK) (encoding) &= ZIP_STR_MASK; \
} while(0)

/* Decode the length encoded in 'ptr'. The 'encoding' variable will hold the
 * entries encoding, the 'lensize' variable will hold the number of bytes
 * required to encode the entries length, and the 'len' variable will hold the
 * entries length. */
#define ZIP_DECODE_LENGTH(ptr, encoding, lensize, len) do {                    \
    ZIP_ENTRY_ENCODING((ptr), (encoding));                                     \
    if ((encoding) < ZIP_STR_MASK) {                                           \
        if ((encoding) == ZIP_STR_06B) {                                       \
            (lensize) = 1;                                                     \
            (len) = (ptr)[0] & 0x3f;                                           \
        } else if ((encoding) == ZIP_STR_14B) {                                \
            (lensize) = 2;                                                     \
            (len) = (((ptr)[0] & 0x3f) << 8) | (ptr)[1];                       \
        } else if (encoding == ZIP_STR_32B) {                                  \
            (lensize) = 5;                                                     \
            (len) = ((ptr)[1] << 24) |                                         \
                    ((ptr)[2] << 16) |                                         \
                    ((ptr)[3] <<  8) |                                         \
                    ((ptr)[4]);                                                \
        } else {                                                               \
            assert(NULL);                                                      \
        }                                                                      \
    } else {                                                                   \
        (lensize) = 1;                                                         \
        (len) = zipIntSize(encoding);                                          \
    }                                                                          \
} while(0);

对len字段进行计算的过程如下面的函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

/* Encode the length 'rawlen' writing it in 'p'. If p is NULL it just returns
 * the amount of bytes required to encode such a length. */
static unsigned int zipEncodeLength(unsigned char *p, unsigned char encoding, unsigned int rawlen) {
    unsigned char len = 1, buf[5];

    if (ZIP_IS_STR(encoding)) {
        /* Although encoding is given it may not be set for strings,
         * so we determine it here using the raw length. */
        if (rawlen <= 0x3f) {
            if (!p) return len;
            buf[0] = ZIP_STR_06B | rawlen;
        } else if (rawlen <= 0x3fff) {
            len += 1;
            if (!p) return len;
            buf[0] = ZIP_STR_14B | ((rawlen >> 8) & 0x3f);
            buf[1] = rawlen & 0xff;
        } else {
            len += 4;
            if (!p) return len;
            buf[0] = ZIP_STR_32B;
            buf[1] = (rawlen >> 24) & 0xff;
            buf[2] = (rawlen >> 16) & 0xff;
            buf[3] = (rawlen >> 8) & 0xff;
            buf[4] = rawlen & 0xff;
        }
    } else {
        /* Implies integer encoding, so length is always 1. */
        if (!p) return len;
        buf[0] = encoding;
    }

    /* Store this length at p */
    memcpy(p,buf,len);
    return len;
}

可以看到，对于integer编码，长度恒为1，否则读取实际的string的长度值。

而实际上，encoding又是保存在len字段的第一个字节，判断是否是字符串的方法如下：

1
2
3

#define ZIP_STR_MASK 0xc0
/* Macro to determine type */
#define ZIP_IS_STR(enc) (((enc) & ZIP_STR_MASK) < ZIP_STR_MASK)

encoding和p表示元素编码和内容，其具体的定义可参考如下函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

#define ZIP_INT_16B (0xc0 | 0<<4)
#define ZIP_INT_32B (0xc0 | 1<<4)
#define ZIP_INT_64B (0xc0 | 2<<4)
#define ZIP_INT_24B (0xc0 | 3<<4)
#define ZIP_INT_8B 0xfe
/* 4 bit integer immediate encoding */
#define ZIP_INT_IMM_MASK 0x0f
#define ZIP_INT_IMM_MIN 0xf1    /* 11110001 */
#define ZIP_INT_IMM_MAX 0xfd    /* 11111101 */

/* Check if string pointed to by 'entry' can be encoded as an integer.
 * Stores the integer value in 'v' and its encoding in 'encoding'. */
static int zipTryEncoding(unsigned char *entry, unsigned int entrylen, long long *v, unsigned char *encoding) {
    long long value;

    if (entrylen >= 32 || entrylen == 0) return 0;
    if (string2ll((char*)entry,entrylen,&value)) {
        /* Great, the string can be encoded. Check what's the smallest
         * of our encoding types that can hold this value. */
        if (value >= 0 && value <= 12) {
            *encoding = ZIP_INT_IMM_MIN+value;
        } else if (value >= INT8_MIN && value <= INT8_MAX) {
            *encoding = ZIP_INT_8B;
        } else if (value >= INT16_MIN && value <= INT16_MAX) {
            *encoding = ZIP_INT_16B;
        } else if (value >= INT24_MIN && value <= INT24_MAX) {
            *encoding = ZIP_INT_24B;
        } else if (value >= INT32_MIN && value <= INT32_MAX) {
            *encoding = ZIP_INT_32B;
        } else {
            *encoding = ZIP_INT_64B;
        }
        *v = value;
        return 1;
    }
    return 0;
}

/* Convert a string into a long long. Returns 1 if the string could be parsed
 * into a (non-overflowing) long long, 0 otherwise. The value will be set to
 * the parsed value when appropriate. */
int string2ll(const char *s, size_t slen, long long *value);

显然如上面的描述，对于entrylen>=32不用做处理，接下来设置encoding为具体的值。

对于ziplist的push操作，在ziplistPush中具体定义，简单描述其流程如下：

1. 获取指向尾部或者头部节点的指针p；
2. 获取p的prevlensize和prevlen；
3. 通过prevlen以及coding、实际插入数据来计算待插入的节点reqlen；
4. 如不在队尾插入，则需要校验p对应节点的prelen是否够reqlen使用，不够需要扩展，够不进行压缩，防止连锁更新；
5. 更新队尾偏移量；
6. 判断是否需要连锁更新；
7. 保存插入节点内容；
8. ziplist的长度加一。

连锁更新的执行函数以及解释如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/* When an entry is inserted, we need to set the prevlen field of the next
 * entry to equal the length of the inserted entry. It can occur that this
 * length cannot be encoded in 1 byte and the next entry needs to be grow
 * a bit larger to hold the 5-byte encoded prevlen. This can be done for free,
 * because this only happens when an entry is already being inserted (which
 * causes a realloc and memmove). However, encoding the prevlen may require
 * that this entry is grown as well. This effect may cascade throughout
 * the ziplist when there are consecutive entries with a size close to
 * ZIP_BIGLEN, so we need to check that the prevlen can be encoded in every
 * consecutive entry.
 *
 * Note that this effect can also happen in reverse, where the bytes required
 * to encode the prevlen field can shrink. This effect is deliberately ignored,
 * because it can cause a "flapping" effect where a chain prevlen fields is
 * first grown and then shrunk again after consecutive inserts. Rather, the
 * field is allowed to stay larger than necessary, because a large prevlen
 * field implies the ziplist is holding large entries anyway.
 *
 * The pointer "p" points to the first entry that does NOT need to be
 * updated, i.e. consecutive fields MAY need an update. */
static unsigned char *__ziplistCascadeUpdate(unsigned char *zl, unsigned char *p);

如上面的描述，可以得到ziplist的简易示意图如下，每个节点是单独的entry，每个entry中一个字段表示前一个entry的长度（长度小于254时采用一个字节编码，否则采用5个字节），一个encoding字段保存当前节点的编码方式和数据长度，content保存着entry的具体数据，可以是字符数组或整数，如果是整数且在0-12之间则不再保存content。

ziplist可以很方便的拿到头节点或者尾节点，由于每个节点都保存前一个节点的长度，因此对于任意节点可以方便的前后遍历。相比linkedlist，除了链表结构节省少量空间外，每个entry可以节省大量的额外内存（最大额外空间才10字节，对于不大于12的正整数，甚至不用content空间来进行存储）。对于主要是pop或push并且每个元素长度不大的场景来说，ziplist相比于linkedlist有较大的优势。

但是如前面所说，通过ZIP_BIGLEN即254这个分界点来确认prevlen的长度，如果每一个节点的长度原本都是253，如果在头部插入时下一个节点的prevlen需要扩展，则会导致整个ziplist都进行更新。在删除时也可能出现类似情况。但是这种情况出现的概率不大，并且在使用ziplist时，entry总量不大，因此可以忽略不计。

ziplist的弊端也很明显了，对于较多的entry或者entry长度较大时，需要大量的连续内存，并且节省的空间比例相对不在占优势，就可以考虑使用其他结构了。

QuickList

前面介绍的两种结构，一种耗内存但是能应付数据较大（数量或者单个的长度）的情况，但是插入和删除成本低，而另一个则在小规模数据情况下表现很好并且非常节省内存，数据规模大时会有问题，并且插入和删除成本高。显然这时候QuickList该上场了。这时候让我们忘记3.0及之前的版本，开始进入新的结构吧。

首先看代码定义，quicklist.h：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

/* Node, quicklist, and Iterator are the only data structures used currently. */

/* quicklistNode is a 32 byte struct describing a ziplist for a quicklist.
 * We use bit fields keep the quicklistNode at 32 bytes.
 * count: 16 bits, max 65536 (max zl bytes is 65k, so max count actually < 32k).
 * encoding: 2 bits, RAW=1, LZF=2.
 * container: 2 bits, NONE=1, ZIPLIST=2.
 * recompress: 1 bit, bool, true if node is temporarry decompressed for usage.
 * attempted_compress: 1 bit, boolean, used for verifying during testing.
 * extra: 10 bits, free for future use; pads out the remainder of 32 bits */
typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;             /* ziplist size in bytes */
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

/* quicklistLZF is a 4+N byte struct holding 'sz' followed by 'compressed'.
 * 'sz' is byte length of 'compressed' field.
 * 'compressed' is LZF data with total (compressed) length 'sz'
 * NOTE: uncompressed length is stored in quicklistNode->sz.
 * When quicklistNode->zl is compressed, node->zl points to a quicklistLZF */
typedef struct quicklistLZF {
    unsigned int sz; /* LZF size in bytes*/
    char compressed[];
} quicklistLZF;

/* quicklist is a 40 byte struct (on 64-bit systems) describing a quicklist.
 * 'count' is the number of total entries.
 * 'len' is the number of quicklist nodes.
 * 'compress' is: -1 if compression disabled, otherwise it's the number
 *                of quicklistNodes to leave uncompressed at ends of quicklist.
 * 'fill' is the user-requested (or default) fill factor. */
typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;        /* total count of all entries in all ziplists */
    unsigned long len;          /* number of quicklistNodes */
    int fill : 16;              /* fill factor for individual nodes */
    unsigned int compress : 16; /* depth of end nodes not to compress;0=off */
} quicklist;

乍一看貌似很复杂，但是整个结构却是非常的清晰。

首先是quicklistNode，这是quicklist的节点，可以看做对ziplist的高层封装。包含指向前后节点的指针，以及指向实际ziplist的指针zl，从定义上看，quicklist的节点上支持了压缩能力，并且多个字段通过位域方式申明内存节省空间。

而quicklistLZF用来存储压缩后的ziplist，占用空间4+N字节，其中N为压缩后的实际长度。

通过quicklist将quicklistNode连接起来，形成了完整的quicklist结构。由于quicklist同时包含了ziplist和quicklist的结构，因此每个quicklistNode的大小就非常重要：如果太大其就更接近ziplist，影响插入效率；如果太小就更接近quicklist，浪费空间。其通过fill字段来控制大小，正数表示单个节点允许的最大数量，最大为2^15，负数表示单个节点的内存空间大小，其中-1表示单个节点最多存储4kb，-2表示单个节点最多存储8kb，以此类推，-5表示单个节点最多保存64kb，在创建时默认的值为-2。这个字段的设置代码即判定是否还能继续插入数据的代码如下。compress表示压缩的深度，0表示不压缩，正数表示头尾多少个节点不压缩其余节点都压缩。

1
2
3
4
5
6
7
8
9

#define FILL_MAX (1 << 15)
void quicklistSetFill(quicklist *quicklist, int fill) {
    if (fill > FILL_MAX) {
        fill = FILL_MAX;
    } else if (fill < -5) {
        fill = -5;
    }
    quicklist->fill = fill;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/* Maximum size in bytes of any multi-element ziplist.
 * Larger values will live in their own isolated ziplists. */
#define SIZE_SAFETY_LIMIT 8192
#define sizeMeetsSafetyLimit(sz) ((sz) <= SIZE_SAFETY_LIMIT)

REDIS_STATIC int _quicklistNodeAllowInsert(const quicklistNode *node,
                                           const int fill, const size_t sz) {
    if (unlikely(!node))
        return 0;

    int ziplist_overhead;
    /* size of previous offset */
    if (sz < 254)
        ziplist_overhead = 1;
    else
        ziplist_overhead = 5;

    /* size of forward offset */
    if (sz < 64)
        ziplist_overhead += 1;
    else if (likely(sz < 16384))
        ziplist_overhead += 2;
    else
        ziplist_overhead += 5;

    /* new_sz overestimates if 'sz' encodes to an integer type */
    unsigned int new_sz = node->sz + sz + ziplist_overhead;
    if (likely(_quicklistNodeSizeMeetsOptimizationRequirement(new_sz, fill)))
        return 1;
    else if (!sizeMeetsSafetyLimit(new_sz))
        return 0;
    else if ((int)node->count < fill)
        return 1;
    else
        return 0;
}

quicklist使用lzf进行压缩，具体压缩算法略过，压缩节点的代码如下，开辟新的空间压缩ziplist数据，并且释放node->zl原有的内存，最后指向压缩后的数据并修改其他属性值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

/* Minimum ziplist size in bytes for attempting compression. */
#define MIN_COMPRESS_BYTES 48

/* Compress the ziplist in 'node' and update encoding details.
 * Returns 1 if ziplist compressed successfully.
 * Returns 0 if compression failed or if ziplist too small to compress. */
REDIS_STATIC int __quicklistCompressNode(quicklistNode *node) {
#ifdef REDIS_TEST
    node->attempted_compress = 1;
#endif

    /* Don't bother compressing small values */
    if (node->sz < MIN_COMPRESS_BYTES)
        return 0;

    quicklistLZF *lzf = zmalloc(sizeof(*lzf) + node->sz);

    /* Cancel if compression fails or doesn't compress small enough */
    if (((lzf->sz = lzf_compress(node->zl, node->sz, lzf->compressed,
                                 node->sz)) == 0) ||
        lzf->sz + MIN_COMPRESS_IMPROVE >= node->sz) {
        /* lzf_compress aborts/rejects compression if value not compressable. */
        zfree(lzf);
        return 0;
    }
    lzf = zrealloc(lzf, sizeof(*lzf) + lzf->sz);
    zfree(node->zl);
    node->zl = (unsigned char *)lzf;
    node->encoding = QUICKLIST_NODE_ENCODING_LZF;
    node->recompress = 0;
    return 1;
}

同样，解压的代码如下，开辟新的空间存放解压后的数据，同时释放压缩数据的空间，node->zl指向新的解压后的数据，最后修改其他属性值。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/* Uncompress the ziplist in 'node' and update encoding details.
 * Returns 1 on successful decode, 0 on failure to decode. */
REDIS_STATIC int __quicklistDecompressNode(quicklistNode *node) {
#ifdef REDIS_TEST
    node->attempted_compress = 0;
#endif

    void *decompressed = zmalloc(node->sz);
    quicklistLZF *lzf = (quicklistLZF *)node->zl;
    if (lzf_decompress(lzf->compressed, lzf->sz, decompressed, node->sz) == 0) {
        /* Someone requested decompress, but we can't decompress.  Not good. */
        zfree(decompressed);
        return 0;
    }
    zfree(lzf);
    node->zl = decompressed;
    node->encoding = QUICKLIST_NODE_ENCODING_RAW;
    return 1;
}

在头尾插入节点如下，如果单个ziplist满足上面说到的大小、数量限制，则使用ziplist的push函数直接插入，否则新建一个节点用来插入即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

/* Add new entry to head node of quicklist.
 *
 * Returns 0 if used existing head.
 * Returns 1 if new head created. */
int quicklistPushHead(quicklist *quicklist, void *value, size_t sz) {
    quicklistNode *orig_head = quicklist->head;
    if (likely(
            _quicklistNodeAllowInsert(quicklist->head, quicklist->fill, sz))) {
        quicklist->head->zl =
            ziplistPush(quicklist->head->zl, value, sz, ZIPLIST_HEAD);
        quicklistNodeUpdateSz(quicklist->head);
    } else {
        quicklistNode *node = quicklistCreateNode();
        node->zl = ziplistPush(ziplistNew(), value, sz, ZIPLIST_HEAD);

        quicklistNodeUpdateSz(node);
        _quicklistInsertNodeBefore(quicklist, quicklist->head, node);
    }
    quicklist->count++;
    quicklist->head->count++;
    return (orig_head != quicklist->head);
}

/* Add new entry to tail node of quicklist.
 *
 * Returns 0 if used existing tail.
 * Returns 1 if new tail created. */
int quicklistPushTail(quicklist *quicklist, void *value, size_t sz) {
    quicklistNode *orig_tail = quicklist->tail;
    if (likely(
            _quicklistNodeAllowInsert(quicklist->tail, quicklist->fill, sz))) {
        quicklist->tail->zl =
            ziplistPush(quicklist->tail->zl, value, sz, ZIPLIST_TAIL);
        quicklistNodeUpdateSz(quicklist->tail);
    } else {
        quicklistNode *node = quicklistCreateNode();
        node->zl = ziplistPush(ziplistNew(), value, sz, ZIPLIST_TAIL);

        quicklistNodeUpdateSz(node);
        _quicklistInsertNodeAfter(quicklist, quicklist->tail, node);
    }
    quicklist->count++;
    quicklist->tail->count++;
    return (orig_tail != quicklist->tail);
}

除此之外，quicklist还提供了merge、旋转、指定节点前后插入等功能，均在quicklist.[h|c]中，其主要在linkedlist的基础上，对于每个节点融合ziplist的特征，并且对于中间节点还提供了lzf压缩的能力，综合了linkedlist和ziplist的有点，同时具有节省内存、插入删除数据高效的特点。整个quicklist的简单示意图可如下图。

性能对比

测试平台：macOS Catalina 10.15.2，Intel Core i7 2.2GHz，16GB 1600MHz DDR3

因为系统上已有通过homebrew安装64位的5.0.7版本Redis，因此先看这个版本。因为打算对比quicklist、ziplist以及linkedlist，所以选择list结构进行测试。为了测试存储空间、插入删除性能，在不同测试中均使用redis-benchmark执行相同的测试。

对于ziplist以及linkedlist，使用本地编译的64位3.0.6版本。

quicklist的性能

首先向quicklist插入1000条定长数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

$ redis-benchmark -t lpush -n 1000
====== LPUSH ======
  1000 requests completed in 0.02 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.90% <= 1 milliseconds
100.00% <= 1 milliseconds
55555.56 requests per second

$ redis-cli
127.0.0.1:6379> memory usage mylist
(integer) 5131

实际使用5131字节，相当于每个元素使用约5.1字节，空间利用率约58.5%（实际插入的是”xxx“，三个字节长）。

再向quicklist的list中插入1000000个定长数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

$ redis-benchmark -t lpush -n 1000000

====== LPUSH ======
  1000000 requests completed in 12.36 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.44% <= 1 milliseconds
99.85% <= 2 milliseconds
99.91% <= 3 milliseconds
99.93% <= 4 milliseconds
99.94% <= 5 milliseconds
99.95% <= 6 milliseconds
99.96% <= 7 milliseconds
99.97% <= 8 milliseconds
99.99% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 11 milliseconds
100.00% <= 17 milliseconds
100.00% <= 18 milliseconds
100.00% <= 18 milliseconds
80893.05 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7fd2ca51c2e0 refcount:1 encoding:quicklist serializedlength:72148 lru:462431 lru_seconds_idle:57 ql_nodes:612 ql_avg_node:1633.99 ql_ziplist_max:-2 ql_compressed:0 ql_uncompressed_size:5006732

$ redis-benchmark -t lpop -n 1000000
====== LPOP ======
  1000000 requests completed in 13.80 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.47% <= 1 milliseconds
99.65% <= 2 milliseconds
99.80% <= 3 milliseconds
99.87% <= 4 milliseconds
99.89% <= 5 milliseconds
99.91% <= 6 milliseconds
99.92% <= 7 milliseconds
99.94% <= 8 milliseconds
99.95% <= 9 milliseconds
99.97% <= 10 milliseconds
99.97% <= 11 milliseconds
99.98% <= 12 milliseconds
99.98% <= 13 milliseconds
99.98% <= 14 milliseconds
99.99% <= 15 milliseconds
99.99% <= 17 milliseconds
99.99% <= 21 milliseconds
99.99% <= 22 milliseconds
99.99% <= 26 milliseconds
100.00% <= 27 milliseconds
100.00% <= 29 milliseconds
100.00% <= 30 milliseconds
100.00% <= 30 milliseconds
72442.77 requests per second

可以看出，其插入速度基本都能保持在1ms以内，并且在未压缩情况下（value空间小于MIN_COMPRESS_BYTES即48字节，不执行压缩），共有612个quicklist节点，总共占用5006732字节内存，即每个值仅占用约5字节，而实际插入的值"xxx"本身是3字节长，约60%的空间利用率。弹出速度也大量保持在1ms以内。

接着尝试插入更长的数据，先不开启quicklist的，再看看插入和弹出性能以及内存占用情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

$ redis-benchmark -n 1000000 lpush mylist "mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial"
====== lpush mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial ======
  1000000 requests completed in 14.27 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

97.91% <= 1 milliseconds
99.61% <= 2 milliseconds
99.83% <= 3 milliseconds
99.88% <= 4 milliseconds
99.90% <= 5 milliseconds
99.92% <= 6 milliseconds
99.93% <= 7 milliseconds
99.94% <= 8 milliseconds
99.95% <= 9 milliseconds
99.95% <= 10 milliseconds
99.96% <= 11 milliseconds
99.98% <= 12 milliseconds
99.98% <= 13 milliseconds
99.99% <= 16 milliseconds
99.99% <= 17 milliseconds
99.99% <= 18 milliseconds
100.00% <= 19 milliseconds
100.00% <= 28 milliseconds
100.00% <= 28 milliseconds
70081.99 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7fd2cfa025d0 refcount:1 encoding:quicklist serializedlength:29294298 lru:465570 lru_seconds_idle:6 ql_nodes:58824 ql_avg_node:17.00 ql_ziplist_max:-2 ql_compressed:0 ql_uncompressed_size:470411768
127.0.0.1:6379> memory usage mylist
(integer) 428062336

$ redis-benchmark -t lpop -n 1000000
====== LPOP ======
  1000000 requests completed in 13.50 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.24% <= 1 milliseconds
99.58% <= 2 milliseconds
99.77% <= 3 milliseconds
99.85% <= 4 milliseconds
99.88% <= 5 milliseconds
99.91% <= 6 milliseconds
99.94% <= 7 milliseconds
99.95% <= 8 milliseconds
99.96% <= 9 milliseconds
99.96% <= 10 milliseconds
99.97% <= 11 milliseconds
99.98% <= 12 milliseconds
99.98% <= 13 milliseconds
99.99% <= 14 milliseconds
99.99% <= 15 milliseconds
99.99% <= 16 milliseconds
100.00% <= 17 milliseconds
100.00% <= 18 milliseconds
74057.62 requests per second

可以看出，随着字符串的变长，实际的插入、弹出时间相差不大，每个元素占用空间470411768/1000000≈470字节，约98.5%的空间利用率。实际内存空间使用428062336字节，约408M。

如果开启压缩，设置list-compress-depth为1，再进行相同的测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

$ redis-benchmark -n 1000000 lpush mylist "mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial"
====== lpush mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial ======
  1000000 requests completed in 13.99 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.09% <= 1 milliseconds
99.72% <= 2 milliseconds
99.86% <= 3 milliseconds
99.90% <= 4 milliseconds
99.92% <= 5 milliseconds
99.94% <= 6 milliseconds
99.94% <= 7 milliseconds
99.95% <= 8 milliseconds
99.96% <= 9 milliseconds
99.96% <= 10 milliseconds
99.97% <= 11 milliseconds
99.97% <= 12 milliseconds
99.98% <= 13 milliseconds
99.99% <= 14 milliseconds
99.99% <= 15 milliseconds
100.00% <= 24 milliseconds
100.00% <= 25 milliseconds
100.00% <= 27 milliseconds
71489.85 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7fd2ca4355f0 refcount:1 encoding:quicklist serializedlength:29294298 lru:465449 lru_seconds_idle:6 ql_nodes:58824 ql_avg_node:17.00 ql_ziplist_max:-2 ql_compressed:1 ql_uncompressed_size:470411768
127.0.0.1:6379> memory usage mylist
(integer) 74930099

$ redis-benchmark -t lpop -n 1000000
====== LPOP ======
  1000000 requests completed in 13.63 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.42% <= 1 milliseconds
99.69% <= 2 milliseconds
99.84% <= 3 milliseconds
99.88% <= 4 milliseconds
99.90% <= 5 milliseconds
99.91% <= 6 milliseconds
99.93% <= 7 milliseconds
99.95% <= 8 milliseconds
99.98% <= 9 milliseconds
99.98% <= 10 milliseconds
99.99% <= 11 milliseconds
99.99% <= 12 milliseconds
99.99% <= 14 milliseconds
100.00% <= 31 milliseconds
100.00% <= 32 milliseconds
100.00% <= 32 milliseconds
73351.42 requests per second

可以看出，在进行lzf压缩后，插入、弹出元素的时间相差无几，但是实际的空间占用降到了74930099，即约71M，空间节省极大。

linkedlist的性能

在redis中，通过两处配置定义list底层使用的数据结构。list-max-ziplist-entries表示ziplist元素最大值，list-max-ziplist-value表示单个节点的最大长度。

1
2
3
4
5

# Similarly to hashes, small lists are also encoded in a special way in order
# to save a lot of space. The special representation is only used when
# you are under the following limits:
list-max-ziplist-entries 512
list-max-ziplist-value 64

如果元素的值的长度或者数量超过了配置值的任何一个，则ziplist会自动转变为linkedlist并且不会退化回ziplist，转换的代码如下，可以看到只允许转为REDIS_ENCODING_LINKEDLIST的单向转换。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

void listTypeConvert(robj *subject, int enc) {
    listTypeIterator *li;
    listTypeEntry entry;
    redisAssertWithInfo(NULL,subject,subject->type == REDIS_LIST);

    if (enc == REDIS_ENCODING_LINKEDLIST) {
        list *l = listCreate();
        listSetFreeMethod(l,decrRefCountVoid);

        /* listTypeGet returns a robj with incremented refcount */
        li = listTypeInitIterator(subject,0,REDIS_TAIL);
        while (listTypeNext(li,&entry)) listAddNodeTail(l,listTypeGet(&entry));
        listTypeReleaseIterator(li);

        subject->encoding = REDIS_ENCODING_LINKEDLIST;
        zfree(subject->ptr);
        subject->ptr = l;
    } else {
        redisPanic("Unsupported list conversion");
    }
}

因此启动redis-server时显式的指定list-max-ziplist-entries为0即可使用linkedlist进行测试。

插入100条数据：

1
2
3
4
5
6
7
8
9
10

$ redis-benchmark -t lpush -n 100
====== LPUSH ======
  1000 requests completed in 0.01 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
66666.67 requests per second

通过redisinsight分析其实际使用内存44kb，即单个元素占用约45字节，空间利用率约6.7%。

同样，插入1000000个定长数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

$ redis-benchmark -t lpush -n 1000000

====== LPUSH ======
  1000000 requests completed in 13.08 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.75% <= 1 milliseconds
99.72% <= 2 milliseconds
99.83% <= 3 milliseconds
99.87% <= 4 milliseconds
99.90% <= 5 milliseconds
99.92% <= 6 milliseconds
99.94% <= 7 milliseconds
99.95% <= 8 milliseconds
99.96% <= 9 milliseconds
99.96% <= 10 milliseconds
99.97% <= 11 milliseconds
99.97% <= 12 milliseconds
99.99% <= 13 milliseconds
100.00% <= 28 milliseconds
100.00% <= 29 milliseconds
100.00% <= 30 milliseconds
76440.91 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7fc41b433aa0 refcount:1 encoding:linkedlist serializedlength:4000005 lru:472156 lru_seconds_idle:24


$ redis-benchmark -t lpop -n 1000000
====== LPOP ======
  1000000 requests completed in 13.80 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.47% <= 1 milliseconds
99.65% <= 2 milliseconds
99.80% <= 3 milliseconds
99.87% <= 4 milliseconds
99.89% <= 5 milliseconds
99.91% <= 6 milliseconds
99.92% <= 7 milliseconds
99.94% <= 8 milliseconds
99.95% <= 9 milliseconds
99.97% <= 10 milliseconds
99.97% <= 11 milliseconds
99.98% <= 12 milliseconds
99.98% <= 13 milliseconds
99.98% <= 14 milliseconds
99.99% <= 15 milliseconds
99.99% <= 17 milliseconds
99.99% <= 21 milliseconds
99.99% <= 22 milliseconds
99.99% <= 26 milliseconds
100.00% <= 27 milliseconds
100.00% <= 29 milliseconds
100.00% <= 30 milliseconds
100.00% <= 30 milliseconds
72442.77 requests per second

其实际使用内存43M，即单个节点使用约45字节的空间，空间利用率约6.7%。但是在插入与弹出的时间消耗上，和quicklist相差不大。

再看看插入长字符串的情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

$ redis-benchmark -n 1000000 lpush mylist "mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial"
====== lpush mylist mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial ======
  1000000 requests completed in 14.24 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

97.33% <= 1 milliseconds
99.64% <= 2 milliseconds
99.83% <= 3 milliseconds
99.87% <= 4 milliseconds
99.91% <= 5 milliseconds
99.93% <= 6 milliseconds
99.94% <= 7 milliseconds
99.94% <= 8 milliseconds
99.97% <= 9 milliseconds
99.98% <= 10 milliseconds
99.98% <= 11 milliseconds
99.99% <= 12 milliseconds
99.99% <= 13 milliseconds
100.00% <= 15 milliseconds
100.00% <= 16 milliseconds
100.00% <= 17 milliseconds
100.00% <= 18 milliseconds
100.00% <= 25 milliseconds
100.00% <= 25 milliseconds
70239.52 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7fc616f03f80 refcount:1 encoding:linkedlist serializedlength:371000005 lru:473445 lru_seconds_idle:26

$ redis-benchmark -t lpop -n 1000000
====== LPOP ======
  1000000 requests completed in 12.65 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.67% <= 1 milliseconds
99.78% <= 2 milliseconds
99.89% <= 3 milliseconds
99.90% <= 4 milliseconds
99.92% <= 5 milliseconds
99.95% <= 6 milliseconds
99.95% <= 7 milliseconds
99.97% <= 8 milliseconds
99.98% <= 9 milliseconds
99.98% <= 10 milliseconds
99.98% <= 11 milliseconds
99.99% <= 12 milliseconds
100.00% <= 13 milliseconds
100.00% <= 13 milliseconds
79026.39 requests per second

通过redisinsight分析其实际使用内存488M，即单个节点使用约512字节的空间，空间利用率约90.4%。但是在插入与弹出的时间消耗上，和quicklist以及短字符串插入都相差不大。

ziplist的性能

最后再看看ziplist的表现。设置list-max-ziplist-entries与list-max-ziplist-value为较大的值来启动redis-server，保证使用ziplist编码来实现list。我们先插入比较少的数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

$ redis-benchmark -t lpush -n 100
====== LPUSH ======
  100 requests completed in 0.00 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
50000.00 requests per second


$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7f82e9100890 refcount:1 encoding:ziplist serializedlength:30 lru:473656 lru_seconds_idle:36

$ redis-benchmark -t lpop -n 100
====== LPOP ======
  100 requests completed in 0.00 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
33333.33 requests per second

分析内存占用，100个元素总共占用约553字节空间，平均一个元素约5.5字节，空间利用率约54.5%。

因为ziplist插入数据量过大可能非常的慢，甚至每秒的请求数量能到个位数，因此来看看插入100000个元素的情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142

$ redis-benchmark -t lpush -n 100000
====== LPUSH ======
  100000 requests completed in 39.20 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

37.85% <= 1 milliseconds
64.63% <= 2 milliseconds
65.22% <= 3 milliseconds
65.37% <= 4 milliseconds
65.43% <= 5 milliseconds
65.43% <= 6 milliseconds
65.45% <= 7 milliseconds
65.47% <= 9 milliseconds
65.47% <= 11 milliseconds
65.47% <= 12 milliseconds
65.47% <= 13 milliseconds
65.48% <= 14 milliseconds
65.53% <= 15 milliseconds
65.53% <= 16 milliseconds
65.53% <= 17 milliseconds
65.53% <= 18 milliseconds
65.53% <= 19 milliseconds
65.54% <= 20 milliseconds
65.54% <= 23 milliseconds
65.54% <= 26 milliseconds
65.54% <= 27 milliseconds
65.54% <= 28 milliseconds
65.54% <= 29 milliseconds
65.55% <= 30 milliseconds
65.55% <= 32 milliseconds
65.55% <= 34 milliseconds
65.55% <= 35 milliseconds
65.56% <= 36 milliseconds
65.56% <= 38 milliseconds
65.57% <= 39 milliseconds
65.57% <= 40 milliseconds
65.57% <= 41 milliseconds
65.58% <= 42 milliseconds
65.97% <= 43 milliseconds
67.04% <= 44 milliseconds
68.92% <= 45 milliseconds
70.23% <= 46 milliseconds
71.32% <= 47 milliseconds
72.07% <= 48 milliseconds
72.97% <= 49 milliseconds
74.51% <= 50 milliseconds
76.12% <= 51 milliseconds
78.02% <= 52 milliseconds
80.05% <= 53 milliseconds
81.86% <= 54 milliseconds
83.42% <= 55 milliseconds
84.66% <= 56 milliseconds
86.14% <= 57 milliseconds
87.74% <= 58 milliseconds
89.33% <= 59 milliseconds
90.45% <= 60 milliseconds
91.75% <= 61 milliseconds
93.67% <= 62 milliseconds
95.49% <= 63 milliseconds
96.69% <= 64 milliseconds
97.84% <= 65 milliseconds
98.68% <= 66 milliseconds
99.03% <= 67 milliseconds
99.20% <= 68 milliseconds
99.43% <= 69 milliseconds
99.54% <= 70 milliseconds
99.66% <= 71 milliseconds
99.78% <= 72 milliseconds
99.84% <= 73 milliseconds
99.87% <= 74 milliseconds
99.90% <= 75 milliseconds
99.92% <= 76 milliseconds
99.93% <= 77 milliseconds
99.96% <= 78 milliseconds
99.97% <= 79 milliseconds
99.99% <= 80 milliseconds
100.00% <= 81 milliseconds
2551.15 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7f82e9100890 refcount:1 encoding:ziplist serializedlength:30 lru:473656 lru_seconds_idle:36

$ redis-benchmark -t lpop -n 100000
====== LPOP ======
  100000 requests completed in 21.04 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

42.08% <= 1 milliseconds
63.70% <= 2 milliseconds
65.00% <= 3 milliseconds
65.26% <= 4 milliseconds
65.36% <= 5 milliseconds
65.37% <= 6 milliseconds
65.38% <= 7 milliseconds
65.39% <= 8 milliseconds
65.44% <= 9 milliseconds
65.45% <= 10 milliseconds
65.50% <= 11 milliseconds
65.54% <= 12 milliseconds
65.54% <= 13 milliseconds
65.54% <= 14 milliseconds
65.55% <= 15 milliseconds
65.56% <= 16 milliseconds
65.57% <= 17 milliseconds
65.60% <= 18 milliseconds
65.68% <= 19 milliseconds
65.80% <= 20 milliseconds
66.01% <= 21 milliseconds
66.39% <= 22 milliseconds
67.35% <= 23 milliseconds
69.41% <= 24 milliseconds
72.64% <= 25 milliseconds
75.51% <= 26 milliseconds
77.92% <= 27 milliseconds
80.83% <= 28 milliseconds
83.25% <= 29 milliseconds
87.63% <= 30 milliseconds
91.26% <= 31 milliseconds
94.02% <= 32 milliseconds
96.35% <= 33 milliseconds
97.76% <= 34 milliseconds
98.78% <= 35 milliseconds
99.20% <= 36 milliseconds
99.45% <= 37 milliseconds
99.56% <= 38 milliseconds
99.66% <= 39 milliseconds
99.70% <= 40 milliseconds
99.78% <= 41 milliseconds
99.84% <= 42 milliseconds
99.86% <= 43 milliseconds
99.87% <= 44 milliseconds
99.90% <= 45 milliseconds
99.92% <= 46 milliseconds
99.99% <= 47 milliseconds
99.99% <= 48 milliseconds
100.00% <= 48 milliseconds
4753.08 requests per second

显然，插入的速度相比quicklist、linkedlist以及小规模数据量的ziplist时明显慢了许多。并且能看到，随着数据插入越来越多，插入的速度越来越慢，从数万左右的每秒请求数量慢慢下降到最后的几千每秒请求数量。在100000个元素时，内存占用约488kb，即每个元素约5.0字节，空间利用率约60%，可以看到，空间的占用几乎是线性的关系，并且空间利用率反而增加了一些。

在弹出数据时可以看到，速度越来越快，从1k左右上升到最终的数万每秒请求数量。

对于长字符串的插入，先插入100条：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

$ redis-benchmark -n 100 lpush mylist "mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial"

====== lpush mylist mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial ======
  100 requests completed in 0.00 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

20.00% <= 1 milliseconds
100.00% <= 1 milliseconds
25000.00 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7f82e7f03b40 refcount:1 encoding:ziplist serializedlength:1130 lru:475907 lru_seconds_idle:55

$ redis-benchmark -t lpop -n 100
====== LPOP ======
  100 requests completed in 0.00 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

46.00% <= 1 milliseconds
100.00% <= 1 milliseconds
33333.33 requests per second

可以看出，插入的时间明显比短字符串更多。插入后总共占用了47kb空间，即每个元素约481字节空间，空间利用率约96.3%。

再来看长字符串的批量插入（日志有删减）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

$ redis-benchmark -n 100000 lpush mylist "mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial"

====== lpush mylist mylist str len: 463. Redis is not a plain key-value store, it is actually a data structures server, supporting different kinds of values. What this means is that, while in traditional key-value stores you associated string keys to string values, in Redis the value is not limited to a simple string, but can also hold more complex data structures. The following is the list of all the data structures supported by Redis, which will be covered separately in this tutorial ======
  100000 requests completed in 361.97 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

0.34% <= 1 milliseconds
1.22% <= 2 milliseconds
1.84% <= 3 milliseconds
3.02% <= 4 milliseconds
3.97% <= 5 milliseconds
4.91% <= 6 milliseconds
5.91% <= 7 milliseconds
6.47% <= 8 milliseconds
7.25% <= 9 milliseconds
7.78% <= 10 milliseconds
13.51% <= 20 milliseconds
18.07% <= 30 milliseconds
23.39% <= 40 milliseconds
28.43% <= 50 milliseconds
33.09% <= 60 milliseconds
36.63% <= 70 milliseconds
41.06% <= 80 milliseconds
46.23% <= 90 milliseconds
49.85% <= 100 milliseconds
61.87% <= 120 milliseconds
64.51% <= 140 milliseconds
65.13% <= 170 milliseconds
65.46% <= 202 milliseconds
66.86% <= 320 milliseconds
71.61% <= 350 milliseconds
78.91% <= 380 milliseconds
84.36% <= 410 milliseconds
90.07% <= 440 milliseconds
95.08% <= 470 milliseconds
98.34% <= 510 milliseconds
99.45% <= 543 milliseconds
99.80% <= 570 milliseconds
100.00% <= 746 milliseconds
276.26 requests per second

$ redis-cli
127.0.0.1:6379> DEBUG OBJECT mylist
Value at:0x7f82e7e02660 refcount:1 encoding:ziplist serializedlength:661619 lru:476557 lru_seconds_idle:579

$ redis-benchmark -t lpop -n 100000
====== LPOP ======
  100000 requests completed in 344.83 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1
0.31% <= 1 milliseconds
1.17% <= 2 milliseconds
2.41% <= 3 milliseconds
3.35% <= 4 milliseconds
4.14% <= 5 milliseconds
5.10% <= 6 milliseconds
5.84% <= 7 milliseconds
6.73% <= 8 milliseconds
7.50% <= 9 milliseconds
8.19% <= 10 milliseconds
55.85% <= 100 milliseconds
65.55% <= 211 milliseconds
85.84% <= 300 milliseconds
99.40% <= 400 milliseconds
100.00% <= 72866 milliseconds
290.00 requests per second

可以看到，在单个元素比较大时，插入、弹出ziplist会更加的耗时，但是内存总共占用45M，即单个元素占用约472字节内存，内存利用率达到98%。

总结

从上面的试验可以看到，ziplist对空间的利用率非常高，在数据规模比较小时，耗时相对可接受，但是对于元素比较多或者是单个元素比较长时，插入、弹出的耗时非常大。而linkedlist在插入、删除元素时，元素数量、单个元素的长度对耗时影响小（耗时分布比较集中），但是空间利用率比较差，特别是数据规模较小时，空间利用率非常差。而quicklist结合了二者的优点，首先时间消耗上，数据规模对其影响小，其次是空间利用率，因为底层使用了ziplist，所以在小规模数据上空间表现也良好。

• 两人一车，说走就走的西藏自驾游（1）：西藏行之起源
• 两人一车，说走就走的西藏自驾游（2）：走上318
• 两人一车，说走就走的西藏自驾游（3）：到达拉萨
• 两人一车，说走就走的西藏自驾游（4）：青藏出藏
• 两人一车，说走就走的西藏自驾游（5）：青海归来

嗯万万没想到，拖了一年采开始写的游记，写的过程也被我拖延了半年，终于结束双十一啦，可以把这个游记彻底撸完了。

Day14：格尔木-德令哈（0526）

到了青海，是的我们居然没去青海湖，惊不惊喜意不意外。早晨在KFC吃过早餐后发现商场有个卖书的活动，顺手买了本仓央嘉措诗传全集，毕竟刚从西藏回来，假装文艺一把。在格尔木时候发现以及出来半个月了，然后想开车回家后面车就不开回北京了，所以如果往东去青海湖玩，可能还得废掉几天，并且再开回成都比较麻烦，因此就打住了。看了下附件有个水上雅丹的地方，看几个月前的游记还能露营然后风景很好，所以决定去水上雅丹露营，带了一路，跟着我们翻山越岭的露营装备看上去终于能用上了。

决定好了就出发了，出格尔木不久，就进入大漠的感觉，路边很荒凉，但是路超级棒，而且还没啥车。在马路上各种角度各种拍，茫茫大漠就我们自己的感觉真的超级棒（嗯一会儿就知道多吓人了）。

以下是这一天的花费：

Day15 德令哈-久治（0527）

接下来主要是赶路了，要开始虎头蛇尾流水账模式了。

德令哈住了一宿，和@xqq商量是时候撤啦。准备直接开回成都。刚好有个德马高速刚修通不久，准备走这条高速回去。

新高速的确新，没啥车，没啥人，服务区空的，路边居然还有野骆驼，超级原生态。

服务区没人也没吃的，所以大中午的，终于用上了带了一路的煮面套装神器了（其实还带着米啥的，然而煮粥得等太久了，所以煮面了）。

吃过泡面沿着这条高速跑了很久很久很久，也没看到加油站，异常心慌。随着油表上的读数越来越小，越来越慌，一路尽可能保持匀速，下坡也不太敢踩刹车。

以下是这一天的花费：

Day16 久治-都江堰（0528）

出发不久就进入大四川地界啦，从阿坝进川，在四川界附近就遇到一场雪，景色很美，南国的雪原来也能很美。

以下是这一天的花费：

Day17 都江堰-乐山（0529）

在都江堰玩了大半天，嗯就不写都江堰游记啦，放几张图片吧。

是的又没去成青城山，上次和发小去都江堰，准备第二天去青城山，然而睡到了下午。这次真的是时间不够了，下午回乐山还得保养车，然后各种吃。车子在北京保养了一遍开出来的，开了这么远该保养了。

4s店依然很黑，宰了我一把。出了4s点我半小时就回去了，修车小哥一句咋又来了呢。嗯是的，出去刚上高速就被撞了，所以又回来了。不过还好，也就是反光镜掉了，漆磨掉了一些，其他啥事没有。

`

是的然后就等着修车了，接着线各回各家各找各妈去。

以下是这一天的花费：

名称	金额	备注
过路费19	都江堰-成都
过路费	9.5	绕城高速
过路费	44.65	乐山
油费	280	乐山
共计	353.15

Day18 乐山-成都（0614）

终于修好车啦，然后在家呆了半个月也差不多了，再呆几天就得被赶出家门了😁。去机场接@xqq 然后就出发直接开去杭州啦。 结果刚上高速不久，正开始打瞌睡了，就遇到前面的面包车爆胎，瞬间吓醒了。成乐高速对我也太不友好了吧。

• 两人一车，说走就走的西藏自驾游（1）：西藏行之起源
• 两人一车，说走就走的西藏自驾游（2）：走上318
• 两人一车，说走就走的西藏自驾游（3）：到达拉萨
• 两人一车，说走就走的西藏自驾游（4）：青藏出藏
• 两人一车，说走就走的西藏自驾游（5）：青海归来

Day11：拉萨-当雄（0523）

终于到拉萨了，昨天说了因为没有定到布达拉宫的票，所以最终也没有进布达拉宫，算是一大遗憾吧，当然了，这趟旅途遗憾可多了，比如也没能去珠穆朗玛，没有去羊湖，没有去阿里，以及前面说过的从雅鲁藏布大峡谷旁边经过也没有去看看等等~嗯有遗憾才更有兴趣下次再去（虽然并不太可能）。

Anyway，一早从酒店出发，玩到下午我们就又双叒叕启程了。@腿哥 他们预计今晚到拉萨，看上去是又要错过了，他们明天预计晚上到纳木错然而我们应该下午就从纳木错撤退，嗯友谊的小船不知道吹飞到哪里去了。

上午先去逛小昭寺，到了八廊街外面，以及震撼到不行。一大早广场上已经非常多的人（其实是中午了，这边天亮得太晚了，并且车停得非常远，走了半天），天气也很热，然而信徒们已经在聚集起来了，路上很多转着经筒默念经文的人，也有开始祭拜的人。

小昭寺离布达拉宫不是太远，虽然没有买到门票，但是门口还是需要去打个卡的。一路走过去，顺便买了杯咖啡，气温不高但是非常热，停下来，一阵风过来又冷得慌。来了当然要拍游客照了，@xqq 已经早早的换好了50元人民币，到了布达拉宫广场上就迫不及待的开始拍了。

既然来的时候走的川藏，所以出藏准备走青藏，也算圆满吧（其实是想去青海湖玩玩，结果。。gg了）。出拉萨后路还不错，一路蛮平坦的，但是云层低到可怕。

以下是这一天的花费：

Day12：当雄-安多（0524）

又是一早就起床了（真一早，七点多就起来了，相当于北京五点多就起床了），出酒店不远就转出大路往纳木错去了。一路上车不多，路也有的段正在修，但是景色真的贼美。

在回当雄上主路之前，终于趁着吃饭把车给洗了，这十多天来，车上糊满了的尘土。吃饭时候还遇到老板打电话训儿子，骂他不好好学习就知道贪玩，对不起自己和孩子他爸。下午开了一路平淡的公路，终于到达安多，感觉比当雄大一些，但是依然像个小镇。到安多的时候@腿哥 他们终于到当雄了。

以下是这一天的花费：

Day13：安多-格尔木（0525）

在高原呆了这么多天，今天终于下高原啦。然而因为两晚都在4000多米的地方睡(安多4800m，当雄4200m)，和@xqq 两人都有点不舒服，原本以为是感冒了，结果翻过昆仑雪山后居然啥事也没有了，嗯居然高反了。然后我觉得是因为高反了所以我居然错过了唐古拉山口，开过去了才在地图上瞅到。

一早出发，结果走了不久就开始堵车。青藏路上大卡车比较多，一长串的大卡车，夹在大卡车中间感觉特别压抑，卡车司机们居然有的开始下车煮泡面闲聊了。我们堵了半个小时，发现小汽车再开始往回走，下车跑到路边一看，发现外面有一条小路可以通行，赶紧也跟着绕下来了。

在沱沱河之前是长江源头，过了沱沱河就是可可西里无人区，我居然还能离藏羚羊这么近，在无人区里看到了一群群的藏羚羊以及更多的野驴群🤣

过了可可西里就是最后一个山头啦，翻过昆仑山口就一路下高原了。昆仑山这个名字从小在各种电视剧中出现过无数次，当然路过要跑出去拍照啦，结果穿着短袖冲出去发现，外面居然在飘雪？？？刚从在可可西里不是短袖正好么？？？

如果说这是一篇西藏游记，那么下高原了，这里算是告一段落了吧。

以下是这一天的花费：

• 两人一车，说走就走的西藏自驾游（1）：西藏行之起源
• 两人一车，说走就走的西藏自驾游（2）：走上318
• 两人一车，说走就走的西藏自驾游（3）：到达拉萨
• 两人一车，说走就走的西藏自驾游（4）：青藏出藏
• 两人一车，说走就走的西藏自驾游（5）：青海归来

Day7：巴塘-左贡（0519）

前面说了，从巴塘出发后，晚上的歇脚点非常不好找，沿途一天能到的城镇：芒康，海拔3875m，距离上看距离巴塘就100公里左右，太近了，排除；左贡，海拔3877m，也比较高，距离250公里左右，距离上看比较合适；邦达，海拔4120m，太高了，住宿一晚估计会高反，并且距离左贡还有100公里，比较远。综合考虑了下决定今晚在左贡住宿了，今天路途虽然不远但是一路都是翻山越岭，所以可能相对更累了。对了今天比较大的进展就是，终于进入西藏地界啦，但是有一个巨大的遗憾，就是经过金沙江大桥到达界牌的时候，我忘了拍照！！都怪@xqq 开太快没给我思考时间就过去了。赶紧拍了张车窗外的金沙江，嗯这个照片离四川-西藏的界牌大概有几米吧。

以下是这一天的花费：

Day8：左贡-然乌（0520）

嗯今天又拍了五六百张照片，这个游记写得心好累。下面是手机一些照片的截图。

今天的天气特别的好，之前几天云比较多，云层比较低，但是今天的天空特别晴朗，云也很少，车在四千多米海拔跑着，人也非常兴奋。窗外是起伏的群山，掺点着一些高原植物的深绿色，黄沙一样的土地上遍布牦牛群，路边时不时出现一辆事故车摆着提示过往车辆安全驾驶。随手一拍都是桌面级的美景（嗯我拍照太烂了可能桌面比较丑）

以下是这一天的花费：

Day9：然乌-林芝（0521）

今天从然乌需要开到林芝，需要开350多公里，任务还是比较重的。昨天去看的是然乌湖三大湖的其中一个，其实然乌湖还有两个湖，早晨从酒店出发不久就看到了，就在318国道旁边。然乌湖是一个堰塞湖，貌似是刚好是在喜马拉雅、唐古拉山的对撞处，湖边还有个冰川，然而因为今天赶路没法去看了。

再往前到了追龙沟特大桥，@xqq 说之前这里没有桥和隧道的时候需要走一段盘山路，这里也被称为川藏路上的“天险”，之前这里垮塌的通麦大桥也被称为通麦坟场。而如今的追龙沟特大桥看上去非常的坚固，悬崖上也明显能看到防止塌方用的围栏。桥身是汹涌的河水，可惜我没有拍到。

下山不久就到林芝了，之前听说过这个地方很多次，没想到现在就在这个城市了。这里蛮大的，在路上跑了这么久，终于感觉到进城了。晚上和@xqq 跑去吃了下特色的石锅鸡，还挺好吃的。出门特意没开车步行去的饭店，吃完饭逛街走回来，好久没有踏踏实实的在马路上走过路了。

回到酒店突然发现，即使涂满了防晒的情况下，好像手心手背开始不是一个色号了，发了个朋友圈感慨了下还被插刀。看了下轨迹，3600多公里啦。到了林芝，明天终于能到拉萨了。

以下是这一天的花费：

Day10：林芝-拉萨（0522）

终于，今天能到拉萨了。一早起来就出发啦，直接上拉林高速，传说中的西藏最美高速，其实也不算高速了，因为居然不收费，感觉是一条高大上的快速路。具体的图片可以百度搜一下，非常漂亮。嗯这趟旅程让我非常的后悔没有买个无人机，很多景都没法拍出来了。当时走的时候整条路还没有通，中间还有几条隧道正在挖掘，但是大部分都可以通车了。路上整体车不多。

• 两人一车，说走就走的西藏自驾游（1）：西藏行之起源
• 两人一车，说走就走的西藏自驾游（2）：走上318
• 两人一车，说走就走的西藏自驾游（3）：到达拉萨
• 两人一车，说走就走的西藏自驾游（4）：青藏出藏
• 两人一车，说走就走的西藏自驾游（5）：青海归来

这是一篇拖延了整整一年的游记。上次写到从下决心到到达成都的过程（两人一车，说走就走的西藏自驾游（1）：西藏行之起源），接下来就走上318了。btw，虽然忙完618但是不知道为嘛还是忙成狗，周末感觉得撸一篇不然感觉就要鸽掉了。

Day4：成都-海螺沟（0516）

在成都休息了一下后，算是正式踏上了进藏的路了（嗯睡了个自然醒）。第一件事就是被师姐提醒，我貌似有麻烦了？（垃圾iCloud照片死活加载不出来，开场就折腾我半天）

以下是这一天的花费：

Day5：海螺沟-新都桥（0517）

因为昨天让酒店帮忙订了今天去海螺沟的票，包含大巴，所以一大早起来吃了饭就卡着点在酒店门口坐大巴去景区啦。在景区发现可以多交几十块钱，然后以后能免费来（还是半价，记不清了），在@xqq 阻止下我成功没有入坑，嗯虽然这个景区还不错，但是的确半辈子都不会再来了。

刚进景区，空气非常棒，景色也很棒，然后登山步道给人一种九寨的感觉（嗯大夏天的越往上爬越冷。。这点非常像）。

在冰川（还是愿意叫它冰泥）旁边（貌似是一号营地）玩了一会儿太冷了，我们就回头去坐缆车准备上三号营地从上往下看冰川了。缆车上看冰川感觉挺酷，能看到悬崖数十万年间被冰川磨平的痕迹。

以下是这一天的花费：

Day6：新都桥-巴塘（0518）

终于把手机上的照片大部分都移动到nas上了，再也不用忍受iCloud那龟速加载了

忘了说，新都桥街道在翻修，所以小镇里全是坑坑洼洼的，昨晚比较晚了一路开到酒店，早晨起来从酒店看了下，感觉整个小镇都在修。

一路上景色很美，我居然想用“鲜”来形容。大概十点多的时候，发现开始各种回头线爬山了（此处同情骑行的人们），感觉这个回头线能赶上进九寨前的那十多道弯了。爬到山上一看，嗯的确是山路十八弯。

以下是这一天的花费：

• 两人一车，说走就走的西藏自驾游（1）：西藏行之起源
• 两人一车，说走就走的西藏自驾游（2）：走上318
• 两人一车，说走就走的西藏自驾游（3）：到达拉萨
• 两人一车，说走就走的西藏自驾游（4）：青藏出藏
• 两人一车，说走就走的西藏自驾游（5）：青海归来

这是一篇拖延了整整一年的游记，这一年来一直牵挂着它，再不写下来它就要难产了。

最近有朋友想自驾西藏，然后刚好去年这几天我们正在高原上浪着，借着还没忘记一些东西，所以先写下来，补记一下当年的自由生活。再注明一下：1. 本文发生在18年；2. 本文所有图片未添加滤镜，均为手机/相机直出相片截图（不然图片太大本文打开可能比较费劲，照片都尽可能的截图+拼接了）。

嗯本来准备一口气写完，结果gg了我觉得得花小半个月写这玩意儿，果然当时拖延是有原因的。

Day0：准备工作（0511）

大概说一下背景，5月11日晚上忘了为啥@腿哥 突然请客，然后说要抛弃我们几个，跟着本科同学去西藏租车自驾。其实我和@xqq 一直想着抽空去西藏，所以想要乘机一起去浪，晚上回宿舍后就和@xqq 刷机票，准备跟@腿哥 一起去浪。在机票下单前几秒，突然觉得自驾去西藏也行比在西藏自驾更酷，于是11号晚上睡前临时决定：走，自驾去西藏！12日睡到中午，两人赶紧的爬下床开始各种搜攻略，318国道安全吗，去西藏需要准备什么，高原反应要死人吗，无人区有狼吗，汽车常见故障及维修宝典，第一次自驾进藏走川藏线还是青藏线。反正就是一阵狂搜，然后晚上去物美买了一堆零食，在迪卡侬备了些乱七八糟的东西（帐篷、地垫、隔热垫、充气床、睡袋、充气枕头啥的都有，所以就买了些简单的露营灯这种），在京东上下单了一堆还缺的东西（血氧仪、葡萄糖、红景天、多功能逃生手链、野营套锅、各种袋装绿豆汤红豆汤啥的），再找@达叔 借上野用燃气灶、气罐、兵工铲、拖车绳这些，13号一早就出发啦！

Day1：北京-运城（0513）

一大早就出发啦，塞满后备箱以及后排，然后快出六环了发现忘记记录里程了，感觉拍张照记一下，想着等开回来看看走了多远，然而没想到，最终这辆车没机会开到北京而是停在了杭州（估计得等换车的时候它才再有机会回北京了）。

中午忘记吃什么了（貌似随便吃了点泡面和零食？），晚上我自己在服务区吃了顿自助餐，居然才35，刚从北京出来的我感觉真的是良心价啊（现在的我看着这个价格想着当年的心情突然觉得我现在真的穷成狗了），而且看上去以及吃上去还不错。而@xqq 在高速上没饿，到运城吃了顿貌似是啥砂锅，查了下账单是28，我印象中好像很不错的样子。

Day2：运城-剑阁（0514）

一大早出发啦，然而今天显然没有昨天那么激动了（嗯我还记得这个）。一路上路挺好风景挺不错，从风陵渡黄河大桥过黄河（照片带GPS水印真是方便我等脑残换着）进入陕西地界，完成了全程唯一一次被交警拦下的记录，一定是@xqq 太像坏人了。

Day3：剑阁-成都（0515）

作为四川人，“噫吁嚱，危乎高哉”、“剑阁峥嵘而崔嵬，一夫当关，万夫莫开”背了这么多年，居然第一次来剑门关，太惭愧了。整个景区超级大，因为今天计划到成都，所以只有小半天的时间玩，因此景区只走了一小部分，并且到了下图打问号的地方我就失忆了，忘了怎么出来的了┑(￣Д ￣)┍

前段时间改造链路，发现链路上可能会出现丢掉threadlocal中数据的情况，排查发现是在执行parallelStream后出现了丢标，并且这个丢标是偶发的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public static void main(String[] args) {
    List<Integer> lists = Lists.newArrayList();
    for (int i = 0; i < 4; i++) {
        lists.add(i);
    }
    //add threadLocal
    //something...
    //get threadLocal;
    lists.parallelStream().forEach(e -> {
        //set threadLocal;
        //do something
        //clear threadLocal;
    });
    //get threadLocal
}

多次执行后发现，parallelStream之后的标出现偶发性的被吞。（注：这里因为使用了部分集团内部组件，因此使用threadLocal替代）

什么是ParallelStream

Stream（流）是JDK8中引入的一种类似与迭代器（Iterator）的单向迭代访问数据的工具。ParallelStream则是并行的流，它通过Fork/Join 框架（JSR166y）来拆分任务，加速流的处理过程。最开始接触parallelStream很容易把其当做一个普通的线程池使用，因此也出现了上面提到的开始的时候打标，结束的时候去掉标的动作。

ForkJoinPool又是什么

ForkJoinPool是在Java 7中引入了一种新的线程池，其简单类图如下：

task) 或invoke(ForkJoinTask task)方法来执行指定任务。ForkJoinTask表示线程池中执行的任务，其有两个主要的抽象子类：RecusiveAction和RecusiveTask。其中RecusiveTask代表有返回值的任务，而RecusiveAction代表没有返回值的任务。它们的类图如下：ForkJoinPool来支持使用分治法(Divide-and-Conquer Algorithm)来解决问题，即将一个任务拆分成多个“小任务”并行计算，再把多个“小任务”的结果合并成总的计算结果。相比于ThreadPoolExecutor，ForkJoinPool能够在任务队列中不断的添加新任务，在线程执行完任务后可以再从任务列表中选择其他任务来执行；并且可以选择子任务的执行优先级，因此能够方便的执行具有父子关系的任务。ForkJoinPool内部维护了一个无限队列来保存需要执行的任务，而线程的数量则是通过构造函数传入，如果没有向构造函数中传入希望的线程数量，那么当前计算机可用的CPU数量会被设置为线程数量作为默认值（最大为MAX_CAP = 0x7fff）。## 回过头来看ParallelStream原理运行如下代码：

1 2 3 4 5 6 7 8 9 10 11 12 13

public static void main(String[] args) { List<Integer> lists = Lists.newArrayList(); for (int i = 0; i < 10000; i++) { lists.add(i); } Set<String> sequenceThreadNameSet = Sets.newHashSet(); Set<String> parallelThreadNameSet = Sets.newHashSet(); lists.forEach(e -> sequenceThreadNameSet.add(Thread.currentThread().getName())); lists.parallelStream().forEach(e -> parallelThreadNameSet.add(Thread.currentThread().getName())); System.out.println(sequenceThreadNameSet); System.out.println(parallelThreadNameSet); }

得到结果：

1 2 3

[main] [ForkJoinPool.commonPool-worker-7, ForkJoinPool.commonPool-worker-1, ForkJoinPool.commonPool-worker-2, main, ForkJoinPool.commonPool-worker-5, ForkJoinPool.commonPool-worker-6, ForkJoinPool.commonPool-worker-3, ForkJoinPool.commonPool-worker-4]

可以看出，串行的流使用的是main线程，而parallelStream使用了线程名为ForkJoinPool.commonPool-worker-*的线程，而这些线程来自于：

`java.util.concurrent.ForkJoinPool#makeCommonPool`函数在ForkJoinPool类的静态方法块中别调用，返回结果赋值给一个静态成员元素common，这个common是Java 8中引入的一个通用的静态线程池，这个线程池用来处理那些没有被显式提交到任何线程池的任务，ParallelStream其实就是自动的使用了这个通用ForkJoinPool线程池来实现并行化。代码中可以看到，线程池数量取决于`parallelism`，而`parallelism`要么在3412、3419行中从环境变量中获得，要么在3435行被赋值为处理器数量减一，之后再判定如果其值小于0或者大于MAX_CAP，则取1或者MAX_CAP。注意这里，`parallelism < 0`，也就是如果启动jvm时候对其赋值为0，则会使用0作为参数进行线程池的创建。

commonPool线程数好像不太对？

从上面可以看出，commonPool的线程数量默认会使用处理器数量减去1，比如我的电脑是八核（其实是八线程）的，其实commonPool的线程池是7个线程，这个通过打印ForkJoinPool.getCommonPoolParallelism()也能看出，这样做是因为还有一个主线程，主线程加上线程池线程刚好等于cpu核心数，这样能同时跑满cpu，并且不会因为线程太多造成线程本身的切换浪费资源，这样最有效率。

回过头来看上面代码的输出：[ForkJoinPool.commonPool-worker-7, ForkJoinPool.commonPool-worker-1, ForkJoinPool.commonPool-worker-2, main, ForkJoinPool.commonPool-worker-5, ForkJoinPool.commonPool-worker-6, ForkJoinPool.commonPool-worker-3, ForkJoinPool.commonPool-worker-4]，发现main也参与了ParallelStream中的计算。这是因为forEach将执行forEach本身的线程也被当作为线程池中的一个工作线程进行工作，因此使用刚好等于cpu核心数的线程来执行了多个任务。

因此，前面说的丢标的问题也得到解决，因为ParallelStream任务执行时，可能将main线程作为执行线程，因此如果在forEach中清标，可能会导致主线程中的标被丢掉。解决的方式也很简单，在执行完并行流之后，重新set一下标即可。

所以就无脑用ParallelStream了？

ParallelStream可能引起阻塞

对CPU密集型的任务来说，并行流使用ForkJoinPool，为每个CPU分配一个任务，这是非常有效率的，但是如果任务不是CPU密集的，而是I/O密集的，并且任务数相对线程数比较大，那么直接用ParallelStream并不是很好的选择。如下代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public static void main(String[] args) { List<Integer> lists = Lists.newArrayList(); for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) { lists.add(i); } Date start = new Date(); lists.parallelStream().forEach(e -> { try { //do something Thread.sleep(10000); } catch (InterruptedException e1) { e1.printStackTrace(); } }); lists.parallelStream().forEach(e -> { try { //do something Thread.sleep(10000); } catch (InterruptedException e1) { e1.printStackTrace(); } }); Date end = new Date(); System.out.println((end.getTime() - start.getTime()) / 1000); }

发现其执行时长为20秒，但是如下代码：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

public class Test { public static void main(String[] args) throws InterruptedException { List<Integer> lists = Lists.newArrayList(); for (int i = 0; i < Runtime.getRuntime().availableProcessors(); i++) { lists.add(i); } Date start = new Date(); ForkJoinPool forkJoinPool1 = new ForkJoinPool(Runtime.getRuntime().availableProcessors()); ForkJoinPool forkJoinPool2 = new ForkJoinPool(Runtime.getRuntime().availableProcessors()); CountDownLatch countDownLatch = new CountDownLatch(2); taskProcess(lists, forkJoinPool1, countDownLatch); taskProcess(lists, forkJoinPool2, countDownLatch); countDownLatch.await(); Date end = new Date(); System.out.println((end.getTime() - start.getTime()) / 1000); } private static void taskProcess(List<Integer> lists, ForkJoinPool forkJoinPool, CountDownLatch countDownLatch) { forkJoinPool.submit(() -> { lists.parallelStream().forEach(e -> { try { //do something Thread.sleep(10000); } catch (InterruptedException e1) { e1.printStackTrace(); } }); countDownLatch.countDown(); }); } }

执行可以发现，10秒可以执行完毕。这是因为第一份代码中，每次提交8个任务到commonPool，提交了两次，第二次的任务得等第一次执行完毕后才能执行，并且主线程也被阻塞。而第二次，使用独立的ForkJoinPool来执行线程，没有影响主线程的执行，如果在每个任务中打印一下线程名字也能看出来：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

ForkJoinPool-2-worker-1 ForkJoinPool-1-worker-0 ForkJoinPool-1-worker-2 ForkJoinPool-1-worker-4 ForkJoinPool-1-worker-5 ForkJoinPool-1-worker-7 ForkJoinPool-1-worker-6 ForkJoinPool-2-worker-5 ForkJoinPool-2-worker-4 ForkJoinPool-1-worker-3 ForkJoinPool-2-worker-6 ForkJoinPool-2-worker-7 ForkJoinPool-2-worker-2 ForkJoinPool-2-worker-3 ForkJoinPool-2-worker-0 ForkJoinPool-1-worker-1

ParallelStream是多线程，注意线程安全

请看下面的代码

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

public class Test { public static void main(String[] args) throws InterruptedException { List<Integer> listOfIntegers = new ArrayList<>(); for (int i = 0; i <100; i++) { listOfIntegers.add(i); } List<Integer> parallelStorage = new ArrayList<>() ; listOfIntegers .parallelStream() .filter(i->i%2==0) .forEach(i->parallelStorage.add(i)); parallelStorage .stream() .sorted((o1, o2) -> { if (o1 == null) { return -1; } else if (o2 == null) { return 1; } else { return o1 > o2 ? 1 : o1.equals(o2) ? 0 : -1; } }) .forEach(e -> System.out.print(e + " ")); } }

执行完后，发现parallelStorage中居然出现了null：

1	null 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98

这是因为在ArrayList中存储数据的过程不是一个线程安全的过程导致的。因此使用ParallelStream时要注意这点。

一些思考

勿在浮沙筑高台。一些常用的东西，底层的设计还是很巧妙的，而这些巧妙间却埋了不少的坑，当然踩坑还是应为CURD虽然撸得多但是对实现不了解，需要多去了解底层。

]]>

曾几何时，每次建库都选utf8，觉得自己比那些用乱七八糟编码的人不知道酷到哪里去了。直到好多年前的某次课程设计做项目的时候，愉快的建了个用户表：

1
2
3
4
5

CREATE TABLE `test_user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(32) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

然后愉快的新增用户：INSERT INTO test_user(name) VALUES("我是😁")，接着愉快的反思人生：

1

Incorrect string value: '\xF0\x9F\x98\x81' for column 'name' at row 1

我是谁？我来自哪里？我在干嘛？难道是我代码里面的字符集用错了？不对啊我所有地方都用的utf8啊……

MySQL的UTF8编码是什么？

首先来看官方文档：

The character set named utf8 uses a maximum of three bytes per character and contains only BMP characters. The utf8mb4 character set uses a maximum of four bytes per character supports supplementary characters:

For a BMP character, utf8 and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
For a supplementary character, utf8 cannot store the character at all, whereas utf8mb4 requires four bytes to store it. Because utf8 cannot store the character at all, you have no supplementary characters in utf8 columns and need not worry about converting characters or losing data when upgrading utf8 data from older versions of MySQL.

我们再看看维基百科对UTF8编码的解释：

UTF-8 is a variable width character encoding capable of encoding all 1,112,064 valid code points in Unicode using one to four 8-bit bytes.

MySQL一直不承认这是一个bug，他们在2010年发布了“utf8mb4”字符集来绕过这个问题，在MySQL中，utf8mb4才应该是标准的utf8编码，并且官方很鸡贼的偷偷在最新的文档中加上了，算是认识到错误了吧：

utf8 is an alias for the utf8mb3 character set.
The utf8mb3 character set will be replaced by utf8mb4 in some future MySQL version. Although utf8 is currently an alias for utf8mb3, at that point utf8 will become a reference to utf8mb4. To avoid ambiguity about the meaning of utf8, consider specifying utf8mb4 explicitly for character set references instead of utf8.

MySQL UTF8问题简史

MySQL从4.1版本开始支持utf8，即2003年，但是现在的utf8标准（RFC 3629)是在其后发布的。MySQL在2002年3月28日的4.1预览版中使用了旧版的utf8标准（RFC 2279)，该标准最多支持每个字符6个字节，同年9月MySQL调整其utf8字符集最多支持3字节，而这个调整可能只是为了优化空间（05年前推荐使用CHAR类字段，而一个utf8的CHAR将会占用6字节长度）和时间性能（05年前在MySQL中使用CHAR字段会有更优的速度）。嗯可以在GitHub中看到大家对这个坑的吐槽：

但是这个字符编码发布出来，就不能轻易的修改，因为如果已经有用户开始使用了，就需要这些用户重新构建其数据库。

怎么补救呢？在上面最新文档中可以看出，他们将当前的utf8作为utf8mb3的别名，并且在将来的某一天会把utf8重新作为utf8mb4别名，这样来解决这个多年的巨坑。

啥是UTF8

略

utf8mb4_unicode_ci 和 utf8mb4_general_ci

字符除了存储，还需要排序或者比较，这个操作与编码字符集有关，称为collation，与utf8mb4对应的是utf8mb4_unicode_ci 和 utf8mb4_general_ci这两个collation。

准确性

utf8mb4_unicode_ci 是基于标准Unicode来进行排序比较的，能保持在各个语言之间的精确排序；

utf8mb4_general_ci 并不基于Unicode排序规则，因此在某些特殊语言或者字符上的排序结果可能不是所期望的。

性能

utf8mb4_general_ci 在比较和排序时更快，因为其实现了一些性能更好的操作，但是在现代服务器上，这种性能提升几乎可以忽略不计。

utf8mb4_unicode_ci 使用Unicode的规则进行排序和比较，其排序规则为了处理一些特殊字符，实现更加复杂。

现在基本没有理由继续使用utf8mb4_general_ci了，因为其带来的性能差异很小，远不如更好的数据设计，比如使用索引等等。

MySQL用错编码怎么救

1. 备份，不然崩了就只有删库跑路了；

2. 升级MySQL服务端到5.3.3及以上版本，以支持utf8md4；

3. 将数据库、表、列的字符编码、collation改为utf8md4:

   1 2 3 4 5 6

   # For each database: ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; # For each table: ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; # For each column: ALTER TABLE table_name CHANGE column_name column_name VARCHAR(length) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

4. 检查列和索引键的最大长度；

5. 修改连接、客户端、服务端的字符集；

6. 修复和优化所有的表，以免出现一些莫名其妙的错误，可以使用如下的方式：

   1 2 3

   # For each table REPAIR TABLE table_name; OPTIMIZE TABLE table_name;

   或者是使用mysqlcheck工具：

   1	$ mysqlcheck -u root -p --auto-repair --optimize --all-databases

其他坑

MySQL表字段字符集不同导致的索引失效问题

参考

• https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
• https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html
• https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
• https://stackoverflow.com/questions/766809/whats-the-difference-between-utf8-general-ci-and-utf8-unicode-ci
• https://mathiasbynens.be/notes/mysql-utf8mb4#utf8-to-utf8mb4

拨开云雾见天日 守得云开见月明

终于把毕设撸完了，我的毕设刚好值10斤肉。赶论文这段时间无比的想撸代码，第一版写完赶紧的写了一晚上 bug，愉快的熬到了半夜。效果见本站左上角，后端调用了韩寒的“一个”，每天都是不一样的话，后端主要是 Spring 那一套。计划最近写一些常用的接口并且开放出来。

在过程中遇到一个坑，尽管用了@CrossOrigin注解，但是返回内容依然没有Access-Control-Allow-Origin头部，postman上没有（之前写 PHP，在 nginx 中直接对接口调用加上了这个头，所以。。。嗯是我太菜），ajax去访问也没有（这里是我自己脑抽了，后面讲），导致前端无法跨域访问，但是神奇的是，如果任务起在我电脑上，同一个局域网上室友的电脑上 postman 返回正常，微笑脸。。。嗯情况大概就是这样，然后这个 bug 调了我一晚。

CORS 基本概念

这里首先说一下CORS，CORS是一个 W3C的标准，全称是跨域资源共享（Cross-origin resource sharing）。CORS需要服务器返回的数据头部包含相应的信息，CORS在客户端是浏览器自动支持的（IE 走开），如果浏览器收到服务器返回数据中包含了对应的头部，则可以使用其数据。对于简单请求（HEAD、GET、POST 方法之一，并且请求的头部不能超出如Accept、Accept-Language、Content-Language、Last-Event-ID、Content-Type这几个字段，并且Content-Type只限于application/x-www-form-urlencoded、multipart/form-data、text/plain这三个值），浏览器会自动在请求中增加一个 Origin字段，对于非简单请求，浏览器会提前进行一次“预检”请求（请求方法为OPTIONS）查询服务器一些信息，然后再发送加上了Origin字段的正常请求。比如发送一个PUT请求，浏览器首先发送“预检”请求：

1
2
3
4
5
6
7
8

OPTIONS /cors HTTP/1.1
Origin: https://api.liexing.me
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.liexing.me
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: keep-alive
User-Agent: Mozilla/5.0...

“预检”请求用来向服务器确认，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的请求。Access-Control-Request-Method用来询问是否支持该方法，Access-Control-Request-Headers用来指定浏览器CORS请求会额外发送的头信息字段。如果服务器确认了请求，则做出回应：

1
2
3
4
5
6
7
8
9
10
11
12

HTTP/1.1 200 OK
Date: Thu, 20 Mar 2018 22:30:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

其中，Access-Control-Allow-Origin即为允许访问的域名，可以为*或者域名，Access-Control-Allow-Methods表示允许跨域的方法，Access-Control-Allow-Headers为允许跨域需要的头部。

在预检通过之后，会发送正常的PUT请求，并且在头部自动添加Origin 字段，服务器对这个请求需要校验是否含有Access-Control-Allow-Headers标注的头部，是否是允许的方法以及来源域名，如果都通过则返回会带上Access-Control-Allow-Origin，这时候浏览器才能使用。

服务端对跨域请求的识别

在CORS的文档中可以看到这样一句话：

Server-side applications are enabled to discover that an HTTP request was deemed a cross-origin request by the user agent, through the Origin header.

这是第一个坑，当然这是我自己的问题，因为之前写PHP时候，为了方便，直接在通过Nginx代理中加上一个Access-Control-Allow-Origin头部，而 Spring Boot 对于 CORS 是按照标准来的，这里后面会说。

浏览器对CORS的操作

前面说了，浏览器在跨域访问时，会自动加上一个Origin头部来标注来源，这也是后端识别跨域访问的判定标准。而我在写 js 时（嗯我就是前端渣，不然咋会掉坑），域名没有加上协议，即 https://或者//，尽管浏览器给了我提示，然而我瞎了，而且还认为是浏览器 bug 换了一堆浏览器。

这下来了让我当时无比懵逼的一个坑了，就是我的 Postman 是 app 版本（Mac）的，我室友的是 Chrome 的应用版，而Chrome 应用版本的Postman在请求时，会加上一个Origin字段，而 app 版的不会，因此这也算为啥我室友电脑上没事╭(╯^╰)╮

Spring中CORS相关操作

Spring 中，检查是否是CORS只是看Origin头部，即完全按照W3C标准。Spring 通过org.springframework.web.cors中的CorsUtils.isCorsRequest来判断，如下图。

对于 CORS 的各种操作，会在org.springframework.web.cors中进行，比如在org.springframework.web.cors.reactive中的DefaultCorsProcessor。handleInternal对 CORS 请求的返回进行各种校验并且添加头部操作，如下图。

anyway，总结一下这次的坑，首先是自己懒没看CORS详细的规范，以及习惯性的自己用错了都加上跨域的头部；其次是自己傻ajax写错了，导致一直以为是后端代码的问题；最后是postman太坑，室友的电脑上正常我的电脑错误，导致我懵逼了半天。嗯就这样。

画由心生,境为意造 —— 白居易

去年《你的名字》火了之后，某 APP 发布了一个风格迁移的滤镜，随后朋友圈火了一把动画风的图片秀。当时就像玩玩风格迁移，然后这个拖延症一直至今，前几天看吴恩达的深度学习课程，突然想起这个坑。我也不知道在忙到爆炸的毕设中期前哪来的勇气这么浪去玩其他(￣.￣)

风格迁移（Style Transfer）是深度学习非常好玩的一个应用，它可以从一张图片获得风格，另一张图片或得内容，再合成为一张新的图片，比如：

卷积神经网络中学习到了什么

对于图片分类，我们一般使用卷积神经网络获取图片信息，最终输出类别，比如下图中的网络，其实就是一层层的堆积卷积层和池化层，最后加几个全连接层：

在我们的生成迁移模型中，将会使用预训练好的 CNN 网络模型，来提取图形特征与内容，使用越深的网络获取到的特征越高层，因此选用较浅的层将会更加像素级的趋近输入图片，越深则越在内容上趋近。

风格迁移模型

最早期的风格迁移模型非常缓慢，因为它把图片的生成过程当做一个“训练”过程，将风格图片和内容图片作为输入，生成最后的新图片，每生成一张图片都相当于训练一个模型。模型图如下：

因此我们需要加快风格迁移的速度，需要把其当做一个“生成”或者“执行”的过程，即快速风格迁移，该模型图如下：

损失函数

训练机器学习模型，需要定义损失函数。从上面对风格迁移模型的描述可以看出，模型的损失由两部分来定义：内容损失与风格损失，即：

$$J(G) = \alpha J_{Content}(C,G) + \beta J_{Style}(S,G)$$

其中，C(Content)表示内容图片，S(Style)表示风格图片，G(Generate)即第一项表示内容的损失，第二项表示风格的损失。

内容损失函数

那么如何来计算内容损失函数$\alpha J_{Content}(C,G)$呢？

首先应该使用一个预训练好的卷积神经网络模型，比如 VGG19，然后选择 l 层的激活来计算生成图片 G 和内容图片 C 的相似性，即计算 $a^{[l](C)}$ 和 $a^{[l](G)}$之间的相似度。这两个值越相似，那么 G 和 C 的内容就越相似。

$$J_{Content}(C,G) = \frac{1}{2} \lVert a^{[l](C)} - a^{[l](G)} \rVert^2$$

风格损失函数

首先我们需要定义什么是风格。风格就是 l 层中不同通道的激活值的相关性。因为不同通道的卷积核，对不同的特征敏感，那么如果多个通道同时激活，说明图中出现了某些关联的特征，即风格。例如对于某层（l层）激活值的维度为：$n_H, n_W, n_C$，$a^{[l]}_{i,j,k}$表示$(i,j,k)$上的激活值，$G^{[l](S)}$表示风格矩阵，它是一个$n^{[l]}_C \times n^{[l]}C$维度的矩阵。$G^{[l](S)}{kk’}$表示在 k 通道和 k’ 通道的关联性：

$$G^{[l](S)}{kk’} = \sum{i=1}^{n_H^{[l]}} \sum_{j=1}^{n_w^{[l]}} a^{[l]}{i,j,k} a^{[l]}{i,j,k’}$$

进而，风格损失函数可以定义为：

$$J_{Stype}^{[l]}(S,G) = \frac{1}{2n_H^{[l]}n_W^{[l]}n_C^{[l]}} \sum_k \sum_{k’}\lVert G^{[l](S)}{kk’} - G^{[l](G)}{kk’} \rVert$$

对多个层求风格损失并且累加，可以同时得到多层的风格相似性，往往效果更好：

$$J_{Style}(S,G) = \sum_l \lambda^{[l]}J_{Stype}^{[l]}(S,G)$$

模型示例

模型的代码具体见：Keras 官方 examples

这里给出几个运行的例子（从左到右依次是 风格图、内容图、生成图）：

梯度下降最直观的解释如图所示，在山上某处，沿着最陡的方向向下，直到能到达的最低点。

对于一般线性回归函数，其假设为：

$$h_{\theta}=\sum_{j=0}^{n}\theta_{j}x_{j}$$

对应的损失函数为：

$$J_{train}(\theta)=\frac{1}{2m}\sum_{i=1}^{m}(h_{\theta}(x^{(i)})-y^{(i)})^{2}$$

我们假设参数$\theta$是二维的，下图为一个二维参数（$\theta_{0}$和$\theta_{1}$）组对应能量函数的可视化图：

本文大概分为：基本的梯度下降算法和梯度下降优化算法。

基本的梯度下降算法

批量梯度下降（Batch Graduebt Descent, BGD）

批量梯度下降算法使用整个数据集，算得整个数据集的损失，对目标参数$\theta$求导，用来更新$\theta$：

$$\theta = \theta - \alpha\nabla_{\theta}{J(\theta)}$$

其具体的过称为：

1. 对上面的损失函数求偏导：

   $$\frac{\partial{J(\theta)}}{\partial{\theta_j}} = - \frac{1}{m}\sum_{i=1}^{m}(y^i - h_{\theta}(x^i))x_{j}^{i}$$

2. 最小化损失函数，按照每个参数$\theta$的梯度负方向来更新每个$\theta$：

   $$\theta_{j} = \theta_{j} + \alpha\frac{1}{m}\sum_{i=1}^{m}(y^i - h_{\theta}(x^i))x_{j}^{i}$$

这种方法，每更新一次参数，需要对整个数据集进行运算，十分缓慢并且非常占内存，而且不能实时在线更新参数。这是最原始的梯度下降方法。从迭代的次数上来看，BGD迭代的次数相对较少。其迭代的收敛曲线示意图可以表示如下：

随机梯度下降（Stochatic Gradient Decent, SGD）

随机梯度下降一次只使用一个样本进行目标函数梯度计算，其公式为：

$$\theta = \theta - \alpha\nabla_{\theta}{J(\theta;x^i,j^i)}$$

即将上面的损失函数改写为：

$$J_{train}(\theta)=\frac{1}{m}\sum_{i=1}^{m}\frac{1}{2}(h_{\theta}(x^{(i)})-y^{(i)})^{2} = \frac{1}{m}\sum_{i=1}^{m}cost(\theta;x^i,j^i)$$

$$cost(\theta;x^i,j^i) = \frac{1}{2}(h_{\theta}(x^{(i)})-y^{(i)})^{2}$$

利用每个样本的损失函数对$\theta$求偏导得到对应的梯度，来更新$\theta$：

$$\theta_{j} = \theta_{j} + \alpha(y^i - h_{\theta}(x^i))x_{j}^{i}$$

随机梯度下降是通过每个样本来迭代更新一次，计算非常快并且适合线上更新模型。但是，SGD伴随的一个问题是噪音较BGD要多，使得SGD并不是每次迭代都向着整体最优化方向，在解空间的搜索过程看起来很盲目。其迭代的收敛曲线示意图可以表示如下：

上述两种方法，BGD 样本多时，训练慢，占内存；SGD 找到的解却不如 BGD，并且干扰较大，不易于并行实现。而 MBGD 则是在二者之间找到一个平衡。它一次以小批量的训练数据计算目标函数的权重并更新参数。公式如下：

$$\theta = \theta - \alpha\nabla_{\theta}{J(\theta;x^{(i:i+n)},j^{(i:i+n)})}$$

其中，n为每批训练集的数量，一般设为50到256。

虽然 MBGD 相对 BGD 和 SGD 更加优秀，但是仍然存在许多问题，比如：

1. 难以选择合适的学习速率：学习速率过小会造成网络收敛太慢，但是太大使得损失函数可能在最小点周围不断摇摆而永远达不到最小点；
2. 可以随着训练降低学习率，虽然这个方法有一些作用，但是由于降低学习率的周期是人为事先设定的，所以它不能很好地适应数据内在的规律；
3. 对特征向量中的所有的特征都采用了相同的学习率，如果训练数据十分稀疏并且不同特征的变化频率差别很大，这时候对变化频率慢得特征采用大的学习率而对变化频率快的特征采用小的学习率是更好的选择；
4. 可能出现在垂直于优化方向上的摆动。

因此我们需要更好的方法来进行梯度下降的求解。

梯度下降优化算法

Momentum

对于如图所示的损失函数等高线图：

其中中心的蓝色点表示了最优值。如图我们可以知道，其在 Y 轴比较陡峭，在 X 轴比较平缓。如果我们使用普通的梯度下降方法，如果选取较小的学习效率，则其收敛的图像如下面的第一张图。可以看出我们从某个点出发，整体趋势向着最优点前进，但是其在 Y 轴变化比较快，但是在 X 轴的前进非常缓慢。如果我们增大学习效率，则如第二张图，在 Y 轴抖动非常明显：

指数加权平均

对于一组连续的数值，比如温度，可能变化（波动）较大，如下图的蓝色点。如果我们想要拟合温度，我们需要一个较为平缓的曲线（红色）。

Momentum 梯度下降

借助指数加权平均的思想，我们可以解决上面的抖动问题。即在SGD的基础上，加上了上一步的梯度：

$$v_t = \gamma v_{t-1} + (1 - \gamma)\nabla_{\theta}{J(\theta)}$$
$$\theta = \theta - \alpha v_t$$

其中$\gamma$通常设为0.9。由于目标函数在Y方向上摇摆，所以前后两次计算的梯度在Y方向上相反，所以相加后相互抵消，而X方向上梯度方向不变，所以X方向的梯度是累加的，其效果就是损失函数在Y方向上的震荡减小了，而更加迅速地从X方向接近最优点。如图所示：

Nesterov Accelerated Gradient

但是上面，小球越来越快的往山谷滚动，越接近谷底越快，会导致冲过谷底。因此我们需要让小球感知坡度的变化，从而在它再次冲上山坡之前减速而避免错过山谷。NAG方法更新梯度的公式变为：

$$v_t = \gamma v_{t-1} + (1 - \gamma)\nabla_{\theta}{J(\theta - \gamma v_{t-1})}$$
$$\theta = \theta - \alpha v_t$$

即在 Momentum 的基础上，进行修正，达到减速的效果。

Adagrad

我们除了想让参数更新速率自适应坡度外，还需要适合处理稀疏特征的梯度更新算法。比如，稀疏特征采用高的更新速率，其他特征采用相对较低的更新速率。Adagrad是一种适合处理稀疏特征的梯度更新算法，它对稀疏特征采用高的更新速率，而对其他特征采用相对较低的更新速率。Dean等人发现Adagrad能很好地提高SGD的鲁棒性，它已经被谷歌用来训练大规模的神经网络。

Adagrad对每个参数使用不同的参数进行更新。如果用$g_{t,i}$来表示参数$\theta_i$在第t次更新时的梯度，即$g_{t,i} = \nabla_{\theta}{J(\theta_i)}$，则SGD的更新规则可以写作：

$$\theta_{t+1, i} = \theta_i - \alpha g_{t,i}$$

而Adagrad的更新规则可以表示为：

$$\theta_{t+1, i} = \theta_i - \frac{\alpha}{\sqrt{G_{t,ii} + \epsilon}} g_{t,i}$$

其中，$G_{t,ii}$是一个$\mathbb{R}^{d×d}$维的对角矩阵，其第i行第i列的元素为过去到当前第i个参数的梯度平方和，$\epsilon$是为了防止分母为0的平滑项。进一步，可以将上式向量化如下：

$$\theta_{t+1} = \theta_i - \frac{\alpha}{\sqrt{G_{t} + \epsilon}} \bigodot g_{t}$$

这样，利用Adagrad就可以自动根据每个特征的稀疏性来设置不同的学习率。但是$G_t$累加了参数的历史梯度的平方，所以到后期学习率会越来越小，最后无法再学习到新的信息。

Adadelta

Adadelta 和 Adagrad 的主要区别就是把 $G_t$变为$E[g^2]_t$，即不再累加参数所有的历史梯度平方和，转而设定一个窗口w，只求前w个历史梯度平方的平均数。而$E[g^2]t = \beta E[g^2]{t-1} + (1-\beta)g_t^2$，因此Adadelta更新规则可以写作：

$$\theta_{t+1} = \theta_i - \frac{\alpha}{\sqrt{E[g^2]t + \epsilon}} \bigodot g{t}$$

RMSprop

RMSprop（Root Mean Square prop）由Hinton提出，实际上是Adadelta的一种特殊形式：

$$E[g^2]t = \beta E[g^2]{t-1} + (1-\beta)g_t^2$$
$$\theta_{t+1} = \theta_t - \frac{\alpha}{\sqrt{E[g^2]t} + \epsilon} \bigodot g{t}$$

Adam

Adam的全称是Adaptive Moment Estimation, 它也是一种自适应学习率方法。可以把它看做 RMSprop 和 Momentum 的结合。

$$m_t = \beta_1 m_{t - 1} + (1 - \beta_1)g_t$$
$$v_t = \beta_2 v_{t - 1} + (1 - \beta_2)g_t^2$$

$m_t$,$v_t$分别是梯度的带权平均和带权有偏方差，由于当$\beta_1$,$\beta_2$接近于1时，这两项接近于0，因此对他们进行了偏差修正：

$$\hat{m_t} = \frac{m_t}{1 - \beta_1^t}$$
$$\hat{v_t} = \frac{v_t}{1 - \beta_2^t}$$

最终更新方程为：

$$\theta_{t+1} = \theta_t - \frac{\alpha}{\sqrt{\hat{v_t}} + \epsilon} \bigodot m_{t}$$

一般将$\beta_1$设为0.9,$\beta_2$设为0.999, $\epsilon$设为10−8。一般在深度学习的梯度优化中，会使用 Adam。

几种算法的效果对比

如图所示，所有方法都从相同位置出发，经历不同的路径到达了最小点，其中Adagrad、Adadelta和RMSprop一开始就朝向正确的方向并且迅速收敛，而冲量、NAG则会冲向错误的方向，但是由于NAG会向前多“看”一步所以能很快找到正确的方向。

九月中旬鹏哥给我打电话，让我给新入学的大一新生们写点东西，告诉他们我的大学四年是怎么样走过来的，然而国庆大东北去浪了，这件事情丢得一干二净。昨天鹏哥电话来催账了，才想起这件忘记得差不多的事情。

写给大一的新生，教他们怎么进入这个领域，如何去成长。教别人，这是一件大事。无论是工作，还是读研，亦或是技术上，有些人自己都 Low 得不行，却喜欢到处拼凑成一篇篇的“如何求职”或者“如何读研”的长文，装作一副过来人的样子到处分享。我不认为我有这个能力去“教”或者是告诉别人应该怎么做，这里只是一个心得，或者是对大学四年的一个总结吧，写个18岁的自己，各位看看就好。

引子

写给18岁的自己，这是无数的科幻作品的题材吧。希望18岁刚进入大学的懵懂的自己，能在某个晴朗的下午，在景观水渠边漫步，在环形大道上闲逛之时，亦或是在图书馆某个能看到远处风景的角落，读到这封信。

时间的长河，其实就是一次次的选择过程。18岁的你，已经成年，虽然可以继续任性，但是做的每一个选择，都决定了之后的你，而你做的每一个选择，都基于你来的路，也即你做过的选择。

这些文字，不可避免的会带有说教的意味，但是这篇文章，毫无说教的目的，只是希望能给18岁的你一些现在的我的一些看法，亦或是现在的我觉得后悔当时没做好的一些东西，希望能够帮到你做得更好。

接受

从未想到，现在的我想告诉你的第一点会是这个。但是的确，学会接受，是通往社会的第一个桥梁。18岁的你，一定还是愤慨，为什么高考会如此糟糕，来到了这个之前十多年一直瞧不起的大学，恨不得掐死高考场上的自己。但是，愤慨又有什么用呢？各种班委选拔，学生会、社团的面试，明明觉得自己很优秀，可是却落选了，觉得面试自己的人眼瞎，觉得别人一定用了不知道什么样的非正常手段吧。但是，结果这样，你不爽又有什么用呢？明明自己认真的感情付出，但是却换不回预想的结果，觉得人心险恶。但是，你即使伤心，即使自暴自弃，又有什么用呢？自己认真学习，认真完成作业，但是最终成绩却不如别人玩些小把戏，你会觉得老师一定是傻X。但是你骂老师一顿又有什么用呢？

18岁了，你会发现，这个学校，这个社会，并不像自己从小长大的环境，这里的一些事，充满了各种不可抗力的因素。不管你是为此多么努力，奋斗是多么艰辛，结果却和付出不成正比。你可以自暴自弃，但是学会接受，以后你可以做得更好。和结果比起来，也许中间的过程，才是对你之后的人生更加重要的。

也许当年在一本忘了什么名字的书上看到的一句话可以帮助到你：一个人可以被毁灭，但是不能被打败。凡不能毁灭我的，将使我更强大。

时间

大学虽然只有四年，但是这四年决定了你今后的高度。如果挥霍掉了，之后你也许10年也补不回来。刚进入大学，脱离了家长老师的严加管教，也许你觉得尽情的玩游戏了，可以尽情的看小说了，可以随便出去玩了。也许室友每天很开心的玩，很让你心动，想和他们一起开黑一起吃鸡。你可以一起玩，但是控制好自己的时间，若干年后看着他们，你会觉得，幸好当年没和他们一样堕落下去。

自驱动

上面说的挥霍，是指把时间大量的耗费在玩上面。但是如果你把“玩”当做自己的职业，那即使是游戏，也可以定性为在学习，那么花时间在它身上，又何尝不可。

大学四年，是你能够连续性的把时间花费在学习上面的最宝贵的阶段。好好珍惜这段时间，系统性的把自己应该掌握的知识学好，这些系统性学习的东西，将会伴随你一生，成为你整个知识体系的主干。在之后的职业生涯中，你学会的各种其他知识、技能、经验，也只是这主干上的枝叶。干之不成，枝叶焉在？

18岁了，已经没有人在你耳边天天念叨好好学习了，也没有人来守着你学习了。成年的意义，在于自己知道自己应该做什么，应该如何做了。失去了身边的鞭策，你需要学会在心里给自己定一个标杆，一个人或者一个里程碑，不断的去完善自己，去鞭策自己，达到自己的目标。

系统化

上面说到花时间学习，但是如果杂乱无章的学，往往会被一个个的散乱的知识点吞噬，事半功倍。你要学会系统的去整理知识点，找出一个个散乱知识点之间的联系，然后有针对的主动去积累学到的知识。而系统化，能够让你知道，什么是主干，什么是枝叶，主干和枝叶之间又是怎么联系起来的。

时间长河带来的是熵的增加，但是我们存在的意义却是不断积累系统化的知识体系，这是一件很有趣的对抗。18岁的你，应该开始在自己选定的领域里面，主动去积累系统化的知识，积累得越多，越系统，你能够更加透彻的看透这个领域中的迷雾，而你一辈子工作的本质，甚至是人生的本质，也是这个不断积累系统化知识的过程。

兴趣点

即使选择了这个专业，也不意味着对这个专业涉及到的所有知识感兴趣。因此需要找到自己的兴趣点，把这个点深挖，做到自己能做的最好。当然这个兴趣点也行会随着时间的变化而变化，但是每到一个点，你应该真正的喜欢它，有一种执着的渴望去钻研，这样就会自然的有自驱动力。

如果一个人靠着自制力去抵抗诱惑做某件事，那他还只是寻常人；如果他能够靠着内心对某事的执着追求去做这件事而抵御其他诱惑，这才是圣人

目标

当你找到了兴趣点，那么你就应该有一个规划。我知道这对于你来说很难，但是你必须对自己有一个长线的规划，比如想要有个什么样的工作。有了这个长线的目标，那么你就能切分一下，比如这个工作，是否需要出国，或者这个工作是否需要读研，来制定一个中期的目标。并且不断的递归，能够制定精确到周或者月的目标更好。这样你就能更加明确的知道，现在应该做什么，做到什么程度了。比如你就能知道，你的更多的精力，是应该放在分数上，亦或是实践上。

实践

你选择的专业，是一个理工类的专业，其实更加偏重工程实践。死学知识，你也许可以做到考高分，完成自己诸如考研、保研、留学的目标，但是没有实际的实践能力，会严重制约你之后的工作。书上的东西，自己照着实践一遍，或者是一些小的完整的项目，自己尝试去完成一下。在实践的过程中，你会发现你对一些已经学到的知识，有了更加深刻的了解，亦或是发现一些自己尚不了解的知识，能够通过实践过程来学习。

数学、算法、工程

本来想告诉你，数学很重要。又想告诉你，算法很重要。想了下，工程也很重要。遂合并三者，一同告知。

数学是理工科的灵魂，也许你现在不知道学的乱七八糟的高数、线代、概统、离散等等数学有什么用，觉得认真学专业知识就够了。但是你要知道，你现在学习的专业知识，都是很基础的东西，当你以后涉及到一些更深层面的知识时，没有数学这把刀，没法在迷雾中抽丝剥茧，学到一些本质。

算法其实可以概括为数学，但是我觉得算法又不同于上面的数学。你可以理解为算法就是 ACM，就是刷各种 OJ。也许你觉得很无聊，但是在刷题的过程中，你对代码本身的理解，包括你的思维能力，都得到的提高。更加俗的来讲，算法能力可能决定了你在这个行业之后的工资水平。

工程能力，也可以理解为上面的实践能力。是你在代码世界的造物能力。工程能力需要多实践，多思考来培养，需要无数次的尝试，无数次的调试来历练。优秀的工程能力，能够让你的作品经受住各种外在需求的变更，负载起大规模的访问，能够一眼理出庞大系统逻辑。

不能狂