消息队列的发送方式及使用场景
发送方式一般分三种：
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
