【问题标题】:multitenancy using namespace api in Push Queue(GAE)在推送队列(GAE)中使用命名空间 api 的多租户
【发布时间】:2018-08-23 03:06:24
【问题描述】:

计划使用命名空间 API 来为我们的 GAE 应用程序提供多租户支持,因此正在查看 namespace API documentation,这表明命名空间 API 支持推送队列,但并未完全解释命名空间如何用于推送队列。

因此,理想情况下,我们想要将任务推送到队列 A 中,并为每个命名空间分别处理它。也就是说,如果在带有 namespace-Xqueue-A 中有 100 个任务在等待,而 namespace-Y 只有 5 个任务,那么 命名空间-Y 的 任务不应等待命名空间-x 中的 100 个任务完成。

例如:-

队列名称- queue-A
客户- client-X & client-Y

现在 client-X 和 client-Y 都被推入 queue-A,命名空间名称分别为 XY。所以我们对命名空间的期望是,如果队列-A 中有很多 client-X 的工作日志不应该影响 client-Y 的 任务处理速度

这是否会在命名空间 API 中自动处理,因为我认为这是多租户应用程序中非常常见的场景,如果无论如何都无法实现吗?

【问题讨论】:

    标签: google-app-engine google-cloud-platform multi-tenant


    【解决方案1】:

    我认为命名空间对任务调度逻辑没有任何影响。从您提到的文档中的任务队列示例中,您可以看到名称空间信息仅在实际处理任务时恢复,并且调度逻辑已经完成。

    但这并不算太糟糕 - 为了正确运行,您的应用程序的扩展和队列配置通常应该设置为处理您期望的最大工作负载(在所有命名空间中组合),在这种情况下,一个特定租户对另一个租户的影响,如果任何,都应该是微不足道的。

    【讨论】:

    • 感谢@dan-cornilescu 在普通应用程序中,您上面解释的内容完全有道理,但在我们的例子中,我们正在处理数据并使用推送队列作为事件的中间占位符,然后才能获取它们用于处理,因此对于某些客户来说它们的数量会很大,因此会影响其他客户的数据处理。这就是为什么事先管理它对我们来说变得不那么重要了。
    猜你喜欢
    • 2018-03-23
    • 2019-10-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-19
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多