分布式系统工程师roadmap
Posted 2021-07-02 12:45 +0800 by ZhangJie ‐ 2 min read
如何成为一名资深的分布式系统工程师，需要补齐哪些理论基础，又需要哪些工程方面的锻炼？本文原文见 Henry Robinson 的文章 distributed systems theory for the distributed systems engineer，我觉得是一个很不错的roadmap，沿着这个脉络半年下来，还是很有收获的……继续:)
1 掌握分布式背后的相关理论
可能会有人甩出很多论文，FLP论文、Paxos论文、Raft论文、拜占庭将军相关的论文…相关的论文可以摆出很多，但是论文是有一定深度的，是非常严谨的论述，对于攻读PhD的同学有帮助，但是对于一名从事分布式系统工程的同学真的有必要全部掌握吗？应该看多少论文，毕竟经过了那么多年的发展、沉淀呢？ 作为一名分布式系统工程师，搞明白需要掌握哪些理论，比单纯了解有哪些论文更重要。
2 First Steps
下面的4个文集很好地介绍了构建一个分布式系统要面临的挑战，它们共同概述了分布式系统工程师必须克服的一些技术上的困难，并为后面章节中更详细的说明奠定了基础。
- Distributed Systems for Fun and Profit，介绍了分布式系统的基础知识，包括时间在分布式系统中扮演的角色、不同的复制策略等；
- Notes on distributed systems for young bloods，不是纯理论介绍，在理论和实践中做到了一个不错的平衡，为后续更深入学习打好基础；
- A Note on Distributed Systems，一篇很经典的论文，解释了分布式系统中为什么不能总把远程交互对象当做本地的对象，让读者理解分布式场景中的问题和挑战；
- The fallacies of distributed computing，分布式计算的8个谬论，为分布式系统设计人员设计系统打下基础；
我们需要了解两个重要属性的含义，“safety”和“liveness”：
- safety，该属性表示不会有坏的事情发生，如API不会返回不一致的value、集群中不会同时选出两个leader等；
- liveness，该属性表示好的事情最终会发生，如API最终会返回一个结果、磁盘写操作最终会完成等；
3 Failure and Time
分布式系统工程师面对的一些困难，其实可以归结为下面2个原因：
- Processes may fail
- There’s no good way to tell that they have done so
即，分布式系统中的任意进程可能会出现故障，但是其他进程又没有可靠的方式来感知这个进程出现了故障。
进程掌握并共享给其他进程的时间方面的信息、可能检测到的故障场景以及可以正确实现的算法和原语之间存在非常紧密的关系。大多数情况下，我们假设两个不同的节点对于现在是什么时间或时间流逝的速度完全没有共享的信息。
我们需要认识到：
- 故障模式（failure modes）也是分层次的，大致分成：crash stop（崩溃停止） → omission（遗漏） → Byzantine（拜占庭）。我们要知道在层次结构顶部可能发生的在较低级别必须是可能的，在较低层不可能发生的在更高级别也必须是不可能的；
- 在缺少任何共享时钟的情况下，如何判断一个事件和另外一个事件发生的先后顺序。我们需要掌握Lamport clocks，以及它的泛化Vector clocks，也参考下Dynamo的这篇论文吧；
- 发生单个故障的可能性，对我们实现一个正确的分布式系统的影响有多大（可以参考下面给出的FLP result的笔记）；
- 不同的时间模型（models of time），同步（synchronous）、部分同步（partially synchronous）、异步（asynchronous）；
- 检测故障是一个基本问题，它在准确性和完整性之间进行权衡——这是另一个safety与liveness（安全与活跃）的冲突。 真正将故障检测作为理论问题提出的论文是 Chandra 和 Toueg 的“Unreliable Failure Detectors for Reliable Distributed Systems（可靠分布式系统的不可靠故障检测器）”。但是也有几个较短的摘要总结 - 我非常喜欢斯坦福大学的这个随机摘要总结Survey on Scalable Failure Detectors。
4 The basic tension of fault tolerance
一个可以容忍某些故障（fault tolerance）而不降级（downgrade）的系统必须能够像这些故障没有发生一样运行。 这通常意味着系统的某些部分必须冗余地工作（work redundantly），但做比绝对必要的工作更多的工作（do more work than is absolutely necessary）通常会带来性能和资源消耗的成本。 这是为系统添加容错（fault tolerance）的基本冲突。
我们需要了解：
- 确保单副本可串行化（single-copy serialisability）的仲裁技术（quorum technique）。 请参阅 Skeen 的原始论文 a quorum-based commit protocol，但也许更好的是 Wikipedia 的条目。
- 关于2阶段提交（2-phase-commit，简称2PC）、3阶段提交（3PC）、Paxos，等等，它们为什么会拥有不同的容错属性；
- 最终一致性（eventual consistency）及其他技术，如何以对系统行为的较弱保证为代价，来避免一致性、性能之间的冲突。Dynamo论文（Dynamo: Amazon’s Highly Available Key-Value Store）是一个了解这些内容不错的起点吧，Pat Helland的经典论文 Life Beyond Transactions（Life beyond Distributed Transactions: an Apostate’s Opinion） 也值得一读。
5 Basic Primitives
分布式系统中几乎没有达成一致的基本构建块（building blocks），但更多的开始出现。 我们需要知道以下问题是什么，以及在哪里可以找到对应的解决方案：
- 领导者选举（leader election），Bully算法等；
- 一致性快照（consistent snapshotting），Chandy和Lamport的经典论文 Distributed Snapshots: Determining Global States of a Distributed System 等；
- 共识问题（consensus），参考上面提及的2PC、Paxos论文；
- 分布式状态机复制（distributed state machine replication），wikipedia的介绍就不错，Lampson的论文 How to build a highly available system using consensus 比较正式但是有点枯燥；
- 广播（broadcast），同时传递消息给不止一个节点，这里又有几种不同的技术：1）原子广播（atomic broadcast），要么广播一个消息给分组（group）内的所有节点，要么不广播给任何一个节点；2）gossip，参考经典论文；3）因果多播（causal multicast），也考虑下Birman和Cheriton之间令人愉快的来回。
- 链式复制（chain replication），通过将节点组织成虚拟链表来确保写入的一致性和顺序性的一种巧妙方法。1）最早的论文 Chain Replication for Supporting High Throughput and Availability；2）对读多写少场景的一系列改进 Object Storage on CRAQ: High-throughput chain replication for read-mostly workloads；3）@slfritchie做的一个实验报告 Chain Replication In Theory and in Practice Working Title, rough draft。
6 Fundamental Results
关于分布式理论的几个事实要牢记在心，先列几个帮助比较大的。
- 如果在不同进程之间有消息丢失（网络分区），我们将不能实现强一致性存储（C）的同时还能对所有请求进行正确响应（A）。这就是大家熟知的CAP理论；
- 共识（concensus）是不可能通过如下方式实现的：1）总是正确的；2）总能终止，即使当（异步）系统中某台机器出现“崩溃-停止（crash-stop）”时（FLP result）。在论文“We Love SF Talk”第一页解释了FLP result，后面是证明，没有必要去搞明白证明过程（反证，琢磨下也好理解）。
- 一般而言，在少于2轮消息交互的情况下不可能解决共识问题；
- 原子广播（atomic broadcast）和共识问题一样困难——准确地说，如果我们解决了原子广播，也就解决了共识问题；反之亦然。Chandra和Toueg证明了这一点（Unreliable Failure Detectors for Reliable Distributed Systems），我们了解这是对的就好了。
7 Real Systems
掌握、精通分布式的最重要的方式就是不断实践，不断阅读、了解、跟进、评价业界的真实系统、新出现系统的设计决策。 一遍又一遍地这样做。
下面是一些推荐阅读信息：
Google：
Not Google：
8 Postscript
本文作者是 Henry Robinson ，原文见 distributed systems theory for the distributed systems engineer。作者在文末留了个招聘广告，这里就保留了（既然干货满满如此有诚意）。
如果你掌握了这个列表中的所有概念和技术，可以联系我，我想和你谈谈我们在Cloudera Slack的分布式系统工程师开发职位。—— Henry Robinson
ps：作者功力有限，翻译中如有疏漏错误之处，请指出来避免我误导他人。