Как стать автором
Обновить
11
0
Михаил @Mania_c

Teamlead

Зависит от сообщения, которое вы отправили в обработку через outbox.

Перед принятием решения нужно ли отправлять сообщение в асинхрон, стоит ответить на вопрос: Можем ли мы выполнять эту операцию асинхронно или она должна отработать синхронно ?

Например, можем ли мы при создании заказа в асинхронне проверять доступность доставки, очевидно что нет, нам нужен ответ сразу. Можем ли мы освободить интервал доставки в асинхронне, ответ: Да, эта операция должна быть гарантированно выполнена и никак не влияет на пользователя сделавшего заказ.

Дальше что, через 10 секунд повторная попытка связи и так до победного конца, но не более N раз?

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

В отличие от примера с kafka где мы рассматривали exactly-once и пути его достижения, мы выбрали at-least-once поэтому это согласуется с тем что вы написали. Если сервис не успеет отработать или упадёт, то мы попытаемся еще раз выполнить работу.

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

У нас не возникает проблем с потенциально устаревшим значением quantity. В нашем примере отправляется запрос на то, чтобы освободить интервал т.е. вычесть из quantity единицу. Поэтому после обработки текущих сообщений интервал наоборот освободится т.е. появятся доп. слоты для доставки заказов

> Что означает не выходите из круга ?

Это означает, что не стоит выходить за пределы работы по схеме: запродюсили сообщение в kafka, на другой стороне его прочитали и снова запродюсили своё сообщение. 
Если выйти из этой схемы работы, например, добавить поход в микросервис, то теряется семантика exactly-once. Почему? Например, мы вычитали сообщение из kafka, делаем запрос в микросервис, он таймаутит, мы получаем ответ об этом и не выполняем ACK. При этом микросервис мог выполнить свою работу, но просто не успеть ответить нам. Происходит повторная попытка обработать сообщение. Снова делаем запрос в микросервис, он отвечает нам ошибкой т.к. пришли дублирующие данные. Exactly once нарушен.

 

Думаю, на это можно сделать отдельный доклад, но постараюсь ответить=)

>  Какую там тактику применяете, с откатами или нет.

У нас реализован паттерн Saga, а сервис Orders Management является оркестратором, который сообщает другим микросервисам, какое действие необходимо выполнить далее. Как было сказано в статье если в процессе создания заказа, что-то пошло не так, то сервис отправляет ряд компенсирующих запросов, чтобы откатить сделанные изменения в других микросервисах. Поэтому да, откат есть.

> Что делаете с параллельностью если один пользователь покупает одновременно два разных товара, и какая тут тактика, ведь если делать сначала резерв в микросервисе, а потом ему не хватит денег на товар, он при этом в "очереди" был платёжеспособный покупатель которому вы отказали, хотя он мог бы купить , но ему не досталось.

Если это два разных товара, например, один будет доставлять Lamoda, а другой наш партнёр, то он разбивается на два разных заказа. Эти заказы будут обработаны последовательно, но оплата будет общая. Если оплата не пройдёт, то будет попытка перевести заказ в постоплату и сохранить его за пользователем. Если в постоплату невозможно выполнить перевод, то Orders Management выполнит ряд компенсирующих запросов, чтобы откатить сделанные изменения, в том числе снять резерв товара за пользователем. После этого товары снова будут отображены на сайте доступными для покупки.

При регистрации я указал кол-во билетов три, то есть я могу взять еще трёх друзей и не возникнет никаких вопросов при встрече?

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность