消息队列——0

一、什么是消息队列

把要传输的数据放在队列中

• 把数据放到消息队列叫做生产者
• 从消息队列里边取数据叫做消费者

 

二、为什么要用消息队列

2.1、解耦

• 应用耦合：多应用间通过消息队列对同一消息进行处理，避免调用接口失败导致整个过程失败；

• 系统A将userId写到消息队列中，系统C和系统D从消息队列中拿数据。这样有什么好处？

• 系统A只负责把数据写到队列中，谁想要或不想要这个数据(消息)，系统A一点都不关心。
• 即便现在系统D不想要userId这个数据了，系统B又突然想要userId这个数据了，都跟系统A无关，系统A一点代码都不用改。
• 系统D拿userId不再经过系统A，而是从消息队列里边拿。系统D即便挂了或者请求超时，都跟系统A无关，只跟消息队列有关。

2.2、 异步

2.3、削峰/限流

系统B和系统C根据自己的能够处理的请求数去消息队列中拿数据，这样即便有每秒有8000个请求，那只是把请求放在消息队列中，去拿消息队列的消息由系统自己去控制，这样就不会把整个系统给搞崩。

三、消息队列的两种模式

点对点模式（point to point， queue）和发布/订阅模式（publish/subscribe，topic）。

点对点：消息发送者生产消息发送到queue中，然后消息接收者从queue中取出并且消费消息。消息被消费以后，queue中不再有存储，所以消息接收者不可能消费到已经被消费的消息。

点对点模式特点：

• 1、每个消息只有一个接收者（Consumer）(即一旦被消费，消息就不再在消息队列中)；

• 2、发送者和接收者间没有依赖性，发送者发送消息之后，不管有没有接收者在运行，都不会影响到发送者下次发送消息；

• 3、接收者在成功接收消息之后需向队列应答成功，以便消息队列删除当前接收的消息；

发布/订阅模式：发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

发布/订阅模式特点：

• 1、每个消息可以有多个订阅者；

• 2、发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。

• 3、为了消费消息，订阅者需要提前订阅该角色主题，并保持在线运行；

 

三、使用消息队列要解决什么问题？

3.1、高可用

无论是我们使用消息队列来做解耦、异步还是削峰，消息队列肯定不能是单机的。试着想一下，如果是单机的消息队列，万一这台机器挂了，那我们整个系统几乎就是不可用了。

3.2 、数据丢失问题

我们将数据写到消息队列上，系统B和C还没来得及取消息队列的数据，就挂掉了。如果没有做任何的措施，我们的数据就丢了。

3.3、消费者怎么得到消息队列的数据？

• 生产者将数据放到消息队列中，消息队列有数据了，主动叫消费者去拿(俗称push)
• 消费者不断去轮训消息队列，看看有没有新的数据，如果有就消费(俗称pull)

3.4、其他

• 消息重复消费了怎么办啊？
• 我想保证消息是绝对有顺序的怎么做？

 

四、常见消息队列介绍

普通队列

包括分区有序和全局有序，分区有序的普通队列具有更高的并发性能，不保证先入先出（FIFO）的严格顺序，全局有序的普通队列保证消息先入先出（FIFO）的严格顺序。DMS支持普通队列和有序队列，提供高并发、低延时、稳定安全的消息中间件服务。

ActiveMQ队列

使用AMQP协议的队列。Advanced Message Queuing Protocol，是统一消息服务的应用层标准的高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。DMS兼容ActiveMQ，简单易用，按需使用，支持水平扩展，安全可靠，无忧运维。

Kafka队列

支持使用开源kafka客户端进行生产消息和消费消息。支持高吞吐和高可靠两种模式，高吞吐模式的消息副本异步落盘，具有较高的性能，高可靠模式的消息多副本同步落盘，保证消息的可靠性。DMS兼容Kafka，即开即用，安全可靠，支持高吞吐、高可靠两种应用场景。

原理：https://blog.csdn.net/qq_29186199/article/details/80827085

     https://blog.csdn.net/Dongguabai/article/details/86536894

RabbitMQ队列

采用物理隔离方式部署，支持用户自定义内存规格和自定义特性，您可以根据业务需要定制相应计算能力和存储空间的RabbitMQ实例。DMS兼容RabbitMQ，提供独占资源，保证队列高性能。

 

五、消息队列的常见问题

1.消息丢失怎么办？

RabbitMQ消息中间件：

（1）生产者弄丢数据——confirm机制

（2）Mq弄丢数据——设置持久化

（3）消费者弄丢数据——RabbitMQ提供的ack机制

Kafka消息中间件：

（1）消费端弄丢了数据

（2）kafka弄丢了数据

 

2.消费者顺序消费

要实现严格的顺序消息，简单且可行的办法就是：保证生产者- MQServer -消费者是一对一对一的关系。

3.消息的重复

1）、生产者消息重复发送； 2）.MQ向消费者投递时重复投递——终极解决办法：幂等性

 

3、大量消息在mq里积压了几个小时了还没解决

——操作临时紧急扩容

1，先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉。
2，新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量。
3，然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue。
4，接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据。
5，这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据。
6，等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息。

4、消息队列过期失效问题

——批量重导

 

5、消息队列满了怎么搞？

——你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息

 

六、如何保证消息队列的高可用性

RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式

 

原文链接：https://blog.csdn.net/middleware2018/article/details/80768939

原文链接：https://blog.csdn.net/yue_2018/article/details/89305275

原文链接：https://www.cnblogs.com/111testing/p/11488575.html

原文链接：https://blog.51cto.com/caczjz/2141194?source=dra