MQ分类和基本信息

Posted 2020-11-01

好久没更新博客，之前对MQ有过研究，现在打算系统的研究下消息队列。

一、 简介

1、 是一种跨进程的通信机制，用于上下游传递消息。
MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。
消息发送上游-》 MQ -》消息发送下游。 此情况使用MQ
调用上游-》被调用下游。 此情况不使用MQ。
优点与不足：
2、 不足：
1) 系统更复杂，多了一个MQ组件。
2) 通信时间更长，消息传递路径增长，延时会增加。
3) 消息的可靠性和不重复性不能保证。消息不丢不重难以同时保证。
4) 上游无法知道下游的执行结果。如登录，上游无法知道是否登录成功。这种情况使用调用关系。

一、 使用场景

如定时任务。按照执行顺序执行。task1，task2，task3。1-2-3的执行顺序。可以使用MQ进行解耦。1为发布者，2为订阅者和发布者，3为订阅者。
如按照cron执行，需预留时间。有时间浪费。如采用MQ，执行顺序和执行时间得到保证。task1的执行时间改变，2、3不需要改变。
1、什么时候不使用MQ？
上游实时关注执行结果
2、什么时候使用MQ？
1）数据驱动的任务依赖
2）上游不关心多下游执行结果
3）异步返回执行时间长

二、 MQ分类

RabbitMQ：

对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。
Redis
入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

ZeroMQ

号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ

是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 php、 Ruby等。

Kafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统

RocketMQ

阿里巴巴自主研发。

三、 推送类型

场景1：单发送单接收
使用场景：简单的发送与接收，没有特别的处理。
场景2：单发送多接收
使用场景：一个发送端，多个接收端，如分布式的任务派发。为了保证消息发送的可靠性，不丢失消息，使消息持久化了。同时为了防止接收端在处理消息时down掉，只有在消息处理完成后才发送ack消息。
场景3：Publish/Subscribe
使用场景：发布、订阅模式，发送端发送广播消息，多个接收端接收。
场景4：Routing (按路线发送接收)
使用场景：发送端按routing key发送消息，不同的接收端按不同的routing key接收消息。
场景5：Topics (按topic发送接收)
使用场景：发送端不只按固定的routing key发送消息，而是按字符串“匹配”发送，接收端同样如此。
四、 数据准确性

1) 可达性：

消息分为上下半场：上半场，发送方将消息发送给MQ。下半场，MQ将消息发送给接收方。
上下半场都有可能出现消息的丢失。为了避免这种情况，需要进行MQ的超时和重传。
上半场的超时和重传
MQ上半场如果丢失或者超时，MQ-client-sender内的timer会重发消息，直到期望收到3，如果重传N次后还未收到，则SendCallback回调发送失败，需要注意的是，这个过程中MQ-server可能会收到同一条消息的多次重发。
下半场的超时与重传
MQ下半场如果丢失或者超时，MQ-server内的timer会重发消息，直到成功执行，这个过程可能会重发很多次消息，一般采用指数退避的策略，先隔x秒重发，2x秒重发，4x秒重发，以此类推，需要注意的是，这个过程中MQ-client-receiver也可能会收到同一条消息的多次重发。
MQ-client与MQ-server如何进行消息去重，如何进行架构幂等性设计

2) 幂等性

上半场：
1，发送端MQ-client将消息发给服务端MQ-server
2，服务端MQ-server将消息落地
3，服务端MQ-server回ACK给发送端MQ-client
如果3丢失，发送端MQ-client超时后会重发消息，可能导致服务端MQ-server收到重复消息。
此时重发是MQ-client发起的，消息的处理是MQ-server，为了避免步骤2落地重复的消息，对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，这个内部消息ID的特性是：
（1）全局唯一
（2）MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽
有了这个inner-msg-id，就能保证上半场重发，也只有1条消息落到MQ-server的DB中，实现上半场幂等。
下半场：
4，服务端MQ-server将消息发给接收端MQ-client
5，接收端MQ-client回ACK给服务端
6，服务端MQ-server将落地消息删除
需要强调的是，接收端MQ-client回ACK给服务端MQ-server，是消息消费业务方的主动调用行为，不能由MQ-client自动发起，因为MQ系统不知道消费方什么时候真正消费成功。
如果5丢失，服务端MQ-server超时后会重发消息，可能导致MQ-client收到重复的消息。
此时重发是MQ-server发起的，消息的处理是消息消费业务方，消息重发势必导致业务方重复消费（上例中的一次付款，重复发卡），为了保证业务幂等性，业务消息体中，必须有一个biz-id，作为去重和幂等的依据，这个业务ID的特性是：
（1）对于同一个业务场景，全局唯一
（2）由业务消息发送方生成，业务相关，对MQ透明
（3）由业务消息消费方负责判重，以保证幂等
最常见的业务ID有：支付ID，订单ID，帖子ID等。
具体到支付购卡场景，发送方必须将支付ID放到消息体中，消费方必须对同一个支付ID进行判重，保证购卡的幂等。
有了这个业务ID，才能够保证下半场消息消费业务方即使收到重复消息，也只有1条消息被消费，保证了幂等。