1.概述

这个领域是一个分布式领域，它的很多假设完全是不一样的。

比如说函数调用，马上就返回了，但是在分布式领域就不一定了。

所以我们要做好设计，首先要理解这个领域。

对关键的问题，如何去做一个合理的抽象，建立模型。研究的目的是我要知道在这个模型里，我做这件事情的边界（哪些能做，哪些不能做）。

我知道有多少种选择、以及各种选择需要的代价、还有基本的技术。

这样的话我至少可以做一个不错的设计，我再看分布式开源软件的时候知道它为什么这么设计。

• 我要知道水有多深

• 可以解决哪些问题

• 哪些问题解决不了

而不是之前没有考虑过这个问题，那么出了之后就很难解决了。

2.基本问题

我们从工作中最怕的问题入手，得出了一些我们的思考。我们进入了分布式系统的领域，那么分布式系统给我们带来什么好处呢？

Scalability（伸缩性）

分布式的好处，可以拓展资源，两个资源：计算资源和存储资源。（无限大，单个节点都是有限的）。当然我可以做一个理想的计算机，无限的资源，但是成本非常高。任何一个系统都有一个物理的限制，我们期待我们的能力能够随着加资源而现行增长。

系统、网络或者过程在面对的负载量增长时，还能有效处理它们的能力（通过增大自己的能力以应对负载增长）

我们的期望是线性的。即我们的处理能力和物理机器是线性的关系，我通过加机器就可以解决问题。

• 规模、地理位置（延迟问题）、管理（管理开销）

物理限制

• 期望：线性伸缩

Performance

性能：系统使用单位资源和时间，能够完成的有用的工作量

• 请求的低延迟（单个处理）

• 高吞吐量（批量处理，1 小时能处理 1 万个请求）

• 资源的低占用

但是这些都有权衡的，比如提高我的延迟，我的吞吐量很可能是下降的。我一定要根据我系统的一个目标去做权衡。

Availability（可用性）

系统正常工作占用的时间比例。如果用户无法访问系统，那么系统就是不可用的

影响因素：

•1 系统自身。

自己 bug 要少，重启要快，要有备份。。。

•2 网络：系统要端到端的考虑。

•3 依赖的第三方服务。

面临的约束

既要。。又要。。。这话就很可怕。

没有约束就没有创造。

约束提供了设计空间。和边界。

• 节点的数目

随着计算和存储能力要求的增加而增加，节点数目越来越多；一个节点出问题的概率是 1%，那 100 个节点一定出问题。所以考虑 crash，是第一要素。

一定要基于出问题而做设计，而不是说我不出问题！

一定要基于出问题而做设计，而不是说我不出问题！

一定要基于出问题而做设计，而不是说我不出问题！

• 节点间的距离

信息传输的延迟

约束的影响

• 节点越多，系统出现故障的概率就越高

降低可用性，增加管理成本

• 节点越多，节点间的通信就会越多

降低性能

• 地理位置越远，节点间的最小通信延迟就越大

降低性能

3.抽象与模型

和其他学科一样，一定要对模型做抽象。

模型：现实的一个抽象对应物，把现实里面，无关的问题给它排除出去。

模型比现实要简单，跟我们的问题是高度相关的，然后我们在这个模型里研究，我们能做哪些问题，不能做哪些问题。

通信模型（异步/同步）

简单的讲，有没有一个全局同步时钟。

异步/同步：有没有全局同步时钟。假设我一个消息 2 秒没收到，那我可以断定节点 crash 掉了。

异步模型：无法判断 crash 和包丢了。

同步模型是一个理想模型。要么收到，要么 crash。

在异步模型里，是不能设置定时器的，所以这是一个概率问题。现实里是一个混合模型。

故障模型（崩溃/分区/Byzantine）

分区：网络故障。

Byzantine：它并不是会重启，而是会捣乱。会作假，会发错误的包。在大部分领域里面都不会有这种模型，在金融领域里面可能有这种模型。

一致性模型（强一致，最终一致）

《Fallacies of Distributed Computing Explained》

《Fallacies of Distributed Computing Explained》是一篇经典的分布式系统相关文章，介绍了分布式领域几个常见的谬论。在做分布式开发的时候，一定要铭记于心以免出错。

8 个谬论

1. 网络是可靠的

2. 网络延迟为 0

3. 带宽是无限的

4. 网络是安全的

5. 网络拓扑是不变的

6. 网络始终存在管理员

7. 传输损耗为 0

8. 网络是同质化

典型错误/模型

• Delay

• Concurrency

• Partial Failure

Partition

• 提升性能

1. 限制处理的数据规模

2. 相关数据放在同一分区

• 提升可用性

1. 不同分区隔离，互不影响

• 应用相关

1. 主要数据访问模式

2. 跨分区访问的低性能操作

3. 均衡性

Replication

• 提升性能

1. 新的数据拷贝，新的计算能力和带宽

• 提升可用性

1. 冗余备份

• 一致性问题

1. 清晰语义 VS. 业务设计目标

Fast Paxos

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-112.pdf

4.FLP impossibility

《Impossibility of Distributed Consensus with One Faulty Process》

https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf

分布式系统一致性协议里面有一个 FLP impossibility 的结论，这个结论是说，在分布式系统中，异步网络（消息延迟可能任意大或丢失，消息可能乱序），只要有一个进程失效（进程死亡或者足够长时间不响应），就不可能设计出一个确定性的一致性协议。

通俗讲 FLP 告诉你异步网络中 liveness 和 safety 是一对冤家. total correct 意味着要 safety,那么对不起, liveness 不保证了.这其实蕴含了 CAP,只是 CAP 太宽泛缺乏模型,而 FLP 的模型严谨因为只针对 concensus 问题. CAP 比较宽泛,不仅是 consensus 问题. FLP 是一个收窄的模型(fail-stop 模型,消息传递一次且仅一次,不会丢失,有一个节点进入 decision state 就算结束),所以 FLP 的证明更有杀伤力.

FLP 最大的作用就是告诉我们要放松 liveness,因此 Paxos/Raft 才能认为是可行的,严格讲 Paxos 可能永远无法结束,另外有一点很多人没有注意到, FLP 的论文提出的 0-1 consensus 问题成为了以后很多问题的研究模型.