ZMQ通信模式:REQ-REP模式

一对一的场景

REQ-REP模式是阻塞式的,也就是说必须要client先发送一条消息给server,然后server才可以返回一个response给client。任何顺序上的错误都会导致报错。


ZMQ通信模式:REQ-REP模式_第1张图片

服务端代码

  • 首先是创建一个context
  • 之后创建一个新的socket,类型定义为ZMQ_REP,并把这个socket绑定到一个地址
zmq::context_t context (1);
zmq::socket_t socket (context, ZMQ_REP);
socket.bind ("tcp://*:5555");
  • 接下来就可以阻塞式的等待client发送消息
socket.recv (&message);
  • 处理完收到的消息后,返回一个response
zmq::message_t reply (5);
socket.send (reply);

客户端代码

  • 一上来也是创建context和socket,并连接到一个地址
zmq::context_t context (1
zmq::socket_t socket (context, ZMQ_REQ);

socket.connect ("tcp://localhost:5555");
  • 然后Client端就可以通过socket来发送消息
zmq::message_t request (5);
socket.send (request);
  • 消息发送成功后等待reply
zmq::message_t reply;
socket.recv (&reply);

之前演示的是一对一的通信场景,但是实际通信场景下,可能会有多个服务端或多个客户端的场景。

多个客户端对多个服务端

如下图演示的是一个一对多的例子,

  • client端可以绑定socket(客户端只有一个socket)到不同服务端的不同sockets(不同服务端的socket应该绑定了不同的地址)上
  • 接下来REQ socket就可以在这些server端分发请求了,比如说有R1/R2/R3/R4四个请求,R1/R4被发送到了service A处理。
  • 这种场景下添加新的client是方便的,你每添加一个client,只要把这个client和当前所有在工作的server的socket连接一下就好
  • 但是当server的负载不够,需要增加server的时候,问题就来了,相当于每个client端都要更新一下自己连接的socket。


    ZMQ通信模式:REQ-REP模式_第2张图片

在实际的应用场景中,这个系统维护起来显然不容易。
所以这个时候就引入了brocker

Broker

引入broker后,之前的问题解决了,当增加server端时,不需要修改所有的client端,只需要更新一下broker就好了。

ZMQ通信模式:REQ-REP模式_第3张图片

这里引入了两种新的socket类型,DEALER和ROUTER。

Open topics

  1. 消息的帧格式是怎样的?有空帧么?

你可能感兴趣的:(ZMQ通信模式:REQ-REP模式)