Прошло довольно много времени с момента последнего крупного выпуска RabbitMQ — версия 3.0 была запущена еще в ноябре 2012 года. Хотя ожидание следующего большого обновления могло показаться долгим, за это время произошло немало событий. Вместе с несколькими приобретениями команда VMware Tanzu RabbitMQ представила значительные функции и улучшения в промежуточных выпусках. Сегодня RabbitMQ является ключевым компонентом портфеля VMware Tanzu Data Solutions в VMware Tanzu. Приверженность Broadcom к сообществу с открытым исходным кодом также имеет важное значение, поскольку все участники основной инженерной команды являются сотрудниками Broadcom.
Неудивительно, что самая значительная функция RabbitMQ 4.0 является одновременно и нарушением обратной совместимости и в значительной степени невидима для пользователей, однако она критически важна для будущей устойчивости RabbitMQ. Как и многие другие продукты такого типа, RabbitMQ имеет хранилище метаданных в своей основе. Это хранилище используется для хранения определений топологии сообщений, пользователей, виртуальных хостов (vhosts), очередей, обменов, байндингов и параметров выполнения — оно жизненно важно для работы брокера сообщений.
Старое хранилище метаданных Mnesia использовалось столько же, сколько существует RabbitMQ. Как и следовало ожидать, за последние 17 лет в функциональности RabbitMQ произошло множество изменений, и многие функции были улучшены. Новое хранилище метаданных в RabbitMQ 4.0 (Khepri) использует тот же проверенный raft-based алгоритм, который уже несколько лет поддерживает безопасность данных в очередях Quorum Queue. Это делает систему очень устойчивой к разделению сети, что, в свою очередь, делает продукт Tanzu RabbitMQ более надежным.
Другие важные преимущества заключаются в том, что Khepri более эффективен в выполнении задач обслуживания, таких как удаление очередей или обменов, что ведет к общему улучшению производительности ядра Tanzu RabbitMQ. Эти улучшения производительности также прокладывают путь для дальнейших улучшений возможностей кластеризации Tanzu RabbitMQ. Пользователи могут включить Khepri с помощью опционального флага функции, так что никто не будет вынужден использовать эту технологию, если это не требуется. Разумеется, никаких изменений в коде не требуется при его включении, и RabbitMQ автоматически обрабатывает миграцию с Mnesia на Khepri.
Что касается производительности, в этом выпуске протокол AMQP 1.0 включен в ядро RabbitMQ. Это не означает, что старый протокол AMQP 0.9.1 не будет поддерживаться — это просто значит, что теперь можно выбрать более современный и стандартизированный протокол. Поддержка этой новой версии, опубликованной OASIS, укрепляет многопротокольный подход RabbitMQ и увеличивает его универсальность. В соответствии с другими "нативизациями" поддержка AMQP 1.0 также обеспечивает такие же улучшения производительности, которые были достигнуты при внедрении "нативного" MQTT в версиях 3.12 (MQTTv3) и 3.13 (MQTTv5).
На самом деле, пропускная способность (throughput) AMQP 1.0 между версиями 3.13 и 4.0 более чем удвоилась для классических очередей и очередей Quorum, а также для потоков. Как мы видели с нативной реализацией MQTT, такой подход к протоколам ведет к меньшему потреблению памяти на соединение. Это значит, что кластеры RabbitMQ теперь могут обрабатывать более чем в два раза больше соединений AMQP 1.0 по сравнению с предыдущими выпусками. Для получения дополнительной информации об этих улучшениях производительности, пожалуйста, ознакомьтесь с этой статьей в блоге.
Ранее пользователи не могли воспользоваться возможностями управления топологией, определенными в спецификации AMQP 1.0, что требовало заранее заданных очередей, байндингов и обменов. Такая жесткая настройка ограничивала ключевую силу RabbitMQ — его гибкие маршрутизационные возможности. Однако в версии 4.0 клиентские приложения теперь могут самостоятельно объявлять, удалять, очищать, связывать или отсоединять как очереди, так и обмены при использовании AMQP 1.0. Можно даже выполнять команду "get queue", которая предоставляет полезную информацию о лидере очереди и ее репликах в случае очередей Quorum. Эти клиентские библиотеки значительно помогают разработчикам извлекать максимум из протокола с минимальными усилиями. Например, такие функции, как подтверждения отправителя, становятся очень простыми. На сегодняшний день доступны клиенты Java и .NET, а скоро появятся и другие.
Нечасто удаление функции вызывает столько внимания, как удаление классических зеркальных очередей (Classic Mirrored Queues) в RabbitMQ. Несмотря на то, что эти старые зеркальные очереди были устаревшими более 3 лет, многие разочарованы их окончательным удалением. Хорошая новость заключается в том, что, хотя зеркалирование и было удалено, любые очереди, которые были зеркальными, не будут полностью удалены в версии 4.0, только их зеркальная часть. Также стоит отметить, что пользователям не обязательно использовать зеркалирование для публикации или потребления сообщений с конкретных узлов. Фактически, даже после удаления зеркальной очереди можно публиковать сообщения или потреблять их из очереди на любом узле в том же кластере RabbitMQ. Таким образом, приложения могут использовать те же классические очереди, что и раньше. Классические очереди продолжают поддерживаться без каких-либо изменений, нарушающих совместимость с клиентскими библиотеками. Для обеспечения дальнейшей безопасности данных реплицируемыми типами остаются очереди Quorum и потоки, обе из которых являются очень зрелыми технологиями. Дополнительную информацию о том, как мигрировать с классических зеркальных очередей на очереди Quorum, можно найти в этой статье в блоге.
Инженерная команда RabbitMQ продолжает развивать очереди Quorum, чтобы они работали быстрее и безопаснее, чем раньше. Ранее пользователи могли назначать до 255 приоритетов с помощью классических зеркальных очередей, однако это путь к полному приоритетному хаосу и путанице. В спецификации JMS для AMQP 1.0 определено всего два приоритета — нормальный и высокий.
Это то, что было реализовано в очередях Quorum для версии 4.0. Любое значение приоритета между 0 и 4 (включительно) считается нормальным приоритетом. Значения выше 4 считаются высоким приоритетом, а если издатель не указывает приоритет сообщения, предполагается значение 4 (нормальный приоритет). Что делать, если пользователям нужно больше контроля? Возможно, пришло время пересмотреть определения приоритетов сообщений. Приоритеты часто наследуются от старых систем и редко пересматриваются, как видно из спецификации JMS. Если это не удается разрешить, одним из решений является использование нескольких очередей — теперь это стало проще благодаря более быстрому времени загрузки очередей Quorum в RabbitMQ 4.0 и программной декларации AMQP 1.0. Кроме того, в очередях Quorum теперь установлено значение по умолчанию для ограничения на доставку — 20, а также приоритеты для одного активного потребителя (Single Active Consumer).
Добавлен и новый тип обмена — Random Exchange. В основном предназначен для использования в сценариях "запрос-ответ", в которых сообщения всегда доставляются в локальную очередь (чтобы уменьшить задержку при публикации). Если к тому же обмену подключено несколько локальных очередей, для доставки сообщения будет выбрана одна из них случайным образом.
Для пользователей Kubernetes добавлена новая диаграмма Helm, которая развертывает как операторы Kubernetes с открытым исходным кодом, так и коммерческие операторы кластеров и топологии Tanzu. Кроме того, теперь в определениях пользовательских ресурсов Kubernetes (Custom Resource Definitions) поддерживаются регулярные выражения, что позволяет пользователям определять диапазон виртуальных хостов (vhosts) вместо их явного объявления каждый раз.
Функции устойчивости репликации "Горячий резерв" (Warm Standby Replication) также получили улучшения в этом выпуске. В версии 3.13 был добавлен конфигурационный файл, облегчающий пользователям настройку и конфигурацию WSR, который в версии 4.0 был улучшен поддержкой списков и шаблонов для виртуальных хостов и т. д. Поддержка секретов теперь доступна через тот же конфигурационный файл, чтобы помочь обеспечить дополнительную безопасность для репликационной связи между верхним и нижним кластерами; в настоящее время поддерживается Hashicorp Vault. Пользователи также могут помечать конкретные определения shovel и federation для синхронизации в рамках процесса репликации горячего резерва. Оператор Standby Replication для Kubernetes заменен этим конфигурационным файлом, что упрощает настройку WSR независимо от среды.
Таким образом, RabbitMQ 4.0 приносит несколько ключевых улучшений, особенно в области совместимости и устойчивости. Наиболее заметное для пользователей изменение — внедрение AMQP 1.0 как основного протокола с значительными улучшениями пропускной способности и подключений. Этот выпуск и его дополнительные клиентские библиотеки открывают путь к дальнейшему развитию RabbitMQ, что позволит ему оставаться наиболее широко используемым брокером сообщений во всем мире на долгие годы.
RSS
