MySQL中間件性能測試 I

本文根據黃炎在2018年7月7日【MySQL技術沙龍 · 成都站】現場演講內容整理而成。

黃炎
愛可生研發總監，深刻鑽研分佈式數據庫相關技術，擅長業界相關MySQL中間件產品和開發，以及分佈式中間件在企業內部的應用實踐。

MySQL中間件性能測試 I

摘要：我今天表明個人團隊向你們來介紹一下MySQL中間件性能的測試，爲你們帶來一些不太同樣的故事，包括咱們在作性能測試的時候一些不太同樣的視角。

分享大綱：

1.性能測試的常見的(錯誤)方法 * 3
2.性能測試的一些(咱們用的)方法 * 2
3.分佈式事務相關 * 1

我今天表明個人團隊向你們來介紹一下MySQL中間件性能的測試，之因此講選這個主題是由於我注意到你們都是高級的DBA，咱們也有不少的高級的DBA，跟你們聊天的時候都會注意到，你們對於性能測試的第一印象：

性能 = sysbench
測試 = run
結果 = tps
數值要高大上

性能就是sysbench，而後測試就是跑一下，這就叫性能測試了，結果就是要TPS或者QPS，數值必定要高大上，這是你們對性能測試測試的第一印象也多是惟一的印象。咱們公司是屬於乙方的技術服務提供商，咱們對業界的不少產品進行過性能測試，因此今天想爲你們帶來一些不太同樣的故事，以及咱們在作性能測試的時候一些視角。

我今天大概會向你們介紹三件事情：

第一件事情是咱們觀察到，你們在作性能測試的時候，在針對數據庫的中間件作性能測試的時候會有一些常見的方法，咱們會介紹其中的三種方法和相關的場景以及可能產生的一些錯誤。

第二件事情是在性能測試中咱們在實際中使用了幾年的一些方法，這些方法可能跟你們日常見的不太同樣。

第三件事情是一個關於分佈式事務相關的章節。

一．性能測試的常見的(錯誤)方法

首先看咱們的常見方法，其中我想討論三件事情，

• 測試中間件性能的觀測對象是中間件 ?
• 性能測試指標選取: 吞吐 or 延遲 ?
• 性能測試報告的結論 是要獲得絕對數值 ?

1.測試中間件性能的觀測對象是中間件 ?

咱們先關注咱們的觀測對象是誰？咱們來看幾個故事. 這張圖是常見的一箇中間件的形態，中間件和數據庫是分別在兩個操做系統中，操做系統分爲用戶態和內核態，流量從中間件過來，壓力從網絡流向數據庫，而後數據庫自己的壓力會流向存儲，這是大概的壓力流向。

在這個壓力流向圖中，紅色的箭頭是你們作性能測試時的觀察點，能夠看到: 咱們在觀察這個壓力時, 觀察的不是中間件的壓力, 而是後面多個系統產生的一個綜合的壓力，在這種觀測視角下咱們很難評估一箇中間件究竟是好仍是很差。

| 測試中間件的觀察對象是中間件+鏈接屬性+?

這是一個真實的故事，有一天咱們的測試同事找到我，讓我解釋一下這個圖是怎麼來的？

如圖所示，這個中間件是一個簡單的流量轉發類的中間件，後端只有一臺數據庫, 壓力類型是Point-select，就是作簡單的命中主鍵的select，而且壓力是所有命中緩存的，能夠驗證數據庫沒有任何磁盤IO. 橫軸是併發，縱軸是QPS，藍色的這根線是中間件的性能線, 橙色的這根線是直連MySQL的性能線。

爲何經過中間件的性能會比經過MySQL的性能要高？

當時拿到這個結果的時候，我去驗證了全部的環境，我認爲環境沒有問題，壓力沒有問題，那麼這多是我這一輩子中離諾貝爾獎最近的一次，若是說這個現象成了，那麼就至關於我在這個網線造了一個黑洞出來，信息經過這根網線的速度比光速要快， 由於你們知道網線上跑的是電子, 電子的最高速度是光速，或者說我換用一根光纖, 它的最高速度也就是光速，咱們的數據庫SQL跑的速度要比光速快，才能作出剛纔的性能圖。

固然最後我是沒有拿到諾貝爾獎的，是由於鏈接MySQL 5.7時，直連數據庫和鏈接中間件的兩根鏈接的類型不一樣，其中一端是默認開啓的TLS的，直接用客戶端去連數據庫的時候默認會開啓TLS，而鏈接中間件時則不通，由於通常的中間件實現都會比較懶，它不會去作TLS, 因此這兩根鏈接的條件不對稱，直接致使了中間件的性能要比直連數據庫的性能要好。這是我想帶來的第一個場景。

這個場景就擴大了咱們的觀察對象，對中間件的性能測試，除了中間件之外還須要觀察它的鏈接屬性的不一樣。

咱們來看一下第二個故事。你們來考慮一下這個SQL：

prepare ps from ‘…’;
select * from a limit 1;
select * from b limit 1;

若是我將這三句話發往一箇中間件和發往一個數據庫到底有什麼區別？

中間件的狀況如圖所示，後面有兩個數據庫，將第一個prepare發往A庫，而後第二個select可能發往任意一個庫，咱們假設它發往A庫, 那一切正常，若是第三個select發往了B庫，那麼prepare會被帶到B庫上去作。在目前的語句下, 其實prepare是能夠不須要帶到B庫上的，由於它後面的select跟prepare沒有關係. 但若是我下面發一個Exec, prepare就必定要帶到B庫上。

這個場景中, 發到中間件的壓力和中間件實際下發到數據庫的壓力可能會變多，之因此變多, 是爲了中間件要維持一個特性，這個特性叫中間件的上下文轉移。你們若是用過開源的中間件，這個術語應該就比較熟悉。

| 中間件的上下文轉移

· 事務級別 (同一事務必定發到同一節點)
· 會話級別 (上下文遷移)

• 系統變量
• Prepare Statement
• 臨時表
• 用戶變量
• 與會話相關的特殊函數
• LAST_INSERT_ID/ROW_COUNT
• Default schema

事務級別的上下文轉移, 指的是對於簡單轉發類中間件, 同一個事務的SQL要發往同一個後端的數據庫。

除了事務級別, 常見的中間件還會作一些會話級別的上下遷移，好比系統變量，若是把binlog關掉，意味着以後的語句不計入binlog，那麼後面的語句無論發到哪臺數據庫必定要把這個系統變量帶到後面的數據庫裏邊去。而後好比說Default Schema，這個是常見的中間件須要實現的部分。

咱們來看後面，還有一些常見的中間件不必定會實現，好比會話級別的上下文遷移還包括prepare statement、臨時表、用戶變量以及特殊函數。特殊函數其實正常的狀況下人爲使用的並很少，可是你們使用的各個driver都會依賴於這些特殊函數來作，好比說分頁、篩選都會依賴於這些特殊函數來作，因此一個好的中間件會對於這些繪畫級別的，上下文轉移的行爲要麼支持，要麼有明確的文檔說明不支持，要麼加以限制，這個是中間件的上下文轉移帶來的在性能測試中的差異。

因此咱們再次修正咱們中間件的觀察對象，中間件的觀察對象是除了中間件，還有鏈接屬性，還有必需要觀察實際下發的SQL。

| 同一環境下, 中間件損耗越小是否QPS必定越高？

第三個故事，咱們來考慮一下，在同一個測試環境下，兩款中間件中損耗比較小的那款是否是獲得的QPS必定會更高？正常的狀況下咱們認爲一個系統裏邊若是某一個環節損耗小了，總體的損耗就小, 獲得的延遲更低，QPS必定會更高。

但實際上, 請你們考慮這樣一個場景，我列舉了左右兩款中間件，左邊是損耗比較高的中間件，右邊是損耗比較低的中間件，都用同一個壓力測試場景，打了一百個併發下去。

左邊的中間件由於它的損耗比較高， 至關於下發了20個併發，另外的80個併發在損耗的過程當中，右邊的中間件稍微好一點，它下發到數據庫的併發是60個併發，那麼數據庫在不一樣的併發下，由於有資源競爭, 單線程的QPS就會變。20併發下競爭會比較低，因此每個線程，它的QPS比較高，多是100 QPS。而60併發下, 每一個線程的QPS可能只有30，20個併發乘以100個QPS和30個併發乘以60個QPS，算下來:損耗比較高的中間件，有可能它的QPS會更高。

這是性能測試中的一個常見錯誤，若是隻是簡單的觀測，那麼我選擇的應該選那款比較慢的中間件。

這是個人第三個場景，日常咱們在實踐的時候會去計算中間件的一個指標，咱們把它叫作穿透率，一箇中間的穿透率是多少，這個意思是中間件往下發的壓力 比 發到中間件的壓力。

回到以前快慢中間件比較的場景，左邊中間件的穿透率是20%，右邊中間件的穿透率是60%。經過計算穿透率能夠評估一個轉發類中間件的性能。若是是分佈式類的中間件還不能這樣評估，由於穿透率越高，並不表明一個分佈式的中間件的處理性能更好，須要其它的指標來評估。

咱們在測試的時候，若是要比較兩個環境的性能，就必定須要注意: 先讓對數據庫的壓力錶現相同，其中就包括鏈接的屬性、SQL、平均延遲等，才能比較兩個中間件的性能的好壞。若是不知足這個條件，測出來的是整個系統的表現，而並非一箇中間件的性能表現。

因此中間件的最終的測試對象，咱們最終的結論：

測試中間件的觀察對象是
中間件+向數據庫的實際壓力

在這裏我能夠透露給你們一個小的故事，這個故事是真實發生過的，由於咱們是作乙方的，像大型的銀行金融機構提供解決方案，而後有一次個人項目經理就來找我，說咱們中間件測試跟友商的比QPS差了不少。我說你給用戶跪吧，以後咱們派了一個資深的工程師到現場去看，把兩套環境拿到一塊兒看，咱們發現友商的環境上，MySQL的binlog是關掉的。而後咱們就把那個項目經理從地上扶起來，向客戶去解釋其中的道理，咱們解釋的道理就是剛纔這個道理: 必定要觀察數據庫上的壓力錶現。

這是一個sysbench的性能報告，你們第一眼看這個報告, 關注的一般是這個位置，4000QPS，純讀的壓力。

除了這個部分之外還須要注意其餘兩個部分：

第一，Response time, 即響應時間，下面的幾個數值是最小值，平均值、最大值和95%分位數，這四個值能構造出一個延遲分佈的密度曲線大概的形狀。舉個例子，若是在如今這個狀況下，95%分位數接近最大值( 好比把圖中的138.01ms改爲438ms)，那麼說明這個測試中的異常值的出現機率超過5%，好比說，能觀測的性能點是12萬個點，在這12萬個點裏邊有超太高過5%的觀測點，是高過438毫秒的，那麼咱們認爲: 在這個壓力錶現下, 這個中間件的某一些鏈接的延遲頗有可能出現了異常. 響應時間指標的做用，是構造延遲的分佈曲線的大概形狀。

第二，Threads fairness，線程的公平性，舉例兩款中間件，有一款中間件咱們打4個併發下去，其中三根鏈接是不工做的，只有一根鏈接效率特別高，它能夠達到4000 QPS；另一款中間件每根鏈接效率沒有那麼高，可是每根鏈接均可以達到1000 QPS。若是你們去買的話，用一萬塊錢去買中間件，你們會買哪一款. 這就是線程的公平性的度量目的。線程的公平性的兩個數值: 前面是它的平均數，後面是它的標準差。這個標準差必定不能過高，若是過高的話就意味着它每根的線程處理的效率不同，通常意味着這個中間件中間哪一個環節錯了。

2.性能測試指標選取: 吞吐 or 延遲 ?

高壓力下, 高吞吐
低壓力下, 低延遲

舉例，若是有一款中間件在低併發的狀況下延遲很低吞吐還好，隨着它的併發愈來愈高，它的吞吐基本上是一個線性的增加，併發數增加十倍，吞吐量增加了九倍，這個系統已經看起來還不錯，可是延遲增加了20倍左右，這一款中間件你們在實際的業務上會不會選呢？

我諮詢過業務相關的同行，他們的答案是徹底不同的，有人會用，有的人不會用，徹底取決於它的業務類型。 若是是個低併發的業務，會認爲這個中間件夠用，若是說業務是一個高併發而且對延遲沒有過高的要求，150毫秒以內的延遲都能接受，那麼這款中間件它的吞吐量線性成長率實際上是很是不錯的。但若是是延遲敏感型的業務，它的延遲要求很高，好比說它最多隻能接受25毫秒的延遲, 那麼這款中間件就不該該選。

因此在進行性能測試時，到底選擇吞吐仍是選擇延遲是要跟着業務走的，業務必需要給出底線咱們才知道怎麼測，不然拿到例子中的數值，第一反映就是一百毫秒這個數很大，就不想用，但其實它的吞吐的線性成長率仍是比較好的。

通常的來講，開發在作一個系統的時候很容易低成本的作出高壓力下能承受高吞吐、低壓力下能作到低延遲的這樣一個系統，可是反過來不行。若是在高壓力下作低延遲，這個成本在開發上是異常的高，須要用盡各類極端的技術來作，若是在低壓力下作高吞吐，這個在現實中沒有意義，因此在成本受控的狀況下作出來的通常都是這樣的效果. 若是你們從事中間件的測試的話，那麼對中間件的期待的要求不要過高，貼合業務的性能表現是最合適的。

這是我想討論的第二件事情，性能指標的選取就是不一樣的壓力下必定要選取不一樣的指標而且必定要貼着業務走，業務必定要告訴你它的底線在哪裏。

3.性能測試報告的結論是獲得絕對數值 ?

假設你們在評估這樣一個數據庫，這個數據庫它的測試參數都列在屏幕上，測試使用sysbench工具，壓力類型是OLTP只讀方式，讀的類型是點選，一共八張表，每張表有一兆行的數據，使用Socket鏈接，64併發，測試環境是72核超線程. 在這種狀況下這臺數據庫能作到QPS是40萬以上，你們以爲這款數據庫怎麼樣？

若是你手裏有錢，會不會去買這樣一款數據庫來支撐你的線上業務，這款數據庫是誰？這款數據是MySQL 5.5。

這張圖來自於MySQL 5.7的官方報告，其中這個點是MySQL 5.5，它能在64併發下作到40萬QPS，看到這個數據時我其實有點驚訝， MySQL 5.5是我剛工做的時候的數據庫版本，那款是你們公認的性能比較差的數據庫，可是它就能作到40萬QPS。

這張圖來自於MySQL的一份報告，我強烈推薦這個報告的緣由是，首先這個報告裏邊是有絕對的數值，同時，報告裏有對數值的比較，再同時它有對每一個場景進行壓力分析和瓶頸分析。若是你們必定須要一份帶絕對值的測試報告，我強烈推薦這份測試報告，由於它裏面帶了若干的分析，並且它裏邊有一句很是有意思的話：

Numbers are just reflecting what is behind。

這份報告有專門的一節來解釋爲何應該相信壓力分析和瓶頸分析，而不該該相信絕對數值。咱們回到剛纔這張圖，MySQL 5.7在這個壓力場景下能作到的是一百萬，若是在128併發，按照最高到256的併發這樣的場景下能作到1.6兆的QPS，但實際上咱們不多有人在線上能跑出這樣的值. 按照咱們團隊的多年測試的實踐經驗，作性能測試不要以找到值爲目的，而要以找到瓶頸爲目的，而且要把這個瓶頸解決掉。如此循環直到這個瓶頸沒法解決爲止。

實踐經驗:

以找到瓶頸爲目的, 直到瓶頸沒法解決
更容易找到 可重現的 正確的 性能值

好比說遇到操做系統的瓶頸，萬兆網卡已經不夠用了，吞吐已經上不去了，在成本內能買到的卡就是這個樣子，那這個瓶頸就沒有辦法再解決了。這樣咱們能獲得一個正確的而且能夠重現的性能值.

以上三點總結：

1.測試中間件的觀察對象是：
中間件+向數據庫的實際壓力

2.性能測試指標選取:
在不一樣併發下, 選擇不一樣指標

3.性能測試報告的結論應當是:
同等條件下的 性能比較 和 性能瓶頸分析

二．性能測試的一些(咱們用的)方法 * 2

下面介紹2種咱們用下來比較成熟的方法：

1.觀測, 觀測, 觀測
-eBPF/Systemtap
-中間件自身提供觀測
-USE
2.測試工具校準

關於觀測：

第一，推薦兩種觀測工具，eBPF或Systemtap；

第二，咱們本身也作中間件，咱們中間件自身是提供了一些觀測指標的，向你們介紹一下這種方法；

第三，有一種線程是對於資源消耗的觀察手段，即USE；

| eBPF 操做系統級的觀測

eBPF此處引用個人同事洪斌在今年的PHPCON的演講，他的演講主題是《MySQL性能診斷與實踐》，其中詳細的介紹了一下這個工具能給你們帶來什麼好處，列舉其中幾個，如：

1. 延遲分佈，好比MySQL請求的延遲，VFS延遲，Ext4的延遲，塊設備的延遲等；
2. MySQL的文件IO壓力分析；
3. 臨時表的生命周；
4. 短鏈接的分析；

詳細演講內容：github.com/actiontech/slides

舉一個例子，下圖是eBPF的一個腳本，可觀察MySQL的延遲，它會給你們列出延遲的分佈曲線:

左邊這一類是延遲，從零到一，二到三，四到七，它是指數級增加，單位是微秒，能夠看到的是 壓力打在數據庫上的平均延遲，大量的數據壓力在128微妙到255微妙之間，這個數據庫的總體延遲仍是不錯的。

這張材料引用自Breddan Gregg的項目BCC，是eBPF的實用腳本集，它能觀測操做系統的方方面面，來幫助你們作壓力觀測。

| 中間件自身提供觀測

操做系統的觀測已經很全了，爲何中間件自己也要提供一些觀測點，咱們本身的中間件DBLE，是一個開源項目，GitHub上能夠搜到，在DBLE中咱們提供了這樣的一種觀測方法，以下：

DBLE把一個壓力下來分紅了六個階段：

- 開始梳理
- 完成解析
- 完成路由分配
- 從數據庫回收結果
- 後置處理
- 反饋處理

每一個階段提供了時間分佈，這樣咱們可知道壓力到底在中間件的哪個階段變慢。

好比在這個數據下，中間件的性能其實不錯，是由於從第三個點到第四個點之間是後端數據庫的處理，它佔了整個處理時間的70%以上，因此在這種狀況下能夠判斷後端數據庫已經慢了，而不是中間件產生了什麼太大的問題，因此中間件自己應該提供觀測。

在這個項目的文檔中, 咱們把畫了中間件的壓力處理流程，其實對於大部分的中間件都是這樣的，這張圖在DBLE開源的文檔上均可以找到。安利一下咱們本身的中間件DBLE，你們有興趣的話能夠去看一下，文檔齊全，分析方法也很齊全。

中間件自己的觀測與操做系統的區別在於: 中間件提供的視角是站在壓力處理的視角來提供的，操做系統視角是站在資源的視角來提供，這兩個視角缺一不可。若是隻知道操做系統說IO壓力大，可是並不知道是哪一個環節形成的壓力大，那診斷瓶頸的成本會比較高. 這就是爲何中間件要補充一個視角。

| USE

對於資源來講，強烈推薦《性能之巔》這本書，它介紹的分析方法叫USE，就是使用率、飽和度、錯誤率這三個指標就足以評估一個資源，IO資源也好，網絡資源也好，足以評估一個資源如今的使用情況。

舉一個例子，爲何使用率和飽和度得分開，若是如今操做系統告訴咱們內存佔用率是100%，內存能不能再申請出來一塊？是能夠的，由於內存的使用率100%，其中好比說有50%是分給buffer和cache, 操做系統會自動回收，這種狀況下內存的使用率是100%，但飽和度並無達到飽和，咱們能夠繼續使用內存，直到它的飽和度上升到100%爲止，這個內存就再也申請不出來了。

因此這就是爲何這本書將使用率和飽和度必定要拆開的緣由。強烈推薦！

咱們在DBLE中間件內部也提供了相似這樣的觀察機制，有點像Linux的Load average. 咱們對於它的每個線程的使用都提供了一分鐘、五分鐘或者是十五分鐘這三種使用率的評估。經過使用率就能夠觀察到在併發壓力下中間件的運行情況究竟是死在了一根線程上，仍是每根線程上承載的壓力差很少。以前關於線程公平性的問題也能夠經過這個指標來診斷。

2.測試工具校準

測試工具校準，舉個例子，BenchmarkSQL，是Java版的TPCC，很多銀行都在用它檢驗一個數據庫或者是檢驗一箇中間件能不能正常表現，可是咱們碰到了這樣一個問題：在測試壓力中, 測試腳本要刪一個記錄，若是刪不掉我就一直的刪，一直刪，可是這個工具在RR的隔離級別下形成一個死循環。

這個死循環是這樣的：

第一句話它把auto commit設成0；

第二句select就會開啓一個事務；

第三句話在這個壓力下跑過一段邏輯以後再select看看這行數據還在不在，若是在就去刪掉它。若是隔離級別是RR的，在第二三句之間把這行數據刪掉，那麼此時還能看到這行數據對吧. 但以後的delete迴應沒有影響數據行，因此BenchmarkSQL就會陷入上面的這條死循環，看到數據, 刪除, 沒刪掉, 而後就一直會去刪，可是一直能看到這行數據，因此就會陷入這個死循環。

換句話說BenchmarkSQL，在RR的隔離級別下就會形成這樣一個死循環。 很難想象這個工具是在銀行客戶中被大量使用. 有一天項目經理告訴我，友商的中間件好着啊，而後咱們就必需要去研究這款中間件，爲何它沒有問題，緣由是設置了RR的隔離級別, 它實際下到數據庫的壓力是RC隔離級別，RC隔離級別錯在第三步看不到這條數據，它就不會跑下面這個循環，因此人家的中間件的錯誤將測試工具的錯誤抵消了。咱們呼籲在測試時保持科學的態度.

在開始演講以前姜老師的筆記本在這個環境下工做是好的，我說能不能換個人筆記本作這個演講，我就把線插入個人筆記本而後兩邊都顯示不出來了. 這個時候姜老師最應該說的一句話是什麼呢？在個人環境下它是好的啊，但他並無說，這是一個很科學的態度。

關於性能測試，咱們推薦兩個方法：

第一個方法，性能測試必定要去觀測，觀測的目的是什麼，看到瓶頸，看到瓶頸的目的是什麼？解決掉它以得到一個徹底能夠重複的正確的性能測試值來得到正確的結論。

第二個方法，測試工具必定要校準，業界經常使用的測試工具備不少，不要相信一些小衆的測試工具，每一種測試工具都必定要校準。校準的話能夠用多種測試工具同時去跑，去校準，或者是去分析測試工具的壓力類型，剛纔的觀測過程就足以分析一個測試工具實際下發到後端的壓力究竟是什麼，足以看到它的壓力類型是什麼，分析它的壓力模式是否是正確的，以作測試工具校準。

因此在咱們的公司ISO流程裏邊有一個規定是半年用這個測試工具作一次校準，由於測試工具也在面臨着升級，咱們面臨的測試工具不少，這是我想討論的第二個部分。

三．分佈式事務相關*1

分佈式事務相關，其實跟性能沒有什麼太大的關係，它來自於一個故事。咱們作數據庫的服務提供商，面試過不少人，你們都會在分佈式事務上企圖尋找亮點，而後咱們就常常問如何證實分佈式事務是有效的，好比說MySQL有XA，以前也有公司推出了快照隔離級別的分佈式事務中間件，如何測試分佈式事務中間件是有效的，咱們獲得最多的一句話就是你能夠隨便的拔電源一百次，而後那邊就說能夠拔兩百次，那邊又說能夠拔三百次，都是這樣的一個狀況。

1. 事務性

對於分佈式事務相關來講，無論是正確性也好仍是性能也好，首先是要去驗證ACID數據的異常，由於你們作數據庫都會妥協，說這個數據庫比那個數據庫性能好必定是作了什麼妥協的，這些技術必定是關係到這些數據異常。

| ACID相關的數據異常

數據庫異常的分類：

髒讀/不可重複讀/幻讀/髒寫/更新丟失/寫偏序/讀偏序/…

測試分佈式事務時, 至少應該知道這些數據異常的場景. 一個分佈式事務實現，若是脫離MySQL在中間件上作一個分佈式事務實現的話，必定是從頭開始作東西，就必定要從最原始的理論基礎來去證實每一個異常場景都能被正確處理。

| 針對鎖機制的弱點: S2PL/SS2PL

大量的分佈式事務實踐在使用鎖機制，那麼在鎖機制裏邊就兩種鎖一種是S級別的2PL和SS級別的2PL兩種，每一種實現都有它的弱點，建議針對這些弱點進行相關的正確性和性能測試。

2.可靠性和性能

• CPU
• 內存 (perf - NUMA)
• 磁盤 (systemtap - 延遲/錯誤)
• 網絡 (tc - 延遲/亂序/篡改/丟失)
• 進程 (kill / hang / 線程亂序執行)

…

關於破壞性測試，拔電源到底夠不夠？可靠性能的測試必定要從這幾個方面，必定先從資源的角度去考慮。

第一，內存， NUMA到底該不應關閉，把它打開對性能到底有什麼影響，均可以經過perf來觀察到，或者是經過perf來注入一些錯誤點讓它產生一些錯誤，內存或CPU均可以注入錯誤。

第二， 磁盤很早的時候淘寶的團隊就在用systemtap在IO上作延遲和錯誤的注入，好比模擬一個IO是失敗的，或者是模擬一個IO無限的等待下去，Pingcap也有相關的文章介紹，這也是咱們的平常使用的技術。

第三， 網絡，用TC能夠作出四種網絡故障，延遲，亂序，丟失，篡改. 網絡故障不單純是開啓iptables， tc能夠作出這四種，而且按機率來安排這四種故障。

第四，進程，關掉電源不少時候模擬的都是進程kill. 除了這個之外還有進程hang，以及不少人都會忽略掉的線程亂序執行。在某些機器中，程序的線程是按照某種順序執行的，可是換一個CPU或者換一個環境，或者是打個干擾壓力上去, 程序的線程就會亂序執行。

咱們看一個分佈式事務測試報告說測試對象是正確的，必定要考慮這些方面. 下面是咱們同事寫的一句話：

懷着敬畏之心
懷疑每一行代碼都會
-出錯
或者
-不返回結果

必定要懷着一個敬畏的心懷疑每一行代碼都會出錯或者是不返回，我寫這個slide的時候應該是三四周以前，後來第二週阿里就掛了，而後阿里的故障分析報告上也是一樣的一句話，就是你必定要懷着一個敬畏之心. 你們經過這麼多錢買下來的經驗都是這樣的，對於一個系統必定要懷着敬畏之心去看待它，不要沒事兒去拔電源， 我又不是賣電源的對吧！

以上是我今天的分享，謝謝你們！

PPT下載連接：
https://github.com/actiontech...