建站
咨詢
售后
建站咨詢
新聞中心
作者 | Noz
編譯 | 王瑞平
本篇文章主要介紹了Rust中流處理的概念、方法和優(yōu)化。作者不僅介紹了流處理的基本概念以及Rust中常用的流處理庫，還使用這些庫實現(xiàn)了一個流處理程序。
最后，作者介紹了如何通過測量空閑和阻塞時間來優(yōu)化流處理程序的性能，并將這些內(nèi)容同步至Twitter和blog。
圖片
此外，作者還提供了一些其它方面的優(yōu)化建議，例如：
- 在實際系統(tǒng)中，應考慮將線程固定至CPU內(nèi)核上或使用一種版本的綠色線程減少上下文切換。
- 在處理流時，通常需要為結(jié)果分配內(nèi)存。內(nèi)存分配是昂貴的，所以，在以后的文章中，作者將會介紹一些優(yōu)化內(nèi)存分配的好方法。
首先，分別介紹下在同步和異步Rust中的流特質(zhì)。
一、同步和異步Rust中的流特質(zhì)
在同步Rust中，流核心抽象是Iterator。它提供了在序列中產(chǎn)生項的方法并在它們之間進行阻塞，然后，通過將迭代器傳遞給其它迭代器的構(gòu)造函數(shù)完成組合。這使我們可以毫不費力地將事物連接在一起。
在異步Rust中，流核心抽象是Stream。它的行為與Iterator非常相似；但是，它并不是在每個項之間產(chǎn)生的阻塞，而是允許其它任務在阻塞等待時運行。
在異步Rust與同步Rust中，Read和Write分別對應AsyncRead和AsyncWrite。這些特質(zhì)表明：未解析的字節(jié)通常直接來自10層（例如，來自套接字或文件）。
圖片
Rust流吸收了其它語言所具備的最佳功能；例如，它們能通過利用Rust特質(zhì)系統(tǒng)回避Node.js的Duplex流中出現(xiàn)的遺留問題，也能同時實施背壓和惰性迭代，大大提升了效率。最重要的是，Rust流允許使用相同類型的異步迭代。
未來，關于Rust流還有很多值得關注之處，盡管仍有一些問題亟待解決。
二、總體概括：什么是流處理？
現(xiàn)在，也許你已經(jīng)了解到了同步和異步Rust中的流特質(zhì)，下面再來介紹下什么是“流處理”。
“流處理”是一種重要的大數(shù)據(jù)處理手段，其主要特點是處理的數(shù)據(jù)是源源不斷且實時到來的。
在不同規(guī)模的科技公司中，流處理通常被用于分析和處理具體事件，且常被應用于分布式系統(tǒng)。
有些領域確實會大量使用“流處理”手段，包括：視頻處理和高頻交易。我們也能夠借此尋找到新型區(qū)塊鏈之中的架構(gòu)靈感。因為，區(qū)塊鏈需要處理交易和元數(shù)據(jù)流等。
如今，你可以租用具有100多個CPU的內(nèi)核、100GB內(nèi)存、多個GPU和100Gbps帶寬的AWS實例，還無需擁有一個節(jié)點的分布式系統(tǒng)。
現(xiàn)在，讓我們了解下流處理在Rust編程中的應用：
三、舉個例子：計算10億個數(shù)字的哈希程序
現(xiàn)在，讓我們寫一個用來計算10億個數(shù)字的SHA512和BLAKE3哈希程序吧！你可以想象：數(shù)字代表交易、分析事件或價格信號。散列法可用來表示對這些輸入的任意轉(zhuǎn)換。
如下是單線程解決方案程序：
圖片
當我在帶有專用CPU和16核的Digital Ocean上用發(fā)布模式運行此程序時，只需6分鐘多一點。
圖片
1.通道
現(xiàn)在，讓我們用“流處理”來重寫這個程序。與在單個循環(huán)中執(zhí)行散列不同，我們將設置一個線程管道并行執(zhí)行散列，然后收集結(jié)果。
在兩個線程之間發(fā)送數(shù)據(jù)的本地流被稱為通道。我們的新程序?qū)⑸伤膫€線程。生成器線程將生成數(shù)字并同時將它們發(fā)送至兩個不同的哈希線程。散列線程將讀取這些數(shù)字，分別對它們進行散列，然后將它們的輸出發(fā)送給結(jié)果線程，下圖是它的架構(gòu)：
圖片
我們也將使用標準庫中的mpsc通道發(fā)送和接收數(shù)據(jù)。mpsc可用來表示“多生產(chǎn)者-單消費者”，代表你可以從多個線程向通道發(fā)送數(shù)據(jù)，但是，只有一個管道能夠輸出數(shù)據(jù)。雖然我們不會使用這個多制作人功能，但是了解這一點很重要。
它仍是一個相當簡單的程序：
圖片
輸出結(jié)果如下：
圖片
哦！帶通道的新版本花費了兩倍時間，這是怎么了？
2.環(huán)形緩沖器
你可以用火焰圖進行測試，但還是省省時間吧！
無論多小，所有通道庫的構(gòu)建都會產(chǎn)生額外的費用，并行化所帶來的好處必須大于此種開銷，才能保證系統(tǒng)正常運作。這種情況下的瓶頸是通道send（）和recv（）。由于Rust中的標準庫mpsc通道相對緩慢，但仍有其它替代方案，比如，crossbeam-channel。
為此，我們分析了4個不同的通道庫，結(jié)果如下：
圖片
顯然，ringbuf和rtrb速度最快。因為它們的環(huán)形緩沖區(qū)無鎖，扮演著“單個生產(chǎn)者-單個消費者”的角色。單個生產(chǎn)者意味著只有一個管道將數(shù)據(jù)放入隊列，另一個管道將負責數(shù)據(jù)輸出，這比“多生產(chǎn)者隊列”開銷小。
此外，這些程序庫也是非阻塞式的。當隊列已滿時，如果嘗試推送，它將提示“error”而不是“block”，“空隊列”亦是如此。
為使用這些環(huán)形緩沖區(qū)庫，我添加了自旋鎖，以便在通道阻塞時繼續(xù)重試。事實證明，這也是高頻交易架構(gòu)中所使用的方法。
我還發(fā)現(xiàn)，在等待時增加非常短的“休眠”時間整體性能就能提高。這可能是由于當核心使用率達到100%或高于某些溫度時，啟動CPU就會發(fā)生節(jié)流的現(xiàn)象。
如下是新的pop()和push(value)幫助器：
圖片
我們將用新方法展示：
圖片
速度確實比以前快了，但也快不了多少，現(xiàn)在，就讓我們把并行化提升至另一個層次。
3.更多的并行化
目前，我們?yōu)楣?chuàng)建了兩個線程，一個用于SHA512，另一個用于BLAKE3。兩者中較慢的那個將成為我們技術發(fā)展的瓶頸。為證明這一點，我重新運行了原始的單線程示例，僅使用SHA512哈希，結(jié)果如下：
圖片
這與并行哈希示例中的性能非常接近，意味著，總體上花在哈希上的大部分時間都是由SHA512產(chǎn)生。
那么，如果我們同時創(chuàng)建更多的線程并將多個數(shù)字進行散列排列呢?讓我們試一試。我們將創(chuàng)建2個SHA512哈希線程和2個BLAKE3哈希線程來啟動。
4.可視化
每個線程都擁有自己的輸入和輸出隊列。我們將用循環(huán)順序?qū)⑸傻臄?shù)字循環(huán)發(fā)送至每個線程并用相同的順序讀取結(jié)果。
圖片
這確保了流的順序能夠在結(jié)果線程中維持不變；如果排序不重要或消息處理時間多變，那么，其它的調(diào)度機制可能會更好。
如下是循環(huán)調(diào)度代碼：
圖片
新的代碼更復雜，部分如下：
圖片
一起來看看，現(xiàn)在表現(xiàn)如何？輸出結(jié)果如下：
圖片
確實好多了！
5.測量“閑置”和“阻塞”時間
每個哈希函數(shù)應該有多少個線程？在更復雜的系統(tǒng)中，這很難確定，甚至可能是動態(tài)的。
實際上，有一種技術對“流處理”很有幫助，即，在某個時間窗口內(nèi)測量空閑和阻塞時間。
- 空閑時間
等待空隊列接收消息所花的時間
- 全程時間
等待滿隊列發(fā)送輸出所花費的時間
空閑時間是pop()期間旋轉(zhuǎn)的時間，阻塞時間是push()期間旋轉(zhuǎn)的時間。我修改了這兩個函數(shù)，用來跟蹤花費時間。這段代碼使用了開銷很小的單元：
圖片
我還創(chuàng)建了一個新的線程統(tǒng)計這些時間，輸出結(jié)果如下：
圖片
我們可以看到，sha512線程既沒有“空閑”也沒有“阻塞”，而是100%處于活躍狀態(tài)；此外，我們還能通過增加sha512線程數(shù)量為系統(tǒng)提速。
注：當用測量系統(tǒng)的行為改變其性能時，可能會出現(xiàn)像“海森伯測不準原理”這樣的問題。如果遇到此種情況，請查看“粗時間庫”；通常，定時測量取近似值就足夠了。
我們在Digital Ocean實例中，經(jīng)過試驗和錯誤數(shù)據(jù)總結(jié)出：最佳數(shù)量是8個SHA512線程和4個BLAKE3線程。
圖片
結(jié)果：小于初始時間的1/6。
四、下一步：為不同的流處理結(jié)果分配內(nèi)存
在這篇文章中，我們用具體實例介紹了Rust中流處理的概念、方法和優(yōu)化，但是還有很多細節(jié)沒有討論。在實際系統(tǒng)中，我們應該考慮將“線程”固定到CPU內(nèi)核上，用來減少上下文切換。
此外，在流處理時，你通常需要為不同的結(jié)果分配內(nèi)存。這是昂貴的，所以，在今后的文章中，我們還將討論這方面的一些策略。
參考資料：
1.https://noz.ai/hash-pipeline/
2.https://zhuanlan.zhihu.com/p/70247995?utm_id=0
網(wǎng)頁名稱：Rust中的高吞吐量流處理
標題網(wǎng)址：http://www.dlmjj.cn/article/cohcojs.html
