我们需要建立一个系统，其中多个进程在同一个数据集上工作。我们的想法是拥有一组可以被我们的工作进程（异步）拉出的元素（即没有重复的值）。这些流程可能分布在多个服务器上，因此我们需要一个分布式解决方案。
目前，我们正在考虑的模式是使用Redis来保存一个包含工作数据的集合。每个进程都应连接到该集，并从中弹出一个值。 spop的随机功能对我们来说实际上是一个加分，因为我们需要随机访问集合中的元素。必须从我们的主PostgreSQL数据库中填充数据。
就像我说的，我们还有一个可供查询的PostgreSQL数据库，进程在请求元素时可以访问。但是，我们不知道是否在重载下可能成为瓶颈。我们确实希望在这个子系统上进行繁重的并发访问（考虑数百甚至数千个进程）。
如果它与此有任何关联，我们使用带rQ的Python来处理异步任务（作业和工作者）。
编辑：就大小而言，元素可能不会很大 - 顶部大小应该在500到1000字节左右。它们基本上是URL，所以除非发生奇怪的事情，否则它们应该远低于这个大小。元素的数量将取决于并发进程的数量，因此大约10-50 K元素可能是一个很好的球场。请记住，这更像是一个临时区域，所以重点应该放在速度上而不是尺寸上。
总之，我的问题是：
在使用多个进程时，Redis是否为共享访问设置好主意？是否有任何数据可以让我们知道该解决方案将如何扩展？如果是的话，你能提供任何指示或建议吗？
填充共享数据时，什么是一个好的更新策略？
非常感谢！
答案 0 :(得分：2)
不是完整的答案，只是一些想法： 就像它说的那样，Redis在内存中维护你的设置，所以为了回答1你需要考虑或者至少估计一个最糟糕的情况：
估算后，您可以计算并查看是否可以使用Redis：
例如，拥有100个字节的元素并期望“非常重”的1.000.000元素的负载，你需要至少100MB的内存才能用于Redis，使用它甚至便宜是可行的。但是如果你每个元素需要500个字节而你的重负载意味着30.000.000元素然后你需要15GB的内存，它甚至可行但是使用你的postgre数据库可能太昂贵了，这导致你需要的第二个估计：
通过一些估算可以帮助您确定哪种解决方案最符合您的要求/预算。