Grpc 線程架構(gòu)

Execute_thrd: 公有線程误续，啟動(dòng)時(shí)負(fù)責(zé)啟動(dòng)監(jiān)聽飘哨，IO感局，其他任務(wù)尼啡；

Timer_thrd：負(fù)責(zé)執(zhí)行指定的定時(shí)任務(wù)（非周期性任務(wù)）暂衡；

Consumer_thrd：從Queue中取Event消費(fèi)。

網(wǎng)絡(luò)模型

Thread: 用戶Consumer線程崖瞭；

Completion_queue: Grpc Queue古徒，用來實(shí)現(xiàn)異步的事件隊(duì)列；

Pollset: 每個(gè)queue有個(gè)對(duì)應(yīng)的pollset读恃，用來從底層收集IO事件隧膘；

Polling island : 是pollset的一個(gè)邏輯單位，可以包含多個(gè)pollset寺惫；

Epoll set: 底層os對(duì)應(yīng)的epool set疹吃，OS內(nèi)核負(fù)責(zé)收活動(dòng)FD，底層epool的封裝（windows giops封裝）

Transport Explainer

在Grpc上的一個(gè)batch西雀，由幾個(gè)基本的stream ops組成萨驶。Batch是調(diào)度的基本單位。

Stream ops如下:

send_initial_metadata

Client: initate an RPC

Server: supply response headers

recv_initial_metadata

Client: get response headers

Server: accept an RPC

send_message (zero or more) : send a data buffer

recv_message (zero or more) : receive a data buffer

send_trailing_metadata

Client: half-close indicating that no more messages will be coming

Server: full-close providing final status for the RPC

recv_trailing_metadata: get final status for the RPC

Server extra: This op shouldn't actually be considered complete until the server has also sent trailing metadata to provide the other side with final status

cancel_stream: Attempt to cancel an RPC

collect_stats: Get stats

The fundamental responsibility of the transport is to transform between this internal format and an actual wire format, so the processing of these operations is largely transport-specific.

Transport負(fù)責(zé)內(nèi)部格式和網(wǎng)絡(luò)格式之間轉(zhuǎn)換艇肴。

One or more of these ops are grouped into a batch. Applications can start all of a call's ops in a single batch, or they can split them up into multiple batches. Results of each batch are returned asynchronously via a completion queue.

每個(gè)call的ops可以放到一個(gè)batch中腔呜，如果一部實(shí)現(xiàn)，會(huì)放到多個(gè)batch中再悼，每一個(gè)batch會(huì)返回completion queue一個(gè)Event核畴。

Internally, we use callbacks to indicate completion. The surface layer creates a callback when starting a new batch and sends it down the filter stack along with the batch. The transport must invoke this callback when the batch is complete, and then the surface layer returns an event to the application via the completion queue. Each batch can have up to 3 callbacks:

recv_initial_metadata_ready (called by the transport when the recv_initial_metadata op is complete)

recv_message_ready (called by the transport when the recv_message op is complete)

on_complete (called by the transport when the entire batch is complete)

上面三個(gè)回調(diào)函數(shù)，肯定會(huì)被執(zhí)行

一個(gè)batch可以分成這三個(gè)階段recv_initial_metadata冲九，recv_message_ready谤草，on_complete。

一個(gè)call的時(shí)序圖：

Client send_initial_metadata: Initiate an RPC with a path (method) and authority

Server recv_initial_metadata: accept an RPC

Client send_message: Supply the input proto for the RPC

Server recv_message: Get the input proto from the RPC

Client send_trailing_metadata: This is a half-close indicating that the client will not be sending any more messages

Server recv_trailing_metadata: The server sees this from the client and knows that it will not get any more messages. This won't complete yet though, as described above.

Server send_initial_metadata, send_message, send_trailing_metadata: A batch can contain multiple ops, and this batch provides the RPC response headers, response content, and status. Note that sending the trailing metadata will also complete the server's receive of trailing metadata.

Client recv_initial_metadata: The number of ops in one side of the batch has no relation with the number of ops on the other side of the batch. In this case, the client is just collecting the response headers.

Client recv_message, recv_trailing_metadata: Get the data response and status

模式處理

服務(wù)器端異步模式框架莺奸，添加自定義Event Queue增加并發(fā)性能