33 對小規(guī)模RocketMQ集群進行壓測，同時為生產(chǎn)集群進行規(guī)劃
對小規(guī)模RocketMQ集群進行壓測，同時為生產(chǎn)集群進行規(guī)劃
1、壓測就是拼命往死了壓嗎？
上次聽明哥講了一套完整的生產(chǎn)級中間件參數(shù)調(diào)整的方案，包含了OS內(nèi)核參數(shù)調(diào)整，JVM參數(shù)調(diào)整以及中間件核心參數(shù)調(diào)整
小猛在消化理解之后，很快就在已經(jīng)部署好的一個小規(guī)模的RocketMQ集群上對上述幾塊參數(shù)都根據(jù)明哥的建議進行了調(diào)節(jié)，完事兒之后小猛再一次盯著自己的RocketMQ部署圖進入了思考。
? ? ? ? ? ?
? ? ? ? ? ??
所謂的壓測到底是如何壓測？難道就是簡單的啟動幾臺機器上的生產(chǎn)者和消費者，然后每臺機器都開啟大量線程模擬并發(fā)寫入RocketMQ以及并發(fā)從RocketMQ上讀取消息嗎？
難道就是不停的增加壓測用的生產(chǎn)者和消費者的機器，同時不停的增加他們的線程，然后去看RocketMQ集群的極限在哪里嗎？
不，小猛覺得壓測這個事情并沒有那么簡單。于是他再一次去請教了明哥，在壓測的時候到底要關(guān)注哪些指標？采用什么樣的壓測方式才是正確的的？
明哥聽完小猛的疑問之后，再一次耐心的給小猛做出了詳細的解釋。
其實如果對一個小規(guī)模的RocketMQ集群進行瘋狂的壓測，最后壓測出來一個最大的極限TPS值，那只是壓測中我們想要的一個結(jié)果而已，并不是實際中的最理想結(jié)果。
什么意思呢？
假設(shè)我們現(xiàn)在對部署好的RocketMQ集群拼命進行壓測，不停的增加生產(chǎn)者和消費者的機器以及線程數(shù)量，不停的增加RocketMQ集群的并發(fā)寫入量和并發(fā)消費量，發(fā)現(xiàn)RocketMQ集群似乎可以抗下每秒10萬+的消息量
那么你覺得在生產(chǎn)環(huán)境上，我們可以放心的讓RocketMQ集群來抗這么高的TPS嗎？
顯然不是，因為我們在壓測的時候一方面要關(guān)注RocketMQ能抗下多少TPS，一方面還要關(guān)注RocketMQ部署的幾臺機器的資源使用率和負載情況。
比如RocketMQ集群在抗下10萬TPS（可以理解為每秒處理10萬條消息）的同時，結(jié)果機器的CPU負載達到100%，內(nèi)存幾乎消耗殆盡，IO負載極高，網(wǎng)卡流量打滿甚至快要打爆，此時你覺得這個10萬TPS的成本是不是太高了？
因為眼看著你抗下了超高的TPS，結(jié)果自己機器資源消耗殆盡，幾乎機器都快掛了，那么你在真正的生產(chǎn)環(huán)境能放心的允許RocketMQ集群抗到10萬TPS嗎？
顯然是不行的，因為在機器快掛掉的情況下讓中間件抗超高的負載是絕對不行的。
所以這種壓測方法，僅僅能壓測出來一個極限值而已。實際上我們平時做壓測，主要關(guān)注的還是要壓測出來一個最合適的最高負載。
什么叫最合適的最高負載呢？
意思就是在RocketMQ的TPS和機器的資源使用率和負載之間取得一個平衡。
比如RocketMQ集群在機器資源使用率極高的極端情況下可以扛到10萬TPS，但是當他僅僅抗下8萬TPS的時候，你會發(fā)現(xiàn)cpu負載、內(nèi)存使用率、IO負載和網(wǎng)卡流量，都負載較高，但是可以接受，機器比較安全，不至于宕機。
那么這個8萬TPS實際上就是最合適的一個最高負載，也就是說，哪怕生產(chǎn)環(huán)境中極端情況下，RocketMQ的TPS飆升到8萬TPS，你知道機器資源也是大致可以抗下來的，不至于出現(xiàn)機器宕機的情況。
所以我們做壓測，其實最主要的是綜合TPS以及機器負載，盡量找到一個最高的TPS同時機器的各項負載在可承受范圍之內(nèi)，這才是壓測的目的。
2、一次RocketMQ小規(guī)模集群的壓測
（備注：以下壓測過程以及壓測結(jié)果，都是根據(jù)我們之前真實的RocketMQ壓測報告總結(jié)而來，非常的有代表性，大家完全可以結(jié)合我們之前說的機器配置來參考一下）
（1）RocketMQ的TPS和消息延時
我們讓兩個Producer不停的往RocketMQ集群發(fā)送消息，每個Producer所在機器啟動了80個線程，相當于每臺機器有80個線程并發(fā)的往RocketMQ集群寫入消息。
而RocketMQ集群是1主2從組成的一個dledger模式的高可用集群，只有一個Master Broker會接收消息的寫入。
然后有2個Cosumer不停的從RocketMQ集群消費數(shù)據(jù)。
每條數(shù)據(jù)的大小是500個字節(jié)，這個非常關(guān)鍵，大家一定要牢記這個數(shù)字，因為這個數(shù)字是跟后續(xù)的網(wǎng)卡流量有關(guān)的。
我們發(fā)現(xiàn)，一條消息從Producer生產(chǎn)出來到經(jīng)過RocketMQ的Broker存儲下來，再到被Consumer消費，基本上這個時間跨度不會超過1秒鐘，這些這個性能是正常而且可以接受的。
同時在RocketMQ的管理工作臺中可以看到，Master Broker的TPS（也就是每秒處理消息的數(shù)量），可以穩(wěn)定的達到7萬左右，也就是每秒可以穩(wěn)定處理7萬消息。
（2）cpu負載情況
其次我們檢查了一下Broker機器上的CPU負載，可以通過top、uptime等命令來查看
比如執(zhí)行top命令就可以看到cpu load和cpu使用率，這就代表了cpu的負載情況。
在你執(zhí)行了top命令之后，往往可以看到如下一行信息：
load average：12.03，12.05，12.08
類似上面那行信息代表的是cpu在1分鐘、5分鐘和15分鐘內(nèi)的cpu負載情況
比如我們一臺機器是24核的，那么上面的12意思就是有12個核在使用中。換言之就是還有12個核其實還沒使用，cpu還是有很大余力的。
這個cpu負載其實是比較好的，因為并沒有讓cpu負載達到極限。
（3）內(nèi)存使用率
使用free命令就可以查看到內(nèi)存的使用率，根據(jù)當時的測試結(jié)果，機器上48G的內(nèi)存，僅僅使用了一部分，還剩下很大一部分內(nèi)存都是空閑可用的，或者是被RocketMQ用來進行磁盤數(shù)據(jù)緩存了。
所以內(nèi)存負載是很低的。
（4）JVM GC頻率
使用jstat命令就可以查看RocketMQ的JVM的GC頻率，基本上新生代每隔幾十秒會垃圾回收一次，每次回收過后存活的對象很少，幾乎不進入老年代
因此測試過程中，F(xiàn)ull GC幾乎一次都沒有。（友情提示，如果不了解jstat命令如何分析JVM GC的，還是建議看一下《從0開始帶你成為JVM實戰(zhàn)高手》專欄）
（5）磁盤IO負載
接著可以檢查一下磁盤IO的負載情況。
首先可以用top命令查看一下IO等待占用CPU時間的百分比，你執(zhí)行top命令之后，會看到一行類似下面的東西：
Cpu(s):? 0.3% us,? 0.3% sy,? 0.0% ni, 76.7% id, 13.2% wa,? 0.0% hi,? 0.0% si。
在這里的13.2% wa，說的就是磁盤IO等待在CPU執(zhí)行時間中的百分比
如果這個比例太高，說明CPU執(zhí)行的時候大部分時間都在等待執(zhí)行IO，也就說明IO負載很高，導致大量的IO等待。
這個當時我們壓測的時候，是在40%左右，說明IO等待時間占用CPU執(zhí)行時間的比例在40%左右，這是相對高一些，但還是可以接受的，只不過如果繼續(xù)讓這個比例提高上去，就很不靠譜了，因為說明磁盤IO負載可能過高了。
（6）網(wǎng)卡流量
使用如下命令可以查看服務(wù)器的網(wǎng)卡流量：
sar -n DEV 1 2
通過這個命令就可以看到每秒鐘網(wǎng)卡讀寫數(shù)據(jù)量了。當時我們的服務(wù)器使用的是千兆網(wǎng)卡，千兆網(wǎng)卡的理論上限是每秒傳輸128M數(shù)據(jù)，但是一般實際最大值是每秒傳輸100M數(shù)據(jù)。
因此當時我們發(fā)現(xiàn)的一個問題就是，在RocketMQ處理到每秒7萬消息的時候，每條消息500字節(jié)左右的大小的情況下，每秒網(wǎng)卡傳輸數(shù)據(jù)量已經(jīng)達到100M了，就是已經(jīng)達到了網(wǎng)卡的一個極限值了。
因為一個Master Broker服務(wù)器，每秒不光是通過網(wǎng)絡(luò)接收你寫入的數(shù)據(jù)，還要把數(shù)據(jù)同步給兩個Slave Broker，還有別的一些網(wǎng)絡(luò)通信開銷。
因此實際壓測發(fā)現(xiàn)，每條消息500字節(jié)，每秒7萬消息的時候，服務(wù)器的網(wǎng)卡就幾乎打滿了，無法承載更多的消息了。
（7）針對壓測的一點小總結(jié)
最后針對本次壓測做一點小的總結(jié)，實際上經(jīng)過壓測，最終發(fā)現(xiàn)我們的服務(wù)器的性能瓶頸在網(wǎng)卡上，因為網(wǎng)卡每秒能傳輸?shù)臄?shù)據(jù)是有限的
因此當我們使用平均大小為500字節(jié)的消息時，最多就是做到RocketMQ單臺服務(wù)器每秒7萬的TPS，而且這個時候cpu負載、內(nèi)存負載、jvm gc負載、磁盤io負載，基本都還在正常范圍內(nèi)。
只不過這個時候網(wǎng)卡流量基本已經(jīng)打滿了，無法再提升TPS了。
因此在這樣的一個機器配置下，RocketMQ一個比較靠譜的TPS就是7萬左右。
3、基于公司業(yè)務(wù)情況規(guī)劃生產(chǎn)集群
在經(jīng)過了一輪完善的壓測之后，小猛提交了一份壓測報告給明哥，里面寫清楚了壓測的過程，在壓測時候的機器各項指標的表現(xiàn)。接著小猛同時對生產(chǎn)集群的部署做了一些簡單的規(guī)劃。
這個RocketMQ集群實際上未來不光是服務(wù)于訂單團隊，還要服務(wù)于全公司，只不過現(xiàn)在因為公司規(guī)模很小，暫時先由訂單團隊來負責集群部署而已，所以在做集群規(guī)劃的時候還是要考慮到全公司的情況。
就全公司的情況而言，實際上現(xiàn)在還處于創(chuàng)業(yè)成長期，即使在搞雙11活動高峰的時候，公司后臺系統(tǒng)的并發(fā)訪問量也就是每秒上萬，即使你多考慮一些，每秒幾萬的并發(fā)量也就最多了。
因此在部署的時候，小猛建議是對NameServer采用3臺機器部署就足夠了，而對于Broker而言采用6臺機器來部署，2個Master Broker和4個Slave Broker，這樣2個Master Broker每秒最多可以處理十幾萬消息，4個Slave Broker同時也能每秒提供高吞吐的數(shù)據(jù)消費，而且全面保證高可用性。
這樣的一個生產(chǎn)部署架構(gòu)，絕對是可以滿足公司現(xiàn)在的消息吞吐量的
因此，實際上最終的部署方案還是如下圖所示。
? ? ? ? ? ?
? ? ? ? ? ?
4、今日內(nèi)容總結(jié)
現(xiàn)在我們來總結(jié)一下今天學習到的內(nèi)容：
到底應(yīng)該如何壓測：應(yīng)該在TPS和機器的cpu負載、內(nèi)存使用率、jvm gc頻率、磁盤io負載、網(wǎng)絡(luò)流量負載之間取得一個平衡，盡量讓TPS盡可能的提高，同時讓機器的各項資源負載不要太高。
實際壓測過程：采用幾臺機器開啟大量線程并發(fā)讀寫消息，然后觀察TPS、cpu load（使用top命令）、內(nèi)存使用率（使用free命令）、jvm gc頻率（使用jstat命令）、磁盤io負載（使用top命令）、網(wǎng)卡流量負載（使用sar命令），不斷增加機器和線程，讓TPS不斷提升上去，同時觀察各項資源負載是否過高。
生產(chǎn)集群規(guī)劃：根據(jù)公司的后臺整體QPS來定，稍微多冗余部署一些機器即可，實際部署生產(chǎn)環(huán)境的集群時，使用高配置物理機，同時合理調(diào)整os內(nèi)核參數(shù)、jvm參數(shù)、中間件核心參數(shù)，如此即可
繼《從零開始帶你成為JVM實戰(zhàn)高手》后重磅推薦：
《從零開始帶你成為MySQL實戰(zhàn)優(yōu)化高手》
End
專欄版權(quán)歸公眾號儒猿技術(shù)窩所有
未經(jīng)許可不得傳播，如有侵權(quán)將追究法律責任
