MySQL中間件性能測試 I

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

MySQL中間件性能測試 I

摘要：我今天代表我的團隊向大家來介紹一下MySQL中間件性能的測試，爲大家帶來一些不太一樣的故事，包括我們在做性能測試的時候一些不太一樣的視角。

分享大綱：

1.性能測試的常見的(錯誤)方法 * 3

2.性能測試的一些(我們用的)方法 * 2

3.分佈式事務相關 * 1

我今天代表我的團隊向大家來介紹一下MySQL中間件性能的測試，之所以講選這個主題是因爲我注意到大家都是高級的DBA，我們也有很多的高級的DBA，跟大家聊天的時候都會注意到，大家對於性能測試的第一印象：

性能 = sysbench

測試 = run

結果 = tps

數值要高大上

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

 

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

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

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

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

 

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

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

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

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

• 性能測試報告的結論 是要得到絕對數值 ?

 

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

 

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

在這個壓力流向圖中，紅色的箭頭是大家做性能測試時的觀察點，可以看到: 我們在觀察這個壓力時, 觀察的不是中間件的壓力, 而是後面多個系統產生的一個綜合的壓力，在這種觀測視角下我們很難評估一箇中間件到底是好還是不好。

 

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

 

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

如圖所示，這個中間件是一個簡單的流量轉發類的中間件，後端只有一臺數據庫, 壓力類型是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庫上。

 

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

 

l  中間件的上下文轉移

· 事務級別 (同一事務一定發到同一節點)

· 會話級別 (上下文遷移)

 - 系統變量

 - Prepare Statement

 - 臨時表

 - 用戶變量

 - 與會話相關的特殊函數
 - LAST_INSERT_ID/ROW_COUNT

 - Default schema

 

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

 

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

 

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

 

所以我們再次修正我們中間件的觀察對象，中間件的觀察對象是除了中間件，還有連接屬性，還有必須要觀察實際下發的SQL。

 

l  同一環境下, 中間件損耗越小是否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；

 

l  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的實用腳本集，它能觀測操作系統的方方面面，來幫助大家做壓力觀測。

 

l  中間件自身提供觀測

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

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

- 開始梳理

- 完成解析

- 完成路由分配

- 從數據庫回收結果

- 後置處理

- 反饋處理

 

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

 

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

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

 

中間件本身的觀測與操作系統的區別在於: 中間件提供的視角是站在壓力處理的視角來提供的，操作系統視角是站在資源的視角來提供，這兩個視角缺一不可。如果只知道操作系統說IO壓力大，但是並不知道是哪個環節造成的壓力大，那診斷瓶頸的成本會比較高. 這就是爲什麼中間件要補充一個視角。

 

l  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數據的異常，因爲大家做數據庫都會妥協，說這個數據庫比那個數據庫性能好一定是做了什麼妥協的，這些技術一定是關係到這些數據異常。

 

l  ACID相關的數據異常

 

數據庫異常的分類：

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

 

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

 

l  針對鎖機制的弱點: 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/slides