Построение отказоустойчивой (fault tolerant) системы

[pyatigil]

«Infinite Loop… Например, можно отправлять сообщение об ошибке в систему мониторинга (см. ниже) и переходить к обработке следующего таска.» — еще один вариант это увеличивать промежутки между попытками обработать такое сообщения. К примеру, google app engine именно так подходит к обработке своих тасков — при каждом отказе удваивает время до следующего запуска вплоть до суток.

[javaspecialist]

Спасибо, но в этом месте я больше упор делал на бесконечные циклы в системах, которые обрабатывают сообщения последовательно, т.е. пока не обработан предыдущий, следующий не обрабатывается. И тут таймеры точно не могут. Твой случай скорее отностится к тротлингу (Degradate gracefully. Throttling).

[DarkRIP]

В одной системе, с которой я работал, применяли следующюю технику: Каждый поток приложения рапортовал, что он не завис, а отдельный специально созданный поток собирал рапорты, и осуществлял перезапуск системы, если от какого-то потока нет рапорта заданное время.

[javaspecialist]

Интересно, правда, не понятно почему вы перезапускаете всю систему, а не только плохой поток. Или вы просто не можете его корректно остановить? Кстати, кто-нибудь знает можно ли жестко убить в java поток или это невозможно теоретически сделать не только в java?

[DarkRIP]

Я, в своё время, тоже об этом задумался, но потом решил что-всётаки это не правильно. Возможно источник ошибки в другом потоке, возможно он успел изменить какие-либо общие данные или залочить мьютексы и.т.д., кроме того, тогда все потоки изначально нужно проэктировать с учётом того, что их можно перезапустить. Коректно остановить поток по определению нельзя, так как он уже весит, можно только жёстко его убить, при этом не зная, что он делал в этот момент.

[socialNoob]

Жалко, что разработчики некоторого банковского ПО даже не в курсе техник, которые здесь изложены.

А по сути, это, пусть и специфическая, но классика — полностью или частично, эти советы описаны в немалом количестве книг, и не только по JAVA.

Возвращаясь к теме банковского ПО — совсем недавно читал статью, начинающуюся со слов «если единственная часть системы, которая не отказала — конечный терминал, это еще не повод отказывать Вашим клиентам в обслуживании». Пруф, к сожалению, уже потерялся, но если найдете — обязательно прочитайте — советую.

[dkg]

… в вашей системе должно присутствовать N+1 таких компонент, так как иначе, если у вас упадет один из элементов, то на все остальные нагрузка увеличиться и вся ваша система рухнет как домино

Также необходимо ограничить сверху максимальное количество запросов, которые могут быть направлены на каждую ноду кластера Load Balancer-ом. Это поможет защититься от эффекта домино, даже если упадет не один, а два, три, или N/2 элемента. Общая capacity системы будет уменьшаться пропорцинально количеству вышедших из строя элементов, и большее количество пользователей будет получать отлупы, но система должна выживать.

Мои $.02

[Treg]

Если говорить о веб-серверах, то здесь упор можно делать на то, чтобы при высоких нагрузках «продолжать обслуживать» большинство клиентов, в то время как некоторые могут отваливаться, например, по таймауту — это нормальная практика. Главное, чтобы весь сервис не умер.

[shane54]

а на DR у нас была мега железка с огромным количеством ядер, но с небольшой тактовой частотой, так что этот компонент стал затыкаться

Скажите, просто интересно, речь случайно не об истории с Oracle-базами и чипами Sun Niagara?

[javaspecialist]

Железка — похоже, но затыкавшееся приложение — TIBCO EMS, а не Oracle БД.