MQ 选型：非大数据场景rocketmq 延迟消息即可、大数据kafka吞吐量高

XXL-Job，

延迟队列
	前置知识
		延迟队列
			延迟消息：特殊的延迟队列的应用
		其他消息队列的解决方案
			RocketMQ 自带特性
			RabbitMQ
				ttl + 死信队列
				rabbitmq_delayed_message_exchange
					消息丢失问题
					不支持高并发
				自定义插件
	基础方案
		定时任务调度
		分区设置不同延迟时间
			组件：delay_topic、延迟消费组、biz_topic
			要点
				业务发送者将请求发到 delay_topic
				延迟消费组消费 delay_topic
				每一个消费者根据延迟时间睡眠
				睡醒之后转发消息到 biz_topic
			亮点
				rebalance 问题：核心是 Pause + Resume
				一致性问题：要求消费者幂等
			优缺点
				优点：简单
				缺点：延迟时间必须预设好；分区间负载不均匀
	亮点：基于 MySQL 的方案
		组件：delay_topic、延迟消费者、延迟发送者、MySQL、biz_topic
		要点
			业务发送者将消息发送到 delay_topic 里
			延迟消费者消费 delay_topic 里面的消息，转存到数据库里
			延迟发送者轮询数据库中的消息，到时候转发 biz_topic
			延迟发送者将数据库中的状态更新为已发送
		亮点
			分区表：根据并发和数据量，按日、周、天、小时来分
			表交替
			分库分表
				分库分表方案——按照 biz_topic 分；轮询
				延迟消息有序性
					同一个 biz_topic 发送到同一个 delay_topic 的分区
					同一个 biz_topic 存到同一张表
			批量操作
				延迟消费者批量插入
				延迟发送者批量更新
	基于 xxl-job 的方案
		组件：xxl-job 调度平台、业务系统、消息处理器
		要点
			业务系统发送延迟消息时，记录延迟时间、业务数据和处理逻辑
			通过 xxl-job 配置定时任务，在指定时间点执行消息处理逻辑
			任务执行时从存储（如数据库）获取待处理消息并处理
		亮点
			依托成熟分布式任务调度平台，可靠性高，支持分片、故障转移
			与现有任务调度体系易整合，适合多定时任务场景
		优缺点
			优点：调度能力强，支持复杂定时策略，易于监控管理
			缺点：依赖外部平台，极高并发场景性能可能受限
	基于 Redis 的方案
		实现方式一：ZSet + 定时轮询
			组件：Redis ZSet、生产者、消费者、定时轮询程序
			要点
				生产者将延迟消息存入 ZSet，score 为延迟执行时间戳，value 为消息内容
				定时轮询程序/消费者定期查询 ZSet 中 score < 当前时间的消息
				处理消息后从 ZSet 中移除
			亮点：实现简单，Redis 性能高，适合高并发场景
			优缺点
				优点：性能好、延迟低、实现成本低
				缺点：轮询有资源消耗，极端情况存在处理延迟
		实现方式二：过期键通知 + 消费者
			组件：Redis 键、过期通知、消费者程序
			要点
				生产者将延迟消息作为 Redis 键，设置过期时间为延迟时间
				开启 Redis 过期键通知功能
				消费者订阅过期键通知，收到后处理消息
			亮点：无需轮询，由 Redis 主动通知
			优缺点
				优点：实现简单，无轮询开销
				缺点：过期通知可靠性不足（可能丢失），集群模式下存在问题，不适合关键业务