zeromq-使用笔记

27

基础

  1. 客户端可以在服务端没有监听端口 (bind)时,直接创建连接,这会在服务端开始监听端口时自动连接并传输消息
  2. 已经创建过的连接,如果中途中断,会自动重连
  3. 一个服务端 socket 可以监听多个不同的地址,端口不同甚至协议不同
  4. socket 内部有 IO 线程,send 函数返回时,消息并不一定已经发出了,有可能还在队列里等待
  5. 每创建一个 context 对象都会隐式创建一个 IO 线程
  6. C 需要库中处理字符串时 不/不应该 发送空终止字符,所以需要在接收字符串数据后,手动追加空终止字符
  7. zmq_send/zmq_recv 和 zmq_msg_send/zmq_msg_recv,主要区别在于是否需要调用者提供 msg 结构体对象,前者不需要,会自动将数据封装到一个默认的 msg 对象中
  8. 使用 ZMQ_SNDMORE 参数发送多块消息体,当对端接收到数据时,其实肯定已经接收到了所有消息体,但仍旧需要调用多次 get_socketopt + zmq_recv 接口,读取出来所有消息体数据
  9. 使用 zmq_poll(理解参考 linux poll 或 python 协程 异步 IO)相关接口,可以实现同时处理多个 socket 的 send/recv

上下文 Context 对象

  1. 程序一般都以创建 context 开始
  2. 一个进程通常应该创建并使用一个 context 对象
  3. 也有创建多个 context 对象的场景,这相当于拥有多个独立的 zqm 实例,并且要注意销毁所有 context 对象

请求-响应 模式(REQ-REP)

  1. 服务端一般使用 响应 REP 类型的 socket
  2. 客户端一般使用 请求 REQ 类型的 socket
  3. REQ 必须遵守 send-recv 配对规则,先请求并且得到响应后,再发起下一个请求,打乱顺序会报错;REP 同样但它先 recv 再 send
  4. 理论上可以有 N 多个客户端连接到服务端,同时连接都没问题
  5. 这个模式和常见的 CS/BS 模式很类似
  6. 多个 REQ 连接到一个 REP 时,从逻辑上来看 REP 端的消息处理流程是同步的,必须要等到当前已接收消息处理完毕并回复对端后,才能去接收处理下一个 REQ 请求,其他 REQ 请求都在阻塞
  7. 一个 REQ 可以连接到多个 REP 对端,请求会被负载均衡得发送到多个 REP 端
  8. REQ 和 REP 在概念上可以认为是基于 Router-Dealer 实现的,内部自动处理了信封,上层应用不会看到信封(包括空帧),只会看到数据
  9. 当 REQ 直接与 REP 连接时,底层/内部使用的信封是最简单的格式,没有 地址标识帧,只有空帧+数据帧
  10. 当 REQ 和 REP 中间加入了 Router-Dealer 作为代理层时,REP 收到的数据包含了 地址标识帧 + 空帧 + 数据帧
  11. REP 会认为从第一帧开始直到空帧为止都是信封帧,所以当 REQ 直接与 REP 连接时即便没有地址帧,也需要有空帧,这是为了兼容 Router-Dealer 作为代理时的情况
  12. REP 在收到消息时,会保存此消息的信封,在回复消息时会自动在把信封加在数据帧前面;由于 REP 必须遵守 请求-响应 配对规则,所以在回复消息时肯定是知道需要使用的信封的

Router-Dealer

  1. 多用于在 REQ 和 REP 中间作为代理层: REQ(可以是多个) <--> Router(一个) <--> Deader(一个) <--> REP(可以是多个)
  2. 可以成对得出现多个 Router-Dealer 来实现多层代理
  3. 异步的,调用完 recv/send 接口之后不用必须调用反向的 send/recv 接口
  4. 需要显式处理信封,信封用于标识请求来源,同时回复消息时也需要用信封来标识回复到哪一个具体的请求端
  5. 信封可以嵌套,用于表示数据被多个 Router 转发
  6. 需要自己借助信封处理 路由规则(消息发送到哪些对端)
  7. Router 在收到消息时,会跟踪每一个 TCP 连接,并自动在消息前面追加 地址标识帧,以此告诉上层应用此数据的来源
  8. Router 在发送消息时,根据 地址标识帧 判断需要使用哪个 TCP 连接,发送消息给正确的目标,但真正发送消息前,会移除掉 地址标识帧
  9. Dealer 在逻辑上几乎不处理任何东西,只会接收和发送所有帧,不管是信封帧还是数据帧,不会擅自增加或删除任意帧,就像是一个异步的收发中转站
  10. Router 只关心 地址标识帧,它不知道也不关心后面的帧,包括空帧
  11. 当业务层直接使用 Router 时,可以自己处理 地址标识帧,换句话说,可以更灵活得控制消息的路由规则
  12. 当业务层直接使用 Dealer 与 REP 连接时,Deader 应该按照如下规则实现:Deader 发送消息时,必须先发送一个空帧(send-more),来模拟 REQ 的消息信封,否则 REP 会丢弃掉没有空帧的消息;在接收数据时,应该判断第一帧是否是空帧,是的话跳过并取得数据帧,不是的话则丢弃掉整个消息(包括数据帧)
  13. 类似的,当业务层直接使用 Dealer 与 REQ 连接时,Deader 应该按照如下规则实现:Deader 在接收到的消息时,应该判断第一帧是否是空帧,是的话跳过并取得数据帧,不是的话则丢弃掉整个消息(包括数据帧);在发送消息时,同样需要先发送空帧
  14. Router 一般会自动为一个新的连接生成标识,也就是 地址标识帧,但如果对端使用 setsockopt 明确设置了标识,Router 则不再自动生成

发布-订阅 模式(PUB-SUB)

  1. 没有订阅者的话,发布者会把所有消息都丢弃掉
  2. 订阅者可以订阅多个发布者,消息将会以轮次获取的方式公平得从每个发布者处获取
  3. 如果订阅者使用 TCP 创建连接,但处理消息比较慢,发布者会缓存一定量的消息
  4. 在不同版本和连接协议下,filtering 消息过滤这一操作可能在发布者一侧,也可能在订阅者一侧
  5. 一个消息会被所有订阅者获取到
  6. 订阅者必须要设置 SUBSCRIBE 否则收不到任何数据
  7. 订阅者可以设置多个 SUBSCRIBES,匹配到 任何一个 都会收到数据
  8. 消息的读写都是异步的

推送-拉取(PUSH-PULL)(分布式/并行处理模型/管道模式)

  1. 当出现 一对多 的情况时,数据会保证 公平队列(PULL) 和 负载均衡(PUSH)
  2. 一个消息只会被一个 PULL 端获取到