Еще 5 причин выбрать Apache Pulsar вместо Apache Kafka

Apache Kafka — крайне популярное в настоящий момент решение для обмена сообщениями. Тем более интересно посмотреть какие альтернативы для нее существуют. Особенно декларируемые, как более интересные по ряду параметров.

Под катом — перевод статьи-сравнения Apache Pulsar и Apache Kafka. Статья в некоторой степени рекламная, т.к. написана заинтересованным лицом, но как минимум, возбуждает интерес копнуть глубже. Поехали.

Переведено @middle_java

Крис Бартоломью, специалист по проектированию потоковых систем, DataStax

Примечание автора: Изначально я опубликовал этот пост в 2019 году, когда был CEO в Kesque — сервиса обмена сообщениями в реальном времени, построенного на Apache Pulsar — облачной распределенной платформе обмена сообщениями и потоковой передачи. Это продолжение более ранней публикации «7 причин выбрать Apache Pulsar вместо Apache Kafka». С тех пор, как были опубликованы эти два поста, произошло много больших изменений, включая приобретение в январе компанией DataStax компании Kesque. Однако причины выбрать Pulsar не изменились.

Некоторое время назад я написал пост о 7 причинах, по которым мы выбираем Apache Pulsar вместо Apache Kafka. С тех пор я работал над подробным отчетом, сравнивая Kafka и Pulsar, общался с пользователями опен-сорсного проекта Pulsar и пользователями Kesque — сервиса Pulsar, управляемого нами. Я понял, что упустил некоторые причины в первом посте. Итак, я подумал, что сделаю следующий пост, который пополнит список причин.

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

• Совместная потоковая передача (streaming) и использование очередей (queuing) — Kafka и RabbitMQ на единой платформе. Это сделка «два по цене одного».
• Партиции необязательны — с Pulsar вам не нужно возиться с партициями, если вы не хотите. (А я не хочу.)
• Распределенный журнал — журнал Pulsar горизонтально масштабируем, поскольку он распределенный. Я слышу музыку в ушах?
• Брокеры без состояния — Сценарий мечты для облачного приложения. Где мой автоматический масштабатор?
• Нативная георепликация — кто угодно, и тут я имею в виду именно кто угодно, может заставить георепликацию работать.
• Он быстрее — тесты подтверждают это.
• Все продукты Apache Software Foundation — это продукты с открытым исходным кодом — никто не собирается отбирать у вас лицензии.

Это первые семь причин. Кажется, это много, но я нашел больше. Перейдем к ним.

1. Хорошая совместимость с мультиарендностью (multi-tenancy)

Мне действительно следовало поговорить о мультиарендности в первом посте, потому что это важная вещь. Даже если вы не планируете создавать управляемый сервис Pulsar (а зачем вам это, раз мы уже создали его для вас?), если только вы не отшельник, то над несколькими проектами будут работать несколько команд, используя вашу инфраструктуру обмена сообщениями. Разворачивание кластера для каждой команды или проекта — это боль. К тому же это дорого.

При использовании Pulsar, у вас может быть несколько арендаторов, и эти арендаторы могут иметь несколько пространств имен, чтобы все было организовано. Добавьте к этому контроль доступа, квоты и лимитирование скорости для каждого пространства имен, и вы сможете представить себе будущее, в котором можно получить все, что нужно, используя только один кластер. Не только мы можем представить это будущее, Kafka тоже его представляет. Вы можете прочитать об этом в Kafka Improvement Proposal (KIP) KIP-37. Это уже давно обсуждается.

2. У нас уже есть кворум? Репликация

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

Kafka делает это, используя модель «следуй за лидером» (follow-the-leader). Лидер хранит сообщение, а последователи (followers) делают его копию. Как только достаточное количество последователей подтвердят получение сообщения, Kafka расслабляется. Pulsar использует модель кворума. Он отправляет сообщение множеству узлов, и как только достаточное их количество подтвердят получение, Pulsar расслабляется.

Репликация по модели кворума более демократична безо всяких иерархий лидер-последователь. Всегда побеждает большинство, и все голоса равны. Но технология не имеет значения. Что действительно важно, так это то, что репликация по модели кворума, как правило, обеспечивает более согласованное поведение со временем. Возможно, это объясняет, почему Pulsar дает более стабильные показатели задержки.

Если вы хотите подробнее узнать о задержках Kafka и Pulsar, ознакомьтесь с моим постом. (Он длинный. Не говорите потом, что я не предупреждал.) А, да, и Кафка тоже думает о репликации по модели кворума для улучшения согласованности задержек. Посмотрите KIP-250 для обсуждения.

3. Многоуровневое хранилище, мечтания о потоке событий (event sourcing)

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

Что, если вам так понравились сообщения, что вы хотите всегда держать их при себе? Например, если вы создаете поток событий (event-sourcing). Это звучит как отличная идея, но вечность — это очень долгий срок, и вечное хранение сообщений может стать дорогим, особенно если вы храните их на тех высокопроизводительных SSD, которые заставляют вашу систему обмена сообщениями гудеть.

Разве не имело бы смысла, если бы вы могли переместить эти старые сообщения — те, которые вам нужно сохранить, потому что вам когда-нибудь может понадобиться более дешевое решение для хранения? И если бы вы могли использовать дешевое облачное хранилище, такое как корзины Amazon S3, разве это не здорово?

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

Бьюсь об заклад, Kafka хотела бы иметь эту функцию. Как вы уже догадались, так и есть. Это описано в KIP-405.

4. Сквозное шифрование и непонятная хрень

Очевидно, что безопасность важна, и нужно, чтобы сообщения хранились безопасно вдали от любопытных глаз. Естественно, вы будете использовать TLS между клиентом и системой обмена сообщениями (шифрование при передаче).

Когда вы это делаете, система обмена сообщениями должна расшифровать соединение, чтобы понять, что пытается сказать клиент. Затем она сохранит незашифрованное сообщение на диск. Конечно, вы будете настаивать, чтобы диск был зашифрован, для того чтобы, если кто-то украдет диск, сообщения были в безопасности (шифрование при хранении). Но в обоих этих случаях у системы обмена сообщениями есть ключи к вашим данным. В противном случае она имела бы дело с потоками абракадабры.

Во многих случаях этого уровня шифрования достаточно. Но если вы хотите быть абсолютно уверены, что никто не сможет заглянуть в ваши сообщения, вам необходимо сквозное (end-to-end) шифрование. Продюсер шифрует сообщение перед его отправкой, используя ключи, общие с консюмером, получающим сообщение. Когда сообщение сохраняется на диске системы обмена сообщениями, оно зашифровано, а у системы обмена сообщениями нет ключа. Система обмена сообщениями может выполнять свою работу. Но ваше сообщение — супербезопасный бессмысленный набор символов для системы обмена сообщениями.

Pulsar может выполнять сквозное шифрование в своем Java-клиенте. Kafka описывает это в KIP-317.

5. Процесс балансировки брокера

В моем последнем посте я говорил о том, что брокеры Pulsar не имеют состояния и это здорово. Но на самом деле это еще не все.

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

Другими словами, вам нужно перебалансировать нагрузку.

Pulsar автоматически выполняет балансировку нагрузки брокера. Он мониторит утилизацию ЦПУ, памяти и сети брокеров (не диска; ведь я уже упоминал, что брокеры не имеют состояния?) и перемещает нагрузку для поддержания баланса. Это означает, что вам не нужно добавлять новый брокер, пока вы не исчерпаете возможности всех брокеров, а не потому, что один из них перегрелся.

Вы можете выполнять балансировку нагрузки брокера с помощью Kafka. Но вам придется установить другой пакет, например Cruise Control от LinkedIn. Или, если вы любите платить за вещи (со временем), вы также можете использовать инструмент rebalancer от Confluent.

6. Сообщество и экосистема

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

В категориях сообщества и экосистемы, Kafka превосходит Pulsar. У Kafka пятилетний опыт, как проекта с открытым исходным кодом, поэтому вполне естественно, что у нее более широкое сообщество, больше связанных проектов и больше ответов на StackOverflow.

Все, что я могу сказать, это то, что сообщество Pulsar растет, народ регулярно добавляет новые компоненты и интеграции, а участники канала сообщества в Slack дружелюбны и отзывчивы.

На самом деле, могу сказать еще кое-что: понятно, что многое в Pulsar было вдохновлено Kafka, построено на ее основе и что Pulsar стоит на плечах гиганта. Проект и сообщество Kafka заслуживают большой похвалы и уважения. Я знаю, что иногда это может звучать так, как будто я неуважительно отношусь к Kafka, но на самом деле я просто в восторге от Pulsar.

7. Законная альтернатива Kafka

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

Я думаю, совершенно очевидно, что Pulsar — законная альтернатива Kafka. Pulsar поддерживает большую часть той же функциональности, что и Kafka, но имеет несколько (по моим подсчетам, дюжину) преимуществ и набирает обороты по мере того, как все больше людей узнают о нем.

Если вы оцениваете потоковые системы и/или системы очередей, вы должны сами попробовать Pulsar. Это так просто.

Хотите попробовать Pulsar? Зарегистрируйтесь сейчас на Astra Streaming — управляемый полностью нами сервис Apache Pulsar. Мы предоставим вам доступ ко всем его возможностям совершенно бесплатно вплоть доя бета-версии. Убедитесь сами, как легко создавать современные приложения для обработки данных, и расскажите нам, что вы хотели бы увидеть, чтобы сделать вашу работу еще лучше.