Postgresql 如何在多个进程之间共享一组数据？

我们需要建立一个系统，让多个进程在同一个数据集上工作。其思想是拥有一组元素（即没有重复的值），这些元素可以由我们的工作进程（异步）提取。这些进程可能分布在多个服务器上，因此我们需要一个分布式解决方案

目前，我们正在考虑的模式是使用Redis保存一个集合，该集合保存工作数据。每个进程都应该连接到集合，并从中弹出一个值。

spop

的随机功能实际上对我们有利，因为我们需要对集合中的元素进行随机访问。数据必须从我们的主PostgreSQL数据库中填充

正如我所说，我们还有一个PostgreSQL数据库可供查询，进程在请求元素时可以访问该数据库。然而，我们不知道在重载情况下，这是否会成为瓶颈。我们确实期望在这个子系统上有大量到非常大量的并发访问（想想成百上千个进程）

如果与此相关，我们将使用Python和

rQ

来处理异步任务（作业和工人）

编辑：就大小而言，可以预期元素不会很大-顶部大小应该在500-1000字节左右。它们基本上都是URL，所以除非发生什么奇怪的事情，否则它们的大小应该远远小于这个大小。元素的数量将取决于并发进程的数量，因此大约10-50K元素将是一个很好的标准。请记住，这更像是一个分级区域，所以重点应该放在速度上，而不是大小上

总而言之，我的问题是：

当使用多个进程时，Redis set是共享访问的好主意吗？是否有任何数据可以让我们知道该解决方案将如何扩展？如果是的话，你能提供一些建议吗

填充共享数据时，什么是好的更新策略

---

多谢各位

不是完整的答案，只是一些想法： 如前所述，Redis将您的设置保存在内存中，因此为了回答1，您需要考虑或至少估计以下情况的最坏情况：

• 集合中的每个元素需要多少内存空间
• 有多少（数量）元素是非常重的负载

一旦你有了一个估计，你就可以计算并看看使用Redis是否可行：

例如，拥有100字节的元素，并期望1.000.000个元素的“非常重”负载，仅Redis就需要至少100MB的内存，使用它是可行的，甚至是便宜的。但如果每个元素需要500字节，而重负载意味着30.000.000个元素，则需要15GB的内存，这甚至是可行的，但与使用postgre db相比可能过于昂贵，是什么导致您需要进行第二次评估：

• 您对Redis/Postgre服务器每秒（总共）有多少个请求，或者您希望发出请求的进程数以及每个进程每秒发出的请求数

---

进行一些估算可以帮助您决定哪种解决方案最适合您的需求/预算。

Redis在内存中，因此速度快，发生“冲突”的可能性小，但在我看来，如果您不希望出现不期望的结果，您仍然需要管理某种队列OK，请详细说明一下好吗？“意外结果”是什么意思？当你说队列时，你的意思是用它作为数据结构来存储我们想要获取的元素吗？不，我又读了一遍，你不介意随机结果。我想没有问题了。也就是说，没有队列……您可能对“实时事务的异步批处理”感兴趣。谢谢，但我认为该用例不适合PGQ（即合作消费者，而不是广播“侦听器”）。不过，这是一个很好的建议。