2017 6.824学习笔记 Lecture 2: RPC and threads

线程

• 线程是非常有用的构建工具
• 再Go中线程称为goroutines，其他语言中叫做线程
• 他们通常比较棘手

为什么使用线程？

• 允许利用并发，这在分布式系统中很自然的体现出来
• 再I/O并发中，允许在等待一个IO响应时，处理下一个请求
• 多线程可以平行运行在多核上

Thread = "thread of execution"

• 线程允许一个程序在逻辑上一次执行许多事情
• 线程间有共享内存
• 每个线程包含自己的运行状态：
• 程序计数器
• 寄存器
• 栈

一个程序会有多少个线程？

• 尽可能多的“有用的”线程在一个应用中
• Go鼓励创建更多的线程
• 通常线程数会大于CPU核心数
• Go的调度器将他们调度到可用的核心上
• Go的线程也时有损耗的，但他要比通常意义中创建一个系统线程要轻量

使用线程的挑战？

• 共享数据：e.g. 一个线程读数据同时另一个线程改变数据，将导致竞争条件
• 不要共享数据或者协调共享（使用互斥锁等）
• 线程间的协调：（e.g. 等待所有Map结束），导致死锁
• 使用Go的channel或者waitGroup
• 并发性的粒度
• 粗粒度：简单，较少的并发/并行
• 细粒度：更多的并发，但也有更多的竞争和死锁

远程过程调用（RPC）

概述

RPC是分布式系统中的一个关键机制

目标：轻易地编写网络通信

• 隐藏许多客户端/服务端之间的通讯细节
• 客户端调用就像普通的程序调用
• 服务端的处理程序非常像普通程序
• RPC使用非常广泛

理想中RPC让网络通讯就像函数调用一样：

  Client:
    z = fn(x, y)
  Server:
    fn(x, y) {
      compute
      return z
    }

RPC的目标就是这个水平的透明度

RPC 通信模型

  Client             Server
    request--->
       <---response

RPC 软件结构

Software structure
  client app         handlers
    stubs           dispatcher
   RPC lib           RPC lib
     net  ------------ net

一些细节：

• 那个服务函数去处理调用？
  • 在go中通过Call()
• 编码：格式化数据到网络包中
• 一些类型比较棘手，数组 指针 对象 引用等
• Go的RPC包很强大，但是一些类型不允许传输（channel function等）
• 绑定：客户端如何选择服务端？
• 可能是客户端写死
• 可能是有一个服务名称映射服务来选择最优的服务端

RPC的问题：失败如何处理？

例如丢包，网络故障，慢服务，服务端崩溃

从RPC的客户端角度失败是什么样子的？

• 客户端从未收到服务器端的响应数据
• 客户端不会知道服务端有没有接收到请求报文
• 故障可能发生在服务端回复响应之前

解决方案：

最简单RPC行为“最少一次”：
RPC库一直等待响应结果，如果规定时间内没有接收到，则重新发送这个请求。这样一直尝试很多次后，若一直没有收到响应，则返回错误给调用程序

Q：对于应用来说“至少一次”是很容易处理的吗？

A：问题举例

• 客户端发送从银行账户扣除10元钱的请求，可能会导致多扣钱；
• 向数据库的同一个key赋值，当出现网络超时，导致重发时，先发送的写操作可能后到达
• Put（“KEY1”，10）
• Put（“KEY1”，20）
• 期望结果为20，但结果可能为10

Q：什么场景下可以使用“至少一次”模型？

A：

• 重复操作是可以接受的，比如只读操作
• 若应用程序有自己的方法去应对重复写入问题时，可以使用

更好的RPC行为“最多一次”

想法：服务端RPC代码中检测重复的请求，返回之前的结果提单重新运行的操作

Q：如何检测重复操作？

A：客户端使用唯一ID在每个请求中，超时重新请求时使用相同的唯一ID

  server:
    if seen[xid]:
      r = old[xid]
    else
      r = handler()
      old[xid] = r
      seen[xid] = true

一些“最多一次”模型的难点：

1.如何保证唯一ID？
大的随机数?client的唯一地址？等

2.老的RPC结果最终是一定要删除（缓存RPC结果已保证“最多一次”）的
如何保证删除这些数据是安全的？

• 保证各客户端ID是不重的
• 方法1：每个RPC请求要保证之前的所有响应已经回复 像TCP通信中的SEQ ACK
• 方法2：只允许一个暂未结束的RPC请求，当seq+1到达时，删除掉<seq的数据
• 方法3：只保留一段时间内的请求，超过时间范围的都删除掉

3.如何解决重复请求到来时老的请求未产生结果？

• 增加等待标识，返回给RPC调用，由调用方决定等待还是忽略

当服务崩溃或者重启时怎么办？
副本信息在内存中，重启后这些信息会丢失，同时会接收到重复的请求在重启后

• 将往期结果（duplicate ）写入磁盘？
• 备用服务应该保存副本往期结果？

什么是恰好一次模型？

最多一次模型+无限重试+故障容忍服务

GO RPC库是 最多一次模型

• 打开TCP链接
• 写请求到这个链接
• TCP可能会重传，但是服务端的TCP会过滤掉这些重复数据
• 不会在Go的代码中重复
• 当Go RPC库没有获取到响应结果时会返回一个错误，这可能由以下原因导致：
• TCP超时
• 服务端没由看到请求
• 服务端执行了请求但返回结果前网络出现了故障