聊聊分布式系统中的消息

发表于 3年以前 | 总阅读数：313 次

消息队列

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

引入原因

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

消息定义

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

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

消息状态

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

成功
失败

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

成功

投递成功，结果明确。

失败

投递失败，结果明确。

超时

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

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

投递语义

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

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

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

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

最少一次
最多一次
恰好一次？

最少一次

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

重点：

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

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

最多一次

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

正好一次？

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

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

重点：

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

消息协议

AMQP 协议

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

MQTT 协议

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