coolmq
coolmq copied to clipboard
消息最终一致性方案,基于rabbitmq的分布式事务解决方案
1.如果没用你封装的注解,报错 2.使用你封装的注解,redis地址配置不生效 后面我就不想修改了.不知道怎么上的生产
coordinator.setMsgReady(bizName, rabbitMetaMessage); coordinator.setMsgSuccess(msgId); 发送消息确认的回调的key都不一样 搞锤子 浪费我时间恶心人
pom问题
com.itmuch.cloud spring-cloud-microservice-study 0.0.1-SNAPSHOT parent里面报错,大神方便解答下么?

这段代码如何与DeadLetterMessageListener的onMessage联系起来(这段代码如何生效的?) // 入死信队列 channel.basicReject(deliveryTag, false);
微信里longer童鞋提出这样的问题: 1. 执行业务操作 2. 发送消息成功( 此时事务还未提交) 3. 遇到机器挂了的极端情况 此时业务操作事务还未提交,但消息已经发送了,于是出现不一致的情况 如果把提交放到前面 1 执行业务操作-> 2 提交-> 3 发送消息 但此时如果2提交后机器挂了,又会出现不一致的情况。因为发消息是一个异步的过程,是没法在一个事务中进行控制的,即使用事务的传播特性: 事务A: 事务B:执行业务操作 发送消息 B先提交,如果A失败B也会回滚。但即使这样,如果B后面一步出现断电等极端情况依然会产生不一致 考虑到断电的极端情况,必须要有第三方守护进程来进行一个判断,于是可以使用如下的逻辑: 1. db记录“我要做业务操作啦” 2. 执行业务操作 3. 发送消息 4. 如果消息成功,在消息确认时将db中“我要做业务操作啦”删除。...
  
abstractmessagelistener onmessage中increment出现两次有问题吧?还有建议代码重构下。
```java // 消息发送到RabbitMQ交换器后接收ack回调 rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> { if(returnFlag){ logger.error("mq发送错误,无对应的的交换机,confirm回掉,ack={},correlationData={} cause={} returnFlag={}", ack, correlationData, cause, returnFlag); } logger.info("confirm回调,ack={} correlationData={} cause={}", ack, correlationData, cause); String msgId = correlationData.getId(); /** 只要消息能投入正确的消息队列,并持久化,就返回ack为true*/ if(ack){...