作者：聞意

Havenask 是阿里巴巴智能引擎事業(yè)部自研的開源高性能搜索引擎，深度支持了包括淘寶、天貓、菜鳥、高德、餓了么在內(nèi)幾乎整個阿里的搜索業(yè)務(wù)。本文針對性介紹了 Havenask 的消息系統(tǒng)--Swift，它是一個設(shè)計用于處理大規(guī)模的數(shù)據(jù)流和實時消息傳遞的高性能、可靠的消息系統(tǒng)。

一、Havenask 介紹

Havenask 是阿里巴巴廣泛使用的自研大規(guī)模分布式檢索系統(tǒng)，是過去十多年阿里在電商領(lǐng)域積累下來的核心競爭力產(chǎn)品，廣泛應(yīng)用在搜推廣和大數(shù)據(jù)檢索等典型場景。在 2022 年云棲大會-云計算加速開源創(chuàng)新論壇上完成開源首發(fā)，同時作為阿里云開放搜索 OpenSearch 底層搜索引擎，OpenSearch 自 2014 年商業(yè)化，目前已有千余家外部客戶。

下圖展示了 Havenask 中一個完整的搜索服務(wù)：在線系統(tǒng)、索引系統(tǒng)、管控系統(tǒng)、擴展插件，且包括了查詢流、數(shù)據(jù)流、控制流。其中數(shù)據(jù)流的主要載體就是消息系統(tǒng) Swift，索引系統(tǒng)各個角色之間的數(shù)據(jù)傳遞、離線到在線的實時數(shù)據(jù)傳遞都是通過 Swift 完成。

Havenask 支持千億級別數(shù)據(jù)實時檢索、百萬 QPS 查詢，百萬 TPS 高時效性寫入保障，毫秒級查詢延遲和數(shù)據(jù)更新，并具有良好的分布式架構(gòu)、極致的性能優(yōu)化，能夠?qū)崿F(xiàn)比現(xiàn)有技術(shù)方案更低的成本，普惠更多的開發(fā)者和企業(yè)。

二、Swift 簡介

Swift 是一種經(jīng)過精心構(gòu)思和設(shè)計的消息傳遞與大規(guī)模數(shù)據(jù)流處理系統(tǒng)，主要目標是為了適應(yīng)現(xiàn)代分布式架構(gòu)對彈性、高并發(fā)以及低延遲應(yīng)用的要求。相較于業(yè)界廣泛應(yīng)用的傳統(tǒng)消息隊列技術(shù)，Swift 在架構(gòu)設(shè)計理念層面展現(xiàn)了一定程度的創(chuàng)新與突破。

傳統(tǒng)消息隊列為了確保消息安全性及持久化，普遍采用先將消息落地到本地磁盤再確認發(fā)送成功的策略。然而，這種模式無形中對系統(tǒng)的可遷移性、擴展性和資源復(fù)用性形成了約束，因為在單一或有限數(shù)量的物理機上存儲消息數(shù)據(jù)，一旦發(fā)生機器遷移，必然伴隨數(shù)據(jù)遷移過程，且可能引發(fā)性能瓶頸。尤其是在與其他應(yīng)用共享計算資源時，由于 I/O 操作的不穩(wěn)定性及其對性能的影響顯著，往往需要將消息隊列運行于專用且獨占的硬件環(huán)境。

近年來，計算與存儲分離架構(gòu)已經(jīng)成為學術(shù)界與工業(yè)界的關(guān)注焦點與實踐熱點。其最大優(yōu)勢在于解耦了計算任務(wù)與數(shù)據(jù)存儲的位置限制，使得計算資源在先進調(diào)度算法的驅(qū)動下能夠?qū)崿F(xiàn)近乎無限的水平擴展。與此同時，諸如 HDFS 和 PANGU 等分布式存儲系統(tǒng)可以提供 PB 級別的海量存儲空間，并支持百萬級別的文件讀寫操作，從而顯著提升了整體系統(tǒng)的彈性和處理效能。

Swift 消息系統(tǒng)是在計算與存儲分離上的一次嘗試，其主要特點包括：

• 每個計算結(jié)點都是無狀態(tài)的，即每個 worker 上除 log 記錄，不存儲任何消息系統(tǒng)相關(guān)數(shù)據(jù)。系統(tǒng)的狀態(tài)數(shù)據(jù)存儲在 Zookeeper 上，消息的內(nèi)容則存儲在分布式文件系統(tǒng)如 HDFS 上。

• 每個計算結(jié)點都是等價的，只要消息系統(tǒng)需要計算資源，就可以通過調(diào)度系統(tǒng)不停的申請并提升整個消息系統(tǒng)的服務(wù)能力。

• Swift 自身的 client 與 server 的消息讀寫協(xié)議，能夠保證消息高效可靠的傳遞。

三、Swift 系統(tǒng)結(jié)構(gòu)

Swift 的系統(tǒng)結(jié)構(gòu)中，主要分成 2 種 worker：Admin 和 Broker。Admin 和 Broker 的資源分配與啟動都是基于調(diào)度系統(tǒng)。當前 Havenask 開源版本支持基于 Hippo 封裝的 SSH 進行調(diào)度，這 2 種 worker 都會有很多個實例，Broker worker 都是等價的，Admin worker 則有一個 leader，其余的等價，這些 worker 一般在 Docker 容器中工作。

• Admin 角色主要負責：

1. Topic 的增刪改?；

2. Topic 對應(yīng)物理 Partition 與 Broker 調(diào)度 ；

3. Client 讀寫數(shù)據(jù)時物理 Partition 的定位；

4. 資源的調(diào)整，如 Broker 個數(shù)的增減等。

• Broker 角色主要負責：

1. Partition 相關(guān)的消息的讀寫 ；

2. Partition 相關(guān)數(shù)據(jù)的管理如過期數(shù)據(jù)的清理等。

四、Swift Topic 介紹

Swift 系統(tǒng)中的 Topic 與其它消息系統(tǒng)的類似，它是一堆相關(guān)消息的集合，通常由業(yè)務(wù)自定義。在 Swift 中，Topic 是由 65536 個邏輯分區(qū)組成，編號是[0?- 65535]。在 Swift 消息系統(tǒng)內(nèi)部，Topic 是由 Partition 組成的，每個 Partition 負責一個 range 的邏輯 Partition 讀寫。

在用戶層面，用戶看不到 Swift 的物理 Partition，寫消息時要么需要提供一個 hash 字段（由 Swift client 自動映射到相應(yīng)的邏輯分區(qū)）要么提供一個 0-65535 的邏輯編號。Swift 根據(jù) Topic 下每個 Partition 的服務(wù) range，把消息寫入相應(yīng) Partition 的 writer 中。Writer 可以通過同步與異步方式把消息 append 到對應(yīng)的物理 Partition 中。

Topic 的物理 Partition 個數(shù)影響整個 Topic 的讀寫能力，通過邏輯 Partition 與物理 Partition 映射，當 Topic 的服務(wù)能力不足時，可以動態(tài)的擴展物理 Partition 來提升讀寫能力。另外，物理 Partition 是 Swift 的基本調(diào)度單元，Admin 會根據(jù)每個 Broker worker 負載，盡可能平衡地調(diào)度 Partition。

五、Swift 消息可靠傳遞機制

先前提到傳統(tǒng)的消息系統(tǒng)為了保證消息的可靠性，在寫消息時需要先落盤，以防機器掛掉時消息丟失。Swift 也提供類似的模式，但落盤的對象是分布式文件系統(tǒng)如 HDFS。這種模式下正常寫落盤消息延時的毫秒級，當 HDFS 壓力大時，會變成秒級，所以其性能不太穩(wěn)定。

Swift 設(shè)計了一種 client 與 Broker 之間,Broker 與 HDFS 之間的消息寫入與確認協(xié)議來保證消息高效可靠的寫入與持久化，其機制類似 TCP 的滑動窗口協(xié)議。下圖是消息異步安全發(fā)送的示意圖。Broker 在分配到 Partition 進行服務(wù)時，會生成一個標記，其由 Partition 的版本號(V)，Broker 加載 Partition 時間戳(S)以及消息持久化的 checkpoint (C)組成。Client 在向 Admin 定位到 Partition 所在 Broker 的時候也會獲取 Partition 的版本號(V)。版本號 V 主要在 Topic 屬性發(fā)生變化時（例如 Partition 的個數(shù)等）會更新。時間戳在每次 Partition 發(fā)生重新加載或調(diào)度都會發(fā)生變化。

• 用戶通過客戶端寫入一條消息，client 定位到寫哪個物理 Partition，同時把消息寫入到對應(yīng)的 buffer 中。用戶寫消息時，還可以給每條消息設(shè)置一個遞增編號，Swift client 會自動映射寫消息進度與編號的關(guān)系。在異步模式中，client 會有專門的提交線程與 Broker 進行通信。

• Client 第一次向 Partition 發(fā)送消息時，Broker 會驗證 Partition 的版本 V0, 匹配后才會接受消息，同時會把三元組(V，S, C)返回。client 收到 accept 消息后，會更新已接受消息的光標和協(xié)議的三元組信息。

• 客戶端可以持續(xù)地寫入消息，同時 Broker 把 Partition 中的消息做異步持久化，當持久化成功時，會更新持久化信息(Ca)。持久化成功的消息在內(nèi)存中不會馬上刪除，只有內(nèi)存不足時才會被回收。

• Client 的后臺發(fā)送線程繼續(xù)工作，發(fā)送消息 b，同時請求帶上了(V0,S0)。

• Broker 端驗證(V0,S0)，收受消息 b，順便把持久化信息也返回(V0,S0,Ca), client 接收到 accept 信息后，更新已發(fā)送的光標到 b，同時更新已接受的光標到 a。消息 a 已經(jīng)持久化成功，在使用的內(nèi)存將會被 writer 回收。Writer 更新 checkpoint (Ca)給用戶層，表示消息 a 已經(jīng)持久化。

• 同 3 一樣，client 繼續(xù)寫消息 c，Broker 繼續(xù)持久化消息 b。

• 此時 Partition 發(fā)生了調(diào)度（例如被分配到了其它機器），其 HDFS 上的文件消息馬上可以讀取到，但內(nèi)存中的消息會被清空。此時 Partition 加載時間戳變成了 S1。Client 向 Admin 重新定位到 Partition 的服務(wù) Broker 寫入的消息 c 和(V0,S0)。

• Broker 檢查 client 發(fā)送的(V0,S0)與自身的(V0,S1)不相等，將拒絕此次消息的寫入。主要基于消息在 Partition 內(nèi)要求保序考慮。此時 client 還不知道 b 是否被序列化成功，Partition 重新被加載 b 是否被序列化成功的信息也會被丟棄(無狀態(tài))，所以它也不知道。因 Broker 返回(V0,S1,C0)，要求 client 重新發(fā)送未持久化的所有消息。

• Client 重置已發(fā)送光標到 b 之前，更新 S1 并重新發(fā)送消息 b 和 c。

• Broker 檢驗 client 的(V0,S1)并收受消息 b 和 c，這時消息 b 會被再次持久化到 HDFS 上。Client 重新更新已發(fā)送光標到 c。如果此后無新消息的寫入，且 buffer 中的消息還有未被持久化的，client 會發(fā)起一次空寫操作獲取最新的持久化信息。

步驟 1-10 是異步消息寫入的工作方式，用戶層可以獲取到當前持久化消息的 checkpoint，可以自己記錄發(fā)送進度以便回滾。如果不方便記錄發(fā)送進度，可以在寫完一段數(shù)據(jù)后，調(diào)用 flush 方法強制把數(shù)據(jù)從 client 的 buffer 放到 Broker 的 buffer 中。此時消息雖然沒有被持久化，但在 client 與 Partition 各存一份。所以只有在 Broker 與 client 同時掛掉才出現(xiàn)消息丟失，因此我們認為這種方法也是比較安全的。

Swift Partition 的寫 buffer 緩存所有寫入的消息，只有當空間不足時，消息內(nèi)存空間才會被回收。對文件上的消息讀取，也會以塊 buffer 的方式做緩存。Partition 之間的 buffer 和文件 cache buffer 都是共享存儲，由統(tǒng)一的回收模塊管理。其保證冷門的 Partition 基本不消耗資源，熱門的 Partition 可以利用非常的多資源。

正常情況下，Swift 的內(nèi)存可以緩存 1-10 分鐘的消息，所以消費消息時基本上從內(nèi)存讀取，讀的性能也會很高效。在這個協(xié)議下，寫 HDFS 發(fā)生偶爾抖動也不會影響消息的時效性，實際中 HDFS 在 10 分鐘內(nèi)的掛機也不影響消息的實時傳遞。

六、Swift Admin

相比較其他消息中間件，如 Kafka、Metaq，Swift 多了一個 Admin 的角色。Admin 的存在使得對集群的操作有統(tǒng)一的入口，系統(tǒng)的容錯性也更為強大。

Swift Admin 的另一個重要功能就是進行 Partition 的動態(tài)調(diào)度，簡單來說就是將所有的邏輯 Partition 向 Broker 上進行任務(wù)分配的過程。

七、Swift Broker

Broker 是 Swift 消息發(fā)送和讀取的載體，由 Admin 通過調(diào)用 hippo 進行啟動和調(diào)度。Broker 是單獨的一個進程，單臺物理機器可以運行多個 Broker。Broker 加載的最小單位是 Topic 的 Partition，一個進程內(nèi)可以加載相同 Topic 的多個不同 Partition。Partition 由所在的分組名稱、Topic 的名字以及列數(shù)所決定。

Broker 在接收消息時，默認先寫到內(nèi)存中，然后由后臺線程進行消息的持久化，一般是寫到 HDFS 上，這樣可以保證 Broker 在遷移或者重啟后仍然可以讀到消息。讀消息時也是先從內(nèi)存消息中讀取，讀取不到再從 HDFS 中進行讀取，以保證消息讀取的效率。

Broker 與 Admin 之間通過 zookeeper 進行通信，Admin 會將需要 Broker 加載的 Partition 信息放到 zk 的指定路徑的文件中，文件名即 Broker 機器地址，對應(yīng)的 Broker 會監(jiān)控此路徑，當內(nèi)容發(fā)生變化時進行任務(wù)的讀取，即 Partition 的加載。同時 Broker 會實時向 Admin 匯報心跳，內(nèi)容即加載 Partition 的信息，Admin 再根據(jù) Broker 的心跳信息進行決策。

八、Swift Client

Swift Client 包括 Writer 和 Reader，分別介紹如下：

• Swift Writer

用戶在向 Swift 寫消息的時候，消息從客戶端的寫出到最終 HDFS 的落盤，如下圖所示，中間經(jīng)歷了兩個 buffer，分別是客戶端的 buffer 和 Broker 端的 buffer。而在確認結(jié)果時，也提供了 waitSent 和 waitFinish 兩個接口來分別確認消息發(fā)送的位置。

• Swift?reader

Swift 在進行消息讀取的時候，單 Partition 保證有序，多 Partition 順序不做保證。Swift Reader 每次都會從單個 partition 對應(yīng)的 SingleReader 中遍歷找到擁有最小時間戳的消息，然后批量進行讀取，存入 buffer 中等待用戶消費，消費完成后，再次進行遍歷獲取最小時間戳的消息。所以 Swift 讀消息時候不保證多 Partition 之間有序。

九、總結(jié)

Swift 作為 Havenask 消息系統(tǒng)的核心組件，通過計算與存儲分離架構(gòu)，提升系統(tǒng)的可擴展性和資源利用率。在 Swift 中，Topic 由多個邏輯分區(qū)組成，每個分區(qū)對應(yīng)一個或多個物理 Partition，通過動態(tài)調(diào)度和映射，可以靈活調(diào)整 Topic 的讀寫能力。

Swift 采用了一種類似于 TCP 滑動窗口協(xié)議的機制來保證消息的高效可靠傳遞，即使在出現(xiàn) Partition 遷移或 Broker 重啟的情況下，也能確保消息不丟失且維持高時效性。此外，Swift 還引入了 Admin 角色，提供了一個集中式入口進行集群管理和操作，顯著增強了系統(tǒng)的容錯能力和運維效率。

同時，Swift 實現(xiàn)了對 Partition 的動態(tài)調(diào)度等多種優(yōu)化，以適應(yīng)現(xiàn)代分布式架構(gòu)對于彈性、高并發(fā)和低延遲的需求。

關(guān)注我們

[01]Havenask 開源官網(wǎng)

https://havenask.net/

[02]?Havenask-Github?開源項目地址

https://github.com/alibaba/havenask

[03]?阿里云?OpenSearch?官網(wǎng)

https://www.aliyun.com/product/opensearch

釘釘掃碼加入 Havenask 開源官方技術(shù)交流群文章來源地址http://www.zghlxwxcb.cn/news/detail-840688.html

到了這里，關(guān)于【前沿技術(shù)】 阿里開源搜索引擎 Havenask 的消息系統(tǒng)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！