MIT 6.5840-分布式系统 Lab2

2024-04-05 21:20

本文主要是介绍MIT 6.5840-分布式系统 Lab2,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

相关资料

Lab要求

总结
  • 如何保证只执行一次

    • 每次请求时携带一个token,用于标识请求

      // DoOnce 每次请求时携带
      type DoOnce struct {// 标识本次请求Token string
      }// GetToken 获取本次请求的标识符
      func (ck *Clerk) GetToken(operation string) string {return fmt.Sprintf("%s_%d", operation, nrand())
      }
      
    • server记录所有的token,对于put和append,先校验token是否存在,如果已存在,就不要再修改

      _, done := kv.tokenMap[token]
      kv.tokenMap[token] = struct{}{}
      return done
      
  • 如何确保相同append请求的返回值一致

    • 由于append请求需要返回修改前的值,那么存在这样一种情况,同一个append发送了两次,第一次先到,server修改了结果,在第二次append到达之前,server收到了put命令,此时第二次append返回的oldVal就会不正确,因此需要在server用一个map记录append命令的oldVal,其中key为每次append请求的token,value为某次请求对应的oldVal

    • 在执行append命令时额外做判断,如果此前已经执行过,就从appendMap获取oldVal,否则从cache中获取

      func (kv *KVServer) Append(args *PutAppendArgs, reply *PutAppendReply) {// Your code here.kv.mu.Lock()defer kv.mu.Unlock()oldVal := kv.m[args.Key]if !kv.judgeDone(args.Token) {kv.appendMap[args.Token] = oldValkv.m[args.Key] = oldVal + args.Value} else {oldVal = kv.appendMap[args.Token]}reply.Value = oldVal
      }
      
代码

https://github.com/Wonder-Forever/6.5840-2024/pull/7/commits/74dd50ec727952dd100a628b40cef866fb5aac48

知识补充
  • sync.Cond

    • sync.Cond 是 Go 语言中用于协调想要访问共享资源的多个 goroutine 的同步原语。它可以让一个或多个 goroutine 等待某个条件,而在条件达成时接收通知并继续执行

    • 使用方式

      // 创建一个 sync.Cond 实例。这通常通过传递一个已存在的锁(sync.Mutex 或 sync.RWMutex)给 sync.NewCond 函数来完成
      var mu sync.Mutex
      cond := sync.NewCond(&mu)// 在等待条件时,goroutine 需要首先获取锁,然后调用 cond.Wait() 方法。在调用 Wait() 之前,应该检查条件是否已经满足,如果不满足,则等待。Wait() 方法会自动释放锁,并阻塞当前 goroutine 直到收到通知。
      mu.Lock()
      for !condition { // 检查条件是否满足cond.Wait()
      }
      // 处理条件满足后的逻辑
      mu.Unlock()// 当条件发生变化,可能满足其他 goroutine 的等待条件时,应该发送通知。这可以通过 cond.Signal() 或 cond.Broadcast() 方法来完成。Signal() 唤醒等待 Cond 的一个 goroutine,而 Broadcast() 唤醒所有等待的 goroutine。
      mu.Lock()
      // 改变条件
      cond.Signal() // 或者 cond.Broadcast(),根据需要唤醒 goroutine
      mu.Unlock()
      
    • 注意:

      • 总是在锁的保护下使用 Wait(), Signal(), 和 Broadcast() 方法。
      • Wait() 方法在返回时会重新获取锁,因此不需要手动重新锁定。
      • 在发送通知之前,确保已经改变了条件,否则可能导致等待的 goroutine 再次进入等待状态。
      • 使用 Signal() 还是 Broadcast() 取决于你想唤醒多少等待的 goroutine。如果只需要唤醒一个,用 Signal();如果要唤醒所有等待的 goroutine,用 Broadcast()
      • 如果调用 Signal() 还是 Broadcast() 时如果没有等待的 goroutine,这个调用不会有任何效果,也不会报错或阻塞。当后续有 goroutine 调用 Wait 方法时,它将正常等待,直到下一次 SignalBroadcast 被调用。
  • 管道

    • 发送者可通过 close 关闭一个信道来表示没有需要发送的值了。接收者可以通过为接收表达式分配第二个参数来测试信道是否被关闭:v, ok := <-ch
    • 循环 for i := range c 会不断从信道接收值,直到它被关闭
    • 向已关闭的chan写数据会引发panic,向已关闭的chan读数据会先读取缓冲区的值,没有缓冲数据后会返回零值
    • select 语句使一个 Go 程可以等待多个通信操作,它会阻塞到某个分支可以继续执行为止,当 select 中的其它分支都没有准备好时,default 分支就会执行。

这篇关于MIT 6.5840-分布式系统 Lab2的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/878176

相关文章

分布式系统的个人理解小结

分布式系统:分的微小服务,以小而独立的业务为单位,形成子系统。 然后分布式系统中需要有统一的调用,形成大的聚合服务。 同时,微服务群,需要有交流(通讯,注册中心,同步,异步),有管理(监控,调度)。 对外服务,需要有控制的对外开发,安全网关。

分布式系统的主要考虑

异构性:分布式系统由于基于不同的网路、操作系统、计算机硬件和编程语言来构造,必须要考虑一种通用的网络通讯协议来屏蔽异构系统之间的禅意。一般交由中间件来处理这些差异。缺乏全球时钟:在程序需要协作时,它们通过交换消息来协调它们的动作。紧密的协调经常依赖于对程序动作发生时间的共识,但是,实际上网络上计算机同步时钟的准确性受到极大的限制,即没有一个正确时间的全局概念。这是通过网络发送消息作为唯一的通信方式

SpringCloud:构建分布式系统的利器

引言 随着云计算和微服务架构的兴起,传统的单体应用已经难以满足现代应用的高并发、高可用、可扩展等需求。SpringCloud,作为Spring生态中的微服务架构开发工具,通过提供一系列组件和框架,帮助开发者快速构建分布式系统。本文将详细介绍SpringCloud的概念、核心组件、以及如何使用SpringCloud来搭建一个简单的微服务应用。 SpringCloud简介 SpringCloud

分布式系统理论基础三-时间、时钟和事件顺序

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 现实生活中时间是很重要的概念,时间可以记录事情发生的时刻、比较事情发生的先后顺序。分布式系统的一些场景也需要记录和比较不同

分布式系统理论基础二-CAP

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 引言 CAP是分布式系统、特别是分布式存储领域中被讨论最多的理论,“什么是CAP定理?”在Quora 分布式系统分类下排

分布式系统理论进阶:选举、多数派和租约

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 选举(election)是分布式系统实践中常见的问题,通过打破节点间的对等关系,选得的leader(或叫master、co

分布式系统理论进阶 - Paxos

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 引言 《分布式系统理论基础 - 一致性、2PC和3PC》一文介绍了一致性、达成一致性需要面临的各种问题以及2PC、3PC

分布式系统理论进阶:Paxos变种和优化

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 引言 《分布式系统理论进阶 - Paxos》中我们了解了Basic Paxos、Multi Paxos的基本原理,但如果

分布式系统的一些基本概念

GitHub:https://github.com/wangzhiwubigdata/God-Of-BigData 关注公众号,内推,面试,资源下载,关注更多大数据技术~大数据成神之路~预计更新500+篇文章,已经更新50+篇~ 分布式 来自csdn,作者:陆小凤 进阶篇来自:bangerlee 作者对部分地方做了订正 目前这系列文章是网络上分布式

分布式系统:数据一致性解决方案

点击上方蓝色字体,选择“设为星标” 回复”资源“获取更多资源 大数据技术与架构 点击右侧关注,大数据开发领域最强公众号! 大数据真好玩 点击右侧关注,大数据真好玩! 在分布式系统中,随着系统架构演进,原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题,但业务实际又需要保障一致性,下面我从学习和实战运用总结一下分布式一致性解决方案。 1. CAP & Base理论  CA