前言

最近用了幾個月的時間，一直在對EQueue做效能優化。到現在總算告一段落了，現在把一些優化的結果分享給大家。EQueue是一個分散式的訊息佇列，設計思路基本和阿里的RocketMQ一致，只是是用純C#寫的，這點大家應該都知道了。

之前EQueue 1.*版本，訊息持久化是使用SQLServer的，之前也想做效能測試，但發現效果不理想。所以放棄了測試，轉為專心對訊息持久化這塊進行優化。之前的持久化設計是通過Sql Bulk Copy的方式非同步批量持久化訊息。但是當資料庫伺服器和Broker本身部署在不同的伺服器上時，持久化訊息也會走網絡卡，消耗頻寬，影響訊息的傳送和消費的TPS。而如果資料庫伺服器部署在Broker同一臺伺服器上，則因為SQLServer本身也會消耗CPU以及記憶體，也會影響Broker的訊息傳送和消費的TPS。所以，經過考慮後，最終決定狠下心來，採用終極方案來持久化訊息，就是通過本地順序寫檔案的方式來持久化訊息。支援非同步刷盤和同步刷盤兩種方式。採用檔案儲存後，EQueue可以輕易的支援大量訊息的堆積，你的硬碟有多大，就能堆積多少量的訊息。

到現在為止，經過不斷的測試，功能上我認為已經比較穩定了，效能也基本滿足我的要求。另外，EQueue單純的訊息持久化模組（MessageStore）以及TCP通訊層的效能是非常高的。MessageStore我設計時，儘量獨立一些，因為我發現寫檔案和讀檔案的設計是通用的，以後可以被複用到其他專案，所以我設計時，確保持久化模組的通用性；而TCP通訊層，也是也是一樣，通用和高效。目前我自己寫的通訊層（在ECommon類庫中）可以輕鬆把網絡卡壓滿。

關於EQueue 2.0檔案持久化版本的具體設計，我下一篇文章會具體介紹，本文主要是想分享一下EQueue 2.0的效能測試結果。為大家在使用到線上環境前做架構選型給出效能方面的參考。

測試目的

測試單個EQueue Broker伺服器的傳送訊息、消費訊息的效能。

硬體環境

全部採用UCloud雲主機進行測試。一臺Broker，4臺Client機器。Broker的配置為8核16G記憶體，120G的SSD硬碟，Client的配置為4核8G記憶體，普通硬碟。所有伺服器作業系統均為Windows Server 2012。具體如下圖所示：

測試場景1

1臺生產者、1臺消費者、1臺Broker，非同步刷盤，每隔100ms刷一次盤。

測試場景2

2臺生產者、2臺消費者、1臺Broker，非同步刷盤，每隔100ms刷一次盤。

結束語

一些說明

1. 因為EQueue的Producer傳送訊息時，本地會有快取佇列。所以Producer傳送訊息採用的執行緒數對傳送TPS並無什麼影響。所以，我上面的測試中並沒有考慮傳送執行緒數；
2. Broker的記憶體使用我們是可以控制的，我測試時配置為當記憶體使用到達40%時，開始自動清理記憶體，所以上面的測試結果，記憶體使用都不會超過40%；
3. 因為消費者從Broker拉取訊息時，EQueue的設計在記憶體足夠的情況下，總是會將需要消費的訊息快取在非託管記憶體，所以消費者拉取訊息時，總是從記憶體獲取訊息的。所以Broker沒有磁碟的讀取；且由於這個設計，消費者消費訊息不會成為瓶頸，假設當前Broker上存在大量訊息可以被消費，然後我們開一個Consumer，那消費速度是非常快的，1K大小的訊息，10W TPS沒有問題。所以，訊息的消費不會成為瓶頸，除非消費者自己內部處理訊息的程式碼太慢。這種情況下，消費者需要增加Consumer機器，確保消費速度跟得上傳送速度。
4. 上面的測試結果是基於UCloud的虛擬機器，由於我沒有物理機，所以不知道物理機上的效能。有條件的朋友我非常希望能幫忙測試下哦。像這種重要的分散式訊息佇列伺服器，是應該部署在物理機上的。另外，我測試時，Producer和Consumer伺服器使用的是普通的虛擬機器，儘量真實的模仿一般應用的虛擬機器配置。

測試結論

從上面的測試結果可知：

1. 隨著訊息體的不斷增大，傳送訊息的TPS不斷降低，一般我們的訊息大小為1KB，在有兩個傳送者客戶端時，EQueue的傳送訊息TPS大概為31000。我覺得效能上應該滿足大部分需求場景了。如果一個系統平均每秒產生31200個訊息，一天是86400秒。那一天的訊息量是27億。這個數字已經很大了，呵呵。相信國內大部分網站都沒有這麼大的規模。當然我們不能這麼簡單的來算，實際的系統肯定有高峰期的，實際大家要根據自己的系統的高峰期傳送訊息的TPS來衡量具體要部署多少臺EQueue Broker伺服器。線上環境使用時，我們不能把Broker壓滿的，要給其有足夠的處理餘量，比如高峰期傳送TPS為10W，每臺Broker最大能承受3W，那我們至少要分配6臺機器，確保應付可能出現的高峰。這樣才能應付特別高的高峰。
2. 大家可以看到上面的資料中，開兩個生產者，兩個消費者，訊息大小為2KB時，Broker的進出總網路流量為99MB，這個資料還沒有到達千兆網絡卡的總流量（125MB）。目前，我只申請了5臺機器，4個客戶端機器。但實際我們的應用的叢集，客戶端機器應該會更多，我不知道當客戶端機器增加時，能否把Broker的網絡卡壓滿，如果壓不滿，則說明Broker本身的設計實現已經到達瓶頸了，也就是說EQueue Broker本身設計上可能還有效能優化的空間。
3. 在上面的效能資料情況下，所有伺服器的CPU，記憶體使用穩定，符合預期。在穩定性方面，我在個人筆記本上同時傳送和消費訊息，連續執行1天沒有問題；也有其他網友幫忙測試了穩定性，執行幾天也沒有問題。各項指標均正常。所以我認為目前EQueue的穩定性應該問題不大了。
4. Broker的訊息持久化，採用的是順序寫檔案的方式；目前的測試結果來看，完全還沒達到寫檔案的瓶頸；如果我們單獨測試寫檔案模組的效能，可以輕鬆達到300MB每秒，而我們的千兆網絡卡最大流量也只有125MB。所以，訊息持久化不會再成為很大的瓶頸了，但寫檔案的響應時間本身也會影響Broker對外的TPS，目前的響應時間為60ms，我感覺是比較慢的，不知道是否是虛擬機器的原因，不知道物理機上會如何。我覺得SSD硬碟，寫入檔案的響應時間不會這麼慢的。
5. 最後一點，當Broker的客戶端增加時，Broker的CPU的使用也會相應增加一點。這個可以理解，因為TCP長連線的數量多了一倍。而生產者和消費者伺服器的CPU記憶體的使用都非常穩定，符合預期。