Alauda Streaming Service for RabbitMQ
  • Русский

    • Настройка TTL сообщений и ограничений длины очереди

    Используйте TTL сообщений и ограничения длины очереди, чтобы удерживать рост очереди в контролируемых пределах. Эти настройки полезны для обработки всплесков нагрузки, контроля резервного накопления и очередей, которые не должны хранить устаревшие сообщения бесконечно.

    Предпочитайте политики жестко заданным аргументам очереди, если одни и те же ограничения должны применяться к нескольким очередям или если вы хотите изменять ограничения без повторного объявления очередей.

    Содержание

    Выбор правильного механизма управленияПрименение политики очередиПроверка активной политикиРекомендации по проектированиюСвязанная информация

    Выбор правильного механизма управления

    Механизм управленияДля чего использоватьПримечания
    message-ttlИстечение старых сообщений по истечении заданного окна хранения.Сообщения, которые остаются дольше TTL, становятся кандидатами на удаление по истечении срока.
    max-lengthОграничение количества сообщений в очереди.Используйте, когда важнее рост числа сообщений в очереди, а не общий объем в байтах.
    max-length-bytesОграничение размера очереди в байтах.Полезно для workloads с большими payload.
    overflowОпределение того, что происходит при достижении очередью предела.Выберите между удалением из головы очереди и отклонением новых публикаций.
    expires or x-expiresИстечение неиспользуемых очередей.Используйте только для действительно временных очередей, а не для долговечных production-очередей, которые могут долго простаивать.
    Не путайте истечение очереди с TTL сообщений

    Истечение очереди удаляет неиспользуемую очередь. TTL сообщений приводит к истечению сообщений. Для долговечных application-очередей и очередей warm-standby используйте message-ttl для контроля накопления и избегайте expires, если очередь не является намеренно временной.

    Применение политики очереди

    Следующий пример применяет 24-часовое окно хранения сообщений и ограничения длины очереди к очередям, начинающимся с orders., в виртуальном хосте по умолчанию:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmqctl set_policy -p / backlog-controls \
  '^orders\.' \
  '{"message-ttl":86400000,"max-length":100000,"max-length-bytes":1073741824,"overflow":"reject-publish-dlx"}' \
  --priority 20 \
  --apply-to queues

    В этом примере:

    • Сообщения старше 24 часов становятся кандидатами на истечение.
    • Очередь хранит не более 100000 сообщений.
    • Очередь хранит не более 1 GiB данных сообщений.
    • Новые публикации отклоняются после достижения лимита и могут быть отправлены в dead-letter, если очередь настроена с DLX.

    Если другая политика уже совпадает с теми же очередями, проверьте приоритеты политик перед созданием конкурирующего правила.

    Проверка активной политики

    Выведите список политик в виртуальном хосте:

    kubectl -n <namespace> exec <instance-name>-server-0 -- \
  rabbitmqctl list_policies -p /

    Проверьте аргументы очереди и активную политику:

    rabbitmqadmin \
  --host <management-host> \
  --port 15672 \
  --username <admin-user> \
  --password <admin-password> \
  --vhost / \
  list queues name policy arguments messages message_bytes

    Рекомендации по проектированию

    • Используйте message-ttl, чтобы ограничить резервные очереди или очереди replay, которые не должны расти бесконечно.
    • Используйте max-length или max-length-bytes для высоконагруженных очередей, чтобы неожиданные отказы consumers не исчерпали диск.
    • Выбирайте overflow="reject-publish" или overflow="reject-publish-dlx", когда publishers должны получать backpressure вместо тихой потери самых старых сообщений.
    • Используйте overflow="drop-head" только тогда, когда приложение явно предпочитает новые сообщения старому накопленному backlog.
    • Сверяйте значения ограничений с пиками трафика, ожидаемыми окнами отказов и доступным хранилищем.

    Связанная информация