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

Question

我们需要建立一个系统,其中多个进程在同一个数据集上工作.我们的想法是拥有一组可以被我们的工作进程(异步)拉出的元素(即没有重复的值).这些进程可能分布在多个服务器上,因此我们需要一个分布式解决方案.

目前,我们正在考虑的模式是使用Redis来保存一个包含工作数据的集合.每个进程都应连接到该集,并从中弹出一个值.随机功能spop对我们来说实际上是一个加分,因为我们需要随机访问集合中的元素.必须从我们的主PostgreSQL数据库填充数据.

就像我说的,我们还有一个可供查询的PostgreSQL数据库,进程在请求元素时可以访问.但是,我们不知道是否在重载下可能成为瓶颈.我们确实希望在这个子系统上进行繁重的 - 非常繁重的并发访问(想想数百甚至数千个进程).

如果它与此有任何关联,我们使用Python rQ来处理异步任务(作业和工作者).

编辑:就大小而言,元素可能不会很大 - 顶部大小应该在500-1000字节左右.它们基本上是URL,所以除非发生奇怪的事情,否则它们应该远低于这个大小.元素的数量将取决于并发进程的数量,因此大约10-50 K元素可能是一个很好的球场.请记住,这更像是一个临时区域,因此重点应放在速度上而不是尺寸上.

总之,我的问题是:

1. 在使用多个进程时,Redis是否为共享访问设置了一个好主意？是否有任何数据可以让我们知道该解决方案将如何扩展？如果是这样,你能提供任何指示或建议吗？

2. 填充共享数据时,什么是一个好的更新策略？

非常感谢你!

Answer 1

不是完整的答案，只是一些想法：就像所说的那样，Redis 将您的集合保存在内存中，因此为了回答 1，您需要考虑或至少估计最坏的情况：

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

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

例如，拥有 100 字节的元素并期望 1.000.000 个元素的“非常重”负载，您将需要至少 100MB 的内存用于 Redis，并且使用它是可行的，甚至便宜。但是如果您需要 500 字节每个元素和你的重负载意味着 30.000.000 个元素，那么你需要 15GB 内存，它甚至是可行的，但与使用 postgre 数据库相比可能太贵了，这导致了你需要的第二个估计：

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

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