本文主要讲解RabbitMQ的介绍和安装,Spring Cloud Stream核心概念,Spring Cloud Alibaba RocketMQ学习,异步消息推送与消费
com/javaedge/contentcenter/service/content/ShareService.java
假设添加积分操作很耗时,我们的主要操作是审核,而不关心积分,所以可以将其异步化
◆ AsyncRestTemplate
Spring 的异步HTTP请求AsyncRestTemplate
◆ @ Async注解
https://spring.io/guides/gs/a...
◆ WebClient ( Spring 5.0引入 ,为取代AsyncRestTemplate)
https://docs.spring.io/spring... RELEASE/spring-framework-reference/web-reactive.html#webflux-client
◆ MQ
我们采用此法
流行的MQ那么多,如何选择?
RocketMQ实战(一) - 简介
content-center
开始拿出三板斧:
无
user-center
com.javaedge.contentcenter.rocketmq.AddBonusTransactionListener
流程剖析、概念术语、
如何实现事务呢,我们知道Spring有事务注解,那么直接就添加@Transaction注解吧!
可这样是万无一失了吗?显然不行,因为消息已经发出,没法撤回了
那么看看RocketMQ是怎么解决分布式事务问题呢
业务流程图
MQServer如果从4中接收到的是
- commit,就把消息置为可投递,这样消费者就可消费该消息了 - rollback:将该消息删除
总体来说,就是生产者把消息发送到MQ,但MQ只是将其标记,不让消费者消费
然后生产者就执行本地事务,执行完后就知道到底是该投递还是丢弃该消息了!
这其实就是典型的二次确认
消费回查就是防止二次确认消息发送异常的容错处理
◆ 半消息( Half(Prepare) Message )
暂时无法消费的消息。生产者将消息发送到了MQ server ,但这个消息会被标记为"暂不能投递"状态,先存储起来;消费者不会去消费这条消息。
并不是消息的状态,只是一种特殊的消息而已
◆ 消息回查(Message Status Check )
网络断开或生产者重启可能导致丢失事务消息的第二次确认。当MQ Server发现消息长时间处于半消息状态时,将向消息生产者发送请求,询问该消息的最终状态(提交或回滚)。
◆ Commit
提交事务消息,消费者可以消费此消息
◆ Rollback
回滚事务消息, broker会删除该消息,消费者不能消费.
◆UNKNOWN
broker需要回查确认该消息的状态
rocketmq_transaction_log
对照上一小节流程图,开始code!
rocketmq
包,并在其中创建一个新类 AddBonusTransactionListener
@RocketMQTransactionListener
注解 其中的txProducerGroup一定要对应哦
注意这里的
本文由博客一文多发平台 OpenWrite 发布!