В
есть один нюанс
Size: a a a
2020 April 29
В
на процесс да, а что на счет консистентности данных
R
Увеличивайте локи, это первый совет
как это поможет?
В
предположим есть некоторая мутация данных в экстернал таске, их 3, каждый последующий зависит от нового набора данных в базе
SD
А это да, косяк, придется следить за идемпотентностью на клиенте
В
условно назовем жто статус 1 2 3
SD
Да, я понимаю о чем вы говорите
В
теперь кейс мы прошли таск 1 таск 2 - и таск 3 ожидает статус два, но запустился снова таск 1 и скорруптил данные к чертям
В
и единственное что сейчас я вижу как решение, но это ударит по перформансу вытаскивать клиента в солоинстанс и далее им уже раздавать по кругу задачи
SD
как это поможет?
Ответ от клиента гарантированно придет до разлока, либо мы точно уверены что первая итерация уже не будет выполнена.
В
можно еще конечно замутить http-connector камунде прийдется нести нагрузку на фетчинк
SD
и единственное что сейчас я вижу как решение, но это ударит по перформансу вытаскивать клиента в солоинстанс и далее им уже раздавать по кругу задачи
Все зависит от того, сколько сил и средств в эту проблему вы готовы вложить. Вон большинство с external task работают через внешний брокер
SD
Придумать можно кучу вариантов. Отлавливать дубли на клиенте, например. Все зависит от вашей архитектуры и полета фантазии )))
В
история с внешним брокером выглядит не круто. надо получается делать на 1 таск 2 квадратика
SD
история с внешним брокером выглядит не круто. надо получается делать на 1 таск 2 квадратика
Нет, не верно.
В
а как выглядит реализация, мне идея подцепить натс как шину очень нравится
SD
На схеме ничего не меняется. просто fetchAndLock вы выполняете на стороне камунды через Java API
В
то есть это все тот же экстернал таск?
SD
Да
В
но надо листенер на него вешать?