Richard Yen：使用Postgres作为作业队列的潜在后果
💡
原文英文，约2000词，阅读约需8分钟。
📝
内容提要
使用Postgres作为作业队列在小规模时表现良好，但在高并发情况下会出现性能问题，如CPU使用率上升和表膨胀。多事务锁定导致的SLRU争用和死元组积累会使系统变慢。因此，建议在高并发场景下考虑使用轻量级顾问锁、pgq、Redis或Kafka等专用解决方案，以提高效率和可扩展性。
🎯
关键要点
-
在小规模时，使用Postgres作为作业队列是可行的，但在高并发情况下会出现性能问题。
-
高并发下，CPU使用率上升，表膨胀，导致系统变慢。
-
多事务锁定导致的SLRU争用和死元组积累是主要问题。
-
建议在高并发场景下使用轻量级顾问锁、pgq、Redis或Kafka等专用解决方案。
-
顾问锁可以避免行级锁定，减少MVCC开销，但需要手动处理锁释放。
-
pgq和PgQue是基于Postgres的队列实现，能够避免行级锁定的问题。
-
Redis提供低延迟的作业调度，但在持久性方面存在风险。
-
Kafka适合处理高吞吐量的分布式工作负载，提供事件重放能力。
-
选择合适的工具取决于并发工作者的数量和作业的复杂性。
❓
延伸问答
使用Postgres作为作业队列的主要问题是什么？
在高并发情况下，Postgres会出现CPU使用率上升、表膨胀和SLRU争用等性能问题。
在高并发场景下，Postgres的哪些特性会导致性能下降？
多事务锁定导致的SLRU争用和死元组积累是主要原因。
有哪些替代Postgres的作业队列解决方案？
可以考虑使用轻量级顾问锁、pgq、Redis或Kafka等专用解决方案。
Redis作为作业队列的优缺点是什么？
Redis提供低延迟的作业调度，但在持久性方面存在风险。
使用Postgres作为作业队列时，如何减少表膨胀问题？
可以通过更积极地运行VACUUM或对表进行分区来减轻表膨胀问题。
在什么情况下使用Postgres作为作业队列是合适的？
在并发工作者少于100个且作业简单的情况下，使用Postgres是合适的。
➡️
