RPC and Threads

2015/2018 - Lecture 2

线程

线程的存在使得程序可以在逻辑上同时做许多事情。程序中的线程共享内存,同时也保存着自己的局部信息,包括程序指针 (PC),寄存器,栈等。

程序中线程的数量

  • 由程序的功能结构决定:如 Web 服务器

  • 由 CPU 的核数决定:最大化并行

  • 由 I/O 决定:最大化吞吐量

线程的挑战

  • 数据共享:竞争条件 (Race Condition)

  • 线程之间合作:

  • 并发的粒度:

    • 粗粒度:并发程度低,但容易处理

    • 细粒度:并发程度高,但容易产生更多的竞争和死锁

应用举例:爬虫

RPC

RPC 的目的在于:让远程调用看起来就像本地方法调用一样。但实践起来并不简单。

RPC 架构

图1 - RPC 架构

执行细节

  • Marshalling: 将 RPC 调用的函数名、参数放到数据包 (packets) 中

  • Binding: 客户端绑定 RPC 服务端的过程

    • 使用服务器的域名和端口

    • 服务发现配置

实现举例:Toy RPC

问题与解决方案

RPC 调用过程可能出现哪些问题?

  • 丢包

  • 断网

  • RPC 服务器响应慢

  • RPC 服务器宕机

这些问题在客户端上的 RPC Lib 眼中的样子

  • 永远得不到请求的结果

  • 甚至不知道究竟是服务器的问题还是网络的问题

解决方案1:At Least Once/Best Effort

做法:在服务器未响应后重试几次,若仍如此则返回错误。 缺点:有写操作存在时可能出现竞争条件 结论:只能在读或幂等操作的情况下使用

思考实验:假设客户端执行

Put("k", 10);
Put("k", 20);
Get("k");

可能会出现哪些结果?

解决方案2:At Most Once

做法:RPC 客户端发送请求时为每个请求附加唯一的 xid, 服务端根据 xid 检测重复请求,检测成功后直接返回之前缓存的结果,伪代码如下所示:

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

思考实验:

  • 如何保证 XID 的唯一性?

    • 大随机数

    • ip + sequence number

  • 服务端如何清理不必要的缓存?

    • TCP

  • 当前请求还在执行时,又接收到相同的请求?

    • pending flag

    • 等待或者忽略

  • RPC 服务器崩溃重启?

    • 持久化数据

例子:Go RPC

  • 建立 TCP 连接,调用请求通过 TCP 传输

  • Go RPC 不重发请求,因此服务器不会看到重复请求

  • Go RPC 得不到回复直接返回错误

解决方案3:Exactly Once

At Most Once + 无限重试 + 能够容错的 RPC 服务

应用举例:KV

参考

course note 2015, 2018, toy RPC, crawler, kv Youtube video 2015