简单聊聊消息队列，后续可出文章具体实例剖析，本文概览闲聊。
消息，通俗来讲，是由来源发自一个通信单元，被发送给一个或者一群接受者，无论是单体服务还是分布式系统中都有消息的概念。这两种系统中传输消息的通道方法或者通道不同；
比如，在golang的进程里面channel就是单体服务里抽象出来的一个通信组件，或者通过 IO、进程间通信、方法调用的方式进行通信，而分布式系统中，通常是过网络传输，使用 TCP 或者 UDP 等协议进行传输。
在单体服务中，一般来讲，只有两种状态：
这两个结果本质是一样的，就是结果是确定的，因为都是明确告诉了你结果；但在分布式系统中，却因为最不靠谱的网络，存在第三种状态：超时。顾名思义，就是，你根本收不到结果；
投递成功，结果明确。
投递失败，结果明确。
在分布式系统中，因为是网络传输消息，但是网络却是最不靠谱的，可能出现丢包或者节点错误，发出请求的节点就可能永远也无法得到这次请求的响应。
超时状态是分布式系统复杂的最根本原因之一，也是 paxos ，raft 等分布式协议要解决的根本问题。超时的状态，你根本无法确认任何情况，你重试，就有可能重复，不重试，就有可能放着失败不管；
分布式系统中，通过网络传输消息，网络传输是最不靠谱的，网络超时的通信错误是为分布式系统通信复杂的根本。我们通过对网路提供的基本传输能力封装，保证数据通信的可靠性。
那么试想下，你投递一个消息的时候，如果出现超时，你怎么办？才能保证可靠。
其实，你投递消息，出现了超时，还能怎么办，只能重试呗。但是重试，就一定可能会导致消息的发送和处理。那就不重试呗？不重试，那就有可能导致消息丢失。
我们一般分为三种消息语义：
这个很容易理解，就是消息投递至少一次。这个是为了解决消息丢失的问题。这个策略就是，消息发送者在出现网络超时时，重新发送相同的消息，引入超时重试机制，在发送者发出消息之后，监听消息的响应，直到得到确定的响应结果。
重点：
这样才能解决消息丢失的问题。
最多一次，最容易实现，发消息走，就不管结果了。不管成功，失败，还是超时。成功，失败自是好处理，超时也不处理。但这个做法带来的问题，就是可能会丢消息，接受者有可能没有到消息，在半途丢了。
单就发送者和接受者的协议来讲，“正好一次”的语义根本不存在。那你就疑惑了，明明有消息组件提供了“正好一次”的语义，比如 kafka 。其实无论是那种消息组件，要实现“正好一次”的语义，本质上要求是一样的，公式如下：
“正好一次” = “超时重试” + “幂等去重”
重点：
AMQP 是应用层协议，全名 Advanced Message Queuing Protocol ，这是一个面向消息中间件的开放标准，协议定义了关于消息队列、路由、可用性以及安全性等方面的内容。Erlang 的 RabbitMQ 是最出名的一个，支持“最多一次”，“最少一次”的语义。
MQTT 也是应用层协议，基于TCP/IP 之上，全称 Message Queue Telemetry Transport 。这个是处理发布订阅功能的协议，能够在不可靠网络条件下，完成发布与订阅的功能。支持三种投递语义，最多一次、最少一次和正好一次。这里的“正好一次”是协议层帮着做了重试和去重机制，这样消费者就不用再去关注消息重复的问题了。
性能一般来说，由低到高。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8