MIT6.5840 分布式系统笔记

课堂笔记

1.Mapreduce

2.The google file system

• 延迟删除，删除文件后不会立即删除，一般延迟3天删除
• 周期性发送心跳，删除过期副本（版本号不和master相同），同时检测副本的数量，少于规定值会进行副本复制。
• 并发追加时，客户端会将所有数据发送给所有副本，primary会按照顺序执行所有客户端的请求，并进行编号，其他副本按照primary的顺序执行请求，完成后发送给primary，报告请求完成（无需锁控制）。

写时复制（copy on write）：是一种计算机程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。

3.Vmware FT

复制状态机：只是复制指令操作，但这在多核的环境下难以进行，所以后面推出的服务应该是基于状态转移（通过将内存中的所有内容复制给副本），所以不做深究

4.Raft

5.Zookeeper

• 允许向副部发送读请求
• 保证写请求是有顺序的
• 同一个客户端的请求也是有顺序的（通过log的zxid来保证，比如客户端先向leader提交一个写请求，后向一个副本提交一个读请求，则读请求需要leader将写请求同步到副本提交后才能执行读请求）
• 写请求只能发送给leader

6.CRAQ（链复制）

一个链式的容错服务器，能够主动处理一些故障，同时能够加速读操作，但是无法解决网络分区问题，容易出现脑裂
假设next和head下一个节点 head不能和next通信 next不能和head通信 两边同时以为对方挂掉了 无法确定谁来担任head这时需要一个外部的权威机构 test_and_set来决定。 可以使用raft来当作系统的configure manager由CRAQ来担任请求的执行。

7.Aurora

• 一件可以学到的事情其实比较通用，并不局限于这篇论文。大家都应该知道事务型数据库是如何工作的，并且知道事务型数据库与后端存储之间交互带来的影响。这里涉及了性能，故障修复，以及运行一个数据库的复杂度，这些问题在系统设计中会反复出现。
• 另一个件可以学到的事情是，Quorum思想。通过读写Quorum的重合，可以确保总是能看见最新的数据，但是又具备容错性。这种思想在Raft中也有体现，Raft可以认为是一种强Quorum的实现（读写操作都要过半服务器认可）。
• 这个论文中另一个有趣的想法是，数据库和存储系统基本是一起开发出来的，数据库和存储系统以一种有趣的方式集成在了一起。通常我们设计系统时，需要有好的隔离解耦来区分上层服务和底层的基础架构。所以通常来说，存储系统是非常通用的，并不会为某个特定的应用程序定制。因为一个通用的设计可以被大量服务使用。但是在Aurora面临的问题中，性能问题是非常严重的，它不得不通过模糊服务和底层基础架构的边界来获得35倍的性能提升，这是个巨大的成功。
• 最后一件有意思的事情是，论文中的一些有关云基础架构中什么更重要的隐含信息。例如： 需要担心整个AZ会出现故障；
  1.需要担心短暂的慢副本，这是经常会出现的问题；
  2.网络是主要的瓶颈，毕竟Aurora通过网络发送的是极短的数据，但是相应的，存储服务器需要做更多的工作（应用Log），因为有6个副本，所以有6个CPU在复制执行这些redo
  3.Log条目，明显，从Amazon看来，网络容量相比CPU要重要的多。

8.Frangipani

一个分布式文件共享系统
锁服务：

• 工作站获取文件，必须现在petal中获得文件对应的锁，petal会将锁置为busy，工作站修改完后不会立即将内容返回给petal，而是继续缓存同时不会立即释放锁，并且petal中会将该文件的锁置为idle。
• 在工作站释放锁时，必须先将缓存中的数据返回给petal才能释放，同时petal中也将锁释放。
  释放锁步骤：
  1.首先，工作站需要将内存中还没有写入到Petal的Log条目写入到Petal中。
  2.之后，再将被Revoke的Lock所保护的数据写入到Petal。
  3.最后，向锁服务器发送Release消息。

9.分布式事务

分布式事务由并发控制和原子提交组成。两阶段锁是一个典型的应用（释放锁之后不能再加锁）。
它可以防止读到事务的中间状态，或者回滚之前的数据。

使用两阶段提交协议，由事务协调者来分发分布式事务，通过交互来完成分布式事务的原子执行。（由于存在大量的交互他的速度非常的慢）

10.比特币

工作量证明
传统共识协议：Paxos Raft，各个follewer都遵从leader执行相同的操作，不会违背leader的意志。

比特币中的共识协议：可能存在恶意节点进行冒充等等行为。

11.Spanner

简单介绍（还是挺复杂的 到现在还是晕晕乎乎的）

12.FaRM

13.Spark

14.Memcache