远程、IPC和线程场景中微服务的低延迟通信

Question

我想创建一个超快的消息处理C++解决方案，它将是基于CPU和微服务的。它将处理大量足够小的请求/响应消息(每条消息32字节到1kb )。

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

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

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

• 线程通信--使用循环缓冲区或LMAX分解模式可以获得最好的效果。
• IPC通信--我认为共享内存中的管道或循环缓冲区是很好的解决方案。有更好的方法来做IPC吗？
• 远程通信-异步TCP服务器/客户端用于顺序消息传递，UDP用于多播。

另外，我也在考虑Linux解决方案，但是拥有跨平台将是很棒的！

我认为Asio C++库是远程通信的良好起点。

我的问题如下：

1. 创建自定义IPC/线程通信解决方案值得吗?还是应该从基于TCP的本地主机通信开始？
2. 有谁能为我提供不同IPC技术(本地主机tcp与管道与共享内存)的一些性能比较结果，以获得1kb以下的最佳RPS？(例如，共享内存将比本地主机TCP快10倍，比管道或近似RPS值快3倍)。
3. 也许我错过了一些好的低关注度IPC/RPC技术或库，我应该去看看吗？
4. 或者，对于我的问题，我可以使用或购买许可证，这可能存在一些现成的解决方案吗？

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

IPC基准

我刚刚在Linux下找到并执行了低级IPC基准 (Linuxubuntu4.4.0 x86_64 i7-6700K4.00GHz)。消息大小为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

你写道：

一种超高速消息处理C++解决方案

这通常意味着要把手伸进所有的东西。听起来像一个有趣的图书馆，但在最后，如果你成功了。

总的来说，你的问题过于宽泛--尽管如此，以下是我的想法：

1. 在这里很难给出任何建议。
2. 比较将是特定于平台/系统的。例如：TCP可能更快，也可能更慢，这取决于系统。
3. 我想到了OpenMP和boost interprocess。
4. 您可能不想查看或开始使用apache thrift库(我相信它也是为facebook后端服务器开发的跨语言原版)，您可能会做一些早期的实验，并对一些需要考虑的问题有一种感觉。