qq_52010229的博客

但T2在T1提交（实时）之后开始，因此外部一致性要求T2看到x=2。提交后，所有读取都应该看到我们的更新。如何确保如果读/写事务T1在只读事务T2开始之前结束，那么TS1 < TS2。T2选择TT.now().latest，这在当前时间之后，即在10之后。情景是T1提交，然后T2开始，T2必须看到T1的写入。我们希望T3看到T2的所有写入，或者一个也不看。一个读/只事务的读取看到的是事务时间戳时的版本。假设我们有两次银行转账，和一个读取两者的事务。没有锁，没有两阶段提交，没有事务管理器。

当您执行一些并发事务并产生结果时，“结果”既包括输出也包括数据库中的变化。存在一种串行执行事务的顺序，这种顺序产生的结果与实际执行的结果相同。（串行意味着一次一个——没有并行执行。（这个定义应该让你想起线性一致性。您可以通过寻找产生相同结果的顺序来测试执行结果是否是可串行化的。T1;T2T2;T1T1;T2;两者的结果不同；任何一种都可以接受。没有其他结果是可以接受的。实现可能已经并行执行了T1和T2，但它必须仍然产生如同按照串行顺序执行一样的结果。

在一段时间内，关于新创建文件的信息只存在于该工作站的缓存（RAM）中。第5节说，当Frangipani工作站释放读锁时，必须使缓存数据失效，并在释放写锁时将修改后的缓存数据写回Petal。如果一个工作站在系统调用完成后，但在发送相应的日志条目到Petal之前崩溃会发生什么？如果一个工作站在系统调用完成后，但在发送相应的日志条目到Petal之前崩溃会发生什么？如果： WS1持有一个锁，WS2认为WS1已经死亡，进行恢复，释放WS1的锁，如果WS1实际上是活着的，它随后能够尝试写入被锁定的数据吗？

由于头部和尾部的负载可能比中间节点的负载更高，可能出现性能受到头/尾限制的情况，但中间节点却有大量空闲CPU的情况。更好的方法是提前传输状态的快照，然后冻结系统的时间足够长，以发送最后几个更新到新尾部，然后重新配置并解冻，可能使用ZooKeeper的模糊快照概念。现在，假设三个链上的活动大致相等，那么三个服务器的负载也将大致相等。通过这样的布置，请求处理工作可能更加均衡，因为每个服务器参与了多个分片组，而且分片的大小相对较小。对于主/备份系统，服务器在一些组中是主服务器，在其他组中是备份服务器。

一旦旧协调器意识到会话已经失效，它可以创建一个新的会话，但此时它知道自己不再是协调器。因此，虽然可能存在一小段时间内的竞争情况，但在会话超时后，ZooKeeper会自动防止旧的协调器修改状态，确保新的协调器能够顺利被选举。写请求被转发到一个称为 leader 的服务器，其余的ZooKeeper服务器，称为Follower，它们从leader接收消息（主要是状态），并商定状态更改。使用 ZooKeeper ，我们能够实现我们的应用程序所需要的所有协调原语，即使只有写入是可线性化的。

由领导者调用以复制日志条目，同时也作为心跳信号，以维持权威并防止超时。您的日志中可能有与领导者日志不同的条目。因为#3 规定只有在存在冲突条目。：由候选者调用，用于在选举中收集选票。即使领导者没有发送任何条目，也。：所有服务器的共通行为规则。：追随者的特定行为规则。：候选人的特定行为规则。：领导者的特定行为规则。

在Go中实现这一点的一种方法是，领导者在每个迭代中都在一个单独的goroutine中发送AppendEntries RPC，以便领导者可以并发地发送RPC。简而言之，日志在分布式系统中的作用是有序地记录命令，确保一致性，防止丢失，并帮助系统在发生故障或重启后保持一致状态。多数投票的一个关键特性是，任意两个交集中的服务器都可以传达关于先前决策的信息，例如，另一个 Raft 领导者已经在这个任期内被选举出来。Raft 可以在缺失一个服务器的情况下继续运行，但是必须尽快修复失败的服务器，以避免降到少数派以下。

系统使用一个网络磁盘服务器，由主服务器和备份服务器共享（图 1 中的 “共享磁盘”）。如果主服务器或备份服务器认为另一台服务器已经死机，因此它应自行接管，那么它会首先向磁盘服务器发送“test and set”操作。如果主服务器或备份服务器中只有一个能与磁盘服务器通信那么只有这台服务器会启动。主系统（或备份系统）只有在 test-and-set返回true，主系统（或备份系统）才会接管（“上线”）。共享磁盘服务器必须可靠，如果磁盘服务器宕机，服务也会宕机，所以需要使用昂贵的容错磁盘服务器。

本文全面探讨了GFS的设计理念、架构细节、客户端交互模式以及其在解决实际问题中的表现，从而揭示其如何优雅地处理大规模数据集并支持高效的数据操作。通过学习GFS的设计和实践，我们可以获得对现代大规模分布式系统的深刻理解，这对于任何需要处理大数据的系统设计都是极其宝贵的经验。这些设计目标导致了GFS特有的架构选择，特别是其对数据的分片（sharding）、复制和延迟一致性的处理。客户端与GFS的交互主要包括文件的读取和写入操作，这些操作体现了GFS设计的效率和复杂性。

协程与线程的区别在于协程是完全在应用程序内 (低特权运行级) 实现的，不需要操作系统的支持，占用的资源通常也比操作系统线程更小一些。服务器最终必须丢弃旧RPC或者旧客户端的信息，何时丢弃是安全的，当原始请求仍在执行时，如何处理重复请求。事件驱动可以实现I/O并发，并且消除了线程的成本(可观)，但无法获得多核的速度，并且编程很麻烦。当线程并行执行的时候，如果内核数量少于可运行的线程数，运行时将抢先在线程之间分配内核。eg：每个客户端的请求。最简单的故障处理方案：“尽最大努力交付”的RPC。

Map分裂输出，通过哈希函数将其写入Reduce之前的预处理文件。每个Reduce任务从所有Map worker处获取其中间输出。Master将Map分配给worker，直到所有的Map完成。在所有的Map完成之后，Master分配Reduce任务。一个Master，负责向worker分配任务并记录进度。每个Reduce在GFS上写入一个单独的输出文件。Map将输出(中间数据)写入本地磁盘。worker崩溃后恢复的细节。MR如何最小化网络的使用。MR如何获得好的负载均衡。

mit6.824的lab1，实现MapReduce