All streams
Search
Write a publication
Pull to refresh

Comments 4

А я вот все подобные боли закрыл наглухо, продвинув использование Temporal на своем проекте.

Какая то очень бедная на информацию статья.

"Нам не хватило обычной очереди, поэтому мы сделали\взяли полноценный движок воркфлоу", но это же абсолютно разные вещи для разных задач?

Если обработчик очередей вылетал после получения элемента, но до выполнения действий с ним, то данные просто терялись.

Вы не любите машины состояний? Давайте научу любить. В данном случае, вместо подразумеваемого (implicit) состояния (основываясь на косвенном признаке "есть/нету в очереди"), нужно было каждому элементу очереди дать своё состояние (explicit) для обозначения его прохода по конвееру обработки. Так звучит излишне сложно к пониманию, но машина состояний проста и не опирается на кучу переменных среды, а воплощает всё в себе:

  1. Элемент добавляется в очередь: ADDED + Timestamp

  2. Элемент ушел на обработку: PROCESSING + TS

  3. Элемент закончил обработку: FINISHED, равнозначно удалению

Навернулся воркер? Значит висит элемент уже несколько часов а состоянии PROCESSING. Фильтруем по времени, забираем и обновляем метку. Теперь просто понять? Тривиальная линейность. Строго ограниченные переходы из одного состояния в другое.

Да, многократная нагрузка из-за r/w. Разделяйте на логическом уровне, если хочется.

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

Sign up to leave a comment.

Articles