Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 10
«Infinite Loop… Например, можно отправлять сообщение об ошибке в систему мониторинга (см. ниже) и переходить к обработке следующего таска.» — еще один вариант это увеличивать промежутки между попытками обработать такое сообщения. К примеру, google app engine именно так подходит к обработке своих тасков — при каждом отказе удваивает время до следующего запуска вплоть до суток.
Спасибо, но в этом месте я больше упор делал на бесконечные циклы в системах, которые обрабатывают сообщения последовательно, т.е. пока не обработан предыдущий, следующий не обрабатывается. И тут таймеры точно не могут. Твой случай скорее отностится к тротлингу (Degradate gracefully. Throttling).
В одной системе, с которой я работал, применяли следующюю технику: Каждый поток приложения рапортовал, что он не завис, а отдельный специально созданный поток собирал рапорты, и осуществлял перезапуск системы, если от какого-то потока нет рапорта заданное время.
Интересно, правда, не понятно почему вы перезапускаете всю систему, а не только плохой поток. Или вы просто не можете его корректно остановить? Кстати, кто-нибудь знает можно ли жестко убить в java поток или это невозможно теоретически сделать не только в java?
Я, в своё время, тоже об этом задумался, но потом решил что-всётаки это не правильно. Возможно источник ошибки в другом потоке, возможно он успел изменить какие-либо общие данные или залочить мьютексы и.т.д., кроме того, тогда все потоки изначально нужно проэктировать с учётом того, что их можно перезапустить. Коректно остановить поток по определению нельзя, так как он уже весит, можно только жёстко его убить, при этом не зная, что он делал в этот момент.
Жалко, что разработчики некоторого банковского ПО даже не в курсе техник, которые здесь изложены.
А по сути, это, пусть и специфическая, но классика — полностью или частично, эти советы описаны в немалом количестве книг, и не только по JAVA.
Возвращаясь к теме банковского ПО — совсем недавно читал статью, начинающуюся со слов «если единственная часть системы, которая не отказала — конечный терминал, это еще не повод отказывать Вашим клиентам в обслуживании». Пруф, к сожалению, уже потерялся, но если найдете — обязательно прочитайте — советую.
А по сути, это, пусть и специфическая, но классика — полностью или частично, эти советы описаны в немалом количестве книг, и не только по JAVA.
Возвращаясь к теме банковского ПО — совсем недавно читал статью, начинающуюся со слов «если единственная часть системы, которая не отказала — конечный терминал, это еще не повод отказывать Вашим клиентам в обслуживании». Пруф, к сожалению, уже потерялся, но если найдете — обязательно прочитайте — советую.
… в вашей системе должно присутствовать N+1 таких компонент, так как иначе, если у вас упадет один из элементов, то на все остальные нагрузка увеличиться и вся ваша система рухнет как домино
Также необходимо ограничить сверху максимальное количество запросов, которые могут быть направлены на каждую ноду кластера Load Balancer-ом. Это поможет защититься от эффекта домино, даже если упадет не один, а два, три, или N/2 элемента. Общая capacity системы будет уменьшаться пропорцинально количеству вышедших из строя элементов, и большее количество пользователей будет получать отлупы, но система должна выживать.
Мои $.02
Если говорить о веб-серверах, то здесь упор можно делать на то, чтобы при высоких нагрузках «продолжать обслуживать» большинство клиентов, в то время как некоторые могут отваливаться, например, по таймауту — это нормальная практика. Главное, чтобы весь сервис не умер.
а на DR у нас была мега железка с огромным количеством ядер, но с небольшой тактовой частотой, так что этот компонент стал затыкаться
Скажите, просто интересно, речь случайно не об истории с Oracle-базами и чипами Sun Niagara?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Построение отказоустойчивой (fault tolerant) системы