基于用戶級融合I/O的Key-Value存儲系統優化技術研究

安仲奇 張云堯,2 邢 晶 霍志剛,2

1(計算機體系結構國家重點實驗室(中國科學院計算技術研究所) 北京 100190) 2(中國科學院大學計算機與控制工程學院 北京 100049)(anzhongqi@ncic.ac.cn)

現如今，互聯網產生和累積的數據越來越多.根據思科系統公司的報告，2016年的全球互聯網流量已經突破了1 ZB，平均每個月新增96 EB流量.其中忙碌時段的互聯網流量相比以往增長了51%，普通時段的互聯網流量相比以往增長了32%.此外，報告預測2021年的全球互聯網流量將達到3.3 ZB，此間的復合年增長率將達到24%［1].互聯網數據規模和高峰流量的爆發式增長，給數據管理系統帶來了非常大的考驗.

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

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

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

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

本文的主要貢獻有3個方面：

1) 面向key-value存儲系統提出了一種全用戶態的網絡與存儲協同優化的方法，控制路徑由專核統一管理網卡與固態盤設備，減少軟件層面的干涉，數據通路采取統一的DMA中轉內存池，避免額外數據拷貝.

2) 針對大消息數據訪問請求，提出了聯合網絡與存儲的優化方法，將數據分片并交疊執行網卡與固態盤的DMA操作，進一步掩藏延遲.

3) 實現了全用戶態key-value存儲系統UKV，其支持內存-固態盤2層存儲以及廣泛使用的Memcache［7]接口.測試結果表明其網絡I/O性能優于Twitter Fatcache.

1 系統介紹

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

1.1 分層存儲

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

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

現代SSD設備不僅支持傳統的512 B塊單位大小，亦支持4 096 B的塊大小以降低元數據管理開銷，而key-value存儲系統中通常存在大量的小消息負載，對此類消息，一個塊可以包含多個key-value對.如若同一塊的不同key-value對被訪問，將導致對該塊的重復訪問.對此，UKV于用戶態對網絡棧與I/O棧進行了整合，以避免冗余的設備訪問，提高系統的響應性能.

1.2 用戶級I/O

用戶級I/O，旨在旁路操作系統內核，面向應用定制、裁剪系統軟件棧，避免通用內核限制并最小化軟件開銷.

1.2.1 用戶級網絡通信

UKV使用用戶級網絡框架DPDK和用戶級TCP/IP協議棧F-Stack［8]實現用戶級網絡通信，提高系統的網絡數據處理性能和吞吐量.

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

1.2.2 用戶級存儲

UKV使用用戶級存儲框架SPDK實現對SSD的直接管理，并結合key-value存儲系統需求以及F-stack實現了輕量級的I/O層，降低了存儲設備訪問過程的軟件開銷.

1.3 融合I/O

本文的融合I/O軟件棧遵循經典高性能技術(如遠程內存直接訪問)控制平面與數據平面分離的原則，又于控制路徑與數據路徑分別統一管理網絡與存儲的數據流動，以保證高效的數據通路.

1.3.1 統一控制平面

本文通過核專用化的方式，將同一個線程綁定在固定CPU核心上，并采用“執行至結束”(run-to-completion)模型，于用戶態中通過單一的上下文直接訪問網卡設備和NVMe設備的底層硬件隊列，實現網絡與存儲控制平面的統一.

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

如圖1與圖2所示，在傳統操作系統機制下，key-value存儲系統處理數據存取操作的過程中將涉及多次進出內核態的系統調用、網卡設備和存儲設備的多次中斷等.而在UKV的統一控制平面下，通過采用輪詢機制徹底避免了中斷處理的開銷，同時由于設備直接驅動，進一步避免了上下文切換.單一上下文中的定制化輕量級軟件棧也消除了數據拷貝和冗余軟件棧處理開銷.

Fig.2 Comparsion of the scheduling state of the data path of traditional mechanism and unified control plane圖2 傳統機制和統一控制平面下數據通路的調度狀態

UKV使用同一個線程，綁定在固定CPU處理器核心上，采用run-to-completion模型，同時管理網卡設備和NVMe設備.靜態線程綁核的方式避免了線程在核之間的遷移開銷，提高了緩存與內存訪問的效率.如圖3所示，run-to-completion模型指由單一線程負責于單一用戶態上下文中處理key-value請求，具體環節包括：

① 網卡接收數據包.網卡在接收到網絡數據包后通過DMA直接拷貝到UKV的數據區域，該過程完全于用戶空間執行，無額外數據拷貝與管理模式切換；

② key-value系統處理.UKV解析接收到網絡數據包和I/O請求，并完成相關的key-value數據管理操作；

③ 提交SSD讀寫請求.UKV向SSD發起讀寫請求，該過程同樣完全于用戶空間執行，額外開銷極低；

④ 完成SSD讀寫操作.UKV于用戶空間通過SSD驅動輪詢設備完成隊列，等待讀寫操作完成；

⑤ key-value系統處理.UKV生成回復，打包數據或響應并完成相關的key-value數據管理操作；

⑥ 網卡發送數據包.UKV于用戶空間將生成的回復通過網卡直接傳輸.

上述過程不涉及特權模式切換、中斷處理以及線程調度，具有很好的數據緩存局部性，最大限度地避免了數據的額外搬移.如若采用傳統的多線程資源共享、輪轉響應的機制，在訪問共享數據時會面臨嚴重的鎖競爭，線程搶占、調度會導致緩存之間頻繁的數據更新與通信，拉低了效率.

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

此外，根據文獻［9]的測試結果，就目前主流CPU處理器、高速以太網卡、NVMe SSD的性能而言，單一處理器核心可充分發揮出網卡和SSD的性能，故本文暫未考慮多核控制平面的設計.

1.3.2 統一數據平面

簡單地說，統一數據平面是指完全于用戶空間直接驅動設備驅動，網卡與SSD的設備隊列統一調度并緊密耦合，通過設備DMA引擎直接于統一的數據中轉內存池中收發數據.

如圖4所示，在傳統機制下，key-value存儲系統在執行接收操作即SET操作時，數據首先由操作系統內核網絡緩沖區拷貝到用戶態key-value系統的地址空間，再由key-value系統用戶空間拷貝到操作系統內核存儲緩沖區，經過內核存儲棧層層處理后最終寫入存儲設備.發送操作即GET操作，數據首先由存儲設備讀取至內核緩沖區，再拷貝至用戶態key-value地址空間，再次拷貝入內核網絡棧發送.冗長的數據拷貝路徑限制了系統吞吐.雖然傳統操作系統內核提供了一些機制或功能可用于減少部分拷貝環節，但大都存在一些弊端.以Linux為例，mmap的方式仍然需要額外的CPU數據拷貝，且引入了開銷較大的頁表映射操作；sendfile機制僅支持內核空間數據的直接網絡傳輸，存在污染內核頁緩沖的隱患，且考慮網絡傳輸的異步性，通常僅支持發送端的傳輸.

Fig.4 Comparison of the data path of I/O operations of traditional mechanism and unified data plane圖4 傳統機制和統一數據平面下I/O操作的數據通路

而在統一數據平面的設計下，UKV系統完全于用戶空間直接傳輸數據，接收數據時網卡直接寫入、讀取數據時直接由SSD傳輸至應用緩沖，整個數據路徑僅涉及單次系統主存中轉.且地址空間單一、上下文單一，無需額外的頁表處理，不存在污染公共存儲資源的副作用.

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

通過用戶態NVMe驅動提交讀寫操作后，UKV系統輪詢設備的完成隊列.操作完成后，將value數據落盤狀態或讀取到的value數據以Memcache協議格式封裝并存放于內存中轉池.之后于用戶態由TCP/IP協議棧封包后直接交由網卡傳輸.

1.4 數據通路優化

UKV系統的數據傳輸路徑，包括網卡接收數據包、key-value協議解析、提交SSD讀寫請求、完成SSD讀寫操作、key-value格式化、TCP協議棧封包、網卡發送數據包，整體延遲即各個環節延遲的總和.對SET操作而言，得益于slab機制，SET操作于內存中處理后即返回響應，性能路徑不涉及SSD訪問，故而瓶頸集中在網絡通信開銷方面，缺乏優化空間.對GET操作來說，涉及SSD讀取時，SSD延遲最高且占比顯著.如圖5所示，經測試，GET操作中的存儲訪問延遲整體占比可高達70%以上.

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

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

Fig.6 The unified pipelining of networking and SSD I/O圖6 統一并行流水的優化方法

得益于全用戶態、統一內存中轉池的設計，UKV系統能夠實現細粒度的流水線設計與調優，且性能干擾因素較少、流水線表現更加穩定.

2 系統實現

本節詳細介紹UKV系統的實現.

2.1 系統架構

UKV的系統架構如圖7所示，主要包括3部分：網絡模塊、存儲模塊與數據模塊.網絡模塊負責用戶態直接驅動網卡、發送或接收網絡數據包、網絡協議棧封裝或解析等；存儲模塊負責用戶態直接驅動SSD、請求與完成隊列管理等；數據模塊則主要負責基本的key-value邏輯與存儲(例如Memcache接口、slab存儲等)以及統一的控制平面、數據流水線、聯合I/O調度等.

在新時代全面深化改革中推進全面依法治國。黨的十八大以來，以習近平同志為核心的黨中央以高瞻遠矚的戰略眼光、一往無前的宏大氣魄、雷厲風行的堅毅行動、激濁揚清的責任擔當，揭開了新時代全面深化改革的大幕，確立了完善和發展中國特色社會主義制度、推進國家治理體系和治理能力現代化的全面深化改革總目標。與之相適應，從關系黨和國家前途命運、長治久安的戰略全局高度來定位法治、布局法治、推進法治、厲行法治，確立了建設中國特色社會主義法治體系、建設社會主義法治國家的全面依法治國總目標。

Fig.7 The architecture of the UKV system圖7 UKV的系統架構

UKV系統的服務端與客戶端通過標準TCP/IP協議進行通信.UKV服務端內部是完全用戶態的網絡通信且支持內存-外存2層存儲，對NVMe SSD的驅動與管理同樣完全于用戶態實現.UKV控制平面與數據平面分離且各自緊密整合網絡與I/O，有助于屏蔽系統噪聲、精簡數據通路.

2.2 核心模塊

網絡模塊和存儲模塊分別負責完成用戶級網絡通信和用戶級SSD訪問，由統一控制平面和統一數據平面聯合到一起.

數據模塊主要包括網絡管理模塊、協議管理模塊、key-value索引與存儲模塊、統一數據讀寫模塊以及其他輔助模塊.網絡管理模塊主要負責響應客戶端建立連接并響應客戶端請求，以及通過網絡收發消息.協議管理模塊主要負責按Memcache格式解析收到的網絡請求以及封裝準備發出的請求答復.數據管理模塊主要負責數據區域的建立和管理.索引管理模塊主要負責索引表的建立和管理.數據讀寫模塊主要負責讀寫統一內存中轉池，以及通過存儲模塊訪問NVMe SSD.

2.2.1 網絡管理模塊

網絡管理模塊使用F-Stack提供的網絡I/O事件通知機制，其底層基于DPDK用戶級以太網卡驅動、用戶級TCP/IP協議棧和kqueue I/O模型.

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

2.2.2 數據管理模塊

數據管理模塊負責建立和管理4個數據區域:內存數據區、SSD數據區、數據中轉內存池、數據緩存區.

內存數據區和SSD數據區通過slab機制管理，主要用來存儲key-value對數據，其方式與Fatcache類似，不過DRAM與SSD之間的數據置換采用了最近最少使用的策略.

數據緩存區主要服務合并I/O優化.由于UKV采用run-to-completion模型，而且直接與存儲設備硬件隊列交互，并未利用現成的請求隊列調度機制.數據緩存區將短時間內的I/O讀請求緩存起來，若當前請求可以與已緩存請求合并，則直接讀取緩存數據，避免對SSD的多次冗余訪問.

2.2.3 索引管理模塊

索引表存儲于內存，訪問延遲低，可以快速獲取數據存儲的具體位置，不同于傳統存儲系統需要頻繁低效地訪問外存.索引管理模塊負責索引表的建立和維護，其原理機制與Fatcache類似，額外增加了用戶I/O合并的緩存數據的索引.

3 系統評測

本節從吞吐量和延遲的角度對UKV進行性能測試與分析.

3.1 評測環境

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

2個節點軟硬件配置同構，具體如表1所示：

Table 1 Configuration of the Testbed Server表1 測試節點的軟硬件配置

3.2 評測方案

測試與Twitter開源的Fatcache進行了對比，其上層與UKV的數據管理模型基本一致，但是底層基于傳統的操作系統內核網絡和存儲機制，并且網絡棧與存儲棧互相分離.

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

內存數據區的大小會對性能造成很大的影響，故而測試將分為內存充足和內存不足2種情況.設定內存充足時，內存數據區足夠大，不會發生涉及SSD訪問的操作；而內存不足時，配置中幾乎每次GET操作都會訪問SSD，完成網卡通信、應用空間、SSD讀取的完整數據通路處理，從而體現用戶級融合I/O的性能優勢.

3.3 吞吐量測試

內存充足和內存不足2種情況的查詢配置相同：客戶端與服務端建立500個并發連接，發起至少250萬次的SET請求和至少50萬次的GET操作，統計得到平均吞吐量性能.

如圖8所示，內存充足時，相比Fatcache，UKV的SET操作的吞吐量提高了31.87%～100%.數據長度較小時，吞吐量提高了90%以上；隨著數據長度的增加，吞吐量提高的比例有所下降；在數據長度達到4 KB時，吞吐量提高比例仍然達到了31.87%.

Fig.8 The average throughput of SET operations with sufficient memory圖8 內存充足時SET操作的平均吞吐量

如圖9所示，內存充足時，相比Fatcache，UKV的GET操作的吞吐量提高了21.62%～38.48%.在數據長度達到4 KB時，吞吐量提高了21.67%.

Fig.9 The average throughput of GET operations with sufficient memory圖9 內存充足時GET操作的平均吞吐量

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

Fig.10 The average throughput of SET operations with insufficient memory圖10 內存不足時SET操作的平均吞吐量

如圖11所示，內存不足時，UKV的GET操作的吞吐量提高了16.71%～32.48%.在數據長度達到4 KB時，吞吐量提高了32.48%.

Fig.11 The average throughput of GET operations with insufficient memory圖11 內存不足時GET操作的平均吞吐量

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

Fig.12 The maximum throughput of GET operations with insufficient memory圖12 內存不足時GET操作的最大吞吐量

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

數據長度較小時，不同的數據長度對吞吐性能的影響不大，這是因為數據傳輸和拷貝的開銷較小且差距不大，UKV系統體現出了顯著的性能優勢.

隨著數據長度的增加，UKV的吞吐量提高的幅度逐漸下降.這是由于用戶態TCP/IP協議棧處理、Memcache數據格式化等占用的CPU資源越來越多，網絡傳輸、SSD訪問的開銷也越來越高，漸成影響性能的主導因素.

如圖11所示，內存不足且GET操作密度較高時，吞吐量提高的比例沒有明顯的規律.并發請求數量負荷較高時，訪存壓力增加、吞吐量下降，且下降的程度具有不確定性.

3.4 延遲測試

內存充足時的SET或GET操作的延遲性能，與內存不足時的SET操作的延遲性能較為接近.這是由于SET操作訪問SSD的頻率很低，以網絡通信與內存訪問為主，與內存充足時的SET和GET操作的數據通路幾乎一致.故而本節的延遲測試主要分析內存不足時的SET操作與GET操作.

內存不足時，客戶端與服務端建立500個并發連接，每個連接每次只發出一個SET請求，收到答復后再執行下一個請求；如此持續60s統計得到延遲性能.如圖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 內存不足時SET操作的p95延遲

Fig.14 The p95 latency of GET operations with insufficient memory圖14 內存不足時GET操作的p95延遲

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

隨著數據長度的增加，SET操作的p95延遲降低的比例逐漸下降，但是GET操作的p95延遲降低的比例并未下降.因為SET操作的性能主要受網絡傳輸影響，網絡協議棧處理開銷漸成主導，性能提升比例越低；而GET操作的性能瓶頸始終在SSD隨機訪問上，數據長度的影響相對較小.

4 相關工作

本節主要介紹基于高性能I/O的key-value存儲系統的相關研究工作.

傳統基于DRAM的key-value系統的性能受限于內核網絡棧，采用高性能網絡技術取代開銷過大的傳統套接字通信機制是一種比較直接的優化手段.RDMA(remote direct memory access)是高性能通信技術的代表，其在科學計算領域已有了廣泛的應用［10].Jose等人［11]基于RDMA優化Memcache與Thongprasit等人［12]基于用戶級TCP/IP協議棧優化Redis是比較代表性的工作.

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

Guz等人［13]提出數據中心內計算節點利用NVMoF技術訪問專用存儲節點上的數據，并以RocksDB為例進行了性能測評，結果表明采用NVMoF時，訪問本地與遠程存儲資源，性能沒有明顯差距.

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

Klimovic等人［15]設計了一種基于軟件的Flash存儲服務系統——ReFlex，收獲了與本地Flash訪問性能相媲美的遠程Flash訪問能力.當系統負載較低時，比本地SPDK訪問相比，ReFlex的遠程讀寫延遲僅增加了21 μs和20 μs，單CPU處理器核的ReFlex吞吐能力可以達到850 K的IOPS.

5 結 論

本文設計并實現了用戶級融合I/O的高性能key-value存儲系統，并完成了統一并行流水優化，有效提升了數據訪問性能.本文采用用戶態整合網絡與I/O棧以及控制與數據平面分離的設計，保證高效的數據通路.每個平面內則緊密統一網絡與存儲，最大限度降低系統軟件的管理控制開銷.通過吞吐量和延遲的性能評測，用戶級融合I/O能夠有效提升了key-value存儲系統性能.

隨著單節點I/O密度的進一步提升，單CPU處理器核很可能無法滿足下一代高速存儲的需求.下一步工作主要面向多核控制平面，結合節點內互連拓撲，提高融合I/O的效率與可擴展性.