【问题标题】：Low-latency communication of micro-services in remote, IPC and threading scenarios远程、IPC和线程场景下微服务的低延迟通信
【发布时间】：2019-06-03 03:18:55
【问题描述】：

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

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

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

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

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

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

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

我的问题如下：

是否值得创建自定义 IPC/线程通信解决方案，还是应该从基于 TCP 的 localhost 通信开始？
谁能提供一些不同 IPC 技术（locahost tcp vs 管道 vs 共享内存）的性能比较结果，以获得最大 1kb 的小消息的最佳 RPS？（例如，共享内存将比 localhost 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

【问题讨论】：

很抱歉，但由于您发布了多个过于宽泛的问题，因此您很可能会得到“接近”的投票，而不是答案和建议。我会为所有 3 种类型选择“Asio”，并且只有在我遇到真实（而非假设的）性能问题时才进行实验/更改
我明白，但我希望有人遇到同样的权衡，进行调查或基准测试，并可以与我们分享他对该主题的专业知识。
我还建议检查 Actor 模型的任何良好实现，甚至考虑使用它而不是实现自己的框架。这可能是一项艰巨的任务
刚刚发现有趣的低级 IPC 基准测试（管道、unix 域套接字、tcp 套接字）-github.com/rigtorp/ipc-bench

标签： c++ performance ipc microservices low-latency

【解决方案1】：

你写道：

超快消息处理 C++ 解决方案

这通常意味着要亲力亲为。听起来像一个有趣的图书馆，但如果你把它拉下来。

总体而言，您的问题（方式）太宽泛了 - 不过这是我的想法：

在这里很难给出任何建议......
比较将特定于平台/系统。例如。 TCP 可能更快或更慢，具体取决于系统。
想到了OpenMP和boost interprocess。
您可能不想研究或开始使用例如 apache thrift 库（尽管它也是跨语言的 - 我相信最初是为 facebook 后端服务器开发的）您可能会做一些早期试验并获得感觉有些问题需要考虑。

【讨论】：