我们需要建立一个系统，其中多个进程在同一数据集上工作。这个想法是有一组元素(即没有重复的值)，可以被我们的工作进程(异步)拉出。进程可能分布在多个服务器上，因此我们需要一个分布式的解决方案。
目前，我们正在考虑的模式是使用Redis来保存一个集合，它保存工作数据。每个进程都应该连接到该集合，并从中弹出一个值。spop的随机功能实际上对我们来说是一个加分项，因为我们需要随机访问集合中的元素。数据必须从我们的主PostgreSQL数据库中填充。
就像我说的，我们也有一个PostgreSQL数据库可供查询，进程可以在请求元素时访问它。但是，我们不知道在重载情况下这是否会成为瓶颈。我们确实希望在这个子系统上有重并发访问(考虑数百甚至数千个进程)。
如果它与此相关，我们使用Python和rQ来处理异步任务(作业和工人)。
编辑:在大小方面，元素可以预期不是非常大-顶部大小应该在500 - 1000字节左右。它们基本上是url，所以除非发生奇怪的事情，否则它们应该远远小于这个大小。元素的数量将取决于并发进程的数量，所以大概10 - 50k个元素会比较合适。请记住，这更像是一个登台区，因此应该更多地关注速度而不是大小。
总结一下，我的问题是:
-
当使用多个进程时，Redis设置是共享访问的好主意吗?有没有什么数据可以让我们知道这个解决方案是如何扩展的?如果是这样，你能提供一些指导或建议吗?
-
在填充共享数据时，什么是好的更新策略?
非常感谢!
不是一个完整的答案，只是一些想法:就像刚才说的，Redis在内存中维护你的集合，所以为了回答1，你需要考虑或至少估计最坏的情况:
- 每个元素需要多少内存空间?
- 有多少(数量)元素是非常重的负载
一旦你有一个估计，你可以计算，看看是否可行使用Redis:
例如，拥有100字节的元素，并期望"非常重"的负载为1,000.000个元素，您将需要至少100MB的内存，仅用于Redis，这是可行的，甚至便宜。但是如果你需要每个元素500字节，你的重载意味着30000.000个元素，那么你需要15GB的内存，这甚至是可行的，但可能太贵了，相比使用你的postgre数据库，什么导致你需要的第二次估计:
- 你将对你的Redis/Postgre服务器有多少请求/秒(总共)，或者你期望有多少进程发出请求，每个进程将发出多少请求/秒。
有一些估计可以帮助你决定什么解决方案最适合你的需求/预算。