分布式系统中的消息
总结：
消息投递有【明确成功、明确失败、超时】三种。对于超时，重试则可能产生数据重复、不重试则可能导致数据丢失。
消息投递语义，从接收方接收消息情况来看有三种：
至少一次：超时重试，可能导致重复。
至多一次：投递者投递出去后就返回，不管接收成功与否。可能导致消息遗漏。
恰好一次：超时重试 + 幂等去重。
来源见：https://mp.weixin.qq.com/s/slTxl4DEJMeHX-OKxIozKw
消息队列
简单聊聊消息队列，后续可出文章具体实例剖析，本文概览闲聊。
引入原因
- 解耦：现代分布式系统模块众多，之间存在通信和协同的需求，使用消息队列传递的方式有效解耦；
- 异步：有的任务是同步在用户路径上，有的任务是异步，这种一般处理比较耗时，且不需要即时结果的操作，需要可靠的消息队列传递消息，推进流程；
- 广播：同一条消息，广播给多个下游模块处理，模块之间并不感知；
- 冗余：保存处理的消息，防止消息处理失败导致的数据丢失；
消息定义
消息，通俗来讲，是由来源发自一个通信单元，被发送给一个或者一群接受者，无论是单体服务还是分布式系统中都有消息的概念。这两种系统中传输消息的通道方法或者通道不同；
比如，在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 。这个是处理发布订阅功能的协议，能够在不可靠网络条件下，完成发布与订阅的功能。支持三种投递语义，最多一次、最少一次和正好一次。这里的“正好一次”是协议层帮着做了重试和去重机制，这样消费者就不用再去关注消息重复的问题了。
常见组件
性能一般来说，由低到高。
ActiveMQ
- 高可用模型：主从
- 性能：万级吞吐
- 开发语言：Java
- 消息模型：push/pull
RabbitMQ
- 高可用模型：集群 + 镜像队列
- 性能：万级吞吐
- 开发语言：Erlang
- 消息模型：push/pull
RocketMQ
- 高可用模型：主从
- 性能：十万级（批量消息）
- 开发语言：Java
- 消息模型：push/pull
kafka
- 高可用模型：动态集群
- 性能：百万级吞吐（批量消息）
- 开发语言：Java
- 消息模型：pull
