远程、IPC、线程场景下微服务的低延时通信

Question

我想创建一个超快的消息处理 C++ 解决方案，它将 CPU 绑定并基于微服务。它将处理大量 request/response 足够小的消息（每条消息 32 字节到 1kb）。

有些服务会放在不同的主机上。有些将在同一台主机上，但在不同的进程中。还有一些在同一个进程中，但在不同的线程中。

目前我正在考虑此类服务拓扑的通信协议。我的第一个想法是使用基于 TCP 的通信，它允许在同一主机上使用环回进行 IPC 通信，甚至用于线程通信。好处是有一个单一的通信代码，允许试验服务拓扑。在某个进程中托管服务或将其移动到远程主机将很容易。

但是我知道，如果我想要一个具有最大 RPS 和消息传递速度的低延迟解决方案，我必须根据通信类型拆分传输：

线程通信 - 使用循环缓冲区或LMAX Disruptor pattern.
IPC 通信 - 我认为共享内存中的管道或循环缓冲区是很好的解决方案。有没有更好的IPC方式？
远程通信 - 异步 TCP server/client 用于顺序消息传递，UDP 用于多播。

我也在考虑 Linux 解决方案，但跨平台会很棒！

我相信 Asio C++ Library 是远程通信的良好起点。

我的问题如下：

是否值得创建自定义 IPC/threading 通信解决方案，或者我应该从基于 TCP 的本地主机通信开始？
任何人都可以为我提供一些不同 IPC 技术（本地主机 tcp 与管道与共享内存）的性能比较结果，以获得最大 1kb 的小消息的最佳 RPS 吗？（例如，共享内存将比本地主机 TCP 快 10 倍，比管道或近似 RPS 值快 3 倍以进行比较）。
也许我错过了一些我应该研究的好的低延迟 IPC/RPC 技术或库？
或者我的问题可能存在一些生产就绪的解决方案，我可以使用或购买许可证？

提前感谢您的回答和建议！

IPC 基准测试

我刚刚在 Linux (Linux ubuntu 4.4.0 x86_64 i7-6700K 4.00GHz 下找到并执行了低级 IPC benchmarks。消息大小为 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

您写道：

an ultra fast message processing C++ solution

这通常意味着掌握一切。最后听起来像是一个有趣的图书馆，如果你把它拉下来的话。

总的来说，你的问题（方式）过于宽泛 - 尽管如此，我的想法是：

这里很难给出任何建议...
比较将 platform/system 具体。例如。 TCP 可能更快或更慢，具体取决于系统。
OpenMP 和 boost interprocess。
你可能不想研究或开始使用例如 apache thrift 库（尽管它也是跨语言的——我相信最初是为 facebook 后端服务器开发的）你可能会这样做或许可以进行一些早期试验，了解一些需要考虑的问题。

远程、IPC、线程场景下微服务的低延时通信

Low-latency communication of micro-services in remote, IPC and threading scenarios

c++

performance

ipc

low-latency

microservices

IPC 基准测试