9

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

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

就像我说的，我们还有一个 PostgreSQL 数据库可供查询，进程可以在请求元素时访问它。但是，我们不知道在重负载下是否会成为瓶颈。我们确实期望在这个子系统上进行大量 - 到非常大量的并发访问（想想数百甚至数千个进程）。

如果它与此相关，我们将使用 PythonrQ来处理异步任务（作业和工作人员）。

编辑：就大小而言，预计元素不会很大 - 顶部大小应该在 500 - 1000 字节左右。它们基本上是 URL，因此除非发生奇怪的事情，否则它们应该远低于该大小。元素的数量将取决于并发进程的数量，因此大约 10 - 50 K 的元素可能是一个不错的选择。请记住，这更像是一个暂存区域，因此应该更多地关注速度而不是大小。

总而言之，我的问题是：

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

  2. 在填充共享数据时，什么是好的更新策略？

非常感谢你！

4

1 回答 1

3

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

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

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

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

  • How many requests/second (in total) you will have against your Redis/Postgre server, or how many processes you expect to be making requests and how many/second each process will make.

Having some estimates can help you decide what solution is the best for your requirements/budget.

于 2012-12-31T21:21:05.527 回答