所以我看到的两个显而易见的方法是:
1)让网络服务器监听所有事件,并且网络服务器端过滤那些对它有用的事件(例如,与它当前有连接的用户有关).
要么:
2)为每个连接客户端动态创建一个监听器,并在客户端断开连接时删除监听器.
第一种方式意味着很多无用的数据通过网络,但网络服务器很容易过滤(一个简单的hashmap查找).第二种方式看起来很理想,如果postgres以这样的方式实现,即我可以随时创建数千(至数万)的侦听器.
顺便说一下,我正在使用最新版本的postgres
思考?
非常感谢!
解决方法
对于数据库方面,“数千”在数据库方面的数量仍然相对较少,而且听众不会影响规划器,所以我没有看到任何理由为什么这会成为问题.但是,在你走向这个方向之前,有三件事需要考虑.
>数据库连接数.当然,您不需要数千个数据库连接.那种疯狂就是谎言.如果你要成千上万的听众,它应该是相对少量的连接.
>这是对听众的非典型使用,导致非典型数量.仅仅因为我没有看到为什么这不起作用的任何理由并不意味着你最终可能不会遇到问题.我做了一些轻量级测试,并没有发现一万名听众有任何重大的性能影响.我希望每个监听器都会使用少量内存,即使是对监听器表的顺序扫描也能很好地执行(如果频繁使用,它仍然可以缓存在内存中).
> LISTEN / NOTIFY提供的安全性很低.您可能希望将此与存储有效负载的某种表耦合,而不是在notify语句的有效负载中传递它.成千上万的表比成千上万的监听器更容易引起问题,因为规划人员在规划sql语句时必须考虑表的数量.
如果我这样做,我会设置每个连接声明的客户端的目录,并为该连接设置一个监听器.我还会为有效负载数据设置一个表,并且由于每个连接都会声明该表的一部分,因此您可以有效地忽略数据库端的并发问题.再一次,这只是我的解决方案.可能还有其他人.我没有看到任何明显的问题给大量的听众,但要注意你正在进入领域,如果你这样做,很少有人去过.我怀疑,听众的数量可能是你最不担心的.