作者 | GL

導(dǎo)讀

提升廣告檢索漏斗一致性，要求在粗排階段引入更豐富的信號(hào)，這些信號(hào)的需求量已經(jīng)遠(yuǎn)遠(yuǎn)超出了內(nèi)存的承受能力。為此，我們考慮引入基于NVMe SSD的分層存儲(chǔ)。本文詳細(xì)探討了一種長(zhǎng)尾可控的方法論，以及在這個(gè)方法論的約束下，如何極致優(yōu)化讀調(diào)度。這些方法對(duì)于實(shí)施類似LargerThanMem的技術(shù)也將提供有價(jià)值的啟發(fā)。

01業(yè)務(wù)背景

業(yè)務(wù)需要更大存儲(chǔ)空間，需求量預(yù)期遠(yuǎn)超過(guò)內(nèi)存可承受。舉例來(lái)說(shuō)，客戶落地頁(yè)是客戶營(yíng)銷內(nèi)容的核心陣地，增強(qiáng)對(duì)客戶落地頁(yè)內(nèi)容特征理解，才能實(shí)現(xiàn)用戶興趣和客戶投放的精準(zhǔn)匹配，提升用戶體驗(yàn)和轉(zhuǎn)化率，鳳巢正排服務(wù)引入 URL 明文是關(guān)鍵一步。鳳巢正排服務(wù)檢索查詢完全基于內(nèi)存，內(nèi)存存儲(chǔ)著億級(jí)別廣告物料和檢索線程需要的上下文。鳳巢正排服務(wù)實(shí)例上萬(wàn)，單實(shí)例內(nèi)存 Quota 已高達(dá)云原生紅線，常態(tài)利用率 85+%，URL 明文引入后，即使業(yè)務(wù)上極致去重壓縮，單實(shí)例還需增加數(shù)十GB，預(yù)期隨廣告庫(kù)會(huì)繼續(xù)增長(zhǎng)，內(nèi)存已遠(yuǎn)遠(yuǎn)不夠。

廣告檢索過(guò)程引入基于 NVMe SSD 的分級(jí)存儲(chǔ)，長(zhǎng)尾控制尤其關(guān)鍵。檢索效果對(duì)處理性能極為敏感，若查詢超時(shí)導(dǎo)致檢索 KPI 失效，將可能造成廣告丟失，從而帶來(lái)收入損失。以鳳巢正排服務(wù)來(lái)看，單 PV 召回廣告創(chuàng)意量在萬(wàn)級(jí)別，正排服務(wù)通過(guò)多分庫(kù)分包實(shí)現(xiàn)并行，即使在單個(gè)包內(nèi)，廣告創(chuàng)意數(shù)量也可達(dá)數(shù)百。從檢索系統(tǒng)的算力分配來(lái)看，針對(duì)百條 URL 明文的查詢，其長(zhǎng)尾性能空間僅為 5ms。

02技術(shù)背景

SSD 作為內(nèi)存存儲(chǔ)擴(kuò)展，缺點(diǎn)是讀寫干擾不可控。SSD[1] 的操作要求必須按頁(yè)進(jìn)行讀寫，否則會(huì)導(dǎo)致讀寫放大效應(yīng)。此外，SSD 硬件特性還要求“擦除后寫”，因此寫數(shù)據(jù)會(huì)額外引起數(shù)據(jù)搬運(yùn)損耗和擦除損耗，而擦除操作的耗時(shí)往往是讀操作時(shí)間的 1000 倍！更令人擔(dān)憂的是，對(duì)于那些需要極低隨機(jī)讀取的業(yè)務(wù)而言，SSD 就像一個(gè)無(wú)法調(diào)節(jié)的『黑匣子』，應(yīng)用無(wú)法直接干預(yù)由讀寫干擾帶來(lái)的查詢長(zhǎng)尾問(wèn)題。

業(yè)界常用訪盤優(yōu)化手段，未能控制讀長(zhǎng)尾。業(yè)界常用軟件寫盤優(yōu)化，確實(shí)可以顯著提升吞吐，但對(duì)長(zhǎng)尾控制力度有限，主要手段是：① 把隨機(jī)寫轉(zhuǎn)化為對(duì)齊寫、順序?qū)懀?整文件大塊刪除，③ 流量低峰期觸發(fā)盤 GC。比如論文 FAST' 15《F2FS: A New File System for Flash Storage》[2] 介紹了一種面向 SSD 的全新文件系統(tǒng)F2FS，基于 Log-Structured File System 的技術(shù)，將所有的寫入操作轉(zhuǎn)換為日志記錄，從而減少寫放大效應(yīng)，并提高了寫入吞吐。下圖中展示 F2FS v.s. ext4 在隨機(jī)寫場(chǎng)景（varmail、oltp）獲得吞吐優(yōu)勢(shì)：

△F2FS: A New File System for Flash Storage》 圖4

業(yè)界涌現(xiàn)出新硬件控制讀長(zhǎng)尾。硬件標(biāo)準(zhǔn)如 OpenChannel[3,4]，在塊存儲(chǔ)之外還額外提供了接口，使得業(yè)務(wù)可以更加精細(xì)地控制數(shù)據(jù)位置和命令調(diào)度，從而結(jié)合業(yè)務(wù)特點(diǎn)，在一定程度上實(shí)現(xiàn)了讀寫隔離，進(jìn)而控制了長(zhǎng)尾效應(yīng)。曾經(jīng)，Linux LightNVM[5] 試圖標(biāo)準(zhǔn)化對(duì) OpenChannel 的操作，但由于難以定義合理且簡(jiǎn)單的塊操作接口，最終被放棄，這也催生了 Zoned Namespace SSD（ZNS）[6] 新的硬件標(biāo)準(zhǔn)。ZNS 硬件并不是傳統(tǒng)的塊存儲(chǔ)，而是一種稱為 Zone 存儲(chǔ)的概念。整個(gè)固態(tài)硬盤被劃分為多個(gè)等長(zhǎng)的區(qū)域，稱為 Zone。Zone 內(nèi)的數(shù)據(jù)必須以順序的頁(yè)對(duì)齊方式進(jìn)行寫入，并且在進(jìn)行 Zone 內(nèi)數(shù)據(jù)復(fù)寫之前，需要對(duì)整個(gè) Zone 進(jìn)行 reset 操作。ZNS 硬件層面，也按 Zone 接口做了擦除單元隔離。

△《ZNS: Avoiding the Block Interface Tax for Flash-based SSDs》圖5

新硬件的引入和打磨需要較長(zhǎng)的周期，短期的業(yè)務(wù)需求亟需滿足。從長(zhǎng)遠(yuǎn)來(lái)看，ZNS 固態(tài)硬盤是未來(lái)的發(fā)展趨勢(shì)，我們也已經(jīng)和基礎(chǔ)架構(gòu)團(tuán)隊(duì)共同探索。然而，在當(dāng)前情況下，我們需要充分利用現(xiàn)有的檢索池中的 Nvme 存儲(chǔ)。為此，我們發(fā)起了 Ecomm Uniform SSD Layer - SsdEngine 項(xiàng)目，其目標(biāo)是在底層集成各種硬件（包括 NVMe、ZNS），在上層根據(jù)典型的商業(yè)業(yè)務(wù)場(chǎng)景封裝接口，讓商業(yè)業(yè)務(wù)最大限度用上硬件發(fā)展和軟硬件結(jié)合的技術(shù)紅利。

△SsdEngine整體架構(gòu)

通用場(chǎng)景 NVMe 長(zhǎng)尾完全不可控，檢索特化場(chǎng)景長(zhǎng)尾可控。Nvme SSD 在實(shí)際應(yīng)用中確實(shí)受到多種讀寫干擾因素的影響，其主要因素包括讀寫單元大小（ValueSize）、讀寫頻次（IOPS）、數(shù)據(jù)生命周期一致性（Lifetime）等等。這些影響因素的作用是復(fù)雜的，且無(wú)法簡(jiǎn)單地通過(guò)公式化加以描述 [7]。然而，檢索業(yè)務(wù)也有應(yīng)用特殊性：檢索業(yè)務(wù)屬于重讀輕寫的場(chǎng)景，在滿足足夠吞吐用于回溯止損的前提下，我們甚至愿意在一定程度上犧牲一部分寫吞吐，以換取更為穩(wěn)定的讀性能。基于這一背景，結(jié)合檢索業(yè)務(wù)的獨(dú)特特點(diǎn)，我們采用了硬件友好的磁盤訪問(wèn)模式（Disk Access Pattern），并設(shè)計(jì)了一套基準(zhǔn)測(cè)試（Benchmark）方案，以此來(lái)進(jìn)行系統(tǒng)性能評(píng)測(cè)。在評(píng)測(cè)中，我們針對(duì)占檢索池大頭的數(shù)種 NVMe 盤型號(hào)進(jìn)行了測(cè)試，最終得出以下結(jié)論：通過(guò)控制讀單元大小（ValueSize = 4K）以及調(diào)整讀寫吞吐比（IOPS Pattern），能夠有效操控讀寫影響，從而實(shí)現(xiàn)對(duì)讀操作長(zhǎng)尾的控制。下圖是對(duì)于Intel P3600 盤，在讀 999per 5ms 的情況下，物理盤最佳“讀寫配比”。

△Intel P3600 讀長(zhǎng)尾可控的讀寫配比

混布環(huán)境下控制單盤 IOPS 是涉及多層次的復(fù)雜問(wèn)題，本文只分享單實(shí)例實(shí)踐。在單個(gè)實(shí)例中，要嚴(yán)格控制讀寫吞吐，就要從默認(rèn)的基于 PageCache 的讀寫模式，轉(zhuǎn)換為使用 Direct I/O（以下簡(jiǎn)稱 DIO）模式，以便獲取硬件級(jí)別的讀寫控制權(quán)。操作系統(tǒng)將數(shù)據(jù)存儲(chǔ)在 PageCache 中，以供后續(xù)的 I/O 操作直接從內(nèi)存中讀取或?qū)懭耄瑥亩@著提高讀寫性能。在切換到 DIO 讀寫模式時(shí)，為了彌補(bǔ)缺少 PageCache 的性能影響，我們引入了 Libaio/IoUring 異步訪問(wèn)機(jī)制，充分發(fā)揮 SSD 的并行處理能力。下圖是隨機(jī)讀 randread 和順序讀 read 混合的評(píng)測(cè)，如果純順序讀，那么 PageCache 吞吐可達(dá) 1+G，且具備性能優(yōu)勢(shì)，為此我們也進(jìn)一步做了頁(yè)緩存的工作，此處先按下不表。

△單機(jī)吞吐評(píng)測(cè)數(shù)據(jù)

03解決方案

3.1集成 Libaio

Linux Libaio 的操作接口和工作原理十分直觀。常規(guī)操作接口分三步：

（1）通過(guò) io_prepare 準(zhǔn)備異步請(qǐng)求。

（2）io_submit 發(fā)送一批請(qǐng)求。

（3） io_getevents 采用 polling 的方式等待所有請(qǐng)求結(jié)束。

工作原理層面，io_submit 將所有請(qǐng)求都提交給了 IO 調(diào)度器，IO 調(diào)度器做完合并、排序類調(diào)度優(yōu)化后，通過(guò)對(duì)應(yīng)的設(shè)備驅(qū)動(dòng)程序提交給具體的設(shè)備。經(jīng)過(guò)一段時(shí)間，讀請(qǐng)求被設(shè)備處理完成，CPU 將收到中斷信號(hào)，設(shè)備驅(qū)動(dòng)程序注冊(cè)的處理函數(shù)將在中斷上下文中被調(diào)用，調(diào)用 end_request 函數(shù)來(lái)結(jié)束這次請(qǐng)求，將 IO 請(qǐng)求的處理結(jié)果填回對(duì)應(yīng)的 io_event 中，喚醒 io_getevents。

△Libaio 接口示例

SsdEngine 集成 Libaio 的方式也非常直觀。

（1）初始化 IO 任務(wù)隊(duì)列大小為 iodepth。

（2）批量設(shè)置 nr 個(gè) IO 任務(wù)的讀參數(shù)，包含文件的句柄、大小、偏移量。

（3）一次性提交 nr 個(gè) IO 任務(wù)的讀請(qǐng)求。

（4）針對(duì)提交的 IO 任務(wù)，我們采用分批次等待的方法，設(shè)置參數(shù) min_wait_nr 和 batch_timeout，其中 min_wait_nr 的值為 min(nr >> 2, nr - completed) ，作用是減少 io_getevents 系統(tǒng)調(diào)用損耗，并實(shí)現(xiàn) IO 任務(wù)與后續(xù) CPU 任務(wù)的并行化。batch_timeout 會(huì)配合整體 timeout，控制整體超長(zhǎng)耗時(shí)。

// 初始化 Libaio 隊(duì)列
io_queue_init(iodepth, context)


// 設(shè)置 nr 個(gè) IO 任務(wù)的讀參數(shù)
for (int i = 0; i < nr; i++) {
    io_prep_pread(iocb_list[i], fd, page[i], page_size[i], page_offset[i]);
}


// 提交 nr 個(gè) IO 任務(wù)
io_submit(context, nr, iocb_list /*start*/);


// 分批次等待，設(shè)置最小等待個(gè)數(shù) min_wait_nr，最大等待個(gè)數(shù) max_nr - completed，以及超時(shí) ts
while (completed < nr) {
    int res = io_getevents(context, min_wait_nr, max_nr - completed/*nr*/, events, &ts);
    // IO 任務(wù)正確性校驗(yàn)
    for (int = 0; i < res; i++) {
        assert(events[i] == page_size[index]);
    }
    completed += res;
    if (total_time_cost > pv_timeout) {
        io_cancel();
    }
}

3.2 初步集成 IoUring

IoUring 執(zhí)行過(guò)程和 Libaio 大同小異，但更高性能。IoUring 通過(guò)實(shí)現(xiàn)兩個(gè) Ring 結(jié)構(gòu)，將其映射到用戶空間并與內(nèi)核共享，以降低元數(shù)據(jù)復(fù)制和系統(tǒng)調(diào)用開(kāi)銷。Submission Ring 包含應(yīng)用程序發(fā)出的 I/O 請(qǐng)求。Completion ring 包含已完成的 I/O 請(qǐng)求的結(jié)果。應(yīng)用程序可以通過(guò)更新 Ring 的頭/尾指針來(lái)插入和檢索 I/O 請(qǐng)求，而不需要使用系統(tǒng)調(diào)用。總結(jié)來(lái)說(shuō)，IoUring 之所以比 Libaio 的性能更優(yōu)，主要有以下三點(diǎn)：

1、系統(tǒng)調(diào)用少：Libaio 在設(shè)計(jì)上每次 IO 操作需要兩個(gè)系統(tǒng)調(diào)用，IoUring 僅在 IO 任務(wù)提交時(shí)有系統(tǒng)調(diào)用，等待 IO 任務(wù)完成則不需要，比 Libaio 少一次系統(tǒng)調(diào)用。

2、數(shù)據(jù)復(fù)制：Libaio 存在元數(shù)據(jù)的復(fù)制，IoUring 通過(guò)用戶空間和內(nèi)核共享，則不需要數(shù)據(jù)復(fù)制。

3、數(shù)據(jù)中斷：Libaio 依賴基于數(shù)據(jù)中斷的完成通知，IoUring 在 polling 模式下不依賴硬件中斷；使用 polling 需要使用內(nèi)核線程 kthread，我們是混部環(huán)境，該方式不采用。

△IoUring 實(shí)現(xiàn)原理

SsdEngine 集成 IoUring 的過(guò)程卻經(jīng)歷了一番探索。我們希望使用和 Libaio 同一語(yǔ)義的接口 io_uring_wait_cqes，IoUring Manual[14] 中解釋了該函數(shù)的核心參數(shù)為，最小等待 IO 任務(wù)數(shù) wait_nr 和等待超時(shí) timeout，但是對(duì) timeout 發(fā)生時(shí)，已經(jīng)完成多少個(gè) IO 任務(wù)，以及對(duì)已完成 IO 任務(wù)的處理方式?jīng)]有做過(guò)多的介紹。我們先嘗試參考 Libaio 同語(yǔ)義接口和參數(shù)，假設(shè)返回的 IO 任務(wù)都在 cqe 隊(duì)列中直到 nullptr，又嘗試了作者在 ?issue?[15] 中的回答，使用宏 io_uring_for_each_cqe 處理已完成的 IO 任務(wù)，但都會(huì)在任務(wù)的結(jié)果校驗(yàn)環(huán)節(jié)發(fā)生錯(cuò)誤。最終通過(guò)對(duì) kernel 5.10 源碼的跟蹤，我們發(fā)現(xiàn)在 io_uring_wait_cqes 函數(shù)實(shí)現(xiàn)中增加了 io_uring_prep_timeout 超時(shí)任務(wù)，需要業(yè)務(wù)單獨(dú)處理。我們還發(fā)現(xiàn)不同版本內(nèi)核，超時(shí)任務(wù)處理并不相同。

io_uring_wait_cqes：填入 wait_nr 等待任務(wù)數(shù)和 ts 超時(shí)參數(shù) 
1.  __io_uring_submit_timeout(ring, wait_nr, ts);
  該函數(shù)的一個(gè)重點(diǎn)是，給 sqe 隊(duì)列添加了一個(gè)超時(shí)任務(wù)：io_uring_prep_timeout，這個(gè)任務(wù)是管理 wait_nr 和 ts 的關(guān)鍵
2.  __io_uring_get_cqe(ring, cqe_ptr, to_submit, wait_nr, sigmask);
  2.1 _io_uring_get_cqe(ring, cqe_ptr, &data);
      這個(gè)函數(shù)是最終調(diào)用的主要處理邏輯
    2.1.1 __io_uring_peek_cqe(ring, &cqe, &nr_available);
      該函數(shù)不阻塞直接獲取完成任務(wù)的隊(duì)列 head，并且表明當(dāng)前隊(duì)列有 nr_available 個(gè)；
      一個(gè)觀察是在返回值沒(méi)有 error， cqe 不為 null 時(shí)， nr_available 才有含義，因?yàn)橥ㄟ^(guò)打點(diǎn)，有 cqe 為 null，但 nr_aviailable 不為 0 的情況；
    2.1.2 __sys_io_uring_enter2(ring->enter_ring_fd, data->submit, data->wait_nr, flags, data->arg,data->sz);
      提交 sqe 隊(duì)列。io_uring_submit 最終調(diào)用的也是該函數(shù)，使用該接口不需要再顯示調(diào)用 io_uring_submit！

面向 io_uring_wait_cqes 實(shí)現(xiàn)的 kernel 版本自適應(yīng)編程。總之，我們遇到的問(wèn)題是在不同內(nèi)核版本中 io_uring_wait_cqes 的內(nèi)部實(shí)現(xiàn)方式有所不同。具體而言，在 kernel 5.10 及其之前的版本，會(huì)在函數(shù)實(shí)現(xiàn)中新增 io_uring_prep_timeout 任務(wù)處理超時(shí)，等待超時(shí)退出時(shí)，用戶需要感知并單獨(dú)處理該超時(shí)任務(wù)。而在 kernel 5.11 及其之后的版本中，函數(shù)實(shí)現(xiàn)則不再添加 io_uring_prep_timeout 任務(wù)。我們線上使用的內(nèi)核版本屬于前者，因此，在集成 IoUring 時(shí)，我們采取添加超時(shí)任務(wù)標(biāo)識(shí)（LIBURING_UDATA_TIMEOUT）判斷的方式來(lái)兼容這兩個(gè)內(nèi)核版本。在超時(shí)退出時(shí)，低版本內(nèi)核生成的超時(shí)任務(wù)會(huì)匹配 LIBURING_UDATA_TIMEOUT 的條件分支，此時(shí)我們會(huì)跳過(guò)對(duì)該任務(wù)的額外處理。而高版本內(nèi)核則不會(huì)觸發(fā)這個(gè)條件分支。

// 初始化 IoUring 隊(duì)列
io_uring_queue_init(iodepth, io_uring, 0 /*flags*/);


// 設(shè)置 nr 個(gè) IO 任務(wù)的讀參數(shù)
for (int i = 0; i < nr; i++) {
    io_uring_prep_readv(sqe, fd, iovecs[i], 1, page_offset[i]);
}


// 一次性提交任務(wù)【debug 之后發(fā)現(xiàn)，使用 io_uring_wait_cqes 接口不需要再顯示的提交任務(wù)】
// - io_uring_submit(io_uring);


// 設(shè)置 ts 超時(shí)參數(shù)， wait_nr 等待任務(wù)數(shù)限制；該函數(shù)的返回，要么等到 wait_nr 個(gè)任務(wù)結(jié)束，要么等待超時(shí)
while (completed < nr) {
    io_uring_wait_cqes(_s_p_local_io_uring, &wait_cqe, wait_nr, &ts, nullptr /*sigmask*/);
    io_uring_for_each_cqe(io_uring, head, cqe) {
        // 判斷是否為超時(shí) IO 任務(wù)
      if (cqe->user_data == LIBURING_UDATA_TIMEOUT) { 
            continue; 
        }
      process(cqe);
        io_uring_cq_advance(io_uring, 1);
        completed++;
    }
}

3.3 自適應(yīng)切換 Libaio/IoUring

IoUring 有 8% 性能優(yōu)勢(shì)。無(wú)論是 FIO 壓測(cè)效果，還是 SsdEngine 集成效果，都能看出在廠內(nèi)機(jī)器環(huán)境下，IoUring 較 Libaio 可提升 8% 的吞吐。

SsdEngine 要盡可能使用 IoUring。但 IoUring 依賴內(nèi)核版本升級(jí)，這也是個(gè)較長(zhǎng)期的過(guò)程。為此我們實(shí)現(xiàn)了自適應(yīng)切換并行調(diào)度器，在 5 系之下內(nèi)核的機(jī)器上，自動(dòng)切換為 Libaio，在 5 系之上內(nèi)核的機(jī)器，自動(dòng)切換為 IoUring，并且優(yōu)先 IoUring。

if (io_uring_queue_init(env_test_iodepth, &ring, 0) == 0) {
  io_uring_queue_exit(&ring);
  return new(std::nothrow) UringPageScheduler;
} else {
    return new(std::nothrow) AioPageScheduler;
}

3.4流水線設(shè)計(jì)

在分層存儲(chǔ)中，存在兩種經(jīng)典的索引方式：HashKV[8,9] 和 LSM[10]。HashKV 一般是全內(nèi)存索引，基于哈希函數(shù)將鍵映射到存儲(chǔ)位置，因此適用于快速查找，但在范圍查詢上表現(xiàn)相對(duì)較差。相比之下，LSM（Log-Structured Merge）索引采用多層次、順序?qū)懭氲姆绞剑m合高吞吐量的寫入操作和范圍查詢，但可能在單個(gè)鍵查找上略顯繁瑣。對(duì)于檢索多讀少寫且點(diǎn)查的場(chǎng)景下，我們采用了 HashKV。

檢索過(guò)程中，一次請(qǐng)求會(huì)有多個(gè) KV 查詢操作，引入異步并行 IO 的簡(jiǎn)易模式是：基于內(nèi)存串行查詢 HashTable 獲取 value 存儲(chǔ)地址，一次性發(fā)起并行訪盤 IO 操作，再等待任務(wù)結(jié)束。

特別說(shuō)明：

（1）對(duì)于跨多頁(yè)的大 Value，在構(gòu)造查詢?nèi)蝿?wù)時(shí)候，會(huì)拆分為多個(gè)按頁(yè)大小子查詢?nèi)蝿?wù)。

（2）不足一頁(yè)按頁(yè)查詢。

（3）一次 PV 中重復(fù)頁(yè)面查詢會(huì)被去重。

簡(jiǎn)易查詢模式抽象如下圖。橫軸代表時(shí)間線，縱軸從上到下依次為應(yīng)用層代碼的調(diào)用順序，在一次批量查詢 IO 任務(wù)個(gè)數(shù) batch_size 大于并行 IO 隊(duì)列的大小（iodepth）時(shí)，會(huì)重復(fù)進(jìn)行調(diào)度流程：schedule- 批量（iodepth 個(gè)）查詢內(nèi)存中的 HashKV 獲取 value 存儲(chǔ)地址， pread - 批量（iodepth 個(gè)）設(shè)置 IO 任務(wù)的參數(shù)，submit- 批量（iodepth 個(gè)）提交 IO 任務(wù)進(jìn)行處理，wait- 根據(jù) min_nr/max_nr 和 timeout 參數(shù)分批次等待 IO 任務(wù)的完成，在等待 IO 任務(wù)的過(guò)程中，并行進(jìn)行這部分的數(shù)據(jù)校驗(yàn)，直到等到所有（iodepth 個(gè)）IO 任務(wù)的完成。

△簡(jiǎn)單查詢模式

我們的優(yōu)化思路是：把當(dāng)前的串行的 schedule-submit-wait 模式，改為流水線，增加 IO 和 CPU 的處理并行度。具體實(shí)現(xiàn)上，分批次提交任務(wù)，等待任務(wù)的過(guò)程中，執(zhí)行 HashTable 查詢。面向用戶接口方面，我們額外引入了兩個(gè)流水線控制參數(shù)，這樣業(yè)務(wù)可選擇均衡小批量帶來(lái)的系統(tǒng)調(diào)用開(kāi)銷和性能提升：

1、batch_submit，一次性提交的 IO 任務(wù)數(shù)。默認(rèn)等于 iodepth，即一次性提交任務(wù)。

2、iodepth_low，默認(rèn)等于 1，流水線跑起來(lái)之后，IO 任務(wù)隊(duì)列中低于 iodepth - iodepth_low 個(gè)任務(wù)的時(shí)候，就開(kāi)始后續(xù)任務(wù)的填充。

引用流水線后，查詢模式抽象見(jiàn)下圖。核心變化集中在： submit - 原本攢夠 iodepth 個(gè)才提交任務(wù)，變成攢夠 batch_submit 個(gè)就提交任務(wù)，這使得 IO 任務(wù)可以提前進(jìn)入 wait 狀態(tài)。wait- 原本等完 iodepth 個(gè)任務(wù)，變成等待 iodepth_low 個(gè)任務(wù)。schedule- 查詢 HashTable 也因此流水線起來(lái)，提升了整體的 IO 任務(wù)和 CPU 任務(wù)的并行空間（灰色區(qū)域）。

△流水線查詢模式

3.5流水線效果評(píng)測(cè)

評(píng)測(cè)環(huán)境

評(píng)測(cè)均采用單線程運(yùn)行的進(jìn)程，運(yùn)行環(huán)境機(jī)型是 CPU INTEL Xeon Platinum 8350C 2.6GHZ ，L1d cache: 48K，L1i cache 32K，L2 cache:1280K，L3 cache:49152K，內(nèi)核是 64 位 5.10 系，編譯器是 GCC 8.2，編譯優(yōu)化選項(xiàng)是 -O2。

評(píng)測(cè)內(nèi)容

為了充分驗(yàn)證流水線效果，我們?cè)u(píng)測(cè)了兩種讀盤場(chǎng)景：場(chǎng)景一、海量 KV，大量讀盤和 HashTable 查詢；場(chǎng)景二、超大 Value，大量讀盤，但極少量 HashTable 查詢。

場(chǎng)景一、海量KV

設(shè)置一次查詢 pv 會(huì)發(fā)起 1024 次 kv，其中 value 大小為 4K，基本對(duì)應(yīng)到 1024 次 HashTable 訪存查詢和 1024 個(gè)訪盤 IO 任務(wù)。設(shè)置 iodepth=512，iodepth_low=1，調(diào)整 batch_submit 為 512、256、128、64、32，觀察不同參數(shù)下，IO 任務(wù)的平響（io_us）、99 分位（io_us_99) ，評(píng)測(cè)數(shù)據(jù)見(jiàn)下。

△海量 KV 查詢耗時(shí)

場(chǎng)景二、超大Value

設(shè)置一次查詢 pv 會(huì)發(fā)起 20 個(gè) kv 查詢，其中 value 大小為 1M，基本對(duì)應(yīng)到 20 次 HashTable 訪存查詢和 245*20=4900 個(gè)訪盤 IO 任務(wù)。設(shè)置 iodepth=512，iodepth_low=1，調(diào)整 batch_submit 為 512、256、128、64、32，觀察不同參數(shù)下，IO 任務(wù)的平響（io_us）、99 分位（io_us_99) ，評(píng)測(cè)數(shù)據(jù)見(jiàn)下。

△超大 Value 查詢耗時(shí)

評(píng)測(cè)結(jié)論

以 Libaio 評(píng)測(cè)數(shù)據(jù)為例。在海量 KV 場(chǎng)景下，batch_submit=512（iodepth） 時(shí)，沒(méi)有開(kāi)啟流水線，IO 任務(wù)平響 4110us，batch_submit=128 時(shí)，是開(kāi)啟流水線的最佳平響參數(shù)，IO 任務(wù)平響 3373us，有 15%+ 的平響優(yōu)化。在超大 Value 場(chǎng)景下，batch_submit=512 （iodepth）時(shí)，沒(méi)有開(kāi)啟流水線，IO 任務(wù)平響 11.5ms， batch_submit=64 時(shí)，是開(kāi)啟流水線的最佳平響參數(shù)，IO 任務(wù)平響 7.7ms，有 30%+ 的平響優(yōu)化。IoUring 和 Libaio 的評(píng)測(cè)效果趨勢(shì)一致。

04應(yīng)用場(chǎng)景

正如背景中所指出的，引入落地頁(yè)信號(hào)對(duì)于用戶體驗(yàn)和總體收入都具有積極的影響。然而，在過(guò)去迫于鳳巢正排服務(wù)的內(nèi)存容量限制，粗排環(huán)節(jié)僅能使用 64 位的簽名 Sign 推導(dǎo)出歸一化 URLID，整條計(jì)算鏈路環(huán)節(jié)過(guò)多，帶來(lái)了一致性方面的問(wèn)題。經(jīng)過(guò)最近一個(gè)季度的努力，通過(guò)在鳳巢正排服務(wù)中引入U(xiǎn)RL明文，得到了準(zhǔn)確的 URLID，我們顯著提高了體驗(yàn)評(píng)估的 QLQ 準(zhǔn)確性，實(shí)驗(yàn)組相較對(duì)照組提升了10.8pp，業(yè)務(wù)收入也得到了明顯增長(zhǎng)。未來(lái)，我們還將把落地頁(yè)信號(hào)引入到更多的粗排 Q 中，進(jìn)一步提升總體收入。

05相關(guān)工作

廣告基礎(chǔ)檢索系統(tǒng)的模塊，可被視為一種業(yè)務(wù)特化的內(nèi)存數(shù)據(jù)庫(kù)。我們觀察到，在內(nèi)存數(shù)據(jù)庫(kù)領(lǐng)域中出現(xiàn)了類似的發(fā)展趨勢(shì)：在上世紀(jì) 90 年代，隨著內(nèi)存成本的降低和容量的增加，內(nèi)存數(shù)據(jù)庫(kù)得到了發(fā)展。然而，隨著業(yè)務(wù)存儲(chǔ)量的不斷增加，內(nèi)存的限制逐漸顯現(xiàn)。進(jìn)入 2010 年代，LargerThanMem 分支應(yīng)運(yùn)而生[11,12,13]，從歷屆論文看，該分支還比較學(xué)術(shù)，主要研究?jī)蓚€(gè)關(guān)鍵問(wèn)題：

1、如何引入分層存儲(chǔ)，但又避免引入過(guò)多的 I/O 開(kāi)銷，即研究熱/冷執(zhí)行路徑（Hot/Cold Execution Path）。

2、在分層存儲(chǔ)后，如何設(shè)計(jì)自適應(yīng)的冷熱數(shù)據(jù)淘汰和檢索策略。

問(wèn)題 1 是系統(tǒng)設(shè)計(jì)的技術(shù)問(wèn)題，而當(dāng)前的 SsdEngine 設(shè)計(jì)主要關(guān)注了這一問(wèn)題，我們?cè)诰彺妗⒄{(diào)度和訪盤等方面都有明確的規(guī)劃和實(shí)現(xiàn)。在廣告檢索業(yè)務(wù)中，冷熱數(shù)據(jù)的分布特性明顯存在。當(dāng)前，我們只針對(duì)廣告庫(kù)的場(chǎng)景，通過(guò)商業(yè)廣告同步系統(tǒng)的旁路實(shí)現(xiàn)，實(shí)現(xiàn)了業(yè)務(wù)分層。未來(lái)，在詞表場(chǎng)景中，我們還將探索問(wèn)題 2 的解決方案。

長(zhǎng)尾控制在某些特定生產(chǎn)環(huán)境中才會(huì)成為一個(gè)突出問(wèn)題，我們可以將其視為 LargerThanMem 在廣告檢索中所特有的挑戰(zhàn)。如上所述，在混合部署的環(huán)境中，對(duì)單盤的 IOPS 進(jìn)行控制是一個(gè)涉及多個(gè)層次的復(fù)雜任務(wù)。廣告基礎(chǔ)檢索服務(wù)的特點(diǎn)是寫少讀多且具備穩(wěn)定量化的局部性，單實(shí)例頻控 + 超時(shí)控制，已足夠控制讀長(zhǎng)尾。但隨著 SsdEngine 進(jìn)一步推廣應(yīng)用，包括單盤的 Adhoc 組網(wǎng)通信以及集群按照 IOPS 分配，也需要應(yīng)用起來(lái)。

審核編輯：湯梓紅