13 обычных ошибок при работе с RabbitMQ

Мы много лет используем RabbitMQ, и вероятно, видели больше ошибок конфигурации, чем кто-либо другой. Вот список, который поможет вам избежать наших ошибок использования RabbitMQ!

  1. Не открывать и закрывать соединения или каналы повторно
    Процесс установления связи для соединения AMQP фактически задействует как минимум 7 TCP-пакетов (если используется TLS). При необходимости каналы можно открывать и закрывать чаще. Каналы должны быть долговечными, если это возможно, например. повторно использовать один и тот же канал в потоке публикации. Не открывайте канал каждый раз, когда вы публикуете. Лучшей практикой является повторное использование соединений и мультиплексирование соединения между потоками с каналами.

    • AMQP подключение: 7 TCP пакетов
    • AMQP канал: 2 TCP пакета
    • AMQP публикация: 1 TCP пакет (для больших сообщений естественно больше)
    • AMQP закрыть кана: 2 TCP пакета
    • AMQP закрыть подключение: 2 TCP пакета
    • Общее 14-19 пакетов (+ Ack’s)
  2. Не используйте слишком много соединений или каналов
    Попытайтесь уменьшить количество подключений / каналов. Используйте отдельные подключения для публикации и использования. В идеале вы должны иметь только одно соединение для каждого процесса, а затем использовать канал в потоке в своем приложении.

    • Повторное подключение
    • 1 подключение для publisher
    • 1 соединение для consumer
  3. Не разделяйте каналы между потоками
    Вы должны убедиться, что вы не обмениваетесь каналами между потоками, поскольку большинство клиентов не делают потоки потоками каналов (потому что это окажет серьезное негативное влияние на производительность).
  4. Не используйте слишком большие очереди
    Короткие очереди – самые быстрые. Когда очередь пуста, и у нее есть потребители готовые к приему сообщений, то, как только сообщение будет получено очередью, оно будет отправлено прямо к потребителю.Многие сообщения в очереди могут сильно нагружать ОЗУ. Когда это произойдет, RabbitMQ начнет очищать сообщения (на выходе)(будет писать на диск), чтобы освободить ОЗУ, а как извесно скорость чтения из ОЗУ куда быстрее чтения диска.Проблемы с длинными очередями

    • Небольшие сообщения, встраиваються в индекс очереди
    • Увиличиваеться время синхронизации между узлами
    • Увиличиваеться время, затрачиваемое на запуск сервера с большим количеством сообщений
    • Интерфейс управления RabbitMQ собирает и сохраняет статистику для всех очередей
  5. Используйте ленивые очереди (lazy queues) для получения прогнозируемой производительности (или если у вас большие очереди)
    С ленивыми очередями сообщения идут прямо на диск, и поэтому использование ОЗУ минимизируется, но время работы увиличиваеться.

    Ленивые очереди создают более стабильный кластер с более предсказуемой производительностью. Ваши сообщения не будут без предупреждения, записаны на диск.

  6. Ограничение размера очереди (TTL или максимальная длинна)
    Приложения, часто попадают под пики количества сообщений, а если важнее всего пропускная способность, – стоит установить максимальную длину в очереди. Это позволит оставить очередь короткой, отбрасывая сообщения из начала очередей, чтобы никогда не превышала значение максимальной длины.
  7. Использовать несколько очередей и потребителей
    Вы получите более высокую пропускную способность в многоядерной системе, если у вас несколько очередей и потребителей. Вы достигнете оптимальной пропускной способности, если у вас столько очередей, сколько ядер на базовом узле (узлах).
  8. Долговечные сообщения и длинные очереди для сообщений, чтобы пережить перезагрузку сервера
    Если вы не можете потерять какие-либо сообщения, убедитесь, что ваша очередь объявлена как «долговечная», а ваши сообщения отправляются с режимом «persistent» (delivery_mode = 2).

    Для высокой пропускной способности используйте временные или короткие очереди

  9. Разделите свои очереди на разные ядра
    Производительность очереди ограничена одним ядром ЦП. Вы получите лучшую производительность, если разделите свои очереди на разные ядра, а также на разные узлы, если у вас кластер RabbitMQ.
  10. Consume (push), don’t poll (pull) for messages
  11. Не используйте старые версии RabbitMQ / Erlang или клиенты / библиотеки RabbitMQ. Будьте в курсе последних стабильных версий RabbitMQ и Erlang. Убедитесь, что вы используете последнюю рекомендованную версию клиентских библиотек.
  12. Не используйте неограниченного значения предварительной выборки
    Типичная ошибка заключается в том, чтобы иметь неограниченную предварительную выборку, когда один клиент получает все сообщения и заканчивается память, происходит сбой, а затем все сообщения снова отправляются повторно.
  13. Забыли добавить политику HA при создании нового vhost на кластере
    Когда вы создаете новый vhost в кластере, не забудьте включить HA-политику для нового vhost (если у вас есть настройка HA). Сообщения не будут синхронизироваться между узлами без HA-политики.

комментарий

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.