消息队列MQ使用详解

目录

• 什么是消息队列MQ
• 作用
• 缺点
• 主要产品
• 举例
• 1、例一
• 例二
• 例三
• 例四：流量削峰
• 发布订阅 vs MQ
• 总结

什么是消息队列MQ

MQ（Message Queue）消息队列，是基础数据结构中“先进先出”的一种数据结构。指把要传输的数据（消息）放在队列中，用队列机制来实现消息传递——生产者产生消息并把消息放入队列，然后由消费者去处理。

消费者可以到指定队编程客栈列拉取消息，或者订阅相应的队列，由MQ服务端给其推送消息。

作用

消息队列中间件是分布式系统中重要的组件，主要解决应用解耦，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。

• 解耦：一个业务需要多个模块共同实现，或者一条消息有多个系统需要对应处理，只需要主业务完成以后，发送一条MQ，其余模块消费MQ消息，即可实现业务，降低模块之间的耦合。
• 异步：主业务执行结束后从属业务通过MQ，异步执行，减低业务的响应时间，提高用户体验。
• 削峰：高并发情况下，业务异步处理，提供高峰期业务处理能力，避免系统瘫痪。

缺点

1、系统可用性降低。依赖服务也多，服务越容易挂掉。需要考虑MQ瘫痪的情况

2、系统复杂性提高。需要考虑消息丢失、消息重复消费、消息传递的顺序性

3、业务一致性。主业务和从属业务一致性的处理

主要产品

主要的 MQ 产品包括：RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ、Kafka、IBM WebSphere 等。

比较火的是 RocketMQ 和 Kafka。

分别应用在 web 和大数据

举例

1、例一

一个实际的使用消息队列（MQ）的例子是电商网站的订单处理系统。在电商网站中，用户下单后需要经过一系列的处理流程，包括订单验证、库存检查、支付处理、物流跟踪等。这些处理流程需要多个模块之间进行协作，而且每个模块都需要处理大量的订单数据。

为了解决这些问题，可以使用消息队列系统来实现订单处理流程的异步处理。具体来说，可以将订单数据发送到一个订单处理队列中，然后由不同的模块从队列中获取订单数据进行处理。这样就可以将订单数据的发送和接收者进行解耦，实现了系统的高可靠性、可伸缩性和可维护性。

举个例子，当用户下单后，订单系统会将订单数据发送到订单处理队列中，然后库存系统会从队列中获取订单数据进行库存检查，支付系统会从队列中获取订单数据进行支付处理，物流系统会从队列中获取订单数据进行物流跟踪等。这些模块之间可以并行处理订单数据，而且每个模块都可以独立地进行扩展和升级，从而实现了系统的高可用性和可伸缩性。

另外，由于电商网站的订单数据量可能非常大，使用消息队列可以实现削峰填谷，平滑处理订单请求，从而保证系统的可用性和稳定性。此外，使用消息队列还可以实现订单数据的缓存和延迟处理，以提高系统的性能和吞吐量。

总之，使用消息队列可以使得电商网站的订单处理系统更加高效、可靠和可维护，是现代电商系统中必不可少的技术。

例二

在线游戏中的多人游戏场景同步。在多人游戏中，多个玩家之间需要实时同步游戏场景的状态，包括角色位置、状态、动作等，同时还需要处理玩家之间的交互、碰撞等复杂场景逻辑。

为了实现这样的实时场景同步，可以使用消息队列来处理游戏场景事件的分发和处理。具体来说，可以将游戏场景中的事件（如玩家移动、攻击、技能释放等）封装成消息，然后通过消息队列进行广播，让所有参与游戏的客户端都能够接收到相应的消息，并根据消息内容来更新本地的游戏状态。

使用消息队列的好处在于，它可以将游戏场景事件的发送和接收者进行解耦，从而提高系统的可扩展性和可维护性。同时，由于消息队列可以处理大量的消息，还可以应对高并发的场景，并且能够削峰填谷，提高系统的稳定性和可用性。

在多人游戏中，使用消息队列还可以实现一些高级功能，比如实现延迟同步、反作 弊等。比如，可以将游戏场景中的事件缓存到消息队列中，并设置一定的延迟时间后再进行处理，以确保所有玩家都能够接收到相同的游戏状态。此外，还可以使用消息队列来监控和过滤玩家的行为，以检测和防范作弊行为。

综上所述，使用消息队列可以实现多人游戏场景的实时同步，并提高系统的可扩展性、可维护性和稳定性，是现代游戏开发中的重要技术。

例三

用户注册后，需要发注册邮件和注册短信，传统的做法有两种

• 1.串行的方式；
• 2.并行的方式 ；
• 3.消息队列

(1)串行方式：将注册信息写入数据库后，发送注册邮件，再发送注册短信，以上三个任务全部完成后才返回给客户端。这有一个问题是，邮件，短信并不是必须的，它只是一个通知，而这种做法让客户端等待没有必要等待的东西。

(2)并行方式：将注册信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后编程，返回给客户端，并行的方式能提高处理的时间。

(3)消息队列cxTvoZKcb

引入消息队列后，把发送邮件，短信不是必须的业务逻辑异步处理。

例四：流量削峰

秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，一般在应用前端加入消息队列。

用户的请求，服务器收到之后，首先写入消息队列，加入消息队列长度超过最大值，则直接抛弃用户请求或跳转到错误页面。秒杀业务根据消息队列中的请求信息，再做后续处理。

发布订阅 vs MQ

发布订阅模式和消息队列（MQ）都是在分布式系统中广泛使用的消息传递机制，它们都具有将发送者和接收者解耦的优点。

虽然这两种模式在某些方面相似，但它们也有一些重要的区别。

谁负责管理消息？

• 在发布订阅模式中，消息的发送者不需要知道消息的接收者，而是将消息发送到一个主题（Topic），然后所有订阅该主题的订阅者都会接收到该消息。主题的管理通常由发布者负责。
• 在消息队列中，消息的发送者将消息发送到队列中，然后订阅该队列的订阅者会按照队列中的消息顺序进行消费。队列的管理通常由消息队列系统负责。

消息如何分发？

• 在发布订阅模式中，消息是通过主题进行分发的，所有订阅该主题的订阅者都会接收到相同的消息。这种方式可以使得多个订阅者同时接收到同一份消息。
• 在消息队列中，消息是通过队列进行分发的，每个消息只会被一个订阅者接收。这种方式可以确保每个订阅者都能够接收到所有消息，但是无法让多个订阅者同时接收到同一份消息。

如何处理消息丢失？

• 在发布订阅模式中，如果某个订阅者没有及时接收到消息，它将无法再次获取到该消息。这可能会导致消息丢失。
• 在消息队列中，消息通常会被持久化到磁盘上，以确保即使在消息消费者宕机的情况下，消息也不会丢失。如果某个消费者编程客栈无法消费某个消息，该消息将被保留在队列中，直到可以被正确地处理为止。

用例场景

• 发布订阅模式通常适用于一些事件驱动的应用场景，例如消息推送、实时数据处理等。
• 消息队列则适用于一些流量高、性能稳定的场景，例如电商交易、订单处理、日志处理等。

总结

以上为个人经验，希望能给大家一个参cxTvoZKcb考，也希望大家多多支持编程客栈(www.devze.com)。