異數OS 織夢師-水母（一）–訊息佇列篇

本文來自異數OS社群

github： https://github.com/yds086/HereticOS

異數OS社群QQ群： 652455784

異數OS-織夢師（訊息中介軟體）群： 476260389

織夢師-水母 訊息佇列簡介

這是一個使用異數OS技術實做的輕量級的訊息中介軟體，和他的名字一樣，重在表演，他不是一個功能複雜齊全的訊息佇列，使用者需要根據自己需求按照水母的原理去製作自己的超級武器，整個框架，協議，測試等程式碼算下來僅僅1000行，但已經是一個比較完整可用的訊息隊列了（topic沒做，由nameserver去做吧），持久化方便測試使用虛完成，下一階段會接入織夢師-水桶 RAM網盤儲存方案

與眾不同的特性

1.生產者惰性QOS控制，在開啟該特性後，生產者執行緒在佇列滿載後會被阻塞掛起，在佇列可用時恢復並嘗試重新入隊，此特性在佇列壓力較大時可大大降低錯誤重試的網路IO需求，大大增加佇列高負載時的可用性

2.低延遲低佇列深度可用，織夢師-水母的延遲極低，內網生產者入隊僅需10us延遲（82599），佇列無壓力時到消費者延遲20us，因此只要消費者滿足需要，一般佇列深度128即可穩定工作（異數OS系產品本身並不需要訊息佇列做削峰填谷，這是給老舊落後的產品做的

3.海量生產者特性，每Broker最大可接入1000W連結生產者（阻塞IO執行緒），因此有望直接在公網接受使用者生產者檢驗，而不需要系統前端加LVS或者Nginx分流出多生產者。

4.高效能的訊息佇列，dpdk 82599雙口 單CPU核環境，128生產者下，非批量訊息，最大入隊峰值4M每秒，到消費者最大2M峰值，批量則再根據批量規模和頻寬來計算放大倍率，1200W連結最大160W訊息入隊，到消費者最大80W，後面會支援RSS 單Broker多佇列聚合，成倍擴充單broker效能。

架構說明

織夢師-水母使用阻塞執行緒模型，因此相比非同步IO的架構，結構非常簡單輕量穩定可靠，程式碼和框架是對生產者，消費者模型的高度對應，你看到的框架圖就是程式碼。

測試說明

CPU1 作為日誌監控核，CPU3作為經紀人Broker,CPU5建立生產者消費者，成績為10位元組10個訊息批量模式，批量僅供參考。
日誌中引數可自己查閱git中程式碼做分析參考。

測試成績

異數OS虛擬交換機下，128生產者，128消費者

異數OS虛擬交換機下，600W生產者，128消費者

異數OS DPDK雙口交換，128生產者，128消費者

異數OS DPDK雙口交換，600W生產者，128消費者

相關產品效能對比

以下成績都是1 Borker下得到的效能,其他產品資料來自網路的大概參考資料。

非批量訊息模式

批量訊息模式

10位元組訊息批量入隊出隊，織夢師-水母測試用批量規模為10個訊息批量

研發吐槽

RSS方案已經可以正常使用，雙核ECHO 8M IO的樣子，DPDK在異數OS負優化下，在海量連結環境中，終於不丟包，但代價是慘烈的，相對netmap方案，效能損失30%，實踐推測這是由於DPDK polling在需要訪存延遲較高的情況下，網絡卡無法利用mbuf進行資料傳輸，因此你開再多的mbuf都不濟於事，而netmap由於使用驅動的硬體中斷，因此即便不polling，網絡卡中斷也能完成和netmap ring的資料傳輸，所以netmap的polling實際上反而更高效，有削峰填谷作用，為了拯救DPDK polling導致的網絡卡飢餓，異數OS做了更加細粒度的任務排程，併為DPDK網絡卡驅動做了ns精度級別的任務排程，動態控制DPDK tx發包規模，從而實現了600W（1200W）連結的0丟包。