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