一：使用消息队列的原因
1.服务走向分布式的一个必然结果，在追求可靠性、一致性、性能、架构清晰等，MQ在复杂高并发下可以解决很多问题，如下面的登录系统，登陆成功后，需要调用其他服务：
1.登录系统
2.一些常见的原因有：
1）系统间解耦、异步处理，节省主流程时间，方便新增业务对接；比如登陆之后，发积分、送卡券等等，这些和主逻辑关系不密切的，需要解耦；或者是一些分析对账功能，为了减轻mysql的负载，选择监听mysql的binlog
2）削峰、流控：比如防redis、mysql被打爆；比如mysql因一些原因，时延变大，任务堆积，为了防止mysql被打爆，又不想放弃一些任务，MQ可以作为一种可靠性的backup；
3）数据分发：作为一个消息的集聚地，完成一些通用功能，并借用MQ的负载均衡，来分发处理，比如一个跨系统间的同步系统，A服务上报下层的设备的变动，B服务来做统一的验证，并进行分发；
4）效率：现有的MQ大都是为了解决分布式下的问题，天生带着高性能的特点；分支流程的业务剥离之后，主流程的性能简单、效率；
二：使用MQ带来的问题
当然这些问题，不是纯粹是MQ带来的，大部分都是分布式下的通用问题
1. 消息的可靠性、幂等性
常见的问题有：重复消费、消息丢失、消息的顺序、消息的响应级别等
2.生产、消费消息失败
对于RocketMQ、RabbitMQ有重试队列、死信队列、kafka没有，该怎么处理呢
3.消息的事务保证
对于分布式系统，事务都是一个问题，那MQ怎么保证，有没有失败的场景呢？
4.最终一致性
对于一些业务这个是不能接受的，那就不能考虑MQ了
三：注意事项
MQ虽好，可不要贪杯哦
1.要求高一致性的不适合，比如积分、金钱交易、库存等，需要及时答复的场景；
2.下游的动作需要强顺序性时不适合，比如kafka、RabbitMQ、RocketMQ实现顺序的方式牺牲了高性能，一般采用单点的方式；
3.MQ需要对其实现细节有一定的了解，比如Kafka、RabbitMQ等，需要了解它常用的配置参数，如生产者响应、消费者offset、消费者答复等
四：我工作中的MQ应用
1. 数据同步服务，Service B是管理设备、实体网络的系统，Service A是这些设备的抽象层，展现给用户使用；Service B会有大量的事件上报到Service A，Service A需要做一些校验，并将对应的事件持久化在DB，并加载在cache中，供其他Service使用；
2.Service A 监听用户订单状态改变，主流程是Service B的订单创建、状态改变、取消，并通知用户系统、物流系统、push系统、奖励系统等，完成对应的处理；
网友评论