點(diǎn)擊“開發(fā)者技術(shù)前線”，選擇“星標(biāo)??”

讓一部分開發(fā)者看到未來

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

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

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

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

1）性能挑戰(zhàn)

單機(jī)引擎性能是KV系統(tǒng)的關(guān)鍵指標(biāo)，一般我們通過讀寫性能（OPS、延時(shí)（latency））和空間利用率來衡量引擎的性能，由于當(dāng)前引擎架構(gòu)和存儲(chǔ)設(shè)備硬件性能的制約，我們?cè)谝嬷型荒苓x擇讀性能、寫性能和空間利用率中某個(gè)方向進(jìn)行重點(diǎn)優(yōu)化，比如犧牲空間利用率提升寫吞吐，或者犧牲寫吞吐、提升空間利用率和讀吞吐。

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

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

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

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

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

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

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

KV服務(wù)在對(duì)齊上述標(biāo)準(zhǔn)的過程中，主要難點(diǎn)在于容器化改造和動(dòng)態(tài)管理兩個(gè)方面。

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

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

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

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

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

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

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

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

二、引擎優(yōu)化

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

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

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

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

• 在RocksDB中存儲(chǔ)Key和Value的地址索引(BlockID+Offset)，RocksDB的Compaction只影響到索引，不會(huì)引起Value的變動(dòng)。
• Value單獨(dú)持久化，我們稱之Data Block文件，Data Block文件單獨(dú)進(jìn)行Compaction。

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

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

此外，我們?cè)谝嬷袨橥娇蚣芊庋b了Log View，實(shí)現(xiàn)數(shù)據(jù)同步與引擎復(fù)用，WAL降低了數(shù)據(jù)同步造成的寫放大。

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

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

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

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

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

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

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

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

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

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

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

三、云原生實(shí)踐

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

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

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

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

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

我們?cè)谙到y(tǒng)設(shè)計(jì)、實(shí)現(xiàn)中主要考慮如何實(shí)現(xiàn)數(shù)據(jù)全局調(diào)度能力和海量存儲(chǔ)實(shí)例的動(dòng)態(tài)管理能力。

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

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

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

這種能力的意義在于：

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

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

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

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

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

3.2 海量存儲(chǔ)實(shí)例的動(dòng)態(tài)管理能力

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

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

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

我們?cè)跀?shù)據(jù)面中：

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

由于數(shù)據(jù)中心間的元信息不盡相同，尤其是拓?fù)湫畔⑼耆煌彝負(fù)湫畔⒕哂袠O強(qiáng)的時(shí)效性，冷備效果并不好，因此對(duì)于控制面我們采用了利用數(shù)據(jù)面，集群控制服務(wù)多級(jí)兜底的思路，如下圖（圖5）所示：

• 冷備機(jī)制：對(duì)于低頻更新的元信息，諸如業(yè)務(wù)數(shù)據(jù)屬性、配額實(shí)時(shí)備份SQL數(shù)據(jù)庫(kù)。
• 反向恢復(fù)機(jī)制：利用集群控制服務(wù)和存儲(chǔ)集群都有拓?fù)溏R像的特點(diǎn)，支持通過上述服務(wù)反向恢復(fù)拓?fù)湫畔ⅰ?/span>
• 異變攔截機(jī)制：在控制面、數(shù)據(jù)面及業(yè)務(wù)端（Client）攔截異常變更，避免拓?fù)洚惓r(shí)，服務(wù)迅速異常雪崩。

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

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

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

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

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

• DbProxy模塊：整個(gè)架構(gòu)的第一層，是一個(gè)獨(dú)立部署的模塊，DBProxy是對(duì)所有代理存儲(chǔ)節(jié)點(diǎn)（Store Node）的Proxy服務(wù)的總稱，按功能不同還有諸如KvProxy，GraphProxy等，該模塊主要用于：
1. 分擔(dān)存儲(chǔ)節(jié)點(diǎn)（Store Node）訪問壓力：當(dāng)業(yè)務(wù)存在大量的Fanout讀，或離線任務(wù)（map reduce任務(wù)）存在大量寫連接時(shí)，通過proxy可以減少對(duì)存儲(chǔ)節(jié)點(diǎn)的壓力;
2. 減少上下游連接開銷：主要用于超大規(guī)模業(yè)務(wù)，比如搜索業(yè)務(wù)的一張索引表就分布在上萬個(gè)實(shí)例中，這也意味訪問該表的每個(gè)下游都要維護(hù)上萬個(gè)連接，因此需要通過proxy減少客戶端的連接開銷。
3. 存算分離：當(dāng)前通過NVMe-OF、RDMA技術(shù)網(wǎng)絡(luò)已經(jīng)不是系統(tǒng)的主要瓶頸，像圖數(shù)據(jù)庫(kù)這樣的服務(wù)，一次請(qǐng)求需要訪問多個(gè)存儲(chǔ)節(jié)點(diǎn)才能完成，還需要通過本地緩存構(gòu)建子圖加速業(yè)務(wù)查詢速度，整合在存儲(chǔ)節(jié)點(diǎn)中幾乎無法帶來的性能收益，還容易出現(xiàn)熱點(diǎn)查詢，因此我們也通過Proxy實(shí)現(xiàn)存算分離。
   
   
• libNode模塊：該模塊承擔(dān)了存儲(chǔ)節(jié)點(diǎn)的業(yè)務(wù)邏輯、節(jié)點(diǎn)管理和數(shù)據(jù)同步：
1. 分布式管理層：通過CtrlService向業(yè)務(wù)提供了一組響應(yīng)分布式狀態(tài)管理的核心原語，并提供了默認(rèn)原語實(shí)現(xiàn)。
2. 接口協(xié)議層 & 數(shù)據(jù)模型層：提供KvService作為所有服務(wù)共同遵守的最簡(jiǎn)KV協(xié)議，開放服務(wù)注冊(cè)和模型層（Module）供業(yè)務(wù)組織管理自己的定制化服務(wù)接口以及數(shù)據(jù)結(jié)構(gòu)。為了能讓模型使用適應(yīng)不同引擎，我們統(tǒng)一KV接口作為模型層的序列化反序列化接口。
3. 同步框架層：不同業(yè)務(wù)對(duì)服務(wù)的可用性、數(shù)據(jù)一致性的要求并不相同，比如用戶模型關(guān)注可用性和吞吐能力，內(nèi)容模型則關(guān)注讀寫延時(shí)和數(shù)據(jù)的強(qiáng)一致性。我們也針對(duì)業(yè)務(wù)的不同需求提供了最終一致性（高可用、高吞吐）、順序一致（braft實(shí)現(xiàn)的一致性，介于最終一致和強(qiáng)一致性之間）和線性一致（強(qiáng)一致）三個(gè)層級(jí)的一致性保證，其中線性一致是我們?cè)赽raft基礎(chǔ)上，通過ReadIndex和LeaseRead算法滿足的一致性語義。
   
   
• 引擎模塊：也是6層架構(gòu)中的最后一個(gè)分層『引擎層』，主要負(fù)責(zé)單機(jī)存儲(chǔ)功能，與libnode共同組成了一個(gè)存儲(chǔ)節(jié)點(diǎn)（Store Node）。上節(jié)提到的引擎優(yōu)化，就是對(duì)這個(gè)模塊的一系列優(yōu)化工作。

五、總結(jié)

UNDB系統(tǒng)自落地以來，已經(jīng)覆蓋了百度信息流和搜索主要業(yè)務(wù)場(chǎng)景，涉及集群規(guī)模數(shù)十萬實(shí)例，每天承接了超過萬億次的各類訪問流量，成本相較原先降低近50%。同時(shí)系統(tǒng)還保持著月級(jí)頻率的全集群業(yè)務(wù)無感更新。在運(yùn)維方面則實(shí)現(xiàn)了高度自動(dòng)化，集群無專職運(yùn)維，全部由研發(fā)團(tuán)隊(duì)自主管理。目前團(tuán)隊(duì)還在打造多模型數(shù)據(jù)庫(kù)、單機(jī)性能優(yōu)化、存儲(chǔ)架構(gòu)優(yōu)化等方向持續(xù)努力，力求使UNDB具備更完善的業(yè)務(wù)生態(tài)。

— 完 —
點(diǎn)這里??關(guān)注我，記得標(biāo)星呀～

前線推出學(xué)習(xí)交流一定要備注：研究/工作方向+地點(diǎn)+學(xué)校/公司+昵稱（如JAVA+上海

掃碼加小編微信，進(jìn)群和大佬們零距離