Introduce

​ 周末打开SJTU-IPADS SOSP 2021的云笔记，浏览起在线召开的SOSP 2021，找找有没有感兴趣的话题，注意到了Exploiting Nil-Externality for Fast Replicated Storage[1]，提出了一个名为SKYROS的共识协议优化方案，文章开篇的第一句引用的是图灵奖得主Butler W Lampson的金句：

Defining the right interfaces is perhaps the most important aspect of system design

​ 还给了几个例子，其中一个就是幂等接口的设计，让用户处理失败恢复更加简单。抛砖引玉，他们给出了他们的观察和思考，认为现实存储系统，很多时候write了之后并不会立即去read，所以write在共识协议数据复制的阶段可以将一些事情推迟了做，从而提升性能，为此，他们设计和定义了一个全新的nil-externality write接口，表示这次write并不会立即被观察（也就是read），所以数据复制期间就有了开展优化的空间了，是不是感觉有点薛定谔猫的神秘。

​ 但是很遗憾，简单看了下来，不由得感叹，Defining the right interfaces is perhaps the most important aspect of system design。那Nil-Externality到底算是一个好的接口设计吗 ？个人感觉不是，而且过渡设计，让系统的复杂性大大增加，收益确寥寥无几。

​ 那什么是好的设计呢 ？不知道该如何回答，决定搬运存储系统里面好的设计的例子给大家对比下，一起思考下，好的系统设计应该是怎样的 ？

Skyros

​ 先来看看论文作者的设计，我们知道现在分布式存储系统很多都通过共识协议（例如Paxos、Raft等）来实现多副本数据一致性的服务，如下图，通常需要write会写leader，然后leader在复制给follower，等大多数follower返回之后，leader就可以返回给client了，需要两个RTT；read则是直接发送给leader，直接返回，只需要一个RTT。对write来说，性能通常被认为是一个需要优化的问题，一方面是需要两个RTT，另外一方面，是为了保证多个副本数据一致，需要leader定序，leader给follower数据复制也得保序，限制了并发。

​ 而考虑到很多时候write了之后并不会立即去read，所以write在数据复制的阶段可以将一些定序的事情推迟去做，以此来提升性能，为此，他们设计一个全新属性的write接口：nil-externality write，所以整个读写流程都变了：

• nilext write（也就是nil-externality write）：直接client写入多个副本，包含主的大多数返回之后，就返回成功，一个RTT；定序相关的事情在后台异步完成
• write（也就是普通write，非nil-externality write）：直接走老的数据复制协议，写leader，leader再复制给follower，两个RTT
• read且后台不存在相同数据nil-externality write：直接read leader返回，一个RTT
• read且后台存在相同数据nil-externality write：那么leader需要对相关数据完成排序确认之后，再read返回给用户，由于完成排序，leader需要和follower交互确认，所以会是两个RTT

​ 考虑到实际应用场景大多nil-externality write，是不是感觉厉害了，绝大多数情况写入变成了一个RTT。但是终究理想很丰满，现实很骨感，延迟排序看上去很美好，但是确实也掉进了一个大坑，为此持久化就引入两种log，一个是d-log，存放所有nil-externality write会直接写入到d-log中，表示还没有定序不能提交，c-log，存放直接写leader，和定序了之后的d-log。

​ 到这里更细节的东西就不聊了，我们一起看看这个nil-externality设计的得失：

• • nil-externality write的延迟提升，一个RTT；但是nil-externality write，对用户来说是一个真切的需求吗 ？
  • client复杂度提升一个等级，需要处理多副本写入
  • leader复杂度也提升了一个等级，写完d-log，后面还要和follower重新协商c-log，failover恢复需要判定d-log的顺序等等，回想Raft为什么比Paxos简单，核心原因就是不让你乱序，让一切顺序起来，加一个限定，让无序变有序，最终让整个协议的复杂度大大的降低
  • d-log，c-log意味着整体写入多了一倍放大，对性能的影响其实不容小觑
  • read的复杂度也有提升，因为一旦后台存在相同数据nil-externality write，那么还要leader协商完成之后才能返回

整体感觉nil-externality write，一个不被用户真切需要的接口，让整个系统的复杂性陷入灾难。

Great Design

​ 那什么是好的设计呢 ？这里给几个例子。

​ 第一个是window azure storage里面的Stream Layers，它给用户提供的一个只支持append-only语义接口的文件（而不是randwrite语义也支持的文件），一次写入，多次读取，一下子让数据的多副本复制更加简单了，完全不需要走Raft或者Paxos协议了，只需要走new-seal即可，数据写入也可以从client直接发送给所有副本，等所有副本都成功了之后，就可以返回了，好处很明显：（1）append-only，数据复制，可以直接在client做，写多个副本，都成功了直接返回，只需要一个RTT，而且相比Paxos和Raft等更简单，failover也可以通过new-seal的方式直接完成；（2）append-only写入，不可变的数据，那么更加有利于后期做压缩和EC;（3）append-only写入，在性能和后续排错等方面相比覆盖写有天然的优势。通过抽象了分布式数据复制里面最简单、最通用的原子能力，append-only op log来解决分布式系统最难的数据复制的问题

​ 第二个就是Raft了，限定了日志顺序提交，让无序更加有序，虽然损失了一定的并发性能，但是让共识协议的可理解性大大提升，工程实践大大简化，使得大家再解决分布式系统高可靠、高可用问题取得了长足的进步

​ 第三个就是最终一致性，考虑到很多业务场景数据一致性并没有那么强，所以一些Nosql在设计的时候，对CA里面对C做一定的妥协，保证了分布式系统的可用性和可扩展性

Summary

​ 好的设计或许是抽象出要解决问题的本质，用最简单的设计得到一个综合最优的结果，多做减法，在trade-off中找到平衡。当然，Skyros毕竟是一个学术的idea，很多时候更多的是分享思路，实际工程的可行性可能不是他们首要考虑的，所以。

Notes

限于作者水平，难免有理解和描述上有疏漏或者错误的地方，欢迎共同交流；部分参考已经在正文和参考文献中列表注明，但仍有可能有疏漏的地方，有任何侵权或者不明确的地方，欢迎指出，必定及时更正或者删除；文章供于学习交流，转载注明出处

References

[1]. Exploiting Nil-Externality for Fast Replicated Storage. SOSP 2021. https://dl.acm.org/doi/pdf/10.1145/3477132.3483543

[2]. Calder B, Wang J, Ogus A, et al. Windows Azure Storage: a highly available cloud storage service with strong consistency[C]//Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles. ACM, 2011: 143-157.