轉(zhuǎn)載自??揭秘阿里秒級(jí)百萬TPS平臺(tái)架構(gòu)實(shí)現(xiàn)

導(dǎo)讀：搜索離線數(shù)據(jù)處理是一個(gè)典型的海量數(shù)據(jù)批次/實(shí)時(shí)計(jì)算結(jié)合的場(chǎng)景，阿里搜索中臺(tái)團(tuán)隊(duì)立足內(nèi)部技術(shù)結(jié)合開源大數(shù)據(jù)存儲(chǔ)和計(jì)算系統(tǒng)，針對(duì)自身業(yè)務(wù)和技術(shù)特點(diǎn)構(gòu)建了搜索離線平臺(tái)，提供復(fù)雜業(yè)務(wù)場(chǎng)景下單日批次處理千億級(jí)數(shù)據(jù)，秒級(jí)實(shí)時(shí)百萬TPS吞吐的計(jì)算能力。

?

背景

什么是搜索離線？

一個(gè)典型的商品搜索架構(gòu)如下圖所示，本文將要重點(diǎn)介紹的就是下圖中的離線數(shù)據(jù)處理系統(tǒng)（Offline System）。

何謂離線？在阿里搜索工程體系中我們把搜索引擎、在線算分、SearchPlanner等ms級(jí)響應(yīng)用戶請(qǐng)求的服務(wù)稱之為“在線”服務(wù)；與之相對(duì)應(yīng)的，將各種來源數(shù)據(jù)轉(zhuǎn)換處理后送入搜索引擎等“在線”服務(wù)的系統(tǒng)統(tǒng)稱為“離線”系統(tǒng)。商品搜索的業(yè)務(wù)特性（海量數(shù)據(jù)、復(fù)雜業(yè)務(wù)）決定了離線系統(tǒng)從誕生伊始就是一個(gè)大數(shù)據(jù)系統(tǒng)，它有以下一些特點(diǎn)：

1. 任務(wù)模型上區(qū)分全量和增量

1）全量是指將搜索業(yè)務(wù)數(shù)據(jù)全部重新處理生成，并傳送給在線引擎，一般是每天一次。這么做有兩個(gè)原因：有業(yè)務(wù)數(shù)據(jù)是daily更新；引擎需要全量數(shù)據(jù)來高效的進(jìn)行索引整理和預(yù)處理，提高在線服務(wù)效率。

2）增量是指將上游數(shù)據(jù)源實(shí)時(shí)發(fā)生的數(shù)據(jù)變化更新到在線引擎中。

3）性能方面有較高要求。全量需要極高吞吐能力，確保數(shù)以億計(jì)的數(shù)據(jù)可以在數(shù)小時(shí)內(nèi)完成。增量則需要支持?jǐn)?shù)萬TPS秒級(jí)的實(shí)時(shí)性，還需要有極高的可用性。

2. 需要支持多樣化的輸入和輸出數(shù)據(jù)源，包括：Mysql，ODPS，TT等各種數(shù)據(jù)庫(kù)和消息隊(duì)列作為輸入，搜索、Ranking、圖、推薦等各種引擎作為輸出。

3. 需要提供一定能力的數(shù)據(jù)處理能力，例如多表Join、UDTF支持等，以方便搜索業(yè)務(wù)的開發(fā)和接入。

在后續(xù)的段落中我們會(huì)看到離線系統(tǒng)架構(gòu)圍繞著這些特點(diǎn)，針對(duì)搜索業(yè)務(wù)的變化，做出的各種演進(jìn)和發(fā)展。

?

發(fā)展簡(jiǎn)介

阿里商品搜索體系肇始于淘寶搜索，大約在2008年初第一代搜索系統(tǒng)誕生，離線系統(tǒng)隨之上線。搜索離線系統(tǒng)經(jīng)歷多年發(fā)展，技術(shù)架構(gòu)幾經(jīng)迭代，數(shù)據(jù)處理能力、業(yè)務(wù)支持能力不斷提升。下面會(huì)分階段介紹搜索離線的主要技術(shù)架構(gòu)和特點(diǎn)。

★ 淘寶搜索階段

在2008-2012這個(gè)階段，我們重點(diǎn)支持淘寶搜索的業(yè)務(wù)發(fā)展，隨著淘寶商品量的不斷增加，逐步引入Hadoop、Hbase等開源大數(shù)據(jù)計(jì)算和存儲(chǔ)框架，實(shí)現(xiàn)了搜索離線系統(tǒng)的分布式化，有力地支持了淘寶搜索業(yè)務(wù)的發(fā)展。但是在這個(gè)階段，我們支持的業(yè)務(wù)線只有淘系合計(jì)不到5個(gè)業(yè)務(wù)線，為此投入了大約10名開發(fā)人員，整體效率不高。另一方面相關(guān)系統(tǒng)框架代碼與淘系業(yè)務(wù)高度耦合，量身定制了很多特殊代碼，不利于架構(gòu)的推廣和其它業(yè)務(wù)的支持。

?

★ 組件&平臺(tái)化階段

2013年底以來，特別是最近兩年，隨著集團(tuán)技術(shù)業(yè)務(wù)線的梳理以及中臺(tái)化戰(zhàn)略的推行，搜索離線系統(tǒng)需要為越來越多的不同業(yè)務(wù)團(tuán)隊(duì)（飛豬、釘釘、1688、AE、Lazada等等）提供支持，技術(shù)框架復(fù)用、開發(fā)效率提升和平臺(tái)化支持的需求越來越強(qiáng)烈。另一方面隨著大數(shù)據(jù)計(jì)算、存儲(chǔ)技術(shù)的發(fā)展，尤其是流計(jì)算引擎的飛速發(fā)展，離線系統(tǒng)技術(shù)架構(gòu)上的進(jìn)一步演進(jìn)也具備了絕佳的土壤。

我們可以看到整個(gè)搜索離線系統(tǒng)的演進(jìn)是沿著性能和效率兩條主線，以業(yè)務(wù)和技術(shù)為雙輪驅(qū)動(dòng)，一步一個(gè)腳印的走到今天。這是一個(gè)技術(shù)與業(yè)務(wù)高度融合互動(dòng)，互相促進(jìn)發(fā)展的典型樣例。

?

離線平臺(tái)技術(shù)架構(gòu)

上一節(jié)我們簡(jiǎn)要介紹了離線系統(tǒng)的發(fā)展歷史，也簡(jiǎn)要提到技術(shù)架構(gòu)的演進(jìn)，下面將會(huì)把離線平臺(tái)的技術(shù)架構(gòu)展開介紹，主要分為平臺(tái)流程以及計(jì)算和存儲(chǔ)架構(gòu)等幾個(gè)方面。

平臺(tái)組件和任務(wù)流程

上圖描述了離線平臺(tái)技術(shù)組件結(jié)構(gòu)，其中部分組件的簡(jiǎn)介如下：

• Maat：分布式任務(wù)調(diào)度平臺(tái)，基于Airflow發(fā)展而來，主要改進(jìn)點(diǎn)是調(diào)度性能優(yōu)化、執(zhí)行器FaaS化、容器化、API及調(diào)度功能擴(kuò)展等四個(gè)部分，在保持對(duì)Airflow兼容的基礎(chǔ)上，大幅提升性能，提高了穩(wěn)定性。 一個(gè)離線任務(wù)的多個(gè)Blink job會(huì)通過Maat建立依賴關(guān)系并進(jìn)行調(diào)度。

• Bahamut：執(zhí)行引擎，是整個(gè)離線平臺(tái)的核心，負(fù)責(zé)離線任務(wù)的創(chuàng)建、調(diào)度、管理等各種功能，后文會(huì)詳細(xì)介紹。

• Blink：Flink的阿里內(nèi)部版本，在大規(guī)模分布式、SQL、TableAPI、Batch上做了大量的優(yōu)化和重構(gòu)。離線平臺(tái)的所有計(jì)算任務(wù)都是Blink job，包括stream和batch。

• Soman：UI模塊，與Bahamut后端對(duì)接，提供任務(wù)信息展示、狀態(tài)管理等可視化功能，也是用戶創(chuàng)建應(yīng)用的開發(fā)業(yè)務(wù)邏輯的主要入口。

• Catalog： 存儲(chǔ)表信息管理，提供各種數(shù)據(jù)源表的DDL能力，負(fù)責(zé)離線平臺(tái)存儲(chǔ)資源的申請(qǐng)、釋放、變更等各種功能。

• Hippo：阿里搜索自研的分布式資源管理和任務(wù)調(diào)度服務(wù)，類似于Yarn，提供Docker管理能力，主要服務(wù)于在線系統(tǒng)。

• Swift：阿里搜索自研高性能分布式消息隊(duì)列，支持億級(jí)別消息吞吐能力，存儲(chǔ)后端為HDFS，存儲(chǔ)計(jì)算分離架構(gòu)。

?

下圖則描述了一個(gè)離線任務(wù)從數(shù)據(jù)源到產(chǎn)出引擎服務(wù)數(shù)據(jù)的整個(gè)過程，流程圖分成三層：

• 數(shù)據(jù)同步層：將用戶定義的數(shù)據(jù)源表的全量和增量數(shù)據(jù)同步到Hbase內(nèi)部表，相當(dāng)于源表的鏡像。這個(gè)鏡像中我們包含cf和d兩個(gè)列族，分別存儲(chǔ)數(shù)據(jù)庫(kù)的鏡像和Daily更新的數(shù)據(jù)。

• 數(shù)據(jù)關(guān)聯(lián)計(jì)算層：按照數(shù)據(jù)源中定義的各種關(guān)系，將不同維度的數(shù)據(jù)關(guān)聯(lián)到一起，把數(shù)據(jù)送到自定義的UDTF中進(jìn)行處理，產(chǎn)出引擎所需的全量和增量數(shù)據(jù)。

• 數(shù)據(jù)交互層：提供全量和增量數(shù)據(jù)的存儲(chǔ)信息，與在線服務(wù)build模塊進(jìn)行交互。

?

?

全增量統(tǒng)一的計(jì)算模型

那么如何實(shí)現(xiàn)對(duì)用戶屏蔽離線平臺(tái)內(nèi)部的這些技術(shù)細(xì)節(jié)，讓用戶只需要關(guān)注業(yè)務(wù)實(shí)現(xiàn)呢？回顧第一節(jié)介紹的離線任務(wù)概念，離線任務(wù)包含全量和增量，它們業(yè)務(wù)邏輯相同，但是執(zhí)行模式上有區(qū)別。為了讓用戶能夠?qū)ＷI(yè)務(wù)邏輯的開發(fā)，屏蔽離線平臺(tái)技術(shù)細(xì)節(jié)實(shí)現(xiàn)全增量統(tǒng)一的計(jì)算邏輯，我們引入了Business Table（業(yè)務(wù)表）的概念。

Business Table（業(yè)務(wù)表）：Business Table是一個(gè)抽象表，由一個(gè)全量數(shù)據(jù)表和/或一個(gè)增量流表組成，全量/增量表的Schema相同，業(yè)務(wù)含義相同。

基于業(yè)務(wù)表和數(shù)據(jù)處理組件，用戶可以開發(fā)出一個(gè)描述離線處理流程的業(yè)務(wù)邏輯圖，我們稱之為Business Graph。下圖就是一個(gè)Business Graph的樣例，其中上側(cè)紅框標(biāo)識(shí)的就是只包含ODPS全量數(shù)據(jù)源的Business Table，最下方紅框中標(biāo)識(shí)的是包含Hdfs+Swift的Business Table，除此之外我們還支持Mysql+DRC/ODPS+Swift等多種業(yè)務(wù)表的組合。圖中還可以看到Join、UDTF等常用的數(shù)據(jù)處理組件，業(yè)務(wù)表與處理組件結(jié)合在一起就能夠描述常見的離線業(yè)務(wù)處理邏輯。

?

那么如何把這個(gè)Business Graph轉(zhuǎn)化為真正的離線任務(wù)呢？Bahamut作為離線平臺(tái)的執(zhí)行引擎，會(huì)按照Business Graph->APP Graph->Job Graph->(Blink Job/Maat Job)的順序把一個(gè)業(yè)務(wù)描述轉(zhuǎn)化為可執(zhí)行的離線任務(wù)，具體如下：

1. Business Graph->APP Graph：在這個(gè)環(huán)節(jié)中我們主要有2個(gè)重要的工作：

1）正確性校驗(yàn)：根據(jù)BG中的節(jié)點(diǎn)信息，校驗(yàn)節(jié)點(diǎn)間連接的合法性（例如兩個(gè)輸入源節(jié)點(diǎn)不能直接連接）、節(jié)點(diǎn)配置的正確性（數(shù)據(jù)庫(kù)配置/ODPS的配置是否正確）、Schema推導(dǎo)是否正確。

2）任務(wù)分層優(yōu)化：為了用Blink Stream模式來統(tǒng)一完成全量和增量的執(zhí)行，我們需要將輸入源數(shù)據(jù)存入內(nèi)部Hbase，直接使用Blink維表Join功能來完成數(shù)據(jù)的連接。于是在節(jié)點(diǎn)遍歷過程中遇到Join、Merge組件時(shí)，需要在AppGraph中插入一個(gè)內(nèi)部的HTable節(jié)點(diǎn)，將Merge或者Join上游的數(shù)據(jù)同步進(jìn)入Hbase。

2. APP Graph->Job Graph：JobGraph是一個(gè)Blink/Maat任務(wù)的配置DAG，其中每個(gè)節(jié)點(diǎn)包含配置信息，可以在后續(xù)的過程中直接轉(zhuǎn)化為計(jì)算或者調(diào)度任務(wù)。

1）Blink JobGraph：從數(shù)據(jù)源業(yè)務(wù)表節(jié)點(diǎn)開始遍歷AppGraph，每當(dāng)碰到一個(gè)內(nèi)部HTable節(jié)點(diǎn)時(shí)，會(huì)生成兩個(gè)（增量/全量）同步層的Blink JobGraph。所有同步層Blink JobGraph生成后，以所有的內(nèi)部HTable/queue為輸入，生成兩個(gè)（增量/全量）關(guān)聯(lián)處理層的Blink JobGraph。

①同步層：采用Business Table中的全量/增量表配置，分別生成全量和增量的Blink任務(wù)配置，描述把數(shù)據(jù)從數(shù)據(jù)源同步到內(nèi)部HTable過程。例如對(duì)于Mysql+DRC的表，全量階段將會(huì)從mysql中拉取全表數(shù)據(jù)并轉(zhuǎn)化為HFile bulkload到HTable中，增量階段則是從DRC中拉取變化數(shù)據(jù)，直接寫入HTable，并根據(jù)需求寫入驅(qū)動(dòng)queue。

②關(guān)聯(lián)處理層：關(guān)聯(lián)多個(gè)HTable，生成大寬表后調(diào)用UDTF處理，產(chǎn)出最終的進(jìn)入引擎的數(shù)據(jù)。同樣需要分別生成全量和增量任務(wù)配置

2)Maat JobGraph：基于Maat的調(diào)度任務(wù)描述DAG，主要目的是將各個(gè)層次的Blink任務(wù)按照依賴進(jìn)行調(diào)度，同時(shí)執(zhí)行特定的腳本完成與外部系統(tǒng)的交互等職責(zé)。一般來說一個(gè)離線任務(wù)會(huì)生成Build/Publish/Stop/Release等多個(gè)Maat JobGraph。

3. Job Graph->Blink/Maat Job：遍歷JobGraph，調(diào)用Translator將JobGraph轉(zhuǎn)換為Blink/Maat的任務(wù)代碼。引入JobGraph的目的是將底層的計(jì)算引擎與計(jì)算任務(wù)描述解耦，例如：我們底層的計(jì)算引擎曾經(jīng)是MapReduce +Blink-1.4-TableAPI，最近剛完成了Blink-2.1 基于SQL的升級(jí)，我們所有的工作基本上是重寫了一套Translator，對(duì)上層的代碼結(jié)構(gòu)沒有任何變動(dòng)。

經(jīng)過了上述的三個(gè)步驟，我們完成了BusinessGraph（業(yè)務(wù)描述）到Blink/Maat job的轉(zhuǎn)化，生成了若干數(shù)據(jù)同步/處理的Blink job，以及將這些Blink job進(jìn)行依賴調(diào)度的完成不同功能的Maat ?job。特別的針對(duì)搜索離線的場(chǎng)景，在調(diào)度流程中加入了大量與下游引擎交互的邏輯，包括24小時(shí)不間斷增量、觸發(fā)引擎消費(fèi)數(shù)據(jù)、切換引擎消費(fèi)增量queue等重要的業(yè)務(wù)流程。

?

存儲(chǔ)與計(jì)算

★ 基于Hbase的存儲(chǔ)架構(gòu)

搜索離線大約在2012年即引入了Hbase作為數(shù)據(jù)的存儲(chǔ)引擎，有力的支持了搜索業(yè)務(wù)從淘寶主搜到離線平臺(tái)的整個(gè)發(fā)展歷程，歷經(jīng)多次雙11考驗(yàn)，穩(wěn)定性和性能都得到明確的驗(yàn)證。從功能層面，搜索離線引入Hbase的原因主要是以下幾點(diǎn)：

通過Scan/Get可以批量/單條的獲取數(shù)據(jù)，通過bulkload/put可以批量/單條的導(dǎo)入數(shù)據(jù)，這與搜索的全量/增量模型完全吻合，天然適合支持搜索離線業(yè)務(wù)。

底層存儲(chǔ)基于HDFS，LSM-Tree的的架構(gòu)能夠確保數(shù)據(jù)安全性，計(jì)算存儲(chǔ)分離的架構(gòu)保證了集群規(guī)模水平可擴(kuò)展，易于提高整體的吞吐。通過單機(jī)性能優(yōu)化（Async、BucketCache、Handler分層、Offheap）和集群的擴(kuò)容，確保了業(yè)務(wù)大幅增長(zhǎng)時(shí)，存儲(chǔ)從來沒有成為系統(tǒng)的瓶頸。

Free Schema的特性能夠很好的應(yīng)對(duì)業(yè)務(wù)數(shù)據(jù)頻繁變化的情況，也能夠方便支持一些特殊業(yè)務(wù)場(chǎng)景的數(shù)據(jù)邏輯。

通過引入Hbase做為離線系統(tǒng)的內(nèi)部數(shù)據(jù)存儲(chǔ)，我們成功解決了每天全量時(shí)對(duì)上游Mysql造成很大壓力的問題，大幅度的提升了整體系統(tǒng)的吞吐。數(shù)據(jù)存儲(chǔ)到Hbase也是全量任務(wù)向流式處理流程轉(zhuǎn)型（MR->Stream）的基礎(chǔ)，而這一點(diǎn)為后來Blink流引擎在搜索離線的孕育和發(fā)展也埋下了伏筆。

當(dāng)然Hbase也不是毫無缺點(diǎn)，JVM內(nèi)存管理的痼疾、單機(jī)Handler打滿導(dǎo)致雪崩、缺乏容器化部署能力等也帶來了不少煩惱，很快我們就會(huì)替換Hbase為阿里內(nèi)部發(fā)展的另外一套存儲(chǔ)引擎，期望能夠部分的解決這些問題。

?

★ 基于Flink的計(jì)算架構(gòu)

2016年中，搜索離線逐漸開始引入Flink作為計(jì)算引擎，重點(diǎn)解決搜索實(shí)時(shí)計(jì)算場(chǎng)景碰到的大量問題。在社區(qū)Flink版本的基礎(chǔ)上，實(shí)時(shí)計(jì)算團(tuán)隊(duì)開發(fā)了Blink，增加原生yarn模式、Incremetal checkpoint等若干解決Flink大規(guī)模分布式運(yùn)行問題的特性，另一方面，在DataStream/DataSet接口的基礎(chǔ)上，進(jìn)一步加強(qiáng)了TableAPI和SQL的功能，真正統(tǒng)一了Stream和Batch的調(diào)用接口，并實(shí)現(xiàn)計(jì)算業(yè)務(wù)邏輯的sql化開發(fā)模式。

離線平臺(tái)是Blink的早期使用者和開發(fā)者，從0.8版本開始經(jīng)歷了多個(gè)Blink版本的升級(jí)和變遷，先后使用了DataStream、TableAPI和SQL作為任務(wù)接口，同時(shí)也開發(fā)了大量Connector以支持不同數(shù)據(jù)源之間的交互。目前離線平臺(tái)已經(jīng)在使用最新的Blink-2.1.1，Bahamut利用SqlTranslator直接生成SQL來描述任務(wù)邏輯，通過Bayes（Blink SQL開發(fā)平臺(tái)）服務(wù)化直接提交任務(wù)到不同的Yarn集群，這樣做有以下幾個(gè)明顯的優(yōu)勢(shì)：

采用SQL來描述Blink任務(wù)業(yè)務(wù)邏輯非常清晰，可以直接利用Blink提供的各種Operator完成數(shù)據(jù)處理，方便任務(wù)的調(diào)試，例如：dim join、groupby，而不是在Datastream時(shí)期需要自行編寫完成類似Hbase Join的Operator。

Blink 2.1原生支持Batch，采用Batch模式可以直接完成生成HFile的任務(wù)，下線MR任務(wù)，徹底統(tǒng)一計(jì)算引擎到Blink。Batch模式任務(wù)執(zhí)行時(shí)采用分階段調(diào)度可以大幅的節(jié)省計(jì)算資源，提高集群效率。Blink SQL可以通過修改提交模式，分別轉(zhuǎn)化為Stream或Batch任務(wù)，在保持業(yè)務(wù)邏輯穩(wěn)定的同時(shí)方便任務(wù)調(diào)試和驗(yàn)證。

通過Bayes這樣的開發(fā)平臺(tái)服務(wù)化的方式提交任務(wù)到不同集群，徹底解決以前任務(wù)通過GateWay提交運(yùn)維復(fù)雜的問題，添加新的Yarn集群只需要簡(jiǎn)單配置即可完成。另外在Bayes上同樣會(huì)保存Bahamut自動(dòng)生成提交的Sql，可以在Bayes上直接進(jìn)行任務(wù)的調(diào)試和管理，方便了開發(fā)人員。

下圖是一個(gè)Bahamut自動(dòng)生成的Blink Sql樣例，描述同步層的一個(gè)任務(wù)，任務(wù)中包含Source，Select Oper和Sink三個(gè)Operator，實(shí)現(xiàn)從Mysql實(shí)時(shí)變化到Hbase表的同步。

-- 定義數(shù)據(jù)源表，這是一個(gè)DRC（Mysql binlog流）源CREATE TABLE DRCSource_1 (`tag_id` ? ? ? ? ? ? ? ? ? ? ? ?VARCHAR,`act_info_id` ? ? ? ? ? ? ? ? ? ?VARCHAR, ) with (tableFactoryClass='com.alibaba.xxx.xxx.DRCTableFactory',-- other config);-- 定義輸出表 CREATE TABLE HbaseSink_1 (`tag_id` ? ? ? ? ? ? ? ? ? ?VARCHAR,`act_info_id` ? ? ? ? ? ? ? VARCHAR, ) with (class='com.alibaba.xxx.xxx.CombineSink',hbase_tableName='bahamut_search_tmall_act',-- other config);-- 定義Blink任務(wù)的業(yè)務(wù)邏輯 INSERT INTO HbaseSink_1SELECT`tag_id`,`act_info_id`, FROM DRCSource_1;

?

總結(jié)

搜索離線數(shù)據(jù)處理是一個(gè)典型的海量數(shù)據(jù)批次/實(shí)時(shí)計(jì)算結(jié)合的場(chǎng)景，搜索中臺(tái)團(tuán)隊(duì)立足內(nèi)部技術(shù)結(jié)合開源大數(shù)據(jù)存儲(chǔ)和計(jì)算系統(tǒng)，針對(duì)自身業(yè)務(wù)和技術(shù)特點(diǎn)構(gòu)建了搜索離線平臺(tái)，提供復(fù)雜業(yè)務(wù)場(chǎng)景下單日批次處理千億級(jí)數(shù)據(jù)，秒級(jí)實(shí)時(shí)百萬TPS吞吐的計(jì)算能力。離線平臺(tái)目前支持了集團(tuán)內(nèi)200多個(gè)不同業(yè)務(wù)線的搜索業(yè)務(wù)需求，大幅提高了業(yè)務(wù)迭代的效率，成為搜索中臺(tái)的重要組成部分。很快離線平臺(tái)還會(huì)在阿里云上與Opensearch/ES結(jié)合，為集團(tuán)外客戶提供高可用、高性能的搜索離線數(shù)據(jù)處理能力。在不遠(yuǎn)的將來離線平臺(tái)將會(huì)逐漸拓展到推薦和廣告的數(shù)據(jù)處理場(chǎng)景，有著廣闊的應(yīng)用場(chǎng)景，一個(gè)涵蓋搜索/推薦/廣告體系的SARO（Search Advertisment and Recommandation Offline）平臺(tái)會(huì)逐步成型。

?

總結(jié)

以上是生活随笔為你收集整理的揭秘阿里秒级百万TPS平台架构实现的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。