前排提示，本文全文长 1.6w 字，由十个故事组成。出于微信公众号的展示特点，我将其切成若干个部分分开推送。如果想要单页读完全部内容，请点击阅读原文跳转网页，网页展示有目录，可以快速导航。
Apache Ratis
Ratis[1] 是一个 Raft 算法的 Java 实现，完成了 Raft 共识算法的核心逻辑，实现了一个服务框架，包括网络层，日志同步和落盘的功能，状态机及其快照的抽象，还支持运行时增减成员、动态配置和同时运行多个 Raft Group 等高级功能。
我对分布式共识算法的关注由来已久，可能跟我第一个稍有难度的工作就是改良 Flink 基于 ZooKeeper 的高可用模块有关。Ratis 作为共识算法 Raft 的实现，自然也进入我的视野。
真正开始探索 Ratis 的实现，起源于我从分布式计算做到分布式存储以后，了解到 Spanner、TiKV 和 Oceanbase 等等系统都是基于共识算法来实现数据的复制和一致性的。在理解相关的代码和论文之余，我也想要自己写一个个人项目来实践自己的理解。Ratis 自己曾经想过做一个 Replicated Map 实现，类似于 ZooKeeper 或 etcd 来解决大部分用户的简单读写场景，但是最终没做成。我顺着这个思路，时不时做一些实验和源码阅读，并在今年以 zeronos[2] 为项目名开始做一个完整的实现。
在这个过程里，我发现过 RATIS-1619[3] Group 创建时约束的问题，顺手就解了。这跟前面给 atomic 提补丁没什么区别，不做展开。
重点要说的是下面这个例子。我在琢磨怎么实现类似 etcd 的 watch 功能的时候，发现 Ratis 在框架层面实现了网络通信，虽然方便了下游只需要定义状态机就可以起集群，但是网络通信只实现了简单的 request-response 模式，不能照搬 etcd 的全双工长连接实现。
在之前跟 Ratis 的作者施子和博士的沟通过程里，我发现主要能找到他的渠道在邮件列表上，于是我就把自己的需求在 [email protected][4] 上反馈。
•Full-duplex server-client communication[5]
果然，施子和博士在一小时内就回复了我的问题。经过几轮沟通，我们得出结论：watch 和 put 主要的区别在于乱序返回，也就是一个 watch 请求到来之后，必须先处理完后续的写请求才能出发 watcher 并返回给客户端。而 Ratis 同一个客户端的请求默认是排序的。解决了这个问题，只要在请求和返回的时候带上键值状态机里 key (range) 的 revision 就能保证获取变更信息不会错过，至于是不是采用全双工链接来实现，反而不是特别重要。
得出结论以后，我又开始 push 上游推进。当然，开源社群的参与者都是志愿者，没有催促别人做事情的道理。但是我可以做我力所能及的事情，激励其他参与者发现这件事情有人在关注从而提升优先级。所以，在两天之后没有后续的情况下，我就把 user 邮件列表上的结论总结成一个技术上的问题报告，提交到 Ratis 的 JIRA 项目上。
•Support unordered async read[6]
几分钟后，施子和博士在 issue 上问我是否已经开始实现了，我只能坦诚地说没有。于是他表示他可以实现，并且确实在三天之后就提交了补丁。经过几轮 review 以后，我 approve 了相关变更。
然后，就是定番询问发布的计划。因为我知道 master 分支上要等 3.0 版本发布才能用上，而 3.0 发布还没确切的日子，相对而言这个改动并不大，包含在 2.x 版本按照以往的节奏一两个月以内就可以发布了。施子和博士也同意了这个说法。
这个案例是一个代码以外的参与案例。本文开篇就提到，上游优先包括提交代码，也包括报告问题。实际上，将自己创作的软件开源发布，对于软件工程师来说很关键的一个好处就是收获同行评审和用户反馈。相反，仅作公司内部使用的软件往往少有人关注代码的技艺，只关心最终效果，并且通常使用场景有限，很难得到解决复杂问题的锻炼机会。
从参与者的角度看，这个案例体现出来的仍然是积极和上游沟通，尤其是做一些力所能及的工作。开源社群的成员都是志愿者，他们不会因为某个需求是你提出的就另眼相待。他们几乎总是从完成需求的难度和回报来衡量自己是否应该投入时间。做一些力所能及的工作，哪怕是前期调研和技术分析，一方面能降低解决问题的难度，另一方面让其他成员看到你为这个问题付出的努力，你有相当的主动性，解决这个问题能帮助到你。谁又不想和这样的同伴合作呢？
References
[1] Ratis: https://github.com/apache/ratis[2] zeronos: https://github.com/korandoru/zeronos[3] RATIS-1619: https://github.com/apache/ratis/pull/677[4] [email protected]: mailto:[email protected][5] Full-duplex server-client communication: https://lists.apache.org/thread/rg65qoph54hlpdhmoc3p80sd0z6wzwjm[6] Support unordered async read: https://issues.apache.org/jira/browse/RATIS-1714