AI
А что если у тебя обработчик улетит в циклический крэш?
Size: a a a
2020 October 26
S
Ты меня агитируешь сейчас все переписать на раббит?)
AI
Всю очередь сдует в dev/null или память забьется и редис сдохнет возможно утащив что то еще на редис посаженное?
AI
Ты меня агитируешь сейчас все переписать на раббит?)
Я удостоверяюсь что ты предусмотрел все нужные риски
S
Я знаю плюсы этого, но у меня сейчас хватает и без этого работы. А коллеги которые это использую и будут переписывать - сами уже решат что им нужно
AI
А, понятно, и так сойдет
S
Это временное решение - все это понимают
AI
Это временное решение - все это понимают
Сервисы только на таких и живут
S
Тут нет. Руби знаю только я в отделе, поэтому это лишний повод все что используется переписывать 😃
S
У меня были наработки по этому - я смог их быстро внедрить. Это нам наконец то позволило найти проблему, которая была головной болью последние пол года - почему все внезапно все становится плохо, а потом точно так же само проходит и еще пачку застарелых проблем
S
Так что да - с учетом всех рисков этот подход решил гораздо больше проблем, чем создал. Проблемы циклических рестартов обработчика никуда бы не делись и на старой схеме. никуда они не денутся и с раббитом. Проблема сообщений в очереди - да раббит позволит её избежать в теории. На практике - опыта нет ни у кого - не факт что это сходу окажется лучше решения на редисе.
Дроп всего в редисе при его падении - неприятно. Но с учетом того что примерно такое же происходит при падении обработчика с прямы хождением в интерфейс - ничего нового не будет. Только теперь это действительно аварийное событие а не рядовое явление как раньше
Дроп всего в редисе при его падении - неприятно. Но с учетом того что примерно такое же происходит при падении обработчика с прямы хождением в интерфейс - ничего нового не будет. Только теперь это действительно аварийное событие а не рядовое явление как раньше
2020 October 27
D
@ShadoWalkeR31 вам же нужно было очередь последовательно разгребать?
D
или без разницы? главное очередь разгрести
D
обработка батчами подошла бы?
D
т.е. взять например 1000 элементов из очереди, и одним инсертом вставить в БД или обработать одним батчем
S
И если чтото пошло не так всю пачку протерять
S
Но вопрос же был не в этом
D
ну я как понял, нужно было куда-то лить реалтаймово данные и их обрабатывать. и чтобы было отказоустойчиво
S
Нет. Вопрос был как без явного объявления методов клиента редиса проксировать вызовы к нему обвязав это failoverом