HG-544: shumaich base #512
Conversation
| call_with_retry(Function, Args) -> | ||
| hg_retry:call_with_retry( | ||
| fun() -> | ||
| case hg_woody_wrapper:call(accounter_new, Function, Args) of | ||
| {ok, _} = Ok -> | ||
| {return, Ok}; | ||
| {exception, #shumaich_NotReady{}} -> | ||
| retry; | ||
| {exception, _} = Exception -> | ||
| {return, Exception} | ||
| end | ||
| end, | ||
| get_retry_strategy(Function) | ||
| ). |
There was a problem hiding this comment.
Не уверен конечно, что это рабочий вариант. Если конечно ш̙͍̯͒̅͊а̜̥͙̜͔̣͙͗ͥ͑̍̐̆̓м͖аи̩̜̓ͪӵ̻̠̯͚̩̣̺́̅̓̏̎̍̚ не даёт гарантий на upper bound по времени обработки изменений своего состояния, в чём я немного сомневаюсь. Быть может это не единственная конечно стратегия работы с NotReady?
В моём представлении везде, где идёт взаимодействие с ш̙͍̯͒̅͊а̜̥͙̜͔̣͙͗ͥ͑̍̐̆̓м͖аи̩̜̓ͪӵ̻̠̯͚̩̣̺́̅̓̏̎̍̚ем, и надо получить баланс, нам придётся сначала сохранять clock в mg, а потом уже долбить ш̙͍̯͒̅͊а̜̥͙̜͔̣͙͗ͥ͑̍̐̆̓м͖аи̩̜̓ͪӵ̻̠̯͚̩̣̺́̅̓̏̎̍̚ запросами. Опять же, быть может ты это тоже понимаешь.
There was a problem hiding this comment.
Я честно говоря и не вижу теперь других стратегий, подумав ещё. Либо ретраить запросы тут, используя потенциально бесконечную стратегию, либо городить какой-то сложный механизм (особенно если учесть твои замечания по функции plan), который будет перед каждым походом в аккаунтер сохранять ивент вроде waiting_accounter, и только после успешного сохранять *_clock_updated (и так n-раз, в случае с plan), но мне не кажется что преимущества этого подхода перевешивают трудоемкость его реализации (учитывая что проблема, которую решит этот подход, никак не обрабатывается и в текущем коде).
There was a problem hiding this comment.
используя потенциально бесконечную стратегию
Бесконечно нас mg не будет ждать всё равно. Смысл в ретраях тут есть на самом деле некоторый, потому что минимальный ненулевой таймаут на mg − это аж целая 1 секунда, а шамаич по идее должен гораздо быстрее синкаться в штатном режиме.
(особенно если учесть твои замечания по функции plan)
Ну там на самом деле нам критично как я понимаю только финальный clock (после всех холдов) сохранить, а не промежуточные.
Опять же, я вот только что почему-то подумал, что в теории контроль идемпотентности на стороне шамаича + его гарантии на максимальное штатное время синка (например, хз, 5 секунд) могут нас избавить от необходимости clock хранить. Потому что даже в обычных условиях crash-recovery хеллгейта может привести к тому, что мы (как минимум) один батч два раза пошлём или (как максимум) один и тот же план.
Тут правда возможно не помешает вспомнить, что в рамках работ по лимитеру ивенты про clock update уже начинают заезжать в протокол.
К тому же кстати результат операции Hold не может быть NotReady:
https://github.com/rbkmoney/shumaich-proto/blob/700a5b4d635b6d7c26fe3cf3a58896f8d2330645/proto/shumaich.thrift#L176-L178
никак не обрабатывается и в текущем коде
Но текущий код же не работает с асинхронным аккаунтером. Или ты про что-то другое?
There was a problem hiding this comment.
Или ты про что-то другое?
Ну вот скорее про это:
Потому что даже в обычных условиях crash-recovery хеллгейта может привести к тому, что мы (как минимум) один батч два раза пошлём или (как максимум) один и тот же план.
А то что mg не будет ждать бесконечно я наоборот часто забываю, лол. В целом кажется этот вопрос надо решать именно в ключе того поведения, когда ш̙͍̯͒̅͊а̜̥͙̜͔̣͙͗ͥ͑̍̐̆̓м͖аи̩̜̓ͪӵ̻̠̯͚̩̣̺́̅̓̏̎̍̚ сильно не укладывается в ожидаемые таймауты по какой-то причине. Во варианте с ретраями на этом уровне мы, наверное, будем работать быстрее в 99% случаев, но вот в том 1% проценте, когда попытки будут заканчиваться, как правильнее поступить не очень понятно. Кажется, что все так же ничто не будет мешать просто поднять машину и, как и раньше, сделать те же холды еще раз.
Можно совместить ретраи здесь с ретраями посредством mg, но это видится большим объемом кода, который наверное надо как-то оправдать.
Ну там на самом деле нам критично как я понимаю только финальный clock (после всех холдов) сохранить, а не промежуточные.
Ну тут мысль была что мы должны будем не просто начать ходлить план сначала, а продолжить с того места, с которого зафейлились, но да, это излишне.
Тут правда возможно не помешает вспомнить, что в рамках работ по лимитеру ивенты про clock update уже начинают заезжать в протокол.
Но лимитер это же вроде отдельный сервис еще между хг и ш̙͍̯͒̅͊а̜̥͙̜͔̣͙͗ͥ͑̍̐̆̓м͖аи̩̜̓ͪӵ̻̠̯͚̩̣̺́̅̓̏̎̍̚ем, который, подозреваю, хендлит и NotReady кейсы. *_clock_update- ивенты сами по себе есть и в этом эпике в других пиарах.
К тому же кстати результат операции Hold не может быть NotReady
Это кстати да, лол, plan/hold в принципе можно исключить из механики ретраев. Но commit/rollback все еще могут.
| case hold(PlanID, Batch, Timestamp, Clock) of | ||
| {ok, NewClock} -> | ||
| execute_plan(PlanID, Rest, Timestamp, NewClock); | ||
| {error, _} = Error -> |
There was a problem hiding this comment.
Я кстати только сейчас осознал, что с ш̤̖͙͍̄͂а̦̣̫̪̱̬̃͛̊ͯͧм̟͍͈̞̝̩̓̄ͬ̉̂ͯӓ̱͔͕̻͔̯̦́̒̓̑̑̑и̩̖ͥч͕̊̈́ͫͮ͌̉̎ем мы можем оказаться в ситуации, когда половина плана захолдирована, и машина упала. Надо бы наверное понять, что с этим делать, если что. По идее эта ошибка может только на этапе интеграции проявиться, поэтому повода какую-то обвязку по обработке в виде кода вроде как нет, но тем не менее.
There was a problem hiding this comment.
Мне казалось, что шамаич умеет в идемпотентность, и поэтому ничего страшного что мы после поднятия машины попробуем захолдировать захолженные холды еще раз. 🤔
There was a problem hiding this comment.
Тут я скорее про ошибку InvalidPostingParams, с которой в общем случае не пойми что делать. Да и это вообще не докоп, а так, наблюдение.
There was a problem hiding this comment.
не совсем понятен кейс когда ты такую ошибку можешь получить
WWWcool
left a comment
WWWcool
left a comment
There was a problem hiding this comment.
так как сплиты едут уже сейчас, то видимо в этом ПР придется подтягивать работу с новыми аккаунтами и сплитованными кешфлоу
This is the base commit for the shumaich migration, it adds a new accounting module and updates the docker-compose file
Steps for moving to shumaich: