我曾经是一家公司的CTO,这家公司的所有服务每天处理大约10万次请求
我曾经是一家公司的CTO,这家公司的所有服务每天处理大约10万次请求。我们逐渐增长到数百万次,最终达到数千万次,但在这个过程中,我们团队的一名工程师决定利用LISTEN/NOTIFY语义来构建一个队列,以便利用与我们其他数据模型一致的强一致性,这在当时看起来是合理的,因为LISTEN/NOTIFY并不难理解,而我们确实需要这个工作流的一致性保证,这将消除另一个数据存储和传输的地方。但实际上,这最终变得非常棘手,因为要扩展功能(因为我们“自己”构建了它),不得不绕过内部的pg语义(我们早就应该更快地迁移出去了)。它也很难扩展。我们最终在RDS实例上遇到了很多磁盘争用问题,而且这些问题是非显而易见的,该表的vacuum运行简直是一场噩梦。…
源讨论Postgres的LISTEN/NOTIFY实际上是可以扩展的原帖 84 条评论 · 导入时统计