分布式消息队列应用场景之异步处理、应用解耦、流量削锋和消息通讯理解分析
摘要：消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题。实现高性能，高可用，可伸缩和最终一致性架构。是大型分布式系统不可缺少的中间件。
目前在生产环境，使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka等。
消息队列应用场景
以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。
1.异步处理
场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种1.串行的方式；2.并行方式。
（1）串行方式：将注册信息持久化后，发送注册邮件，再发送注册短信。三个业务全部完成后，返回给客户端。
（2）并行方式：将注册信息持久化后，发送注册邮件的同时，发送注册短信。三个业务全部完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间。
假设三个业务节点每个使用100毫秒钟，不考虑其他开销，则串行方式的时间是300ms，并行的时间可能是200毫秒。则串行的方式1秒内可处理3次请求，并行方式1秒内可处理5次请求，综上所述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题呢？
引入消息队列，将不是必须的业务逻辑，异步处理。如下图所示
按照上图，用户的响应时间相当于是注册信息写入数据库的时间和将消息插入消息队列，也就是105毫秒。注册邮件，发送短信消息写入队列后，直接返回。如此消息队列异步处理后，1秒内可处理9次请求。大大提高了系统的性能
2.应用解耦
场景说明：后台发货系统，发货后快递发货系统需要通知订单系统，该订单已发货。如果我们用传统的做法是，快递发货系统调用订单系统的接口，更新订单为已发货。如下图
传统模式的缺点：
1） 假如订单系统无法访问，则订单更新为已发货失败，从而导致发货失败；
2） 发货系统与订单系统耦合；
如何解决以上问题呢？引入应用消息队列后的方案，如下图：
发货系统：发货后，发货系统完成持久化处理，将消息写入消息队列，返回发货成功。
订单系统：订阅发货的消息，获取发货信息，订单系统根据信息，进行更新操作。
如上，发货系统在发货的时候不用关心后续操作了，如果订单系统不能正常使用。也不影响正常发货，实现订单系统与发货系统的应用解耦。
3.流量削锋
流量削锋也是消息队列中的常用场景，一般在秒杀或抢够活动中使用广泛。
应用场景：秒杀活动，一般会因为流量过大，应用系统配置承载不了这股瞬间流量，导致系统直接挂掉，即传说中的“宕机”现象。为解决这个问题，我们会将那股巨大的流量拒在系统的上层，即将其转移至 MQ 而不直接涌入我们的接口，此时MQ起到了缓冲作用。
4.消息通讯
消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在实现消息通讯。如点对点消息队列，或者聊天室等。
点对点通讯：客户端A和客户端B使用同一队列，进行消息通讯。
聊天室通讯：客户端A，客户端B 订阅同一主题，进行消息发布和接收。
以上实际是消息队列的两种消息模式，点对点或发布订阅模式。
以上内容希望帮助到大家，很多PHPer在进阶的时候总会遇到一些问题和瓶颈，业务代码写多了没有方向感，不知道该从那里入手去提升，对此我整理了一些资料，包括但不限于：分布式架构、高可扩展、高性能、高并发、服务器性能调优、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql优化、shell脚本、Docker、微服务、Nginx等多个知识点高级进阶干货需要的可以免费分享给大家，需要请戳这里
以上是 分布式消息队列应用场景之异步处理、应用解耦、流量削锋和消息通讯理解分析 的全部内容， 来源链接： utcz.com/z/515651.html
