redis3.0深入详解（1）

4月1日，redis3.0-stable正式发布。引入了久违的cluster模式，同时进行了多处优化。本文，从源码级别对3.0和2.8.19进行对比，详细解释优化细节。由于能力及时间有限，只会对我已经读过的源码部分进行对比，同时不涉及cluster相关内容。

1. Embedded String

减少由于cache miss带来的内存读取，进一步提升缓存命中率，在某些场景下，大幅提升速度。

1）2.8

redis中，所有对象通过robj表示，包括key和value：

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;

由type指定类型，泛型指针ptr指向具体的对象。对于字符串，ptr直接指向该字符串对应的内存。由于通过间接指针关联，一般情况下，robj和字符串不在连续内存中，读取字符串时，需要两次内存操作。

2）3.0

redis3.0中，如果字符串长度小于39，则会使用ebeded string，将robj和字符串分配在一块连续内存中。由于局部性原理，在读取时，robj和字符串内容都会读到cache中，从而只要一次内存读取即可。

    // <MM>
    // 分配一块内存，容纳robj, sds header, 字符串和'\0'
    // </MM>
    robj *o = zmalloc(sizeof(robj)+sizeof(struct sdshdr)+len+1);
    struct sdshdr *sh = (void*)(o+1);

    o->type = REDIS_STRING;
    o->encoding = REDIS_ENCODING_EMBSTR;
    o->ptr = sh+1;
    o->refcount = 1;
    o->lru = LRU_CLOCK();

    sh->len = len;
    sh->free = 0;
    if (ptr) {
        // <MM>
        // 拷贝字符串内容
        // </MM>
        memcpy(sh->buf,ptr,len);
        sh->buf[len] = '\0';
    } else {
        memset(sh->buf,0,len+1);
    }
    return o;

长度限制在39的原因是，redis使用jemalloc，会以64字节为一个内存块进行分配。robj（16字节），sds的头部（16字节）和字符串结尾的’\0'会占用25字节。

redis中所有的key都是字符串类型，所以这个优化会大幅提升redis的cache命中率。 在实际使用时，可以尽量将key的大小限制在39字节内，充分利用cache，提升性能。

2. AOF Rewrite

在完成rewrite的最后一个步骤中，redis主进程需要将rewrite期间的增量aof diff追加到aof文件中，这是一个比较重的磁盘io操作，会阻塞事件循环，增加延迟，造成服务抖动。

1）2.8

rewrite的流程：

- 主进程fork子进程，由子进程进行rewrite，主进程继续服务请求。同时主进程会初始化一个aof rewrite buffer，用于收集rewrite期间的增量aof diff。

- 子进程完成rewrite后，主进程会wait子进程并对其进行收割。此时，启动rewrite时的数据集已经生成一份aof文件，接下来主进程需要把aof rewrite buffer追加到该aof文件的最后。

由于rewrite过程比较漫长，累积的aof rewrite buffer会比较大，主进程进行追加写操作，会产生磁盘操作，阻塞事件循环，此时的redis是不能服务的，会影响业务。

2）3.0

父子进程间建立pipe进行通信。在子进程进行rewrite期间，父进程会不断的通过pipe向子进程发送aof diff，子进程会不停的收集到aof rewrite buffer中。当子进程完成rewrite后。会通知父进程停止发送aof diff。然后子进程将收集到的aof rewrite buffer追加到重写后的aof文件的最后。

父进程完成对子进程收割后，会把剩余的rewrite buffer追加到aof文件（这个rewrite buffer相对要小一些）。

改进点：

- 大部分的磁盘操作由子进程完成，父进程只需进行小数据量的磁盘操作

- aof rewrite buffer的输出会被打散到每个命令的处理过程中，降低延迟，不会造成大的抖动

3. LRU近似算法改进

如果配置了maxmemory，在每个命令处理过程中，如果占用内存超过maxmemory，redis会根据LRU算法踢出一些key，以释放内存。redis采用的LRU算法是近似的，并没有维护一个LRU链，以精确的表示先后顺序。

在robj中，由属性lru表示该对象最后被访问的时间。同时，全局变量redisServer.lruclock表示当前的lru时钟，在serverCron（每毫秒执行一次）中会不停更新lruclock。当对象被创建或者被访问时，用lruclock更新该对象的lru属性。

#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;

lru占用24个bit，最大值是2^24 - 1，单位是秒。那么，lru有效范围是0.5年（2^24 / 365 / 86400），当一个key半年没有被访问，其lru会重新归0，而错过踢出。

2）2.8

lruclock的计算方法：

    server.lruclock = (server.unixtime/REDIS_LRU_CLOCK_RESOLUTION) &
                                                REDIS_LRU_CLOCK_MAX;

REDIS_LRU_CLOCK_RESOLUTION表示lru的精度，设置的是秒。

在freeMemoryIfNeed函数中会进行lru踢出的逻辑。

                for (k = 0; k < server.maxmemory_samples; k++) {
                    sds thiskey;
                    long thisval;
                    robj *o;

                    // <MM>
                    // 随机选择一个kv对
                    // </MM>
                    de = dictGetRandomKey(dict);
                    thiskey = dictGetKey(de);
                    /* When policy is volatile-lru we need an additional lookup
                     * to locate the real key, as dict is set to db->expires. */
                    if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
                        de = dictFind(db->dict, thiskey);
                    o = dictGetVal(de);
                    // <MM>
                    // 获取其lru值
                    // </MM>
                    thisval = estimateObjectIdleTime(o);

                    // <MM>
                    // 选择最久没有访问的key
                    // </MM>
                    /* Higher idle time is better candidate for deletion */
                    if (bestkey == NULL || thisval > bestval) {
                        bestkey = thiskey;
                        bestval = thisval;
                    }
                }

踢出逻辑比较简单，随机选择maxmemory_samples个对象，选择其中lru值最小的作为要踢出的key。 maxmemory_samples可以配置，默认是3。

3）3.0

lruclock计算方法：

(mstime()/REDIS_LRU_CLOCK_RESOLUTION) & REDIS_LRU_CLOCK_MAX;

REDIS_LRU_CLOCK_RESOLUTION为1000，即精度是毫秒。

为了提升LRU近似算法的准确性，redisDb中增加一个属性eviction_pool，表示一个要踢出的key的候选池。

/* Redis database representation. There are multiple databases identified
 * by integers from 0 (the default database) up to the max configured
 * database. The database number is the 'id' field in the structure. */
typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB */
    dict *expires;              /* Timeout of keys with a timeout set */
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    struct evictionPoolEntry *eviction_pool;    /* Eviction pool of keys */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
} redisDb;

eviction_pool结构如下，包含一个key和其对应的lru时间。

#define REDIS_EVICTION_POOL_SIZE 16
struct evictionPoolEntry {
    unsigned long long idle;    /* Object idle time. */
    sds key;                    /* Key name. */
};

eviction_pool组织成一个数组，长度为16，并且按照idle从小到大排序。看下lru踢出逻辑，同样是在freeMemoryIfNeed函数中：

                struct evictionPoolEntry *pool = db->eviction_pool;

                while(bestkey == NULL) {
                    // <MM>
                    // 填充eviction_pool，在第一次时随机选择16个key填充，
                    // 之后每次调用时，只需要填充一个key
                    // </MM>
                    evictionPoolPopulate(dict, db->dict, db->eviction_pool);
                    /* Go backward from best to worst element to evict. */
                    for (k = REDIS_EVICTION_POOL_SIZE-1; k >= 0; k--) {
                        if (pool[k].key == NULL) continue;
                        de = dictFind(dict,pool[k].key);

                        /* Remove the entry from the pool. */
                        sdsfree(pool[k].key);
                        /* Shift all elements on its right to left. */
                        memmove(pool+k,pool+k+1,
                            sizeof(pool[0])*(REDIS_EVICTION_POOL_SIZE-k-1));
                        /* Clear the element on the right which is empty
                         * since we shifted one position to the left.  */
                        pool[REDIS_EVICTION_POOL_SIZE-1].key = NULL;
                        pool[REDIS_EVICTION_POOL_SIZE-1].idle = 0;

                        /* If the key exists, is our pick. Otherwise it is
                         * a ghost and we need to try the next element. */
                        if (de) {
                            bestkey = dictGetKey(de);
                            break;
                        } else {
                            /* Ghost... */
                            continue;
                        }
                    }
                }

填充 eviction_pool时，随机选择16个key，并按照插入排序添加到pool中。填充完之后，选择pool的最后一个元素（idle最大）作为踢出对象。

改进点：

- 精度改为毫秒，更精确

- 避免每次lru踢出时，需要多次迭代选择踢出对象

4. INCR命令

1）2.8

redis为了节省内存，对于可以整数化的字符串直接以long型存储（只占8个字节）。并且redis有一个整数常量池，对于在[0, 10000]内的整数，直接引用常量池中的对象。

    oldvalue = value;
    if ((incr < 0 && oldvalue < 0 && incr < (LLONG_MIN-oldvalue)) ||
            (incr > 0 && oldvalue > 0 && incr > (LLONG_MAX-oldvalue))) {
        addReplyError(c,"increment or decrement would overflow");
        return;
    }
    // value是原来的值，加上增量
    value += incr;
    // 根据value，创建一个新的string类型的robj，
    // 如果命中常量池，并不会创建新的对象，只有大于10000的才会创建。
    new = createStringObjectFromLongLong(value);
    // 需要一次hash查找，添加新对象或覆盖原有对象
    if (o)
        dbOverwrite(c->db,c->argv[1],new);
    else
        dbAdd(c->db,c->argv[1],new);

只要调用incr命令，就会存在一次hash查找。并且，对于大于10000的情况，需要创建新的robj

2）3.0

3.0对大于10000，不命中常量池的场景做了优化，可以避免hash查找，以及对象创建。

    // 计算新的值
    value += incr;

    if (o && o->refcount == 1 && o->encoding == REDIS_ENCODING_INT &&
            (value < 0 || value >= REDIS_SHARED_INTEGERS) &&
             value >= LONG_MIN && value <= LONG_MAX)
    {
       // 如果该对象的encoding是REDIS_ENCODING_INT，并且不在常量池的范围内
       // 同时引用计数小于1，则直接更改对象的值
       new = o;
       o->ptr = (void*)((long)value);
    } else {
       // 命中常量池，或者引用计数不唯一，按照以前的方式
       new = createStringObjectFromLongLong(value);
       if (o) {
           dbOverwrite(c->db,c->argv[1],new);
       } else {
           dbAdd(c->db,c->argv[1],new);
       }
    }

在没有命中常量池并且引用计数为1的情况，直接修改对象的值，不需要hash查找以及创建新对象。其余情况，还走原来的流程。

之所以只有引用计数为1时才进行优化，是避免与其他逻辑共享对象，造成不一致（比如key，重新编码后，hash查找会失败）。