2017-01-03 16 views
0

Я думаю об этом с недели, но я придумал ничего, что меня убеждает.Apache Ignite - Расписание в кластере

У меня небольшой кластер работает Jetty с Джерси на всех узлах (все они одинаковые). Запросы сбалансированы на узлах, и все узлы «без гражданства».

Данные пользователя разделены на Apache Ignite, встроенные в JVM с Jetty и поэтому доступны для любого узла.

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

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

Это потребует планирования, я могу видеть только два решения:

  • Расписание событий на узле, который уведомлен несколько первых пользователей. (Неверно, если узел вышел из строя или перезагрузился)

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

    • Гибрид обоих; где события хранятся в распределенной коллекции, и планирование может быть хорошим. Если узел не сработает, он запустится и удалит запись коллекции. Медленная итерация коллекции проверяет, есть ли истекшие события и которые не были удалены. (Это выглядит решение, которое может быть трудно для отладки и прогнозирования)

Как я прочитал реализацию DelayedQueue и не искать эффективную систему управления большим количеством запланированных задач.

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

ответ

0

Я думаю, вы можете создать кластер singleton (https://apacheignite.readme.io/docs/cluster-singletons), который позаботится о планировании. Это автоматически обработает переход на другой ресурс в случае сбоев. Если есть какое-либо состояние (например, информация о пользователях, которые были уведомлены, отметка времени, когда задание было запланировано в последний раз и т. Д.), Оно может быть сохранено в кеше.