作者介绍：孙晓光，知乎技术平台团队负责人，负责建设知乎在线和离线的基础设施平台，为业务开发提供统一的基础设施。曾多年从事私有云相关产品开发工作，关注云原生技术，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://blog.csdn.net/TiDB_PingCAP/article/details/100789359