Как построить отказоустойчивое приложение в Storm?

Question

Краткая версия вопроса: как построить надежную программу подсчета слов (топологию) в Twitter Буря, которая производит точные результаты, даже если происходит сбой? Возможно ли это?

Длинная версия: Я изучаю Twitter Storm и пытаюсь понять, как ее использовать. Я следовал за tutorial и нашел это очень простой концепцией. Но пример подсчета слов, описанный в учебнике, не является отказоустойчивым (потому что болты сохраняют некоторые данные в памяти). Однако сохранение одних и тех же данных в базовом БД приводит к двойному счету, если событие повторно отправляется в начало цепи (что происходит, когда некоторые из болтов сбой).

Должен ли я видеть Twitter Storm как платформу реального времени для производства частично точных результатов и по-прежнему зависит от MapReduce, чтобы получить точные данные?

Answer 1

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

1. Грозовых болты должны Ack кортежа только после того, как они обработали его. Если вы пишете свои носики, болты и топологию, чтобы использовать это, вы можете реализовать систему «ровно один раз», которая будет гарантировать точность.

2. Kafka может быть хорошим способом поместить данные в Storm, потому что он использует упор на диске, чтобы поддерживать сообщения в течение длительного времени даже после их потребления. Это означает, что вы можете получить их, если пользователь потеряет линию.

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

Answer 2

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

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

Смотрите ссылку гораздо больше информации и примеры кода:

https://github.com/nathanmarz/storm/wiki/Transactional-topologies