线程

线程的存在使得程序可以在逻辑上同时做许多事情。程序中的线程共享内存，同时也保存着自己的局部信息，包括程序指针 (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​