Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

PHP IPC — Межпроцессное взаимодействие в PHP

Anna | 31.05.2014 | нет комментариев

Целью данной заметки является ознакомление PHP-разработчиков с вероятностями межпроцессного взаимодействия в данном языке. Заметка не полагает во всех деталях рассказать о всякой из вероятностей, деталях реализации либо показать рабочие примеры кода.

От того что задача распараллеливания рано либо поздно возникает у всякого программиста, то данная заметка была задумана отправной точкой, с которой дозволено начать своё путешествие в мир интересногогеморроя процесса построения таких систем.

Так же, будет задета тема многопоточности в PHP, причём, именно потоков (Thread), так как до недавнего времени, PHP разрешал (комфортно) реализовать какое либо распараллеливание лишь вследствие Fork (не будем касаться извращений типа curl_multi_*, popenfsockopen, Apache MPM и т.п.). Тема будет рассмотрена лишь в контексте IPC, поиск деталей реализации того либо другого подхода оставляю читателям.

Повествование будет вестись в разрезе ПО, работающего на одном компьютере, и IPC в рамках одной ЭВМ. Это связано с тем, что межпроцессное взаимодействие в распределённых системах — это крайне и крайне обширная тема. Потому, не будут рассматриваться всяческие брокеры сообщений, базы данных, PubSub, и прочие “межкомпьютерные” подходы, к тому же, они освещены на других источниках в Сети.

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

What does IPC look like?

Выходит, что же такое межпроцессное взаимодействие?

Межпроцессное взаимодействие — (англ. Inter-Process Communication, IPC) — комплект методов обмена данными между большинством потоков в одном либо больше процессах. Процессы могут быть запущены на одном либо больше компьютерах, связанных между собой сетью. IPC-методы делятся на способы обмена сообщениями, синхронизации, разделяемой памяти и удаленных вызовов (RPC). Способы IPC зависят от пропускной способности и задержки взаимодействия между потоками и типа передаваемых данных.

 

Describe like IPC looks like!

План конспекта дальнейший:

0. PCNTL
1. Sockets
2. Shared Memory
3. Semaphore, Shared Memory and IPC
4. pthreads

0. PCNTL

Растяжение реализует самый базовый функционал по работе с процессами, но нас волнует работа ссигналами UNIX, а определеннее — функция pcntl_signal, которая разрешает установить обработчик сигналов. Данный подход самый малофункциональный из всех рассматриваемых, так как он не разрешает передавать данные. С поддержкой этого растяжения дозволено, скажем, организовать стартстоп воркеров, либо считывание задач из буфера (файл, БД, память, etc.), либо сигнализацию одной части системы иной о каком то событии.

Особенно легко реализуема, есть уйма примеров, и вероятностей в использовании, Зачастую может больше чем хватить для каких то не крепко трудных задач.

1. Sockets

 

Сокеты — (англ. socket — разъём) — наименование программного интерфейса для обеспечения обмена данными между процессами. Процессы при таком обмене могут исполняться как на одной ЭВМ, так и на разных ЭВМ, связанных между собой сетью. Сокет — отвлеченный объект, представляющий финальную точку соединения.

Следует различать клиентские и серверные сокеты. Клиентские сокеты дерзко дозволено сравнить с оконечными агрегатами телефонной сети, а серверные — с коммутаторами. Клиентское приложение (скажем, браузер) использует только клиентские сокеты, а серверное (скажем, веб-сервер, которому браузер посылает запросы) — как клиентские, так и серверные сокеты.

Вероятно, это самый явственный и особенно знаменитый метод реализации IPC, впрочем, и самый трудозатратный. 1-й вариант — это сделать брокер (сокет-сервер), заказчиками-потоками коннектиться к нему. Здесь вас ждёт интересный мир отладки неблокирующего вводавывода (а как вы хотели — писать блокирующий код?), а так же реализация многих банальных пророческой типа обёрток над функциями растяжения. 2-й вариант проще, его дозволено использовать для больше примитивных реализаций:create_socket_pair, которая создаёт пару связанных сокетов, пример доступен по ссылке.

Применение сокетов для реализации IPC требует достаточно серьёзного подхода и раскуривания мануалов, но к плюсам дозволено отнести вероятность в грядущем разнести элементы системы на разные сервера, не прибегая к значительным правкам кода. Так же, плюсом данной спецтехнологии является её универсальность: скажем, написать заказчик на PHP, соединяющийся с C-шным сервером не трудно.

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

2. Shared Memory

Данное растяжение разрешает полновесно трудиться с виртуальной памятью. Плюсы подхода в том, что он является особенно стремительным (если быстродействие поставлено во главу угла приложения) и наименее ресурсозатратным. К тому же, его реализация не сопряжена с таким числом подводных камней, как в предыдущем решении, да и сама спецтехнология не является трудноусваиваемой.

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

Данный подход является, вероятно, особенно распостранённым и предпочтительным, так как не требует крупных трудозатрат в реализации, и является больше универсальным.

3. Semaphore, Shared Memory and IPC

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

Семафоры могут сгодиться, когда потоки будут обязаны трудиться с каким то всеобщим источником, скажем, вы написали файрволл, тот, что будет при всяком запросе лезет в файлик с IP-адресами Роскомнадзора и делает с входящим запросом уличную магию. Файлик, внятное дело, обновляется каким то иным сервисным потоком, потому, неприемлемо его чтение (либо метаморфоза), пока идёт процесс обновления, кем либо ещё. Теория работы семафоров примитивна, и примеров их реализации так же существует уйма, потому, для тех, кто ещё не работал с этим типом блокировок, рекомендую ознакомиться, это поможет отменнее понимать процессы построения взаимодействия между потоками.

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

4. Pthreads

И вот мы достигли segfault’а вершины эволюции как IPC, так и многопоточности в PHP.

Изумительный дядька по имени Joe Watkins написал растяжение pthread, которое добавляет в PHP поддержку самой настоящей многопоточности. Дословно на днях (8.09.2013) вышла первая stable-версия (0.0.45), впрочем, автор в своём посте на Reddit крайне детально раскрыл тему betastable релизов, потому, не заостряйте на этом внимание. Настойчиво рекомендую исследовать каждого его комментарии в теме, там много пригодной информации о pthread.

В чём же превосходства? Во всём. Pthreads предоставляет весьма легкой и комфортный API для реализации всяких ваших многопоточных фантазий. Здесь вам и synchronize как в джаве, и события, и IPC с пробросом объктов! С ними, правда, не всё так гладко (см. примеры на гитхабе), и автор пишет, что эта задача — не его рук дело, впрочем, с источниками сокетов ему всё же удалось сотрворить Диво, и сейчас, итогиsocket_accept из основного потока дозволено всунуть в дочерний — удивительно! Довольно разобрать примеры, Дабы осознать, насколько всё легко и изящно сделано.

Описывать все вероятности и прелести этого растяжения не буду, всё есть на гитхабе автора и вдокументации на php.net
Судя по каждому, автор достаточно насыщенно работает над своим планом, потому, в грядущем у него может возникнуть ещё много увлекательных вероятностей, stay tuned.

Для запуска растяжения нужно собрать PHP в Thread-safe режиме, вот маленький скрипт, тот, что сделает всё за вас:

При необходимости доработать напильником

mkdir /opt/php-ts && 
cd /opt/php-ts && 
wget http://www.php.net/get/php-5.5.3.tar.bz2/from/ua1.php.net/mirror -O php-5.5.3.tar.bz2 && 
tar -xf php-5.5.3.tar.bz2 && 
cd php-5.5.3/ext && 
git clone https://github.com/krakjoe/pthreads.git && 
cd ../ && 
./buildconf --force && 
./configure --disable-all --enable-pthreads --enable-maintainer-zts && 
make && 
TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php ext/pthreads  && 
alias php-ts="/opt/php-ts/php-5.5.3/sapi/cli/php"

 

Does he look like a Pipe?

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

P.S. Непринужденно к теме статьи это не относится, но дюже даже применимо к некоторым описанным тут моментам, а именно, блокировании IO и несовершенстве событийной модели: рекомендую ознакомиться с растяжениями Eio и Ev (автор обеих osmanov).

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB