[導(dǎo)讀]導(dǎo)讀：近年來，云原生化、全用戶態(tài)、軟硬協(xié)同等技術(shù)對KV存儲服務(wù)產(chǎn)生了巨大的影響，上述技術(shù)在極大提升了服務(wù)的性能和降低服務(wù)成本的同時，也對系統(tǒng)的架構(gòu)和實現(xiàn)提出了新的要求。百度在信息流和搜索業(yè)務(wù)中大量使用了KV存儲服務(wù)，服務(wù)每天響應(yīng)近千億次各類訪問請求，如何運用上述技術(shù)提升系統(tǒng)的性能...

導(dǎo)讀：近年來，云原生化、全用戶態(tài)、軟硬協(xié)同等技術(shù)對KV存儲服務(wù)產(chǎn)生了巨大的影響，上述技術(shù)在極大提升了服務(wù)的性能和降低服務(wù)成本的同時，也對系統(tǒng)的架構(gòu)和實現(xiàn)提出了新的要求。百度在信息流和搜索業(yè)務(wù)中大量使用了KV存儲服務(wù)，服務(wù)每天響應(yīng)近千億次各類訪問請求，如何運用上述技術(shù)提升系統(tǒng)的性能、穩(wěn)定性和運維人效是我們重點考慮的問題。本文通過介紹我們應(yīng)用上述技術(shù)打造高性能KV存儲系統(tǒng)的實踐過程，為大家分享了我們在單機性能優(yōu)化，大規(guī)模集群設(shè)計、管理等方面的思路和實踐經(jīng)驗。
全文7854字，預(yù)計閱讀時間21分鐘。

自2016年起，百度進入『搜索信息流』雙引擎驅(qū)動構(gòu)建內(nèi)容生態(tài)的“信息分發(fā)2.0時代”，搜索、推薦的內(nèi)容也不再局限于網(wǎng)頁，而是引入越來越多的視頻、圖片、音頻等多媒體資源。KV存儲作為在搜索和推薦中臺中被廣泛使用的在線存儲服務(wù)，更是受到了存儲規(guī)模和訪問流量的雙重考驗。

至2018年初，我們投入各類KV存儲服務(wù)的服務(wù)器數(shù)量便超過萬臺，數(shù)據(jù)規(guī)模超過百PB，承接了每天近千億次的各類訪問請求。集群規(guī)模的增長除了資源成本的提升，還加劇了運維管理的難度。作為有狀態(tài)服務(wù)，集群的故障機處理、服務(wù)器升級、資源擴縮容都需要專人跟進，運維人力隨集群規(guī)模呈正比增長。彼時又逢推薦業(yè)務(wù)完成了微服務(wù)化改造，業(yè)務(wù)資源交付和上線都能當天完成，存儲資源動輒周級的交付能力也成了業(yè)務(wù)上線效率的瓶頸。

這些都促使我們對原來的系統(tǒng)架構(gòu)進行徹底升級，通過提升單機引擎性能和云原生化有效降低資源成本和運維人力成本。同時我們還要滿足業(yè)務(wù)對服務(wù)的敏捷性要求，通過云基礎(chǔ)設(shè)施提供的資源編排能力，使系統(tǒng)具備小時級服務(wù)交付能力。

一、問題與挑戰(zhàn)

1）性能挑戰(zhàn)

單機引擎性能是KV系統(tǒng)的關(guān)鍵指標，一般我們通過讀寫性能（OPS、延時（latency））和空間利用率來衡量引擎的性能，由于當前引擎架構(gòu)和存儲設(shè)備硬件性能的制約，我們在引擎中往往只能選擇讀性能、寫性能和空間利用率中某個方向進行重點優(yōu)化，比如犧牲空間利用率提升寫吞吐，或者犧牲寫吞吐、提升空間利用率和讀吞吐。

這類優(yōu)化對于業(yè)務(wù)單一的場景比較有效，之前我們的系統(tǒng)就針對大業(yè)務(wù)場景進行逐一調(diào)參優(yōu)化，針對其他業(yè)務(wù)則使用讀寫性能和空間利用率均衡的『均衡型』引擎接入。

但是百度的信息流和搜索業(yè)務(wù)規(guī)模都非常龐大、業(yè)務(wù)場景極其復(fù)雜，我們接入的數(shù)千個業(yè)務(wù)中有每天更新PB級數(shù)據(jù)的業(yè)務(wù)，也有讀寫比超過100:1的業(yè)務(wù)，還有要求強一致性、存儲規(guī)模數(shù)十PB的業(yè)務(wù)，不少業(yè)務(wù)還會體現(xiàn)出潮汐特性，全天流量都集中在某個特定時段。

因此我們通過引擎優(yōu)化，既要解決如何在降低讀寫放大的同時，盡可能平衡空間放大的問題；又要在引擎內(nèi)實現(xiàn)自適應(yīng)機制，解決業(yè)務(wù)充分混布場景下，吞吐模式多變的問題。

2）云原生化挑戰(zhàn)

云原生架構(gòu)的主要價值在于效率的提升，包括資源利用效率和研發(fā)效率兩個方面。

百度信息流和搜索業(yè)務(wù)對其業(yè)務(wù)模塊制定了統(tǒng)一的云原生化標準：

微服務(wù)化：每個服務(wù)粒度應(yīng)該在限定的范圍內(nèi)。
容器化封裝：一個服務(wù)的部署，應(yīng)該只依賴基礎(chǔ)架構(gòu)以及本容器內(nèi)的組件，而不應(yīng)該依賴其他業(yè)務(wù)服務(wù)。
動態(tài)管理：每個服務(wù)應(yīng)該可以動態(tài)調(diào)整部署，而不影響自身對外承諾的SLA。

KV服務(wù)在對齊上述標準的過程中，主要難點在于容器化改造和動態(tài)管理兩個方面。

容器化改造方面，單機時代的KV服務(wù)以用滿整機資源為目標，對內(nèi)存資源和存儲介質(zhì)IO的使用往往不加任何限制。引擎的容器化改造，要求我們精細化控制對上述資源的使用：

內(nèi)存資源：存儲引擎除了顯式使用系統(tǒng)內(nèi)存，更多的是對page cache的使用，文件系統(tǒng)中諸如Buffered I/O和文件預(yù)讀都會產(chǎn)生page cache。我們需要在引擎中對其加以控制，避免超過容器配額觸發(fā)硬限。
存儲介質(zhì)I/O：KV服務(wù)的主要介質(zhì)是SSD，我們不少業(yè)務(wù)也需要使用SSD提升讀寫性能，這些業(yè)務(wù)本身往往只需要不到100GB，因此為了提升SSD的使用率，KV服務(wù)需要和這些業(yè)務(wù)進行混布。這也要求我們不但能有效利用SSD I/O，還要能對I/O加以控制，避免影響混布業(yè)務(wù)。

動態(tài)管理則要求業(yè)務(wù)具有一定的容錯能力和彈性伸縮能力，由于KV是典型的有狀態(tài)服務(wù)，兼具了數(shù)據(jù)持久化、多分片、多副本等特點，我們在動態(tài)管理中需要關(guān)注：

服務(wù)可用性：與無狀態(tài)服務(wù)不同，多分片服務(wù)不能看服務(wù)的整體可用性，而要確保每個分片都可用。比如一個服務(wù)有10個分片，每個分片有3個容器，服務(wù)整體可用度為90%。從無狀態(tài)服務(wù)視角2個容器故障不會影響服務(wù)可用性，但是從KV服務(wù)視角，如果這兩個容器正好服務(wù)同一個分片的兩個數(shù)據(jù)副本，那么該服務(wù)就會出現(xiàn)數(shù)據(jù)不可用問題。因此服務(wù)在持續(xù)部署時，需要確保每個數(shù)據(jù)分片的可用性。
數(shù)據(jù)可靠性：云原生化后為了提升資源利用率，在線數(shù)據(jù)遷移和動態(tài)伸縮頻率將遠高于物理機時代，數(shù)據(jù)的動態(tài)伸縮過程需要對業(yè)務(wù)透明，也不能出現(xiàn)數(shù)據(jù)丟失或一致性問題。
管理效率：確保管理服務(wù)能即時響應(yīng)管理操作，對系統(tǒng)的穩(wěn)定性起著關(guān)鍵作用。隨著集群規(guī)模的增加，并發(fā)的管理操作數(shù)量也會增加，如果響應(yīng)操作的時間也逐漸增加，最終將導(dǎo)致系統(tǒng)雪崩，因此我們需要系統(tǒng)響應(yīng)管理操作的能力也能水平伸縮。
部署效率：KV服務(wù)的部署包括部署應(yīng)用和完成數(shù)據(jù)遷移，因此我們不但要在功能上做到可遷移，還要確保數(shù)據(jù)遷移的效率。比如一個有100個實例的服務(wù)，如果遷移一個實例要12個小時，且每輪只允許遷移1個實例，遇到內(nèi)核升級、操作系統(tǒng)升級等需要重啟的操作，全服務(wù)遷移一輪就需要1個半月，這樣的效率還不如人工操作。這樣的服務(wù)就不能算支持動態(tài)管理，因為沒有在線操作可以容忍這樣低的遷移效率。

3）滿足業(yè)務(wù)的特化需求

之前也提到百度的信息流和搜索業(yè)務(wù)規(guī)模都非常龐大，一些大業(yè)務(wù)根據(jù)自身場景已經(jīng)做了單機引擎的特化，有些特化還涉及修改linux內(nèi)核，通用引擎在性能上無法超越這些特化引擎，這就要求能從業(yè)務(wù)中提取共性，同時允許其保留特性，使業(yè)務(wù)團隊能在資源利用效率和研發(fā)效率兩個方面都獲得收益。

為此我們提出了UNDB - NoSQL聯(lián)合存儲系統(tǒng)（United NoSQL Database）的概念，兼顧統(tǒng)一通用能力與保持業(yè)務(wù)特性：

統(tǒng)一框架：使用統(tǒng)一的云原生存儲框架，打平各系統(tǒng)的運維、集群管理差異，同時打破原有的資源屏障。
通用接口：各KV服務(wù)剝離業(yè)務(wù)協(xié)議，對齊基本KV接口協(xié)議，對用戶提供基于基本KV接口封裝的SDK，使業(yè)務(wù)可以在各服務(wù)間平滑遷移，降低學(xué)習(xí)成本。
通用引擎：自研高性能通用KV引擎，便于其他NoSQL服務(wù)在此之上實現(xiàn)高性能的存儲服務(wù)。
分層可插拔架構(gòu)：通過可插拔的接口層、數(shù)據(jù)模型層、數(shù)據(jù)同步層、引擎層設(shè)計，使接入系統(tǒng)能快速實現(xiàn)業(yè)務(wù)特性化差異。

二、引擎優(yōu)化

引擎是KV系統(tǒng)的核心組件，鑒于RocksDB在開源社區(qū)和工業(yè)界的廣泛應(yīng)用，我們一開始便直接使用RocksDB作為單機引擎?；贚SM-Tree實現(xiàn)，RocksDB在HDD介質(zhì)上有良好的性能，但在SSD介質(zhì)上的性能表現(xiàn)卻并不出眾，主要問題在于：

RocksDB在設(shè)計實現(xiàn)中,為了避免隨機I/O，增加了大量順序I/O開銷（讀放大、寫放大），而SSD介質(zhì)的隨機I/O尤其是隨機讀性能和順序I/O差距不大，因此針對HDD介質(zhì)的優(yōu)化在SSD介質(zhì)中反而造成了讀寫帶寬浪費。
上述額外的I/O開銷所產(chǎn)生的高寫放大，還增加了SSD介質(zhì)的壽命損耗，在高吞吐環(huán)境中，新盤的平均使用壽命不足2年。
LSM-Tree結(jié)構(gòu)對業(yè)務(wù)數(shù)據(jù)長度也十分敏感，由于每層SST文件大小是固定的，數(shù)據(jù)長度越大，越容易觸發(fā)Compaction，從而造成寫放大；同時數(shù)據(jù)長度越大，每層SST文件能記錄的數(shù)據(jù)條目數(shù)就越少，讀請求向下層訪問概率就越高，從而造成了讀放大。

我們業(yè)務(wù)場景中的value一般在KB ~ 百KB級別，為了降低LSM-Tree的寫放大，我們在RocksDB基礎(chǔ)上實現(xiàn)了Key-Value分離的單機存儲引擎，如下圖左側(cè)引擎結(jié)構(gòu)所示：

圖1：普通引擎與基于OpenChannel SSD的軟硬協(xié)同引擎的架構(gòu)對比

在RocksDB中存儲Key和Value的地址索引(BlockID Offset)，RocksDB的Compaction只影響到索引，不會引起Value的變動。
Value單獨持久化，我們稱之Data Block文件，Data Block文件單獨進行Compaction。

為了進一部提升引擎的I/O效率，我們又對Compaction策略和壓縮方式進行了優(yōu)化：

自適應(yīng)Compaction機制：綜合引擎I/O和剩余存儲空間，調(diào)節(jié)對Block文件空洞率的選擇閾值，實現(xiàn)流量規(guī)避、動態(tài)調(diào)節(jié)空間放大能力。
冷熱分層：減少冷熱混合導(dǎo)致的不必要Compaction，并選擇流量空閑時段對冷數(shù)據(jù)進行Compaction，降低觸發(fā)SSD靜態(tài)磨損均衡頻率。
全局壓縮：在Block File粒度支持了zstd-dict壓縮方式，進一步提升了Block文件的壓縮率。

此外，我們在引擎中為同步框架封裝了Log View，實現(xiàn)數(shù)據(jù)同步與引擎復(fù)用，WAL降低了數(shù)據(jù)同步造成的寫放大。

通過上述優(yōu)化，在軟件層面，我們在空間放大＜1.6x的情況下，將寫放大控制到了＜ 1.5x。在業(yè)務(wù)持續(xù)以30MB/s更新數(shù)據(jù)的場景下，單盤壽命由之前的半年內(nèi)提升至3年左右。

但是，SSD的寫放大并不限于軟件層，物理特性決定其不支持覆蓋寫，只能先擦除舊數(shù)據(jù)再寫入新數(shù)據(jù)，大部分SSD按4KB（Page）寫入、按256KB ~ 4MB（Block）擦除數(shù)據(jù)。SSD在擦除一個Block時，需要遷移Block中仍然有效的Page，這個遷移動作導(dǎo)致了SSD硬件層的寫放大，硬件層寫放大又與SSD剩余空間密切相關(guān)，一般情況下，當SSD容量使用達90%時，寫放大會超過3.5x。

細心的同學(xué)或許會發(fā)現(xiàn)，我們之前在計算SSD壽命時并沒有提到這部分放大，這里其實包含了SSD廠商的優(yōu)化：SSD介質(zhì)的實際容量單位是GiB（Gibibyte），1GiB = 2³⁰bit，提供給用戶的指標則是GB（Gigabyte），1GB = 10⁹ bit，前者比后者多了7.374%的空間，被廠商用作了內(nèi)部操作空間。加之我們在實際使用時，也會保持磁盤用量不超過80%，因此可以控制寫放大。但是這些策略其實犧牲了SSD的容量。

為了進一步發(fā)掘設(shè)備潛能，我們和百度的基礎(chǔ)架構(gòu)部門合作，基于Open Channel SSD實現(xiàn)了一款軟硬協(xié)同設(shè)計的引擎，如上圖右側(cè)引擎結(jié)構(gòu)所示與傳統(tǒng)用法相比：

實現(xiàn)了全用戶態(tài)I/O操作，降低了引擎讀寫延遲；?
引擎直接管理Flash物理地址，避免了文件系統(tǒng)、LBA、PBA三層映射造成的性能損失和空間浪費；
將FTL中Wear Leveling、GC、PLP、Error Handling上移至引擎，和KV原有的Compaction，Crash Recovery邏輯合并，合并了軟、硬兩層操作空間。

軟硬協(xié)同引擎在性能上超過軟件引擎＞ 30%，軟硬整體放大率＜ 1.1x。

圖2：引擎性能對比，依次為：數(shù)據(jù)加載性能、讀寫吞吐（讀寫1：1）、99分位寫延時、99分位讀延時

上圖是我們實現(xiàn)的KV分離引擎（Quantum）、軟硬協(xié)同引擎（kvnvme）和開源Rocksdb在數(shù)據(jù)加載、隨機讀寫場景下的性能對比。

測試中我們選用：NVME 1TB SSD（硬件指標：4KB隨機寫7萬IOPS，隨機讀46.5萬IOPS）。數(shù)據(jù)集選用：1KB、4KB、16KB和32KB共4組，每組數(shù)據(jù)集都隨機預(yù)構(gòu)建320GB初始數(shù)據(jù)，再采用齊夫分布（Zipf）進行讀寫測試，讀寫測試時保持讀寫比為1：1。

Value Size	key數(shù)量	原始數(shù)據(jù)集
1KB	3.2億	320GB
4KB	8千萬	320GB
16KB	2千萬	320GB
32KB	4千萬	320GB

從測試結(jié)果可以發(fā)現(xiàn)：

Value越大，KV分離引擎和軟硬協(xié)同引擎的讀寫優(yōu)勢就越為明顯，在32KB時軟硬協(xié)同引擎的吞吐是RocksDB的近5x。
軟硬協(xié)同引擎在讀寫延時控制上，尤其是寫延時控制上也明顯優(yōu)于其他引擎。

三、云原生實踐

上節(jié)中我們通過引擎優(yōu)化重構(gòu)解決了業(yè)務(wù)混布性能和容器化問題，這節(jié)將介紹一下我們是如何解決動態(tài)管理問題。

UNDB服務(wù)整體框架如下圖所示：

圖3：UNDB系統(tǒng)框架

架構(gòu)上我們將服務(wù)分成了Operator（數(shù)據(jù)調(diào)度）、控制面和數(shù)據(jù)面三部分：

Operator：負責(zé)向PaaS傳遞控制面和數(shù)據(jù)面中所有容器的狀態(tài)信息和進行用戶數(shù)據(jù)調(diào)度
控制面：包括元信息服務(wù)、集群控制服務(wù)、接入管理服務(wù)、路由服務(wù)和用戶數(shù)據(jù)中心，負責(zé)管理一個IDC（Internet Data Center）中的所有存儲集群（Store Clusters）和用戶發(fā)現(xiàn)、接入存儲集群的路由映射關(guān)系，不同IDC間部署不同的控制面服務(wù)。
數(shù)據(jù)面：IDC中KV服務(wù)管理的所有存儲集群的集合。存儲集群按存儲設(shè)備類型（比如：NVMe SSD、SATA SSD、OpenChannel SSD、HDD、……），存儲機制的容量，引擎類型，以及引擎使用的CPU、內(nèi)存資源數(shù)量進行劃分。

我們在系統(tǒng)設(shè)計、實現(xiàn)中主要考慮如何實現(xiàn)數(shù)據(jù)全局調(diào)度能力和海量存儲實例的動態(tài)管理能力。

3.1 數(shù)據(jù)全局調(diào)度能力

數(shù)據(jù)全局調(diào)度指：

用戶數(shù)據(jù)可以在數(shù)據(jù)面中的不同存儲集群間任意遷移、擴縮容。
用戶數(shù)據(jù)可以在不同數(shù)據(jù)中心間任意遷移、復(fù)制。

這種能力的意義在于：

當業(yè)務(wù)形態(tài)、引擎技術(shù)和存儲設(shè)備發(fā)生變化時，我們能用對業(yè)務(wù)無感的方法將數(shù)據(jù)遷移到合適的集群中。
當部門新建數(shù)據(jù)中心，業(yè)務(wù)新增、切換數(shù)據(jù)中心，或是數(shù)據(jù)中心數(shù)據(jù)恢復(fù)時，我們能以最低的運維成本實施數(shù)據(jù)遷移、恢復(fù)。

圖4：Table在UNDB集群間遷移示意

如上圖（圖4）所示，全局調(diào)度由Operator發(fā)起，通過控制面協(xié)調(diào)數(shù)據(jù)面中的存儲實例完成操作，其中：

元信息服務(wù)和集群控制服務(wù)，為Operator對用戶數(shù)據(jù)進行全局調(diào)度從底層機制上提供了無損遷移和無損伸縮能力。
數(shù)據(jù)中心：通過分析存儲集群的流量、容量分布和業(yè)務(wù)數(shù)據(jù)的流量、容量增長趨勢，向Operator提供了全局調(diào)度方案。
Operator：基于K8S Operator框架實現(xiàn)，通過聲明式原語，引導(dǎo)控制面完成數(shù)據(jù)遷移。

基于上述能力，我們除了支持即時集群容量均衡和即時業(yè)務(wù)容量調(diào)整，還實現(xiàn)了周級機房建設(shè)、搬遷。

3.2?海量存儲實例的動態(tài)管理能力

之前提到我們在動態(tài)管理中需要關(guān)注服務(wù)可用性、數(shù)據(jù)可靠性、管理效率和部署效率，上節(jié)中我們通過引擎優(yōu)化實現(xiàn)了小時級完成TB數(shù)據(jù)的遷移、恢復(fù)。這里我們將關(guān)注如何在動態(tài)管理中確保服務(wù)的可用性、數(shù)據(jù)可靠性和管理效率。

業(yè)務(wù)訪問KV服務(wù)的過程可以簡單概括為：

業(yè)務(wù)通過路由發(fā)現(xiàn)數(shù)據(jù)所在的存儲節(jié)點。
訪問存儲節(jié)點獲取數(shù)據(jù)。
數(shù)據(jù)和存儲節(jié)點映射關(guān)系發(fā)生變更時，通知業(yè)務(wù)更新路由。

我們在數(shù)據(jù)面中：

按3-2-1原則確保數(shù)據(jù)安全。
使用Multi-Raft確保數(shù)據(jù)一致性。
采用多地多活確保重要業(yè)務(wù)的可用性。

由于數(shù)據(jù)中心間的元信息不盡相同，尤其是拓撲信息完全不同，且拓撲信息具有極強的時效性，冷備效果并不好，因此對于控制面我們采用了利用數(shù)據(jù)面，集群控制服務(wù)多級兜底的思路，如下圖（圖5）所示：

冷備機制：對于低頻更新的元信息，諸如業(yè)務(wù)數(shù)據(jù)屬性、配額實時備份SQL數(shù)據(jù)庫。
反向恢復(fù)機制：利用集群控制服務(wù)和存儲集群都有拓撲鏡像的特點，支持通過上述服務(wù)反向恢復(fù)拓撲信息。
異變攔截機制：在控制面、數(shù)據(jù)面及業(yè)務(wù)端（Client）攔截異常變更，避免拓撲異常時，服務(wù)迅速異常雪崩。

圖5：元信息多級攔截、反向恢復(fù)

另外我們還通過獨立的路由服務(wù)向業(yè)務(wù)屏蔽了元信息服務(wù)，業(yè)務(wù)間通過多組路由服務(wù)進行物理隔離。并通過接入管理服務(wù)管理業(yè)務(wù)和路由服務(wù)間的映射關(guān)系，這樣可以有效防止由于某個業(yè)務(wù)的異常訪問（比如：連接泄露）影響其他業(yè)務(wù)的路由訪問。

在提升管理效率方面，我們主要采用了元信息和集群控制分離的設(shè)計，由于元信息服務(wù)需要確保節(jié)點間數(shù)據(jù)一致性，我們的數(shù)據(jù)修改操作只能在Leader節(jié)點上進行，如果不采用分離設(shè)計，所有控制操作只有Leader節(jié)點才能進行，當集群規(guī)模和數(shù)量增加后，無法通過水平擴容節(jié)點增加控制面算力，因此我們選用了兩種模塊分離的方法，使控制面具備水平伸縮控制算力的能力以應(yīng)對超大規(guī)模集群。

四、多模型存儲架構(gòu)

NoSQL概念發(fā)展至今，業(yè)界已經(jīng)出現(xiàn)了數(shù)百種不同的開源和商業(yè)NoSQL數(shù)據(jù)庫，當業(yè)務(wù)發(fā)展到一定程度，對標準數(shù)據(jù)庫進行改造，使其更適合業(yè)務(wù)模型的需求也變得越來越普遍。因此我們在整合KV系統(tǒng)時，提出了整合通用功能保留業(yè)務(wù)特性的設(shè)計思路。在這個思路指導(dǎo)下，我們統(tǒng)一了控制面，用于實現(xiàn)統(tǒng)一的運維管理，數(shù)據(jù)面則分成了3個功能模塊、6個分層向業(yè)務(wù)開放了對服務(wù)接口、數(shù)據(jù)模型、存儲模式、以及對同步框架的定制化能力，如下圖所示：

圖6：UNDB多模型存儲架構(gòu)

DbProxy模塊：整個架構(gòu)的第一層，是一個獨立部署的模塊，DBProxy是對所有代理存儲節(jié)點（Store Node）的Proxy服務(wù)的總稱，按功能不同還有諸如KvProxy，GraphProxy等，該模塊主要用于：

分擔(dān)存儲節(jié)點（Store Node）訪問壓力：當業(yè)務(wù)存在大量的Fanout讀，或離線任務(wù)（map reduce任務(wù)）存在大量寫連接時，通過proxy可以減少對存儲節(jié)點的壓力;
減少上下游連接開銷：主要用于超大規(guī)模業(yè)務(wù)，比如搜索業(yè)務(wù)的一張索引表就分布在上萬個實例中，這也意味訪問該表的每個下游都要維護上萬個連接，因此需要通過proxy減少客戶端的連接開銷。
存算分離：當前通過NVMe-OF、RDMA技術(shù)網(wǎng)絡(luò)已經(jīng)不是系統(tǒng)的主要瓶頸，像圖數(shù)據(jù)庫這樣的服務(wù)，一次請求需要訪問多個存儲節(jié)點才能完成，還需要通過本地緩存構(gòu)建子圖加速業(yè)務(wù)查詢速度，整合在存儲節(jié)點中幾乎無法帶來的性能收益，還容易出現(xiàn)熱點查詢，因此我們也通過Proxy實現(xiàn)存算分離。