消息队列（MQ）

消息队列的发送方式及使用场景

发送方式一般分三种：
SYNC 同步发送
应用场景：重要通知邮件、报名短信通知、营销短信系统等

ASYNC 异步发送
应用场景：对RT时间敏感,可以支持更高的并发，回调成功触发相对应的业务，比如注册成功后通知积分系统发放优惠券

ONEWAY 无需要等待响应
应用场景：主要是日志收集，适用于某些耗时非常短，但对可靠性要求并不高的场景, 也就是LogServer, 只负责发送消息，不等待服务器回应且没有回调函数触发，即只发送请求 不等待应答

发送方式汇总对比：

发送方式	发送TPS	发送结果反馈	可靠性
同步发送	快	有	不丢失
异步发送	块	有	不丢失
单向发送	最快	无	可能丢失

延迟消息的使用场景

延迟消息介绍：
Producer 将消息发送到消息队列 broker服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费。

使用场景：

• 通过消息触发一些定时任务，比如在某一固定时间点向用户发送提醒消息
• 消息生产和消费有时间窗口要求，比如在天猫电商交易中超时未支付关闭订单的场景，在订单创建时会发送一条 延时消息。这条消息将会在 30分钟后投递给消费者，消费者收到此消息后需要判断对应的订单是否已完成支付。 如支付未完成，则关闭订单。如已完成支付则忽略。

消息队列如何避免重复消费

幂等性：一个请求，不管重复来多少次，结果是不会改变的。
RabbitMQ、RocketMQ、Kafka等任何队列不保证消息不重复，如果业务需要消息不重复消费，则需要消费端处理业务消息要保持幂等性。

• 方式一：Redis的setNX() , 做消息id去重，Java版本目前不支持设置过期时间

//Redis中操作，判断是否已经操作过 TODO
boolean flag = jedis.setNX(key);
if(flag) {
    //消费
} else {
    //忽略，重复消费
}

• 方式二：Redis的 Incr 原子操作：key自增，大于0 返回值大于0则说明消费过，(key可以是消息的MD5取值，或者如果消息id设计合理直接用id做key)

int num = jedis.incr(key);
if(num == 1) {
    //消费
} else {
    //忽略，重复消费
}

• 方式三：数据库去重表：设计一个去重表，某个字段使用Message的key做唯一索引，因为存在唯一索引，所以重复消费会失败

CREATE TABLE message_record (
	id int(11) unsigned NOT NULL AUTO_INCREMENT,
	key varchar(128) DEFAULT NULL,
	create_time datetime DEFAULT NULL,
	PRIMARY KEY (id),
	UNIQUE KEY key (key)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

消息队列之消息发生大量堆积应该怎么处理

问题：线上故障了，消息堆积了10小时，有几千万条消息待处理，现在怎么办？

核心思想：紧急临时扩容，更快的速度去消费数据

修复Consumer不消费问题，使其恢复正常消费，根据业务需要看是否要暂停

临时topic队列扩容，并提高消费者能力，但是如果增加Consumer数量，但是堆积的topic里面的message queue数量固定，过多的consumer不能分配到message queue

编写临时处理分发程序，从旧topic快速读取到临时新topic中，新topic的queue数量扩容多倍，然后再启动更多consumer进行在临时新的topic里消费

直到堆积的消息处理完成，再还原到正常的机器数量

RocketMQ的一个topic下存在多个queue
Kafka的一个topic下存在多个partition