在之前的文章里面，我提到我用 Go 寫了一個類似 Jepsen 的工具 - Chaos ，里面我使用的是 Porcupine 來進行的線性一致性測試，但 Porcupine 并不能長時間執(zhí)行，因為它要解決的是一個 NP hard 的問題，如果要驗證的 history 太多，會算不出來，在我們 128 GB 機器上面，如果 history 有 2000 條，驗證線性一致性的時候就容易 OOM 了。

雖然之前看過一篇論文，Why Is Random Testing Effective for Partition Tolerance Bugs?，里面提到通過設計合理的測試用例，我們是能有很大概率去發(fā)現(xiàn)系統(tǒng)的問題的，但我仍然希望我們的測試能跑的久一點，能有更多的 history，這樣沒準能發(fā)現(xiàn)更多的 bug。

一個可能的辦法就是固定一個測試場景，然后跑多次，這樣比較簡單，但因為每次重跑集群都是新做的，重做集群會有一部分時間開銷，等的有點不爽。另外，仍然是跑的時間太短，對于 TiDB 整個集群來說，一些調度可能都還沒開始就結束了，其實并不能很好的發(fā)現(xiàn) bug。

于是就想到一個可行的辦法，引入中間狀態(tài)。怎么說呢，對于 Procupline，它的驗證其實仍然是基于狀態(tài)機的模型，給定一個初始狀態(tài)，然后開始迭代，每次迭代會根據(jù)測試程序的輸入輸出來生成下一個狀態(tài)，然后在驗證下一個狀態(tài)是不是符合預期，滿足線性一致性。對于 Chaos 來說，我們是有 5 個 client 來并發(fā)的給 TiDB 發(fā)送命令測試的。那么，我們其實可以做到，先讓 5 個 client 處理 1000 個請求，然后我們得到一個中間狀態(tài)，生成一個新的 history，再繼續(xù)。那么對于 Porcupine 來說，每一個 history 其實就是一個新的模型驗證了，然后初始化的狀態(tài)機就是 history 開始的中間狀態(tài)。

以我們現(xiàn)在的轉賬為例子，5 個用戶依次轉賬，最開始每人初始金額是 1000 塊錢，然后執(zhí)行 1000 次，這時候我們暫停測試，得到 5 個人現(xiàn)在的金額，當成下一次測試的初始狀態(tài)，繼續(xù)開始?？梢钥吹剑ㄟ^這樣的方式，我們就能在測試的時候一直進行線性一致性判斷了。每次跑 1000 條測試，生成一個 history，異步給 Porcupine 驗證，同時繼續(xù)下一次測試。

這個改動也是很容易的，在 history 的第一行記錄下初始狀態(tài)機，然后根據(jù)這個來創(chuàng)建 Porcupine 的 model 就可以了。如果你對這個感興趣，歡迎提 PR。

當然，我們可以更進一步。這個是我在跟 FoundationDB 的 Alex 討論的時候想到的，無論對于 Jepsen 的 Knossos 還是 Chaos 的 Porcupine，它其實是一個通用的線性一致性測試框架，是把整個測試服務當成黑盒來判斷的，但實際上，我們對于自己的服務，是有著清晰的認識的，也就是，我們其實能寫一個針對我們自己服務，專用的線性一致性測試框架。

對于 TiDB 來說，我們能夠確定，任何的事務都是有唯一的時間戳，而這個時間戳是一定單調遞增的，所以我們只要把我們的事務按照時間戳排序，然后在依次 replay，那么我們就能知道我們的系統(tǒng)是不是線性一致的。舉個例子，譬如轉賬，在 T1 時候，用戶 1 和 2 都是 1000 塊錢，然后 1 給 2 轉了 100，在 T3 的時候我們知道事務成功，那么 1 就是 900， 2 就是 1100。在 T2 （T1 < T2 < T3）的時候，我們可能會讀出來 1000，也可能會讀出來 1100，但一定不會讀出來其他的值。如果在 T2 的時候，我們讀出來是 1100 了，那么就意味著前一個轉賬的事務一定成功了，那么在 T2 之后，只能讀出來 1100， 不能在讀出來 1000 了。

因為這個線性驗證是跟我們自己的實現(xiàn)強相關的，所以寫出來就非常容易了，而且也不用處理那么多的分支情況，自然就能長時間運行跑了。當然，現(xiàn)在我只是簡單的實現(xiàn)了一個 demo，算是驗證了一下，還有很多東西需要完善，譬如我現(xiàn)在只考慮了全局的時序一致，其實也可以把單個客戶端的順序一致也考慮進來。如果你對這塊感興趣，歡迎提 PR，或者郵箱聯(lián)系 tl@pingcap.com。