消息队列-ZeroMQ

小o魂

已于 2022-02-03 19:07:46 修改

阅读量355

点赞数

文章标签：后端消息队列

于 2021-11-28 14:22:23 首次发布

本文链接：https://blog.youkuaiyun.com/u012173846/article/details/121591031

版权

消息队列的场景

异步处理
流量控制
服务解耦
发布订阅
高并发缓冲

异步处理

主要场景：短信通知、终端状态推送、 App推送、用户注册等

秒杀系统为例

更快速返回结果；减少等待，实现并发处理，提升系统总体性能。

流量控制(削峰)

秒杀场景下的下单状态
使用消息队列隔离网关和后端服务，以达到流量控制和保护后端服务的目的。

服务解耦

使用消息队列实现系统的解耦

发布订阅

比如游戏里面跨服：

广播今天整体还剩多少把屠龙刀可以暴
广播用户暴的屠龙刀的消息

高并发缓冲

kafka 日志服务、监控上报

消息队列-基本概念和原理

Broker

Broker的概念来自与Apache ActiveMQ，通俗的讲就是MQ的服务器。

消息的生产者、消费者

消息生产者Producer：发送消息到消息队列。
消息消费者Consumer：从消息队列接收消息。

点对点消息队列模型

消息生产者向一个特定的队列发送消息，消息消费者从该队列中接收消息；消息的生产者和消费者可以不同时处于运行状态。每一个成功处理的消息都由消息消费者签收确认（Acknowledge）。

rabbitmq 点对点：

发布订阅消息模型-Topic

发布订阅消息模型中，支持向一个特定的主题Topic发布消息， 0个或多个订阅者接收来自这个消息主题的消息。在这种模型下，发布者和订阅者彼此不知道对方。实际操作过程中，发布订阅消息模型中，支持向一个特定的主题Topic发布消息， 0个或多个订阅者接收来自这个消息主题的消息。在这种模型下，发布者和订阅者彼此不知道对方。

消息的顺序性保证

基于Queue消息模型，利用FIFO先进先出的特性，可以保证消息的顺序性。

消息的ACK确认机制

即消息的Ackownledge确认机制，为了保证消息不丢失，消息队列提供了消息Acknowledge机制，即ACK机制，当Consumer确认消息已经被消费处理，发送一个ACK给消息队列，此时消息队列便可以删除这个消息了。如果Consumer宕机/关闭，没有发送ACK，消息队列将认为这个消息没有被处理，会将这个消息重新发送给其他的Consumer重新消费处理。

消息的持久化

消息的持久化，对于一些关键的核心业务来说是非常重要的，启用消息持久化后，消息队列宕机重启后，消息可以从持久化存储恢复，消息不丢失，可以继续消费处理。

消息的同步和异步收发

同步：消息的收发支持同步收发的方式。
同时还有另一种同步方式：同步收发场景下，消息生产者和消费者双向应答模式，例如：张三写封信送到邮局中转站，然后李四从中转站获得信，然后在写一份回执信，放到中转站，然后张三去取，当然张三写信的时候就得写明回信地址消息的接收如果以同步的方式(Pull)进行接收，如果队列中为空，此时接收将处于同步阻塞状态，会一直等待，直到消息的到达。

异步：消息的收发同样支持异步方式：异步发送消息，不需要等待消息队列的接收确认；
异步接收消息，以Push的方式触发消息消费者接收消息。

消息的事务支持

消息的收发处理支持事务，例如：在任务中心场景中，一次处理可能涉及多个消息的接收、处理，这处于同一个事务范围内，如果一个消息处理失败，事务回滚，消息重新回到队列中。

可供选择的消息队列产品

特性	RabbitMQ	RocketMQ	Kafka	ZeroMQ
单机吞吐量	万级，比RocketMQ、 Kafka 低一个数量级	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景	100万级别，最早设计用于股票实时交易系统
topic 数量对吞吐量的影响		topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下， Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
时效性	微秒级，这是RabbitMQ 的一大特点，延迟最低	ms 级	延迟在 ms 级以内	延迟在微妙级别/毫秒级别
可用性	高，基于主从架构实现高可用	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用	不是一个独立的服务，要嵌套到自己的程序里面去
消息可靠性	基本不丢	经过参数优化配置，可以做到 0 丢失	同RocketMQ
功能支持	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用	如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ。

ZeroMQ

吞吐量和延时性

ZeroMQ解决传统网络编程的问题

调用的socket接口较多；
TCP是一对一的连接；一对多， reactor模式
编程需要关注很多socket细节问题；
不支持跨平台编程；
需要自行处理分包、组包问题；
流式传输时需处理粘包、半包问题；
需自行处理网络异常，比如连接异常中断、重连等；
服务端和客户端启动有先后；
自行处理IO模型；
自行实现消息的缓存；
自行实现对消息的加密

官方API: http://api.zeromq.org/
中文指南： https://github.com/anjuke/zguide-cn，文档里面的代码有些是过时的，需要参考提供的github链接的代码
英文指南： http://zguide.zeromq.org/page:all
性能测试： http://wiki.zeromq.org/results:perf-howto
中文参考书籍：《ZeroMQ 云时代极速消息通信库 .pdf》