C|分布式|RPC&NFS

Intro

随着单机性能进入瓶颈，storage与serve的压力与日俱增，因此，这两个职责被分布在不同服务器上。由于原本单机的文件访问变为跨服务器，因此NFS（Network File System）诞生了。

大存储服务器负责文件系统，应用服务器负责响应客户端

但是，如果我不想进行原本代码的修改，而想让通过网络进行的文件访问看起来如同之前本地的访问一样呢？我们现在一般使用RPC（Remote Procedure Call）在原有的单机文件系统上进行一层封装，使之成为NFS.程序员所面对的编程接口依然和往常的接口相同，而变化的仅仅是底层实现。

RPC

允许进程在远端执行而无需编码交互细节

我们使用Stub中间件隐藏通信的交互细节，真正的RPC通过Stub进行，而用户代码毫无察觉。

Stub隐藏了通信的细节，使得上层的调用无需修改

Client stub

• request中放置参数
• send requset to server
• 等待response

Service stub

• 等待message
• 获取request参数
• 进程调用
• response中放置结果与状态（success?/accecpted?）
• send respones to client

问题在于，message中应该放置什么，以下是一些比较重要的信息

当前的call的标识-Transaction ID

调用什么方法–Service ID (e.g., function ID)

身份认证-Auth Stuff

使用什么参数–Service parameter (e.g., function parameter)

由于引用失效，参数的再编排–Using marshal / unmarshal

//跨地址空间引用失效，因此需要进行序列化/反序列化（及处理网络通信的大小端）

Components

为了搭建一个RPC框架，我们需要

1.RPC格式标准（UDP or TCP or HTTP2？）

2.marshal / unmarshal工具库

3.Stub Generator：产生Stub

Client：marshal arguments, call, wait, unmarshal reply

Server：unmarshal arguments, call real function, marshal reply

4.Framework:

Client:

正确分发message到对应的server stub

跟踪所有发出去的请求

将收到的响应匹配到对应的call

多个caller共用一个socket

请求超时、重传的处理

Server:

对每个thread/callback正确分发reply（每个请求分配一个线程，或者请求多时维护线程池）

5.Binding：Client如何找到对应的Server

6.网络传输（如socket）

网络通信导致的Trade-off

1.性能开销（但不是传文本可以不用HTTP，会快些）

2.超时造成的额外问题

一旦发生超时，有这么几种解决方案，一般RPC使用第一或者第二

At Least Once：

重复resend，直到收到响应（但是可能会收到一堆响应）->要求调用无副作用

At Most Once：

重复resend, Server只保留一个request而忽略重复进行处理 -> 要求幂等性，多次调用如一

Exactly Once：

难以实现（没学）

3.错误隔离（C/S崩溃不影响彼此）

NFS

eg: mount –t nfs 10.131.250.6:/nfs/dir /mnt/nfs/dir

在应用程序调用文件系统接口时，NFS的所有调用如下。

NFS顺序图

值得注意的几点

fd<-->fh (file handler)

和下面Server无状态有关，而fd在Client内存中。因此传递对Server有用的fh，内含：

• file system ID
• inode number（path name可能会被rename）
• generation number-维护一致性（如果inode被删除后，又被复用number）

NFS Server并没有open/close

Server stateless，状态由Client维护（即使Server崩溃重启，由于无状态，依然能处理request）

回传file attributes

维护Client上的metadata

Cache

Server Reply Cache：

由于网络传输延迟或丢包，Client可能重复request，因此根据Transaction ID建立Cache。这样重复的request可以返回相同的响应。

Client Cache：

存储一些最近使用的vnode（virtual node），attributes，blocks。减少RPC延迟。

Cache coherence ：

Read/write：

与单机不同，无法保证获取最新数据，自行负责解决

Close-to-open：

open时获取modified time，与cache中进行比较，更新到最新数据。

close时写回（类似于cache被淘汰时写回内存）

左图中：C2open时能获取最新的数据

右图中：C2open时，由于C1未close，因此open时没有更新，因此read脏数据。

由于上述情况，一般需要另外进行并发的处理，例如对文件加锁。

Vnode

虚拟化

把文件属于local还是remote抽象化，左侧的箭头可以指向NFS client，也可能指向Local file system，从而让程序员忽视了实现细节。

GFS(Google FS）

随着规模的增大，单文件服务器也无法承受了。为了scalable，GFS使用一个服务器作为转发，多个文件服务器进行数据传输。这里的核心架构在于，将控制流和数据流解耦。

Flat Namespace

尽管namespace看起来有树形结构，实际上并没有directory，而是把整个路径映射到chunk上（因为目录访问需要多次访问chunk，而网络传输的开销远高于硬盘）

GFS Cluster

Single Master

内存中维护metadata（没有inode，没有symlink，没有hard link）

使用前缀编码进行压缩（每个entry小于64bytes）

• namespace
• 访问控制
• 映射表
• chunk的位置

Multiple Chunkserver

存储数据（chunk64mb）

传送heartbeat信息（如果崩溃了，需要让master保持同步）

Cache

Client和Chunkserver没有数据的cache（因为chunk的容量很大），但是Client有chunkserver的cache，下次访问可以不通过master。

（由master进行lease，进行临时的权限移交）

Fault Tolerance

Chunkserver

在这里使用三备份，当三个备份都写入完成后再进行response。三个buffer一般不会同时崩溃，所以写入buffer后就可以视为写入完成。

对于每个chunk产生32bit的checksum

定期扫描罕用文件，检查一致性

Master

• 对于所有metadata修改log
• shadow master
• 状态在多机器冗余存储

Typical Workload

搜索引擎特点

大的流读取+小的随机读取（因此适合这种大chunk）

大量顺序写操作（append），先前爬取的数据较少修改

多client同时append一个文件（因此没有什么对已有内容的修改，写方面不追求效率）