关于Mq你必须要知道的那些知识点
文章目录
关于Mq你必须要知道的那些知识点
前言一、MQ的功能场景1.解耦2.削峰填谷3.最终一致性
二、MQ的幂等性问题1.非幂等性产生的原因2.非幂等解决方案
三、MQ的发布订阅模式和设计模式的观察者模式对比
前言
记录一下自己学习MQ的一些知识点，希望可以帮助到小伙伴们，说的不对的地方希望大家指正
一、MQ的功能场景
1.解耦
解耦分为空间解耦和时间解耦，比如生产者不需要知道消费者的存在，消费者也不需要知道生产者的存在，生产者和消费者不相互依赖，这样就实现了空间解耦。 生产者将消息发送到队列后实际上是不关心消费者什么时候去消费数据。消费者可以实时去消费，也可以根据自己的业务逻辑判断什么时候去消费。因为队列可以存储数据，这样就实现了时间的解耦。
2.削峰填谷
比如订单系统通过RPC调用库存系统，在流量高峰时订单量非常多，而且生成的速度非常快，势必会对库存系统造成较大的压力，库存系统的服务器利用率比较高。而在非高峰时，订单量又比较少，库存系统服务器利用率又比较低，对库存系统来说，就会出现高峰波谷现象。 如果通过MQ的方式，将订单存储在MQ队列中，消费端通过拉取方式来消费数据，并且拉取速度由消费端来控制，则可以控制流量趋于平稳。这样对于库存系统来说，就达到了削峰填谷的目的
3.最终一致性
以订单系统和库存系统为例，用户购买了一件商品，在支付成功后订单系统会立即更新状态为已支付。那么库存系统要保持和订单系统相同的状态，即从库存系统里面将该商品数量减一。订单系统会涉及到两个操作。修改状态和发送MQ。我们可以把两个动作放在一个事务中，要么成功，要么失败。当第一次发送MQ失败后，可以结合定时任务进行补偿，这样可以保证生成订单的结果落地到MQ存储中。同样库存系统消费端依靠MQ重试机制一直触发消息，直到消费端最终确认库存系统减库存处理完成。通过消息落地加补偿，消费端从业务上考虑重复消费的保障，做好幂等性操作，利用MQ实现最终的一致性
二、MQ的幂等性问题
1.非幂等性产生的原因
大多数消息中间件产品都要保证消息一定投递成功，但同时要确保消息不重复投递就非常困难了，这种情况下，消息中间件为确保消息不丢失宁可让消息重复。而分布式环境下最不稳的的就是网络因素，网络因素造成的消息重复主要有两种 1。发送消息时重复 消费者将消息发送给MQ服务端，如果服务端返回生产者响应时闪断，那么生产者认为消息没有发送成功，会尝试第二次发送，造成服务端存储了两份消息 2。消费消息时重复 消息消费端在第一次消费服务端上面的消息时，出现网络闪断。为例确保消息一定投递，在网络恢复时MQ服务端会尝试第二次投递（这里要看PUSH模式还是PULL模式），那么消费端会受到两份消息
2.非幂等解决方案
生产者要做好确保消息一定会成功投递，对于没有成功投递的消息，可以借助定时任务做补偿。消费者要根据具体的业务逻辑，在消费消息时做响应的判断处理，确保重复的消息只会被消费一次。比如订单系统和库存系统，成功支付后，订单状态的改变和投递MQ在一个事务中，如果两个操作有一个失败，就在数据库将该订单状态标注为n,借助定时任务对订单状态为n的数据进行再次修改状态和投递，确保消息一定会成功投递。消费者在进行消费的时候，要记录该条订单是否已经见过库存，确保消息重复投递时不会被二次消费
三、MQ的发布订阅模式和设计模式的观察者模式对比
订阅发布模式下多了队列，这样发布者和订阅者是彻底解耦的。但是观察者模式下，被观察者触发事件时会通知所有的观察者，在该模式下通信一般是同步的
