公眾號(hào)記得加星標(biāo)??，第一時(shí)間看推送不會(huì)錯(cuò)過(guò)。

Unified Bus 的協(xié)議文檔終于發(fā)布了。協(xié)議最初的設(shè)計(jì)大多數(shù)是四五年前的工作了，我也有兩年多沒(méi)有繼續(xù)做網(wǎng)絡(luò)互聯(lián)方面的工作，但今天讀到這本 500 多頁(yè)的文檔，還是倍感親切。

與大多數(shù)協(xié)議文檔一樣，UB 文檔介紹了 Unified Bus 協(xié)議的大量細(xì)節(jié)，但很少涉及它設(shè)計(jì)背后的思考。作為曾在早期參與 UB 項(xiàng)目的一名小兵，介紹一些我個(gè)人的思考。今天產(chǎn)品化的 UB 可能與我們當(dāng)年的設(shè)計(jì)有諸多不同，因此不要把本文作為權(quán)威指南。當(dāng)成段子看就行了。

為什么要做 UB

要理解 Unified Bus (UB) 誕生的必然性，我們必須回到一個(gè)計(jì)算機(jī)體系結(jié)構(gòu)中的根本性矛盾：總線（Bus）與網(wǎng)絡(luò)（Network）的割裂。

長(zhǎng)久以來(lái)，計(jì)算機(jī)世界被這兩種截然不同的互聯(lián)范式劃分為一個(gè)個(gè)孤島。

在孤島內(nèi)部（例如一臺(tái)服務(wù)器或一個(gè)機(jī)箱內(nèi)），我們使用總線技術(shù)，如 PCIe 或 NVLink。它們是為緊耦合系統(tǒng)設(shè)計(jì)的，設(shè)備間共享著統(tǒng)一的物理地址空間，通信延遲可以做到納秒級(jí)，帶寬極高。這是性能的天堂，但這個(gè)天堂的疆域極其有限——總線的物理距離和可連接的設(shè)備數(shù)量都受到嚴(yán)格限制。

在孤島之間，我們則依賴網(wǎng)絡(luò)技術(shù)，如以太網(wǎng)或 InfiniBand。它們?yōu)樗神詈舷到y(tǒng)而生，擅長(zhǎng)將成千上萬(wàn)的節(jié)點(diǎn)連接起來(lái)，具備超強(qiáng)的擴(kuò)展性。但這種擴(kuò)展性是有代價(jià)的：復(fù)雜的協(xié)議棧、額外的轉(zhuǎn)發(fā)開(kāi)銷(xiāo)、微秒甚至毫秒級(jí)的延遲，都讓網(wǎng)絡(luò)的性能與總線相比，存在著數(shù)量級(jí)的鴻溝。

這種”內(nèi)外有別”的架構(gòu)，在很長(zhǎng)一段時(shí)間里是行之有效的。然而，一個(gè)幽靈開(kāi)始在計(jì)算機(jī)世界上空盤(pán)旋——Scaling Law。

大約 10 年前，深度學(xué)習(xí)領(lǐng)域的研究者們發(fā)現(xiàn)了一個(gè)驚人的規(guī)律：只要持續(xù)增大模型規(guī)模、數(shù)據(jù)量和計(jì)算量，模型的性能就會(huì)隨之可預(yù)見(jiàn)地、持續(xù)地提升。這個(gè)發(fā)現(xiàn)徹底改變了游戲規(guī)則。曾經(jīng)被認(rèn)為是”足夠用”的單機(jī) 8 卡配置，在動(dòng)輒百億、千億參數(shù)的巨型模型面前，瞬間變得杯水車(chē)薪。

此時(shí)，一個(gè)清晰而迫切的需求擺在了所有系統(tǒng)架構(gòu)師面前：我們能否推倒總線與網(wǎng)絡(luò)之間的這堵墻？我們能否創(chuàng)造一種統(tǒng)一的互聯(lián)，既擁有總線級(jí)的編程簡(jiǎn)易度和極致性能，又具備網(wǎng)絡(luò)級(jí)的超大規(guī)模擴(kuò)展能力？

這正是 UB 的核心使命。它不僅僅是對(duì)現(xiàn)有協(xié)議的修補(bǔ)或改良，而是一次徹底的重構(gòu)。UB 的目標(biāo)，是構(gòu)建一個(gè)真正的”數(shù)據(jù)中心計(jì)算機(jī)”（Datacenter-scale Computer），將整個(gè)集群的異構(gòu)算力、內(nèi)存、存儲(chǔ)無(wú)縫地連接成一個(gè)統(tǒng)一的、可編程的整體。在這個(gè)愿景中，訪問(wèn)一臺(tái)遠(yuǎn)程服務(wù)器上的內(nèi)存，應(yīng)該像訪問(wèn)本地內(nèi)存一樣簡(jiǎn)單自然；上萬(wàn)個(gè)處理器協(xié)同計(jì)算，應(yīng)該像在一塊芯片上一樣高效。

主從架構(gòu)與對(duì)等架構(gòu)

傳統(tǒng)的計(jì)算機(jī)系統(tǒng)中，CPU 和其他設(shè)備（如內(nèi)存、存儲(chǔ)、網(wǎng)卡）之間通常是主從架構(gòu)。CPU 是主（Master），負(fù)責(zé)發(fā)起和控制所有的數(shù)據(jù)傳輸，而其他設(shè)備是從（Slave），被動(dòng)地響應(yīng) CPU 的指令。PCIe、RDMA 都是這種主從架構(gòu)的產(chǎn)物。在 CPU 性能服從摩爾定律一騎絕塵的幾十年前，主從架構(gòu)有其歷史優(yōu)勢(shì)。但在異構(gòu)計(jì)算成為主流的今天，主從架構(gòu)就日益成為現(xiàn)代計(jì)算系統(tǒng)的瓶頸。

• 性能瓶頸：所有 I/O 操作都需要 CPU 介入，隨著設(shè)備數(shù)量和速度的增加，CPU 成為整個(gè)系統(tǒng)的瓶頸。

• 延遲較高：數(shù)據(jù)路徑長(zhǎng)，需要經(jīng)過(guò)多層軟件棧，帶來(lái)額外的軟件開(kāi)銷(xiāo)和數(shù)據(jù)拷貝，導(dǎo)致延遲增加。即使 RDMA 等技術(shù)可以實(shí)現(xiàn) CPU 上的用戶態(tài)軟件直通網(wǎng)卡，仍然受限于 PCIe uncacheable 的諸多限制，無(wú)法實(shí)現(xiàn)真正的分布式共享內(nèi)存。

• 擴(kuò)展性差：在異構(gòu)計(jì)算場(chǎng)景下，大量 GPU、NPU 等智能設(shè)備都需要和 CPU 通信，主從架構(gòu)難以高效擴(kuò)展，無(wú)法形成設(shè)備間的高效”橫向”數(shù)據(jù)交換。

為了打破這一瓶頸，UB 提出了一種對(duì)等架構(gòu)。在 UB 的世界里，所有設(shè)備都是平等的，可以被看作是一個(gè)個(gè)內(nèi)存塊。任何設(shè)備都可以通過(guò) Load/Store 這樣的內(nèi)存語(yǔ)義，像訪問(wèn)本地內(nèi)存一樣，直接訪問(wèn)其他設(shè)備的內(nèi)存，而不需要對(duì)方 CPU 的干預(yù)。這使得數(shù)據(jù)路徑可以完全繞過(guò)操作系統(tǒng)，實(shí)現(xiàn)零拷貝和微秒級(jí)的超低延遲。

這種對(duì)等架構(gòu)帶來(lái)了許多好處。例如，不同服務(wù)器的內(nèi)存可以組成一個(gè)共享的內(nèi)存池，一個(gè)計(jì)算密集的應(yīng)用服務(wù)器上空閑的內(nèi)存，可以被一個(gè)內(nèi)存密集的應(yīng)用服務(wù)器高效利用。各種異構(gòu)的計(jì)算資源、存儲(chǔ)資源也可以池化，根據(jù)應(yīng)用的需求動(dòng)態(tài)組合，提高了資源利用率，也減少了不必要的數(shù)據(jù)搬運(yùn)。

總線與網(wǎng)絡(luò)

要理解 UB 的設(shè)計(jì)哲學(xué)，就需要理解總線和網(wǎng)絡(luò)的根本區(qū)別。當(dāng)然，我們不應(yīng)陷入摳概念的辯經(jīng)，現(xiàn)代的總線（如 PCIe）也借鑒了網(wǎng)絡(luò)的交換思想，但從設(shè)計(jì)目標(biāo)和應(yīng)用規(guī)模上看，它們的范式差異是顯著的。

傳統(tǒng)上，我們?cè)谝粋€(gè)”超節(jié)點(diǎn)”（例如一臺(tái)服務(wù)器或一個(gè)機(jī)箱）范圍內(nèi)使用總線技術(shù)以追求極致性能；而在超節(jié)點(diǎn)之間，則使用網(wǎng)絡(luò)技術(shù)以追求大規(guī)模擴(kuò)展。這是兩種完全不同的技術(shù)棧和編程抽象。

UB 的核心價(jià)值在于，它在架構(gòu)和編程抽象上實(shí)現(xiàn)了統(tǒng)一。無(wú)論物理上是超節(jié)點(diǎn)內(nèi)的高速電信號(hào)背板，還是超節(jié)點(diǎn)間的長(zhǎng)距離光纖，UB 都為上層應(yīng)用提供了統(tǒng)一的內(nèi)存語(yǔ)義。

這意味著，UB 承認(rèn)在底層的物理實(shí)現(xiàn)上，超節(jié)點(diǎn)內(nèi)（更像總線）和超節(jié)點(diǎn)間（更像網(wǎng)絡(luò)）的互聯(lián)技術(shù)可以是不同的，但它通過(guò)一層統(tǒng)一的抽象，將這種物理差異向應(yīng)用屏蔽了。這最終實(shí)現(xiàn)了”魚(yú)與熊掌兼得”：既有總線級(jí)的編程簡(jiǎn)易度和高性能潛力，又具備網(wǎng)絡(luò)級(jí)的超大規(guī)模擴(kuò)展能力。

總線與網(wǎng)絡(luò)的區(qū)別，并非對(duì)錯(cuò)之分，而是在不同尺度下的范式差異。正如牛頓力學(xué)在宏觀低速世界中足夠精確和簡(jiǎn)潔，而我們只有在接近光速或深入微觀時(shí)才需要相對(duì)論和量子力學(xué)。長(zhǎng)久以來(lái)，我們?cè)凇瘷C(jī)箱內(nèi)’這個(gè)宏觀世界里安心使用總線這個(gè)經(jīng)典范式，而在’數(shù)據(jù)中心’這個(gè)相對(duì)論尺度上則依賴網(wǎng)絡(luò)。然而，AI 的 Scaling Law 如同一種新的觀測(cè)工具，它將計(jì)算的需求推向了極致，讓兩個(gè)尺度之間的’裂痕’——即通信鴻溝——變得無(wú)法忽視。這正是 UB 誕生的歷史必然性：我們需要一個(gè)能統(tǒng)一這兩個(gè)尺度的新范式。

太陽(yáng)底下沒(méi)有新鮮事

太陽(yáng)底下沒(méi)有新鮮事。在一個(gè)領(lǐng)域做了一段時(shí)間后，就會(huì)發(fā)現(xiàn)解決問(wèn)題就像搭積木，首先列出有哪些關(guān)鍵問(wèn)題，然后對(duì)每個(gè)關(guān)鍵問(wèn)題，從已有的方案中選出一個(gè)，組合起來(lái)就行了。

例如網(wǎng)絡(luò)，最關(guān)鍵的問(wèn)題就幾個(gè)：

• 給應(yīng)用程序提供什么編程抽象？

• 編程抽象在什么層次上實(shí)現(xiàn)，在硬件、操作系統(tǒng)、編程語(yǔ)言和運(yùn)行時(shí)，以及應(yīng)用程序之間，如何劃分？

• 在上述功能劃分的基礎(chǔ)上，軟硬件之間的接口如何設(shè)計(jì)？

• 每個(gè)設(shè)備歸誰(shuí)管理？哪些設(shè)備一起上電啟動(dòng)？

• 報(bào)文在網(wǎng)絡(luò)上用什么粒度切分傳輸？

• 采用什么方式分配地址？

• 網(wǎng)絡(luò)用什么拓?fù)浣Y(jié)構(gòu)？

• 網(wǎng)絡(luò)中的節(jié)點(diǎn)用什么方式發(fā)現(xiàn)？

• 有了地址之后，怎么做路由？要不要支持多路徑？

• 點(diǎn)到點(diǎn)，網(wǎng)絡(luò)每條鏈路上的的流控（flow control）要不要做，怎么做？

• 端到端，跨越多條鏈路的的擁塞控制（congestion control）要不要做，怎么做？

• 是否提供可靠傳輸?shù)恼Z(yǔ)義，如果是，丟包如何檢測(cè)，如何重傳？其他故障如何處理和上報(bào)？

• 是否提供保序傳輸?shù)恼Z(yǔ)義，如果是，如何實(shí)現(xiàn)？

• 是提供字節(jié)流語(yǔ)義，還是消息語(yǔ)義？

• 是否提供共享內(nèi)存的語(yǔ)義，如果是，是否提供緩存一致性？共享內(nèi)存的訪問(wèn)是可以用單條硬件指令實(shí)現(xiàn)，還是需要軟件執(zhí)行多條指令？

• 如果編程抽象中提供了其他語(yǔ)義，如何實(shí)現(xiàn)？

• 認(rèn)證鑒權(quán)和加密問(wèn)題怎么解決？

這些問(wèn)題都想清楚了，回答了，設(shè)計(jì)就做得七七八八了。類(lèi)似的這么一種方法在其他領(lǐng)域其實(shí)也適用。例如，今天的 AI Agent，無(wú)非是選哪個(gè)模型，用戶記憶怎么實(shí)現(xiàn)，知識(shí)庫(kù)怎么實(shí)現(xiàn)，上下文工程用哪幾種技巧，工具集合有哪些，哪些工作流需要提取成 sub-agent。

單邊語(yǔ)義與雙邊語(yǔ)義

單邊語(yǔ)義（內(nèi)存語(yǔ)義）

《神雕俠侶》中楊過(guò)和小龍女的十六年之約，就是單邊語(yǔ)義很好的一個(gè)例子。楊過(guò)與小龍女在絕情谷底身中情花劇毒，小龍女自知時(shí)日無(wú)多，為求解藥，也為激勵(lì)楊過(guò)求生，她選擇跳下斷腸崖，并在崖壁上刻下”十六年后，在此相會(huì)，夫妻情深，勿失信約”。她留下這行字，是希望楊過(guò)相信她仍然在世，并以此為信念，耐心等待十六年?？套种螅憧v身跳下了懸崖。

小龍女在崖壁上刻字，就是一個(gè)單邊的”寫(xiě)”操作，她并不需要楊過(guò)在場(chǎng)確認(rèn)。十六年后，楊過(guò)如約而至，看到了崖壁上的字，并最終在谷底與小龍女重逢。楊過(guò)的”讀”操作，同樣是單邊的，他只是讀取崖壁上的信息，而不需要小龍女在場(chǎng)。在計(jì)算機(jī)網(wǎng)絡(luò)中，這種通信模式被稱(chēng)為”單邊語(yǔ)義”。信息的發(fā)送方（小龍女）可以將數(shù)據(jù)直接寫(xiě)入接收方（楊過(guò)）可以訪問(wèn)的某個(gè)位置（崖壁），而接收方可以在自己方便的時(shí)候去讀取，整個(gè)過(guò)程無(wú)需雙方同時(shí)在線。

由于單邊語(yǔ)義主要是讀寫(xiě)操作，它又稱(chēng)為內(nèi)存語(yǔ)義。

注意，單邊語(yǔ)義讀寫(xiě)的對(duì)象不一定是內(nèi)存地址。凡是依賴共享存儲(chǔ)進(jìn)行通信的都屬于單邊語(yǔ)義。例如，Redis 等 Key-Value Store 提供的也是一種單邊語(yǔ)義，這里的 key 不再是內(nèi)存地址，而是一個(gè)字符串。

從楊過(guò)和小龍女的故事中，我們也能發(fā)現(xiàn)單邊語(yǔ)義的一個(gè)缺點(diǎn)：它沒(méi)有辦法通知接收方，發(fā)送方也無(wú)法得知接收方是否收到了這個(gè)信息。楊過(guò)如果沒(méi)有注意看，他就會(huì)錯(cuò)過(guò)崖壁上的字。楊過(guò)有沒(méi)有看到崖壁上的字，小龍女也無(wú)法得知。

雙邊語(yǔ)義（消息語(yǔ)義）

為了解決這個(gè)缺點(diǎn)，需要發(fā)送方和接收方配合的雙邊語(yǔ)義應(yīng)運(yùn)而生。計(jì)算機(jī)網(wǎng)絡(luò)中最早的語(yǔ)義都是雙邊語(yǔ)義：從最早的發(fā)送網(wǎng)絡(luò)數(shù)據(jù)包、接收網(wǎng)絡(luò)數(shù)據(jù)包，然后發(fā)展到通過(guò)連接，發(fā)送數(shù)據(jù)、接收數(shù)據(jù)。

由于雙邊語(yǔ)義主要是消息收發(fā)操作，它又稱(chēng)為消息語(yǔ)義。

聰明的讀者容易發(fā)現(xiàn)，寫(xiě)一個(gè)內(nèi)存地址，跟發(fā)一個(gè)消息給對(duì)面的應(yīng)用，看起來(lái)也很類(lèi)似??？?jī)?nèi)存地址是一個(gè)數(shù)，給對(duì)方發(fā)個(gè)消息是 IP 地址和端口號(hào)，看起來(lái)沒(méi)有什么區(qū)別??？

這里的關(guān)鍵區(qū)別在于 “寫(xiě)” 操作的語(yǔ)義。寫(xiě)內(nèi)存地址時(shí)，每個(gè)地址里只能存一個(gè)數(shù)據(jù)，新的數(shù)據(jù)寫(xiě)入，舊的數(shù)據(jù)就被覆蓋了。而發(fā)消息不一樣，盡管也只要一個(gè)目的地址，但發(fā)的所有消息都會(huì)保存在對(duì)端。如果一個(gè)應(yīng)用只需要接受來(lái)自固定發(fā)送方的消息，那么消息語(yǔ)義也很容易用內(nèi)存語(yǔ)義來(lái)實(shí)現(xiàn)——只要發(fā)送方自己確保數(shù)據(jù)不會(huì)互相覆蓋就行了。但如果有多個(gè)發(fā)送方需要在不確定的時(shí)間向同一個(gè)接收方發(fā)送消息，并且還需要及時(shí)通知接收方，單純的內(nèi)存語(yǔ)義就很麻煩了——如何協(xié)調(diào)這些發(fā)送方，讓它們寫(xiě)內(nèi)存地址的時(shí)候不要發(fā)生沖突呢？此時(shí)消息語(yǔ)義就更合適了。

消息語(yǔ)義聽(tīng)起來(lái)很好，但在高性能網(wǎng)絡(luò)中，它往往容易導(dǎo)致性能問(wèn)題。每次接收消息時(shí)，接收方的 CPU 都需要處理這個(gè)消息。如果只是想讀取一塊數(shù)據(jù)，卻需要麻煩接收方的 CPU 處理，那么性能肯定沒(méi)法很高。

更重要的是，消息語(yǔ)義需要接收方預(yù)先準(zhǔn)備內(nèi)存緩沖區(qū)。那么如果接收方事先不知道要接收的消息有多大，那該準(zhǔn)備多少緩存區(qū)呢？如果接收方要從多個(gè)發(fā)送方分別接收消息，還得做好多個(gè)發(fā)送方幾乎同時(shí)發(fā)送的緩沖區(qū)準(zhǔn)備。一旦接收緩沖區(qū)不足，就會(huì)導(dǎo)致發(fā)送失敗。

從第一性原理出發(fā)，雙邊消息語(yǔ)義更適合用于通知，而單邊內(nèi)存語(yǔ)義更適合用來(lái)傳輸大塊數(shù)據(jù)。就像我要把一個(gè)大文件傳輸給另一個(gè)人，多半是把大文件上傳到網(wǎng)盤(pán)，再發(fā)一封郵件通知對(duì)方去網(wǎng)盤(pán)下載，而不是把大文件直接作為郵件的附件。其中上傳到網(wǎng)盤(pán)和從網(wǎng)盤(pán)下載就是單邊語(yǔ)義，而發(fā)郵件通知就是雙邊語(yǔ)義。

UB 協(xié)議正是提供了這種單邊內(nèi)存操作，允許一臺(tái)服務(wù)器直接讀寫(xiě)另一臺(tái)服務(wù)器的內(nèi)存，而無(wú)需對(duì)方 CPU 的干預(yù)，從而實(shí)現(xiàn)了極高的數(shù)據(jù)傳輸效率和極低的延遲。

對(duì)于雙邊語(yǔ)義，認(rèn)識(shí)到雙邊語(yǔ)義最重要的作用是通知應(yīng)用，是很重要的。如果一個(gè)應(yīng)用有多個(gè)消息等待處理，只要把它們放入一個(gè)隊(duì)列，然后喚醒一次就行了。等應(yīng)用喚醒后，它自然會(huì)依次處理隊(duì)列中的所有消息。傳統(tǒng)上，這些報(bào)文處理和進(jìn)程的事件通知都是通過(guò)中斷和操作系統(tǒng)完成的。而在 UB 中，硬件可以完成數(shù)據(jù)面上大多數(shù)的任務(wù)，從而大大降低操作系統(tǒng)的開(kāi)銷(xiāo)。

當(dāng)然，學(xué)過(guò)分布式系統(tǒng)的都知道，內(nèi)存語(yǔ)義和消息語(yǔ)義是可以互相實(shí)現(xiàn)的。但能實(shí)現(xiàn)不意味著實(shí)現(xiàn)效率高。因此，在不同的場(chǎng)景中，兩種語(yǔ)義都有存在的價(jià)值。UB 的關(guān)鍵是提供高效的內(nèi)存語(yǔ)義，使得大塊數(shù)據(jù)的傳輸、共享數(shù)據(jù)的訪問(wèn)更加高效。

語(yǔ)義的融合：帶立即數(shù)的高效通知

我們希望應(yīng)用使用單邊內(nèi)存語(yǔ)義傳數(shù)據(jù)，使用雙邊消息語(yǔ)義發(fā)通知。但在實(shí)踐中，這兩者常常是耦合的：應(yīng)用在完成一次大規(guī)模數(shù)據(jù)寫(xiě)入后，幾乎總需要再發(fā)起一個(gè)獨(dú)立的消息來(lái)通知對(duì)端”數(shù)據(jù)已備好”。這個(gè)”先寫(xiě)數(shù)據(jù)、再發(fā)通知”的兩步操作，引入了額外的網(wǎng)絡(luò)延遲和軟件開(kāi)銷(xiāo)。

為了消除這種低效，UB 協(xié)議引入了一項(xiàng)優(yōu)雅的創(chuàng)新：帶立即數(shù)（with immediate）的操作。它將數(shù)據(jù)傳輸和輕量級(jí)通知融合為單個(gè)硬件原語(yǔ)，徹底消除了應(yīng)用層發(fā)起第二次通知操作的必要。

1.Write with Immediate

標(biāo)準(zhǔn)的 Write 是一種純粹的單邊操作，數(shù)據(jù)被”靜默”地寫(xiě)入目標(biāo)內(nèi)存，接收方的應(yīng)用對(duì)此毫不知情。而我們提出的 Write with Immediate 則在寫(xiě)入數(shù)據(jù)后，通知對(duì)方應(yīng)用：

• 首先，它像普通的 Write 一樣，由硬件完成一次高效的、繞過(guò)對(duì)端 CPU 的單邊內(nèi)存寫(xiě)入。

• 關(guān)鍵在于，在數(shù)據(jù)寫(xiě)入完成后，UB 硬件會(huì)在接收端的 JFC 中，生成一個(gè)完成事件。

• 這個(gè)完成事件就像一個(gè)雙邊消息一樣，起到了通知對(duì)端應(yīng)用的作用。

• 更進(jìn)一步，這個(gè)由 Write 操作在遠(yuǎn)端生成的完成事件，同樣可以攜帶一個(gè)由發(fā)起方提供的 8 字節(jié)立即數(shù)。

Write with Immediate 就像是網(wǎng)盤(pán)在文件上傳成功后，自動(dòng)幫你給接收方發(fā)送了一封帶有備注（立即數(shù)）的通知郵件。它將”傳輸大塊數(shù)據(jù)”和”發(fā)送通知”這兩個(gè)邏輯步驟，在硬件層面融合成了一個(gè)原子操作，極大地簡(jiǎn)化了應(yīng)用邏輯，并且避免了單邊寫(xiě)入消息和雙邊通知消息之間亂序的問(wèn)題。

2. Send with Immediate

這是對(duì)標(biāo)準(zhǔn)雙邊消息的增強(qiáng)。在發(fā)起 Send 操作時(shí)，除了常規(guī)的數(shù)據(jù)緩沖區(qū)，應(yīng)用還可以附帶一個(gè) 8 字節(jié)的”立即數(shù)”。這個(gè)立即數(shù)不會(huì)被寫(xiě)入接收方的內(nèi)存緩沖區(qū)，而是由硬件直接傳遞到接收方該消息對(duì)應(yīng)的 JFC 完成記錄中。這意味著，接收方應(yīng)用在收到消息完成通知的那一刻，就能立刻從完成記錄中讀到這 8 字節(jié)的元數(shù)據(jù)，無(wú)需再對(duì)內(nèi)存進(jìn)行額外的讀取操作。這對(duì)于傳遞消息類(lèi)型標(biāo)簽等小塊元數(shù)據(jù)非常高效。

有連接和無(wú)連接語(yǔ)義：Jetty 抽象

RDMA “連接”的可擴(kuò)展性挑戰(zhàn)

在 UB 這種顛覆性的范式出現(xiàn)之前，網(wǎng)絡(luò)領(lǐng)域的工程師們?nèi)缤凇Ｒ?guī)科學(xué)’階段的科學(xué)家，致力于在現(xiàn)有的’面向連接’范式內(nèi)解決難題。RDMA 的出現(xiàn)本身就是一次巨大的成功，但隨著數(shù)據(jù)中心規(guī)模的擴(kuò)張，其固有的可擴(kuò)展性問(wèn)題逐漸成為新的’謎題’。在 RDMA 中，通信前必須先”建立連接”，這個(gè)”連接”的實(shí)體就是隊(duì)列對(duì)（Queue Pair, QP）。每個(gè) QP 都包含了發(fā)送隊(duì)列（SQ）和接收隊(duì)列（RQ），以及一整套相關(guān)的狀態(tài)機(jī)，用于處理包序、重傳、確認(rèn)等復(fù)雜的可靠性邏輯。

這種設(shè)計(jì)的代價(jià)是，每一個(gè) QP 的狀態(tài)都必須完整地保存在網(wǎng)卡的片上內(nèi)存（SRAM）中，以便硬件能以線速進(jìn)行處理。在小規(guī)模的高性能計(jì)算集群中，這不成問(wèn)題。但當(dāng)我們將這個(gè)模型應(yīng)用到上萬(wàn)臺(tái)服務(wù)器、每個(gè)服務(wù)器上又運(yùn)行著成百上千個(gè)應(yīng)用進(jìn)程的超大規(guī)模數(shù)據(jù)中心時(shí)，這套模型就撞上了”可擴(kuò)展性的天花板”：

• 硬件資源耗盡：一臺(tái)服務(wù)器要和另外 1000 臺(tái)服務(wù)器通信，就需要維護(hù) 1000 個(gè) QP。網(wǎng)卡的片上內(nèi)存資源極其寶貴，很快就會(huì)被耗盡。

• 管理復(fù)雜度爆炸：應(yīng)用程序和操作系統(tǒng)需要管理海量的連接狀態(tài)，這本身就帶來(lái)了巨大的軟件開(kāi)銷(xiāo)。

為了解開(kāi)這個(gè)謎題，社區(qū)付出了巨大的努力，發(fā)展出了 XRC（eXtended Reliable Connection）和 SRQ（Shared Receive Queue）等技術(shù)。

• SRQ 允許多個(gè) QP 共享同一個(gè)接收隊(duì)列，這在一定程度上減少了接收緩沖區(qū)的內(nèi)存占用，但發(fā)送方依然需要為每個(gè)對(duì)端維護(hù)獨(dú)立的 QP。

• XRC 更進(jìn)一步，允許多個(gè)遠(yuǎn)端節(jié)點(diǎn)共享同一個(gè)目標(biāo) QP，進(jìn)一步減少了連接狀態(tài)。

然而，這些技術(shù)本質(zhì)上都是在原有”面向連接”模型上的”補(bǔ)丁”，它們讓模型變得更復(fù)雜，但沒(méi)有從根本上解決問(wèn)題。當(dāng) Scaling Law 這一巨大的’反?！F(xiàn)象出現(xiàn)時(shí)，我們意識(shí)到，需要的不再是更精巧的補(bǔ)丁，而是一場(chǎng)徹底的范式革命——只要通信還需要應(yīng)用去顯式地創(chuàng)建和管理一個(gè)”連接”狀態(tài)，可擴(kuò)展性的天花板就永遠(yuǎn)存在。

從 “連接” 到 “碼頭”

當(dāng)時(shí)我們意識(shí)到，必須徹底拋棄面向連接的思維模型, 釜底抽薪。這個(gè)想法最終催生了 UB 的核心抽象：Jetty。

傳統(tǒng)的”連接”模型，好比是兩個(gè)港口之間開(kāi)辟了一條專(zhuān)屬的、點(diǎn)對(duì)點(diǎn)的私人航道。而從第一性原理看，通信的本質(zhì)無(wú)非是 “將一份信息，從 A 點(diǎn)可靠地送到 B 點(diǎn)”。通信領(lǐng)域的很多概念，例如 port（港口）、beacon（燈塔）、ping（聲納發(fā)出的聲音）、gateway（可以通航的水道或海峽）、firewall（船上的防水防火隔板），都起源于航海領(lǐng)域。程傳寧老師給我們的無(wú)連接抽象起了個(gè) jetty 的名字，它的本意是從岸上伸出到海里的人造物，例如防波堤或碼頭。

我們特意選擇了’Jetty’（碼頭）這個(gè)詞，而沒(méi)有沿用網(wǎng)絡(luò)領(lǐng)域常見(jiàn)的術(shù)語(yǔ)。庫(kù)恩在《科學(xué)革命的結(jié)構(gòu)》中提到，新范式的建立往往伴隨著新語(yǔ)言的誕生。舊的詞匯，如’連接’，承載了太多舊范式的思維慣性。創(chuàng)造一個(gè)新詞，是為了強(qiáng)制我們用一種全新的世界觀去思考問(wèn)題——不再是點(diǎn)對(duì)點(diǎn)的’私有航道’，而是多對(duì)多的’公共碼頭’。這套新的詞匯體系構(gòu)成了 UB 這個(gè)新范式的’行話’，它們是進(jìn)入這個(gè)新世界的’教科書(shū)’。

最初，我們?cè)O(shè)想過(guò)一種更簡(jiǎn)單的模型。Jetty 就像一個(gè)皮劃艇下水點(diǎn)。應(yīng)用線程（皮劃艇愛(ài)好者）將請(qǐng)求（皮劃艇）放入 JFS 后就可以立刻離開(kāi)，下水點(diǎn)瞬間就可供下一個(gè)人使用。這聽(tīng)起來(lái)非常高效，因?yàn)樗鼘⒂布蛙浖耆怦睢?/p>

然而，這個(gè)看似簡(jiǎn)單的設(shè)計(jì)卻隱藏著一個(gè)致命缺陷：它無(wú)法實(shí)現(xiàn)可靠的軟硬件流控。硬件完成任務(wù)的速度可能快于軟件處理完成事件的速度。如果硬件不斷地將完成事件（CQE）投遞到 JFC，而軟件來(lái)不及取走，JFC 很快就會(huì)被填滿。一旦 JFC 溢出，后續(xù)的完成事件就會(huì)被丟棄，導(dǎo)致災(zāi)難性的后果——軟件將永遠(yuǎn)無(wú)法得知某些操作已經(jīng)完成。

正是為了解決這個(gè)問(wèn)題，最終的設(shè)計(jì)采用了更為精巧的”泊位”模型。我們可以將 Jetty 想象成一個(gè)擁有多個(gè)泊位（berth）的公共碼頭。每個(gè)需要出海的請(qǐng)求（一個(gè)獨(dú)立的雙邊消息或一個(gè)內(nèi)存讀寫(xiě)請(qǐng)求），就像一艘船，需要先在碼頭申請(qǐng)一個(gè)泊位。這個(gè)泊位，就是 Jetty 中一個(gè)被占用的資源格子。在 UB 的具體實(shí)現(xiàn)中，當(dāng)應(yīng)用將請(qǐng)求（WQE）提交到 JFS（Jetty For Send）后，這個(gè)請(qǐng)求就占據(jù)了 JFS 中的一個(gè)格子。

關(guān)鍵在于，這個(gè)格子并非轉(zhuǎn)瞬即逝的。JFS 中的每個(gè)格子都與 JFC（Jetty For Completion）中的一個(gè)格子一一對(duì)應(yīng)。當(dāng)硬件完成了網(wǎng)絡(luò)傳輸和遠(yuǎn)端操作后，它會(huì)將一個(gè)完成事件（Completion）放入 JFC 中對(duì)應(yīng)的格子里。只有當(dāng)應(yīng)用程序處理了這個(gè)完成事件后，這個(gè)格子（即”泊位”）才算被徹底釋放，變?yōu)榭臻e狀態(tài)，可供下一個(gè)請(qǐng)求使用。這個(gè) JFS-JFC 配對(duì)的機(jī)制，也構(gòu)成了 CPU 與網(wǎng)卡之間精巧的硬件流控：JFC 中未被軟件處理的完成事件，會(huì)反過(guò)來(lái)阻止硬件在 JFS 中接收新的請(qǐng)求。

因此，Jetty 中的不同請(qǐng)求，確實(shí)更類(lèi)似船舶碼頭里泊位的概念。一個(gè)請(qǐng)求從提交，到網(wǎng)絡(luò)傳輸，再到發(fā)起方軟件最終處理完完成事件，整個(gè)生命周期內(nèi)都會(huì)持續(xù)占用碼頭上的一個(gè)泊位。這種設(shè)計(jì)雖然比”皮劃艇下水點(diǎn)”模型復(fù)雜，但它通過(guò) JFS 和 JFC 的一一對(duì)應(yīng)關(guān)系，建立了一個(gè)背壓（Back Pressure）機(jī)制，從根本上解決了軟硬件速度不匹配可能導(dǎo)致的事件丟失問(wèn)題。

這種模式的根本優(yōu)勢(shì)在于，它把一個(gè) N x N 的”私有航道”管理問(wèn)題，簡(jiǎn)化成了 N 個(gè)”公共碼頭”的管理問(wèn)題，解決了可擴(kuò)展性難題。

Jetty 模型的實(shí)踐考量：

HOL 阻塞、公平性與隔離

當(dāng)然，”公共碼頭”模型也必須面對(duì)現(xiàn)實(shí)世界的復(fù)雜性。

首先是 隊(duì)頭阻塞 (Head-of-Line Blocking) 問(wèn)題。由于 Jetty 中的每個(gè)泊位（JFS/JFC 資源對(duì)）都需要在請(qǐng)求的整個(gè)生命周期內(nèi)被占用，HOL 阻塞問(wèn)題是客觀存在的。在一個(gè)先進(jìn)先出（FIFO）的隊(duì)列中，如果排在隊(duì)首的是一個(gè)巨大且耗時(shí)的任務(wù)（比如一次超大數(shù)據(jù)的發(fā)送），它就會(huì)長(zhǎng)時(shí)間占用一個(gè)泊位。如果在這個(gè)巨大的發(fā)送任務(wù)之后，同一個(gè) JFS 中放入了大量小的發(fā)送任務(wù)，有可能把整個(gè)隊(duì)列（環(huán)形緩沖區(qū)）的空間占滿，此時(shí)即使一些小的發(fā)送任務(wù)已經(jīng)完成，新的發(fā)送任務(wù)也無(wú)法放入 JFS，因?yàn)殛?duì)列中第一個(gè)巨大的發(fā)送任務(wù)一直沒(méi)有完成。

不過(guò)，這個(gè)問(wèn)題在實(shí)踐中通常不會(huì)造成嚴(yán)重困擾。首先，一個(gè) Jetty 可以擁有的”泊位”數(shù)量非常多，可以達(dá)到上千的量級(jí)。其次，UB 是一個(gè)非?？斓木W(wǎng)絡(luò)，大多數(shù)請(qǐng)求的生命周期極短。因此，在大多數(shù)場(chǎng)景下，HOL 導(dǎo)致所有泊位被填滿的概率并不高。

其次是 公平性 (Fairness) 與隔離 (Isolation) 問(wèn)題。既然所有出港的船都從同一個(gè)碼頭出發(fā)（單個(gè) JFS），那么就無(wú)法保證不同目的地、不同優(yōu)先級(jí)船只的公平性。一個(gè)”瘋狂”的貨主（某個(gè)應(yīng)用）可能會(huì)持續(xù)不斷地向碼頭堆貨，占滿所有資源，讓其他貨主的船根本沒(méi)有機(jī)會(huì)離港。

對(duì)于 HOL 阻塞、公平性和隔離問(wèn)題，Jetty 模型都提供了統(tǒng)一且靈活的解決方案：當(dāng)需要時(shí)，應(yīng)用可以創(chuàng)建多個(gè) Jetty。

• 緩解 HOL 阻塞：如果應(yīng)用需要混合處理大的請(qǐng)求和大量小的請(qǐng)求，一個(gè)最佳實(shí)踐是為它們使用不同的 Jetty，將大請(qǐng)求的”慢船”和小請(qǐng)求的”快艇”分流到不同的碼頭。

• 需要隔離：如果一個(gè)關(guān)鍵應(yīng)用不希望它的數(shù)據(jù)收發(fā)被其他任何應(yīng)用干擾，它可以創(chuàng)建自己專(zhuān)屬的一對(duì)一 Jetty（一個(gè) JFS/JFR 對(duì)），這在邏輯上部分回歸了”連接”的抽象，用一個(gè)獨(dú)立的”私有碼頭”來(lái)保證服務(wù)質(zhì)量（QoS）。

• 需要公平性：一個(gè)服務(wù)如果需要公平地處理來(lái)自多個(gè)不同租戶的請(qǐng)求，它可以為每個(gè)租戶或每類(lèi)請(qǐng)求建立不同的 Jetty，然后在應(yīng)用層自己做輪詢或調(diào)度。

這正是 Jetty 抽象的精妙之處：它提供了一個(gè)極致簡(jiǎn)單和可擴(kuò)展的”無(wú)連接”模型作為默認(rèn)選項(xiàng)，同時(shí)又把”需要多大程度的隔離和分流”這個(gè)選擇權(quán)交還給了應(yīng)用層。應(yīng)用可以根據(jù)自己的需求，在”完全共享”和”完全隔離”之間，做出最適合自己的權(quán)衡。

Jetty 抽象下的單雙邊語(yǔ)義實(shí)現(xiàn)

Jetty 抽象可以用一套統(tǒng)一的隊(duì)列模型，高效地實(shí)現(xiàn)單邊和雙邊兩種核心語(yǔ)義。

1.單邊內(nèi)存語(yǔ)義 (One-Sided)

單邊操作（如 RDMA Read/Write）的特點(diǎn)是，它像一次內(nèi)存訪問(wèn)，只需要發(fā)起方提供地址、數(shù)據(jù)，而不需要對(duì)端應(yīng)用 CPU 的參與。在 Jetty 模型中，這個(gè)流程被極度簡(jiǎn)化：

• 發(fā)起方應(yīng)用將一個(gè)”寫(xiě)”請(qǐng)求（包含目標(biāo)地址、數(shù)據(jù)等信息）提交到 JFS。

• UB 硬件從 JFS 取走請(qǐng)求，完成到目標(biāo)的可靠傳輸。

• 目標(biāo)端 UB 硬件直接將數(shù)據(jù)寫(xiě)入指定內(nèi)存地址。

• 在發(fā)起方，UB 硬件在 JFC 中放入一個(gè)完成事件（CQE）。發(fā)起方應(yīng)用通過(guò)檢查 JFC 就知道操作已完成。

• 整個(gè)過(guò)程，發(fā)起方應(yīng)用甚至不需要接收隊(duì)列（JFR），因?yàn)樗弧苯邮铡比魏螒?yīng)用層消息，只關(guān)心自己的操作是否”完成”。

2. 雙邊消息語(yǔ)義 (Two-Sided)

雙邊操作（如 Send/Receive）則需要兩邊應(yīng)用的參與。JFR (Jetty for Receive) 的工作機(jī)制與 RDMA 的接收隊(duì)列 (RQ) 相似，其核心是解耦消息的到達(dá)和應(yīng)用對(duì)緩沖區(qū)的管理：

• 首先，目標(biāo)端應(yīng)用需要預(yù)先將若干”接收”請(qǐng)求提交到 JFR。每個(gè)接收請(qǐng)求都指向一塊應(yīng)用提供的內(nèi)存緩沖區(qū)。

• 當(dāng)發(fā)起方應(yīng)用將一個(gè)”發(fā)送”請(qǐng)求提交到 JFS 后，UB 硬件會(huì)將其可靠地傳輸?shù)侥繕?biāo)端。

• 目標(biāo)端 UB 硬件收到消息后，會(huì)從 JFR 中消耗一個(gè)預(yù)置的接收請(qǐng)求，將網(wǎng)絡(luò)上收到的數(shù)據(jù)直接存入該請(qǐng)求對(duì)應(yīng)的緩沖區(qū)中。

• 數(shù)據(jù)存入后，硬件會(huì)在 JFC (Jetty for Completion) 中放入一個(gè)完成事件，以此來(lái)通知目標(biāo)端應(yīng)用。這個(gè)完成事件會(huì)告知應(yīng)用緩沖區(qū)地址、數(shù)據(jù)大小等信息。

• 目標(biāo)端應(yīng)用通過(guò)檢查其 JFC，發(fā)現(xiàn)這個(gè)完成事件，就可以去處理相應(yīng)緩沖區(qū)中的新消息了。

• 與此同時(shí)，在發(fā)起方，UB 硬件也會(huì)在其 JFC 中放入完成事件，通知”發(fā)送”操作已成功。

這種預(yù)先提交接收緩沖區(qū)的模式，引出了一個(gè)消息語(yǔ)義中的經(jīng)典難題：如果接收方無(wú)法預(yù)知消息的大小，應(yīng)該如何高效地管理緩沖區(qū)？為了應(yīng)對(duì)這一挑戰(zhàn)，Jetty 提供了靈活的緩沖區(qū)拆分與合并機(jī)制。例如，一個(gè)大的接收緩沖區(qū)可以被拆分用來(lái)接收多個(gè)小的消息；反之，一個(gè)大的消息也可以被”分散”到多個(gè)預(yù)先提交的小緩沖區(qū)中。

然而，這種靈活性帶來(lái)了額外的復(fù)雜性，更可能引發(fā)不易察覺(jué)的性能問(wèn)題。復(fù)雜的緩沖區(qū)管理不僅增加了應(yīng)用層軟件的負(fù)擔(dān)，還可能因?yàn)橐粋€(gè)邏輯消息對(duì)應(yīng)多個(gè)硬件操作而干擾 JFC 的流控機(jī)制。因此，從設(shè)計(jì)理念和最佳實(shí)踐出發(fā)，我們建議采用更簡(jiǎn)單、高效的一對(duì)一模式：為每個(gè)消息預(yù)備一個(gè)足夠大的接收緩沖區(qū)。這再次印證了 UB 的核心設(shè)計(jì)哲學(xué)：雙邊消息語(yǔ)義是為高效的”通知”而生，而大塊數(shù)據(jù)的傳輸應(yīng)該交由單邊內(nèi)存語(yǔ)義來(lái)完成。

3. 高效的應(yīng)用喚醒機(jī)制

最高性能的應(yīng)用會(huì)持續(xù)輪詢（Polling）JFC/JFR 來(lái)獲取完成狀態(tài)和新消息。但在很多場(chǎng)景下，應(yīng)用可能處于休眠狀態(tài)。如果每個(gè)完成事件都觸發(fā)一次中斷來(lái)喚醒 CPU，開(kāi)銷(xiāo)又太大了。Jetty 通過(guò) JFC 和 EQ 的聯(lián)動(dòng)，實(shí)現(xiàn)了一種高效的異步通知機(jī)制：應(yīng)用在提交請(qǐng)求時(shí)可以設(shè)置一個(gè)標(biāo)志，請(qǐng)求硬件在事務(wù)完成后觸發(fā)一個(gè) Event。硬件會(huì)將這個(gè) Event 放入 EQ 中，多個(gè) Event 可以對(duì)應(yīng)一次中斷。應(yīng)用進(jìn)程被喚醒后，只需檢查 EQ，就知道有”事件”發(fā)生，然后再去批量處理 JFC 和 JFR 中積累的多個(gè)完成消息。這就將”每消息一次”的潛在喚醒開(kāi)銷(xiāo)，變成了”每批消息一次”的開(kāi)銷(xiāo)，極大地提升了效率。

總而言之，Jetty 抽象是 UB 無(wú)連接設(shè)計(jì)哲學(xué)的基石。它用一個(gè)簡(jiǎn)單、無(wú)連接的”碼頭-隊(duì)列”模型，取代了傳統(tǒng)網(wǎng)絡(luò)中復(fù)雜、有連接的狀態(tài)機(jī)模型，將繁重的工作下沉到硬件，最終為上層軟件提供了極致簡(jiǎn)潔、極致性能、極致可擴(kuò)展的編程接口。

強(qiáng)事務(wù)序與弱事務(wù)序

在分布式系統(tǒng)中，順序是保證一致性的核心，卻也是性能的枷鎖。

消息語(yǔ)義：掙脫字節(jié)流的枷鎖

傳統(tǒng)的網(wǎng)絡(luò)通信，以 TCP 為代表，為我們提供了一個(gè)可靠的、點(diǎn)對(duì)點(diǎn)的字節(jié)流（Byte Stream）抽象。這是一個(gè)強(qiáng)大的模型，保證了數(shù)據(jù)不丟、不重、不亂。然而，當(dāng)我們?cè)谝粋€(gè)連接中傳遞多個(gè)獨(dú)立的業(yè)務(wù)”消息”時(shí)，這種嚴(yán)格的字節(jié)流序反而會(huì)成為性能瓶頸。如果承載第一個(gè)消息的數(shù)據(jù)包丟失，TCP 的可靠性機(jī)制會(huì)阻塞整個(gè)連接，直到這個(gè)包被重傳成功。所有后續(xù)的、即使邏輯上完全獨(dú)立的消息，也不得不原地等待。這就是著名的”隊(duì)頭阻塞”（Head-of-Line Blocking, HoL Blocking）。

現(xiàn)代網(wǎng)絡(luò)協(xié)議的設(shè)計(jì)充分認(rèn)識(shí)到了這一問(wèn)題。無(wú)論是承載了 Web 未來(lái)的 QUIC 和 HTTP/3，還是為高性能數(shù)據(jù)中心設(shè)計(jì)的 UB，其核心變革之一就是用”消息語(yǔ)義”取代了”字節(jié)流語(yǔ)義”。通過(guò)在無(wú)連接的 UDP 或類(lèi)似的底層協(xié)議之上構(gòu)建多個(gè)獨(dú)立的邏輯流，一個(gè)消息的傳輸問(wèn)題不再會(huì)阻塞其他無(wú)關(guān)的消息。這為我們?cè)诟呔S度上——即事務(wù)與事務(wù)之間——討論順序提供了必要的基礎(chǔ)。

強(qiáng)序之夢(mèng)：全局全序的誘惑與挑戰(zhàn)

既然我們可以在邏輯上區(qū)分獨(dú)立的事務(wù)，一個(gè)自然而然的終極理想便浮現(xiàn)出來(lái)：我們能否構(gòu)建一個(gè)通信系統(tǒng)，將順序保證從單一的點(diǎn)對(duì)點(diǎn)連接，擴(kuò)展到整個(gè)網(wǎng)絡(luò)？

這個(gè)想法最早的靈感，源于一個(gè)簡(jiǎn)單的物理直覺(jué)：網(wǎng)絡(luò)中一個(gè)事件帶來(lái)的影響，就像投入水中的石子激起的波浪，從一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)（交換機(jī)或主機(jī)）傳遞到后續(xù)的節(jié)點(diǎn)。每一個(gè)數(shù)據(jù)包的轉(zhuǎn)發(fā)，都像是波前（wavefront）的推進(jìn)。如果我們能捕捉到這些”波”在整個(gè)網(wǎng)絡(luò)中傳播的先后順序，不就能天然地為所有事件定義一個(gè)全局一致的順序嗎？

這是我在博士期間與左格非、白巍和張霖濤導(dǎo)師合作的研究課題（1Pipe: Scalable Total Order Communication in Data Center Networks）。這個(gè)工作的核心動(dòng)機(jī)在于，如果網(wǎng)絡(luò)能為所有節(jié)點(diǎn)提供一個(gè)”O(jiān)ne Big Pipe”的抽象，讓所有發(fā)送的事務(wù)（無(wú)論是單播還是多播）都在一個(gè)虛擬的全局序列中被嚴(yán)格排序，那么許多分布式系統(tǒng)難題都能有更高效、簡(jiǎn)單的解決方案，例如：

• 分布式事務(wù)：一次跨越多個(gè)節(jié)點(diǎn)的原子寫(xiě)入，可以被打包成一個(gè)全序”散射”（Scattering）消息，協(xié)議能保證所有節(jié)點(diǎn)都在同一”邏輯時(shí)刻”看到這次寫(xiě)入，從而天然地實(shí)現(xiàn)了原子性，無(wú)需復(fù)雜的兩階段提交或鎖。

• 狀態(tài)機(jī)復(fù)制：共識(shí)算法（如 Paxos/Raft）的核心就是對(duì)操作日志達(dá)成一個(gè)一致的順序。如果網(wǎng)絡(luò)本身就提供全序，復(fù)制（Replication）將只需要考慮故障問(wèn)題，復(fù)雜度將極大降低。

• 內(nèi)存一致性：分布式共享內(nèi)存系統(tǒng)中，全局全序通信可以避免很多類(lèi)型的 data hazard（數(shù)據(jù)讀寫(xiě)順序沖突），解決內(nèi)存更新的順序問(wèn)題。

這個(gè)理想，本質(zhì)上是試圖在工程上實(shí)現(xiàn) Leslie Lamport 在其劃時(shí)代論文中，基于狹義相對(duì)論所描述的 happen-before (→) 關(guān)系的終極強(qiáng)化版——一個(gè)與所有因果關(guān)系都兼容的全局全序關(guān)系 (?)。

然而，從 2018 年的首次投稿到 2021 年最終發(fā)表，我的 iPipe 這個(gè)工作歷經(jīng)五次投稿，其核心的挑戰(zhàn)也暴露無(wú)遺：現(xiàn)實(shí)世界的網(wǎng)絡(luò)充滿了故障（Failure），而一個(gè)純粹的全序系統(tǒng)在故障面前是極其脆弱的。 僅僅為消息分配一個(gè)全局唯一的序列號(hào)是不夠的，因?yàn)槟銦o(wú)法保證消息的可靠交付和原子性。如果一個(gè)發(fā)送者在分配了序號(hào)后、但在消息被所有接收者確認(rèn)前崩潰，會(huì)發(fā)生什么？如果一個(gè)接收者永久下線，這次”原子”散射操作的完整性如何保證？為了解決這些問(wèn)題，我們被迫在理想化的全序模型之上，增加了復(fù)雜的故障檢測(cè)與恢復(fù)機(jī)制，系統(tǒng)的復(fù)雜性也隨之劇增。

弱序之道：擁抱不確定性的新范式

這段艱難的科研經(jīng)歷讓我深刻反思：我們是否真的需要一個(gè)如此昂貴、如此復(fù)雜的強(qiáng)因果、強(qiáng)順序系統(tǒng)？

答案的曙光，意外地來(lái)自兩個(gè)看似無(wú)關(guān)的領(lǐng)域：基礎(chǔ)物理學(xué)與人工智能。一位同事告訴我，物理學(xué)界的前沿實(shí)驗(yàn)，如”量子開(kāi)關(guān)”，已經(jīng)揭示出宇宙在最精細(xì)的尺度上，其因果結(jié)構(gòu)可能并非我們宏觀世界里那樣”堅(jiān)固”。因果順序本身可能是不確定的、疊加的，我們所體驗(yàn)到的確定性因果，或許只是微觀概率世界在宏觀尺度上的一個(gè)統(tǒng)計(jì)平均結(jié)果。

這個(gè)思想與現(xiàn)代 AI 系統(tǒng)的內(nèi)在特性形成了奇妙的共鳴。今天，我們最大規(guī)模的計(jì)算負(fù)載——深度神經(jīng)網(wǎng)絡(luò)的訓(xùn)練與推理——其核心算法（如隨機(jī)梯度下降）本身就是概率性的，并且天然地容忍甚至利用”噪聲”。在一個(gè)本身就是概率性的系統(tǒng)中，由通信帶來(lái)的微小亂序或延遲，僅僅是另一種可被算法消化的噪聲而已。

既然宇宙的底層規(guī)則可能不是強(qiáng)因果的，而我們最重要的應(yīng)用又可以容忍弱因果，那么，強(qiáng)行在不可靠的硬件之上構(gòu)建一個(gè)完美的、強(qiáng)一致性的通信層，是否是一種不必要的、過(guò)度的工程設(shè)計(jì)？

這正是 Unified Bus 中”弱事務(wù)序”設(shè)計(jì)的哲學(xué)根基。UB 認(rèn)識(shí)到，不同的應(yīng)用場(chǎng)景對(duì)順序和一致性的要求天差地別。因此，它不提供單一的、僵化的順序模型，而是提供了一組分級(jí)的、可供應(yīng)用按需選擇的事務(wù)序原語(yǔ)。

UB 事務(wù)序：執(zhí)行序與完成序

UB 將事務(wù)的順序保證分解為兩個(gè)正交的維度：執(zhí)行序與完成序。

事務(wù)執(zhí)行序 (Execution Order)

它定義了請(qǐng)求在 Target 端被執(zhí)行的順序，是保證一致性的核心。

• NO (No Order) ：默認(rèn)選項(xiàng)，性能最高。事務(wù)之間完全獨(dú)立，Target 可以按任意順序執(zhí)行它們。適用于無(wú)狀態(tài)的查詢、獨(dú)立的日志上傳等場(chǎng)景。

• RO (Relaxed Order) ：弱序的核心。它保證來(lái)自同一 Initiator 的、被標(biāo)記為 RO 或 SO 的事務(wù)鏈，會(huì)按照發(fā)送的順序執(zhí)行。但它不會(huì)阻塞與此事務(wù)鏈無(wú)關(guān)的其他事務(wù)。它在保證”因果鏈內(nèi)部不亂序”的前提下，最大化了并行度。

• SO (Strong Order) ：強(qiáng)序的保證。被標(biāo)記為 SO 的事務(wù)，必須等待從該 Initiator 發(fā)出的、在它之前的所有 RO 和 SO 事務(wù)都執(zhí)行完畢后，才能開(kāi)始執(zhí)行。這提供了一個(gè)強(qiáng)序列點(diǎn)，適用于需要嚴(yán)格串行化的關(guān)鍵操作。

• Fence：一種特殊的屏障機(jī)制。它確保在它之前的所有事務(wù)（無(wú)論何種類(lèi)型）都執(zhí)行完畢后，在它之后的事務(wù)才能開(kāi)始。它用于在不同的、邏輯獨(dú)立的事務(wù)”批次”之間建立清晰的邊界。

事務(wù)完成序 (Completion Order)

它定義了事務(wù)完成的通知（CQE）產(chǎn)生的順序，與執(zhí)行序解耦。這允許系統(tǒng)進(jìn)行更靈活的優(yōu)化。例如，事務(wù)可以按序執(zhí)行，但亂序完成（比如寫(xiě)操作在持久化到日志后即可通知完成，無(wú)需等待數(shù)據(jù)落盤(pán)）。

通過(guò)將這些原語(yǔ)組合成不同的事務(wù)服務(wù)模式（如 ROI, ROT, ROL），UB 賦能給上層應(yīng)用，讓其根據(jù)自身的業(yè)務(wù)邏輯，在性能與一致性之間做出最明智的、細(xì)粒度的選擇。對(duì)于需要強(qiáng)一致性的分布式數(shù)據(jù)庫(kù)，可能會(huì)多使用 SO 和 Fence；而對(duì)于大規(guī)模的 AI 訓(xùn)練，絕大多數(shù)梯度更新都可以使用 RO 甚至 NO，從而將系統(tǒng)吞吐量推向極致。這套設(shè)計(jì)哲學(xué)，是對(duì)分布式系統(tǒng)”順序”問(wèn)題，從理論反思到工程實(shí)踐的系統(tǒng)性回答。

Load/Store 與 Read/Write：

內(nèi)存訪問(wèn)的兩種世界觀

在 Unified Bus 的設(shè)計(jì)哲學(xué)中，對(duì)遠(yuǎn)程內(nèi)存的訪問(wèn)并非只有一種方式，而是提供了兩種核心的、互補(bǔ)的編程范式：一種是與處理器指令集深度融合的 Load/Store，另一種是更為靈活、軟件定義的 Read/Write。這兩種范式代表了兩種不同的”世界觀”，其背后是在編程模型、性能、一致性、硬件耦合度等多個(gè)維度上的深刻權(quán)衡。

兩類(lèi)范式：

同步 Load/Store 與異步 Read/Write

要理解這兩種范式的根本區(qū)別，我們首先要回到一個(gè)基本問(wèn)題：一次遠(yuǎn)程內(nèi)存訪問(wèn)，在應(yīng)用和硬件層面，究竟是如何發(fā)生的？

什么是 Load/Store？

我們討論任何系統(tǒng)語(yǔ)義時(shí)，首先要明確它是在哪個(gè)層次上實(shí)現(xiàn)的，否則就容易陷入雞同鴨講的辯經(jīng)。Load/Store 語(yǔ)義的核心，在于它是否由處理器硬件指令直接支持。

• 在經(jīng)典的圖靈機(jī)模型中，Load 指令完成后，下一條指令才能開(kāi)始。

• 在現(xiàn)代處理器的亂序執(zhí)行模型中，Load 指令發(fā)出后，不相關(guān)的后續(xù)指令可以繼續(xù)執(zhí)行，但任何依賴該 Load 結(jié)果的指令會(huì)被硬件自動(dòng)阻塞，直到數(shù)據(jù)返回。

• 在一些專(zhuān)用處理器（如 NPU）中，一條 Load 指令甚至可以搬運(yùn)一個(gè)非連續(xù)的、巨大的數(shù)據(jù)塊（如 Tensor 的一個(gè)切片）。

這些都屬于 Load/Store 語(yǔ)義，因?yàn)樗鼈兌加捎布噶钪苯影l(fā)起和管理。與之相對(duì)，那些由軟件發(fā)起、運(yùn)行時(shí)封裝的內(nèi)存訪問(wèn)（例如，軟件構(gòu)造一個(gè)工作請(qǐng)求，通過(guò)驅(qū)動(dòng)發(fā)給網(wǎng)卡，再輪詢完成隊(duì)列），通常不被認(rèn)為是 Load/Store 語(yǔ)義，即使它最終實(shí)現(xiàn)了數(shù)據(jù)的遠(yuǎn)程讀取。

同步 vs. 異步

Load/Store 的本質(zhì)是一種同步的內(nèi)存訪問(wèn)模型，而傳統(tǒng)的 RDMA Read/Write 則是異步模型的典范。

一次典型的異步 RDMA 寫(xiě)操作，其過(guò)程繁瑣而漫長(zhǎng)：

1. 軟件在內(nèi)存中構(gòu)造一個(gè)工作隊(duì)列元素（WQE）。

2. 軟件通過(guò)”按門(mén)鈴”（Doorbell）的方式通知網(wǎng)卡有新任務(wù)。

3. 網(wǎng)卡從內(nèi)存中將 WQE 讀取到自己的片上內(nèi)存。

4. 網(wǎng)卡根據(jù) WQE 中的信息，將用戶數(shù)據(jù)從主機(jī)內(nèi)存 DMA 到網(wǎng)卡。

5. 網(wǎng)卡將數(shù)據(jù)打包成網(wǎng)絡(luò)報(bào)文，發(fā)送到遠(yuǎn)端。

6. 遠(yuǎn)端網(wǎng)卡接收?qǐng)?bào)文，并將數(shù)據(jù)寫(xiě)入目標(biāo)內(nèi)存。

7. 遠(yuǎn)端網(wǎng)卡返回一個(gè)確認(rèn)消息。

8. 發(fā)起端網(wǎng)卡收到確認(rèn)后，在內(nèi)存中寫(xiě)入一個(gè)完成隊(duì)列元素（CQE）。

9. 軟件需要主動(dòng)輪詢（Poll）CQE，才能最終確認(rèn)操作完成。

整個(gè)過(guò)程涉及多次 DMA 和復(fù)雜的軟硬件交互。而在 UB 中，Read/Write 借鑒了 NVIDIA BlueFlame 等技術(shù)，允許在”按門(mén)鈴”時(shí)附帶少量信息，將 WQE 直接寫(xiě)入網(wǎng)卡的設(shè)備地址空間，從而省去了步驟 1 和 3，節(jié)約了兩次 DMA 開(kāi)銷(xiāo)，但其異步交互的本質(zhì)沒(méi)有改變。

相比之下，一次同步 Load/Store 操作則極致簡(jiǎn)化：

1. 應(yīng)用執(zhí)行一條 Load 或 Store 指令。

2. CPU 中的網(wǎng)絡(luò)模塊（或與之緊密集成的協(xié)處理器）直接將該指令轉(zhuǎn)化為網(wǎng)絡(luò)報(bào)文。

3. 遠(yuǎn)端網(wǎng)絡(luò)模塊完成內(nèi)存讀寫(xiě)，并通過(guò)網(wǎng)絡(luò)返回結(jié)果（或確認(rèn)）。

4. 發(fā)起端 CPU 的指令完成，流水線繼續(xù)執(zhí)行。

現(xiàn)代 CPU 的流水線機(jī)制可以很好地隱藏同步訪問(wèn)的部分延遲。雖然一個(gè)耗時(shí)過(guò)長(zhǎng)的遠(yuǎn)程 Load 可能會(huì)阻塞部分流水線，降低并行度，但其端到端的延遲和軟件開(kāi)銷(xiāo)遠(yuǎn)低于異步模型，尤其適合對(duì)延遲敏感的小數(shù)據(jù)塊訪問(wèn)。

優(yōu)劣總結(jié)

同步遠(yuǎn)程內(nèi)存訪問(wèn) (Load/Store)

• 優(yōu)勢(shì): 過(guò)程簡(jiǎn)單，延遲極低；對(duì)應(yīng)用透明，可直接用于內(nèi)存擴(kuò)展；小數(shù)據(jù)量訪問(wèn)效率高；可支持硬件緩存一致性。

• 劣勢(shì): 對(duì)硬件要求高（需 CPU 緊密集成）；單次訪問(wèn)數(shù)據(jù)量?。ㄍǔＪ蔷彺嫘辛６龋豢煽啃浴北ò霃健贝螅ü?jié)點(diǎn)故障可能拖垮訪問(wèn)該節(jié)點(diǎn)內(nèi)存的其他所有節(jié)點(diǎn)）；大規(guī)模緩存一致性開(kāi)銷(xiāo)高。

異步遠(yuǎn)程內(nèi)存訪問(wèn) (Read/Write)

• 優(yōu)勢(shì): 可靈活指定訪問(wèn)數(shù)據(jù)量，大數(shù)據(jù)傳輸吞吐高；對(duì)硬件要求低，解耦性好；可通過(guò)軟件捕獲異常，故障隔離性好。

• 劣勢(shì): 過(guò)程復(fù)雜，延遲較高；對(duì)應(yīng)用不透明，需要顯式編程；無(wú)硬件緩存一致性，需軟件保證。

正是因?yàn)檫@兩種模式各有千秋，UB 協(xié)議才選擇同時(shí)提供它們，讓開(kāi)發(fā)者能根據(jù)場(chǎng)景按需選擇。

遠(yuǎn)程內(nèi)存尋址

提供了兩種編程范式后，下一個(gè)核心問(wèn)題是：如何為遠(yuǎn)程內(nèi)存”命名”和”定位”，即尋址？UB 的內(nèi)存管理機(jī)制，正是圍繞著如何高效支持 Load/Store 和 Read/Write 這兩種模式而構(gòu)建的。

在 UB 的世界里，內(nèi)存的基本管理單元是內(nèi)存段（Memory Segment）。一個(gè)內(nèi)存段是一段連續(xù)的物理內(nèi)存。當(dāng)一個(gè)節(jié)點(diǎn)（Home）希望將其部分內(nèi)存共享給其他節(jié)點(diǎn)（Initiator）時(shí)，它會(huì)創(chuàng)建一個(gè)內(nèi)存段，并為其分配一個(gè)唯一的標(biāo)識(shí)符（TokenID）。Initiator 要想訪問(wèn)這段遠(yuǎn)程內(nèi)存，就必須先從 Home 獲取這個(gè)內(nèi)存段的信息，包括 TokenID、基地址（UBA）和大小（Len）。

獲取了這些信息后，Initiator 面臨一個(gè)關(guān)鍵選擇：如何將這個(gè)遠(yuǎn)程內(nèi)存地址”翻譯”成自己可以理解和使用的地址？業(yè)界和學(xué)術(shù)界探索了多種路徑，各有優(yōu)劣：

1.物理內(nèi)存統(tǒng)一編址 (Globally Shared Physical Memory)

這種方式最為簡(jiǎn)單直接，常見(jiàn)于傳統(tǒng)的緊耦合 HPC 系統(tǒng)。在整個(gè)系統(tǒng)中，所有節(jié)點(diǎn)的物理內(nèi)存都被映射到一個(gè)全局統(tǒng)一的物理地址空間。任何節(jié)點(diǎn)訪問(wèn)一個(gè)地址，硬件都能直接解析到它屬于哪個(gè)節(jié)點(diǎn)的哪塊物理內(nèi)存。這種模型的優(yōu)點(diǎn)是硬件實(shí)現(xiàn)簡(jiǎn)單。但其致命缺點(diǎn)是擴(kuò)展性極差。隨著節(jié)點(diǎn)數(shù)量增多，維持一個(gè)全局一致的物理地址視圖變得異常困難和昂貴。

2.網(wǎng)絡(luò)地址 + 遠(yuǎn)程虛擬地址 (Network Address + Remote VA)

這是一種更為靈活和可擴(kuò)展的方案。訪問(wèn)一個(gè)遠(yuǎn)程內(nèi)存地址需要一個(gè)”二元組”：目標(biāo)節(jié)點(diǎn)的網(wǎng)絡(luò)地址，以及該內(nèi)存在目標(biāo)節(jié)點(diǎn)上的虛擬地址。這種方式將地址空間解耦，每個(gè)節(jié)點(diǎn)維護(hù)自己的地址空間，擴(kuò)展性非常好。UB 協(xié)議中的 read 和 write 事務(wù)就支持這種訪問(wèn)方式。

然而，這種網(wǎng)絡(luò)地址 + 虛擬地址的二元組通常非常長(zhǎng)（例如需要 128 位），無(wú)法被現(xiàn)有的 CPU 指令直接作為內(nèi)存地址來(lái)尋址。發(fā)起一次遠(yuǎn)程讀寫(xiě)，需要 CPU 執(zhí)行專(zhuān)門(mén)的指令，將這個(gè)長(zhǎng)地址和操作類(lèi)型一起打包成請(qǐng)求，交給網(wǎng)卡硬件去處理。這種方式的另一個(gè)重要特征是，它本質(zhì)上是一種非緩存（Non-cacheable）的訪問(wèn)模式。每次讀寫(xiě)都直達(dá)對(duì)端內(nèi)存，數(shù)據(jù)不在本地緩存。這樣做的好處是模型簡(jiǎn)單，完全不存在緩存一致性問(wèn)題，因?yàn)楦揪蜎](méi)有緩存。但缺點(diǎn)也很明顯，即每次訪問(wèn)都需要承受完整的網(wǎng)絡(luò)延遲。

3.映射到本地虛擬地址 (Mapping to Local VA)

這是 UB 協(xié)議為追求極致性能而提供的核心機(jī)制，由 load 和 store 指令支持。在這種模式下，Initiator 會(huì)將獲取到的遠(yuǎn)程內(nèi)存段，通過(guò)本地的內(nèi)存管理單元（UBMMU），映射到自己進(jìn)程的虛擬地址空間中。一旦映射完成，CPU 就可以像訪問(wèn)本地內(nèi)存一樣，使用標(biāo)準(zhǔn)的 load 和 store 指令來(lái)訪問(wèn)這段遠(yuǎn)程內(nèi)存。

這種方式的性能優(yōu)勢(shì)是巨大的，因?yàn)樗鼘⑦h(yuǎn)程內(nèi)存”本地化”了，使得 CPU 流水線可以無(wú)縫地處理遠(yuǎn)程訪問(wèn)，無(wú)需特殊的指令和軟件開(kāi)銷(xiāo)。更重要的是，這種模式天然地支持緩存（Cacheable）。當(dāng) CPU load 一個(gè)遠(yuǎn)程地址時(shí)，數(shù)據(jù)可以被緩存到本地 Cache 中，后續(xù)的訪問(wèn)就可以在極低的延遲下完成。

當(dāng)然，引入緩存也帶來(lái)了新的挑戰(zhàn)：如何保證緩存的一致性？UB 協(xié)議為此設(shè)計(jì)了精巧的緩存一致性機(jī)制。通過(guò)在內(nèi)存段映射時(shí)設(shè)置不同的權(quán)限（如只讀或讀寫(xiě)），系統(tǒng)可以為后續(xù)的緩存一致性管理留下充足的設(shè)計(jì)空間。例如，一個(gè)被多個(gè)節(jié)點(diǎn)以只讀方式映射的內(nèi)存段，其緩存管理就相對(duì)簡(jiǎn)單；而一旦允許寫(xiě)入，就需要更復(fù)雜的機(jī)制來(lái)確保數(shù)據(jù)的一致性。

綜上所述，UB 的內(nèi)存管理機(jī)制提供了一個(gè)分層的、靈活的解決方案。它既提供了簡(jiǎn)單、無(wú)需考慮一致性的 read/write 模式，也提供了與 CPU 指令集深度融合、支持緩存的 load/store 高性能模式，讓?xiě)?yīng)用可以根據(jù)自身的需求，在易用性、性能和一致性之間做出最合適的選擇。

緩存一致性

當(dāng)多個(gè)節(jié)點(diǎn)可以將同一段遠(yuǎn)程內(nèi)存映射到本地并進(jìn)行緩存時(shí)，緩存一致性就從一個(gè)”可選項(xiàng)”變成了”必答題”。如果管理不當(dāng)，不同節(jié)點(diǎn)緩存中的數(shù)據(jù)副本就可能出現(xiàn)不一致，導(dǎo)致程序讀到臟數(shù)據(jù)，從而產(chǎn)生災(zāi)難性的后果。UB 協(xié)議作為一個(gè)旨在提供內(nèi)存級(jí)語(yǔ)義的系統(tǒng)，必須提供清晰可靠的緩存一致性方案。

設(shè)計(jì)緩存一致性協(xié)議，本質(zhì)上是在性能、復(fù)雜度和一致性強(qiáng)度這三個(gè)維度之間進(jìn)行權(quán)衡。業(yè)界已經(jīng)發(fā)展出多種不同強(qiáng)度和實(shí)現(xiàn)方式的一致性模型，以下探討幾種典型的方案，并結(jié)合 UB 的設(shè)計(jì)理念進(jìn)行分析：

1.任意節(jié)點(diǎn)、強(qiáng)一致性（動(dòng)態(tài)共享列表）

這是最理想化的模型：允許多個(gè)節(jié)點(diǎn)同時(shí)緩存一份數(shù)據(jù)，并保證其訪問(wèn)體驗(yàn)與訪問(wèn)本地多核處理器的內(nèi)存完全一致（即強(qiáng)一致性）。當(dāng)一個(gè)節(jié)點(diǎn)修改數(shù)據(jù)時(shí)，協(xié)議需要通過(guò)類(lèi)似”廣播”或”多播”的方式，要么使其余所有節(jié)點(diǎn)的緩存副本失效（Invalidate），要么將更新同步給它們（Update）。這種模型的關(guān)鍵挑戰(zhàn)在于維護(hù)一個(gè)動(dòng)態(tài)的共享者列表（Sharer List）。由于任何節(jié)點(diǎn)都可能隨時(shí)加入或退出，這個(gè)列表的大小和成員都是不固定的，硬件要高效地管理這樣一個(gè)動(dòng)態(tài)列表，復(fù)雜度非常高，擴(kuò)展性也面臨挑戰(zhàn)。

2.多讀單寫(xiě)（Multiple Readers, Single Writer）

這是實(shí)踐中最為常見(jiàn)和經(jīng)典的一致性模型，也是現(xiàn)代多核 CPU 中 MSI/MESI/MOESI 等協(xié)議的基石。它規(guī)定，在任何時(shí)刻，一段數(shù)據(jù)可以被任意多個(gè)節(jié)點(diǎn)持有只讀緩存（Read-only Cache），但最多只能被一個(gè)節(jié)點(diǎn)持有可寫(xiě)權(quán)限（Write Permission）。當(dāng)某個(gè)節(jié)點(diǎn)希望寫(xiě)入數(shù)據(jù)時(shí)，它必須先獲得唯一的寫(xiě)權(quán)限，而獲得該權(quán)限的前提是，網(wǎng)絡(luò)中所有其他只讀緩存副本都必須被設(shè)置為無(wú)效（Invalidate）。UB 協(xié)議文檔中描述的 Ownership（所有權(quán)）概念和 Invalid/Read/Write 三種狀態(tài)的轉(zhuǎn)換，正是這一思想的體現(xiàn)。這種模型實(shí)現(xiàn)相對(duì)簡(jiǎn)單，在讀多寫(xiě)少的場(chǎng)景下性能很高，是性能和復(fù)雜度之間一個(gè)很好的平衡點(diǎn)。

3.獨(dú)占訪問(wèn)/所有權(quán)遷移（Ownership Migration）

這是”多讀單寫(xiě)”模型的一個(gè)特例。在這種模式下，任何時(shí)候只允許一個(gè)節(jié)點(diǎn)訪問(wèn)（緩存）某個(gè)內(nèi)存段。當(dāng)一個(gè)節(jié)點(diǎn)（Borrower）需要訪問(wèn)時(shí)，它會(huì)從原始持有者（Home）那里”借走”所有權(quán)，成為新的 Owner。在此期間，原有的 Home 節(jié)點(diǎn)將暫時(shí)失去對(duì)這段內(nèi)存的訪問(wèn)權(quán)，直到 Borrower 將其”歸還”。這種模型的實(shí)現(xiàn)最為簡(jiǎn)單，因?yàn)樗耆苊饬硕鄠€(gè)副本之間的一致性問(wèn)題。它適用于內(nèi)存借用場(chǎng)景，即 Home 節(jié)點(diǎn)把空閑的內(nèi)存 “出租” 出來(lái)，組成一個(gè)大的內(nèi)存池，其他內(nèi)存不足的節(jié)點(diǎn)從內(nèi)存池中索要內(nèi)存，用以彌補(bǔ)本地內(nèi)存的不足。

4.有限節(jié)點(diǎn)、強(qiáng)一致性（固定共享列表）

這是對(duì)第一種理想模型的簡(jiǎn)化和妥協(xié)。它同樣提供強(qiáng)一致性，但限制了能夠同時(shí)共享一份數(shù)據(jù)的節(jié)點(diǎn)數(shù)量。因?yàn)楣蚕碚邤?shù)量有上限，硬件可以用一個(gè)固定大小的列表來(lái)維護(hù)，從而大大降低了設(shè)計(jì)復(fù)雜度。然而，這種模型的實(shí)用性不強(qiáng)，因?yàn)樗趹?yīng)用層引入了一個(gè)不自然的限制，難以適應(yīng)通用和動(dòng)態(tài)變化的計(jì)算需求。

5.軟件管理一致性（Explicit Cache Management）

這是一種將一致性維護(hù)的責(zé)任部分或全部交給軟件的方案。硬件依然提供緩存機(jī)制以加速訪問(wèn)，但它不自動(dòng)保證不同節(jié)點(diǎn)間緩存的一致性。當(dāng)應(yīng)用需要確保自己讀到最新數(shù)據(jù)時(shí)，必須由軟件顯式地執(zhí)行 refresh cache（或 invalidate）操作，主動(dòng)丟棄本地可能過(guò)期的緩存。當(dāng)應(yīng)用修改了數(shù)據(jù)，希望對(duì)其他節(jié)點(diǎn)可見(jiàn)時(shí)，也必須顯式地執(zhí)行 write back（或 flush）操作，將本地緩存寫(xiě)回到主內(nèi)存。這種模型給了軟件最大的靈活性，但對(duì)程序員的要求極高，容易出錯(cuò)。

6.非緩存模式（Non-cacheable）

這是最簡(jiǎn)單直接的”一致性”方案：沒(méi)有緩存，自然也就不需要考慮一致性。如前文所述，UB 的 read/write 事務(wù)就屬于這種模式。每次訪問(wèn)都直達(dá)目標(biāo)主內(nèi)存，確保了讀取到的永遠(yuǎn)是最新數(shù)據(jù)。它的代價(jià)是需要應(yīng)用程序自行實(shí)現(xiàn)數(shù)據(jù)搬移，把數(shù)據(jù)從 Home 節(jié)點(diǎn)搬移到本地，才能享受緩存帶來(lái)的訪問(wèn)效率提升。

UB 協(xié)議的設(shè)計(jì)，正是在上述多種可能性中尋求最佳平衡的成果。它以”多讀單寫(xiě)”的所有權(quán)模型為核心，為 load/store 緩存訪問(wèn)提供了強(qiáng)大的硬件一致性保證，同時(shí)又保留了 read/write 這一非緩存的通道作為補(bǔ)充，從而讓不同的應(yīng)用都能找到最適合自身需求的一致性與性能平衡點(diǎn)。

內(nèi)存池的殺手級(jí)應(yīng)用：KV Cache

當(dāng)我們五年前首次構(gòu)思基于 UB 的內(nèi)存池時(shí)，我們手中握著一個(gè)強(qiáng)大的解決方案，卻一直在苦苦尋覓一個(gè)真正與之匹配的問(wèn)題。我們?cè)O(shè)想，通過(guò) UB，可以匯集上千臺(tái)服務(wù)器的內(nèi)存，構(gòu)建出一個(gè)前所未有的、統(tǒng)一的巨大內(nèi)存池，并且池中的任何數(shù)據(jù)都能被以接近本地內(nèi)存的超低延遲訪問(wèn)。這在技術(shù)上是激動(dòng)人心的，但一個(gè)現(xiàn)實(shí)的問(wèn)題始終縈繞在我們心頭：”究竟什么樣的應(yīng)用，才需要這樣一個(gè)規(guī)模龐大、性能極致的共享內(nèi)存池？”

LLM 推理服務(wù)的爆發(fā)，帶來(lái)了 KV Cache 的挑戰(zhàn)。LLM 在生成文本時(shí)，需要緩存海量的中間狀態(tài)（即 KV Cache），其大小動(dòng)輒數(shù)十上百 GB，遠(yuǎn)超單張 GPU 顯存的極限。更關(guān)鍵的是，這部分?jǐn)?shù)據(jù)在每個(gè) token 的生成過(guò)程中都必須被高頻訪問(wèn)，對(duì)延遲和帶寬極為敏感。突然之間，我們五年前提出的所有設(shè)想——巨大的容量、極低的延遲、高效的共享——都在 KV Cache 這個(gè)問(wèn)題上找到了完美的用武之地。

1. Prefill-Decode 分離

LLM 處理一個(gè)請(qǐng)求分為兩個(gè)階段：

• Prefill 階段：接收用戶輸入的 Prompt、對(duì)話歷史或 Agent 工具調(diào)用軌跡，并行計(jì)算出所有 token 的 KV Cache。這是一個(gè)計(jì)算密集型（Compute-bound）的過(guò)程。

• Decode 階段：逐一生成新的 token。每生成一個(gè) token，都需要讀取完整的 KV Cache（包含提示語(yǔ)和之前所有已生成的 token）。這是一個(gè)內(nèi)存帶寬密集型（Memory-bound）的過(guò)程。

由于這兩個(gè)階段的計(jì)算特性截然不同，大規(guī)模 LLM 推理框架普遍采用了 Prefill-Decode (PD) 分離的調(diào)度策略。系統(tǒng)會(huì)將大量的 Prefill 請(qǐng)求聚合成一個(gè)大的批次進(jìn)行計(jì)算，同時(shí)將 Decode 請(qǐng)求聚合成另一個(gè)批次。這種分離調(diào)度可以顯著提高 GPU 的利用率和系統(tǒng)整體的吞吐量。

2. Prefix KV Cache

在很多應(yīng)用場(chǎng)景中，不同的用戶請(qǐng)求常常包含相同的 “前綴”（Prefix）。例如，在多輪對(duì)話和 Agent 中，后續(xù)的請(qǐng)求完全包含了之前的對(duì)話歷史或工具調(diào)用歷史。

為這些相同的前綴重復(fù)計(jì)算 KV Cache 是巨大的浪費(fèi)。Prefix Caching 技術(shù)應(yīng)運(yùn)而生。其核心思想是，將計(jì)算好的前綴 KV Cache 存儲(chǔ)在一個(gè)全局的內(nèi)存池中。當(dāng)一個(gè)新的請(qǐng)求到來(lái)時(shí)，系統(tǒng)會(huì)檢查其前綴是否與緩存中的某個(gè)條目匹配。如果匹配，則直接從內(nèi)存池中找到這份共享的 KV Cache，然后從前綴末尾繼續(xù)計(jì)算即可。這極大地降低了首個(gè) token 的生成延遲（Time to First Token, TTFT），并節(jié)省了可觀的計(jì)算資源。

這種基于內(nèi)存池的 Prefix Caching 機(jī)制，本質(zhì)上就是一種跨請(qǐng)求的計(jì)算結(jié)果復(fù)用。UB 協(xié)議所倡導(dǎo)的全局內(nèi)存池和低延遲內(nèi)存借用，為實(shí)現(xiàn)一個(gè)高效、跨服務(wù)器的全局 KV Cache 池提供了理想的硬件基礎(chǔ)。

從更深層次看，KV Cache 的成功，或許是計(jì)算機(jī)系統(tǒng)領(lǐng)域?qū)?AI 領(lǐng)域做出的最核心的貢獻(xiàn)之一。Transformer 模型中的注意力機(jī)制可以被看作是一種新穎的、可微分的”鍵值存儲(chǔ)”（Key-Value Store）。在這個(gè)范式中，查詢向量（Query）是我們要查找的”鍵”，而上下文中的所有詞元都提供了自己的”鍵”（Key）和”值”（Value）。與傳統(tǒng)系統(tǒng)里通過(guò)哈希表進(jìn)行精確、離散匹配的 map[key] -> value 不同，注意力機(jī)制進(jìn)行的是一種模糊、連續(xù)的”軟”匹配（softmax 中的 soft 正是這個(gè)意思）。它用當(dāng)前 Query 與所有 Key 計(jì)算相似度（注意力分?jǐn)?shù)），然后按此分?jǐn)?shù)對(duì)所有的 Value 進(jìn)行加權(quán)求和。這相當(dāng)于一次性地、按相關(guān)性程度”讀取”了數(shù)據(jù)庫(kù)中的所有內(nèi)容。

總結(jié)：Load/Store 與 Read/Write

綜上所述，UB 提供的 Load/Store 與 Read/Write 絕不是冗余的功能，而是不同場(chǎng)景必需的兩種抽象。

• Load/Store 提供了極致的低延遲和編程透明性，將遠(yuǎn)程內(nèi)存無(wú)縫融入了處理器的原生指令集，是構(gòu)建高性能、細(xì)粒度共享內(nèi)存應(yīng)用的利器。但它也帶來(lái)了硬件實(shí)現(xiàn)的復(fù)雜度。

• Read/Write 則提供了一種更為傳統(tǒng)和靈活的異步訪問(wèn)模型，它解耦了軟硬件，簡(jiǎn)化了一致性模型，更適合大塊數(shù)據(jù)的搬運(yùn)和對(duì)延遲不那么敏感的場(chǎng)景。

URMA：統(tǒng)一遠(yuǎn)程內(nèi)存訪問(wèn)

行文至此，我們已經(jīng)探討了 UB 設(shè)計(jì)背后的諸多關(guān)鍵決策：從打破 CPU 瓶頸的”對(duì)等架構(gòu)”，到解決大規(guī)模擴(kuò)展性難題的”Jetty 無(wú)連接模型”，再到為性能優(yōu)化的”弱事務(wù)序”和”Load/Store 語(yǔ)義”。

URMA（Unified Remote Memory Access，統(tǒng)一遠(yuǎn)程內(nèi)存訪問(wèn)），是將所有這些設(shè)計(jì)哲學(xué)融為一體的頂層概念，由分布式與并行軟件實(shí)驗(yàn)室主任譚焜博士提出。URMA 正是 UB 協(xié)議為上層應(yīng)用提供的統(tǒng)一編程抽象和核心語(yǔ)義的集合。

URMA 的誕生，源于對(duì)未來(lái)計(jì)算模式的深刻洞察。在未來(lái)的數(shù)據(jù)中心和高性能計(jì)算集群中，CPU、GPU、NPU 等異構(gòu)算力單元將以對(duì)等的方式協(xié)同工作，共同處理復(fù)雜的計(jì)算任務(wù)。為了完全釋放這種異構(gòu)算力的潛力，底層的通信協(xié)議必須滿足幾個(gè)嚴(yán)苛的訴求：

1. 異構(gòu)算力直接通信：必須允許不同類(lèi)型的算力單元以對(duì)等的方式直接通信，繞開(kāi)傳統(tǒng)的主從架構(gòu)瓶頸，從而在細(xì)粒度的任務(wù)上實(shí)現(xiàn)高效的并行與協(xié)作。

2. 極致的可擴(kuò)展性：協(xié)議必須能高效地支持從單節(jié)點(diǎn)內(nèi)到超大規(guī)模集群的通信，輕松應(yīng)對(duì)數(shù)以萬(wàn)計(jì)節(jié)點(diǎn)的互聯(lián)需求。

3. 最大化的網(wǎng)絡(luò)效率：協(xié)議需要內(nèi)建靈活的路由和傳輸機(jī)制，例如通過(guò)多路徑和亂序傳輸，來(lái)充分利用昂貴的數(shù)據(jù)中心網(wǎng)絡(luò)帶寬，保障業(yè)務(wù)的實(shí)時(shí)性。

URMA 正是為這三大訴求量身打造的答案。它旨在高效、可靠地完成任意兩個(gè) UB 實(shí)體（UB Entity）之間的通信，無(wú)論是單邊的內(nèi)存訪問(wèn)（DMA），還是雙邊的消息收發(fā)。我們?cè)谇拔闹兴懻摰哪切╆P(guān)鍵特性，最終都在 URMA 的設(shè)計(jì)中得到了體現(xiàn)：

• 平等的訪問(wèn) (Peer-to-Peer Access) ：這是 URMA 的基石。任何異構(gòu)算力設(shè)備都可以通過(guò) URMA 實(shí)現(xiàn)免 CPU 介入的直接通信，呼應(yīng)了我們最初對(duì)”對(duì)等架構(gòu)”的設(shè)想。

• 天生的無(wú)連接 (Inherently Connectionless) ：URMA 通過(guò) Jetty 抽象，讓?xiě)?yīng)用之間可以直接復(fù)用 UB 傳輸層提供的可靠服務(wù)，無(wú)需建立和維護(hù)端到端的連接狀態(tài)。這從根本上解決了傳統(tǒng) RDMA 的可擴(kuò)展性問(wèn)題，是其能夠支撐超大規(guī)模部署的關(guān)鍵。

• 靈活的事務(wù)序 (Weak Ordering) ：URMA 允許應(yīng)用根據(jù)自身需求配置任務(wù)的保序行為。它默認(rèn)允許亂序執(zhí)行和亂序完成，這不僅避免了”隊(duì)頭阻塞”問(wèn)題，更釋放了底層硬件進(jìn)行多路徑傳輸和并行處理的巨大潛力，從而顯著提升了端到端的執(zhí)行效率。

總而言之，URMA 不僅僅是一套 API 或協(xié)議規(guī)范，它更代表了一種面向未來(lái)的、統(tǒng)一的異構(gòu)計(jì)算通信范式。它將總線的高性能與網(wǎng)絡(luò)的靈活性融為一體，通過(guò)一系列創(chuàng)新的設(shè)計(jì)，為上層應(yīng)用屏蔽了底層硬件的復(fù)雜性，最終提供了一個(gè)簡(jiǎn)單、高效且極具擴(kuò)展性的編程接口。這正是 Unified Bus “統(tǒng)一總線”這個(gè)名字的最終奧義所在。

當(dāng)然，如同任何一次范式的轉(zhuǎn)移，URMA 的統(tǒng)一抽象并非沒(méi)有代價(jià)。它將一部分過(guò)去由操作系統(tǒng)和軟件處理的復(fù)雜性（如內(nèi)存管理、一致性）下沉到了硬件，帶來(lái)了巨大的硬件設(shè)計(jì)挑戰(zhàn)。同時(shí)，它也向上層應(yīng)用暴露了更多的選項(xiàng)和責(zé)任，例如對(duì)事務(wù)序、負(fù)載均衡策略的選擇。一個(gè)新范式的勝利，不在于它解決了所有舊問(wèn)題而沒(méi)有引入任何新問(wèn)題，而在于它所解決的核心矛盾——在 UB 的案例中，即’性能’與’規(guī)?！拿堋钱?dāng)前時(shí)代最迫切、最重要的問(wèn)題。

擁塞控制

擁塞控制的歷史，本質(zhì)上是一部我們與”隊(duì)列”這個(gè)魔鬼的斗爭(zhēng)史。

最早，TCP/IP 的設(shè)計(jì)者認(rèn)為網(wǎng)絡(luò)是”盡力而為”的，擁塞的信號(hào)就是丟包。因此，TCP 采用了經(jīng)典的”加性增窗，乘性減窗”（AIMD）算法：沒(méi)丟包就慢慢增大發(fā)送窗口，一旦丟包，就猛烈地把窗口砍半。這個(gè)模型在廣域互聯(lián)網(wǎng)上取得了巨大成功，但它的一個(gè)根本問(wèn)題是，它是一個(gè)”事后”控制。它依賴隊(duì)列被填滿、最終導(dǎo)致丟包來(lái)感知擁塞，這必然導(dǎo)致兩個(gè)問(wèn)題：1）高延遲，即所謂的”Bufferbloat”（緩沖區(qū)膨脹）；2）網(wǎng)絡(luò)利用率劇烈震蕩。

為了解決這個(gè)問(wèn)題，人們提出了主動(dòng)隊(duì)列管理（AQM），其代表是 RED (Random Early Detection)。RED 的思想是，不要等到隊(duì)列滿了再丟包，而是在隊(duì)列長(zhǎng)度開(kāi)始增加時(shí)，就以一定概率隨機(jī)丟棄數(shù)據(jù)包，提前向發(fā)送方發(fā)出擁塞信號(hào)。這在一定程度上緩解了 Bufferbloat，但”丟包”作為一個(gè)擁塞信號(hào)，依然過(guò)于粗暴。

一個(gè)更溫和的方案是顯式擁塞通知（Explicit Congestion Notification, ECN）。ECN 允許路由器在發(fā)現(xiàn)隊(duì)列開(kāi)始積壓時(shí)，在包頭上打一個(gè)標(biāo)記，而不是丟棄它。發(fā)送方收到這個(gè)標(biāo)記后，就知道網(wǎng)絡(luò)出現(xiàn)了擁塞，從而主動(dòng)降低發(fā)送速率。ECN 避免了不必要的丟包和重傳，是現(xiàn)代網(wǎng)絡(luò)擁塞控制的標(biāo)配。

然而，在數(shù)據(jù)中心這種追求極致低延遲和高吞吐的場(chǎng)景下，這些基于 TCP 的擁塞控制方案依然不夠精細(xì)。特別是對(duì)于 RDMA 這種無(wú)連接、對(duì)丟包極度敏感的應(yīng)用，需要更快速、更精確的擁塞控制。RoCEv2 網(wǎng)絡(luò)為此設(shè)計(jì)了 DCQCN（Data Center Quantized Congestion Notification）。DCQCN 結(jié)合了 ECN 和基于速率的控制，交換機(jī)標(biāo)記擁塞后，網(wǎng)卡會(huì)快速地、按一定的步長(zhǎng)降低發(fā)送速率，實(shí)現(xiàn)了更快的收斂和更低的隊(duì)列占用。

UB 的 C-AQM (Confined Active Queue Management) 進(jìn)一步將這種精細(xì)化控制推向了極致。DCQCN 依然是一種”先擁塞、再降速”的被動(dòng)模式，而 C-AQM 的核心思想是”按需分配、主動(dòng)授予”，目標(biāo)是實(shí)現(xiàn)”近似零隊(duì)列”。這背后最大的優(yōu)勢(shì)，正是華為作為端到端（網(wǎng)卡+交換機(jī)）網(wǎng)絡(luò)設(shè)備提供商的”端網(wǎng)協(xié)同”能力。

C-AQM 的工作機(jī)制體現(xiàn)了這種協(xié)同的精妙之處：

1. 發(fā)送端（UB Controller）主動(dòng)請(qǐng)求：發(fā)送端在發(fā)送數(shù)據(jù)時(shí)，可以通過(guò)包頭中的 I（Increase）位置 1，來(lái)向網(wǎng)絡(luò)請(qǐng)求增加帶寬。

2. 交換機(jī)（UB Switch）精確反饋：當(dāng)交換機(jī)收到這個(gè)請(qǐng)求后，它會(huì)評(píng)估自己出口端口的擁塞狀況。如果認(rèn)為增加帶寬會(huì)導(dǎo)致?lián)砣粌H會(huì)在包頭中置位 C (Congestion) 位來(lái)拒絕請(qǐng)求，還會(huì)在 Hint 字段中，給出一個(gè)建議的帶寬值。這個(gè) Hint 值是交換機(jī)根據(jù)自己精確的隊(duì)列和帶寬占用情況計(jì)算出來(lái)的，它告訴發(fā)送端：”你不能再增加了，你應(yīng)該把速率調(diào)整到這個(gè)建議值”。

3. 發(fā)送端快速響應(yīng)：發(fā)送端收到這個(gè)包含了精確 Hint 值的反饋后，就可以立即將自己的發(fā)送速率調(diào)整到交換機(jī)建議的水平。

這個(gè)過(guò)程，就像一個(gè)聰明的交通指揮系統(tǒng)。司機(jī)（發(fā)送端）想要加速，先通過(guò)信號(hào)燈（I 位）詢問(wèn)前方的交警（交換機(jī)）。交警根據(jù)整個(gè)路口的實(shí)時(shí)車(chē)流情況，不僅會(huì)亮紅燈（C 位）告訴司機(jī)”不行”，還會(huì)通過(guò)對(duì)講機(jī)（Hint 字段）直接告訴司機(jī)”保持時(shí)速 30 公里”。

通過(guò)這種”請(qǐng)求-精確反饋”的閉環(huán)，C-AQM 使得發(fā)送端的發(fā)送速率與網(wǎng)絡(luò)能夠提供的服務(wù)能力被精確地匹配起來(lái)，數(shù)據(jù)包”隨到隨走”，交換機(jī)的隊(duì)列始終維持在一個(gè)極低的、接近于零的水位。這不僅徹底消除了 Bufferbloat 帶來(lái)的高延遲，也最大化了網(wǎng)絡(luò)的有效吞吐。這種近似零排隊(duì)的設(shè)計(jì)理念，是 UB 實(shí)現(xiàn)微秒級(jí)端到端延遲的關(guān)鍵基石之一。

可靠傳輸

在構(gòu)建任何一個(gè)可靠的網(wǎng)絡(luò)協(xié)議時(shí)，如何處理丟包都是核心議題。TCP/IP 的教科書(shū)式方案——“慢啟動(dòng)、擁塞避免、快重傳、快恢復(fù)”——早已深入人心。然而，在數(shù)據(jù)中心網(wǎng)絡(luò)中，為了最大化帶寬利用率，普遍采用了等價(jià)多路徑路由（ECMP）。流量被分散到多條物理路徑上傳輸，這不可避免地會(huì)導(dǎo)致數(shù)據(jù)包到達(dá)順序與發(fā)送順序不一致。一個(gè)根本性的矛盾便浮現(xiàn)出來(lái)：我們?nèi)绾文茉谝粋€(gè)充滿了”有序的亂序”的網(wǎng)絡(luò)中，精確地判斷出丟包？

然而，傳統(tǒng)的快速重傳機(jī)制，其核心邏輯是”收到三個(gè)重復(fù)的 ACK 就認(rèn)為一個(gè)包丟了”。這個(gè)假設(shè)在單一路徑上是基本合理的，但在 ECMP 環(huán)境下，這種”亂序”會(huì)輕易地騙過(guò)這個(gè)機(jī)制，導(dǎo)致大量的偽重傳（Spurious Retransmission）。網(wǎng)絡(luò)本身沒(méi)有丟包，只是有些包抄近路先到了，協(xié)議卻誤以為丟包，瘋狂發(fā)起不必要的重傳，這不僅浪費(fèi)了寶貴的帶寬，甚至可能因?yàn)橐肓祟~外的流量而導(dǎo)致真正的擁塞。

UB 的負(fù)載均衡機(jī)制

與傳統(tǒng)網(wǎng)絡(luò)中依賴 ECMP 哈希”聽(tīng)天由命”式的負(fù)載均衡不同，UB 將選擇權(quán)交給了應(yīng)用，讓其根據(jù)自身對(duì)性能和順序性的需求，在不同的負(fù)載均衡粒度之間做出明智的權(quán)衡。UB 支持兩個(gè)層次的負(fù)載均衡機(jī)制上：

1. 事務(wù)級(jí)負(fù)載均衡：基于 TPG 的”車(chē)隊(duì)”模式

UB 引入了 TPG (Transport Protocol Group) 的概念。我們可以將一個(gè) TPG 想象成一家物流公司，它負(fù)責(zé)將一批批的”貨物”（即事務(wù)）從 A 點(diǎn)運(yùn)到 B 點(diǎn)。為了提高運(yùn)力，這家公司可以同時(shí)使用多條高速公路，每一條高速公路就是一個(gè) TP Channel。

當(dāng)一個(gè)事務(wù)（例如一次大的 RDMA Write）需要發(fā)送時(shí)，TPG 會(huì)為它選擇一條 TP Channel。一旦選定，這個(gè)事務(wù)的所有數(shù)據(jù)包（TP Packet）都會(huì)在這條固定的”高速公路”上傳輸。這種模式，就像一個(gè)龐大的車(chē)隊(duì)，所有車(chē)輛都保持在同一條車(chē)道上行駛。

這種事務(wù)級(jí)負(fù)載均衡的巨大優(yōu)勢(shì)在于簡(jiǎn)單性和有序性。由于同一事務(wù)的所有數(shù)據(jù)包都在同一條路徑上，它們天然就是有序到達(dá)的，從根本上避免了包級(jí)亂序的發(fā)生。這使得上層的可靠傳輸協(xié)議可以放心地使用最高效的快速重傳機(jī)制，因?yàn)槿魏我粋€(gè)”重復(fù) ACK”的信號(hào)，都極大概率指向一次真正的丟包，而非亂序。這是一種安全、穩(wěn)定、易于管理的并行策略，適用于大多數(shù)需要可靠傳輸?shù)膱?chǎng)景。

2. 包級(jí)負(fù)載均衡：極致性能的”賽車(chē)”模式

對(duì)于那些追求極致網(wǎng)絡(luò)利用率和最低延遲的應(yīng)用，UB 提供了更為激進(jìn)的包級(jí)負(fù)載均衡機(jī)制。在這種模式下，系統(tǒng)允許同一個(gè)事務(wù)的數(shù)據(jù)包，被”打散”到多個(gè)不同的 TP Channel，甚至通過(guò)修改包頭中的 LBF 字段，在交換機(jī)層面被動(dòng)態(tài)地導(dǎo)向不同的物理路徑。

這就好比一場(chǎng)公路賽車(chē)，為了最快到達(dá)終點(diǎn)，每輛賽車(chē)（TP Packet）都可以自由選擇最不擁堵的車(chē)道，動(dòng)態(tài)超車(chē)、變道。

這種模式能最大程度地”填滿”網(wǎng)絡(luò)中的所有可用帶寬，實(shí)現(xiàn)無(wú)與倫比的吞吐量。然而，它也帶來(lái)了一個(gè)必然的”副作用”：亂序。后發(fā)的數(shù)據(jù)包完全有可能因?yàn)檫x擇了一條更快的路徑而先于先發(fā)的數(shù)據(jù)包到達(dá)。

多路徑下的丟包重傳

在多路徑傳輸下，對(duì)”丟包”的判斷必須更加審慎和智能。強(qiáng)行套用一個(gè)”一刀切”的方案是行不通的。因此，我們沒(méi)有設(shè)計(jì)一個(gè)萬(wàn)能的重傳算法，而是將重傳的決策權(quán)交還給用戶，由兩個(gè)維度的選擇構(gòu)成：

1.重傳范圍：是”一人犯錯(cuò)，全體罰站”，還是”精準(zhǔn)打擊”？

• GoBackN (GBN) ：這是一種簡(jiǎn)單而經(jīng)典的策略。一旦檢測(cè)到丟包，發(fā)送方會(huì)從丟失的那個(gè)包開(kāi)始，重傳它以及它之后所有已發(fā)送的包。這種方式的好處是實(shí)現(xiàn)簡(jiǎn)單，接收方需要維護(hù)的狀態(tài)極少。但在高延遲、高帶寬、高丟包率的網(wǎng)絡(luò)中，它可能會(huì)重傳大量本已正確送達(dá)的數(shù)據(jù)，造成效率低下。

• 選擇性重傳 (Selective Retransmission) ：這是一種更精細(xì)化的策略。發(fā)送方只重傳那些被確認(rèn)丟失的包。接收方需要維護(hù)一個(gè)更復(fù)雜的狀態(tài)（例如一個(gè) bitmask），來(lái)告訴發(fā)送方哪些包收到了，哪些沒(méi)收到。這種方式效率最高，但實(shí)現(xiàn)也更復(fù)雜。

2.觸發(fā)機(jī)制：是”火急火燎”，還是”三思后行”？

• 快速重傳 (Fast Retransmit) ：類(lèi)似于 TCP 的機(jī)制，通過(guò)冗余的確認(rèn)信息（例如 UB 中的錯(cuò)誤應(yīng)答）來(lái)快速觸發(fā)重傳，無(wú)需等待一個(gè)完整的超時(shí)周期。它的優(yōu)點(diǎn)是響應(yīng)快，能顯著降低丟包時(shí)的延遲。但如前所述，它對(duì)亂序非常敏感。

• 超時(shí)重傳 (Timeout Retransmit) ：這是最保守、最可靠的機(jī)制。發(fā)送方為每個(gè)發(fā)出的包啟動(dòng)一個(gè)計(jì)時(shí)器，如果超過(guò)預(yù)設(shè)時(shí)間（RTO）還沒(méi)收到確認(rèn)，就認(rèn)為包丟了并發(fā)起重傳。它的優(yōu)點(diǎn)是能最終兜底所有丟包場(chǎng)景，并且不受亂序影響。缺點(diǎn)是 RTO 的計(jì)算通常比較保守，等待超時(shí)的過(guò)程會(huì)引入較長(zhǎng)的延遲。

通過(guò)將這兩個(gè)維度的策略進(jìn)行組合，UB 為用戶提供了四種重傳模式，以適應(yīng)不同的網(wǎng)絡(luò)場(chǎng)景：

重傳與事務(wù)序的協(xié)同

前文我們討論了 UB 如何通過(guò)”弱事務(wù)序”來(lái)打破不必要的順序枷鎖，最大化并行傳輸?shù)男?。一個(gè)自然而深刻的問(wèn)題隨之而來(lái)：如果系統(tǒng)允許事務(wù)亂序執(zhí)行，那么一個(gè)”舊”事務(wù)的重傳包，與一個(gè)”新”事務(wù)的包，它們之間是什么關(guān)系？

我們有個(gè)核心的設(shè)計(jì)哲學(xué)：傳輸層的可靠性（Reliability）與事務(wù)層的順序性（Ordering）在設(shè)計(jì)上是正交解耦的。

• 傳輸層的使命：它的世界里只有 TP Packet 和它們的序列號(hào)（PSN）。它的唯一目標(biāo)，就是通過(guò) GBN 或選擇性重傳等機(jī)制，確保一個(gè)事務(wù)所對(duì)應(yīng)的 所有 TP Packet，最終能完整、無(wú)誤地從發(fā)送端（Initiator）的傳輸層，交付給接收端（Target）的傳輸層。它負(fù)責(zé)處理網(wǎng)絡(luò)中的物理丟包，實(shí)現(xiàn)”數(shù)據(jù)必達(dá)“。

• 事務(wù)層的使命：它的世界里只有事務(wù)（Transaction）以及它們的順序標(biāo)記（NO, RO, SO）。它的工作，是在傳輸層確認(rèn)收齊了一個(gè)事務(wù)的所有數(shù)據(jù)之后，才開(kāi)始的。它根據(jù)事務(wù)的順序標(biāo)記，來(lái)決定這個(gè)剛剛”湊齊”了所有零件的事務(wù)，應(yīng)該何時(shí)被執(zhí)行。它負(fù)責(zé)處理業(yè)務(wù)邏輯上的依賴關(guān)系，實(shí)現(xiàn)”按需保序“。

讓我們通過(guò)一個(gè)具體的場(chǎng)景來(lái)理解這種解耦如何工作：

1.發(fā)送：Initiator 先后發(fā)送了兩個(gè)事務(wù)：

• 事務(wù) A (RO)：被切分為三個(gè)包 A1, A2, A3。

• 事務(wù) B (RO)：被切分為兩個(gè)包 B1, B2。

2.丟包：在網(wǎng)絡(luò)傳輸中，A2 不幸丟失。而 A1, A3, B1, B2 都順利到達(dá)了 Target。

3.傳輸層響應(yīng)：Target 的 UB 傳輸層開(kāi)始工作。

• 對(duì)于事務(wù) B，它收到了 B1 和 B2，通過(guò) PSN 檢查發(fā)現(xiàn)數(shù)據(jù)完整。于是，它將重組好的事務(wù) B 向上交付給事務(wù)層，宣告任務(wù)完成。

• 對(duì)于事務(wù) A，它收到了 A1 和 A3，但通過(guò) PSN 或 Bitmap 發(fā)現(xiàn) A2 不見(jiàn)了。它會(huì)默默地將 A1 和 A3 緩存起來(lái)，同時(shí)通過(guò) TPNAK 或等待超時(shí)等機(jī)制，通知 Initiator 的傳輸層：”A2 丟了，請(qǐng)重發(fā)?！?/p>

4.事務(wù)層決策：此時(shí)，Target 的事務(wù)層也開(kāi)始工作。

• 它收到了從傳輸層遞交上來(lái)的、完整的事務(wù) B。

• 它檢查事務(wù) B 的順序標(biāo)記，是 RO（Relaxed Order）。這意味著 B 無(wú)需等待在它之前發(fā)送的任何事務(wù)。

• 因此，事務(wù)層會(huì)立刻將事務(wù) B 投入執(zhí)行，完全無(wú)視此刻還在苦苦等待重傳包 A2 的事務(wù) A。

5.重傳與最終執(zhí)行：

• 稍后，重傳的 A2 數(shù)據(jù)包終于抵達(dá)。

• Target 的傳輸層將它與之前緩存的 A1, A3 成功合體，重組出完整的事務(wù) A，并交付給事務(wù)層。

• 事務(wù)層收到事務(wù) A，檢查其 RO 標(biāo)記，同樣將其立即投入執(zhí)行。

在這個(gè)過(guò)程中，一個(gè)”舊”事務(wù)（A）的丟包和重傳，完全沒(méi)有阻塞一個(gè)”新”事務(wù)（B）的執(zhí)行。這就是弱事務(wù)序與可靠傳輸協(xié)同工作的威力。

那么，強(qiáng)順序（SO）又會(huì)如何改變這一切呢？

如果在上述場(chǎng)景中，事務(wù) B 被標(biāo)記為 SO (Strong Order) ，那么在第 4 步”事務(wù)層決策”時(shí)，情況將完全不同。當(dāng)事務(wù)層收到完整的事務(wù) B 后，它會(huì)檢查其 SO 標(biāo)記，并意識(shí)到自己必須等待所有在 B 之前的事務(wù)（即事務(wù) A）執(zhí)行完畢。因此，即使 B 的所有數(shù)據(jù)都已備齊，事務(wù)層也只能讓它”原地待命”，直到重傳的 A2 到達(dá)、事務(wù) A 被成功執(zhí)行后，事務(wù) B 才能被執(zhí)行。

總結(jié)而言，UB 的這套解耦設(shè)計(jì)，實(shí)現(xiàn)了一種極致的效率：

• 網(wǎng)絡(luò)層面的問(wèn)題，就在網(wǎng)絡(luò)層面解決：傳輸層可以積極地使用各種高級(jí)技巧（如選擇性重傳）來(lái)最高效地對(duì)抗丟包，而不用擔(dān)心自己的行為會(huì)干擾到上層業(yè)務(wù)的邏輯順序。

• 業(yè)務(wù)層面的順序，由業(yè)務(wù)自己決定：事務(wù)層則可以從網(wǎng)絡(luò)細(xì)節(jié)中解脫出來(lái)，專(zhuān)注于根據(jù)應(yīng)用的真實(shí)需求來(lái)決定是否需要等待、需要何種強(qiáng)度的順序保證，從而避免了不必要的”隊(duì)頭阻塞”。

這種清晰的責(zé)任劃分，使得系統(tǒng)在默認(rèn)情況下獲得了最大的并行度和性能，同時(shí)又為需要強(qiáng)一致性的應(yīng)用保留了構(gòu)建嚴(yán)格順序的能力。這是對(duì)現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)復(fù)雜性的一種優(yōu)雅且高效的回答。

死鎖避免

數(shù)據(jù)鏈路層的死鎖避免

在任何一個(gè)保證無(wú)損（lossless）的通信網(wǎng)絡(luò)中，死鎖都是一個(gè)必須面對(duì)的幽靈。當(dāng)網(wǎng)絡(luò)采用基于信用的流控（Credit-based Flow Control）或背壓機(jī)制（Back Pressure）時(shí)，如果資源（如緩沖區(qū)）的依賴關(guān)系構(gòu)成了環(huán)路，就可能出現(xiàn)所有節(jié)點(diǎn)都在等待對(duì)方釋放資源，而自己又占著資源不放的”循環(huán)等待”狀態(tài)，這就是死鎖。

一個(gè)典型的場(chǎng)景是：網(wǎng)絡(luò)中有四個(gè)交換機(jī)，構(gòu)成了一個(gè)環(huán)形依賴。UB Switch 1 的出口緩沖區(qū)滿了，因?yàn)樗氲竭_(dá) UB Switch 2 的數(shù)據(jù)發(fā)不出去；Switch 2 的緩沖區(qū)也滿了，因?yàn)樗诘却?Switch 3；Switch 3 在等待 Switch 4；而 Switch 4 又在等待 Switch 1。所有的緩沖區(qū)都被占滿，數(shù)據(jù)無(wú)法流動(dòng)，整個(gè)系統(tǒng)陷入停滯。

為了避免這種災(zāi)難性的情況發(fā)生，必須在設(shè)計(jì)上打破這種循環(huán)等待的條件。在 UB 設(shè)計(jì)中，采用以下幾種經(jīng)典的死鎖避免方案：

1.基于路由的死鎖避免

這種方法從根本上入手，通過(guò)設(shè)計(jì)一個(gè)無(wú)環(huán)的路由算法來(lái)保證死鎖不會(huì)發(fā)生。一個(gè)經(jīng)典的例子是基于生成樹(shù)的”上/下路由”（Up/Down Routing）。首先在網(wǎng)絡(luò)拓?fù)渲写_定一個(gè)根節(jié)點(diǎn)，并構(gòu)建一個(gè)生成樹(shù)。路由規(guī)則被限制為：數(shù)據(jù)包可以從”下方”節(jié)點(diǎn)路由到”上方”節(jié)點(diǎn)（即更靠近根節(jié)點(diǎn)的節(jié)點(diǎn)），也可以從”上方”節(jié)點(diǎn)路由到”下方...