MySQL 的 bug 必須修復嗎？兼論海勒姆法則 昨晚（2021-12-04）邀請在 PingCAP 工作的老弟屈鵬到 dubbogo 社區在線講解 TiDB，其間講到 TiDB 并沒有百分百兼容 MySQL，因為 MySQL 有些 bug，TiDB 將錯就錯照著實現了，而有些 bug 實在無法也去照著兼容實現，線上有社區同學質疑道，MySQL 也有 bug 嗎？ 且不論只要是軟件都會有 bug，TiDB 為了兼容 MySQL，其 bug 也要兼容實現，實在令人匪夷所思。其中一些原因是銀行在替換 MySQL 的過程中，對 TiDB 進行評估時，判斷標準是 TiDB 的計算結果與 MySQL 是否一致，TiDB 為了做到結算結果一致，其中一些功能便會依照 MySQL Bug 一并實現。 這便引申出一個話題，如何在不可靠的軟硬件體系之上構建可靠的計算體系。作為吃瓜群眾一方，我們可以與銀行一方，進行如下思想實驗： 不用。誠如不能因為會拉屎撒尿，便否認熊貓不是可愛的動物。 關于 MySQL bug 的話題，讓我回想起前一陣子 dubbogo 所依賴的網絡庫 getty 遇到的一次問題。今年（2021 年） 9 月 11 日【真是一個好日子】集團相關同學反饋 getty “在一個大量使用短鏈接的場景，XX 發現造成內存大量占用，因為大塊的buffer被收集起來了，沒有被釋放”。 通過定位，發現原因是 sync.Pool 把大量的 bytes.Buffer 對象緩存起來后沒有釋放。集團的同學簡單粗暴地去掉了 sync.Pool 后，問題得以解決。復盤這個問題，其根因是 Go 1.13 對 sync.Pool 進行了優化：在 1.13 之前 pool 中每個對象的生命周期是兩次 gc 之間的時間間隔，每次 gc 后 pool 中的對象會被釋放掉，1.13 之后可以做到 pool 中每個對象在每次 gc 后不會一次將 pool 內對象全部回收。 所以，Go 官方沒有 ”修復“ sync.Pool 的這個 bug ，其上層的 dubbogo 還能穩定運行，當他們 ”修復“ 之后，上層的 dubbogo 運行反而出了問題。 Go 語言 另外一個比較著名的例子便是 。Go 1.12 對其內存分配算法做了改進：Go runtime 在釋放內存時，使用了一個自認為更加高效的 而不是之前的 ，其導致的后果是 Go 程序釋放內存后，RSS 不會立刻下降。這影響了很多程序監控指標的準確性，在大家怨聲載道的抱怨后，Go 1.16 又改回了默認的內存分配算法。 關于軟件的 bug 是否應該修復這個問題，個人的看法是，對于出現的大部分 bug 我們當然需要修復。但對于一些有著悠久歷史的 bug，需要慎重對待。 今年（2021 年） 11 月，Java之父 James Gosling 在一次名為 ”你需要的軟件可靠性越高，靜態類型語言的幫助就越大“ 的采訪中，有如下論道。 現代的數字世界就是在這套看似 ”不可靠“ 的軟硬件體系之上構建出來的。換言之，我們需要做的是，如何在有 bug 的軟硬件體系上，構建出一個可穩定運轉且最終數據一致的數字世界。即便后退一步，如果做不到數據嚴格一致，如何把資損控制在最小范圍， 控制到我們可接受的范圍內。 時過境遷，又一年。來到 2022 年，也是我在螞蟻集團的第四年，還是在干一線。 今年（2022年）工作內容主要是 DBMesh，明白話就是：實現內部分庫分表系統 Java 語言實現的 zdal 【阿里集團的 tddl 的螞蟻分支版本】的 Go 語言版本，內部命名為 zdas。今天遇到了 SQL 的語義分析問題與同事產生了歧義，zdal 對某個 SQL 的解析明顯是個 bug，但既然實現的是一個 “完全兼容” 的系統，我個人堅持在 zdas 中按照這個 ‘bug' 實現了相關語義。 其實，業界早有一個 Hyrum's Law(海勒姆法則) 對這種現象予以描述：“With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody”，翻譯過來就是 "某個 API 接口的語義不是由制定者和實現者定義的，而是首批使用者的理解以及其后續跟隨者決定的"。【法則詳細內容見參考文檔1 】 這種 “bug 兼容” 現象，海勒姆法則【參考文檔1 】用一個專業詞語予以描述：“bug-for-bug compatibility”，聞之不禁莞爾。 1 https://www.hyrumslaw.com/