Redis 多線程演進

Redis 作爲一個基於內存的緩存系統，一直以高性能著稱，因沒有上下文切換以及無鎖操作，即使在單線程處理情況下，讀速度仍可達到 11 萬次 / s，寫速度達到 8.1 萬次 / s。但是，單線程的設計也給 Redis 帶來一些問題：

針對上面問題，Redis 在 4.0 版本以及 6.0 版本分別引入了Lazy Free以及多線程IO，逐步向多線程過渡，下面將會做詳細介紹。

| 單線程原理

都說 Redis 是單線程的，那麼單線程是如何體現的？如何支持客戶端併發請求的？爲了搞清這些問題，首先來了解下 Redis 是如何工作的。

Redis 服務器是一個事件驅動程序，服務器需要處理以下兩類事件：

事件調度

如上圖，Redis 將文件事件和時間事件進行抽象，時間輪訓器會監聽 I/O 事件表，一旦有文件事件就緒，Redis 就會優先處理文件事件，接着處理時間事件。在上述所有事件處理上，Redis 都是以單線程形式處理，所以說 Redis 是單線程的。此外，如下圖，Redis 基於 Reactor 模式開發了自己的 I/O 事件處理器，也就是文件事件處理器，Redis 在 I/O 事件處理上，採用了 I/O 多路複用技術，同時監聽多個套接字，併爲套接字關聯不同的事件處理函數，通過一個線程實現了多客戶端併發處理。

多路複用件

正因爲這樣的設計，在數據處理上避免了加鎖操作，既使得實現上足夠簡潔，也保證了其高性能。當然，Redis 單線程只是指其在事件處理上，實際上，Redis 也並不是單線程的，比如生成 RDB 文件，就會 fork 一個子進程來實現，當然，這不是本文要討論的內容。

| Lazy Free 機制

如上所知，Redis 在處理客戶端命令時是以單線程形式運行，而且處理速度很快，期間不會響應其他客戶端請求，但若客戶端向 Redis 發送一條耗時較長的命令，比如刪除一個含有上百萬對象的 Set 鍵，或者執行 flushdb，flushall 操作，Redis 服務器需要回收大量的內存空間，導致服務器卡住好幾秒，對負載較高的緩存系統而言將會是個災難。爲了解決這個問題，在 Redis 4.0 版本引入了Lazy Free，將慢操作異步化，這也是在事件處理上向多線程邁進了一步。

如作者在其博客中所述，要解決慢操作，可以採用漸進式處理，即增加一個時間事件，比如在刪除一個具有上百萬個對象的 Set 鍵時，每次只刪除大鍵中的一部分數據，最終實現大鍵的刪除。但是，該方案可能會導致回收速度趕不上創建速度，最終導致內存耗盡。因此，Redis 最終實現上是將大鍵的刪除操作異步化，採用非阻塞刪除（對應命令UNLINK），大鍵的空間回收交由單獨線程實現，主線程只做關係解除，可以快速返回，繼續處理其他事件，避免服務器長時間阻塞。

以刪除（DEL命令）爲例，看看 Redis 是如何實現的，下面就是刪除函數的入口，其中，lazyfree_lazy_user_del是是否修改DEL命令的默認行爲，一旦開啓，執行DEL時將會以UNLINK形式執行。

void delCommand(client *c) {
    delGenericCommand(c,server.lazyfree_lazy_user_del);
}

/* This command implements DEL and LAZYDEL. */
void delGenericCommand(client *c, int lazy) {
    int numdel = 0, j;

    for (j = 1; j < c->argc; j++) {
        expireIfNeeded(c->db,c->argv[j]);
        // 根據配置確定DEL在執行時是否以lazy形式執行
        int deleted  = lazy ? dbAsyncDelete(c->db,c->argv[j]) :
                              dbSyncDelete(c->db,c->argv[j]);
        if (deleted) {
            signalModifiedKey(c,c->db,c->argv[j]);
            notifyKeyspaceEvent(NOTIFY_GENERIC,
                "del",c->argv[j],c->db->id);
            server.dirty++;
            numdel++;
        }
    }
    addReplyLongLong(c,numdel);
}

同步刪除很簡單，只要把 key 和 value 刪除，如果有內層引用，則進行遞歸刪除，這裏不做介紹。下面看下異步刪除，Redis 在回收對象時，會先計算回收收益，只有回收收益在超過一定值時，採用封裝成 Job 加入到異步處理隊列中，否則直接同步回收，這樣效率更高。回收收益計算也很簡單，比如String類型，回收收益值就是 1，而Set類型，回收收益就是集合中元素個數。

/* Delete a key, value, and associated expiration entry if any, from the DB.
 * If there are enough allocations to free the value object may be put into
 * a lazy free list instead of being freed synchronously. The lazy free list
 * will be reclaimed in a different bio.c thread. */
#define LAZYFREE_THRESHOLD 64
int dbAsyncDelete(redisDb *db, robj *key) {
    /* Deleting an entry from the expires dict will not free the sds of
     * the key, because it is shared with the main dictionary. */
    if (dictSize(db->expires) > 0) dictDelete(db->expires,key->ptr);

    /* If the value is composed of a few allocations, to free in a lazy way
     * is actually just slower... So under a certain limit we just free
     * the object synchronously. */
    dictEntry *de = dictUnlink(db->dict,key->ptr);
    if (de) {
        robj *val = dictGetVal(de);
        // 計算value的回收收益
        size_t free_effort = lazyfreeGetFreeEffort(val);

        /* If releasing the object is too much work, do it in the background
         * by adding the object to the lazy free list.
         * Note that if the object is shared, to reclaim it now it is not
         * possible. This rarely happens, however sometimes the implementation
         * of parts of the Redis core may call incrRefCount() to protect
         * objects, and then call dbDelete(). In this case we'll fall
         * through and reach the dictFreeUnlinkedEntry() call, that will be
         * equivalent to just calling decrRefCount(). */
        // 只有回收收益超過一定值，纔會執行異步刪除，否則還是會退化到同步刪除
        if (free_effort > LAZYFREE_THRESHOLD && val->refcount == 1) {
            atomicIncr(lazyfree_objects,1);
            bioCreateBackgroundJob(BIO_LAZY_FREE,val,NULL,NULL);
            dictSetVal(db->dict,de,NULL);
        }
    }

    /* Release the key-val pair, or just the key if we set the val
     * field to NULL in order to lazy free it later. */
    if (de) {
        dictFreeUnlinkedEntry(db->dict,de);
        if (server.cluster_enabled) slotToKeyDel(key->ptr);
        return 1;
    } else {
        return 0;
    }
}

通過引入a threaded lazy free，Redis 實現了對於Slow Operation的Lazy操作，避免了在大鍵刪除，FLUSHALL，FLUSHDB時導致服務器阻塞。當然，在實現該功能時，不僅引入了lazy free線程，也對 Redis 聚合類型在存儲結構上進行改進。因爲 Redis 內部使用了很多共享對象，比如客戶端輸出緩存。當然，Redis 並未使用加鎖來避免線程衝突，鎖競爭會導致性能下降，而是去掉了共享對象，直接採用數據拷貝，如下，在 3.x 和 6.x 中ZSet節點 value 的不同實現。

// 3.2.5版本ZSet節點實現，value定義robj *obj
/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    robj *obj;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned int span;
    } level[];
} zskiplistNode;

// 6.0.10版本ZSet節點實現，value定義爲sds ele
/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;

去掉共享對象，不但實現了lazy free功能，也爲 Redis 向多線程跨進帶來了可能，正如作者所述：

Now that values of aggregated data types are fully unshared, and client output buffers don’t contain shared objects as well, there is a lot to exploit. For example it is finally possible to implement threaded I/O in Redis, so that different clients are served by different threads. This means that we’ll have a global lock only when accessing the database, but the clients read/write syscalls and even the parsing of the command the client is sending, can happen in different threads.

| 多線程 I/O 及其侷限性

Redis 在 4.0 版本引入了Lazy Free，自此 Redis 有了一個Lazy Free線程專門用於大鍵的回收，同時，也去掉了聚合類型的共享對象，這爲多線程帶來可能，Redis 也不負衆望，在 6.0 版本實現了多線程I/O。

實現原理

正如官方以前的回覆，Redis 的性能瓶頸並不在 CPU 上，而是在內存和網絡上。因此 6.0 發佈的多線程並未將事件處理改成多線程，而是在 I/O 上，此外，如果把事件處理改成多線程，不但會導致鎖競爭，而且會有頻繁的上下文切換，即使用分段鎖來減少競爭，對 Redis 內核也會有較大改動，性能也不一定有明顯提升。

多線程 IO 實現

如上圖紅色部分，就是 Redis 實現的多線程部分，利用多核來分擔 I/O 讀寫負荷。在事件處理線程每次獲取到可讀事件時，會將所有就緒的讀事件分配給I/O線程，並進行等待，在所有I/O線程完成讀操作後，事件處理線程開始執行任務處理，在處理結束後，同樣將寫事件分配給I/O線程，等待所有I/O線程完成寫操作。

以讀事件處理爲例，看下事件處理線程任務分配流程：

int handleClientsWithPendingReadsUsingThreads(void) {
    ...

    /* Distribute the clients across N different lists. */
    listIter li;
    listNode *ln;
    listRewind(server.clients_pending_read,&li);
    int item_id = 0;
    // 將等待處理的客戶端分配給I/O線程
    while((ln = listNext(&li))) {
        client *c = listNodeValue(ln);
        int target_id = item_id % server.io_threads_num;
        listAddNodeTail(io_threads_list[target_id],c);
        item_id++;
    }

    ...

    /* Wait for all the other threads to end their work. */
    // 輪訓等待所有I/O線程處理完
    while(1) {
        unsigned long pending = 0;
        for (int j = 1; j < server.io_threads_num; j++)
            pending += io_threads_pending[j];
        if (pending == 0) break;
    }

    ...

    return processed;
}

I/O線程處理流程：

void *IOThreadMain(void *myid) {
    ...

    while(1) {
        ...

        // I/O線程執行讀寫操作
        while((ln = listNext(&li))) {
            client *c = listNodeValue(ln);
            // io_threads_op判斷是讀還是寫事件
            if (io_threads_op == IO_THREADS_OP_WRITE) {
                writeToClient(c,0);
            } else if (io_threads_op == IO_THREADS_OP_READ) {
                readQueryFromClient(c->conn);
            } else {
                serverPanic("io_threads_op value is unknown");
            }
        }
        listEmpty(io_threads_list[id]);
        io_threads_pending[id] = 0;

        if (tio_debug) printf("[%ld] Done\n", id);
    }
}

侷限性

從上面實現上看，6.0 版本的多線程並非徹底的多線程，I/O線程只能同時執行讀或者同時執行寫操作，期間事件處理線程一直處於等待狀態，並非流水線模型，有很多輪訓等待開銷。

Tair 多線程實現原理

相較於 6.0 版本的多線程，Tair 的多線程實現更加優雅。如下圖，Tair 的Main Thread負責客戶端連接建立等，IO Thread負責請求讀取、響應發送、命令解析等，Worker Thread線程專門用於事件處理。IO Thread讀取用戶的請求並進行解析，之後將解析結果以命令的形式放在隊列中發送給Worker Thread處理。Worker Thread將命令處理完成後生成響應，通過另一條隊列發送給IO Thread。爲了提高線程的並行度，IO Thread和Worker Thread之間採用無鎖隊列 和管道 進行數據交換，整體性能會更好。

| 小結

Redis 4.0 引入Lazy Free線程，解決了諸如大鍵刪除導致服務器阻塞問題，在 6.0 版本引入了I/O Thread線程，正式實現了多線程，但相較於 Tair，並不太優雅，而且性能提升上並不多，壓測看，多線程版本性能是單線程版本的 2 倍，Tair 多線程版本則是單線程版本的 3 倍。在作者看來，Redis 多線程無非兩種思路，I/O threading和Slow commands threading，正如作者在其博客中所說：

I/O threading is not going to happen in Redis AFAIK, because after much consideration I think it’s a lot of complexity without a good reason. Many Redis setups are network or memory bound actually. Additionally I really believe in a share-nothing setup, so the way I want to scale Redis is by improving the support for multiple Redis instances to be executed in the same host, especially via Redis Cluster.

What instead I really want a lot is slow operations threading, and with the Redis modules system we already are in the right direction. However in the future (not sure if in Redis 6 or 7) we’ll get key-level locking in the module system so that threads can completely acquire control of a key to process slow operations. Now modules can implement commands and can create a reply for the client in a completely separated way, but still to access the shared data set a global lock is needed: this will go away.

Redis 作者更傾向於採用集羣方式來解決I/O threading，尤其是在 6.0 版本發佈的原生 Redis Cluster Proxy 背景下，使得集羣更加易用。此外，作者更傾向於slow operations threading（比如 4.0 版本發佈的Lazy Free）來解決多線程問題。後續版本，是否會將IO Thread實現的更加完善，採用 Module 實現對慢操作的優化，着實值得期待。

轉自：景同學

鏈接：https://juejin.cn/post/6928407842009546766

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Im1jNXGaGx7ssnAOqHNr_Q

猜你喜歡