论文材料： https://pdos.csail.mit.edu/6.824/papers/spanner.pdf
Spanner是谷歌公司研发的、可扩展的、多版本、全球分布式、同步复制数据库。它是第一个吧数据分布在全球范围内的系统，并且支持外部一致性的分布式事务。Spanner实现了一个强大的时间API，用于实现非阻塞的读、不采用锁机制的只读事务和原子模式变更。
Spanner论文比较复杂，这里我结合课程，只重点讲述如何利用时间API完成分布式事务，包括读写事务和只读事务。
1 | http://loopjump.com/google_spanner/ |
本节介绍了分布式事务，如何进行并发控制和原子提交，主要是2PL和2PC。
2PL区别于简单锁，事务锁数量是动态增长的，并在事务commit或abort之后才能释放锁。2PC其实有3阶段，包括inform、prepare、commit阶段。每一阶段为了防止数据丢失都要进行Write Ahead Log操作。每个服务器也要维护各自的锁表单，用来记录当前锁被哪个事务持有。
本节介绍了一个事务的基本实现方式以及Aurora。
对于Aurora，值得注意的是6个副本3个中心的设计，以及Quorum的读写思想。还有就是违背抽象，设计耦合的日志专用存储能极大提升性能。
这节课主要介绍了链复制的基本思想以及链复制的改进（Chain Replication with Apportioned Queries，CRAQ）。
CRAQ通过引入版本机制以及clean/dirty状态机制来改进多个节点的分散读。当数据首次到达中间节点时，该数据会被标识为dirty；当数据达到tail节点时，数据标识为clean，并进行反向传播，使之前的节点也将该数据标识为clean。
Raft是一个分布式共识算法/协议，即让多台机器达成一致的算法。
Raft将共识问题分解为三部分：Leader选举、Log复制以及安全性设置(一致性设置）。
由于实验2完整复现了Raft协议，这里只挑一些重点讲。复现时应该着重考虑：节点崩溃又上线、不可靠网络。
这节课主要介绍了线性一致的概念与Zookeeper论文。
线性一致描述的是系统的行为，正确的行为是客户端发送了一个写请求并且收到服务端答复后，这个写请求能被之后的读请求看到。每个读请求看到的都是最新的写请求所作的更改。
Zookeeper论文是我接触到的最抽象的一篇论文。首先它的功能就很抽象：分布式协调内核。它提供的两个保证：线性写和FIFO客户端请求也费时间理解。最后则是它的API调用以及具体实现。
读这篇论文的原因我想一是Zookeeper的广泛使用，证明了其实用性；二是其“线性一致”的设计，契合课程。收获就是其API的设计、Watch模式。
这节课主要介绍分布式存储系统的难点以及论文GFS。
分布式系统出现的原因是人们想要利用更多的机器实现更好的性能，但更多的机器意味着故障的期望上升。解决单台机器故障最简单的办法就是多副本的容错机制，但多副本间需要时间同步。一致性难题意味着牺牲性能，这是个闭环，人们必须在性能和一致性上做取舍。
对于GFS的学习，我觉得首先要明白GFS应对的需求，整体的架构设计，然后就是读写过程，数据一致性，这是从使用层面上来说的。在高可用方面，GFS的备份管理、文件快照、崩溃恢复等细节需要再深入研究。
这节课主要介绍容错的主要手段——复制以及相应的论文：Fautl-Tolerant Virtual Machines。
这节课主要介绍Go语言以及用Go实现爬虫的例子。
MIT 6.824 课程第一节笔记，主要介绍了分布式系统的驱动力、难点、类型等，还介绍了MapReduce。