redis 作為最受歡迎的 NoSQL 數據庫之一，具備高性能、高可用性、高擴展性等特點，在各互聯網業務中使用廣泛。目前業界針對 Redis 的性能優化主要針是配置項優化以及使用方式的優化。本文介紹嘗試撇開 Redis 本身，而從通用的協議棧層面來做優化，這種優化方式理論上可推廣到其他 Socket 類互聯網應用，如 Memcached、Ngnix、Envoy 等。
分 析
Redis-server 作為一個標準的 Socket 類應用，會通過監聽地址端口接收來自客戶端的連接，連接建立后會讀取連接上的客戶端請求，處理后再返回響應給客戶端，這其中的連接建立、請求讀取、響應返回都是通過內核的 TCP/IP 協議棧來處理的。可以通過火焰圖先看一下 Redis-server 在性能壓測下的 CPU 消耗情況。
圖中，是在客戶端讀請求壓測的時候抓取的火焰圖信息。可見，內核態協議棧所占用的 CPU 消耗較大，其中以 sys_write 為主，占比 40% 左右。所以，如果能對這部分 CPU 占用進行優化，收益還是非常可觀的。
那么這部分 CPU 占比如何進行優化呢？最好還能做到 Redis 應用本身完全無感知。
協議棧的處理完全省掉是不現實的，這樣底層 TCP 通信就玩不轉了。但是我們可以考慮將這部分處理剝離出去，不占用 Redis 的 CPU。
那剝離出去的協議棧實現放在哪兒呢？
可以放到一個單獨的進程中實現。那這樣是不是和剝離前沒有區別？
No！因為一臺機器上一般會啟動多個 Redis 實例，多個 Redis 實例在這種情況下就可以共享這個協議棧實現的進程。相當于將 Redis 和協議棧的 1:1 綁定部署關系，變為 N:1 的獨立部署關系。
那這個協議棧實現進程的性能就非常重要了，絕對不能成為瓶頸，否則會導致最終的性能沒有提升，甚至更糟。具體如何實現呢？
下面該輪到用戶態協議棧出場了！
優 化
用戶態協議棧介紹
顧名思義，用戶態協議棧是將原本在內核態實現的 TCP/IP 協議棧移到用戶態實現的技術。放到用戶態實現可以帶來幾大好處：
1. 高性能
Redis 本身是一個用戶態的應用程序，調用內核態的 TCP/IP 協議棧實現，不可避免地會帶來用戶態和內核態的上下文切換開銷。另外，最重要的一點，內核協議棧和應用綁定在一起，無法做到和應用在資源占用上剝離，也就是前面所述的獨立部署。
2. 易調測
做過內核態開發的同學應該都知道，內核下程序的調測還是比較痛苦的，動不動給你來個 Oops 就會導致內核掛死。放到用戶態實現調測起來就會方便很多。
3. 易定制
內核協議棧隨著版本的迭代，歷史包袱越來越重，導致越來越臃腫。而且新特性的合入時依賴會越來越多，也會越來越謹慎，甚至 bug 的修復周期也越來越長。用戶態協議棧則不會有此類問題，可以在內核協議棧的基礎上做裁剪和定制，易調測也會讓試錯成本大大降低。
相關視頻推薦
徒手實現網絡協議棧，請準備好環境，一起來寫代碼
linux下的epoll實戰揭秘——支撐億級IO的底層基石
學習地址：C/C++Linux服務器開發/后臺架構師【零聲教育】-學習視頻教程-騰訊課堂
需要C/C++ linux服務器架構師學習資料加qun812855908獲取（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等），免費分享
用戶態協議棧具體實現
用戶態協議棧我們采用開源 VPP+VCL 的方案：VPP 作為獨立進程在用戶態實現 TCP/IP 協議棧，VCL 作為動態庫實現 Socket 類接口劫持并和后端 VPP 完成交互。整個系統的架構如下圖所示：
其中：
- VCL - 實現 Socket 類接口劫持并和后端 VPP 完成交互
- FIFO - 是基于共享內存封裝的消息隊列，用于 VCL 和 VPP 之間通信
- Session - 維持傳輸層和上層應用會話之間的對應
- TCP/IP - 對應內核的 TCP/IP 協議棧實現
- DPDK - 實現將網卡的報文收發卸載到用戶態
可見，VPP+VCL 分離式的部署模式將協議棧從應用端剝離，并通過 LD_PRELOAD 方式加載 VCL 動態庫實現對于 Redis 的無侵入加速。
最后，VPP 如何做到本身處理的高效而不會成為瓶頸呢？
VPP 主要基于 DPDK 實現報文的高效收發，再結合自身的向量化處理（減少 CPU Cache missing）來實現報文的高效處理。另外，graph node+ 插件化也讓其非常易于擴展和定制。
rdbsave 動態進程問題
使用開源 VPP 加速 Redis 過程中，也遇到和解決了不少社區版本中的問題，比較典型的就是 rdbsave 動態進程引發的問題。
Redis 可以配置周期性的保存快照，實現上會啟用一個動態的 rdbsave 進程來完成，rdbsave 進程非常駐進程，在完成工作后就會退出。配置文件中可以指定保存的周期以及觸發保存的變化量，如果周期配置的比較短且觸發保存的變化量比較小，則可能會導致 rdbsave 進程頻繁的創建和退出，實測過程中這也會導致目前社區中對于動態進程支持的一些問題很快速的就能暴露出來。
Session 同步問題
rdbsave 進程創建時會從主線程同步 socket 相關的 session 資源。目前社區中 epoll fd 相關的 session 資源沒有同步完全，主要是因為 session handle 中包含了各個進程的 worker_index 信息，而 worker_index 是因進程 / 線程而異的，直接從主線程同步過來的 session handle 需要根據 worker_index 做轉換才能使用。相關的 patch 目前已經合入社區。
死鎖問題
rdbsave 進程退出時需要釋放和進程關聯的 session 資源，目前是通過主線程捕獲 SIGCHLD 信號，在信號處理函數中來釋放相關 session 資源。如果主線程在先獲取鎖 A 的情況下跳轉到信號處理函數釋放資源，而釋放資源的時候也獲取了鎖 A，則會導致死鎖。當然我們可以針對鎖 A 的情況想辦法解決此問題，但是這種解決方式不徹底，因為主線程可能獲取了鎖 B 后再去執行信號處理函數釋放資源，然后釋放資源的時候也獲取了鎖 B。根源是在于執行信號處理函數之前的主線程狀態未知。
所以，我們可以考慮在信號處理函數中不釋放資源，而僅僅將待釋放的資源索引進行保存，等到后面合適的時機，如執行 epoll_wait 的時候再進行釋放。相關的 patch 目前也已經合入社區。
效 果
通過優化后的火焰圖看效果：
可見，內核的 socket 讀寫已經大大降低，還遺留的是用戶態協議棧實現中用來在 VCL 和 VPP 之間通知事件的 eventfd 通知。
基于 redis 4.0.9 以及 memtier_benchmark 1.2.17 測試的結果。
QPS 提升 31%，此時內核態 Redis CPU 占用 99%，用戶態 Redis CPU 占用 80% 左右。
延遲降低 23.2%，同樣此時內核態 Redis CPU 占用 99%，用戶態 Redis CPU 占用 80% 左右。
總 結
用戶態協議棧可以輕松做到針對 Redis 的無侵入加速，在占用 CPU 資源更少的情況下，相較內核態協議棧可以取得 31% 的 QPS 加速效果，同時延遲降低 23%。
用戶態協議棧作為通用的加速組件，理論上可以支持所有 Socket 類應用的加速。目前基于用戶態協議棧對網易數帆輕舟微服務 API 網關中 Envoy 的加速已經產品化并在網易嚴選環境中落地，針對 Sidecar 的加速也相繼在內外部客戶完成測試，針對 Redis 的加速也完成了 PoC 測試。整個加速組件的數據面基于 Kubernetes 的 DaemonSet 部署，而管控面基于 Kubernetes 的 Operator 部署，部署簡單、運維方便。我們也會在后續工作中，持續探索基于用戶態協議棧的更多應用場景。
