RPC and Threads

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