從使用者到開發者，知乎參與 TiDB 社區背後的故事

做者介紹：孫曉光，知乎技術平臺團隊負責人，負責建設知乎在線和離線的基礎設施平臺，爲業務開發提供統一的基礎設施。曾多年從事私有云相關產品開發工做，關注雲原生技術，TiKV 項目 Committer。

關注 TiDB 的朋友們可能發現繼 Follower Read 在 TiKV 端的 PR 合併後，TiDB 端相關的 PR 也於近期完成了到主幹的合併工做。若是後期的穩定性測試一切正常，相關功能應該會隨 TiDB 3.1 發佈。Follower Read 功能自己從代碼量上看並不大，但這個功能的意義尤爲是對互聯網類型業務來講是很是大的。

前段時間 PingCAP CTO 黃東旭已經寫了 一篇文章，從原理角度對 Follower Read 作了很是透徹的介紹和分析。今天我想從非技術的角度介紹 Follower Read 功能的落地過程，並從 Contributor 的視角跟你們聊一聊我的參與 TiDB 開發過程當中的體驗和感覺。最後站在知乎技術平臺團隊的角度，聊一下咱們將來在積極參與開源項目，共同建設社區的願望和決心。

Follower Read 背後的故事

Follower Read 的實現思路在 PingCAP 工程師大腦裏應該已經存在好久了，但出於各類緣由這個特性的優先級一直不夠高，並無能排到開發計劃中。年中的時候咱們開始嘗試在知乎更普遍的業務中引入 TiDB，在灰度過程當中咱們遇到了某些特定工做負載下 TiDB 表現不夠理想的問題。目前看來 TiDB 讀寫操做都交給 Leader 完成，是咱們目前在特定負載下遇到吞吐問題的瓶頸點。

在理清思路後，咱們同 PingCAP 的工程師作了幾回交流並達成一致，決定經過 Follower Read 的方式來解決咱們業務場景中極端熱點數據訪問的吞吐問題。在實際需求的驅動下， PingCAP 同窗將 Follower Read 相關特性的優先級提升，快速肯定了相關功能的技術方案並啓動了 TiKV 端的開發工做。做爲 Follower Read 功能的需求方，知乎負責這個需求在 TiDB 上的落地工做。

PingCAP 工程師用了大約兩週的時間完成了 TiKV 層 Follower Read 整個功能的開發測試，並將其合併到 master 分支中，隨後咱們開始了 TiDB 側相應功能的開發，在 PingCAP 小夥伴們的幫助下最終完成了相應功能到 master 分支的合併。做爲知乎和 PingCAP 兩家公司第一次聯合開發的成果，這個功能的落地對雙方都有着重大的意義。

從 Contributor 到 Committer

在以知乎技術平臺團隊成員的身份參與 TiDB 貢獻以前，我的曾經在過去的一年裏以用戶的身份爲 TiKV & TiDB 作過一些小型的貢獻。接下來我就從我的角度聊一下從 Contributor 到 Committer 的成長過程和其中的體驗。

第一次爲 PingCAP 旗下項目提交 PR 併成爲 Contributor 發生在大約一年前，我在爲內部開發的業務系統選擇合適的存儲後端時，嘗試給 TiKV 增長了一些批量操做接口。PR 提出後，PingCAP 首席架構師唐劉很快就跟我創建了聯繫，在隨後的交流中幫助我快速完善 PR 並最終合併到 TiKV 的主幹中。

雖然以往以零散的方式給不少開源項目提交過 Patch，但此次的體驗是徹底不一樣的，PingCAP 和社區夥伴們熱心的幫助和鼓勵讓我切身感覺到了活躍的開源社區所具備的獨特魅力。隨後出於我的興趣，我在 TiDB 相關的項目中又陸陸續續作了一些簡單的貢獻，最終獲得你們的承認成爲 TiKV 項目的 Committer 之一。

擁抱開源

回過頭來看這段時間的成長和收穫都是巨大的，不但學習到了如何同開源社區衆多優秀的貢獻者更加高效的交流，而且對開源的價值理念和開源在基礎軟件領域的重大意義有了更加深刻的理解。

近期隨着在公司所在團隊的轉換，我我的開始更多的關注在線和離線的基礎設施在知乎的演進。知乎一直以來都鼓勵擁抱開源，並基於大量開源組件搭建了知乎的技術架構，得益於開源的力量，知乎的內部平臺一直都緊隨着行業技術發展的潮流。從前咱們更可能是站在使用者的角度從開源社區汲取營養，隨着知乎技術架構和內部工程能力的成長，將來咱們但願可以以更加積極主動的狀態參與開源項目，回饋社區。Follower Read 是知乎第一次以 Contributor 身份參與 TiDB 社區建設，將來咱們會參與更多的技術社區的建設爲開源社區的發展貢獻咱們的力量。

原文閱讀：https://pingcap.com/blog-cn/zhihu-the-story-of-contributing-to-tidb-community/