rabbitmq中的消息有id吗_Rabbitmq消息队列在生产环境中的应用以及存在问题的解决方案...

消息队列小结

一、什么是消息队列？

消息队列，一般我们会简称它为MQ(Message Queue)。它的结构是先进先出(FIFO)。

二、为什么使用消息队列？

消息队列使用的场景和中间件有很多，但解决的核心问题主要是：削峰、异步、解耦。

削峰：秒杀活动/某些时段系统请求暴涨已经突破了数据库的处理能力。比如说数据库处理能力是每秒2000个请求。但是系统此时达到了每秒1万+的请求,如果这时系统不加处理 就会挂掉。因此 这种情况可以通过MQ作为缓冲,根据系统的处理能力来限流处理这些请求。而不至于把系统打崩。

异步：A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要10ms，BCD三个系统分别写库要300ms、300ms、300ms。最终请求总延时是3 + 300 + 300 + 300 = 903ms。如果把往BCD系统学数据这步操作改为异步执行呢?那对于A系统这个请求只花了 3ms。 比之前同步写库节省了900ms!

解耦：同样是ABCD四个系统，A系统发送个数据到BCD三个系统，接口调用发送，那如果E、F...系统也要这个数据呢？那如果C系统现在不需要了呢？如果现在A系统又要发送第二种数据了呢？ 这时开发人员估计要崩溃.... 而且系统A开发人员还要考虑BCD系统...有没有写库成功？要不要重发？要不要把消息存起来？ 那如果我把这个数据扔到MQ，只要扔成功！ 其他系统爱怎么玩怎么玩。 不管,一劳永逸有木有！

三、使用消息队列带来什么问题？

前面貌似我们用了MQ之后贼爽.. 既挡住了流量高峰,又提高了接口响应时间,还解决了产品经理没完没了的需求... 是不是可以说系统没问题了? 且看! 上线不久后,突然收到反馈: 你怎么重复给我发数据? 你有没有发啊? 我没有收到。。。 一系列问题接踵而至... 此时技术总监走到跟前说:小伙子，过来我办公室，我们聊聊...

技术带来便利的同时也会有负面的东西。技术是把双刃剑！就消息队列来说使用消息队列后会使系统更为复杂，业务需要考虑的地方更多，人力投入成本也会随之增加。

(1) 高可用性

集群(单机模式、普通集群、镜像集群)

(2) 重复消费/重复发送

消费幂等操作

(3) 顺序消费

queue的FIFO特性

(4) 数据一致/消息怎么确保不丢(**)

消息ACK问题/分布式事务问题 (详情看业务实例说明)

3.1业务实例

以TBL和供应链的交互为例,取消订单流程:

用户在TBL发起取消订单,接着TBL通过MQ告诉供应链组去调用唯品的接口取消订单。供应链组调用取消订单成功后修改订单状态 然后再通过MQ告诉TBL订单取消成功。

基于这个流程有没有发现什么问题?

问题一：TBL怎么保证这条消息一定发送成功了?

问题二: 就算TBL确认这天消息一定发送成功了,那万一供应链组这边没有收到呢? 那TBL这边怎么知道这条消息有没有被消费了。自己要不要重新发送?

问题三: 供应链组这边确实收到了消息,调唯品的接口成功了， 订单状态也改成了已取消了,但是在通知TBL过程中失败了... 从而导致两边的数据不一致，怎么解决这问题?

其实不管是该流程还是别的流程，只要引入了MQ 都会遇到这种问题

总结: 问题一和问题二归纳其实是MQ的ACK 问题。

问题三其实是分布式事务问题。

两者的问题其实可以归结为网络问题。

3.2 消息队列RabbitMq的ACK机制

RabbitMq的Ack分两种:

1) 消息发送Ack。这种是用来确认生产者将消息发送给交换器，交换器传递给队列的过程中，消息是否成功投递。

发送确认分为两步骤: 一是确认是否到达交换器，二是确认是否到达队列。

2) 消费者消费Ack。这种是确认消费者是否成功消费了队列中的消息。 (这里包含消息的重回队列及异常重试)

具体代码:

生产端:

消费端:

开关

手动Ack

3.3消息执行问题如何解决

本地消息表最终一致性。

四、最后

本文主要阐述了什么是消息队列，消息队列可以为我们带来什么好处、rabbitMq的ACK、以及引入消息队列可能会涉及到哪些问题/怎么解决这些问题，希望给大家带来一定的帮助。