mit6.824 笔记 一
作者：互联网
分布式是复杂的系统再考虑分布式系统前应该尽可能尝试其他方法。
人们使用大量的相互协作的计算机驱动力是：
人们需要获得更高的计算性能。可以这么理解这一点，（大量的计算机意味着）大量的并行运算，大量CPU、大量内存、以及大量磁盘在并行的运行。
提供容错（tolerate faults）。比如两台计算机运行完全相同的任务，其中一台发生故障，可以切换到另一台。
一些问题天然在空间上是分布的。例如银行转账，我们假设银行A在纽约有一台服务器，银行B在伦敦有一台服务器，这就需要一种两者之间协调的方法。所以，有一些天然的原因导致系统是物理分布的。
人们构建分布式系统来达成一些安全的目标。比如有一些代码并不被信任，但是你又需要和它进行交互，这些代码不会立即表现的恶意或者出现bug。你不会想要信任这些代码，所以你或许想要将代码分散在多处运行，
这样你的代码在另一台计算机运行，我的代码在我的计算机上运行，我们通过一些特定的网络协议通信。
分布式系统的挑战：
会遇到并发编程和各种复杂交互所带来的问题，以及时间依赖的问题（比如同步，异步）。这让分布式系统变得很难。
大规模计算机导致小概率故障被无限放大。
不知道要多少计算机才能提高到我们需要的性能。
分布式系统的设计目标：
存储和计算希望通过设计一些简单的抽象接口，让第三方应用使用。就像一个文件系统或者一个大家知道如何编程的普通系统，并且有一个非常简单的模型语句。我们希望构建一个接口，它看起来就像一个非分布式存储和计算系统一样，但是实际上又是一个有极高的性能和容错性的分布式系统。
构建分布式的工具：
RPC、线程、锁
可扩展性：
最简单的提高性能是利用可扩展性，增加服务器数量。
利用两倍的计算机资源获得两倍的吞度量，按照某种稀疏增加用于解决问题的计算机数量，那么你就可以得到该系数的吞吐量和系统性能。
但是DB负载不可以太大，可扩展也有限。
当有N个web服务器访问同一个数据库，DB就会成为性能瓶颈，性能不会提高。
可能通过增加DB解决。
可用性：
当遇上故障，系统会继续运行，提供完好的服务。
因为错误总会发生，必须要在设计时就考虑，系统能够屏蔽错误，或者说能够在出错时继续运行。同时，因为我们需要为第三方应用开发人员提供方便的抽象接口，我们的确也需要构建这样一种基础架构，
它能够尽可能多的对应用开发人员屏蔽和掩盖错误。这样，应用开发人员就不需要处理各种各样的可能发生的错误。 （具体实现就是当发生错误，分布式系统内部有处理方案，不用上报告给应用开发人员）
实现方式举例：
构建了一个有两个拷贝的多副本系统，其中一个故障了，另一个还能运行。当然如果两个副本都故障了，你的系统就不再有可用性。
所以，可用系统通常是指，在特定的故障范围内，系统仍然能够提供服务，系统仍然是可用的。如果出现了更多的故障，系统将不再可用。
可恢复性：
当系统完全停用，修复完毕再恢复到停用前状态的能力。
实现工具:
非易失存储（non-volatile storage，类似于硬盘）,我们需要其记录一些数据和状态，当系统停用后读取相关内容恢复到停用前的状态。
问题：磁盘写入代价很高，要避免频繁读写。
复制（replication），不过，管理复制的多副本系统会有些棘手。任何一个多副本系统中，都会有一个关键的问题，比如说，我们有两台服务器，它们本来应该是有着相同的系统状态，现在的关键问题在于，这两个副本总是会意外的偏离同步的状态，而不再互为副本。
一致性：
一致性是一种“操作行为”的概念，他产生的原因是因为，多个副本服务器数据无法时刻保证完全统一。
一致性保证我们如何获取我们需要的值。
从性能和容错的角度来说，我们通常会有多个副本。在一个非分布式系统中，你通常只有一个服务器，一个表单。虽然不是绝对，但是通常来说对于put/get的行为不会有歧义。直观上来说，put就是更新这个表单，get就是从表单中获取当前表单中存储的数据。但是在一个分布式系统中，由于复制或者缓存，数据可能存在于多个副本当中，于是就有了多个不同版本的key-value对。假设服务器有两个副本，那么他们都有一个key-value表单，两个表单中key 1对应的值都是20。
现在某个客户端发送了一个put请求，并希望将key 1改成值21。这里或许是KV服务里面的一个计数器。这个put请求发送给了第一台服务器，之后会发送给第二台服务器，因为相同的put请求需要发送给两个副本，这样这两个副本才能保持同步。但是就在客户端准备给第二台服务器发送相同请求时，这个客户端故障了，可能是电源故障或者操作系统的bug之类的。所以，现在我们处于一个不好的状态，我们发送了一个put请求，更新了一个副本的值是21，但是另一个副本的值仍然是20。
如果现在某人通过get读取key为1的值，那么他可能获得21，也可能获得20，取决于get请求发送到了哪个服务器。即使规定了总是把请求先发送给第一个服务器，那么我们在构建容错系统时，如果第一台服务器故障了，请求也会发给第二台服务器。所以不管怎么样，总有一天你会面临暴露旧数据的风险。
强一致性：比如说get请求可以得到最近一次完成的put请求写入的值。
弱一致性：弱一致是指，不保证get请求可以得到最近一次完成的put请求写入的值。
因为强一致性实现代价很高，比如网络导致的延迟，所以弱一致性也是有使用场合的。
举例强一致性：人们希望将不同的副本放置在尽可能远的位置，例如在不同的城市或者在大陆的两端。这样，如果地震摧毁了一个数据中心，另一个数据中心中的副本有很大可能还能保留。我们期望这样的效果。但是如果我们这么做了，另一个副本可能在数千英里之外，按照光速来算，也需要花费几毫秒到几十毫秒才能完成横跨洲际的数据通信，而这只是为了更新数据的另一个副本。所以，为了保持强一致的通信，代价可能会非常高。因为每次你执行put或者get请求，你都需要等待几十毫秒来与数据的两个副本通信，以确保它们都被更新了或者都被检查了以获得最新的数据。现在的处理器每秒可以执行数十亿条指令，等待几十毫秒会大大影响系统的处理速度。
标签：副本,请求,系统,笔记,分布式系统,put,服务器,mit6.824 来源： https://www.cnblogs.com/thotf/p/16462518.html