Разрабатывая веб-приложение важно помнить об отказоустойчивости. Fault tolerance – метод проектировки, при котором неработоспособность отдельного элемента или функции приложения не выводит из строя само приложение, устойчивость программы к отказам. Не путайте fault tolerance с failover (аварийное переключение) – переключением отказавшего функционала резервному компоненту.
Отказоустойчивая архитектура готова к сбоям. Приложение проектируют таким образом, чтобы при падении компоненты сами перезапускались без сбоев, потерь или ошибок.
Как пример используем скрипт для рассылки писем по базе. Не отказоустойчивая программа в случае сбоя при выполнении начнет процесс сначала, если восстановить работу.
А скрипт, написанный с учетом fault tolerance поймет, что при последнем выполнении произошел сбой и продолжит отправлять письма с пользователя, на котором произошла ошибка.
Сам скрипт выглядит так:
# получаем id пользователя для восстановления, если скрипт был завершен некорректно
$restart_from = file_get_contents(‘/tmp/mail.status’);
# получаем список всех пользователей
$users = get_list(‘SELET * FROM users ORDER BY id’);
foreach ( $users as $user )
{
# пропускаем отправку, если переменная восстановления задана
if ( $restart_from && $user[‘id’] <= $restart_from ) continue;
send_email($user[‘id’]);
# сохраняем id пользователя в файл статуса
file_put_contents(‘/tmp/mail.status’, $user[‘id’]);
}
# удаляем файл статуса
unlink(‘/tmp/mail.status’);
## Отсутствие файла статуса свидетельствует об успешном завершении предыдущей отправки
Еще один вариант отказоустойчивого приложения – запуск скриптов в отдельных дочерних процессах, используя многопоточность. Если появятся сбои, то процесс закончится с ошибкой, а воркер перезапустится. Для этого подойдет Gearman.
В UNIX-подобных системах сигналы – метод уведомления процессов о событиях. Они выполняются асинхронно и с высоким приоритетом, так что при получении такого notification система прерывает выполнение процесса.
При чем здесь сигналы в статье о fault tolerance? Функция подходит для остановки или перезапуска процессов (демонов) в случае ошибки, и корректного завершения задачи.
Для PHP доступно расширение-менеджер процессов pcntl. Оно использует UNIX-стиль управления процессами и подпрограммами, в том числе обработку сигналов. Так что на его основе реализуется простейшая отказоустойчивая система:
declare(ticks = 1);
class SIG { public static $cought = 0; }
…
function sig_handler($sig) {
SIG::$cought = $sig;
echo ‘Finishing all operations to exit…’ . “n”;
}
pcntl_signal(SIGINT, “sig_handler”);
pcntl_signal(SIGTERM, “sig_handler”);
pcntl_signal(SIGHUP, “sig_handler”);
while ( true )
{
/*
Длинный код скрипта для обработки с нужными действиями
*/
…
if ( SIG::$cought )
{
echo ‘finished operations, exiting now’ . “n”;
exit;
}
}
## Отлавливает сигналы SIGINT, SIGTERM, SIGHUP, если такой сигнал приходит, то скрипт останавливается
Такой подход используется для корректного перезапуска скриптов при использовании supervisor.
pcntl подходит для асинхронного выполнения PHP как альтернатива pthreads. Отличия между расширениями в том, что pcntl – менеджер процессов, а pthreads – менеджер потоков.
PHP-библиотека [https://github.com/odesk/phystrix Phystrix] разрабатывалась под впечатлением и по принципу Netflix Hystrix. Она создана для распределенных приложений с зависимостями.
По своей сути Phystrix – обертка для PHP-скриптов, которая изолирует их выполнение друг от друга, обеспечивая отказоустойчивость и отсутствие каскадных сбоев.
При создании комманды Phystrix используется метод run(), который выполняет нужную функцию (запрос к базе данных, вызов API) и метод getFallback(), который вызывает значение по умолчанию.
Затем при вызове execute() Phystrix запускает функцию, обозначенную в run(). И в случае ошибки вызывает значение по умолчанию в getFallback(), к примеру “Функция временно недоступна”.
Для корректной работы библиотеки потребуется расширение [http://php.net/manual/en/book.apc.php APC], а для установки рекомендуется использовать [https://getcomposer.org/ Composer]:
"require": {
“odesk/phystrix”: “dev-master”
}
## Будет использовать репозиторий компании на GitHub
В простейшем случае пример использования Phystrix будет выглядеть так:
use OdeskPhystrixAbstractCommand;
**class MyCommand extends AbstractCommand**
{
protected $name;
public function __construct($name)
{
$this->name = $name;
}
/**
# Внутренний вызов функции только если запрос разрешен
# @return mixed
*/
protected function run()
{
return ‘Hello ‘ . $this->name;
}
}
## Все комманды должны использовать наследование AbstractCommand
А затем комманду можно выполнять используя метод execute():
$myCommand = $phystrix->getCommand('MyCommand', 'Alex'); # 'Alex' передается конструктору MyCommand
$result = $myCommand->execute();
## Дополнительные параметры в getCommand передаются конструктору
Библиотека может использоваться для множества функций, запросов HTTP, кастомных или стандартных API, а также SQL:
use OdeskPhystrixAbstractCommand;
class GetTop extends AbstractCommand
{
protected $startDate;
public function __construct($startDate)
{
$this->startDate = $startDate;
}
protected function run()
{
# получение зависимостей DB из служебного локатора Phystrix
$db = $this->serviceLocator->get(‘db’);
$sql = ”
SELECT
U.DisplayName,
COUNT(C.ID) AS CommentCount
FROM
Users AS U
INNER JOIN Comments AS C ON U.ID = C.UserID
GROUP BY
U.DisplayName
WHERE C.time > ?
ORDER BY
COUNT(C.ID) DESC
LIMIT 1;
“;
return $db->fetchOne($sql, $this->_startDate);
}
protected function getFallback()
{
return “функция временно недоступна”;
}
}
## SQL-запрос обернут в шаблон проектирования
Ну а для запуска используется все тот же метод execute():
$getTopCommenterNameCmd =
$phystrixFactory->getCommand(‘GetTop’, strtotime(‘-1 week’));
$topCommenterName = $getTop->execute();
## Phystrix самостоятельно проверит все зависимости
Не пренебрегайте отказоустойчивостью сервиса или приложения. Сигналов PHP достаточно для создания fault-tolerant архитектуры. А внешние библиотеки и решения, как Phystrix, обеспечат гибкость, но принесут дополнительные сложности при настройке и внедрении.
Прокси (proxy), или прокси-сервер — это программа-посредник, которая обеспечивает соединение между пользователем и интернет-ресурсом. Принцип…
Согласитесь, было бы неплохо соединить в одно сайт и приложение для смартфона. Если вы еще…
Повсеместное распространение смартфонов привело к огромному спросу на мобильные игры и приложения. Миллиарды пользователей гаджетов…
В перечне популярных чат-ботов с искусственным интеллектом Google Bard (Gemini) еще не пользуется такой популярностью…
Скрипт (англ. — сценарий), — это небольшая программа, как правило, для веб-интерфейса, выполняющая определенную задачу.…
Дедлайн (от англ. deadline — «крайний срок») — это конечная дата стачи проекта или задачи…