分布式系统工程师roadmap

分享:  

如何成为一名资深的分布式系统工程师,需要补齐哪些理论基础,又需要哪些工程方面的锻炼?本文原文见 Henry Robinson 的文章 distributed systems theory for the distributed systems engineer,我觉得是一个很不错的roadmap,沿着这个脉络半年下来,还是很有收获的……继续:)

1 掌握分布式背后的相关理论

可能会有人甩出很多论文,FLP论文、Paxos论文、Raft论文、拜占庭将军相关的论文…相关的论文可以摆出很多,但是论文是有一定深度的,是非常严谨的论述,对于攻读PhD的同学有帮助,但是对于一名从事分布式系统工程的同学真的有必要全部掌握吗?应该看多少论文,毕竟经过了那么多年的发展、沉淀呢? 作为一名分布式系统工程师,搞明白需要掌握哪些理论,比单纯了解有哪些论文更重要。

2 First Steps

下面的4个文集很好地介绍了构建一个分布式系统要面临的挑战,它们共同概述了分布式系统工程师必须克服的一些技术上的困难,并为后面章节中更详细的说明奠定了基础。

我们需要了解两个重要属性的含义,“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)的基本冲突。

我们需要了解:

5 Basic Primitives

分布式系统中几乎没有达成一致的基本构建块(building blocks),但更多的开始出现。 我们需要知道以下问题是什么,以及在哪里可以找到对应的解决方案:

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:作者功力有限,翻译中如有疏漏错误之处,请指出来避免我误导他人。