代码之家  ›  专栏  ›  技术社区  ›  chronoxor

远程、工控机和线程方案中的微服务低延迟通信

  •  -1
  • chronoxor  · 技术社区  · 6 年前

    我想创建一个超高速消息处理的C++解决方案,它将是CPU绑定和微服务的基础。它将处理大量足够小的请求/响应消息(每个消息32字节到1KB)。

    某些服务将放置在不同的主机中。有些将在同一主机上,但在不同的进程中。一些在同一进程中,但在不同的线程中。

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

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

    • 线程通信 -使用圆形缓冲器或 LMAX Disruptor pattern .

    • 工控机通信 -我认为共享内存中的管道或循环缓冲区是很好的解决方案。有没有更好的方法来做工控机?

    • 远程通信 -异步TCP服务器/客户端用于顺序消息传递,UDP用于多播。

    另外,我也在考虑Linux解决方案,但是拥有跨平台将是非常棒的!

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

    我的问题如下:

    1. 是否值得创建自定义的IPC/线程通信解决方案,或者应该从基于TCP的本地主机通信开始?
    2. 有人能为我提供一些不同的IPC技术的性能比较结果吗(locahost tcp vs pipes vs shared memory),以获得最高1Kb的小消息的最佳RPS?(例如,共享内存将比本地主机TCP快10倍,比管道或要比较的近似RPS值快3倍)。
    3. 也许我错过了一些好的低格工控机/RPC技术或我应该研究的库?
    4. 或者可能存在一些针对我的问题的生产就绪解决方案,我可以使用或购买许可证?

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


    IPC基准

    我只是发现和执行低水平 IPC benchmarks 在Linux(Linux Ubuntu 4.4.0 x86_64 i7-6700K 4.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
    

    FIFOS(命名管道)基准:

    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
    
    1 回复  |  直到 6 年前
        1
  •  0
  •   darune    6 年前

    你写道:

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

    这通常意味着把手伸进每件事。不过,如果你把它拔掉的话,这听起来就像是一个有趣的图书馆。

    总的来说,你的问题太宽泛了——不过我的想法是:

    1. 在这里很难给出任何建议…

    2. 比较将是特定于平台/系统的。TCP可能更快或更慢,这取决于系统。

    3. OpenMP boost interprocess 浮现在脑海中。

    4. 例如,你可能不想调查或开始调查 apache thrift 图书馆(尽管它也是跨语言的——我相信它是为Facebook后端服务器开发的原始版本),您可能会做一些早期的试验,并对一些需要考虑的问题有一些感觉。