linux文件删除原理

要实施微服务，首先要搞定RPC框架，RPC框架分为客户端部分与服务端部分：

RPC client的部分又分为：
(1) 序列化和反序列化部分；
(2) 发送字节流和接收字节流部分；
这里主要讨论发送字节流与接收字节流。

客户端调用又分为同步调用和异步调用，
同步调用的代码片段为：
Result = Add(Obj1, Obj2); //得到Result之前处于阻塞状态
异步调用的代码片段为：
Add(Obj1, Obj2, callback);//调用后直接返回，不等结果，处理结果通过回调得到：
callback(Result) { //得到处理结果后会调用这个回调函数
…
}

1 RPC client同步调用

所谓同步调用，在得到结果之前，一直处于阻塞状态，会一直占用一个工作线程，上图简单的说明了一下组件、交互、流程步骤。

上图中的左边大框，就代表了调用方的一个工作线程；
左边粉色中框，代表了RPC-client组件；
右边橙色框，代表了RPC-server；
蓝色两个小框，代表了同步RPC-client两个核心组件，序列化组件与连接池组件；
白色的流程小框，以及箭头序号1-10，代表整个工作线程的串行执行步骤：
(1) 业务代码发起RPC调用，Result=Add(Obj1,Obj2)
(2) 序列化组件，将对象调用序列化成二进制字节流，可理解为一个待发送的包packet1
(3) 通过连接池组件拿到一个可用的连接connection
(4) 通过连接connection将包packet1发送给RPC-server
(5) 发送包在网络传输，发给RPC-server
(6) 响应包在网络传输，发回给RPC-client
(7) 通过连接connection从RPC-server收取响应包packet2
(8) 通过连接池组件，将conneciont放回连接池
(9) 序列化组件，将packet2反序列化为Result对象返回给调用方
(10) 业务代码获取Result结果，工作线程继续往下走

RPC框架需要支持负载均衡、故障转移、发送超时，这些特性都是通过连接池组件去实现的，连接池组件如下：

典型连接池组件对外提供的接口为：
int ConnectionPool::init(…);
Connection ConnectionPool::getConnection();
intConnectionPool::putConnection(Connection t);

INIT
和下游RPC-server(一般是一个集群)，建立N个tcp长连接，即所谓的连接池；

getConnection
从连接池中获取一个连接，加锁(置一个标志位)，返回给调用方；

putConnection
将已分配的连接放回连接池中，解锁(也是置一个标志位)；

如何实现负载均衡？
连接池中建立了与一个RPC-server集群的连接，连接池在返回连接的时候，需要具备随机性；

如何实现故障转移？
连接池中建立了与一个RPC-server集群的连接，当连接池发现某一个机器的连接异常后，需要将这个机器的连接移除掉，返回正常的连接，在机器恢复后，再将连接添加回来；

如何实现发送超时？
因为是同步阻塞调用，拿到一个连接后，使用带超时的send/recv即可实现带超时的发送和接收；

总的来说，同步RPC-client的实现是相对容易的，序列化组件、连接池组件配合多工作线程数，就能够实现。

2 RPC client异步调用

所谓异步回调，在得到结果之前，不会处于阻塞状态，理论上任何时间都没有任何线程处于阻塞状态，因此异步回调的模型，理论上只需要很少的工作线程与服务连接就能够达到很高的吞吐量。

上图中左边的框框，是少量工作线程(少数几个就行)进行调用与回调；
中间粉色的框框，表示RPC client组件；
右边橙色框，表示RPC Server；
蓝色六个小框，表示RPC client六个核心组件：上下文管理器，超时管理器，序列化组件，下游收发队列，下游收发线程，连接池组件；
白色的流程小框，以及箭头序号1-17，表示整个工作线程的串行执行步骤：
(1) 业务代码发起异步RPC调用，Add(Obj1, Obj2, callback)；
(2) 上下文管理器，将请求、回调、上下文存储起来；
(3) 序列化组件，将对象调用序列化为二进制字节流，可以理解为一个待发送的包Packet1；
(4) 下游收发队列，将报文放入"待发送队列"，此时调用返回，不会阻塞工作线程；
(5) 下游收发线程，将报文从待发送队列中取出，通过连接池组件获取一个可用的连接connection；
(6) 通过连接connection将报Packet1发送给RPC server；
(7) 发送包在网络传输，发给RPC server；
(8) 响应包在网络传输，发回给RPC client；
(9) 通过连接connection从RPC server收取响应包Packet2；
(10) 下游收发线程，将报文放入已接收队列，通过连接池组件，将connection放回连接池；
(11) 下游收发队列里，报文取出，此时回调将要开始，不会阻塞工作线程；
(12) 序列化组件，将Packet2反序列化为Result对象；
(13) 上下文管理器，将结果回调，上下文取出；
(14) 通过callback回调业务代码，返回Result结果，工作线程继续往下走；
如果请求长时间不返回，处理流程为：
(15) 上下文管理器，请求长时间没有返回；
(16) 超时管理器拿到超时的上下文；
(17) 通过timeout_cb回调业务代码，工作线程继续执行；

为什么需要上下文管理器？
由于请求包的发送，响应包的回调是异步的，甚至不在同一个工作线程中完成，需要一个组件来记录一个请求的上下文，把请求-响应-回调等一些信息匹配起来。

如何将请求-响应-回调这些信息匹配起来？
这是一个很有意思的问题，通过一条连接往下游服务发送了a，b，c三个请求包，异步的收到了x，y，z三个响应包：

(1) 如何知道哪个请求包对应哪个响应包？
(2) 如何知道哪个响应包与哪个回调函数对应？
是通过请求ID来实现请求-响应-回调的关联

整个处理流程如上，通过请求id，上下文管理器来对应请求-响应-callback之间的映射关系：
(1) 生成请求id；
(2) 生成请求上下文context，上下文中包含发送时间time，回调函数callback等信息；
(3) 上下文管理器记录req-id与上下文context的映射关系；
(4) 将req-id打在请求包里发给RPC-server；
(5) RPC-server将req-id打在响应包里返回；
(6) 由响应包中的req-id，通过上下文管理器找到原来的上下文context；
(7) 从上下文context中拿到回调函数callback；
(8) callback将Result带回，推动业务的进一步执行；

如何实现负载均衡，故障转移？
与同步的连接池思路相同。不同在于，同步连接池使用阻塞方式收发，需要与一个服务的一个ip建立多条连接，异步收发，一个服务的一个ip只需要建立少量的连接(例如，一条tcp连接)；

如何实现超时发送与接收？
同步阻塞发送，可以直接使用带超时的send/recv来实现，异步非阻塞的nio网络报文收发，如何实现超时接收呢？(由于连接不会一直等待回包，那如何知晓超时呢？)这时，超时管理器就上场啦。

备注：
对端正常close socket，或者进程退出(正常退出或崩溃)，对端系统正常关闭
这种情况下，协议栈会走正常的关闭状态转移，使用epoll的话，一般要判断如下几种情况：

• 处理可读事件时，在循环read后，返回结果为0；
• 处理可写事件时，write返回-1，errno为EPIPE；
• EPOLLERR或EPOLLHUP事件

对端非正常断开，比如服务器断电，网线被拔掉这种情况下，协议栈无法感知，select和epoll监测不到，SO_KEEPALIVE这个选项的超时事件太长并不实用，一般还是以应用层的heartbeat来及时发现
异常情况主要有：
(1) 服务器主机突然断电，TCP连接的双方都没有向对方发送数据；
(2) 服务器主机网线被拔出，TCP连接的双方都没有向对方发送数据；

超时管理器

超时管理器，用于实现请求回包超时回调处理。
每一个请求发送给下游RPC server，会在上下文管理器中保存req id与上下文的信息，上下文中保存了请求很多相关信息，例如req id，回包回调，超时回调，发送时间等。超时管理器启动timer对上下文管理器中的context进行扫描，看上下文中请求发送时间是否过长，如果过长，就不再等待回包，直接超时回调，推动业务流程继续往下走，并将上下文删除。如果超时回调执行后，正常的回包又到达，通过req id在上下文管理器里找不到上下文，就直接将请求丢弃（因为已经超时处理过了）。

异步回调和同步回调相比，除了序列化组件和连接池组件，会多出上下文管理器，超时管理器，下游收发队列，下游收发线程等组件，并且对调用方的调用习惯有影响(同步->回调)。异步回调能提高系统整体的吞吐量，具体使用哪种方式实现RPC client，可以结合业务场景来选取(对时延敏感的可以选用同步，对吞吐量敏感的可以选用异步)。

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至yj.mapple@gmail.com