hi，大家好，今天給大家分享一篇，如何設計和優化緩存（類redis）系統，希望大家了解真正落地的架構設計方案，類別redis和memcached，了解架構是如何演進的，學習落地經驗。

CKV(也稱為CKV+)是騰訊新一代自研高性能NoSQL KV數據庫，兼容Redis、Memcached、ASN協議，具備高性能、低延時、低成本的優勢，能夠應對海量數據訪問、存儲成本敏感、延時敏感等問題。

CKV作為公司應用最廣泛的NoSQL存儲系統，已接入包括廣點通、信鴿、QQ音樂、財付通、微視、看點等業務。

隨著業務規模的增長，成本和性能是用戶最關注的問題，為了進一步降低用戶的成本并提升性能，我們分別從性能和成本兩個方面對CKV進行了優化。

下面先回顧CKV的架構演進，然后分析當前架構的性能瓶頸，重點介紹性能方面的優化，并在性能上與開源Redis和友商競品做對比。

一、CKV的架構演進

CKV作為公司有歷史的分布式內存系統，下面羅列了一些重要的發展經歷。

• 2009年TMEM(tencent memcached)作為高并發內存級存儲解決方案上線，支撐了當時的QZone/朋友網等業務。

• 2011年更名為CMEM(cloud memcached)，開始向云計算靠攏并為海量的第三方游戲用戶提供了解決方案，比如偷菜，搶車位等。

• 2012年隨著業務規模的增加，內存的高成本成為了核心問題，通過引入冷數據存儲介質降低了業務的使用成本。

• 2014年CKV支持了微信紅包業務。

• 2017年基于seastar框架開發的CKV上線，兼容了REDIS協議，進一步提升了性能。

1.1 CMEM架構

1.1.1 架構總覽

CMem的模塊眾多，按照模塊功能分為核心模塊和外圍模塊。

核心模塊采用的是傳統的三層架構，包括接入、存儲和元數據(master)模塊三部分。元數據(master)模塊負責管理路由等元數據，元數據是本地文件存儲，無備份節點。業務直接訪問的是接入模塊，接入模塊會根據路由轉發到后端的存儲模塊。

外圍模塊包括備份、搬遷、統計、探測、恢復等模塊。

CMem對業務數據通過Presharding的方式進行分片，將所有數據按照 hash(key) % 10000的方式邏輯上分成10000個Slot，每個Slot會對應存儲節點的一對主備分片，存儲端采用主備的方式來容災。

1.1.2 架構優缺點

優點

底層數據存儲采用共享內存，在進程異常的時候可以快速恢復。引擎設計上對于用戶數據長度比較一致的業務上，可以充分利用內存。

支持開源memcached協議，可以直接用memcached客戶端訪問。

搬遷對用戶影響很小，只影響搬遷中的刪除操作。

多租戶方式，可以充分利用資源。

缺點

模塊較多，出現異常定位問題鏈路較長。

存儲模型采用整機主備的設計，一個機器都是主，一個機器都是備，造成主機壓力較大，而備機相對比較閑，而且只支持一主一備。

主備同步用的rsync進程，是單進程單線程模型。在訪問量較大的場景下，容易成為瓶頸。

引擎設計對于隨機用戶數據長度上不太友好。

存儲模塊采用多進程加鎖的方式，不能充分利用資源。進程太少，能夠利用的CPU就少，進程太多，鎖的開銷就增大。

元數據管理模塊采用的本地存儲，并且是單點。元數據推送采用全量推送，效率較低。

1.2 CKV架構

1.2.1 架構總覽

上圖中灰色部分是從CMem的架構中移除的模塊，只保留了一些必要的模塊（藍色部分）。從功能上也分為核心和外圍模塊。

核心模塊采用的是二層架構，包括存儲和元數據管理兩個模塊。元數據是保存在本地的ETCD服務中，采用ETCD服務于元數據服務1對1模式，至少是三分數據，提升了元數據的可靠性。

存儲模塊兼顧接入的能力，業務直接訪問存儲模塊，如果根據路由計算出是本機處理就直接處理，非本機請求就轉發到目標節點處理。

外圍模塊主要包括備份和OSS。備份負責數據的冷備與恢復，OSS負責管理整個集群，包括實例的創建/刪除/備份/擴縮容等。

1.2.2 核心架構

CKV從設計上為了適應新型的多CPU大內存機型，采用多租戶方式，底層引擎采用共享內存，為了兼容REDIS協議，設計支持了string/list/hash/set/zset等數據結構。

存儲節點采用單進程多線程模型，實際存儲分片按需分配，一個節點上盡量保證主備數量均衡，同時存儲兼有轉發的能力，也支持獨立部署接入層的能力。

元數據管理上基于ETCD保證元數據的可靠性，路由設計上采用增量推送的方式，提高了路由更新的效率。數據模型上跟CMem類似，采用Presharding，hash(key) % 16384，Slot數從10000增加到了16384，跟Redis保持一致，并且支持一主多備。

1.2.3 線程模型

CKV的Cache作為核心的存儲模塊，在設計的時候，性能是我們最看重的，同時為了充分利用當前多CPU大內存的機型資源，我們基于Seastar這個高性能網絡通信框架來開發。

http://seastar.io/

Seastar是一個面向現代硬件多核架構的高性能異步網絡框架，它是KVM作者Avi Kivity領銜開發的開源項目。Seastar采用Share-nothing架構、全異步編程、用戶態任務調度器、支持內核協議棧和用戶態協議棧、獨立的內存管理等提供了極致的性能。

Cache的設計采用對等模式，每個CPU可以理解為一個線程，所有線程的功能可以認為是一樣的，不區分IO線程和worker線程。

CKV的最小存儲單元是分片，每個分片是獨立的共享內存，采用按需分配的方式。CKV存儲訪問采用無鎖設計，每個分片只會由一個CPU來管理，這樣訪問就不需要加鎖。

在上圖中可以看到，一共有四個線程，其中第一個線程管理兩個分片，第二個線程管理三個分片，后面兩個線程分別只管理一個分片。

每個線程接收到請求之后，會根據路由計算是不是當前線程處理，如果不是的話，會轉發到其他線程來執行請求。

同時每個線程都可以處理網絡IO，一旦接受到數據包，在當前核完成編解碼的工作，然后會根據路由將請求轉發到指定的線程或者其他節點運行。這樣就把網絡IO和編解碼的工作分攤到所有線程，可以充分利用CPU資源。

Cache上大部分操作都是基于future/promise實現的異步，包括邏輯處理、網絡IO和磁盤IO等，只有底層存儲引擎是同步操作。這樣的好處是所有的IO不需要等待，可以讓出CPU，提高吞吐量。

2、性能瓶頸及分析

2.1 性能數據

基于Seastar框架開發的CKV整機測試性能數據。

2.2 CKV性能分析

前面已經給出了CKV的性能數據，雖然相對CMem來說，性能提升了不少，為了進一步提高性能，我們對于整機場景了做了性能分析。

從火焰圖上看沒有明顯的集中，CPU主要消耗是

seastar::reactor::run_tasks 和 seastar::reactor:poll_once。

其中run_tasks負責執行命令以及網絡收包，而poll_once主要是負責網絡包的發送。

然后通過mpstat分析CPU消耗。

上圖中，第2列是CPU，第3列是%usr 用戶態占比，第5列是%sys 內核態占比，第8列是%si 軟中斷占比。可以看出軟中斷已經消耗了30%的CPU。

這里的軟中斷主要是網卡收包導致的。網卡收到網絡包后，會通過硬件中斷通知內核有新的數據到了，內核會調用對應的中斷處理程序來響應該事件，先將網卡的數據讀到內存中，然后更新硬件寄存器的狀態，

然后內核會觸發一個軟中斷，需要從內存中找到網絡數據，再按照網絡協議棧，對數據逐層解析和處理，最后將數據給到應用程序。

2.3 REDIS性能分析

在同樣的硬件條件下，測試機器包含72個物理核，在機器上啟動了72個redis實例，然后對72個實例進行了整機壓測。perf統計如下

從上圖可以看出，redis的CPU消耗主要是網絡收發包。通過mpstat查看CPU消耗。

從上圖可以看出，CPU消耗主要集中也是在軟中斷。在整機測試的場景下可以看出網絡成為了性能的瓶頸。

在整機大壓力訪問場景中，無論是CKV還是REDIS，最終性能瓶頸都在網絡上，因此傳統的內核協議棧不能能充分利用最新硬件的能力，DPDK通過用戶態協議棧則可以解決這個問題。

3、DPDK

DPDK全稱Intel Data Plane Development Kit，是intel提供的數據平面開發工具集，是一個用來進行包數據處理加速的軟件庫。DPDK專注于網絡應用中數據包的高性能處理，具體體現在DPDK應用程序是運行在用戶態上利用自身提供的數據平面庫來收發數據包，繞過了Linux內核協議棧對數據包處理過程。

DPDK通過UIO、poll-mode網卡驅動、內存池、大頁內存管理、無鎖數據結構等數據手段來提升性能。

3.1 初始化SEASTAR

1.seastar初始化的時候，先在cpu 0調用smp::configure 初始化配置。

2.在cpu 0調用rte_eal_init 初始化DPDK的EAL。

3.通過rte_eal_remote_launch 在非0 cpu上調用reactor::configure 初始化引擎，在初始化引擎的時候會根據用戶配置初始化協議棧

4.等待其他核初始化完成后，在cpu 0上初始化引擎和協議棧。完成框架的初始化。

3.2 初始化協議棧(DPDK)

協議棧的初始化分成三大步。其中上圖中設置成橙色的 設置隔離模式 和 設置流規則 是CKV增加的。

1.網卡初始化。首先通過rte_eth_dev_info_get 獲取網卡信息，然后通過rte_flow_isolate設置網卡成隔離模式，最后調用rte_eth_dev_configure 配置網卡

2.隊列初始化。通過調用rte_eth_rx_queue_setup 和 rte_eth_tx_queue_setup 分別初始化入隊列和出隊列。然后會輪詢 rte_eth_rx_burst 和 rte_eth_tx_burst分別處理收包和發包。

3.網卡啟動。先調用rte_eth_dev_start啟動網卡，然后調用rte_flow_create設置流規則，最后調用rte_eth_link_get_nowait檢查網卡是否正確啟動。

3.3 數據包處理

在前面隊列初始化完成后，我們會輪詢RX和TX兩個方向上的包。RX代表接受數據，TX代表傳輸數據。具體是通過注冊一個poller不停的輪詢處理。

• RX注冊的是 reactor::poller::simple([&] { return poll_rx_once(); })

• TX注冊的是 reactor::poller::simple([this] { return poll_tx(); }))

對于Server端，首先會通過RSS(Receive-Side Scaling, also known as multi-queue receive) 將包分發給指定的隊列。將不同的流分發給不同的CPU，同一個流始終會在同一個CPU上，避免TCP的順序和CPU的并行發生沖突。

在協議棧實現中，在二三層都有RX方向的rx_stream，高層會調用低層stream的listen方法，注冊包處理的回調函數，從dpdk_qp收到包，會將包從dpdk的rte_mbuf轉化成packet格式，然后往上交給L2的stream，再往上交給L3的stream。

包傳遞到二三層是通過stream/subscription的回調方式，送到四層直接調用l4→receive方法直接處理。

目前Seastar的用戶態協議棧已經支持了ARP、DHCP、ICMP、IP、TCP、UDP協議。四層主要是TCP/UDP層，我們重點分析TCP層。協議棧抽象了TCB對應內核協議棧的連接概念。每一個TCP連接對應一個TCB對象。當數據從三層傳遞給TCP層的時候，根據IP/PORT四元組可以找到對應的TCB，然后會將數據保存到TCB的接受隊列里。

上層的應用通過調用READ訪問從TCB的接受隊列讀取數據，這里協議棧的實現為了zero-copy，單次讀取是一個packet，我們優化成批量讀取，單個連接的通信速度整體提升了一倍，從100MB/s提高到200MB/s.

發送數據通過上層調用WRITE方法，首先將數據保存到對應TCB的unsent隊列，在發送的時候會將數據先放到packetq的循環buffer，發送成功后然后再保存到發送的data隊列里，等到對端ACK后才會將發送隊列data的數據刪除。

3.4 隔離模式和流規則

DPDK的應用程序默認需要接管網卡，一旦程序運行，網卡的所有數據都通過DPDK處理，比如常見的SSH登錄可能就會失敗，還有一些其他公司的Agent探測和上報都會失效。

對于這個問題我們通過DPDK提供的isolate模式來解決，也就是上文提到的設置隔離模式。isolate模式是指所有通過DPDK的數據默認還是走內核協議棧，然后通過配置一些流規則，可以將指定的流指向DPDK。

4、性能數據

單分片六核

對比結果可見，CKV寫性能比Tair高60%，讀性能與Tair基本一致，value比較大時性能略低于Tair，是CKV未來優化方向。

六分片六核

在六分片六核場景下，基于DPDK的CKV相對內核協議棧CKV，整體提升明顯，提升了100%左右。

整機

從測試結果看，CKV在引入DPDK后，通過DPDK代替了內核協議棧，優化了網絡收發包的性能瓶頸，達到了單機千萬的QPS。

總結

我們從性能方面對CKV做了一系列優化。引入DPDK，通過優化網絡瓶頸，將整機性能提升到千萬QPS。目前適配部分網卡，后續會適配更多類型的網卡。

在壓測的過程中,基于DPDK的原生協議棧在單個連接上收發包目前只能達到250MB/s的傳輸速度，對于CKV目前來說是可以應對絕大部分場景，但是還需要持續地優化提升單個連接上的傳輸性能。

未來CKV會持續優化迭代，成本上會采用全類型數據下沉到SSD介質，進一步降低成本，性能上面會持續優化原生協議棧，持續挖掘性能。

- END -

---

看完一鍵三連在看，轉發，點贊

是對文章最大的贊賞，極客重生感謝你

推薦閱讀

我們究竟為誰打工?

大廠后臺開發基本功修煉路線和經典資料

如何從0搭建公司的后端技術棧

你好，這里是極客重生，我是阿榮，大家都叫我榮哥，從華為->外企->到互聯網大廠，目前是大廠資深工程師，多次獲得五星員工，多年職場經驗，技術扎實，專業后端開發和后臺架構設計，熱愛底層技術，豐富的實戰經驗，分享技術的本質原理，希望幫助更多人蛻變重生，拿BAT大廠offer，培養高級工程師能力，成為技術專家，實現高薪夢想，期待你的關注！點擊藍字查看我的成長之路。

校招/社招/簡歷/面試技巧/大廠技術棧分析/后端開發進階/優秀開源項目/直播分享/技術視野/實戰高手等,?極客星球希望成為最有技術價值星球，盡最大努力為星球的同學提供技術和成長幫助！詳情查看->極客星球

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 求點贊，在看，分享三連

總結

以上是生活随笔為你收集整理的深入理解缓存系统|单机QPS突破千万优化之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。