本篇文章主要介紹了Rust中流處理的概念、方法和優(yōu)化。作者不僅介紹了流處理的基本概念以及Rust中常用的流處理庫，還使用這些庫實現(xiàn)了一個流處理程序。

最后，作者介紹了如何通過測量空閑和阻塞時間來優(yōu)化流處理程序的性能，并將這些內(nèi)容同步至Twitter和blog。

此外，作者還提供了一些其它方面的優(yōu)化建議，例如：

• 在實際系統(tǒng)中，應(yīng)考慮將線程固定至CPU內(nèi)核上或使用一種版本的綠色線程減少上下文切換。
• 在處理流時，通常需要為結(jié)果分配內(nèi)存。內(nèi)存分配是昂貴的，所以，在以后的文章中，作者將會介紹一些優(yōu)化內(nèi)存分配的好方法。

首先，分別介紹下在同步和異步Rust中的流特質(zhì)。

一、同步和異步Rust中的流特質(zhì)

在同步Rust中，流核心抽象是Iterator。它提供了在序列中產(chǎn)生項的方法并在它們之間進(jìn)行阻塞，然后，通過將迭代器傳遞給其它迭代器的構(gòu)造函數(shù)完成組合。這使我們可以毫不費(fèi)力地將事物連接在一起。

在異步Rust中，流核心抽象是Stream。它的行為與Iterator非常相似；但是，它并不是在每個項之間產(chǎn)生的阻塞，而是允許其它任務(wù)在阻塞等待時運(yùn)行。

在異步Rust與同步Rust中，Read和Write分別對應(yīng)AsyncRead和AsyncWrite。這些特質(zhì)表明：未解析的字節(jié)通常直接來自10層（例如，來自套接字或文件）。

Rust流吸收了其它語言所具備的最佳功能；例如，它們能通過利用Rust特質(zhì)系統(tǒng)回避Node.js的Duplex流中出現(xiàn)的遺留問題，也能同時實施背壓和惰性迭代，大大提升了效率。最重要的是，Rust流允許使用相同類型的異步迭代。

未來，關(guān)于Rust流還有很多值得關(guān)注之處，盡管仍有一些問題亟待解決。

二、總體概括：什么是流處理？

現(xiàn)在，也許你已經(jīng)了解到了同步和異步Rust中的流特質(zhì)，下面再來介紹下什么是“流處理”。

“流處理”是一種重要的大數(shù)據(jù)處理手段，其主要特點(diǎn)是處理的數(shù)據(jù)是源源不斷且實時到來的。

在不同規(guī)模的科技公司中，流處理通常被用于分析和處理具體事件，且常被應(yīng)用于分布式系統(tǒng)。

有些領(lǐng)域確實會大量使用“流處理”手段，包括：視頻處理和高頻交易。我們也能夠借此尋找到新型區(qū)塊鏈之中的架構(gòu)靈感。因為，區(qū)塊鏈需要處理交易和元數(shù)據(jù)流等。

如今，你可以租用具有100多個CPU的內(nèi)核、100GB內(nèi)存、多個GPU和100Gbps帶寬的AWS實例，還無需擁有一個節(jié)點(diǎn)的分布式系統(tǒng)。

現(xiàn)在，讓我們了解下流處理在Rust編程中的應(yīng)用：

三、舉個例子：計算10億個數(shù)字的哈希程序

現(xiàn)在，讓我們寫一個用來計算10億個數(shù)字的SHA512和BLAKE3哈希程序吧！你可以想象：數(shù)字代表交易、分析事件或價格信號。散列法可用來表示對這些輸入的任意轉(zhuǎn)換。

如下是單線程解決方案程序：

當(dāng)我在帶有專用CPU和16核的Digital Ocean上用發(fā)布模式運(yùn)行此程序時，只需6分鐘多一點(diǎn)。

1.通道

現(xiàn)在，讓我們用“流處理”來重寫這個程序。與在單個循環(huán)中執(zhí)行散列不同，我們將設(shè)置一個線程管道并行執(zhí)行散列，然后收集結(jié)果。

在兩個線程之間發(fā)送數(shù)據(jù)的本地流被稱為通道。我們的新程序?qū)⑸伤膫€線程。生成器線程將生成數(shù)字并同時將它們發(fā)送至兩個不同的哈希線程。散列線程將讀取這些數(shù)字，分別對它們進(jìn)行散列，然后將它們的輸出發(fā)送給結(jié)果線程，下圖是它的架構(gòu)：

我們也將使用標(biāo)準(zhǔn)庫中的mpsc通道發(fā)送和接收數(shù)據(jù)。mpsc可用來表示“多生產(chǎn)者-單消費(fèi)者”，代表你可以從多個線程向通道發(fā)送數(shù)據(jù)，但是，只有一個管道能夠輸出數(shù)據(jù)。雖然我們不會使用這個多制作人功能，但是了解這一點(diǎn)很重要。

它仍是一個相當(dāng)簡單的程序：

輸出結(jié)果如下：

哦！帶通道的新版本花費(fèi)了兩倍時間，這是怎么了？

2.環(huán)形緩沖器

你可以用火焰圖進(jìn)行測試，但還是省省時間吧！

無論多小，所有通道庫的構(gòu)建都會產(chǎn)生額外的費(fèi)用，并行化所帶來的好處必須大于此種開銷，才能保證系統(tǒng)正常運(yùn)作。這種情況下的瓶頸是通道send（）和recv（）。由于Rust中的標(biāo)準(zhǔn)庫mpsc通道相對緩慢，但仍有其它替代方案，比如，crossbeam-channel。

為此，我們分析了4個不同的通道庫，結(jié)果如下：

顯然，ringbuf和rtrb速度最快。因為它們的環(huán)形緩沖區(qū)無鎖，扮演著“單個生產(chǎn)者-單個消費(fèi)者”的角色。單個生產(chǎn)者意味著只有一個管道將數(shù)據(jù)放入隊列，另一個管道將負(fù)責(zé)數(shù)據(jù)輸出，這比“多生產(chǎn)者隊列”開銷小。

此外，這些程序庫也是非阻塞式的。當(dāng)隊列已滿時，如果嘗試推送，它將提示“error”而不是“block”，“空隊列”亦是如此。

為使用這些環(huán)形緩沖區(qū)庫，我添加了自旋鎖，以便在通道阻塞時繼續(xù)重試。事實證明，這也是高頻交易架構(gòu)中所使用的方法。

我還發(fā)現(xiàn)，在等待時增加非常短的“休眠”時間整體性能就能提高。這可能是由于當(dāng)核心使用率達(dá)到100%或高于某些溫度時，啟動CPU就會發(fā)生節(jié)流的現(xiàn)象。

如下是新的pop()和push(value)幫助器：

我們將用新方法展示：

速度確實比以前快了，但也快不了多少，現(xiàn)在，就讓我們把并行化提升至另一個層次。

3.更多的并行化

目前，我們?yōu)楣?chuàng)建了兩個線程，一個用于SHA512，另一個用于BLAKE3。兩者中較慢的那個將成為我們技術(shù)發(fā)展的瓶頸。為證明這一點(diǎn)，我重新運(yùn)行了原始的單線程示例，僅使用SHA512哈希，結(jié)果如下：

這與并行哈希示例中的性能非常接近，意味著，總體上花在哈希上的大部分時間都是由SHA512產(chǎn)生。

那么，如果我們同時創(chuàng)建更多的線程并將多個數(shù)字進(jìn)行散列排列呢?讓我們試一試。我們將創(chuàng)建2個SHA512哈希線程和2個BLAKE3哈希線程來啟動。

4.可視化

每個線程都擁有自己的輸入和輸出隊列。我們將用循環(huán)順序?qū)⑸傻臄?shù)字循環(huán)發(fā)送至每個線程并用相同的順序讀取結(jié)果。

這確保了流的順序能夠在結(jié)果線程中維持不變；如果排序不重要或消息處理時間多變，那么，其它的調(diào)度機(jī)制可能會更好。

如下是循環(huán)調(diào)度代碼：

新的代碼更復(fù)雜，部分如下：

一起來看看，現(xiàn)在表現(xiàn)如何？輸出結(jié)果如下：

確實好多了！

5.測量“閑置”和“阻塞”時間

每個哈希函數(shù)應(yīng)該有多少個線程？在更復(fù)雜的系統(tǒng)中，這很難確定，甚至可能是動態(tài)的。

實際上，有一種技術(shù)對“流處理”很有幫助，即，在某個時間窗口內(nèi)測量空閑和阻塞時間。

• 空閑時間

等待空隊列接收消息所花的時間

• 全程時間

等待滿隊列發(fā)送輸出所花費(fèi)的時間

空閑時間是pop()期間旋轉(zhuǎn)的時間，阻塞時間是push()期間旋轉(zhuǎn)的時間。我修改了這兩個函數(shù)，用來跟蹤花費(fèi)時間。這段代碼使用了開銷很小的單元：

我還創(chuàng)建了一個新的線程統(tǒng)計這些時間，輸出結(jié)果如下：

我們可以看到，sha512線程既沒有“空閑”也沒有“阻塞”，而是100%處于活躍狀態(tài)；此外，我們還能通過增加sha512線程數(shù)量為系統(tǒng)提速。

注：當(dāng)用測量系統(tǒng)的行為改變其性能時，可能會出現(xiàn)像“海森伯測不準(zhǔn)原理”這樣的問題。如果遇到此種情況，請查看“粗時間庫”；通常，定時測量取近似值就足夠了。

我們在Digital Ocean實例中，經(jīng)過試驗和錯誤數(shù)據(jù)總結(jié)出：最佳數(shù)量是8個SHA512線程和4個BLAKE3線程。

結(jié)果：小于初始時間的1/6。

四、下一步：為不同的流處理結(jié)果分配內(nèi)存

在這篇文章中，我們用具體實例介紹了Rust中流處理的概念、方法和優(yōu)化，但是還有很多細(xì)節(jié)沒有討論。在實際系統(tǒng)中，我們應(yīng)該考慮將“線程”固定到CPU內(nèi)核上，用來減少上下文切換。

此外，在流處理時，你通常需要為不同的結(jié)果分配內(nèi)存。這是昂貴的，所以，在今后的文章中，我們還將討論這方面的一些策略。

多看看優(yōu)秀的前沿工具

太空電梯、MOSS、ChatGPT等，都預(yù)兆著2023年注定不會是平凡的一年。任何新的技術(shù)都值得推敲，我們應(yīng)要有這種敏感性。

這幾年隱約碰過低代碼，目前比較熱門，很多大廠都相繼加入。

低代碼平臺概念：通過自動代碼生成和可視化編程，只需要少量代碼，即可快速搭建各種應(yīng)用。

到底啥是低代碼，在我看來就是拖拉拽，呼呼呼，一通操作，搞出一套能跑的系統(tǒng)，前端，后端，數(shù)據(jù)庫，一把完成。當(dāng)然這可能是最終目標(biāo)。

鏈接：www.jnpfsoft.com/?csdn，如果你感興趣，也體驗一下。

JNPF的優(yōu)勢就在于它能生成前后臺代碼，提供了極大的靈活性，能夠創(chuàng)建更復(fù)雜、定制化的應(yīng)用。它的架構(gòu)設(shè)計也讓開發(fā)者無需擔(dān)心底層技術(shù)細(xì)節(jié)，能夠?qū)Ｗ⒂趹?yīng)用邏輯和用戶體驗的開發(fā)。文章來源地址http://www.zghlxwxcb.cn/news/detail-626338.html

到了這里，關(guān)于Rust中的高吞吐量流處理的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！