生產經驗：互聯(lián)網(wǎng)公司的生產環(huán)境數(shù)據(jù)庫是如何進行性能測試的？

1、申請了機器之后，你作為Java架構師就要心里有數(shù)

上一篇文章我們講到了在真實的項目中，第一件事情就是申請數(shù)據(jù)庫機器，一般來說我們需要申請8核16G或者16核32G的高配置機器下來，甚至要機器全部搭配SSD固態(tài)硬盤，然后讓DBA兄弟在申請下來的機器上安裝和部署一個MySQL，同時啟動MySQL數(shù)據(jù)庫。

當然如何安裝和部署MySQL，以及如何啟動MySQL，都是非常簡單的，大家網(wǎng)絡上隨便一搜索就會看到大量類似的東西，那不是我們專欄要講的東西。然后MySQL在生產環(huán)境下的各種紛繁復雜的高級參數(shù)的調整，暫時我們還不會立馬涉及到，那些是屬于MySQL DBA需要搞定的事情。

但是我們后續(xù)隨著專欄的推進，會講解一部分MySQL生產環(huán)境中的高階參數(shù)的調優(yōu)和配置，有一些是跟我們開發(fā)Java應用系統(tǒng)密切相關的東西，我們作為開發(fā)人員，也是需要了解MySQL一些高階參數(shù)的調優(yōu)的，有時候在我們優(yōu)化系統(tǒng)性能的時候，可能就需要跟DBA一起配合進行調優(yōu)。

但是簡單來說，我們作為一個項目的核心Java工程師甚至Java架構師，必須要選擇自己的數(shù)據(jù)庫使用什么配置的機器，心里大致明白這個配置的機器部署的數(shù)據(jù)庫，大致能幫我們抗下每秒多少并發(fā)請求。

比如你申請的是8核16G的機器來部署MySQL，那你作為項目的Java架構師，心里大致就該知道你這個數(shù)據(jù)庫后續(xù)每秒抗個一兩千請求還是可以的，如果你申請的是16核32G的機器，那你心里就知道妥妥可以抗個每秒兩三千，甚至三四千的請求，你心里就有數(shù)了，這是你要做到的

2、把機器交給專業(yè)的DBA，讓他部署MySQL

其次你要知道的是，你申請一臺機器下來之后，接著這臺機器在有一定規(guī)模的公司里，一定是交給公司專業(yè)的DBA去安裝、部署和啟動MySQL的，DBA這個時候會按照他過往的經驗，用自己的MySQL生產調優(yōu)參數(shù)模板，直接放到MySQL里去，然后用一個參數(shù)模板去啟動這個MySQL，往往這里很多參數(shù)都是調優(yōu)過的。

而且DBA還可能會對linux機器的一些OS內核參數(shù)進行一定的調整，比如說最大文件句柄之類的參數(shù)，這些參數(shù)往往也都是需要調整的。

接著當DBA搞定這臺機器上的數(shù)據(jù)庫之后，就會交給你來使用，你就知道這臺機器的地址和用戶名密碼，然后你的Java系統(tǒng)就可以直接連接上去，就可以執(zhí)行各種各樣的SQL語句去實現(xiàn)業(yè)務邏輯了。

3、有了數(shù)據(jù)庫之后，還需要先進行壓測

當你手頭有一個可以使用的數(shù)據(jù)庫之后，你覺得就可以直接基于他開發(fā)Java系統(tǒng)了嗎？

并不是這樣的！這么做在一個互聯(lián)網(wǎng)公司里往往會顯得比較的業(yè)余，因為你首先得先對這個數(shù)據(jù)庫進行一個較為基本的基準壓測。

也就是說，你得基于一些工具模擬一個系統(tǒng)每秒發(fā)出1000個請求到數(shù)據(jù)庫上去，觀察一下他的CPU負載、磁盤IO負載、網(wǎng)絡IO負載、內存負載，然后數(shù)據(jù)庫能否每秒處理掉這1000個請求，還是每秒只能處理500個請求？這個過程，就是壓測。

你不光用工具每秒發(fā)送1000個請求，還可以模擬每秒發(fā)送2000個請求，甚至3000個請求，逐步的測試出來，這個數(shù)據(jù)庫在目前的機器配置之下，他大致的一個負載壓力如何，性能表現(xiàn)如何，每秒最多可以抗多少請求。

可能有的人會提出疑問了，他會說：老師，為什么剛開始就要對數(shù)據(jù)庫搞一個基準壓測？你完全可以等Java系統(tǒng)都開發(fā)完畢了，然后直接讓Java系統(tǒng)連接上MySQL數(shù)據(jù)庫，然后直接對Java系統(tǒng)進行壓測啊！

如果有人提出這個問題，那就有所不知了，數(shù)據(jù)庫的壓測和他上面的Java系統(tǒng)的壓測，其實是兩回事兒，首先你得知道你的數(shù)據(jù)庫最大能抗多大壓力，然后你再去看你的Java系統(tǒng)能抗多大壓力。

因為有一種可能是，你的數(shù)據(jù)庫每秒可以抗下2000個請求，但是你的Java系統(tǒng)每秒只能抗下500個請求，這也是有可能的。所以你不能光是針對Java系統(tǒng)去進行壓測，在那之前也得先對數(shù)據(jù)庫進行壓測，心里得有個數(shù)。

4、傻傻分不清楚：QPS和TPS到底有什么區(qū)別？

既然要壓測了，那么肯定得先明白一點，我們壓測數(shù)據(jù)庫，最終是想看看這個數(shù)據(jù)庫在現(xiàn)有的機器配置之下，每秒可以抗下多少個請求呢？這個每秒抗下多少個請求，其實是有專業(yè)術語的，分別是QPS和TPS。

就QPS而言，他的英文全稱是：Query Per Second。

其實就是英文字面意思已經很明確了，QPS就是說，你的這個數(shù)據(jù)庫每秒可以處理多少個請求，你大致可以理解為，一次請求就是一條SQL語句，也就是說這個數(shù)據(jù)庫每秒可以處理多少個SQL語句。

對于QPS而言，其實你的一些Java系統(tǒng)或者中間件系統(tǒng)在進行壓測的時候，也可以使用這個指標，也就是說，你的Java系統(tǒng)每秒可以處理多少個請求。

然后另外一個術語是TPS，他的英文全稱是：Transaction Per Second。其實就是每秒可處理的事務量，這個TPS往往是用在數(shù)據(jù)庫中較多一些，其實從字面意思就能看的出來，他就是說數(shù)據(jù)庫每秒會處理多少次事務提交或者回滾。

因為大家應該都對數(shù)據(jù)庫有一個基本的了解，就是他的事務到底是什么？

簡單來說，一個事務就會包含多個SQL語句，這些SQL最好要么就是事務提交，大家一起成功了，要么就是最好事務回滾，大家一起失敗了，這就是事務。

所以TPS往往指的是一個數(shù)據(jù)庫每秒里有多少個事務執(zhí)行完畢了，事務提交或者回滾都算是事務執(zhí)行完畢了，所以TPS衡量的是一個數(shù)據(jù)庫每秒處理完的事務的數(shù)量。有一些人往往會把TPS理解為是數(shù)據(jù)庫每秒鐘處理請求的數(shù)量，其實這是不太嚴謹?shù)摹?/p>

5、IO相關的壓測性能指標

接著再給大家講幾個壓測的時候要關注的IO相關的性能指標，大家也要對他做一個了解：

（1）IOPS：這個指的是機器的隨機IO并發(fā)處理的能力，比如機器可以達到200 IOPS，意思就是說每秒可以執(zhí)行200個隨機IO讀寫請求。

這個指標是很關鍵的，因為之前我們在數(shù)據(jù)庫架構原理中講解過，你在內存中更新的臟數(shù)據(jù)庫，最后都會由后臺IO線程在不確定的時間，刷回到磁盤里去，這就是隨機IO的過程。如果說IOPS指標太低了，那么會導致你內存里的臟數(shù)據(jù)刷回磁盤的效率就會不高。

（2）吞吐量：這個指的是機器的磁盤存儲每秒可以讀寫多少字節(jié)的數(shù)據(jù)量

這個指標也是很關鍵的，因為大家通過之前的學習都知道，我們平時在執(zhí)行各種SQL語句的時候，提交事務的時候，其實都是大量的會寫redo log之類的日志的，這些日志都會直接寫磁盤文件。

所以一臺機器他的存儲每秒可以讀寫多少字節(jié)的數(shù)據(jù)量，就決定了他每秒可以把多少redo log之類的日志寫入到磁盤里去。一般來說我們寫redo log之類的日志，都是對磁盤文件進行順序寫入的，也就是一行接著一行的寫，不會說進行隨機的讀寫，那么一般普通磁盤的順序寫入的吞吐量每秒都可以達到200MB左右。

所以通常而言，機器的磁盤吞吐量都是足夠承載高并發(fā)請求的。

（3）latency：這個指標說的是往磁盤里寫入一條數(shù)據(jù)的延遲。

這個指標同樣很重要，因為我們執(zhí)行SQL語句和提交事務的時候，都需要順序寫redo log磁盤文件，所以此時你寫一條日志到磁盤文件里去，到底是延遲1ms，還是延遲100us，這就對你的數(shù)據(jù)庫的SQL語句執(zhí)行性能是有影響的。

一般來說，當然是你的磁盤讀寫延遲越低，那么你的數(shù)據(jù)庫性能就越高，你執(zhí)行每個SQL語句和事務的時候速度就會越快。

6、壓測的時候要關注的其他性能指標

除了上面說的QPS、TPS、IOPS、吞吐量、latency這些指標之外，在壓測的時候還需要關注機器的其他一些性能指標。

（1）CPU負載：CPU負載是一個很重要的性能指標，因為假設你數(shù)據(jù)庫壓測到了每秒處理3000請求了，可能其他的性能指標都還正常，但是此時CPU負載特別高，那么也說明你的數(shù)據(jù)庫不能繼續(xù)往下壓測更高的QPS了，否則CPU是吃不消的。

（2）網(wǎng)絡負載：這個主要是要看看你的機器帶寬情況下，在壓測到一定的QPS和TPS的時候，每秒鐘機器的網(wǎng)卡會輸入多少MB數(shù)據(jù)，會輸出多少MB數(shù)據(jù)，因為有可能你的網(wǎng)絡帶寬最多每秒傳輸100MB的數(shù)據(jù)，那么可能你的QPS到1000的時候，網(wǎng)卡就打滿了，已經每秒傳輸100MB的數(shù)據(jù)了，此時即使其他指標都還算正常，但是你也不能繼續(xù)壓測下去了

（3）內存負載：這個就是看看在壓測到一定情況下的時候，你的機器內存耗費了多少，如果說機器內存耗費過高了，說明也不能繼續(xù)壓測下去了

7、后續(xù)的壓測實戰(zhàn)說明

接下來下一篇文章，我就會在我自己的電腦上安裝一個MySQL數(shù)據(jù)庫，然后交給大家如何使用方便的壓測工具，對數(shù)據(jù)庫進行一定的壓測，壓測的同時，應該通過哪些便捷的工具，去觀察壓測過程中的機器表現(xiàn)和各項指標。

8、今日思考題

今天想請每個人思考一下QPS和TPS兩個術語，想請大家說說自己在看今天的文章之前，自己對QPS和TPS是怎么理解的，在你們公司里是否有相關的系統(tǒng)和數(shù)據(jù)庫的QPS/TPS的統(tǒng)計？今天看完這篇文章之后，你對QPS和TPS兩個術語的理解是否有所變化呢？

另外，我再給大家出另外一個思考題，假設現(xiàn)在你負責一個交易系統(tǒng)，對于這個交易系統(tǒng)，他拆分為了很多服務，一筆交易的完成需要多個服務協(xié)作完成，也就是說一次交易請求需要調用多個服務才能完成。

那么你覺得對于每個服務而言，他每秒處理的請求數(shù)量是QPS還是TPS呢？對于整個交易系統(tǒng)而言，他每秒鐘處理的交易筆數(shù)是QPS還是TPS呢？請大家談談你的看法。

請大家在評論區(qū)寫下自己的心得體會，同時多看看其他人在評論區(qū)發(fā)表的留言，多多交流。

End

專欄版權歸公眾號儒猿技術窩所有

未經許可不得傳播，如有侵權將追究法律責任