适合 分布式系统工程师 的 分布式系统理论

适合 分布式系统工程师 的 分布式系统理论

原文

Gwen Shapira曾在Cloudera作工程师，如今宣传Kafka，他在Twitter问了如下问题，使我有所思考。

我想在分布式理论上有所提高。应该从哪开始？有推荐的书？
— Gwen (Chen) Shapira (@gwenshap) August 7, 2014

我第一反应是“能够看：FLP论文、paxos论文、Byzantine将军论文”。我推荐的主要阅读材料，若是你贸然去读，你至少要阅读6个月才会有感受。由此可知，推荐一吨的理论论文让你阅读，这是了解分布式系统的错误的方式（除非你在读博士）。 论文通常是深奥、复杂的，并且须要一系列学习和丰富的经验才能感受到其贡献、才能把其放到对应的场景(以理解和应用)。

工程师了解分布式理论有什么好处？

很不幸，几乎没有好的引导文章，来总结、提炼、场景化 分布式系统理论中的重要结论和想法; 特别是 通俗易懂的引导文章 更没有。
考虑这样的空白区域，让我想问另外一个问题：

一个分布式系统工程师应该了解什么样的分布式系统理论？

这种状况下，了解一点点理论并非坏事。我平常工做是一个分布式系统工程师，下面会给出 我认为适合个人基本概念 们。
你认为我缺失的请告知我!

准备

下面四个读物解释了构建分布式系统会遇到的困难。这些读物都勾勒了一些列 抽象而非技术 的困难，分布式系统工程师必需要克服这些困难。这些读物的后面章节有更详细的研究。

Distributed Systems for Fun and Profit 是一本小书，它想覆盖分布式系统中的一些基本问题，包括 时钟所起的做用、不一样策略的复制。

Notes on distributed systems for young bloods - 非理论，而是一个很好的实践，以让你落到实处。

A Note on Distributed Systems - 一个经典论文，关于 为何你不能伪装全部远程交互像本地对象同样。

The fallacies of distributed computing 分布式计算的8个错误的推论，以提醒系统设计者。

你应该知道 安全 和 活力:

• 安全 说的是 永远不会发生坏事。好比，不返回不一致的值 是 一种 安全， 同一时刻不会选出两个 主节点 也是 一种 安全。
• 活力 说的是 好事情终究会发生。好比，对于每一个api调用，一个系统终究会返回一个结果，这是一种 活力；保证一次写磁盘最终总能结束，这是一种 活力。

失败和时钟

分布式系统工程师面对的许多困难能够归结为如下两个缘由:

1. 进程可能_失败_
2. There is no good way to tell that they have done so

进程间怎么共用时钟、什么样的失败能够检测、什么样的算法和原语能够被正确实现，这三者之间有很深的联系。通常状况下，咱们假设不一样节点绝对没法共用时钟(时刻值或流过了多少时间).

你应该知道:

• 失败模型的层次：节点崩溃后关机 -> 节点崩溃后死机(通过无限长时间后才响应) -> 恶意节点 (不遵照约定的规则) 。 各个层次间逐渐将限制放松，你应该知道这些限制.
• 两个节点之间，没有任何共用时钟，你怎么肯定一个节点上的一个事件和另外一个节点上的另外一个事件之间的前后顺序. 这就要阅读Lamport时钟和更通常化的Vector时钟, 也能够阅读Dynamo论文.
• 容许单节点失败对实现正确的分布式系统有多大的冲击？(见下面FLP结论处)
• 时钟的不一样模型：同步、部分同部 、 异步
• 失败检测是一个基本问题，失败检测能够平衡准确度和完成度(若是能检测到失败了，则能够允许不那么准确、没彻底作完)，失败检测也能够解决安全和活力间的冲突。把失败检测做为理论来研究的论文是 Chandra and Toueg’s ‘Unreliable Failure Detectors for Reliable Distributed Systems’. 不过也有一些简短的总结-我特别喜欢this random one from Stanford.

容错致使的基本矛盾

一个系统容忍一些错误而没有降级 必须能当成 就像这些错误没有发生过同样。这意味着系统的一部分要冗余地工做(一样的功能部署多个节点)，冗余是绝对必要的，冗余通常会带来性能和资源的消耗。这就是给一个系统添加冗余的基本矛盾。

你应该知道：

• 确保串行单复制的多数派技术. 见 Skeen’s original paper, 不过或许更好的是 Wikipedia条目).

(多数派中有一个是主节点,其他为从节点，以主节点接收到的写请求序列为准[即串行]，主节点单方面的要求从节点们接受主节点的写请求序列[从节点不得反抗、不得有异议：从节点是诚实的非恶意的、遵照全局规则的、非拜占庭的])

• 两步提交、 三步提交 、Paxos, 以及为何他们不一样于容错.
• 最终一致性、其余技术 以 对系统行为作更弱的保证 为代价 来 设法避开 此矛盾 . 能够看 Dynamo 论文 , 不过 必需要读 Pat Helland的论文 经典 Life Beyond Transactions .

基本原语

在分布式系统中，不多有约定的基本构建块，更多的是处于造成中的基本构建块。你应该知道下面的问题是什么，而且从哪能找到他们的解决方案：

• 主节点选举 (例如 Bully 算法)
• 一致快照 (好比 这个来自 Chandy and Lamport的经典论文 )
• 一致性 (见上面 2PC 、 Paxos 处)
• 分布式状态机复制 (看Wikipedia 就行, Lampson的 论文 是权威可是太枯燥了).

• 广播 - 同时发送消息给集群

  • 原子广播 - 你能发送消息给一集群，使得要么集群中的全部节点都收到了这条信息、要么集群中所有节点都没收到此消息?(这就是原子广播)

*   Gossip ([经典论文](http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-89-1_Epidemic_Algorithms_for_Replicated_Database_Maintenance.pdf))
    
*   [因果广播](https://www.cs.cornell.edu/courses/cs614/2003sp/papers/BSS91.pdf) (也能够看看 [Birman](https://www.cs.rice.edu/~alc/comp520/papers/Cheriton_Skeen.pdf)和[forth](https://www.cs.princeton.edu/courses/archive/fall07/cos518/papers/catocs-limits-response.pdf) ).

• 链式复制 (将节点们放进一个虚拟链表中，从而能够干净的确保写请求的一致性和顺序 ).

  • 原始论文
  • 对负载中读请求占绝大多数的一系列改良
  • @slfritchie给出的 一个经验报告

基础结论

有些事实只须要主观理解(不须要关注证实).

• 若是节点间可能丢失消息[:P]，那么你不可能 既 实现一致性存储[:C] 又 响应全部时刻的请求[:A]. 这就是 CAP理论.
• 在一个异步系统中，一致性不可能以这样一个途径实现：既a) 老是正确的 ； 又b) 老是能结束 即便只有一个节点可能以 崩溃-*中止 失败 (FLP结论). 在看证实以前，看下我以简明的方式解释FLP结论的论文 Papers We Love SF talk . _建议: 没有理解证实的须要_.

(一个异步系统中，假设节点崩溃后中止而不是奔溃后又恢复；一、要确保结果老是正确的，二、每次写请求可以在有限时间内返回结果。这两点无法同时知足：这就是FLP结论)

• 通常地，只进行少于2轮的消息传递，不可能达成一致性 .
• 原子广播和一致性，两者的难度精确的相等。更直白的说，若是你能解原子广播，那么你也能解一致性，反之亦然。 Chandra 和 Toueg 证实了这一点, 可是你只须要知道这个论断是成立的。

真实系统

最重要的、应该不断重复的实践是：读新的、真实的系统的描述，并评价他们设计的决定。 下面是建议的系统：

Google:

• GFS
• Spanner
• F1
• Chubby
• BigTable
• MillWheel
• Omega
• Dapper
• Paxos Made Live
• The Tail At Scale

Not Google:

• Dryad
• Cassandra
• Ceph
• RAMCloud
• HyperDex
• PNUTS
• Azure Data Lake Store

Postscript 结尾

若是你驯服了这个列表中的全部概念和技术，我很乐意和你聊聊Cloudera的分布式系统工程师职位。