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