常用MQ及其原理

mq为了解决什么问题？

1、异步通信

   有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

2、解耦

   降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束

3、冗余

   有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

4、扩展性

   因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容

5、过载保护

   在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃

6、可恢复性

   系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

7、顺序保证

   在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

8、缓冲

   在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

9、数据流处理

分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择

Mq原理

1)MQ原型-Pub/Sub发布订阅

（广播：生产者-消费之1对多）：使用topic作为通信载体

希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型

2) MQ原型-PTP点对点

:使用queue作为通信载体

 如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式。

3 MQ原型-多点广播：

MQ适用于不同类型的应用。其中重要的，也是正在发展中的是"多点广播"应用，即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。

4 MQ原型-群集(Cluster)：

为了简化点对点通讯模式中的系统配置，MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain)，群集内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用群集(Cluster)通道与其它成员通讯，从而大大简化了系统配置。此外，群集中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性

 

2、MQ组成结构

   Broker：消息服务器，作为server提供消息核心服务

   Producer:消息生产者，业务的发起方，负责生产消息传输给broker，

   Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理

   Topic:主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅 者，实现消息的广播

   Queue：队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收

   Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

RabbitMq与kafaka选型比较

https://blog.csdn.net/yifansj/article/details/79248586

架构方面：

Kafaka是正常的mq架构，包括provider broker consumer。，kafaka没有消息确认机制

rabbitMq 中的broker由exchange、binder queue三部分组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费，rabbit有消息确认机制

吞吐量方面：

Kafaka采用zero-copy方式，即数据存储和获取是本地磁盘顺序批量操作，具有O（1）复杂度，数据处理效率很高

RabbitMq在吞吐量方面不如kafaka，RabbitMq支持对消息可靠的传递，支持事务，不支持批量的操作。

可用性方面

Kafaka的broker采用主备模式，所以可用性很高

RabbitMq支持miror queue，主queue失效，minor queue生效

集群负载方面

Kafaka使用zookeeper实现负载均衡，zookeeper管理集群中的broker sonsumer，通过zookeeper的协调机制，producer会记录topic对应的broker，对broker进行轮询或者随机访问broker，实现负载均衡

RabbitMq需要单独自定义负载均衡

 

一般推荐使用mq，例如RabbitMq，activeMq等，已经比较成熟和稳定了，性能也一般，一般推荐使用这些。Redies适用于在内存中存储数据库，作为消息队列可靠性较差，而且依赖于网络IO;kafaka设计的初衷是日志统计分析，现在也可以配合zookeeper用于消息