【问题标题】:Read-only queue for distributed event throttling?分布式事件限制的只读队列?
【发布时间】:2014-02-10 19:25:59
【问题描述】:

我正在寻找一种在集群范围内限制各种进程的方法。这需要某种可以处理任意数量的事件消费者的集中控制。我的想法涉及一个只读队列,它以一定的速率生成令牌,没有积压(所以错过的事件被丢弃)。例如,假设我有一些 Web API 需要限制为每小时 10,000 条消息,但可以从集群中的任意数量的服务器调用。我将配置一个队列以每小时 10k 条消息生成令牌,并且所有服务器都连接到该队列并在继续之前检索令牌。这将引入延迟元素(第一次请求后的 3600/10000 秒),但无论消费者数量如何,都将是平滑且可预测的。我不想有积压,因为我不想在一段安静的时间后匆忙赶路 - 目的不仅仅是限制每小时的事件总数,而是将它们均匀地分布在其中。

我的主要应用是 PHP,它在 linux 上运行。目前我对 beanstalkd 的正常排队非常满意,但它不支持这种操作模式。我过去使用过 RabbitMQ,但相比之下发现它又重又脆弱。如果这可以由队列管理器自己完成,那就太好了,因为它在配置后不需要外部输入。

在没有对此类内容的特定支持的情况下,我可以尝试使用普通队列,并在很短的时间内将令牌推入其中,尽管这看起来很不雅。有更好的想法吗?

【问题讨论】:

    标签: queue rabbitmq cluster-computing beanstalkd throttling


    【解决方案1】:

    您可以使用以下方法之一:

    1. 将主题交换与常规队列一起使用,但根据您的需要设置消息 ttl。这种方法的优点是你可以有少量的积压,比如最后 5 秒,这允许你的应用程序在短期问题后恢复,比如在某些维护期间网络丢失。没有缺点。

    2. 您可以将消息发布到扇出交换并使用auto-delete 标志声明队列,然后从中消费消息。这种方式的最大缺点是消息通过队列复制。实际上,如果您需要这样的行为,它可能是专业的,但您也可以通过具有相同绑定的附加队列轻松实现主题交换。

    【讨论】:

    • 消息的重复并不重要——重要的是令牌的可用性;它根本不需要任何内容​​或含义——如果队列可以创建自己的令牌,我实际上根本不需要任何消息输入。我真的不想使用 Rabbit,因为我过去遇到过很多问题。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2011-12-07
    • 2017-04-14
    • 1970-01-01
    • 2012-10-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多