Рекомендации по использованию

ADS как Messaging System

Как понятие о потоках ADS сравнивается с традиционной корпоративной системой обмена сообщениями?

Обмен сообщениями традиционно имеет две модели: “очередь” и “публикация-подписка”. В очереди группа потребителей может читать с сервера, и каждая запись переходит к одному из них; в модели “публикация-подписка” запись передается всем потребителям.

Каждая из этих двух моделей имеет свои плюсы и минусы. Преимущество очереди заключается в том, что она допускает разделение обработки данных на несколько инстансов потребителей, что позволяет масштабировать обработку. Но при этом очереди не являются многопотребительскими – как только один процесс считывает данные, они удаляются. Модель обмена сообщениями “публикация-подписка” позволяет передавать данные нескольким процессам, но при этом не имеет возможности масштабирования, так как каждое сообщение отправляется каждому подписчику.

Концепция группы потребителей в ADS обобщает эти две модели. Как и в случае с очередью, группа потребителей позволяет разделять обработку по совокупности процессов (по членам группы потребителей). А как в случае с моделью “публикация-подписка”, ADS позволяет передавать сообщения нескольким группам потребителей.

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

К тому же ADS имеет более мощные гарантии упорядочения, чем традиционная система обмена сообщениями.

Традиционная очередь сохраняет записи на сервере по порядку, и передача записей с сервера осуществляется в порядке их хранения на нем. Однако если считывание из очереди производится несколькими потребителями, то, несмотря на то, что сервер ведет записи по порядку, данные доставляются потребителям асинхронно. Фактически это означает, что при параллельном считывании упорядоченность записей теряется. Системы обмена сообщениями часто обходят эту проблему, используя понятие “исключительный потребитель” (“exclusive consumer”), которое позволяет только одному процессу считывать из очереди, но это говорит о том, что параллелизм в обработке отсутствует.

В платформе ADS эта проблема решена. Имея понятие “параллелизм – партиция – в рамках топика” (“parallelism – the partition – within the topics”), ADS может обеспечить как гарантии упорядоченности, так и балансировку нагрузки над группами потребительских процессов. Это достигается путем назначения партиций в топике для потребителей соответствующей группы, чтобы каждая партиция считывалась ровно одним потребителем в группе. При этом гарантируется, что потребитель является единственным читателем этой партиции и потребляет данные по порядку. Поскольку существует много партиций, нагрузка балансируется по всем экземплярам потребителя. Также следует обратить внимание, что в группе не может быть экземпляров потребителей больше, чем партиций.

ADS как Storage System

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

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

Дисковые структуры ADS хорошо масштабируются: платформа функционирует одинаково, не зависимо от объема постоянных данных на сервере – будь то 50 КБ или 50 ТБ.

С целью использования ADS в качестве хранилища и предоставления клиентам возможности контролирования позиции чтения, платформу можно рассматривать как своего рода распределенную файловую систему специального назначения, предназначенную для высокопроизводительного хранения данных с низкой задержкой коммитов в журнал, а также для их репликации и распространения.

ADS – Stream Processing

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

В ADS потоковый процессор – это все, что принимает непрерывные потоки данных из входных топиков, выполняет некоторую обработку и создает непрерывные потоки данных в выходные топики.

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

Простую обработку можно выполнять напрямую, используя Consumer API и Producer API. Однако для более сложных преобразований ADS предоставляет Streams API. Он позволяет создавать приложения с нетривиальной обработкой, выполняющей агрегацию потоков или объединяющей их вместе. Это помогает решить сложные проблемы, с которыми сталкивается подобный тип приложений: обработка неупорядоченных данных, переработка входных данных при изменении кода, выполнение вычислений с учетом состояния и т.д.

Streams API построен на основных примитивах ADS: он использует Producer API для ввода, использует Kafka для хранения состояний и применяет механизм группы для обеспечения отказоустойчивости среди инстансов потокового процессора.