RocketMQ常见问题及实现分布式事务时关注问题
RocketMQ实现分布式事务时，需关注的问题
1、MQ半消息回查，若得不到该消息是提交还是回滚，会一直隔一段时间就查询一次吗？
答：为了避免单个消息被检查太多次而导致半队列消息累积，我们默认将单个消息的检查次数限制为 15 次，但是用户可以通过 Broker 配置文件的 transactionCheckMax参数来修改此限制。如果已经检查某条消息超过 N 次的话（ N = transactionCheckMax ） 则 Broker 将丢弃此消息，并在默认情况下同时打印错误日志。用户可以通过重写 AbstractTransactionalMessageCheckListener 类来修改这个行为。
RocketMQ官网解释.
2、二阶段异常，需要回滚怎么处理？
答：这个问题我个人觉得是SEATA和RocketMQ的主要区别：
SEATA在解决分布式事务时，SEATA主要是有四种模式来解决分布式事务，通常用的较多的时AT模式和TCC模式：
1、AT模式涉及到一个全局锁的概念，通过全局锁，来保证二阶段回滚时，一阶段的数据也可以回滚，所以在数据库层性能多少会受到影响
2、TCC模式主要是我们自己控制 资源预留、确认提交、回滚资源释放，也可以回滚一阶段的数据，不过业务侵入度较高
RocketMQ：当二阶段(消费者)逻辑异常时，只能够保证消费者端事务回滚、无法正常消费消息，但是生产者端是无法进行回滚操作的。所以在开发时，通常将容易出现异常的情况放在一阶段(生产者端，例:跨行转账的扣款，下单成功送积分的下单等等)，尽可能保证消费者进行消费时，不会因为业务逻辑不同导致无法正常消费，从而产生的数据不一致的问题。
那，如果真的由于特殊原因，消息一直不能被正确处理，那怎么办 ？
我们考虑两种方式来解决这个问题。
第一，在代码中设置消息重试次数，如果达到指定次数，就发邮件或者短信通知业务方人工介入处理
@Component
public class OrderListener implements MessageListenerConcurrently {
Logger logger = LoggerFactory.getLogger(this.getClass());
@Override
public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> list, ConsumeConcurrentlyContext context) {
logger.info("消费者线程监听到消息。");
for (MessageExt message:list) {
if (!processor(message)){
return ConsumeConcurrentlyStatus.RECONSUME_LATER;
}
}
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
/**
* 消息处理，第3次处理失败后，发送邮件通知人工介入
* @param message
* @return
*/
private boolean processor(MessageExt message){
String body = new String(message.getBody());
try {
logger.info("消息处理....{}",body);
int k = 1/0;
return true;
}catch (Exception e){
if(message.getReconsumeTimes()>=3){
logger.error("消息重试已达最大次数，将通知业务人员排查问题。{}",message.getMsgId());
sendMail(message);
return true;
}
return false;
}
}
}
第二，等待消息重试最大次数后，进入死信队列。
消息重试最大次数默认是16次，我们也可以在消费者端设置这个次数。
consumer.setMaxReconsumeTimes(3);//设置消息重试最大次数
死信队列的主题名称是 %DLQ% + 消费者组名称，比如在订单数据中，我们设置了消费者组名：
String consumerGroup = “order-consumer-group”;
那么这个消费者，对应的死信队列主题名称就是%DLQ%order-consumer-group
可以通过程序代码监听这个死信队列的主题，来通知人工介入处理或者直接在控制台查看处理了。通过幂等性消费和对死信消息的处理，基本上就能保证消息一定会被处理。
3、消费者消费失败后，会重试吗，多次重试后还是失败会怎么样？
答：这个问题其实在第二个问题中已经给出答案了，消息重试最大次数默认是16次，我们也可以在消费者端设置这个次数,当消息消费到达重试最大次数后，进入死信队列
RocketMQ常见的一些疑问或问题
1、如何防止消息丢失的问题(待更新)
消息生产者：消息发送成功也不意味着它是可靠的。要确保不会丢失任何消息，还应启用同步Master服务器或同步刷盘，即SYNC_MASTER或SYNC_FLUSH。
（1.2 消息发送失败处理方式
Producer的send方法本身支持内部重试，重试逻辑如下：
至多重试2次。
如果同步模式发送失败，则轮转到下一个Broker，如果异步模式发送失败，则只会在当前Broker进行重试。这个方法的总耗时时间不超过sendMsgTimeout设置的值，默认10s。
如果本身向broker发送消息产生超时异常，就不会再重试。
以上策略也是在一定程度上保证了消息可以发送成功。如果业务对消息可靠性要求比较高，建议应用增加相应的重试逻辑：比如调用send同步方法发送失败时，则尝试将消息存储到db，然后由后台线程定时重试，确保消息一定到达Broker。）
2、如何防止消息的重复消费问题(幂等性问题)
RocketMQ官网幂等性问题解释.
这个问题官方也指明了实际使用中，可能会存在相同的消息有两个不同msgId的情况（消费者主动重发、因客户端重投机制导致的重复等），这种情况就需要使业务字段进行重复消费。
解决方式:
一、借助关系数据库的唯一ID进行去重。(官网推荐，即使分布式环境也不会出现问题，并发很高的话，可能数据库压力会大些)
二、通过Redis的increment自增操作，通过这一原子性操作来生成唯一ID
三、通过雪花算法生成唯一ID
四、通过UUID生成唯一ID，缺点生成的ID过于随机
扩展：这里和大家简单聊一下雪花算法
网上有部分朋友提出雪花算法会有重复ID出现的情况，这问题是什么原因导致的呢
雪花算法原理可参看: 雪花算法原理解析.
通过对原理的认识，我们可以得出当workerId和datacenterId相同，且是多例模式时，会出现ID重复的情况，我这边也进行了代码测试：
@Component
public class SnowFlakeUtil {
private long workerId = 0L;
private long datacenterId = 1L;
private Snowflake snowflake = IdUtil.createSnowflake(workerId, datacenterId);
@PostConstruct
public void init() {
try {
workerId = NetUtil.ipv4ToLong(NetUtil.getLocalhostStr());
} catch (Exception e) {
workerId = NetUtil.getLocalhostStr().hashCode();
}
}
public synchronized long snowflakeId(long workerId, long datacenterId) {
Snowflake snowflake = IdUtil.createSnowflake(workerId, datacenterId);
return snowflake.nextId();
}
public synchronized long snowflakeId() {
return snowflake.nextId();
}
}
package com.fss.test;
import cn.hutool.core.lang.Snowflake;
import cn.hutool.core.util.IdUtil;
import com.fss.utils.SnowFlakeUtil;
import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.Test;
import javax.annotation.Resource;
import java.util.HashSet;
import java.util.concurrent.*;
/**
测试类
*/
@Slf4j
class SnowFlakeUtilTest extends BaseTest {
@Resource
private SnowFlakeUtil snowFlakeUtil;
@Resource
private SnowFlakeUtil snowFlakeUtil1;
@Resource
private SnowFlakeUtil snowFlakeUtil2;
@Resource
private SnowFlakeUtil snowFlakeUtil3;
/**
* 因为snowFlakeUtil中的snowflakeId方法是synchronized修饰，所以当单机部署下单例模式下生成snowflakeId 是不会出现问题的
*/
@Test
void insert() {
int num = 10000000;
HashSet<Long> set = new HashSet<Long>(new Double(num / 0.75).intValue() + 1);
boolean flag = true;
log.info("开始执行...");
for (int i = 0; i < num; i++) {
if (i % 1000 == 0) {
log.info("当前i为：" + i);
}
flag = set.add(snowFlakeUtil.snowflakeId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
}
}
/**
* 虽然是多线程生成snowflakeId，但是synchronized对对象加锁，故也不会出现问题
*/
@Test
void manyThread() {
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(20, 20, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>());
int num = 10000000;
HashSet<Long> set = new HashSet<>(new Double(num / 0.75).intValue() + 1);
log.info("开始执行...");
for (int i = 0; i < 10000000; i++) {
if (i % 10000 == 0) {
log.info("当前i为：" + i);
}
threadPoolExecutor.execute(() -> {
boolean flag = set.add(snowFlakeUtil.snowflakeId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
});
}
}
/**
* 我本以为这种情况下会出现问题，后面run了几次发现不会抛出异常，仔细想了下，才想起Spring生成bean都是单例模式的，所以虽然定义了多个SnowFlakeUtil实例，
* 但是实际上指向的实例还是同一个，故也不会出现问题
*/
@Test
void manySameSnowFlakeUtillBySpring() {
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(15, 15, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>());
int num = 10000000;
HashSet<Long> set = new HashSet<>(new Double(num * 5 / 0.75).intValue() + 1);
log.info("开始执行...");
for (int i = 0; i < num; i++) {
if (i % 10000 == 0) {
log.info("当前i为：" + i);
}
threadPoolExecutor.execute(() -> {
boolean flag = set.add(snowFlakeUtil1.snowflakeId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowFlakeUtil2.snowflakeId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowFlakeUtil3.snowflakeId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
});
}
}
/**
* 创建多个workerId和datacenterId相同的实例，通过多线程生成snowflakeId，此时就会出现ID重复的问题。
* 这个在单机架构下多个服务器和分布式多服务器，若workerId和datacenterId相同，就有可能会出现ID重复的问题
*/
@Test
void manySameSnowFlakeUtill() {
Snowflake snowflake1 = IdUtil.createSnowflake(0, 1);
Snowflake snowflake2 = IdUtil.createSnowflake(0, 1);
Snowflake snowflake3 = IdUtil.createSnowflake(0, 1);
Snowflake snowflake4 = IdUtil.createSnowflake(0, 1);
Snowflake snowflake5 = IdUtil.createSnowflake(0, 1);
ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(15, 15, 1, TimeUnit.MINUTES, new LinkedBlockingQueue<>());
int num = 10000000;
HashSet<Long> set = new HashSet<>(new Double(num * 5 / 0.75).intValue() + 1);
log.info("开始执行...");
for (int i = 0; i < num; i++) {
if (i % 10000 == 0) {
log.info("当前i为：" + i);
}
threadPoolExecutor.execute(() -> {
boolean flag = set.add(snowflake1.nextId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowflake2.nextId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowflake3.nextId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowflake4.nextId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
flag = set.add(snowflake5.nextId());
if (!flag) {
throw new RuntimeException("存在重复的key");
}
});
}
}
}
那么在单机架构下多个服务器和分布式多服务器下，想使用雪花算法生成唯一ID的解决方式是什么呢？
一、workId使用服务器hostName生成，dataCenterId使用IP生成，这样可以最大限度防止10位机器码重复，但是由于两个ID都不能超过32，只能取余数，还是难免产生重复，但是实际使用中，hostName和IP的配置一般连续或相近，只要不是刚好相隔32位，就不会有问题(不是十分严谨，还有几率重复)
二、启动方式： java -jar -Xms256m -Xmx512m -Dserver.workId=1 -Dserver.datacenterId=1 /home/admin/jars/test.jar ，通过执行workId和datacenterId的方式避免重复，不同的服务器 -Dserver.workId -Dserver.datacenterId设置为不同的值。(部署较为麻烦，还需要更更改对应的脚本文件)
三、（待续更）