2021-05-16 Zeromq

Zeromq 是什么

处理消息传输的库/组件

特征

Socket 进程间通信要建立连接
Zeromq 是一个嵌入式网络链接库，包含其的进程之间可以直接通信，用于大型的高并发场景下，构建大型分布式系统，主要用于线程间、进程间、tcp、广播等。
传统tcp是1对1的，zeromq是多对多的连接模式
io高吞吐，异步机制
多语言支持、多平台支持

开发功能的过程

1.将功能模块化，通过调用模块组织代码实现功能
2.利用多核：多线程、多进程、协程
3.将功能划分为多个微服务（多线程、多进程），来实现功能

4.微服务之间怎么沟通？

以多线程为例：pipe、队列、锁

pipe（管道）：一端写，一端读，数据流向单一，半双工通信
队列：actor模型，多线程上面封装一层运行实体
锁：互斥锁、条件变量、读写锁、自旋锁、乐观悲观锁，在程序中大量使用锁会使可读性变差，还容易引起死锁，解决bug困难

以多进程为例：共享内存、管道、消息队列、socket

共享内存：nginx、openresty

多维度思考选择哪种方式进程间通讯

扩展、性能、灵活性，一般选用socket

但socket需要

1、建立连接 销毁连接
2、指定协议 选择协议 protobuffer json 拆包粘包问题
3、处理错误 error close
4、进程间通信断线重连问题（心跳检测）
5、io epoll（很复杂）
6、进程间通信的时候，监听发布 推拉 请求回应 多语言
6、进程启动有顺序要求

开发一个稳定的通信组件有众多问题需要解决

对于Zeromq

1、启动顺序无关
2、bind connect send recv 函数即可实现进程间的通信
3、无需处理拆包粘包、断线重连、出现错误等问题

zeromq是socket上封装了一层，让我们忽略网络通信的细节

Zeromq有哪些模型？

1、请求回应模型Req-Rep：依次请求依次回应

请求端：send，recv
回应端：recv，send
复杂时可能请求端发给多个worker，worker协作组装后发给回应端，回应段再response回请求端：route + dealer + device
主要为了消息一一对应以及协作组装

2、管道模型：push—pull

以nginx为例

nginx将请求分发给多个worker进程，即push
worker接收请求并进行处理，即pull
采用公平队列：worker间有多个子队列，有个主队列，消息队列之间将消息均衡分布在子队列中

监听发布者模型：sub-pub

发布者pub有很多子监听者sub，当发布者pub有变更就一次就发给各个sub

通配符 *-hello 1-hello 2-hello
发布者要有sub列表，zeromq中不管sub怎么样，pub全部发送，sub按需接收。

以上三种模式组合实现各种场景

eg：
腾讯欢乐斗地主，有大厅（hall），有很多桌子（worker）
hall进程：显示桌子、人物变动
worker进程：实现欢乐斗地主服务

如何选择合适的模型？

多个work间无状态（没有差异）

管道模型：使用：均衡压力
监听发布者模型：使用：worker（pub）发布人数变动，hall（sub）接受变动信息并组织发给客户端，在客户端实时显示大厅变化

详细学习REQ-REP模型

模型原理

由 Client 发起请求，并等待Server回应请求。请求端和服务端都可以是1：N的模型。通常把1认为是Server，N认为是Client。通过device将1：N扩展为N:M（只需要加入若干路由节点）。

Client：首先发送（send）request 指令，在接收（recv）到 reply 指令之前处于阻塞状态
Server：首先接收（recv）request 指令，然后发送（send）reply 指令，在接收到下一条 request 指令前阻塞

https://download.csdn.net/download/yy805428679/10787808?utm_medium=distribute.pc_relevant.none-task-download-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-3.control&depth_1-utm_source=distribute.pc_relevant.none-task-download-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-3.control