Уведомления

Группа в Telegram: @pythonsu

#1 Авг. 21, 2014 13:14:11

Budulianin
От:
Зарегистрирован: 2011-10-18
Сообщения: 1218
Репутация: +  33  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Есть WSGI приложение. Запускается в uWSGI. Приложение построено так, что если worker uWSGI “погибнет” в определённом месте(например от нагрузки), то не выполнит запрос доконца и не успеет убрать значение из БД, что в дальнейшем нарушит работу всему приложению(пока значение не уберёшь из БД).

Что думаете? Это критическая архитектурная ошибка, которая снижает отказоустойчивость?
Или просто нужно стремиться, чтобы workerы не “падали”, а такая особенность приложения вполне приемлема в реальности?



Офлайн

#2 Авг. 21, 2014 16:16:01

s0rg
От:
Зарегистрирован: 2011-06-05
Сообщения: 777
Репутация: +  25  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Budulianin
Это критическая архитектурная ошибка, которая снижает отказоустойчивость?
this

Что будет если клиент начнет запрос, но отвалится/отсоединится?

Офлайн

#3 Авг. 21, 2014 16:52:02

Budulianin
От:
Зарегистрирован: 2011-10-18
Сообщения: 1218
Репутация: +  33  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

s0rg
this
?
s0rg
Что будет если клиент начнет запрос, но отвалится/отсоединится?
Я думаю что ничего, ведь запрос отработает до конца, просто отдать его будет некому.

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



Офлайн

#4 Авг. 21, 2014 17:28:22

s0rg
От:
Зарегистрирован: 2011-06-05
Сообщения: 777
Репутация: +  25  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Budulianin
?
Указание, что по моему мнению, именно этот вариан правильный )

Budulianin
воркер может упасть
У вас воркеры не перезапускаются?
Uwsgi не может упасть? (у меня ни разу не падал, но все же)
И не факт, что воркер будет отрабатывать до конца, в случае отвалившегося клиента.
Для критичных данных есть очереди, отдавайте задачу, о записи важных для вас данных
в очередь (RabbitMQ например) - это надежней, чем надеятся, что цепочка клиент-веб-сервер-uwsgi-ваш код будет всегда отрабатывать как Вы предполагаете. Но это мое мнение )

Офлайн

#5 Авг. 21, 2014 17:38:04

Budulianin
От:
Зарегистрирован: 2011-10-18
Сообщения: 1218
Репутация: +  33  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

s0rg
У вас воркеры не перезапускаются?
Перезапускаются, но это никак не влияет, потому что воркер умер в неподходящий момент :) и оставил в БД, то что должен был убрать.

s0rg
Uwsgi не может упасть?
Может, у него даже настройки есть на этот случай, убивать воркеров, если главный процесс умер.

s0rg
И не факт, что воркер будет отрабатывать до конца, в случае отвалившегося клиента.
Как проверить правильно? Чем сделать запрос, чтобы его оборвать в нужный момент?
Убивать процесс сигналом, пока он ждёт ответ? Наверно это плохой вариант.

s0rg
Для критичных данных есть очереди, отдавайте задачу, о записи важных для вас данных
Не знаю подойдёт такой вариант или нет, надо подумать.

s0rg
Но это мое мнение )
Его я и хотел получить.



Офлайн

#6 Авг. 21, 2014 17:42:26

s0rg
От:
Зарегистрирован: 2011-06-05
Сообщения: 777
Репутация: +  25  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Budulianin
Как проверить правильно? Чем сделать запрос, чтобы его оборвать в нужный момент?
Вставить sleep в интерисующий обработчик?

Budulianin
Может, у него даже настройки есть на этот случай, убивать воркеров, если главный процесс умер.
Есть - посмотрите в сторону emperor, если я правильно понял идею.

Офлайн

#7 Авг. 21, 2014 17:45:20

Budulianin
От:
Зарегистрирован: 2011-10-18
Сообщения: 1218
Репутация: +  33  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

s0rg
Вставить sleep в интерисующий обработчик?
Пока он спит, убить процесс, который сделал запрос?

s0rg
Есть - посмотрите в сторону emperor, если я правильно понял идею.
Это не идея:), просто сказал про возможности uWSGI.



Офлайн

#8 Авг. 21, 2014 17:54:50

s0rg
От:
Зарегистрирован: 2011-06-05
Сообщения: 777
Репутация: +  25  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Budulianin
Пока он спит, убить процесс, который сделал запрос?
Да, именно.
Ксати а на чем само приложение? flask?

Офлайн

#9 Авг. 21, 2014 17:56:08

Budulianin
От:
Зарегистрирован: 2011-10-18
Сообщения: 1218
Репутация: +  33  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

s0rg
Да, именно.
Спасибо за ответы.

s0rg
flask?
only Pyramid :)



Офлайн

#10 Авг. 21, 2014 17:59:58

s0rg
От:
Зарегистрирован: 2011-06-05
Сообщения: 777
Репутация: +  25  -
Профиль   Отправить e-mail  

Архитектура приложения. Отказоустойчивость.

Budulianin
only Pyramid
За него не скажу, но у flask есть специальный обработчик всех ошибок, типа финализатор запроса, возможно, что-то подобное есть и в пирамиде.
Наверно это будет самое простое решение - разместить код ‘прибирающий’ в бд именно в таком обработчике )

Отредактировано s0rg (Авг. 21, 2014 18:01:52)

Офлайн

Board footer

Модераторировать

Powered by DjangoBB

Lo-Fi Version