遠程、IPC、線程場景下微服務的低延遲通信

Question

我想創建一個超快速消息處理 C++ 解決方案，它將受 CPU 限制和基於微服務。 它將處理大量足夠小的請求/響應消息（每條消息 32 字節到 1kb）。

一些服務會被放置在不同的主機上。 有些將在同一主機上，但在不同的進程中。 還有一些在同一個進程里面，但是在不同的線程中。

目前我正在考慮這種服務拓撲的通信協議。 我的第一個想法是使用基於 TCP 的通信，它允許在同一主機上使用環回進行 IPC 通信，甚至用於線程通信。 好處是有一個單一的通信代碼，允許試驗服務拓撲。 在某些進程中托管服務或將其移動到遠程主機將很容易。

但是我明白，如果我想要一個具有最大 RPS 和消息傳遞速度的低延遲解決方案，我必須根據通信類型拆分傳輸：

• 線程通信- 使用循環緩沖區或LMAX Disruptor 模式可以獲得最佳結果。

• IPC 通信- 我認為共享內存中的管道或循環緩沖區是很好的解決方案。 有沒有更好的方法來做IPC？

• 遠程通信- 用於順序消息傳遞的異步 TCP 服務器/客戶端和用於多播的 UDP。

我也在考慮 Linux 解決方案，但擁有跨平台會很棒！

我相信Asio C++ 庫是遠程通信的一個很好的起點。

我的問題如下：

1. 是否值得創建自定義 IPC/線程通信解決方案，還是應該從基於 TCP 的本地主機通信開始？
2. 誰能為我提供不同 IPC 技術（locahost tcp vs 管道 vs 共享內存）的一些性能比較結果，以獲得最大 1kb 的小消息的最佳 RPS？ （例如，共享內存將比 localhost TCP 快 10 倍，比管道或近似 RPS 值快 3 倍以進行比較）。
3. 也許我錯過了一些我應該研究的好的低延遲 IPC/RPC 技術或庫？
4. 或者，對於我可以使用或購買許可證的問題，是否存在一些生產就緒的解決方案？

在此先感謝您的回答和建議！

---

工控機基准

我剛剛在 Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz) 下發現並執行了低級IPC 基准測試。 消息大小為 128 字節，消息計數為 1000000。我得到以下結果：

管道基准：

Message size:       128
Message count:      1000000
Total duration:     27367.454 ms
Average duration:   27.319 us
Minimum duration:   5.888 us
Maximum duration:   15763.712 us
Standard deviation: 26.664 us
Message rate:       36539 msg/s

FIFO（命名管道）基准：

Message size:       128
Message count:      1000000
Total duration:     38100.093 ms
Average duration:   38.025 us
Minimum duration:   6.656 us
Maximum duration:   27415.040 us
Standard deviation: 91.614 us
Message rate:       26246 msg/s

消息隊列基准測試：

Message size:       128
Message count:      1000000
Total duration:     14723.159 ms
Average duration:   14.675 us
Minimum duration:   3.840 us
Maximum duration:   17437.184 us
Standard deviation: 53.615 us
Message rate:       67920 msg/s

共享內存基准：

Message size:       128
Message count:      1000000
Total duration:     261.650 ms
Average duration:   0.238 us
Minimum duration:   0.000 us
Maximum duration:   10092.032 us
Standard deviation: 22.095 us
Message rate:       3821893 msg/s

TCP 套接字基准測試：

Message size:       128
Message count:      1000000
Total duration:     44477.257 ms
Average duration:   44.391 us
Minimum duration:   11.520 us
Maximum duration:   15863.296 us
Standard deviation: 44.905 us
Message rate:       22483 msg/s

Unix 域套接字基准測試：

Message size:       128
Message count:      1000000
Total duration:     24579.846 ms
Average duration:   24.531 us
Minimum duration:   2.560 us
Maximum duration:   15932.928 us
Standard deviation: 37.854 us
Message rate:       40683 msg/s

ZeroMQ 基准測試：

Message size:       128
Message count:      1000000
Total duration:     64872.327 ms
Average duration:   64.808 us
Minimum duration:   23.552 us
Maximum duration:   16443.392 us
Standard deviation: 133.483 us
Message rate:       15414 msg/s

Answer 1

也許我錯過了一些我應該研究的良好的低延遲IPC / RPC技術或庫？

美國大陸航空發布了IPC庫，該庫專注於在單個主機（使用共享內存）上或不同主機之間（使用udp組播）的低延遲和高帶寬數據傳輸。 它在Windows和Linux OS上運行。 在這里看看https://github.com/continental/ecal

Answer 2

你寫了：

超快速的消息處理C ++解決方案

這通常意味着需要掌握一切。 盡管聽起來很有趣，但最終聽起來像是一個有趣的庫。

總體而言，您的問題過於廣泛-盡管如此，這是我的想法：

1. 很難在這里給出任何建議...

2. 比較將針對特定平台/系統。 例如。 TCP可能更快或更慢，具體取決於系統。

3. OpenMP想到了OpenMP和boost interprocess 。

4. 您可能不需要研究或開始使用apache thrift庫（盡管它也是跨語言的-我相信它最初是為facebook后端服務器開發的），您可能需要做一些早期的嘗試，並可以考慮一些問題。