目前,我们正在考虑的模式是使用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服务器提出多少请求/秒(总计),或者您希望提出请求的进程数以及每个进程将进行多少/秒.
通过一些估算可以帮助您确定哪种解决方案最符合您的要求/预算.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。