聊聊消息队列 2020/4/17 9:58

文章目录

  • 消息队列
    • 引入原因
  • 消息定义
  • 消息状态
    • 成功
    • 失败
    • 超时
  • 投递语义
    • 最少一次
    • 最多一次
    • 正好一次?
  • 消息协议
    • AMQP 协议
    • MQTT 协议
  • 常见组件
    • ActiveMQ
    • RabbitMQ
    • RocketMQ
    • kafka

消息队列

简单聊聊消息队列,后续可出文章具体实例剖析,本文概览闲聊。

引入原因

  1. 解耦:现代分布式系统模块众多,之间存在通信和协同的需求,使用消息队列传递的方式有效解耦;
  2. 异步:有的任务是同步在用户路径上,有的任务是异步,这种一般处理比较耗时,且不需要即时结果的操作,需要可靠的消息队列传递消息,推进流程;
  3. 广播:同一条消息,广播给多个下游模块处理,模块之间并不感知;
  4. 冗余:保存处理的消息,防止消息处理失败导致的数据丢失;

消息定义

消息,通俗来讲,是由来源发自一个通信单元,被发送给一个或者一群接受者,无论是单体服务还是分布式系统中都有消息的概念。这两种系统中传输消息的通道方法或者通道不同;

比如,在golang的进程里面channel就是单体服务里抽象出来的一个通信组件,或者通过 IO、进程间通信、方法调用的方式进行通信,而分布式系统中,通常是过网络传输,使用 TCP 或者 UDP 等协议进行传输。

消息状态

在单体服务中,一般来讲,只有两种状态:

  1. 成功
  2. 失败

这两个结果本质是一样的,就是结果是确定的,因为都是明确告诉了你结果;但在分布式系统中,却因为最不靠谱的网络,存在第三种状态:超时。顾名思义,就是,你根本收不到结果;

成功

投递成功

失败

投递失败

超时

在分布式系统中,因为是网络传输消息,但是网络却是最不靠谱的,可能出现丢包或者节点错误,发出请求的节点就可能永远也无法得到这次请求的响应。

超时状态是分布式系统复杂的最根本原因之一,也是 paxos ,raft 等分布式协议要解决的根本问题。超时的状态,你根本无法确认任何情况,你重试,就有可能重复,不重试,就有可能放着失败不管;

投递语义

分布式系统中,通过网络传输消息,网络传输是最不靠谱的,网络超时的通信错误是为分布式系统通信复杂的根本。我们通过对网路提供的基本传输能力封装,保证数据通信的可靠性。

那么试想下,你投递一个消息的时候,如果出现超时,你怎么办?才能保证可靠。

其实,你投递消息,出现了超时,还能怎么办,只能重试呗。但是重试,就一定可能会导致消息的发送和处理。那就不重试呗?不重试,那就有可能导致消息丢失。

我们一般分为三种消息语义:

  1. 最少一次
  2. 最多一次
  3. 恰好一次?

最少一次

这个很容易理解,就是消息投递至少一次。这个是为了解决消息丢失的问题。这个策略就是,消息发送者在出现网络超时时,重新发送相同的消息,引入超时重试机制,在发送者发出消息之后,监听消息的响应,直到得到确定的响应结果。

重点:

  1. 超时重试机制
  2. 监听消息响应

这样才能解决消息丢失的问题。

最多一次

最多一次,最容易实现,发消息走,就不管结果了。不管成功,失败,还是超时。成功,失败自是好处理,超时也不处理。但这个做法带来的问题,就是可能会丢消息,接受者有可能没有到消息,在半途丢了。

正好一次?

单就发送者和接受者的协议来讲,“正好一次”的语义根本不存在。那你就疑惑了,明明有消息组件提供了“正好一次”的语义,比如 kafka 。其实无论是那种消息组件,要实现“正好一次”的语义,本质上要求是一样的,公式如下:

“正好一次” = “超时重试” + “幂等去重”

重点

  • “超时重试”是消息投递者做的,”幂等去重“是接受方做的;
  • “幂等去重”要么消息组件来做,比如做在消息组件的 SDK 里面,或者业务自己来做;
    • kafka 就是自己做了幂等去重处理。简单来说,kafka 的每条消息都有一个全局编号,接受端会记录自己收到的消息编号,如果收到一条消息,发现比最近的大1以上,就会认为乱序会拒绝;如果小于自己记录的消息,那么就认为重复消息,直接丢弃;

消息协议

AMQP 协议

AMQP 是应用层协议,全名 Advanced Message Queuing Protocol ,这是一个面向消息中间件的开放标准,协议定义了关于消息队列、路由、可用性以及安全性等方面的内容。Erlang 的 RabbitMQ 是最出名的一个,支持“最多一次”,“最少一次”的语义。

MQTT 协议

MQTT 也是应用层协议,基于TCP/IP 之上,全称 Message Queue Telemetry Transport 。这个是处理发布订阅功能的协议,能够在不可靠网络条件下,完成发布与订阅的功能。支持三种投递语义,最多一次、最少一次和正好一次。这里的“正好一次”是协议层帮着做了重试和去重机制,这样消费者就不用再去关注消息重复的问题了。

常见组件

性能一般来说,由低到高。

ActiveMQ

  • 高可用模型:主从
  • 性能:万级吞吐
  • 开发语言:Java
  • 消息模型:push/pull

RabbitMQ

  • 高可用模型:集群 + 镜像队列
  • 性能:万级吞吐
  • 开发语言:Erlang
  • 消息模型:push/pull

RocketMQ

  • 高可用模型:主从
  • 性能:十万级(批量消息)
  • 开发语言:Java
  • 消息模型:push/pull

kafka

  • 高可用模型:动态集群
  • 性能:百万级吞吐(批量消息)
  • 开发语言:Java
  • 消息模型:pull

坚持思考,方向比努力更重要。微信公众号关注我:奇伢云存储

扫码_搜索联合传播样式-白色版.png

你可能感兴趣的:(消息队列,消息队列)