Зависит от сообщения, которое вы отправили в обработку через outbox.
Перед принятием решения нужно ли отправлять сообщение в асинхрон, стоит ответить на вопрос: Можем ли мы выполнять эту операцию асинхронно или она должна отработать синхронно ?
Например, можем ли мы при создании заказа в асинхронне проверять доступность доставки, очевидно что нет, нам нужен ответ сразу. Можем ли мы освободить интервал доставки в асинхронне, ответ: Да, эта операция должна быть гарантированно выполнена и никак не влияет на пользователя сделавшего заказ.
Дальше что, через 10 секунд повторная попытка связи и так до победного конца, но не более N раз?
В целом, да. Это решается на этапе реализации: сколько и какой интервал должен быть между попытками связаться с брокером или сервисом, обычно это выносят в конфиг решения.
В отличие от примера с kafka где мы рассматривали exactly-once и пути его достижения, мы выбрали at-least-once поэтому это согласуется с тем что вы написали. Если сервис не успеет отработать или упадёт, то мы попытаемся еще раз выполнить работу.
В таком случае вы можете показать доступным интервал, который окажется занят после обработки текущих сообщений.
У нас не возникает проблем с потенциально устаревшим значением quantity. В нашем примере отправляется запрос на то, чтобы освободить интервал т.е. вычесть из quantity единицу. Поэтому после обработки текущих сообщений интервал наоборот освободится т.е. появятся доп. слоты для доставки заказов
Это означает, что не стоит выходить за пределы работы по схеме: запродюсили сообщение в kafka, на другой стороне его прочитали и снова запродюсили своё сообщение. Если выйти из этой схемы работы, например, добавить поход в микросервис, то теряется семантика exactly-once. Почему? Например, мы вычитали сообщение из kafka, делаем запрос в микросервис, он таймаутит, мы получаем ответ об этом и не выполняем ACK. При этом микросервис мог выполнить свою работу, но просто не успеть ответить нам. Происходит повторная попытка обработать сообщение. Снова делаем запрос в микросервис, он отвечает нам ошибкой т.к. пришли дублирующие данные. Exactly once нарушен.
Думаю, на это можно сделать отдельный доклад, но постараюсь ответить=)
> Какую там тактику применяете, с откатами или нет.
У нас реализован паттерн Saga, а сервис Orders Management является оркестратором, который сообщает другим микросервисам, какое действие необходимо выполнить далее. Как было сказано в статье если в процессе создания заказа, что-то пошло не так, то сервис отправляет ряд компенсирующих запросов, чтобы откатить сделанные изменения в других микросервисах. Поэтому да, откат есть.
> Что делаете с параллельностью если один пользователь покупает одновременно два разных товара, и какая тут тактика, ведь если делать сначала резерв в микросервисе, а потом ему не хватит денег на товар, он при этом в "очереди" был платёжеспособный покупатель которому вы отказали, хотя он мог бы купить , но ему не досталось.
Если это два разных товара, например, один будет доставлять Lamoda, а другой наш партнёр, то он разбивается на два разных заказа. Эти заказы будут обработаны последовательно, но оплата будет общая. Если оплата не пройдёт, то будет попытка перевести заказ в постоплату и сохранить его за пользователем. Если в постоплату невозможно выполнить перевод, то Orders Management выполнит ряд компенсирующих запросов, чтобы откатить сделанные изменения, в том числе снять резерв товара за пользователем. После этого товары снова будут отображены на сайте доступными для покупки.
Зависит от сообщения, которое вы отправили в обработку через outbox.
Перед принятием решения нужно ли отправлять сообщение в асинхрон, стоит ответить на вопрос: Можем ли мы выполнять эту операцию асинхронно или она должна отработать синхронно ?
Например, можем ли мы при создании заказа в асинхронне проверять доступность доставки, очевидно что нет, нам нужен ответ сразу. Можем ли мы освободить интервал доставки в асинхронне, ответ: Да, эта операция должна быть гарантированно выполнена и никак не влияет на пользователя сделавшего заказ.
В целом, да. Это решается на этапе реализации: сколько и какой интервал должен быть между попытками связаться с брокером или сервисом, обычно это выносят в конфиг решения.
В отличие от примера с kafka где мы рассматривали exactly-once и пути его достижения, мы выбрали at-least-once поэтому это согласуется с тем что вы написали. Если сервис не успеет отработать или упадёт, то мы попытаемся еще раз выполнить работу.
У нас не возникает проблем с потенциально устаревшим значением quantity. В нашем примере отправляется запрос на то, чтобы освободить интервал т.е. вычесть из quantity единицу. Поэтому после обработки текущих сообщений интервал наоборот освободится т.е. появятся доп. слоты для доставки заказов
> Что означает не выходите из круга ?
Это означает, что не стоит выходить за пределы работы по схеме: запродюсили сообщение в kafka, на другой стороне его прочитали и снова запродюсили своё сообщение.
Если выйти из этой схемы работы, например, добавить поход в микросервис, то теряется семантика exactly-once. Почему? Например, мы вычитали сообщение из kafka, делаем запрос в микросервис, он таймаутит, мы получаем ответ об этом и не выполняем ACK. При этом микросервис мог выполнить свою работу, но просто не успеть ответить нам. Происходит повторная попытка обработать сообщение. Снова делаем запрос в микросервис, он отвечает нам ошибкой т.к. пришли дублирующие данные. Exactly once нарушен.
Думаю, на это можно сделать отдельный доклад, но постараюсь ответить=)
> Какую там тактику применяете, с откатами или нет.
У нас реализован паттерн Saga, а сервис Orders Management является оркестратором, который сообщает другим микросервисам, какое действие необходимо выполнить далее. Как было сказано в статье если в процессе создания заказа, что-то пошло не так, то сервис отправляет ряд компенсирующих запросов, чтобы откатить сделанные изменения в других микросервисах. Поэтому да, откат есть.
> Что делаете с параллельностью если один пользователь покупает одновременно два разных товара, и какая тут тактика, ведь если делать сначала резерв в микросервисе, а потом ему не хватит денег на товар, он при этом в "очереди" был платёжеспособный покупатель которому вы отказали, хотя он мог бы купить , но ему не досталось.
Если это два разных товара, например, один будет доставлять Lamoda, а другой наш партнёр, то он разбивается на два разных заказа. Эти заказы будут обработаны последовательно, но оплата будет общая. Если оплата не пройдёт, то будет попытка перевести заказ в постоплату и сохранить его за пользователем. Если в постоплату невозможно выполнить перевод, то Orders Management выполнит ряд компенсирующих запросов, чтобы откатить сделанные изменения, в том числе снять резерв товара за пользователем. После этого товары снова будут отображены на сайте доступными для покупки.