Postgres 动态创建监听器答案

【问题标题】：Postgres dynamically creating listenersPostgres 动态创建监听器
【发布时间】：2013-11-25 11:07:16
【问题描述】：

我有一个由 postgres 数据库支持的网站。有多个网络服务器，它们维护与每个客户端的持久连接，并且需要通知它们相关事件。来自一个 Web 服务器的更改可能会影响连接到另一个 Web 服务器的用户，因此我需要一些 Web 服务器之间的消息传递层。理想情况下，我想为此使用数据库，以保持简单。

因此，我认为，两种明显的方法是：

1) 让网络服务器监听所有事件，并让网络服务器端过滤对其有用的事件（例如，与它当前连接的用户相关）。

或者：

2) 为每个连接的客户端动态创建一个监听器，并在客户端断开连接时移除该监听器。

第一种方式意味着很多无用的数据通过网络传输，但网络服务器很容易过滤（简单的哈希图查找）。第二种方式看起来很理想如果 postgres 以这样一种方式实现，我可以随时创建数千个（到数万个）听众。

顺便说一句，我正在使用最新版本的 postgres

想法？

非常感谢！

【问题讨论】：

判断 postgres 是否能够处理数千个 LISTEN/NOTIFY 的最简单（也是最准确）的方法是设置一个模拟生产负载的简单测试。跨度>
顺便说一句。您还可以设置一个服务器，它将LISTEN 并将事件转发给在其上注册的客户端（直接或间接通过网络服务器）。或者使用某种中间件消息代理。
3.有一个active_listeners 表并在发出通知之前检查它。
您的问题是关于在 PostgreSQL 中监听事件还是将事件传输到客户端？
两者都是。只想了解拥有数千个听众的性能特征

标签： node.js postgresql

【解决方案1】：

好的，所以要通知客户端，您必须使用某种持久的、有状态的连接，例如 websocket。有很多方法可以解决那里的负载和性能问题，因此我不会过多讨论，因为我们没有足够狭窄的领域来讨论其影响和解决方案。

对于数据库方面，“千”在数据库方面的数量仍然相对较少，并且侦听器不会影响规划器，所以我看不出有什么原因会成为问题。但是，在您朝这个方向发展之前，需要考虑三件事。

数据库连接数。当然，您不希望有数千个数据库连接。疯狂的谎言就是这样。如果您要创建数千个侦听器，则应该使用相对较少的连接数。
这是侦听器的非典型用途，导致数量非典型。仅仅因为我看不出这不起作用的任何原因并不意味着您最终可能不会遇到问题。我做了一些轻量级的测试，并没有发现任何对一万名听众的显着性能影响。我希望每个侦听器都会使用少量内存，并且即使是对侦听器表的顺序扫描也会表现良好（并且如果经常使用它无论如何都会缓存在内存中）。
LISTEN/NOTIFY 提供的安全性非常低。您可能希望将此与存储有效负载的某种表结合起来，而不是在通知语句的有效负载中传递它。与数千个侦听器相比，数千个表更容易导致问题，因为规划者在规划 SQL 语句时必须考虑表的数量。

如果我要这样做，我会设置每个连接声明的客户端目录，并为该连接设置一个侦听器。我还将为有效负载数据设置一个表，并且由于每个连接都会声明该表的一部分，因此您可以有效地忽略数据库端的并发问题。同样，这只是我的解决方案。可能还有其他人。对于大量听众来说，我没有看到任何明显的问题，但请注意，如果你走这条路，那么你正在进入一个领域，这是以前很少有人去过的。不过，我怀疑听众的数量可能是您最不担心的问题。

【讨论】：