RPC and Threads

2015/2018 - Lecture 2

线程

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

程序中线程的数量

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

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

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

线程的挑战

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

  • 线程之间合作：

  • 并发的粒度：

    • 粗粒度：并发程度低，但容易处理

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

应用举例：爬虫

RPC

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

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

PreviousIntroduction and MapReduceNextPrimary/Backup Replication

Last updated