Infrastructure: Rpc and threads
Why Go?
关注于分布式问题本身，而不是别的。
go 支持 concurrency，RPC，GC，type safe。
go 简单
Why Thread？
利用并发， I/O 并发，多核
Thread = “Thread of excution”
线程让程序同时执行多个事情(逻辑上)
共享内存
每个线程自己的状态: programe counter，register，stack
Threading challenges:
- 竞态
- 死锁
- 粒度:
- 粗粒度: 简单，更低的并发/并行。
- 细粒度: 更高并发，更多的竞态和死锁
RPC
目标: 简化进程间网络通讯
- 隐藏 client/server 间通讯细节
- client 调用像不同的过程调用
- server 处理像不同过程
RPC problem: lost packet, broken network, slow server, crashed server
发生下列错误时 client RPC库如何反应?
- client 永远看不到回应
- client 不知道 server 是否收到请求
“at least once” 行为:
- RPC libray 等待一段时间
- 如果没有回应，再次发送请求
- 等待，如果还是没有回应，返回错误给应用
“at least once” 问题:
Put("k", 10)
Put("k", 20)
“at least once” 对只读操作或应用本身处理了重复请求是 OK 的
“at most once” 更好的行为:
-
server RPC 处理重复的请求，返回原来的回复，代替重新运行
-
client 请求中包含 unique ID(XID)
if seen[xid]: r = old[xid] else: r = handler() old[xid] = r seen[xid] = true
“at most once” 复杂问题:
- 如何确保 XID 唯一？
- 什么时候丢弃旧请求的信息是安全的？
- 每个 client 一个唯一的 ID。
- 每个 client 端递增 RPC 请求的序列号。
- client 每次请求包含 “seen all replies <= X”。
- much like TCP sequence #s and acks 。
- 或只允许 client 同时只有一个未处理的 RPC 请求，当 seq +１到达是丢弃所有 <= seq 的请求信息。
- 或 client 同意重试只在 5 分钟内的请求, server 可以丢弃 5 分钟的请求信息。
- 怎么处理重复的 seq 当原来的请求还在处理中时？
- 添加 pending 标记对每个 RPC 请求； 等待或忽略。
“at most once” server 崩溃和重启如何处理?
- 如果 duplicate info 在内存中，重启后会接受重复的请求。
- 持久化到 disk?
- 复制 server 的同时也复制 duplicate info？
什么是 “exactly once”?
- at-most-once + 无限制 retries + fault-tolerant service
- Lab 3
Go RPC is “at-most-once”
