我们需要建立一个系统，让多个进程处理同一个数据集。我们的想法是拥有一组可以被我们的工作进程(异步)拉取的元素(即没有重复的值)。进程可能分布在多个服务器上，因此我们需要一个分布式的解决方案。
目前我们想到的模式是用Redis做一个集合，这个集合保存工作数据。每个进程都应该连接到集合，并从中弹出一个值。 spop 的随机功能实际上对我们来说是一个优势，因为我们需要随机访问集合中的元素。数据必须从我们的主 PostgreSQL 数据库中填充。
就像我说的，我们还有一个可供查询的 PostgreSQL 数据库，进程可以在请求元素时访问该数据库。但是，我们不知道在重负载下是否会成为瓶颈。我们确实希望在此子系统上进行大量到非常大量的并发访问(想想成百上千个进程)。
如果它与此有任何关联，我们将使用 Python 和 rQ 来处理异步任务(作业和工作人员)。
编辑:就大小而言，元素预计不会很大 - 最大大小应该在 500 - 1000 字节左右。它们基本上是 URL，因此除非发生奇怪的事情，否则它们应该远小于该大小。元素的数量将取决于并发进程的数量，因此大约 10 - 50 K 元素可能是一个不错的选择。请记住，这更像是一个暂存区，因此应该更多地关注速度而不是大小。
总的来说，我的问题是:
在使用多个进程时，Redis 集是否是共享访问的好主意？是否有任何数据可以让我们知道该解决方案将如何扩展？如果是这样，您能否提供任何指示或建议？
填充共享数据时，什么是好的更新策略？
非常感谢!
最佳答案
不是一个完整的答案，只是一些想法: 就像有人说的那样，Redis 在内存中维护你的集合，所以为了回答 1 你需要考虑或至少估计最坏的情况:
- 集合中的每个元素需要多少内存空间
- 有多少(数量)元素是一个很重的负载
一旦有了估算，您就可以计算并查看使用 Redis 是否可行:
例如，具有 100 个字节的元素并期望“非常重”的 1.000.000 个元素负载，您将需要至少 100MB 的内存仅用于 Redis，并且使用它是可行的，甚至便宜。但是如果您每个元素需要 500 个字节，而你的重负载意味着 30.000.000 个元素，那么你需要 15GB 的内存，它甚至是可行的，但与使用你的 postgre 数据库相比可能太贵了，导致你需要的第二个估计:
- 您将有多少请求/秒(总共)针对您的 Redis/Postgre 服务器，或者您希望有多少进程发出请求以及每个进程每秒将发出多少请求。
进行一些估算可以帮助您确定最适合您的要求/预算的解决方案。
关于postgresql - 如何在多个进程之间共享一组数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14104572/