分散式系統測試那些事兒——錯誤注入
接上篇：
當然測試可能會讓你代碼變得沒有那麼漂亮，舉個例子：
那麼在設計 TiDB 的時候，我們當時是怎麼考慮 test 這個事情的？首先一個百萬級的 test 不可能由人肉來寫，也就是說你如果重新定義一個自己的所謂的 SQL 語法，或者一個 query language，那這個時候你需要構建百萬級的 test，即使全公司去寫，寫個兩年都不夠，所以這個事情顯然是不靠譜的。但是除非說我的 query language 特別簡單，比如像 MongoDB 早期的那種，那我一個「大於多少」的這種，或者 equal 這種條件查詢特別簡單的，那你確實是不需要構建這種百萬級的 test。但是如果做一個 SQL 的 database 的話，那是需要構建這種非常非常複雜的 test 的。這時候這個 test 又不能全公司的人寫個兩年，對吧？所以有什麼好辦法呢？MySQL 兼容的各種系統都是可以用來 test 的，所以我們當時兼容 MySQL 協議，那意味著我們能夠取得大量的 MySQL test。不知道有沒有人統計過 MySQL 有多少個 test，產品級的 test 很嚇人的，千萬級。然後還有很多 ORM， 支持 MySQL 的各種應用都有自己的測試。大家知道，每個語言都會 build 自己的 ORM，然後甚至是一個語言的 ORM 都有好幾個。比如說對於 MySQL 可能有排第一的、排第二的，那我們可以把這些全拿過來用來測試我們的系統。
但對於有些應用程序而言，這時候就比較坑了。就是一個應用程序你得把它 setup 起來，然後操作這個應用程序，比如 WordPress，而後再看那個結果。所以這時候我們為了避免剛才人肉去測試，我們做了一個程序來自動化的 Record---Replay。就是你在首次運行的時候，我們會記錄它所有執行的 SQL 語句，那下一次我再需要重新運行這個程序的時候怎麼辦？我不需要運行這個程序了，我不需要起來了，我只需要把它前面記錄的 SQL record 重新回放一遍，就相當於是我模擬了程序的整個行為。所以我們在這部分是這樣做的自動化。
那麼剛剛說了那麼多，實際上做的是什麼？實際上做的都是正確路徑的測試，那幾百萬個 test 也都是做的正確的路徑測試，但是錯誤的路徑怎麼辦？很典型的一個例子就是怎麼做 Fault injection。硬體比較簡單粗暴的模擬網路故障可以拔網線，比如說測網路的時候可以把這個網線拔掉，但是這個做法是極其低效的，而且它是沒法 scale 的，因為這個需要人的參與。
然後還有比如說 CPU，這個 CPU 的損壞概率其實也挺高的，特別是對於過保了的機器。然後還有磁碟，磁碟大概是三年百分之八點幾的損壞率，這是一篇論文裡面給出的數據。我記得 Google 好像之前給過一個數據，就是 CPU、網卡還有磁碟在多少年之內的損壞率大概是什麼樣的。
還有一個大家不太關注的就是時鐘。先前，我們發現系統時鐘是有回跳的，然後我們果斷在程序裡面加個監測模塊，一旦系統時鐘回跳，我們馬上把這個檢測出來。當然我們最初監測出這個東西的時候，用戶是覺得不可能吧，時鐘還會有回跳？我說沒關係，先把我們程序開了監測一下，然後過段時間就檢測到，系統時鐘最近回跳了。所以怎麼配 NTP 很重要。然後還有更多的，比如說文件系統，大家有沒有考慮過你寫磁碟的時候，磁碟出錯會怎麼辦？好，寫磁碟的時候沒有出錯，成功了，然後磁碟一個扇區壞了，讀出來的數據是損壞的，怎麼辦？大家有沒有 checksum ？沒有 checksum 然後我們直接用了這個數據，然後直接給用戶返回了，這個時候可能是很要命的。如果這個數據剛好存的是個元數據，而元數據又指向別的數據，然後你又根據元數據的信息去寫入另外一份數據，那就更要命了，可能數據被進一步破壞了。
所以比較好的做法是什麼？
Fault injection
Hardware
disk error
network card
cpu
clock
Software
file system
network & protocol
Simulate everything
模擬一切東西。就是磁碟是模擬的，網路是模擬的，那我們可以監控它，你可以在任何時間、任何的場景下去注入各種錯誤，你可以注入任何你想要的錯誤。比如說你寫一個磁碟，我就告訴你磁碟滿了，我告訴你磁碟壞了，然後我可以讓你 hang 住，比如 sleep 五十幾秒。我們確實在雲上面出現過這種情況，就是我們一次寫入，然後被 hang 了為 53 秒，最後才寫進去，那肯定是網路磁碟，對吧？這種事情其實是很嚇人的，但是肯定沒有人會想說我一次磁碟寫入然後要耗掉 53 秒，但是當 53 秒出現的時候，整個程序的行為是什麼？TiDB 裡面用了大量的 Raft，所以當時出現一個情況就是 53 秒，然後所有的機器就開始選舉了，說這肯定是哪兒不對，重新把 leader 都選出來了，這時候卡 53 秒的哥們說「我寫完了」，然後整個系統狀態就做了一次全新的遷移。這種錯誤注入的好處是什麼？就是知道當出錯的時候，你的錯誤能嚴重到什麼程度，這個事情很重要，就是 predictable，整個系統要可預測的。如果沒有做錯誤路徑的測試，那很簡單的一個問題，現在假設走到其中一條錯誤路徑了，整個系統行為是什麼？這一點不知道是很嚇人的。你不知道是否可能破壞數據；還是業務那邊會 block 住；還是業務那邊會 retry？
以前我遇到一個問題很有意思，當時我們在做一個消息系統，有大量連接會連這個，一個單機大概是連八十萬左右的連接，就是做消息推送。然後我記得，當時的 swap 分區開了，開了是什麼概念？當你有更多連接打進來的時候，然後你內存要爆了對吧？內存爆的話會自動啟用 swap 分區，但一旦你啟用 swap 分區，那你系統就卡成狗了，外面用戶斷連之後他就失敗了，他得重連，但是重連到你正常程序能響應，可能又需要三十秒，然後那個用戶肯定覺得超時了，又切斷連接又重連，就造成一個什麼狀態呢？就是系統永遠在重試，永遠沒有一次成功。那這個行為是不是可以預測？這種錯誤當時有沒有做很好的測試？這都是非常重要的一些教訓。
硬體測試以前的辦法是這樣的(Joke)：
這不僅僅是硬體的監控，也可以認為是做錯誤的注入。比如說一個集群我現在燒掉一台會怎麼樣？著火了，很典型的嘛，雖然重要的機房都會有這種防火、防水等各種的策略，但是真的著火的時候怎麼辦？當然你不能真去燒，這一燒可能就不止壞一台機器了，但我們需要使用 Fault injection 來模擬。
我介紹一下到底什麼是 Fault injection。給一個直觀的例子，大家知道所有人都用過 Unix 或者 Linux 的系統，大家都知道，很多人習慣打開這個系統第一行命令就是 ls 來列出目錄裡面的文件，但是大家有沒有想過一個有意思的問題，如果你要測試 ls 命令實現的正確性，怎麼測？如果沒有源代碼，這個系統該怎麼測？如果把它當成一黑盒這個系統該怎麼測？如果你 ls 的時候磁碟出現錯誤怎麼辦？如果讀取一個扇區讀取失敗會怎麼辦？
這個是一個很好玩的工具，推薦大家去玩一下。就是當你還沒有做更深入的測試之前，可以先去理解一下到底什麼是 Fault injection，你就可以體驗到它的強大，一會我們用它來找個 MySQL 的 bug。
libfiu - Fault injection in userspace
It can be used to perform fault injection in the POSIX API without having to modify the applications source code, that can help to test failure handling in an easy and reproducible way.
那這個東西主要是用來 Hook 這些 API 的，它很重要的一點就是它提供了一個 library ，這個 library 也可以嵌到你的程序裡面去 hook 那些 API。就比如說你去讀文件的時候，它可以給你返回這個文件不存在，可以給你返回磁碟錯誤等等。最重要的是，它是可以重來的。
舉一個例子，正常來講我們敲 ls 命令的時候，肯定是能夠把當前的目錄顯示出來。
這個程序乾的是什麼呢？就是 run，指定一個參數，現在是要有一個 enable_random，就是後面所有的對於 IO 下面這些 API 的操作，有 5% 的失敗率。那第一次是運氣比較好，沒有遇到失敗，所以我們把整個目錄列出來了。然後我們重新再跑一次，這時候它告訴我有一次讀取失敗了，就是它 read 這個 directory 的時候，遇到一個 Bad file descriptor，這時候可以看到，列出來的文件就比上面的要少了，因為有一條路徑讓它失敗了。接下來，我們進一步再跑，發現剛列出來一個目錄，然後下次讀取就出錯了。然後後面再跑一次的時候，這次運氣也比較好，把這整個都列出來了，這個還只是模擬的 5% 的失敗率。就是有 5% 的概率你去 read、去 open 的時候會失敗，那麼這時候可以看到 ls 命令的行為還是很 stable 的，就是沒有什麼常見的 segment fault 這些。
大家可能會說這個還不太好玩，也就是找找 ls 命令是否有 bug 嘛，那我們復現 MySQL bug 玩一下。
Bug #76020
InnoDB does not report filename in I/O error message for reads
fiu-run -x -c "enable_random name=posix/io/*,probability=0.05" bin/mysqld --basedir=/data/ushastry/server/mysql-5.6.24 --datadir=/data/ushastry/server/mysql-5.6.24/76020 --core-file --socket=/tmp/mysql_ushastry.sock --port=15000
2015-05-20 19:12:07 31030 [ERROR] InnoDB: Error in system call pread(). The operating system error number is 5.
2015-05-20 19:12:07 7f7986efc720 InnoDB: Operating system error number 5 in a file operation.InnoDB: Error number 5 means Input/output error.2015-05-20 19:12:07 31030 [ERROR] InnoDB: File (unknown):read returned OS error 105. Cannot continue operation
這是用 libfiu 找到的 MySQL 的一個 bug，這個 bug 是這樣的，bug 編號是 76020，是說 InnoDB 在出錯的時候沒有報文件名，那用戶給你報了錯，你這時候就傻了對吧？這個到底是什麼地方出錯了呢？然後這個地方它怎麼出來的？你可以看到它還是用我們剛才提到的 fiu-run，然後來模擬，模擬的失敗概率還是這麼多，可以看到，我們的參數一個沒變，這時把 MySQL 啟動，然後跑一下，出現了，可以看到 InnoDB 在報的時候確實沒有報 filename ，File : read returned OS error，然後這邊是 auto error，你不知道是哪一個文件名。
換一個思路來看，假設沒有這個東西，你復現這個 bug 的成本是什麼？大家可以想想，如果沒有這個東西，這個 bug 應該怎麼復現，怎麼讓 MySQL 讀取的東西出錯？正常路徑下你讓它讀取出錯太困難了，可能好多年沒出現過。這時我們進一步再放大一下，這個在 5.7 裡面還有，也是在 MySQL 裡面很可能有十幾年大家都沒怎麼遇到過的，但這種 bug 在這個工具的輔助下，馬上就能出來。所以 Fault injection 它帶來了很重要的一個好處就是讓一個東西可以變得更加容易重現。這個還是模擬的 5% 的概率。這個例子是我昨天晚上做的，就是我要給大家一個直觀的理解，但是分散式系統裡面錯誤注入比這個要複雜。而且如果你遇到一個錯誤十年都沒出現，你是不是太孤獨了？ 這個電影大家可能還有印象，威爾史密斯主演的，全世界就一個人活著，唯一的夥伴是一條狗。
實際上不是的，比我們痛苦的人大把的存在著。
舉 Netflix 的一個例子，下圖是 Netflix 的系統。
他們在 2014 年 10 月份的時候寫了一篇博客，叫《 Failure Injection Testing 》，是講他們整個系統怎麼做錯誤注入，然後他們的這個說法是 Internet Scale，就是整個多數據中心互聯網的這個級別。大家可能記得 Spanner 剛出來的時候他們叫做 Global Scale，然後這地方可以看到，藍色是注射點，黑色的是網路調用，就是所有這些請求在這些情況下面，所有這些藍色的框框都有可能出錯。大家可以想一想，在 Microservice 系統上，一個業務調用可能涉及到幾十個系統的調用，如果其中一個失敗了會怎麼樣？如果是第一次第一個失敗，第二次第二個失敗，第三次第三個失敗是怎麼樣的？有沒有系統做過這樣的測試？有沒有系統在自己的程序裡面去很好的驗證過是不是每一個可以預期的錯誤都是可預測的，這個變得非常的重要。這裡以 cache 為例，就說每一次訪問 Cassandra 的時候可能出錯，那麼也就給了我們一個錯誤的注入點。
然後我們談談 OpenStack
OpenStack fault-injection library:
os-faults 0.1.2 : Python Package Index
大名鼎鼎的 OpenStack 其實也有一個 Failure Injection Library，然後我把這個例子也貼到這裡，大家有興趣可以看一下這個 OpenStack 的 Failure Injection。這以前大家可能不太關注，其實大家在這一點上都很痛苦， OpenStack 現在還有一堆人在罵，說穩定性太差了，其實他們已經很努力了。但是整個系統確實是做的異乎尋常的複雜，因為組件太多。如果你出錯的點特別多，那可能會帶來另外一個問題，就是出錯的點之間還能組合，就是先 A 出錯，再 B 出錯，或者 AB 都出錯，這也就幾種情況，還好。那你要是有十萬個錯誤的點，這個組合怎麼弄？當然現在還有新的論文在研究這個，2015 年的時候好像有一篇論文，講的就是會探測你的程序的路徑，然後在對應的路徑下面去注入錯誤。
再來說 Jepsen
Jepsen: Distributed Systems Safety Analysis
當我們的分散式系統啟動起來之後，control node 會啟動很多進程，每一個進程都能使用特定的 client 訪問到我們的分散式系統。一個 generator 為每一個進程生成一系列的操作，比如 get/set/cas，讓其執行。每一個操作都會被記錄到 history 裡面。在執行操作的同時，另一個 nemesis 進程會嘗試去破壞這個分散式系統，譬如使用 iptable 斷開網路連接等，當所有操作執行完畢之後，jepsen 會使用一個 checker 來分析驗證系統的行為是否符合預期。PingCAP 的首席架構師唐劉寫過兩篇文章介紹我們實際怎麼用 Jepsen 來測試 TiDB，大家可以搜索一下，我這裡就不詳細展開了。
FoundationDB
It is difficult to be deterministic
Random
Disk Size
File Length
Time
Multithread
FoundationDB 這就是前輩了，2015 年被 Apple 收購了。他們為了解決錯誤注入的問題，或者說怎麼去讓它重現的這個問題，做了很多事情，很重要的一個事情就是 deterministic 。如果我給你一樣的輸入，跑幾遍，是不是能得到一樣的輸出？這個聽起來好像很科學、很自然，但是實際上我們絕大多數程序都是做不到的，比如說你們有判斷程序裡面有隨機數嗎？有多線程嗎？有判斷磁碟空間嗎？有判斷時間嗎？你再一次判斷的時候還是一樣的嗎？你再跑一次，同樣的輸入，但行為已經不一樣了，比如你生了一個隨機數，比如你判斷磁碟空間，這次判斷和下次判斷可能是不一樣的。
所以他們為了做到「我給你一樣的輸入，一定能得到一樣的輸出」，花了大概兩年的時間做了一個庫。這個庫有以下特性：它是個單線程的，然後是個偽並發的。為什麼？因為如果用多線程你怎麼讓它這個相同的輸入變成相同的輸出，誰先拿到鎖呢？這裡面的問題很多，所以他們選擇使用單線程，但是單線程本身有單線程的問題。而且比如你用 Go 語言，那你單線程它也是個並發的。然後它的語言規範就告訴我們說，如果一個 select 作用在兩個 channel 上，兩個 channel 都 ready 的時候，它會隨機的一個，就是在語言定義的規範上面，就已經不可能讓你得到一個 deterministic 了。但還好 FoundationDB 是用 C++ 寫的。
FoundationDB
Single-threaded pseudo-concurrency
Simulated the implementation of all the external communication
Determinism
Disasters happen more frequently here than in the real world.
另外 FoundationDB 模擬了所有的網路，就是兩個之間認為通過網路通訊，對吧？實際上是通過它自己模擬的一套東西在通訊。它裡面有一個很重要的觀點就是說，如果磁碟損壞，出現的概率是三年百分之八的話，那麼在用戶那出現的概率是三年百分之八。但是在用戶那一旦出現了，那證明就很嚴重了，所以他們對待這個問題的辦法是什麼？就是我通過自己的模擬系統讓它每時每刻都在產生。它們大概是每兩分鐘產生一次磁碟損壞，也就是說它比現實中的概率要高几十萬倍，所以它就覺得它調的技術 more frequently，就是我這種錯誤出現的更加頻繁，那網卡損壞的概率是多少？這都是極低的，但是你可以用這個系統讓它每分每秒都產生，這樣一來你就讓你的系統遇到這種錯誤的概率是比現實中要大非常非常多。那你重現，比如說現實中跑三年能重現一次，你可能跑三十秒就能重現一次。
但對於一個 bug 來說最可怕的是什麼？就是它不能重現。發現一個 bug，後來說我 fix 了，然後不能重現了，那你到底 fix 了沒有？不知道，這個事情就變得非常的恐怖。所以通過 deterministic 肯定能保證重現，我只要把我的輸入重放一次，我把它錄下來，每一次我把它錄下來一次，然後只要是曾經出現過，我重放，一定能出現。當然這個代價太大了，所以現在學術界走的是另外一條路，不是完全 deterministic，但是我只需要它 reasonable。比如說我在三十分鐘內能把它重現也是不錯的，我並不需要在三秒內把它重現。所以，每前一步要付出相應的成本代價。
未完待續...
延展閱讀：
分散式系統測試那些事兒——理念
推薦閱讀：
※如何解決分散式系統的Logical Time問題？（一）
※阿里PolarDB中的ParallelRaft中的亂序應答、亂序提交如何保證Raft協議的安全性？
TAG:分布式系统 |