分布式之RPC

Remote Procedure Calls是一种Client/Server的通信，尝试使得远程调用过程(程序)如同调用本地的过程。

RPC基本介绍

RPC的目的:

1. 相对于网络编程来说有更好的抽象: 程序员可以很容易的调用一个远程的服务, RPC 的子系统能够处理格式, 发送和接收, 处理超时等。

2. 为了使大部分分布式透明: 某些故障不会在本地发生, 分布式和本地函数调用性能不同。

RPC不简单的原因:

1. 客户端和服务器是不同的机器, 可能有不同地址, 不同环境或者操作系统。

2. 必须转为本机表示的数据。

3. 机器和网络可能会失败。

分布式程序的基本架构:

RPC工作流程：

Stubs:

Client stub:

1. marshals:直译为“编排”， 在计算机中特 指将数据按某种描述格式编排出来，通常来说一般是从非文本格式到文本格式的数据转化。在rpc Client中指代将参数等转换为不依赖机器的形式(比如在WebService中，我们需要把java对象以xml方式表示并在网络间传输，把java对象转化成xml片段的过程就是marshal)。

2. 发送请求到服务器。

3. 等待回复。

4. unmarshals: 指marshal的逆过程, 得到结果然后返回给caller。

Server stub:

1. 逆编排参数, 然后建立一个栈框架。

2. 调用procedure。

3. Server stub编排结果然后发送这个回复。

Stubs&IDLs

RPC的stubs能够做到编排和反编排数据, 但是这需要我们使用IDL(interface defination language 接口定义语言)来实现, 转化为同一种对象, 例如我们就可以用JSON来进行编排和反编排。

RPC实现的两种风格:

1. 浅整合(shallow integration):

   需要使用到大量的库调用来set thing up: 如何格式化数据, 注册哪些函数以及如何调用它们.

2. 深整合(deep integration):

   根据类型的申明进行数据格式化, 几乎所有的object的公共方法都进行注册

RPC困难

三个分布式的特性使得透明化变得困难:

1. 内存的访问

2. 部分故障

3. 延迟

部分故障:

1. 在本地计算: 如果机器故障, 则应用故障

2. 在分布式的计算:如果机器故光, 则部分应用故障, 我们部分判断是机器故障和网络故障

使得部分故障对客户端透明:

实际的解决方案是破坏透明度:

1. 仅执行一次(Exactly-once):几乎不存在

2. 至少一次:仅用于幂等运算, 客户端保持重试直到得到response, 而服务器如往常一样处理请求.

3. 最多做一次: 即0次, 不知道或者1次. 服务器可能会收到同样的请求两次, 并且必须返回之前一次的回复且不会处理请求, 必须能够识别各个客户端的请求, 所以我们需要一个RPC ID的滑动窗口, 保证客户端RPC id的有序.

4. 零或者1次: 事务语义

实现RPC需要的考虑:

1. RPC作为一种通用的library, 性能是永远是一个很重要的考虑.

2. 主要的资源消耗: 拷贝还有编排/反编排

3. 可以尝试0拷贝技巧

4. 表达: 当我们以本地格式发送数据的时候, 需要在前面说明好我们用到的格式

5. Scatter-gather writes: 分散（scatter）从Channel中读取是指在读操作时将读取的数据写入多个buffer中。因此，Channel将从Channel中读取的数据“分散（scatter）”到多个Buffer中。聚集（gather）写入Channel是指在写操作时将多个buffer的数据写入同一个Channel，因此，Channel 将多个Buffer中的数据“聚集（gather）”后发送到Channel。scatter gather经常用于需要将传输的数据分开处理的场合，例如传输一个由消息头和消息体组成的消息，你可能会将消息体和消息头分散到不同的buffer中，这样你可以方便的处理消息头和消息体。

最后根据从cmu课程学到的以上我使用java手写了一个基于http的rpc框架，详情请见https://github.com/yyss1997/yyss1997-RPC

分布式之RPC

原文：https://www.cnblogs.com/zhilue/p/14057594.html