【发布时间】：2012-12-15 18:55:25
【问题描述】：
我们需要建立一个系统，让多个进程在同一个数据集上工作。这个想法是有一组可以被我们的工作进程（异步）拉取的元素（即没有重复的值）。进程可能分布在多台服务器上，因此我们需要一个分布式解决方案。
目前，我们正在考虑的模式是使用 Redis 来保存一个集合，该集合保存工作数据。每个进程都应该连接到集合，并从中弹出一个值。 spop 的随机功能实际上对我们来说是一个加分项，因为我们需要随机访问集合中的元素。数据必须从我们的主 PostgreSQL 数据库中填充。
就像我说的，我们还有一个 PostgreSQL 数据库可供查询，进程可以在请求元素时访问该数据库。但是，我们不知道在重负载下是否会成为瓶颈。我们确实期望在这个子系统上进行大量 - 到非常大量的并发访问（想想数百甚至数千个进程）。
如果与此相关，我们使用 Python 和 rQ 来处理异步任务（作业和工作人员）。
编辑：就大小而言，预计元素不会很大 - 顶部大小应该在 500 - 1000 字节左右。它们基本上是 URL，因此除非发生奇怪的事情，否则它们应该远低于该大小。元素的数量将取决于并发进程的数量，因此大约 10 - 50 K 的元素可能是一个不错的选择。请记住，这更像是一个临时区域，因此应该更关注速度而不是大小。
总的来说，我的问题是：
在使用多个进程时，Redis 设置是否适合共享访问？是否有任何数据可以让我们知道该解决方案将如何扩展？如果是这样，您能提供任何指示或建议吗？
填充共享数据时，什么是好的更新策略？
非常感谢！
【问题讨论】：
-
Redis 在内存中，所以速度很快，“冲突”的可能性更小，但是，在我看来，如果你不想要意外的结果，你仍然需要管理某种队列
-
好的，您能详细说明一下吗？ “意想不到的结果”是什么意思？当您说队列时，您的意思是使用它作为数据结构来存储我们要获取的元素？
-
不，我又读了一遍，你不介意随机结果。我想那没有问题。也就是说，没有队列...
-
您可能对PGQ“实时交易的异步批处理”感兴趣。
-
谢谢，但我认为该用例不适合 PGQ（即合作消费者，而不是广播“听众”）。不过，很棒的建议。
标签： postgresql asynchronous redis queue distributed-computing