Thread by @Randomazer

Cоветы по настройке RabbitMQ, если бы я только начал им пользоваться.

Тред объемный, поэтому содержит 5 глав:

- System
- Configuration
- VHost/Exchange/Queue
- Shovel
- Speed

С вас лайки и вопросы. Обожаю вопросы. Поехали!!!

0. Полезные видосы (в дополнение всему что написано ниже).

1. System.

В этой главе расскажу про настройку системы.

1.1 File decriptors.

File decriptors напрямую влияет на количество открываемых файлов и сокетов для RabbitMQ по-умолчанию равно 1024. Это очень мало, я, например, сразу ставлю 65535. Можно ставить больше.

1.2. Socket connection.

Также тюним количество socket connection. Зачем? Представьте, ваш кластер упал, потом поднялся и мгновенно все Х клиентов полезли соединяться. Неприятно после падения опять грохнуться из-за скачков соединений. Поэтому тюним.

jeka.by/post/1075/rabb…

1.3 Не храните кролика (mnesia) на системном диске.

Здесь все просто, системный диск под ОС. Все остальное размещаем на отдельном диске (логи RMQ, mnesia). На диске может резко закончится место, может быть дикая утилизация. Поэтому все на отдельный диск.

1.4 Бекапы.

Может быть момент, когда после сбоя все очереди, exchanges,виртуальные хосты могут быть потеряны. Советую делать бекап не только mnesia (хотя мне кажется бесполезным), но и файла definiton.json. Это можно делать через UI и по API. Потом себе огромное спасибо скажете

1.5.

Используйте SSD диски. Мне кажется, что это уже стандарт де-факто. Если используете stream очереди, которые появились совсем недавно, так и для persistent очередей. Памяти может в какой-нибудь момент не хватить для хранения сообщений и все будет скидываться на диск.

1.6.

Используйте RabbitMQ Exporter (который из коробки) + Grafana для наблюдений за очередями, exhcnage и прочего. А так же за редиливами, отправками в очередь, ack, nack и много чего.

1.6.1.

В UI Managment RMQ показывает стату только за определенные промежутки времени 1 минута, 10 минут, 1 час, 9 часов и сутки. Нельзя просто взять и посмотреть что было с очередью за определенный промежуток времени.

1.7.

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

rabbitmq.com/cli.html

2. RabbitMQ Configuration.

Конфигурации кролика.

2.1.

Количество нод делаем строго не четное. Вы можете конечно сэкономить, сделать 2. Но поверьте, когда будет нестабильная сеть в ДЦ, упадут 2 ноды, посрутся между собой кто из них master кто зеркало и придется пересоздавать с нуля кластер (с потерей сообщений естественно).

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

Кластер из 2 нод.

- Падает первая нода.
- Поднимается.
- Sync 1ой ноды с 2ой.
- Во время sync падает 2я нода.
- В итоге не поднимается ни одна ни вторая.

2.2.1.

Ноды кластера RabbitMQ в разных ДЦ - это зло.

2.2.2.

Это влияет на скорость отправки сообщений. Пока все ноды не подтвердят, что получили сообщение, сообщение для клиента не будет считаться доставленным.

2.2.3.

Ноды будут отваливаться в самый неподходящий момент. Так как heartbeat между нодами довольно маленький. Можно это значение тюнить и выставлять выше, но если одна нода действительно отвалиться, то кластер об этом поймет не скоро и есть возможность потерять сообщения.

2.2.4.

Если хотите RMQ в 2х разных ДЦ. Используйте shovel (не кластер). Но тогда придется делать shovel на каждую очередь/exchange. Что такое shovel расскажу позже.

rabbitmq.com/distributed.ht…

2.3.1.

Если сервера кластера находятся в одной стойке, то классно было бы, если у каждого сервера было два сетевых интерфейса внешний и внутренний. По внутреннему шло бы общение между кластером (sync). По внешнему кластер бы общался с клиентами.

2.3.2.

Зачем? А затем, что при большом количестве трафика на кластере мы забиваем внешний интерфейс и синхронизация происходит медленнее и ноды могут отваливаться.

2.3.3.

Было такое один раз. Нода падала постоянно, оказалось, что просто мы уперлись в пропускную способность внешнего сетевого интерфейса.

2.4.

Используйте TLS и шифрование.

Тут все просто. Чтобы не видно было содержание трафика. Можно и нужно еще и сообщения шифровать.

2.5 High availability.

Сделал кластер - поставь политики синхронизации

rabbitmqctl set_policy HA ".*" "{""ha-mode"": ""all""}"

rabbitmq.com/ha.html

3. VHost/Exchange/Queue.

Разберемся с настройками VHost/Exchange/Queue

Вот видос отдельно по главе 3.

3.1 VirtualHost.

Что такое VHost можно прочесть здесь rabbitmq.com/vhosts.html

Рекомендации:

- Один проект один VHost.
- Настраиваем на каждый VHost права отдельно.
- Максимально изолируем VHost друг от друга, чтобы другие проекты даже не знали о существовании друг друга.

3.2 Exchange/Queues.

- Используйте расширения для exchange и queues. Многое кролик может сделать на своей стороне. Не стоит писать свою логику на стороне клиентов

rabbitmq.com/extensions.html

3.2.1 TTL.

Можно задавать время жизни сообшения в очереди и время жизни отдельного сообщения. Если сообщение не обрабатывается N секунд/минут/часов оно может автоматом удалиться.

rabbitmq.com/ttl.html#per-q…
rabbitmq.com/ttl.html#queue…
rabbitmq.com/ttl.html#per-m…

3.2.2 Dead letters.

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

rabbitmq.com/dlx.html

3.2.2.

Второй кейс. Сообщение отправляется в exchange, но в exchange нет роутинга на очередь. Сообщение пропадает. Так вот такие вот сообщения можно отправлять в DL exchange, это лакмусовая бумажка того, что что то не так настроено.

3.2.3 queue-length-limit.

Здесь все просто лимит по количеству сообщений в очереди. Если лимит превышен удаляется старое сообщение, поступает новое, при этом сохраняя размер очереди. Законы FIFO сохраняются.

rabbitmq.com/maxlength.html

3.2.4 Приоритет сообщения в очереди.

Можно сообщению выставлять приоритет от 1 до 255. Consumers прочитают сообщения в зависимости от того какой у них приоритет. Осторожнее!!! Чем больше приоритетов, тем медленнее все это работает. Увлекаться не стоит.

rabbitmq.com/priority.html

3.2.5 Alternate Exchanges.

Также в добавок к пункту 3.2.2

rabbitmq.com/ae.html

3.2.6 Ack / Nack.

Используем ack/nack на консьюмере.

Консьюмер взял сообщение (2 варианта):

- Если обработали сообщение без ошибок, подтверждаем его обработку (Ack) сообщение из очереди удаляется.
- Если обработали сообщение с ошибкой, возвращаем сообщение в очередь (Nack).

4.0 Shovel.

Что это такое можно прочитать здесь.

rabbitmq.com/shovel.html

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

4.0.1.

Пример, если у вас клиенты в Китае, Индии, США и Европе. Они генерят евенты. Чтобы евенты обрабатывались быстро, то ставим на каждую локацию по кролику и собираем туда евенты.
А дальше настраиваем shovel, чтобы сообщения из каждой локации кидались в основную шину.

4.0.2.

Плюсы в том, что при сбоях в сети между ДЦ в локациях мы не теряем сообщения. Сервисы которые обрабатывают евенты находятся в локациях близко к клиентам.

4.1 Federation.

Сразу признаюсь, не использовал ни разу, поэтому сказать ничего, к сожалению, не смогу. Почитать про это можно здесь

rabbitmq.com/federation.html

4.2 Shovel reconnect timeout.

При обрыве сети или когда ДЦ куда мы прокидываем сообщения недоступен мы делаем в shovel настройку на время переподключения.

4.2.1

Не рекомендую делать это время слишком маленьким. 1-5 секунд. Если будет просто кратковременный обрыв сети, то волна переподключений просто накроет RMQ получателя. И нас спасет только выставленный правильно параметр sockets connections.

4.3 Shovel ack-mode.

Сообщения передаются с RMQ отправителя на RMQ получателя. Есть 3 настройки для подтверждения отправки (после которого сообщения с RMQ отправителя удаляются)

- no-ack
- on-publish
- on-confirm

4.3.1 no-ack.

Самый быстрый и самый ненадежный вариант. Сообщение отправляется получателю и сразу же автоматом удаляется без подтверждения о получении.

4.3.2 on-publish.

Сообщение удаляется у отправителя только после того, как RMQ получатель подтвердил получение сообщения. Минус в том, что когда сообщение с одного RMQ передалось в другой, RMQ получатель подтверждает получение и, например, падает. Сообщение пропадет.

4.3.3 on-confirm (default).

Самый надежный, но и самый медленный вариант.

Сообщения удаляются у отправителя только после того, как consumer прочитал сообщение из RMQ приемника и подтвердил обработку сообщения.

4.4 Shovel domain.

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

- Если много shovel потом не нужно руками менять IP если RMQ получатель переедет в другой ДЦ.
- Shovel нельзя редактировать, только удалять и создавать заново.

5. Speed.

Ну тут как выжать из кролика по скорости все соки. Вообще вот здесь все за меня написано:

cloudamqp.com/blog/part2-rab…

Но напишу еще своими словами.

5.1 Делайте сообщения максимально короткими.

- Чем меньше полей в сообщении, тем лучше. Не стоит тащить все поля, авось, пригодится.
- Название полей в сообщении 1-3 буквы. Да, не информативно, но потом в коде или документации можно все расшифровать.

5.1.1

- Сжимайте сообщения, но смотрите, чтобы скорость компресии/декомпресии не была выше скорости отправки. Подбирайте алгоритмы.

5.2.

Отключите lazy queues. Это очереди, содержимое которых автоматически сбрасывается на диск. Не подходит для очередей с большим количеством соединений. Придет ООМ killer.

5.3.

Если сообщений много, то распределяем сообщения по нескольким очередям.

10кк сообщений в 2 очередях по 5кк каждая будет публиковаться быстрее, чем в одну очередь 10кк сообщений.
По чтению тоже самое.

5.3.1.

Также быстрее будет, если кластер из 3 нод

Очередь A (на 1 ноде) - зеркала на 2 и 3.
Очередь Б (на 2 ноде) - зеркала на 1 и 3.
Очередь В (на 3 ноде) - зеркала на 2 и 1.

5.4.

Следите за размером очередей. Если consumer не поспевает, очередь накапливается, то включается flow режим и скорость publisher замедляется.

Как контролировать
- TTL на очередь/сообщения.
- max-length на очередь.
- шардировать сообщения по нескольким очередям. (смотри 5.3)

5.5 Disable manual acks and publish confirms.

Я бы отключал ручные acks, только если точно уверены, что сообщения будут обрабатываться без ошибок и автоматом удаляться. Если произойдет сбой в логике сервиса, то есть вероятность потери сообщения. Так что надо 100 раз подумать.

5.6.

Чем больше нод в кластере и чем больше у очереди зеркал при включеном HA, тем медленнее скорость консьюмеров и паблишеров.
Одна нода быстрее, чем 3 ноды в кластере, так как при отправке требуется подтверждение, что сообщение на всех нодах.

5.7 Disable plugins you are not using.

Спорный пункт, но имеет место быть, хотя, вполне логично - отключай то, чем не пользуешься.

5.8.

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

github.com/rabbitmq/rabbi…

5.9 RabbitMQ Streams.

Хотите еще быстрой работы RabbitMQ используем Streams:

rabbitmq.com/streams.html