LinkedIn 開源其分布式對(duì)象存儲(chǔ)系統(tǒng)課件

1、LinkedIn 開源其分布式對(duì)象存儲(chǔ)系統(tǒng)Ambry2016-06-04SubramanianInfoQ“LinkedIn在Github上基于Apache 2許可證協(xié)議開源了其分布式對(duì)象存儲(chǔ)系統(tǒng)Ambry。Ambry是一個(gè)是不可變對(duì)象的存儲(chǔ)系統(tǒng)，非常易于擴(kuò)展，它能夠存儲(chǔ)KB到GB大小的不可變對(duì)象，并且能夠?qū)崿F(xiàn)高吞吐和低延遲，該系統(tǒng)支持跨數(shù)據(jù)中心的雙活部署，并且存儲(chǔ)成本低廉。它特別適于存儲(chǔ)各種媒體內(nèi)容。據(jù)Linkedin的前工程主管Sriram Subramanian介紹，媒體內(nèi)容在Web中已經(jīng)無處不在，Linkedin中的每項(xiàng)新特性基本上都會(huì)與某種類型的媒體內(nèi)容進(jìn)行交互。這些媒體內(nèi)容會(huì)存儲(chǔ)在后

2、端，并且主要會(huì)由內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Networks，CDN）來提供服務(wù)，后臺(tái)存儲(chǔ)系統(tǒng)會(huì)作為CDN的原始服務(wù)器（origin server）。隨著Linkedin流量的不斷增長(zhǎng)，原來所使用的媒體內(nèi)容存儲(chǔ)方案在可擴(kuò)展性、可用性以及運(yùn)維方面所遇到的問題越來越多。兩年前，他們著手解決這些問題，而Ambry正是該項(xiàng)工作的結(jié)果。2013年時(shí)的媒體存儲(chǔ)是怎樣的？LinkedIn之前的系統(tǒng)被稱為媒體服務(wù)器（因?yàn)闆]有一個(gè)像樣的名字），這個(gè)系統(tǒng)由兩部分組成，分別是用于媒體文件存儲(chǔ)的Filer以及存儲(chǔ)元數(shù)據(jù)的大型Oracle數(shù)據(jù)庫。這些系統(tǒng)的前端是一些運(yùn)行在SOLARIS上的無狀態(tài)機(jī)器

3、，它們會(huì)將請(qǐng)求路由到對(duì)應(yīng)的Filer或數(shù)據(jù)庫上。Filer是通過NFS的方式mount到無狀態(tài)機(jī)器上的，并使用Java的File API進(jìn)行遠(yuǎn)程訪問。前端會(huì)與數(shù)據(jù)中心（DC）里面的一組緩存進(jìn)行交互，從而保證如果下游系統(tǒng)（Filer/Oracle）出現(xiàn)性能問題或不可用時(shí)，前端不會(huì)受其影響。隨著LinkedIn對(duì)媒體內(nèi)容的需求不斷增加，原有的系統(tǒng)在面臨這些需求時(shí)，遇到了如下嚴(yán)重的問題： 頻繁出現(xiàn)的可用性問題：每次對(duì)文件的元數(shù)據(jù)操作出現(xiàn)峰值時(shí)，原有的系統(tǒng)都會(huì)出現(xiàn)延遲。當(dāng)訪問大量的小文件時(shí)，對(duì)元數(shù)據(jù)的操作就會(huì)增多。每次文件操作都要經(jīng)過多級(jí)的轉(zhuǎn)換（Java、NFS以及Filer），使其很難進(jìn)行調(diào)試； 難

4、以擴(kuò)展：用來存儲(chǔ)數(shù)據(jù)和元數(shù)據(jù)的底層系統(tǒng)都是單體的。水平擴(kuò)展元數(shù)據(jù)的存儲(chǔ)是不可能實(shí)現(xiàn)的，為數(shù)據(jù)存儲(chǔ)增加硬件也需要很多的手動(dòng)過程； 對(duì)小對(duì)象和大對(duì)象的支持效率低下：媒體數(shù)據(jù)集中包含了數(shù)萬億的小對(duì)象（50KB-1MB）也包括數(shù)億的大對(duì)象（1MB-1GB）。對(duì)于小對(duì)象的存儲(chǔ)來說，元數(shù)據(jù)操作的代價(jià)是很高昂的，而對(duì)于大數(shù)據(jù)，原有的系統(tǒng)缺乏端到端的流支持，難以支持新產(chǎn)品的使用場(chǎng)景； 平均修復(fù)時(shí)間（MTTR，Mean Time To Repair）指標(biāo)很差：老系統(tǒng)中的大多數(shù)組成部分在很大程度上都是黑盒，這需要獲得支持許可證，并且要通過電話的方式來描述和解決問題，這會(huì)影響到MTTR； 成本高昂：舊的媒體存儲(chǔ)成本

5、很高，再繼續(xù)擴(kuò)展的話，成本上已經(jīng)吃不消了。如果想管理媒體的擴(kuò)展性，就不能延續(xù)該方案了。在這個(gè)過程中，Linkedin探索過多種替代方案，最終還是決定自行實(shí)現(xiàn)更匹配其需求的解決方案。Ambry是如何運(yùn)行的？設(shè)計(jì)目標(biāo)在了解Ambry的設(shè)計(jì)和內(nèi)部運(yùn)行原理之前，明確其設(shè)計(jì)目標(biāo)是很有幫助的，這決定了它的實(shí)現(xiàn)方式。 高可用性和水平可擴(kuò)展：該系統(tǒng)要處理實(shí)時(shí)流量，會(huì)直接影響到站點(diǎn)的可用性，因此它必須具有很高的可用性。另外，還希望新系統(tǒng)能夠盡可能地實(shí)現(xiàn)無縫的集群擴(kuò)展； 降低運(yùn)維的負(fù)擔(dān)：分布式系統(tǒng)一般都會(huì)難以管理，對(duì)于頻繁的集群操作，能夠?qū)崿F(xiàn)自動(dòng)化是非常重要的，這能避免系統(tǒng)成為運(yùn)維的一種負(fù)擔(dān)。復(fù)雜的系統(tǒng)通常很難實(shí)

6、現(xiàn)自動(dòng)化并可靠的運(yùn)行，因此新系統(tǒng)的設(shè)計(jì)要簡(jiǎn)單、優(yōu)雅并自動(dòng)化； 更低的MTTR：分布式系統(tǒng)出現(xiàn)故障是難以避免的，但是很重要的一點(diǎn)在于快速修復(fù)故障，讓各個(gè)子組件啟動(dòng)并運(yùn)行。這就需要系統(tǒng)的設(shè)計(jì)簡(jiǎn)單，并且不會(huì)出現(xiàn)單點(diǎn)故障； 跨DC雙活：Linkedin有多個(gè)數(shù)據(jù)中心，因此所有的系統(tǒng)都要支持雙活配置，這樣的話，系統(tǒng)能夠更新不同數(shù)據(jù)中心中的同一個(gè)對(duì)象； 提升小對(duì)象和大對(duì)象的效率：請(qǐng)求是由小對(duì)象和大對(duì)象所組成的，小對(duì)象通常是1K到100K，超出這個(gè)范圍的對(duì)象會(huì)位于大對(duì)象桶中（bucket）。要同時(shí)處理好各種大小的對(duì)象，通常來講是很困難的。大量的小對(duì)象會(huì)給元數(shù)據(jù)帶來很高的負(fù)載，造成硬盤碎片，需要很多的隨機(jī)IO

7、，而大對(duì)象則需要很好的內(nèi)存管理、端到端的流處理和有限的資源使用； 廉價(jià)：媒體內(nèi)容很快就會(huì)占據(jù)很大的存儲(chǔ)空間，它的另外一個(gè)特點(diǎn)是舊數(shù)據(jù)會(huì)變成“冷”數(shù)據(jù)，并不會(huì)頻繁訪問。針對(duì)這種情況有很多優(yōu)化技術(shù)，包括使用密集的硬件（denser hardware）、分層存儲(chǔ)、擦除編碼以及數(shù)據(jù)去重等。在設(shè)計(jì)時(shí)，Ambry希望媒體內(nèi)容能夠高效存儲(chǔ)在密集型的機(jī)器上，并且能夠非常容易地使用其他優(yōu)化成本的方案。概覽總體上來講，Ambry由三部分組成，分別是用來存儲(chǔ)和檢索數(shù)據(jù)的一組數(shù)據(jù)節(jié)點(diǎn)，路由請(qǐng)求的前端機(jī)器（請(qǐng)求會(huì)在一些預(yù)處理之后路由到數(shù)據(jù)節(jié)點(diǎn)上）以及協(xié)調(diào)和維護(hù)集群的集群管理器。數(shù)據(jù)節(jié)點(diǎn)會(huì)在不同節(jié)點(diǎn)之間復(fù)制數(shù)據(jù)，同時(shí)支持

8、數(shù)據(jù)中心內(nèi)部和數(shù)據(jù)中間之間的復(fù)制。前端提供了支持對(duì)象PUT、GET和DELETE操作的HTTP API。另外，前端所使用的路由庫也可以直接用在客戶端中，從而實(shí)現(xiàn)更好的性能。在LinkedIn，這些前端節(jié)點(diǎn)會(huì)作為CDN的原始服務(wù)器。APIAmbry提供了REST API，它們適用于大多數(shù)的場(chǎng)景。在有些場(chǎng)景下，需要更好的性能，如果是這樣的話，Ambry也支持在客戶端使用路由庫，直接針對(duì)數(shù)據(jù)節(jié)點(diǎn)的流字節(jié)進(jìn)行讀取和寫入。目前，路由庫是阻塞的（同步），不過Ambry目前正在致力于實(shí)現(xiàn)非阻塞（異步）版本，同時(shí)也會(huì)提供對(duì)路由庫的多語言支持。ClustermapClustermap控制拓?fù)浣Y(jié)構(gòu)、維護(hù)狀態(tài)并幫助

9、協(xié)調(diào)集群的操作。Clustermap有兩部分組成： 硬件布局：包含了機(jī)器的列表、每臺(tái)機(jī)器上的磁盤以及每個(gè)磁盤的容量。布局還維護(hù)資源的狀態(tài)（機(jī)器和磁盤）并指定主機(jī)名和端口，通過主機(jī)名和端口就能連接到數(shù)據(jù)節(jié)點(diǎn)； 分區(qū)布局：包含了分區(qū)的列表、它們的位置信息以及狀態(tài)。在Ambry中，分區(qū)有一個(gè)數(shù)字表示的ID，副本的列表可以跨數(shù)據(jù)中心。分區(qū)是固定大小的資源，集群間的數(shù)據(jù)重平衡都是在分區(qū)級(jí)別進(jìn)行的。數(shù)據(jù)節(jié)點(diǎn)和前端服務(wù)器都能夠訪問clustermap，并且會(huì)始終使用它們當(dāng)前的視圖來做出決策，這些決策涉及到選擇可用的機(jī)器、過濾副本以及識(shí)別對(duì)象的位置等。存儲(chǔ)存儲(chǔ)節(jié)點(diǎn)會(huì)用來存放不同分區(qū)的副本。每個(gè)存儲(chǔ)節(jié)點(diǎn)會(huì)有N塊

10、磁盤，副本會(huì)跨磁盤分布存儲(chǔ)。這些副本的結(jié)構(gòu)和管理都是相同的。在存儲(chǔ)方面，Ambry涵蓋的功能包括如下幾個(gè)方面： 持久化：磁盤上的每個(gè)副本均被建模為預(yù)先分配的log（preallocated log）。所有新的消息都會(huì)按照順序附加到log上，消息是由實(shí)際的對(duì)象塊（chunk）和相關(guān)的元數(shù)據(jù)（系統(tǒng)和用戶）所組成的。這能夠使寫入操作實(shí)現(xiàn)很高的吞吐量，并且避免出現(xiàn)磁盤碎片。Ambry會(huì)使用索引將對(duì)象id與log中的消息映射起來，索引本身是一組排序的文件片段，條目按照最新使用在前，最舊的條目在后的順序，從而便于高效查找。索引中的每個(gè)條目都維護(hù)了log中消息的偏移量、消息的屬性以及一些內(nèi)部使用的域。索引中

11、的每個(gè)片段會(huì)維護(hù)一個(gè)bloom filter，從而優(yōu)化實(shí)際磁盤操作所耗費(fèi)的時(shí)間； 零拷貝：通過使用sendfileAPI，在進(jìn)行讀取時(shí)，字節(jié)從log轉(zhuǎn)移到網(wǎng)絡(luò)的過程中實(shí)現(xiàn)了零拷貝。通過避免額外的系統(tǒng)調(diào)用，實(shí)現(xiàn)了更好的性能，在這個(gè)過程中，會(huì)確保字節(jié)不會(huì)讀入到用戶內(nèi)存中，不必進(jìn)行緩存池的管理； 恢復(fù)：因?yàn)橄到y(tǒng)和機(jī)器會(huì)出現(xiàn)宕機(jī)，磁盤上的數(shù)據(jù)也有可能會(huì)損壞，所以有必要實(shí)現(xiàn)恢復(fù)（recovery）的功能。在啟動(dòng)的時(shí)候，存儲(chǔ)層會(huì)從最后一個(gè)已知的檢查點(diǎn)讀取log，并重建索引?；謴?fù)也有助于重建內(nèi)存中的狀態(tài)。Log是恢復(fù)的來源，并且會(huì)永久保存； 復(fù)制：存儲(chǔ)節(jié)點(diǎn)還需要維護(hù)分區(qū)中各副本的同步。每個(gè)節(jié)點(diǎn)上都會(huì)有一個(gè)復(fù)

12、制服務(wù)（replication service），它會(huì)負(fù)責(zé)保證本地存儲(chǔ)中的副本與所有的遠(yuǎn)程副本是同步的。在這里，進(jìn)行了很多的優(yōu)化，以保證復(fù)制過程的高效可靠。路由/前端前端服務(wù)器提供了HTTP接口，供客戶端與之通信。除此之外，它們還會(huì)負(fù)責(zé)為CDN設(shè)置正確的頭信息、進(jìn)行安全校驗(yàn)，并將對(duì)象以流的形式返回給路由庫和客戶端。路由所負(fù)責(zé)的功能如下所示： 請(qǐng)求管理：請(qǐng)求的端到端生命周期是由路由來進(jìn)行管理的。路由會(huì)處理PUT、GET以及DELETE請(qǐng)求。對(duì)于其中的每個(gè)請(qǐng)求類型，路由都會(huì)跟蹤副本成功和失敗的數(shù)量從而確定Quorum的值、維護(hù)分塊的狀態(tài)、生成對(duì)象id并在成功或失敗的時(shí)候觸發(fā)對(duì)應(yīng)的回調(diào)； 分塊：大對(duì)

13、象會(huì)分解為塊（chunk），每個(gè)塊都能夠跨分區(qū)獨(dú)立地進(jìn)行路由。每個(gè)塊都會(huì)有一個(gè)id來進(jìn)行唯一標(biāo)識(shí)。路由會(huì)生成一個(gè)元數(shù)據(jù)對(duì)象，其中包含了塊的列表以及它們所需的獲取順序。元數(shù)據(jù)對(duì)象存儲(chǔ)為獨(dú)立的blob，它的id也會(huì)作為blob的id。在讀取的時(shí)候，會(huì)得到元數(shù)據(jù)對(duì)象，然后檢索各個(gè)塊并返回給客戶端； 故障檢測(cè)：故障檢測(cè)的邏輯要負(fù)責(zé)主動(dòng)識(shí)別宕機(jī)或狀態(tài)出問題的資源。資源可以是機(jī)器、磁盤或分區(qū)。路由會(huì)將出現(xiàn)問題的資源標(biāo)記為不可用，這樣后續(xù)的請(qǐng)求就不會(huì)使用它們了； Quorum：Ambry為寫入和讀取實(shí)現(xiàn)了一種多主人（multi-master）的策略。這能夠?qū)崿F(xiàn)更高的可用性并減少端到端的延遲，這是通過減少一個(gè)

14、額外的hop來實(shí)現(xiàn)的，在基于主從結(jié)構(gòu)（master slave）的系統(tǒng)中，往往會(huì)有這個(gè)額外的hop。請(qǐng)求通常會(huì)發(fā)往M個(gè)副本，然后等待至少N個(gè)成功的響應(yīng)（這里N=M）。路由會(huì)優(yōu)先使用本地?cái)?shù)據(jù)中心的副本，向其發(fā)送請(qǐng)求，如果本地存儲(chǔ)無法實(shí)現(xiàn)所需的Quorum的話，它會(huì)代理遠(yuǎn)程數(shù)據(jù)中心的訪問； 變更捕獲：在每次成功的PUT或DELETE操作之后，路由會(huì)生成一個(gè)變更捕獲（change capture）。變更捕獲中所包含的信息是blob id以及blob相關(guān)的元數(shù)據(jù)，這個(gè)信息可以被下游的應(yīng)用所使用。在路由中，典型的PUT和GET操作的流程分別如下所示，系統(tǒng)的實(shí)際運(yùn)行過程會(huì)比下述的描述會(huì)更復(fù)雜一些： PUT

15、操作：客戶端會(huì)將對(duì)象以及一些元數(shù)據(jù)信息以流的形式發(fā)送到前端，當(dāng)流到達(dá)時(shí)，前端會(huì)將對(duì)象進(jìn)行分塊、選擇可用的分區(qū)、為blob或分塊生成blob id，并將請(qǐng)求分發(fā)給W個(gè)副本。然后，前端就開始等待至少Q(mào)個(gè)成功的響應(yīng)（Q=W），等到之后，會(huì)將blob id返回給客戶端。如果無法達(dá)到足夠的Quorum，那么前端會(huì)報(bào)告一個(gè)錯(cuò)誤。當(dāng)然，Ambry也實(shí)現(xiàn)了當(dāng)Quorum失敗的時(shí)候，選擇另外一個(gè)分區(qū)的功能，從而提升可用性。 GET操作：客戶端通過將id發(fā)送給前端來請(qǐng)求某一個(gè)blob。前端會(huì)根據(jù)id來確定分區(qū)，并在數(shù)據(jù)節(jié)點(diǎn)中檢索blob相關(guān)的塊。對(duì)于每個(gè)塊，前端會(huì)并行發(fā)送R個(gè)請(qǐng)求，在將blob或分塊發(fā)送給客戶端之

16、前，前端會(huì)等待Q個(gè)成功響應(yīng)（Q=R）。解決運(yùn)維的難題分布式系統(tǒng)最困難的在于它的運(yùn)維，在這個(gè)過程中，需要工具、度量并且要進(jìn)行廣泛地測(cè)試，從而保證所有的事情都能符合預(yù)期。在這個(gè)過程中，Ambry積累了很多的工具和實(shí)踐。 Simoorg：為了模擬各種故障，他們孵化并開源了Simoorg。這是一個(gè)分布式的故障引入系統(tǒng)，能夠在集群中引入各種故障，如GC暫停、磁盤錯(cuò)誤、節(jié)點(diǎn)宕機(jī)以及網(wǎng)絡(luò)故障，從而校驗(yàn)在各種情況下，系統(tǒng)的正確性，有助于預(yù)先發(fā)現(xiàn)并修正嚴(yán)重的缺陷； 生產(chǎn)環(huán)境的正確性測(cè)試：當(dāng)新版本部署到集群中的部分機(jī)器進(jìn)行驗(yàn)證時(shí)，可以進(jìn)行正確性測(cè)試，從而保證生產(chǎn)環(huán)境的健康狀態(tài)。通過加壓訪問所有可用的API（組合使

17、用各種可能出現(xiàn)的輸入?yún)?shù)），確保結(jié)果的正確性； 審計(jì)：當(dāng)新的blob寫入到磁盤時(shí)，都會(huì)產(chǎn)生復(fù)制事件，這個(gè)事件包含了blob的信息以及事件的來源。所有存儲(chǔ)節(jié)點(diǎn)的事件都會(huì)聚集到Hadoop中，這樣就能審計(jì)是否所有的副本都進(jìn)行了寫入。目前該系統(tǒng)并不是實(shí)時(shí)的，不過，Ambry規(guī)劃會(huì)構(gòu)建一個(gè)實(shí)時(shí)的審計(jì)系統(tǒng)。除此之外，Ambry還實(shí)現(xiàn)了指標(biāo)和告警工具，用來幫助識(shí)別系統(tǒng)中的異常行為以及維護(hù)集群的管理工具。遷移工作是如何進(jìn)行的？團(tuán)隊(duì)需要將所有的媒體內(nèi)容從遺留系統(tǒng)遷移至Ambry，在這個(gè)過程中還要服務(wù)于所有的流量，不能出現(xiàn)任何的宕機(jī)時(shí)間。除此之外，團(tuán)隊(duì)還面臨著多項(xiàng)deadline，了解Ambry是如何組織研發(fā)和

18、部署的，對(duì)我們會(huì)有一定的指導(dǎo)意義：1. 當(dāng)時(shí)，公司正在將所有的服務(wù)從Spring RPC方案中剝離出來。從構(gòu)建Ambry開始計(jì)算，團(tuán)隊(duì)有四個(gè)月的時(shí)間支持新的API并移除Spring RPC；2. 一個(gè)新的數(shù)據(jù)中心正好需要搭建，Ambry團(tuán)隊(duì)并不想再去部署遺留系統(tǒng)了，因?yàn)檫@會(huì)帶來很高的成本。這同時(shí)也就意味著為了避免部署遺留系統(tǒng)，需要在八個(gè)月內(nèi)完成Ambry；3. 最后，團(tuán)隊(duì)希望在數(shù)據(jù)中心里面移除掉Solaris的方案，遺留系統(tǒng)是運(yùn)行在Solaris上的，它的deadline是一年。Ambry團(tuán)隊(duì)采用了一種特殊的方式來達(dá)到這些里程碑節(jié)點(diǎn)。首先，構(gòu)建前端并使用它來代理所有對(duì)舊系統(tǒng)的請(qǐng)求，然后再將所有

19、的客戶端遷移到新的前端上。這雖然費(fèi)了很大的功夫，但是確保了第一個(gè)deadline目標(biāo)的達(dá)成。第二步是讓Ambry能夠以端到端的方式運(yùn)行，并且只將其部署到新的數(shù)據(jù)中心上，然后將所有的數(shù)據(jù)從舊系統(tǒng)遷移至Ambry。在代碼中，添加了一定的邏輯，確保如果新數(shù)據(jù)中心發(fā)生故障的話，將會(huì)使用舊的系統(tǒng)。這可能會(huì)產(chǎn)生更多的延遲，但是團(tuán)隊(duì)決定承擔(dān)這個(gè)風(fēng)險(xiǎn)。在新數(shù)據(jù)中心搭建完成之后，在接下來的幾個(gè)月里，團(tuán)隊(duì)不斷運(yùn)行并穩(wěn)定Ambry?；跍y(cè)試和審計(jì)結(jié)果，當(dāng)對(duì)新系統(tǒng)完全自信的時(shí)候，團(tuán)隊(duì)決定停掉遺留的系統(tǒng)。這樣就在一年的deadline之內(nèi)完成了目標(biāo)。在接下來的一年中，Ambry成為了Linkedin中媒體內(nèi)容的唯一來源

20、。它的成功要?dú)w因于周密的規(guī)劃以及漸進(jìn)式的基礎(chǔ)設(shè)施研發(fā)。如何適應(yīng)LinkedIn的生態(tài)系統(tǒng)？媒體基礎(chǔ)設(shè)施是針對(duì)媒體內(nèi)容的端到端管道，涉及到上傳、存儲(chǔ)、處理、元數(shù)據(jù)管理以及內(nèi)容下載。在基礎(chǔ)設(shè)施中，Ambry是很重要的一個(gè)環(huán)節(jié)，基礎(chǔ)的穩(wěn)固是非常重要的。在Ambry就緒之后，就可以圍繞著它進(jìn)行擴(kuò)展并關(guān)注生態(tài)系統(tǒng)中的其他組成部分。下一步的研發(fā)計(jì)劃目前，Ambry主要進(jìn)行中的任務(wù)包括在前端和路由層實(shí)現(xiàn)非阻塞、存儲(chǔ)節(jié)點(diǎn)實(shí)現(xiàn)機(jī)架感知等功能。團(tuán)隊(duì)希望不斷地為Ambry添加新的特性，并且構(gòu)建活躍的開源社區(qū)。完整的未來工作計(jì)劃列表可以參見Github上的相關(guān)頁面，如下列出了當(dāng)前正在進(jìn)行的或者可能會(huì)開展的項(xiàng)目： 非阻塞：阻塞類型的請(qǐng)求通常會(huì)占用一個(gè)進(jìn)程，直到請(qǐng)求結(jié)束并且不支持管道。為了達(dá)到更高的吞吐量，并且避免大對(duì)象所造成的資源枯竭現(xiàn)象，需要將路由和前端變成完全非阻塞的。這樣的話，就能支持更大吞吐量，在操作執(zhí)行時(shí)，不再受限于線程資源，從而能夠?qū)崿F(xiàn)更好的可用性。目前，前端實(shí)現(xiàn)已經(jīng)完成，正在進(jìn)行測(cè)試。路由庫的代碼預(yù)計(jì)也將會(huì)很快完成，可以參