安仲奇 張?jiān)茍?2 邢 晶 霍志剛,2

1(計(jì)算機(jī)體系結(jié)構(gòu)國家重點(diǎn)實(shí)驗(yàn)室(中國科學(xué)院計(jì)算技術(shù)研究所) 北京 100190) 2(中國科學(xué)院大學(xué)計(jì)算機(jī)與控制工程學(xué)院 北京 100049)(anzhongqi@ncic.ac.cn)

現(xiàn)如今，互聯(lián)網(wǎng)產(chǎn)生和累積的數(shù)據(jù)越來越多.根據(jù)思科系統(tǒng)公司的報(bào)告，2016年的全球互聯(lián)網(wǎng)流量已經(jīng)突破了1 ZB，平均每個(gè)月新增96 EB流量.其中忙碌時(shí)段的互聯(lián)網(wǎng)流量相比以往增長(zhǎng)了51%，普通時(shí)段的互聯(lián)網(wǎng)流量相比以往增長(zhǎng)了32%.此外，報(bào)告預(yù)測(cè)2021年的全球互聯(lián)網(wǎng)流量將達(dá)到3.3 ZB，此間的復(fù)合年增長(zhǎng)率將達(dá)到24%［1].互聯(lián)網(wǎng)數(shù)據(jù)規(guī)模和高峰流量的爆發(fā)式增長(zhǎng)，給數(shù)據(jù)管理系統(tǒng)帶來了非常大的考驗(yàn).

隨著數(shù)據(jù)時(shí)代的到來，企業(yè)對(duì)大數(shù)據(jù)處理的性能需求日漸提高.傳統(tǒng)關(guān)系型數(shù)據(jù)庫為了保證數(shù)據(jù)的原子性、一致性、隔離性、持久性，導(dǎo)致數(shù)據(jù)操作開銷大、效率低，且隨著數(shù)據(jù)規(guī)模的快速增長(zhǎng)，其在可縮放性、可擴(kuò)展性方面幾乎已經(jīng)達(dá)到極限.鍵值(key-value， KV)存儲(chǔ)系統(tǒng)以key-value對(duì)的形式對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)和索引，摒棄了對(duì)新型業(yè)務(wù)需求而言開銷過高的冗余數(shù)據(jù)管理機(jī)制，通過“鍵”即可快速查詢到對(duì)應(yīng)的“值”，具備快速小消息交換、高并發(fā)、高吞吐、易伸縮易擴(kuò)展等的優(yōu)勢(shì)，適用于不涉及復(fù)雜關(guān)系的數(shù)據(jù)應(yīng)用場(chǎng)景.

key-value存儲(chǔ)系統(tǒng)往往承擔(dān)著緩沖或存儲(chǔ)互聯(lián)網(wǎng)熱點(diǎn)數(shù)據(jù)、應(yīng)對(duì)高峰流量、保障用戶體驗(yàn)的重任，其始終對(duì)性能有著很高的要求.隨著底層新型網(wǎng)絡(luò)與存儲(chǔ)硬件(如100 Gbps以太網(wǎng)、PCIe固態(tài)存儲(chǔ))性能的迅速提高，操作系統(tǒng)內(nèi)核逐漸成為限制key-value系統(tǒng)吞吐能力的瓶頸.例如內(nèi)存數(shù)據(jù)存儲(chǔ)系統(tǒng)Redis在完成讀操作(GET)和寫操作(SET)時(shí)，內(nèi)核網(wǎng)絡(luò)棧的開銷可分別占整體延遲的62%和84%［2].存儲(chǔ)方面，雖然對(duì)傳統(tǒng)機(jī)械磁盤而言，數(shù)據(jù)訪問過程中的軟件存儲(chǔ)棧開銷相比硬件處理開銷可以忽略不計(jì)，但對(duì)新型高性能存儲(chǔ)(如PCM，3D XPoint，RRAM等)，操作系統(tǒng)開銷在數(shù)據(jù)訪問中的占比可高達(dá)90%［3].

用戶級(jí)I/O技術(shù)通過旁路操作系統(tǒng)內(nèi)核并針對(duì)應(yīng)用需求定制軟件棧以達(dá)到避免傳統(tǒng)系統(tǒng)軟件不足或開銷的目的.由英特爾公司開源的用戶級(jí)網(wǎng)絡(luò)框架DPDK(data plane development kit)［4]和用戶級(jí)存儲(chǔ)框架SPDK(storage performance development kit)［5]是用戶級(jí)技術(shù)的代表，其提供了用戶態(tài)的設(shè)備驅(qū)動(dòng)，并采用了輪詢、大頁、核綁定、免鎖隊(duì)列等不同于傳統(tǒng)內(nèi)核設(shè)計(jì)的機(jī)制，降低了系統(tǒng)軟件層面的開銷，取得了較為顯著的性能提升.例如相比Linux內(nèi)核，SPDK的總體延遲可改善10倍，單個(gè)CPU核可提供超過350萬次IOPS(input/output operations per second)吞吐量，并使8塊NVMe(non-volatile memory express)固態(tài)硬盤SSD(solid state drive)達(dá)到飽和［3].不過，此類用戶級(jí)技術(shù)側(cè)重暴露硬件底層機(jī)制與接口，其接口不夠友好，往往要求應(yīng)用重構(gòu)代碼并實(shí)施復(fù)雜的優(yōu)化以收獲性能.再者，現(xiàn)有用戶級(jí)軟件棧大都只提供或網(wǎng)絡(luò)或存儲(chǔ)單方面的解決，而上層真實(shí)應(yīng)用往往對(duì)需要二者協(xié)同優(yōu)化以取得理想的性能.此外，從底層硬件角度，以PCIe SSD為代表的高性能存儲(chǔ)設(shè)備的訪問延遲和帶寬已經(jīng)與主流高速以太網(wǎng)絡(luò)達(dá)到同一個(gè)數(shù)量級(jí)，網(wǎng)絡(luò)和存儲(chǔ)的性能逐漸匹配，為網(wǎng)絡(luò)棧與存儲(chǔ)棧的統(tǒng)一融合提供了契機(jī).

本文聚焦key-value存儲(chǔ)系統(tǒng)的數(shù)據(jù)通路，面向高速以太網(wǎng)與NVMe SSD，于用戶態(tài)整合網(wǎng)絡(luò)棧與存儲(chǔ)棧，協(xié)同設(shè)計(jì)以優(yōu)化系統(tǒng)的吞吐性能與延遲穩(wěn)定性.控制平面采用核專門化(core specialization)的方法，由單一處理器核“專門”統(tǒng)一管理網(wǎng)絡(luò)與存儲(chǔ)，最小化系統(tǒng)軟件開銷.數(shù)據(jù)平面通過統(tǒng)一內(nèi)存池并于設(shè)備之間直接發(fā)起直接內(nèi)存訪問(direct memory access， DMA)通信，避免冗余的數(shù)據(jù)拷貝.測(cè)試結(jié)果表明，與Twitter公司開源的Fatcache［6]相比，每秒查詢(queries per second， QPS)吞吐量提高了近1倍，p95延遲降低了約50%.

本文的主要貢獻(xiàn)有3個(gè)方面：

1) 面向key-value存儲(chǔ)系統(tǒng)提出了一種全用戶態(tài)的網(wǎng)絡(luò)與存儲(chǔ)協(xié)同優(yōu)化的方法，控制路徑由專核統(tǒng)一管理網(wǎng)卡與固態(tài)盤設(shè)備，減少軟件層面的干涉，數(shù)據(jù)通路采取統(tǒng)一的DMA中轉(zhuǎn)內(nèi)存池，避免額外數(shù)據(jù)拷貝.

2) 針對(duì)大消息數(shù)據(jù)訪問請(qǐng)求，提出了聯(lián)合網(wǎng)絡(luò)與存儲(chǔ)的優(yōu)化方法，將數(shù)據(jù)分片并交疊執(zhí)行網(wǎng)卡與固態(tài)盤的DMA操作，進(jìn)一步掩藏延遲.

3) 實(shí)現(xiàn)了全用戶態(tài)key-value存儲(chǔ)系統(tǒng)UKV，其支持內(nèi)存-固態(tài)盤2層存儲(chǔ)以及廣泛使用的Memcache［7]接口.測(cè)試結(jié)果表明其網(wǎng)絡(luò)I/O性能優(yōu)于Twitter Fatcache.

1 系統(tǒng)介紹

本文的基于用戶級(jí)融合I/O的key-value存儲(chǔ)系統(tǒng)UKV面向高速以太網(wǎng)與NVMe SSD存儲(chǔ)，采用直通式的I/O架構(gòu)，支持內(nèi)存-固態(tài)盤2級(jí)存儲(chǔ)層級(jí)以及Memcache文本接口.首先，UKV基于DPDK與SPDK提供的用戶級(jí)設(shè)備驅(qū)動(dòng)，分別搭建輕量級(jí)的網(wǎng)絡(luò)通路和存儲(chǔ)通路軟件棧，降低軟件開銷并完全旁路操作系統(tǒng)內(nèi)核，消除了內(nèi)核的性能限制.然后，在全用戶態(tài)硬件資源直接訪問的基礎(chǔ)上，整合網(wǎng)絡(luò)棧與存儲(chǔ)棧，由單一處理器核心緊密統(tǒng)一二者的控制平面和數(shù)據(jù)平面，進(jìn)一步降低了“跨?！边M(jìn)出的軟件開銷.最后針對(duì)由網(wǎng)絡(luò)到存儲(chǔ)的完整數(shù)據(jù)通路，直接調(diào)度設(shè)備DMA引擎，通過數(shù)據(jù)分片流水進(jìn)一步掩藏開銷、改善性能.

1.1 分層存儲(chǔ)

主流key-value存儲(chǔ)系統(tǒng)為了提供足夠的吞吐能力與延遲表現(xiàn)，其索引和數(shù)據(jù)都存儲(chǔ)于內(nèi)存.面對(duì)爆發(fā)式增長(zhǎng)的數(shù)據(jù)規(guī)模與熱點(diǎn)時(shí)段的高峰流量，內(nèi)存容量漸成瓶頸.由于單機(jī)可安裝的內(nèi)存容量有限，且動(dòng)態(tài)隨機(jī)訪問內(nèi)存(dynamic random access memory, DRAM)功耗高、單位容量?jī)r(jià)格高，這使得此類key-value系統(tǒng)的內(nèi)存空間遭遇了可擴(kuò)展性的挑戰(zhàn).而與內(nèi)存相比，SSD在容量、價(jià)格、功耗等方面有著明顯優(yōu)勢(shì)，并且考慮到下一代新型非易失存儲(chǔ)(non-volatile memory, NVM)與DRAM之間的性能差距將進(jìn)一步縮小，其完全可以作為內(nèi)存的擴(kuò)展，是搭建大規(guī)模、低成本、高性能、可擴(kuò)展存儲(chǔ)系統(tǒng)的理想選擇.

UKV借鑒了Fatcache的2級(jí)存儲(chǔ)方法，并進(jìn)行了改造與擴(kuò)展.Fatcache將塊設(shè)備作為內(nèi)存數(shù)據(jù)區(qū)域的擴(kuò)展，在接收到數(shù)據(jù)存儲(chǔ)請(qǐng)求后，數(shù)據(jù)優(yōu)先寫入內(nèi)存；當(dāng)內(nèi)存數(shù)據(jù)區(qū)存滿時(shí)，將內(nèi)存數(shù)據(jù)寫入外存，以騰出內(nèi)存數(shù)據(jù)區(qū)用于接收新的數(shù)據(jù)寫入.Fatcache雖然宣稱支持SSD，但其對(duì)SSD的支持較為簡(jiǎn)單，主要的優(yōu)化手段限于批量聚合對(duì)SSD的寫入、將隨機(jī)寫轉(zhuǎn)換為順序?qū)?，從而降低寫放大、垃圾回收等的影?由于仍然采用內(nèi)核接口，無法實(shí)現(xiàn)對(duì)設(shè)備的直接控制以及細(xì)粒度的I/O調(diào)度.此外，F(xiàn)atcache使用了slab機(jī)制以減少空間浪費(fèi)，且索引計(jì)算開銷小、利于快速定位.但是，F(xiàn)atcache的數(shù)據(jù)置換采用了較為簡(jiǎn)單的先進(jìn)先出(first in first out， FIFO)策略，雖然利于數(shù)據(jù)的順序讀寫，但數(shù)據(jù)命中率、帶寬效率方面不夠理想.本文的置換策略改用最近最少使用(least recently used， LRU)，并結(jié)合slab機(jī)制，同時(shí)保證外存“冷數(shù)據(jù)”順序?qū)懭胄阅芘c內(nèi)存“熱數(shù)據(jù)”隨機(jī)訪問命中率，以獲得理想的響應(yīng)延遲表現(xiàn).

現(xiàn)代SSD設(shè)備不僅支持傳統(tǒng)的512 B塊單位大小，亦支持4 096 B的塊大小以降低元數(shù)據(jù)管理開銷，而key-value存儲(chǔ)系統(tǒng)中通常存在大量的小消息負(fù)載，對(duì)此類消息，一個(gè)塊可以包含多個(gè)key-value對(duì).如若同一塊的不同key-value對(duì)被訪問，將導(dǎo)致對(duì)該塊的重復(fù)訪問.對(duì)此，UKV于用戶態(tài)對(duì)網(wǎng)絡(luò)棧與I/O棧進(jìn)行了整合，以避免冗余的設(shè)備訪問，提高系統(tǒng)的響應(yīng)性能.

1.2 用戶級(jí)I/O

用戶級(jí)I/O，旨在旁路操作系統(tǒng)內(nèi)核，面向應(yīng)用定制、裁剪系統(tǒng)軟件棧，避免通用內(nèi)核限制并最小化軟件開銷.

1.2.1 用戶級(jí)網(wǎng)絡(luò)通信

UKV使用用戶級(jí)網(wǎng)絡(luò)框架DPDK和用戶級(jí)TCP/IP協(xié)議棧F-Stack［8]實(shí)現(xiàn)用戶級(jí)網(wǎng)絡(luò)通信，提高系統(tǒng)的網(wǎng)絡(luò)數(shù)據(jù)處理性能和吞吐量.

DPDK只是一個(gè)用戶級(jí)網(wǎng)絡(luò)的軟件庫和驅(qū)動(dòng)程序，并不包含網(wǎng)絡(luò)協(xié)議棧.UKV使用了騰訊公司于2017年5月開源的F-Stack.F-Stack是基于DPDK的高性能開源網(wǎng)絡(luò)框架，其移植了FreeBSD 11.01的TCP/IP協(xié)議棧，在提供了完整的網(wǎng)絡(luò)協(xié)議棧功能的同時(shí)裁剪了大量的冗余功能，極大地提升了網(wǎng)絡(luò)吞吐.F-Stack作為粘合劑，緊密集成了DPDK,FreeBSD協(xié)議棧和可移植操作系統(tǒng)接口(portable operating system interface, POSIX)，易于部署并提供用戶級(jí)網(wǎng)絡(luò)訪問.

1.2.2 用戶級(jí)存儲(chǔ)

UKV使用用戶級(jí)存儲(chǔ)框架SPDK實(shí)現(xiàn)對(duì)SSD的直接管理，并結(jié)合key-value存儲(chǔ)系統(tǒng)需求以及F-stack實(shí)現(xiàn)了輕量級(jí)的I/O層，降低了存儲(chǔ)設(shè)備訪問過程的軟件開銷.

1.3 融合I/O

本文的融合I/O軟件棧遵循經(jīng)典高性能技術(shù)(如遠(yuǎn)程內(nèi)存直接訪問)控制平面與數(shù)據(jù)平面分離的原則，又于控制路徑與數(shù)據(jù)路徑分別統(tǒng)一管理網(wǎng)絡(luò)與存儲(chǔ)的數(shù)據(jù)流動(dòng)，以保證高效的數(shù)據(jù)通路.

1.3.1 統(tǒng)一控制平面

本文通過核專用化的方式，將同一個(gè)線程綁定在固定CPU核心上，并采用“執(zhí)行至結(jié)束”(run-to-completion)模型，于用戶態(tài)中通過單一的上下文直接訪問網(wǎng)卡設(shè)備和NVMe設(shè)備的底層硬件隊(duì)列，實(shí)現(xiàn)網(wǎng)絡(luò)與存儲(chǔ)控制平面的統(tǒng)一.

在傳統(tǒng)內(nèi)核機(jī)制中，網(wǎng)卡設(shè)備和存儲(chǔ)設(shè)備每次完成收發(fā)讀寫請(qǐng)求后，均通過中斷機(jī)制來通知CPU.整個(gè)中斷的過程包括保存信息、中斷處理、恢復(fù)信息等，至少需要300個(gè)CPU時(shí)鐘周期.中斷處理、系統(tǒng)調(diào)用以及多線程搶占都伴隨著上下文切換.上下文切換的開銷又包括：翻轉(zhuǎn)特權(quán)級(jí)、保存和加載寄存器數(shù)據(jù)、執(zhí)行系統(tǒng)調(diào)度器代碼、重新加載TLB(translation lookaside buffer)實(shí)例、刷新CPU流水線等.另外，上下文切換以及進(jìn)程/線程間的搶占式調(diào)度會(huì)造成CPU的緩存失效.多核環(huán)境下，若設(shè)備中斷接收線程與應(yīng)用線程位于不同的核心、不同的處理器，將通過處理器間中斷進(jìn)行處理的中轉(zhuǎn)，跨核跨域的數(shù)據(jù)傳輸進(jìn)一步增加了處理開銷.此外，操作系統(tǒng)內(nèi)核不僅引入了厚厚的存儲(chǔ)棧處理開銷，還可能導(dǎo)致數(shù)據(jù)在用戶態(tài)與內(nèi)核態(tài)之間的額外拷貝，影響系統(tǒng)的吞吐.

如圖1與圖2所示，在傳統(tǒng)操作系統(tǒng)機(jī)制下，key-value存儲(chǔ)系統(tǒng)處理數(shù)據(jù)存取操作的過程中將涉及多次進(jìn)出內(nèi)核態(tài)的系統(tǒng)調(diào)用、網(wǎng)卡設(shè)備和存儲(chǔ)設(shè)備的多次中斷等.而在UKV的統(tǒng)一控制平面下，通過采用輪詢機(jī)制徹底避免了中斷處理的開銷，同時(shí)由于設(shè)備直接驅(qū)動(dòng)，進(jìn)一步避免了上下文切換.單一上下文中的定制化輕量級(jí)軟件棧也消除了數(shù)據(jù)拷貝和冗余軟件棧處理開銷.

Fig.2 Comparsion of the scheduling state of the data path of traditional mechanism and unified control plane圖2 傳統(tǒng)機(jī)制和統(tǒng)一控制平面下數(shù)據(jù)通路的調(diào)度狀態(tài)

UKV使用同一個(gè)線程，綁定在固定CPU處理器核心上，采用run-to-completion模型，同時(shí)管理網(wǎng)卡設(shè)備和NVMe設(shè)備.靜態(tài)線程綁核的方式避免了線程在核之間的遷移開銷，提高了緩存與內(nèi)存訪問的效率.如圖3所示，run-to-completion模型指由單一線程負(fù)責(zé)于單一用戶態(tài)上下文中處理key-value請(qǐng)求，具體環(huán)節(jié)包括：

① 網(wǎng)卡接收數(shù)據(jù)包.網(wǎng)卡在接收到網(wǎng)絡(luò)數(shù)據(jù)包后通過DMA直接拷貝到UKV的數(shù)據(jù)區(qū)域，該過程完全于用戶空間執(zhí)行，無額外數(shù)據(jù)拷貝與管理模式切換；

② key-value系統(tǒng)處理.UKV解析接收到網(wǎng)絡(luò)數(shù)據(jù)包和I/O請(qǐng)求，并完成相關(guān)的key-value數(shù)據(jù)管理操作；

③ 提交SSD讀寫請(qǐng)求.UKV向SSD發(fā)起讀寫請(qǐng)求，該過程同樣完全于用戶空間執(zhí)行，額外開銷極低；

④ 完成SSD讀寫操作.UKV于用戶空間通過SSD驅(qū)動(dòng)輪詢?cè)O(shè)備完成隊(duì)列，等待讀寫操作完成；

⑤ key-value系統(tǒng)處理.UKV生成回復(fù)，打包數(shù)據(jù)或響應(yīng)并完成相關(guān)的key-value數(shù)據(jù)管理操作；

⑥ 網(wǎng)卡發(fā)送數(shù)據(jù)包.UKV于用戶空間將生成的回復(fù)通過網(wǎng)卡直接傳輸.

上述過程不涉及特權(quán)模式切換、中斷處理以及線程調(diào)度，具有很好的數(shù)據(jù)緩存局部性，最大限度地避免了數(shù)據(jù)的額外搬移.如若采用傳統(tǒng)的多線程資源共享、輪轉(zhuǎn)響應(yīng)的機(jī)制，在訪問共享數(shù)據(jù)時(shí)會(huì)面臨嚴(yán)重的鎖競(jìng)爭(zhēng)，線程搶占、調(diào)度會(huì)導(dǎo)致緩存之間頻繁的數(shù)據(jù)更新與通信，拉低了效率.

Fig.3 The run-to-completion model圖3 run-to-completion模型

此外，根據(jù)文獻(xiàn)［9]的測(cè)試結(jié)果，就目前主流CPU處理器、高速以太網(wǎng)卡、NVMe SSD的性能而言，單一處理器核心可充分發(fā)揮出網(wǎng)卡和SSD的性能，故本文暫未考慮多核控制平面的設(shè)計(jì).

1.3.2 統(tǒng)一數(shù)據(jù)平面

簡(jiǎn)單地說，統(tǒng)一數(shù)據(jù)平面是指完全于用戶空間直接驅(qū)動(dòng)設(shè)備驅(qū)動(dòng)，網(wǎng)卡與SSD的設(shè)備隊(duì)列統(tǒng)一調(diào)度并緊密耦合，通過設(shè)備DMA引擎直接于統(tǒng)一的數(shù)據(jù)中轉(zhuǎn)內(nèi)存池中收發(fā)數(shù)據(jù).

如圖4所示，在傳統(tǒng)機(jī)制下，key-value存儲(chǔ)系統(tǒng)在執(zhí)行接收操作即SET操作時(shí)，數(shù)據(jù)首先由操作系統(tǒng)內(nèi)核網(wǎng)絡(luò)緩沖區(qū)拷貝到用戶態(tài)key-value系統(tǒng)的地址空間，再由key-value系統(tǒng)用戶空間拷貝到操作系統(tǒng)內(nèi)核存儲(chǔ)緩沖區(qū)，經(jīng)過內(nèi)核存儲(chǔ)棧層層處理后最終寫入存儲(chǔ)設(shè)備.發(fā)送操作即GET操作，數(shù)據(jù)首先由存儲(chǔ)設(shè)備讀取至內(nèi)核緩沖區(qū)，再拷貝至用戶態(tài)key-value地址空間，再次拷貝入內(nèi)核網(wǎng)絡(luò)棧發(fā)送.冗長(zhǎng)的數(shù)據(jù)拷貝路徑限制了系統(tǒng)吞吐.雖然傳統(tǒng)操作系統(tǒng)內(nèi)核提供了一些機(jī)制或功能可用于減少部分拷貝環(huán)節(jié)，但大都存在一些弊端.以Linux為例，mmap的方式仍然需要額外的CPU數(shù)據(jù)拷貝，且引入了開銷較大的頁表映射操作；sendfile機(jī)制僅支持內(nèi)核空間數(shù)據(jù)的直接網(wǎng)絡(luò)傳輸，存在污染內(nèi)核頁緩沖的隱患，且考慮網(wǎng)絡(luò)傳輸?shù)漠惒叫?，通常僅支持發(fā)送端的傳輸.

Fig.4 Comparison of the data path of I/O operations of traditional mechanism and unified data plane圖4 傳統(tǒng)機(jī)制和統(tǒng)一數(shù)據(jù)平面下I/O操作的數(shù)據(jù)通路

而在統(tǒng)一數(shù)據(jù)平面的設(shè)計(jì)下，UKV系統(tǒng)完全于用戶空間直接傳輸數(shù)據(jù)，接收數(shù)據(jù)時(shí)網(wǎng)卡直接寫入、讀取數(shù)據(jù)時(shí)直接由SSD傳輸至應(yīng)用緩沖，整個(gè)數(shù)據(jù)路徑僅涉及單次系統(tǒng)主存中轉(zhuǎn).且地址空間單一、上下文單一，無需額外的頁表處理，不存在污染公共存儲(chǔ)資源的副作用.

由硬件設(shè)備讀取/發(fā)送的數(shù)據(jù)只存儲(chǔ)在用戶空間，數(shù)據(jù)無需再于內(nèi)核空間與用戶空間之間頻繁來回拷貝，數(shù)據(jù)傳輸過程中也不再涉及操作系統(tǒng)內(nèi)核的干涉.結(jié)合圖4，更為詳細(xì)地，網(wǎng)卡直接由UKV系統(tǒng)于用戶空間驅(qū)動(dòng)，網(wǎng)卡在接收到網(wǎng)絡(luò)數(shù)據(jù)包后，通過DMA直接傳輸至UKV用戶級(jí)的數(shù)據(jù)中轉(zhuǎn)內(nèi)存池中.UKV通過用戶態(tài)TCP/IP協(xié)議棧獲知消息內(nèi)容，并按照Memcache協(xié)議進(jìn)行解析，得到具體的key-value數(shù)據(jù)與相應(yīng)的I/O請(qǐng)求.如若是SET請(qǐng)求，則將同時(shí)解析出的key-value對(duì)數(shù)據(jù)寫入slab存儲(chǔ).如若是GET請(qǐng)求，則根據(jù)key索引確認(rèn)value的存儲(chǔ)位置.如若發(fā)生數(shù)據(jù)置換、讀取外存等I/O操作，則通過純用戶態(tài)的NVMe驅(qū)動(dòng)向SSD設(shè)備直接提交讀寫請(qǐng)求.若I/O操作為寫，則通過用戶級(jí)驅(qū)動(dòng)提交命令，由設(shè)備DMA從中轉(zhuǎn)內(nèi)存池讀取數(shù)據(jù)并寫入存儲(chǔ)設(shè)備；若I/O操作為讀，則由設(shè)備DMA直接將數(shù)據(jù)寫入中轉(zhuǎn)內(nèi)存池.

通過用戶態(tài)NVMe驅(qū)動(dòng)提交讀寫操作后，UKV系統(tǒng)輪詢?cè)O(shè)備的完成隊(duì)列.操作完成后，將value數(shù)據(jù)落盤狀態(tài)或讀取到的value數(shù)據(jù)以Memcache協(xié)議格式封裝并存放于內(nèi)存中轉(zhuǎn)池.之后于用戶態(tài)由TCP/IP協(xié)議棧封包后直接交由網(wǎng)卡傳輸.

1.4 數(shù)據(jù)通路優(yōu)化

UKV系統(tǒng)的數(shù)據(jù)傳輸路徑，包括網(wǎng)卡接收數(shù)據(jù)包、key-value協(xié)議解析、提交SSD讀寫請(qǐng)求、完成SSD讀寫操作、key-value格式化、TCP協(xié)議棧封包、網(wǎng)卡發(fā)送數(shù)據(jù)包，整體延遲即各個(gè)環(huán)節(jié)延遲的總和.對(duì)SET操作而言，得益于slab機(jī)制，SET操作于內(nèi)存中處理后即返回響應(yīng)，性能路徑不涉及SSD訪問，故而瓶頸集中在網(wǎng)絡(luò)通信開銷方面，缺乏優(yōu)化空間.對(duì)GET操作來說，涉及SSD讀取時(shí)，SSD延遲最高且占比顯著.如圖5所示，經(jīng)測(cè)試，GET操作中的存儲(chǔ)訪問延遲整體占比可高達(dá)70%以上.

Fig.5 The latency analysis of a GET operation圖5 GET操作的延遲占比分析

參考上述性能特點(diǎn)，GET操作傳輸大消息時(shí)，SSD讀操作與網(wǎng)絡(luò)通信存在并行流水優(yōu)化的空間.UKV系統(tǒng)將大消息數(shù)據(jù)分片處理，從而實(shí)現(xiàn)SSD讀操作與網(wǎng)絡(luò)傳輸交疊執(zhí)行，如此并行流水來掩藏通信開銷，大幅降低了涉及SSD讀取的GET操作的整體延遲.如圖6所示，在統(tǒng)一流水線中，每個(gè)數(shù)據(jù)分片由SSD讀取以后，經(jīng)由TCP/IP協(xié)議棧封包后交由網(wǎng)卡異步傳輸；異步網(wǎng)絡(luò)傳輸發(fā)起后立即返回，并隨之異步傳輸相應(yīng)的標(biāo)記位；再之后同步執(zhí)行向SSD的下一數(shù)據(jù)分片讀取.客戶端逐片收到數(shù)據(jù)，該過程持續(xù)到客戶端接收到最后一片數(shù)據(jù)分片.可見，網(wǎng)絡(luò)傳輸中的協(xié)議棧處理仍然由CPU完成，交疊執(zhí)行實(shí)際起始于網(wǎng)卡DMA傳輸.由于SSD訪問延遲顯著大于其他處理延遲，CPU處理協(xié)議棧的環(huán)節(jié)并不會(huì)拖慢整體流水效果.

Fig.6 The unified pipelining of networking and SSD I/O圖6 統(tǒng)一并行流水的優(yōu)化方法

得益于全用戶態(tài)、統(tǒng)一內(nèi)存中轉(zhuǎn)池的設(shè)計(jì)，UKV系統(tǒng)能夠?qū)崿F(xiàn)細(xì)粒度的流水線設(shè)計(jì)與調(diào)優(yōu)，且性能干擾因素較少、流水線表現(xiàn)更加穩(wěn)定.

2 系統(tǒng)實(shí)現(xiàn)

本節(jié)詳細(xì)介紹UKV系統(tǒng)的實(shí)現(xiàn).

2.1 系統(tǒng)架構(gòu)

UKV的系統(tǒng)架構(gòu)如圖7所示，主要包括3部分：網(wǎng)絡(luò)模塊、存儲(chǔ)模塊與數(shù)據(jù)模塊.網(wǎng)絡(luò)模塊負(fù)責(zé)用戶態(tài)直接驅(qū)動(dòng)網(wǎng)卡、發(fā)送或接收網(wǎng)絡(luò)數(shù)據(jù)包、網(wǎng)絡(luò)協(xié)議棧封裝或解析等；存儲(chǔ)模塊負(fù)責(zé)用戶態(tài)直接驅(qū)動(dòng)SSD、請(qǐng)求與完成隊(duì)列管理等；數(shù)據(jù)模塊則主要負(fù)責(zé)基本的key-value邏輯與存儲(chǔ)(例如Memcache接口、slab存儲(chǔ)等)以及統(tǒng)一的控制平面、數(shù)據(jù)流水線、聯(lián)合I/O調(diào)度等.

在新時(shí)代全面深化改革中推進(jìn)全面依法治國。黨的十八大以來，以習(xí)近平同志為核心的黨中央以高瞻遠(yuǎn)矚的戰(zhàn)略眼光、一往無前的宏大氣魄、雷厲風(fēng)行的堅(jiān)毅行動(dòng)、激濁揚(yáng)清的責(zé)任擔(dān)當(dāng)，揭開了新時(shí)代全面深化改革的大幕，確立了完善和發(fā)展中國特色社會(huì)主義制度、推進(jìn)國家治理體系和治理能力現(xiàn)代化的全面深化改革總目標(biāo)。與之相適應(yīng)，從關(guān)系黨和國家前途命運(yùn)、長(zhǎng)治久安的戰(zhàn)略全局高度來定位法治、布局法治、推進(jìn)法治、厲行法治，確立了建設(shè)中國特色社會(huì)主義法治體系、建設(shè)社會(huì)主義法治國家的全面依法治國總目標(biāo)。

Fig.7 The architecture of the UKV system圖7 UKV的系統(tǒng)架構(gòu)

UKV系統(tǒng)的服務(wù)端與客戶端通過標(biāo)準(zhǔn)TCP/IP協(xié)議進(jìn)行通信.UKV服務(wù)端內(nèi)部是完全用戶態(tài)的網(wǎng)絡(luò)通信且支持內(nèi)存-外存2層存儲(chǔ)，對(duì)NVMe SSD的驅(qū)動(dòng)與管理同樣完全于用戶態(tài)實(shí)現(xiàn).UKV控制平面與數(shù)據(jù)平面分離且各自緊密整合網(wǎng)絡(luò)與I/O，有助于屏蔽系統(tǒng)噪聲、精簡(jiǎn)數(shù)據(jù)通路.

2.2 核心模塊

網(wǎng)絡(luò)模塊和存儲(chǔ)模塊分別負(fù)責(zé)完成用戶級(jí)網(wǎng)絡(luò)通信和用戶級(jí)SSD訪問，由統(tǒng)一控制平面和統(tǒng)一數(shù)據(jù)平面聯(lián)合到一起.

數(shù)據(jù)模塊主要包括網(wǎng)絡(luò)管理模塊、協(xié)議管理模塊、key-value索引與存儲(chǔ)模塊、統(tǒng)一數(shù)據(jù)讀寫模塊以及其他輔助模塊.網(wǎng)絡(luò)管理模塊主要負(fù)責(zé)響應(yīng)客戶端建立連接并響應(yīng)客戶端請(qǐng)求，以及通過網(wǎng)絡(luò)收發(fā)消息.協(xié)議管理模塊主要負(fù)責(zé)按Memcache格式解析收到的網(wǎng)絡(luò)請(qǐng)求以及封裝準(zhǔn)備發(fā)出的請(qǐng)求答復(fù).數(shù)據(jù)管理模塊主要負(fù)責(zé)數(shù)據(jù)區(qū)域的建立和管理.索引管理模塊主要負(fù)責(zé)索引表的建立和管理.數(shù)據(jù)讀寫模塊主要負(fù)責(zé)讀寫統(tǒng)一內(nèi)存中轉(zhuǎn)池，以及通過存儲(chǔ)模塊訪問NVMe SSD.

2.2.1 網(wǎng)絡(luò)管理模塊

網(wǎng)絡(luò)管理模塊使用F-Stack提供的網(wǎng)絡(luò)I/O事件通知機(jī)制，其底層基于DPDK用戶級(jí)以太網(wǎng)卡驅(qū)動(dòng)、用戶級(jí)TCP/IP協(xié)議棧和kqueue I/O模型.

UKV系統(tǒng)啟動(dòng)時(shí)首先初始化網(wǎng)絡(luò)I/O事件通知模型.然后初始化非阻塞的用戶級(jí)監(jiān)聽套接字，綁定服務(wù)端的IP地址和端口號(hào)，并設(shè)置IP地址和端口號(hào)為可重用.隨之封裝監(jiān)聽套接字的讀事件并加入通知模型.通知模型開始輪詢監(jiān)聽，一旦收到向監(jiān)聽套接字的連接請(qǐng)求，就與客戶端建立連接，并將已建立的非阻塞用戶級(jí)套接字的讀事件也加入通知模型中.通知模型繼續(xù)輪詢監(jiān)聽，當(dāng)其中某個(gè)套接字收到消息后觸發(fā)讀事件并調(diào)用回調(diào)函數(shù)，此后執(zhí)行數(shù)據(jù)讀取、請(qǐng)求解析等后續(xù)操作.當(dāng)其中某個(gè)套接字收到發(fā)送消息的請(qǐng)求后，則將該套接字的寫事件加入到通知模型，監(jiān)聽到寫事件觸發(fā)后，調(diào)用回調(diào)函數(shù)并發(fā)送數(shù)據(jù)給客戶端.

2.2.2 數(shù)據(jù)管理模塊

數(shù)據(jù)管理模塊負(fù)責(zé)建立和管理4個(gè)數(shù)據(jù)區(qū)域:內(nèi)存數(shù)據(jù)區(qū)、SSD數(shù)據(jù)區(qū)、數(shù)據(jù)中轉(zhuǎn)內(nèi)存池、數(shù)據(jù)緩存區(qū).

內(nèi)存數(shù)據(jù)區(qū)和SSD數(shù)據(jù)區(qū)通過slab機(jī)制管理，主要用來存儲(chǔ)key-value對(duì)數(shù)據(jù)，其方式與Fatcache類似，不過DRAM與SSD之間的數(shù)據(jù)置換采用了最近最少使用的策略.

數(shù)據(jù)緩存區(qū)主要服務(wù)合并I/O優(yōu)化.由于UKV采用run-to-completion模型，而且直接與存儲(chǔ)設(shè)備硬件隊(duì)列交互，并未利用現(xiàn)成的請(qǐng)求隊(duì)列調(diào)度機(jī)制.數(shù)據(jù)緩存區(qū)將短時(shí)間內(nèi)的I/O讀請(qǐng)求緩存起來，若當(dāng)前請(qǐng)求可以與已緩存請(qǐng)求合并，則直接讀取緩存數(shù)據(jù)，避免對(duì)SSD的多次冗余訪問.

2.2.3 索引管理模塊

索引表存儲(chǔ)于內(nèi)存，訪問延遲低，可以快速獲取數(shù)據(jù)存儲(chǔ)的具體位置，不同于傳統(tǒng)存儲(chǔ)系統(tǒng)需要頻繁低效地訪問外存.索引管理模塊負(fù)責(zé)索引表的建立和維護(hù)，其原理機(jī)制與Fatcache類似，額外增加了用戶I/O合并的緩存數(shù)據(jù)的索引.

3 系統(tǒng)評(píng)測(cè)

本節(jié)從吞吐量和延遲的角度對(duì)UKV進(jìn)行性能測(cè)試與分析.

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

測(cè)試采用2個(gè)物理節(jié)點(diǎn)：1)配備NVMe SSD，部署UKV或原生Memcached，作為服務(wù)端；2)部署客戶端性能測(cè)試工具.2個(gè)節(jié)點(diǎn)通過萬兆以太網(wǎng)卡相互連接.測(cè)試所采用的數(shù)據(jù)集由測(cè)試工具提供.

2個(gè)節(jié)點(diǎn)軟硬件配置同構(gòu)，具體如表1所示：

Table 1 Configuration of the Testbed Server表1 測(cè)試節(jié)點(diǎn)的軟硬件配置

3.2 評(píng)測(cè)方案

測(cè)試與Twitter開源的Fatcache進(jìn)行了對(duì)比，其上層與UKV的數(shù)據(jù)管理模型基本一致，但是底層基于傳統(tǒng)的操作系統(tǒng)內(nèi)核網(wǎng)絡(luò)和存儲(chǔ)機(jī)制，并且網(wǎng)絡(luò)棧與存儲(chǔ)棧互相分離.

測(cè)試主要對(duì)吞吐量與延遲進(jìn)行對(duì)比分析.具體來說，吞吐量是指key-value系統(tǒng)在單位時(shí)間內(nèi)處理請(qǐng)求的數(shù)量，是衡量服務(wù)器性能的重要指標(biāo)，單位是QPS.吞吐量測(cè)試建立多個(gè)并發(fā)連接，并發(fā)起多次并發(fā)請(qǐng)求，統(tǒng)計(jì)服務(wù)器處理完所有請(qǐng)求所花費(fèi)的時(shí)間，再計(jì)算得到吞吐量.延遲則是指客戶端向服務(wù)器發(fā)出請(qǐng)求到收到答復(fù)的時(shí)間，對(duì)真實(shí)互聯(lián)網(wǎng)服務(wù)而言，通常直接影響用戶體驗(yàn).延遲測(cè)試建立多個(gè)并發(fā)連接，每個(gè)連接每次只發(fā)出一個(gè)請(qǐng)求，收到答復(fù)后，發(fā)出下一個(gè)請(qǐng)求，如此反復(fù)；持續(xù)一段時(shí)間后，統(tǒng)計(jì)所有請(qǐng)求從發(fā)出到收到答復(fù)所花費(fèi)的時(shí)間，忽略花費(fèi)時(shí)間最多的5%請(qǐng)求，統(tǒng)計(jì)其他95%請(qǐng)求中花費(fèi)最多的時(shí)間，得到p95延遲.

內(nèi)存數(shù)據(jù)區(qū)的大小會(huì)對(duì)性能造成很大的影響，故而測(cè)試將分為內(nèi)存充足和內(nèi)存不足2種情況.設(shè)定內(nèi)存充足時(shí)，內(nèi)存數(shù)據(jù)區(qū)足夠大，不會(huì)發(fā)生涉及SSD訪問的操作；而內(nèi)存不足時(shí)，配置中幾乎每次GET操作都會(huì)訪問SSD，完成網(wǎng)卡通信、應(yīng)用空間、SSD讀取的完整數(shù)據(jù)通路處理，從而體現(xiàn)用戶級(jí)融合I/O的性能優(yōu)勢(shì).

3.3 吞吐量測(cè)試

內(nèi)存充足和內(nèi)存不足2種情況的查詢配置相同：客戶端與服務(wù)端建立500個(gè)并發(fā)連接，發(fā)起至少250萬次的SET請(qǐng)求和至少50萬次的GET操作，統(tǒng)計(jì)得到平均吞吐量性能.

如圖8所示，內(nèi)存充足時(shí)，相比Fatcache，UKV的SET操作的吞吐量提高了31.87%～100%.數(shù)據(jù)長(zhǎng)度較小時(shí)，吞吐量提高了90%以上；隨著數(shù)據(jù)長(zhǎng)度的增加，吞吐量提高的比例有所下降；在數(shù)據(jù)長(zhǎng)度達(dá)到4 KB時(shí)，吞吐量提高比例仍然達(dá)到了31.87%.

Fig.8 The average throughput of SET operations with sufficient memory圖8 內(nèi)存充足時(shí)SET操作的平均吞吐量

如圖9所示，內(nèi)存充足時(shí)，相比Fatcache，UKV的GET操作的吞吐量提高了21.62%～38.48%.在數(shù)據(jù)長(zhǎng)度達(dá)到4 KB時(shí)，吞吐量提高了21.67%.

Fig.9 The average throughput of GET operations with sufficient memory圖9 內(nèi)存充足時(shí)GET操作的平均吞吐量

如圖10所示，內(nèi)存不足時(shí)，UKV的SET操作的吞吐量提高了14.97%～97.78%.數(shù)據(jù)長(zhǎng)度較小時(shí)，吞吐量提高可達(dá)90%以上；隨著數(shù)據(jù)長(zhǎng)度的增加，吞吐量提高的比例有所下降；在數(shù)據(jù)長(zhǎng)度達(dá)到2 KB時(shí)，吞吐量仍然提高了40.22%；在數(shù)據(jù)長(zhǎng)度達(dá)到4 KB時(shí)，吞吐量提高比例14.97%.

Fig.10 The average throughput of SET operations with insufficient memory圖10 內(nèi)存不足時(shí)SET操作的平均吞吐量

如圖11所示，內(nèi)存不足時(shí)，UKV的GET操作的吞吐量提高了16.71%～32.48%.在數(shù)據(jù)長(zhǎng)度達(dá)到4 KB時(shí)，吞吐量提高了32.48%.

Fig.11 The average throughput of GET operations with insufficient memory圖11 內(nèi)存不足時(shí)GET操作的平均吞吐量

內(nèi)存不足時(shí)，幾乎每次GET操作都需要訪問SSD，吞吐量大幅下降.50萬次GET請(qǐng)求對(duì)服務(wù)器單SSD的訪問壓力較大，測(cè)試得到的平均吞吐量性能并不是服務(wù)器的最佳性能.通過保持500個(gè)并發(fā)連接，但是適當(dāng)減少GET請(qǐng)求數(shù)量，可以測(cè)試得到最大吞吐量性能，如圖12所示.再與Fatcache相比，UKV的GET操作的最大吞吐量提高了14.60%～51.81%.數(shù)據(jù)長(zhǎng)度較小時(shí)，吞吐量提高了50%左右；隨著數(shù)據(jù)長(zhǎng)度的增加，吞吐量提高的比例有所下降；在數(shù)據(jù)長(zhǎng)度達(dá)到2 KB時(shí)，吞吐量仍然提高了27.91%；在數(shù)據(jù)長(zhǎng)度達(dá)到4 KB時(shí)，吞吐量提高比例為14.60%.可見，內(nèi)存不足時(shí)，GET操作的吞吐能力受到SSD隨機(jī)訪問性能的限制，與內(nèi)存充足時(shí)相比有一定下降.

Fig.12 The maximum throughput of GET operations with insufficient memory圖12 內(nèi)存不足時(shí)GET操作的最大吞吐量

UKV的統(tǒng)一控制平面減少了中斷處理和上下文切換、統(tǒng)一數(shù)據(jù)平面減少了數(shù)據(jù)拷貝，節(jié)省的CPU資源可用來處理key-value請(qǐng)求、簡(jiǎn)化的數(shù)據(jù)通路消除了冗余數(shù)據(jù)搬移，再結(jié)合統(tǒng)一流水、單一地址空間等的優(yōu)化，從而提高了吞吐性能.

數(shù)據(jù)長(zhǎng)度較小時(shí)，不同的數(shù)據(jù)長(zhǎng)度對(duì)吞吐性能的影響不大，這是因?yàn)閿?shù)據(jù)傳輸和拷貝的開銷較小且差距不大，UKV系統(tǒng)體現(xiàn)出了顯著的性能優(yōu)勢(shì).

隨著數(shù)據(jù)長(zhǎng)度的增加，UKV的吞吐量提高的幅度逐漸下降.這是由于用戶態(tài)TCP/IP協(xié)議棧處理、Memcache數(shù)據(jù)格式化等占用的CPU資源越來越多，網(wǎng)絡(luò)傳輸、SSD訪問的開銷也越來越高，漸成影響性能的主導(dǎo)因素.

如圖11所示，內(nèi)存不足且GET操作密度較高時(shí)，吞吐量提高的比例沒有明顯的規(guī)律.并發(fā)請(qǐng)求數(shù)量負(fù)荷較高時(shí)，訪存壓力增加、吞吐量下降，且下降的程度具有不確定性.

3.4 延遲測(cè)試

內(nèi)存充足時(shí)的SET或GET操作的延遲性能，與內(nèi)存不足時(shí)的SET操作的延遲性能較為接近.這是由于SET操作訪問SSD的頻率很低，以網(wǎng)絡(luò)通信與內(nèi)存訪問為主，與內(nèi)存充足時(shí)的SET和GET操作的數(shù)據(jù)通路幾乎一致.故而本節(jié)的延遲測(cè)試主要分析內(nèi)存不足時(shí)的SET操作與GET操作.

內(nèi)存不足時(shí)，客戶端與服務(wù)端建立500個(gè)并發(fā)連接，每個(gè)連接每次只發(fā)出一個(gè)SET請(qǐng)求，收到答復(fù)后再執(zhí)行下一個(gè)請(qǐng)求；如此持續(xù)60s統(tǒng)計(jì)得到延遲性能.如圖13所示，相比Fatcache，UKV的SET操作的p95延遲降低了26.12%～40.90%.如圖14所示，UKV的GET操作降低了15.10%～24.36%.

Fig.13 The p95 latency of SET operations with insufficient memory圖13 內(nèi)存不足時(shí)SET操作的p95延遲

Fig.14 The p95 latency of GET operations with insufficient memory圖14 內(nèi)存不足時(shí)GET操作的p95延遲

UKV的統(tǒng)一控制平面的設(shè)計(jì)避免了中斷處理、上下文切換、冗余軟件棧處理以及潛在的核間通信核與數(shù)據(jù)遷移等延遲開銷，統(tǒng)一數(shù)據(jù)平面減少了額外的數(shù)據(jù)拷貝，從而降低了延遲.

隨著數(shù)據(jù)長(zhǎng)度的增加，SET操作的p95延遲降低的比例逐漸下降，但是GET操作的p95延遲降低的比例并未下降.因?yàn)镾ET操作的性能主要受網(wǎng)絡(luò)傳輸影響，網(wǎng)絡(luò)協(xié)議棧處理開銷漸成主導(dǎo)，性能提升比例越低；而GET操作的性能瓶頸始終在SSD隨機(jī)訪問上，數(shù)據(jù)長(zhǎng)度的影響相對(duì)較小.

4 相關(guān)工作

本節(jié)主要介紹基于高性能I/O的key-value存儲(chǔ)系統(tǒng)的相關(guān)研究工作.

傳統(tǒng)基于DRAM的key-value系統(tǒng)的性能受限于內(nèi)核網(wǎng)絡(luò)棧，采用高性能網(wǎng)絡(luò)技術(shù)取代開銷過大的傳統(tǒng)套接字通信機(jī)制是一種比較直接的優(yōu)化手段.RDMA(remote direct memory access)是高性能通信技術(shù)的代表，其在科學(xué)計(jì)算領(lǐng)域已有了廣泛的應(yīng)用［10].Jose等人［11]基于RDMA優(yōu)化Memcache與Thongprasit等人［12]基于用戶級(jí)TCP/IP協(xié)議棧優(yōu)化Redis是比較代表性的工作.

利用高性能非易失存儲(chǔ)技術(shù)來改進(jìn)key-value系統(tǒng)的訪存性能并降低存儲(chǔ)成本是熱點(diǎn)優(yōu)化方向.定制化方案例如Open-Channel SSD雖然能取得理想的效率，但成本較高.基于商品SSD設(shè)備并結(jié)合系統(tǒng)軟件定制優(yōu)化是性價(jià)比較高的方案.近來的NVMoF(NVMe over fabrics)技術(shù)雖然提供了易用的塊接口，但仍然由操作系統(tǒng)內(nèi)核提供支持，無法消除資源爭(zhēng)用、線程調(diào)度等的弊端.DPDK與SPDK提供了基礎(chǔ)的用戶級(jí)驅(qū)動(dòng)，暴露了最為底層的硬件接口，無法為應(yīng)用直接利用，且二者相對(duì)獨(dú)立，彼此沒有適配或優(yōu)化.

Guz等人［13]提出數(shù)據(jù)中心內(nèi)計(jì)算節(jié)點(diǎn)利用NVMoF技術(shù)訪問專用存儲(chǔ)節(jié)點(diǎn)上的數(shù)據(jù)，并以RocksDB為例進(jìn)行了性能測(cè)評(píng)，結(jié)果表明采用NVMoF時(shí)，訪問本地與遠(yuǎn)程存儲(chǔ)資源，性能沒有明顯差距.

IBM研究院的Trivedi等人［14]提出了一種軟件I/O棧，取名FlashNet，將高性能RDMA網(wǎng)絡(luò)與Flash SSD融合統(tǒng)一管理.基準(zhǔn)測(cè)試性能中，與傳統(tǒng)套接字與文件系統(tǒng)的服務(wù)器相比，IOPS提高了38.6%，訪問延遲降低了43.5%.

Klimovic等人［15]設(shè)計(jì)了一種基于軟件的Flash存儲(chǔ)服務(wù)系統(tǒng)——ReFlex，收獲了與本地Flash訪問性能相媲美的遠(yuǎn)程Flash訪問能力.當(dāng)系統(tǒng)負(fù)載較低時(shí)，比本地SPDK訪問相比，ReFlex的遠(yuǎn)程讀寫延遲僅增加了21 μs和20 μs，單CPU處理器核的ReFlex吞吐能力可以達(dá)到850 K的IOPS.

5 結(jié) 論

本文設(shè)計(jì)并實(shí)現(xiàn)了用戶級(jí)融合I/O的高性能key-value存儲(chǔ)系統(tǒng)，并完成了統(tǒng)一并行流水優(yōu)化，有效提升了數(shù)據(jù)訪問性能.本文采用用戶態(tài)整合網(wǎng)絡(luò)與I/O棧以及控制與數(shù)據(jù)平面分離的設(shè)計(jì)，保證高效的數(shù)據(jù)通路.每個(gè)平面內(nèi)則緊密統(tǒng)一網(wǎng)絡(luò)與存儲(chǔ)，最大限度降低系統(tǒng)軟件的管理控制開銷.通過吞吐量和延遲的性能評(píng)測(cè)，用戶級(jí)融合I/O能夠有效提升了key-value存儲(chǔ)系統(tǒng)性能.

隨著單節(jié)點(diǎn)I/O密度的進(jìn)一步提升，單CPU處理器核很可能無法滿足下一代高速存儲(chǔ)的需求.下一步工作主要面向多核控制平面，結(jié)合節(jié)點(diǎn)內(nèi)互連拓?fù)?，提高融合I/O的效率與可擴(kuò)展性.