pursuit的博客

分布式锁是微服务架构下解决并发资源竞争的关键机制，本质上是一种基于共识服务达成的临时独占契约而非传统锁。合格分布式锁必须满足互斥性、锁超时、容错性和可重入性四大条件。主流实现方案包括基于Redis的SETNX+LUA脚本（高性能但需处理复杂细节）、Zookeeper的临时有序节点（强一致性但性能较低）以及数据库乐观锁/悲观锁（简单但性能最差）。实际应用中还需解决锁续期、公平性、集群容错等挑战，需根据业务场景权衡选择合适方案。随着云原生发展，分布式锁技术仍在持续演进中。

本实验要求构建一个键 / 值存储系统，该系统能够将键 “分片” 或分区到一组副本组上。分片是键 / 值对的子集，例如所有以“a”开头的键可能是一个分片等，通过分片可提高系统性能，因为每个副本组仅处理几个分片的放置和获取，并且这些组并行操作。系统有两个主要组件：一组副本组和分片控制器。每个副本组使用 Raft 复制负责部分分片的操作，分片控制器决定每个分片应由哪个副本组服务，其配置会随时间变化。客户端和副本组都需咨询分片控制器来找到对应关系。系统必须能在副本组间转移分片，以平衡负载或应对副本组的加入和离开。

它考虑的是这样一个问题：系统在大部分时间下，分区都是平稳运行的，并不会出错，在这种情况下，系统设计要均衡的其实就是延迟与数据一致性的问题，为了保证数据一致性，写入与读取的延迟就会增高。CAP理论是分布式系统领域中被广泛讨论的一个理论，由 Eric Brewer 在 2000 年提出，一般系统架构师会把其作为衡量系统设计的准则，其中CAP是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）的缩写。CAP的一致性，关注的是数据一致性；

Bigtable 是 Google 设计的用于管理结构化数据的分布式存储系统，可扩展到数千台服务器存储 PB 级数据。它不是关系数据库，而是一种稀疏、分布式、持久性多维排序映射（K/V）。Bigtable被 60 多个 Google 产品使用，涵盖不同数据规模和延迟要求的应用，这得益于 BigTable 提供的简单数据模型可以使客户端动态控制数据的布局和格式。

Chubby是一个面向松耦合分布式系统的锁服务，被广泛应用于Google内部的多个关键系统中，如GFS（Google文件系统）和Bigtable。在GFS中，Chubby用于指定主服务器；而在Bigtable中，它不仅支持主服务器选举、帮助主服务器发现其所管理的子服务器以及协助客户端定位主服务器，还充当了少量元数据存储的角色。Chubby允许客户端同步活动并就环境基本信息达成一致。主要目标包括可靠性、对大量客户端的可用性以及易于理解的语义，吞吐量和存储容量是次要考虑因素。

例如，在下面这张图中：x初始值为0，client1发送put请求(x,1)，client2发送put请求(x,2)，并在put请求前后发送get请求，此时如果put请求因为超时不断重发，如果在client2的put请求之后才被应用，则导致最后client2读到的是1，RaftKV的结果也是1，这就违背了线性一致性。为单一服务器提供线性化相对容易，但如果服务是复制的，则较为困难，因为所有服务器必须为并发请求选择相同的执行顺序，避免使用过时的状态回复客户端，并在故障恢复时以保留所有确认的客户端更新为前提。

大型应用在分布式系统中遭遇多重挑战，如并发控制、故障恢复、网络不稳定及服务器时钟异步等。形式化验证则是一种严格确立系统正确性的方法，帮助处理边缘情况。租约是分布式系统中的关键技术，用于保证系统某方面在一定时间内不变，GFS、Chubby和DynamoDB都具有类似的机制。例如租约允许领导者高效执行只读查询，无需频繁验证自身领导权，然而，这一机制的有效性验证却是一项艰巨任务。

这篇论文介绍了ZooKeeper，一个用于协调分布式应用进程的服务。ZooKeeper旨在提供一个简单且高性能的内核，用于构建更复杂的客户端协调原语。它整合了组消息传递、共享寄存器和分布式锁服务的元素，形成了一个复制的、集中式的服务。Zookeeper提供了一个接口，具有共享寄存器的无等待特性和类似分布式文件系统缓存失效的事件驱动机制，以提供简单而强大的协调服务。ZooKeeper还保证了每个客户端请求的FIFO执行和所有更改ZooKeeper状态的请求的线性化。分布式系统中的基本协调机制配置。

此Raft结构体基于论文图2，基本上都是其中介绍的字段以及lab自带的字段，其中其他属性论文中也间接简述和支持，以确保Raft节点能够高效、稳定地运作。这些定时器对于触发关键的系统行为至关重要——选举定时器确保在必要时发起选举过程，而心跳定时器则维持着领导者与跟随者之间的连接，防止不必要的选举。然而，对于一个长期运行的服务来说，永远记录完整的 Raft 日志是不切实际的。论文的图 2 提到了哪种状态应该是持久的，即。这两个核心函数，前者负责保存Raft的状态，后者则是在Raft启动时恢复之前保存的数据。

Raft协议作为库（Library）存在于服务中，每个Raft副本包含应用程序代码和Raft库。应用程序代码处理RPC或其他客户端请求，Raft库负责同步多副本之间的操作。操作流程客户端请求：客户端发送请求（如Put或Get）到Raft集群的Leader节点。请求处理Raft层：Leader节点将请求操作传递给Raft层，要求将操作写入日志。Raft节点之间的交互确保操作被过半节点复制。当Leader节点确认过半副本都有操作的拷贝后，通知应用程序层执行操作。应用程序层。

分布式一致性共识算法指的是在分布式系统中，使得所有节点对同一份数据的认知能够达成共识的算法。且算法允许所有节点像一个整体一样工作，即使其中一些节点出现故障也能够继续工作。之前的大部分一致性算法实现都是基于Paxos，但Paxos难以理解和实现，为此作者开始寻找一种新的易于理解的一致性算法，Raft则是作者工作的产出。算法分解：Raft将核心功能模块化，分离出领导人选举、日志复制和安全性三个关键部分，使每个部分的逻辑更加清晰。状态空间缩减。

根据GFS论文的描述，客户端会选择一个在网络上最近的服务器（在Google的数据中心中，通过IP地址的差异可以判断网络位置的远近），然后将读请求发送到这个服务器。然后，如果它读取的记录与之前的记录具有相同的 ID，它就知道它们是彼此的重复项。如果服务器1（S1）先处理C1的请求，那么在它的表单里面，X先是1，之后S1看到了来自C2的请求，会将自己表单中的X覆盖成2。但是，如果S2恰好以不同的顺序收到客户端请求，那么S2会先执行C2的请求，将X设置为2，之后收到C1的请求，将X设置为1。

Google File System (GFS) 是一个可扩展的分布式文件系统，专为快速增长的Google数据处理需求而设计。这篇论文发表于2003年，此前已在Google内部大规模应用。GFS不仅追求性能、可伸缩性、可靠性和可用性等传统分布式文件系统的设计目标，还基于对自身应用负载情况和技术环境的深入观察，提出了独特的设计思路，与早期文件系统的假设明显不同。GFS 在设计的时候有一些假想，即预期要实现的目标。系统由许多廉价的普通组件组成，因此组件失效是一种常态。

类似的，我们可以画出 client 1，2 和 4 的，那么 client 2 的操作一定会在 4 的操作开始的后面，但这样我们就不能处理 client 3，它只可能合法的返回。但不幸的是，在测试一些分布式 key-value store 的时候，Knossos 并不能很好的工作，它可能只能适用于一些少的并发 clients，以及只有几百的事件的历史。上面的代码比较简单，但包含了足够的信息，包括初始状态是怎样的，内部状态是如何被操作的结果改变的，从 key-value存储里面操作返回的结果是怎样的。

对于并发的请求来说，返回的结果和最终状态都必须和这些操作顺序执行的结果一致。例如，如果一个客户端发起一个更新请求并从服务器获取了响应，随后从其他客户端发起的读操作可以保证能看到改更新的结果。如果存在，则表明该请求已经处理过，服务器可以跳过重复的处理，直接返回之前处理过的值。在本次 Lab 中，你将在单机上构建一个键/值服务器，以确保即使网络出现故障，每个操作也只能执行一次，并且操作是可线性化的。当然，还需要考虑一个问题，就是服务器会不断积压处理过的请求ID信息，所以我们需要快速释放服务器内存。

远程过程调用（RPC）是分布式系统中的关键技术之一，它使得客户端和服务器之间的通信变得简单而直观。在分布式系统中，不同的节点可能分布在不同的物理机器上，RPC允许这些节点之间进行远程通信，就像调用本地函数一样，无需了解底层的网络协议细节。RPC的目标是实现易于编程的客户端/服务器通信，它隐藏了底层网络通信的复杂性，为开发人员提供了简单的接口。通过RPC，开发人员可以专注于业务逻辑的实现，而无需担心网络通信的细节。

本次实验是实现一个简易版本的MapReduce，你需要实现一个工作程序（worker process）和一个调度程序（coordinator process）。工作程序用来调用Map和Reduce函数，并处理文件的读取和写入。调度程序用来协调工作任务并处理失败的任务。你将构建出跟MapReduce论文里描述的类似的东西。（注意：本实验中用"coordinator"替代里论文中的"master"。阅读MapReduce论文阅读lab文档理解MapReduce框架理解原框架代码，理清所需完成任务。

举例来说，如果一台计算机能够解决一定量的问题，那么增加第二台计算机后，系统能够以更快的速度解决相同数量的问题，或者在相同时间内处理更多的问题。这样，不同的用户可以访问不同的Web服务器，但它们需要访问相同的数据，因此所有的Web服务器都需要与后端数据库通信。因此，为了尽可能减少通信，特别是当副本相距很远时，人们会构建弱一致性系统，只需要更新最近的数据副本，并且只需要从最近的副本获取数据，并允许读取旧数据。然而，重构一个单一的数据库是困难的，尽管可以将数据库拆分为多个来提高性能，但这需要大量的工作。

当在一个足够大的 cluster 集群上运行大型 MapReduce 操作的时候，大部分的输入数据都能从本地机器读取，因此消耗非常少的网络带宽。用户可以控制操作的执行，并且可以将其限制在特定的。操作是输入确定性函数（即相同的输入产生相同的输出）时，MapReduce保证任何情况下的输出都和所有程序没有出现任何错误、顺序的执行产生的输出是一样的。MapReduce 模型的核心思想是将大规模的数据集分解成多个小的数据块，然后分配给集群中的多个计算节点进行并行处理，最终将结果合并成最终的输出。