Компоненты очереди сообщений

Три главных компонента:

• Производитель сообщений
• Брокер сообщений
• Потребитель сообщений

Очереди абстрагируются брокером.

На этой схеме более очевидно, что происходит:

• Производитель отправляет сообщение брокеру
• Брокер получает сообщение и помещает его в очередь
• Потребитель запрашивает сообщение у брокера
• Брокер достаёт сообщение из очереди и передаёт потребителю

Изоляция производителей и потребителей

Одна из целей – ослабить связи.

Очередь сообщений ослабляет связь сбора данных и анализа.

Какие преимущества это даёт?

Если сообщения порождаются быстрее, чем получается обработать, как предотвратить “захлёбывание”?

“Противодавление” – мера того, насколько быстрее сообщения порождаются, чем обрабатываются. Аналогия с гидравликой.

Временный рост противодавления – нормально.

В системах “почти” реального времени, рост противодавления – признак проблемы.

Варианты:

1. Решение на стороне потребителей. При росте противодавления, можно увеличить число потребителей или сделать их быстрее.

   Не всегда оправдано.

2. Управление производителем. Уменьшать плотность потока при росте противодавления.

   Не все системы поддерживают. Тогда управление – на совести разработчика.

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

Долговечные сообщения

Интересны не только в связи с противодавлением.

Могут обеспечивать устойчивость к сбоям связности сети.

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

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

Пример: система дорожной навигации (типа Яндекс.Навигатор).

Семантика доставки сообщений

Три вида гарантий:

1. Не более одного раза
2. Не менее одного раза
3. Ровно один раз

Точки отказа “только один раз”:

• Производитель
• Сеть между производителем и брокером
• Брокер
• Очередь сообщений
• Сеть между потребителем и брокером
• Потребитель

Не все системы дают гарантию “только один раз”.

Не фатально – можно реализовать вручную через координацию производителей и потребителей:

• Со стороны производителя. Не пытаться отправить сообщения повторно.
• Со стороны потребителя. Сохранять метаданные последнего сообщения.

Стоит обратить внимание:

• На этапе сбора данных:
  • Можно ли аутентифицировать производителя?
  • Авторизовать?
• При передаче сообщений:
  • Как обеспечить безопасность передачи?
• При хранении сообщений:
  • Как обеспечить безопасность хранения?
• На этапе очереди сообщений:
  • Взаимная аутентификация брокеров?
• На этапе анализа данных:
  • Можно ли аутентифицировать потребителя?
  • Авторизовать?

Способов снижения рисков:

• Ожидание производителем подтверждения записи сообщений на диск
• Реплицкация сообщения нескольким брокерам
• Минимизация хранимых в оперативной памяти данных

В случае разрыва сетевых соединений? При поддержке репликации, данные в относительной безопасности.

При выборе продукта, следует найти ответы:

• При отказе сети, выбирается ли в качестве реплики другой брокер?
• Что происходит при восстановлении сети?
• Есть ли возможность настроить временную задержку (“таймаут”), при которой считается, что сеть отказала?
• Что произойдёт с данными, если сеть не восстановится?
• Что произойдёт с данными, если брокер отключится от кластера в момент передачи ему сообщения от производителя?

При отказе хранилища? Следует найти ответы на вопросы:

• Существуют ли реплики потерянных в результате отказа СХД данных?
• Если реплицируемые данные не успели записать на диск до момента отказа: будут ли эти данные потеряны?
• Как восстановить брокера после отказа СХД?

Финансы: обнаружение мошенничества

Вопросы:

• Как повлияет на бизнес длительное отсутствие связи между звеньями сбора данных и анализа?
• Данные за сколько дней можно потерять без последствий?
• Должны ли храниться старые данные?
• Какая семантика доставки сообщений нужна в этом случае?

• Отсутствие связи. Повлияет катастрофически.
• Потеря данных. Всегда с последствиями.
• Старые данные. Скорее всего, должны храниться.
• Семантика доставки. Скорее всего, “ровно один раз”.

Интернет вещей: “социальные” автоматы для продажи лимонада

Электронная коммерция: рекомендация товаров

Цель – быстрее получить данные из очереди сообщений. В идеале, анализ данных с тем же темпом, что и сбор данных.

В “традиционной” системе – меняющиеся запросы к статичным данным.

В потоковой системе – фиксированный запрос, динамические данные. Модель непрерывного запроса.

Пример: управление новостным агентством.

Традиционная система:

Традиционная система проигрывает потоковой в отзывчивости.

Ещё раз ключевые различия:

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

Различие в обработке сбоев:

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

Различие в обработке сбоев:

• Если традиционная система отказывает в момент выполнения запроса, то повторное выполнение запроса – на совести приложения (или пользователя)
• Если потоковая система отказывает, после восстановления непрерывные запросы могут быть продолжены с прерванного места (хотя это не всегда необходимо). Часто с точки зрения клиента, всё выглядит так, как будто никакого сбоя вообще не было.

Приведём несколько примеров успеха:

• Маркетинг на основе поведения. McDonald’s, VMob (Plexure), увеличение конверсии увеличилась на 700%.
• Повышение эффективности дорожного движения. Veovo. Распределение нагрузки на дорожную сеть.
• Обнаружение мошенничества. По отчёту FICO, после внедрения в США анализа данных в реальном времени, потери от мошенничества с кредитными картами снизились на 70%

Общая архитектура

Пример с газовой турбиной:

Архитектура Streaming:

Концепции:

• Топология
• Spout (струя)
• Bolt (разряд)

Архитектура:

Семантика доставки сообщений

Похожа на семантику доставки в очередях. Определения те же, но выводы немного другие.

Семантики:

• Не более одного раза
• Не менее одного раза
• Ровно один раз

“Не более одного раза”, ошибки:

• потеря (отбрасывание) сообщения
• отказ обработчика

“Не менее одного раза” более сложная, поскольку потоковая система должна отслеживать каждое сообщение и подтверждение получения.

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

Семантика “ровно один раз” ещё увеличивает сложность системы. Система должна ещё и обнаруживать дубликаты. Упрощает работу задачи.

Вообще, лучше всё равно делать задачи идемпотентными.

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

Управление состоянием

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

Отказы со стороны входящего потока и места назначения (и связи с ними) должны корректно обрабатываться и связь должна автоматически восстанавливаться при первой возможности

Оставшиеся элементы:

• Потеря данных. Сюда относится потеря данных при передаче, и авария обработчика (теряются данные в памяти)
• Утрата контроля. Авария потокового диспетчера и/или драйвера.

Два подхода к репликации и координации:

• Резервирование
• Восстановление откатом