请问有必要用专门的消息队列吗？ all in sqldb 是否可行？

首先是 message 表：

字段名	类型及描述
id	主键
status	消息状态（待处理，进行中，成功，失败）
try_count	消费者重试次数
lock_expires	锁过期时间
created	创建时间
data	消息数据

然后消费端轮询：

select *
from message
where status in ('PENDING', 'STARTED', 'FAILED')
and try_count < max_tries
and lock_expires < now()
order by created
limit 1 for update
skip locked;

解释下 sql：

状态筛选 (status IN ('PENDING', 'STARTED', 'FAILED')) 只选取未开始或已开始但未完成的任务（可能因崩溃需重启）。
重试保护 (try_count < max_tries) 确保任务重试次数未超过允许的最大值（避免无限重试失败任务）。
锁过期检查 (lock_expires < NOW()) 任务被处理时会加锁（设置未来过期时间），此条件筛选锁已过期的任务（说明此前处理进程异常退出）。
排序与限量 (ORDER BY created LIMIT 1) 按创建时间排序后取最旧的一条任务，实现公平调度。
并发控制 (FOR UPDATE SKIP LOCKED)
- FOR UPDATE：锁定所选行，防止其他进程修改。
- SKIP LOCKED：跳过已被其他进程锁定的行，避免阻塞等待，提升并发效率。
- 此语法在 postgresql 、mysql(8.0)均支持。

利用关系数据库持久化消息，支持索引，可以灵活检索，关键是无需额外引入组件，请问这种方案是否可行呢？

codingKingKong

66 天前

1.首先看规模, 如果数据量不大, 资源竞争不严重, 我同意其他人的观点, 怎么搞都行
2.然后还是看规模, 如果都上到 sql 上, 发现性能能接受, 那其实就是合适的方案
3.如果流量再高些, 请考虑 redis, 你可以不用它的 push, pop 这些来实现, 但是它能提供比高并发下 mysql 更好的性能, 毕竟它是做缓存用的
4.如果还有些特殊需求, 请考虑上专业的延迟队列, 例如延迟消费, 自动重试, 精确消费, 至多至少消费语义等, 这些不是 sqldb 不能实现, 而是你需要自己实现, 你需要考虑性价比
最后, 是否有必须要这个问题需要你自己考虑, 不同场景下答案不一样

neilq

66 天前

另针对 redis 消息队列补充一句，现在 redis 5.0 以上不推荐使用 pub/sub ，pub/sub 确实不能持久化。

现在 redis 消息队列推荐使用 redis streams 。不过需要自己实现清理消息的机制。

redis 服务器压力没那么大的情况下不需要考虑持久化稳定性，尤其在你`系统没那么大规模`的情况下。