我有一个由 postgres 数据库支持的网站。有多个 Web 服务器，它们维护与每个客户端的持久连接，并且需要通知它们相关事件。来自一个 Web 服务器的更改可能会影响连接到另一个 Web 服务器的用户，因此我需要一些 Web 服务器之间的消息传递层。理想情况下，我想为此使用数据库，以保持简单。
因此，我看到的两种明显的方法是：
1）让网络服务器监听所有事件，网络服务器端过滤对它有用的事件（例如，与它当前有连接的用户有关）。
或者：
2) 为每个连接的客户端动态创建一个监听器，并在客户端断开连接时移除该监听器。
第一种方式意味着大量无用的数据通过网络传输，但网络服务器很容易过滤（简单的哈希图查找）。如果postgres 以我可以随时创建数千（到数万）个侦听器的方式实现，则第二种方式看起来很理想。
顺便说一句，我正在使用最新版本的 postgres
想法？
非常感谢！
好的，所以要通知客户端，您必须使用某种持久的、有状态的连接，例如 websocket。有很多方法可以解决那里的负载和性能问题，所以我不会讨论太多，因为我们没有足够狭窄的区域来讨论影响和解决方案。
对于数据库方面，“千”在数据库方面的数量仍然相对较少，并且侦听器不会影响规划器，所以我看不出有什么原因会成为问题。但是，在您朝着这个方向前进之前，需要考虑三件事。
数据库连接数。当然，您不希望有数千个数据库连接。疯狂的谎言就是这样。如果你打算做成千上万的听众，它应该是相对少量的连接。
这是听众的非典型使用，导致非典型数量。仅仅因为我看不出这不起作用的任何原因并不意味着您最终可能不会遇到问题。我做了一些轻量级的测试，并没有发现任何对一万名听众的显着性能影响。我希望每个侦听器都会使用少量内存，并且即使是对侦听器表的顺序扫描也会表现良好（并且如果经常使用它无论如何都会缓存在内存中）。
LISTEN/NOTIFY 提供的安全性非常低。您可能希望将此与存储有效负载的某种表结合起来，而不是在通知语句的有效负载中传递它。与数千个监听器相比，数千个表更容易引起问题，因为规划者在规划 SQL 语句时必须考虑表的数量。
如果我要这样做，我将设置每个连接声明的客户端目录，并为该连接设置一个侦听器。我还将为有效负载数据设置一个表，并且由于每个连接都会声明该表的一部分，因此您可以有效地忽略数据库端的并发问题。同样，这只是我的解决方案。可能还有其他人。对于大量听众来说，我没有看到任何明显的问题，但是请注意，如果您走这条路，那么您正在进入领域，而这是以前很少有人去过的。但是，我怀疑听众的数量可能是您最不担心的事情。