Параллельное / асинхронное переполнение стека

Question

Параллельное / асинхронное переполнение стека

Передо мной была поставлена задача перестроить приложение (CakePHP 2.0, php 5.6), которое получает запрос, переформатирует / сопоставляет тело с полями, специфичными для API, и выполняет запросы к нескольким API с новым сопоставленным телом.

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

В настоящее время процесс декодирования (сопоставления из определенных полей API) происходит последовательно, как только возвращаются запросы Multicurl.

Моя идея состоит в том, чтобы обрабатывать ответы и как только они приходят, и я пытаюсь сделать это параллельно.

Одна сложность состоит в том, что каждому целевому API нужны 4 очень специфические функции отображения, поэтому у каждого объекта API есть карта и обратная карта для 2 различных операций.

Требование клиента состоит в том, чтобы иметь минимальное количество зависимостей, решение должно быть предпочтительно в сыром php, библиотеки не нужны.
Решение KISS было запрошено.

Я рассмотрел следующие подходы, но все они имеют недостатки.

Multicurl ждет самого медленного ответа, чтобы вернуть все ответы. Это текущий подход, без параллельной обработки ответов.
pthreads не совместим с Apache, только для командной строки.
Не может легко передавать сложные объекты (объект API) через сокеты.
Слишком много зависимостей и / или слишком незрелых.
а) Appserver
б) Кракен
в) RabbitMQ
d) socket.io

Я ищу PHP 7 (ничего больше) альтернативы этой задаче.

Какие-либо предложения?

0

asynchronous concurrency php

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Стоит отметить, что «параллельный» и «асинхронный» являются отдельными понятиями.

Например: ReactPHP и его аналог [node.js Включено] являются асинхронными, но все еще однопоточными, полагаясь на циклы событий, обратные вызовы и сопрограммы, чтобы разрешить выполнение кода вне порядка.

Отвечая на вашу оценку подходов:

Точная оценка curl_multi(),
- Тем не менее, ваш заявленный случай заключается в том, что все это должно происходить в контексте одного запроса, поэтому независимо от того, что вы делаете, вы застрянете в ожидании самого медленного ответа API, прежде чем сможете обслуживать ваш ответ.
- Если вы принципиально не меняете свой рабочий процесс, вам, вероятно, следует просто придерживаться этого.
Это не то pthreads несовместим с Apache, это то, что он несовместим с mod_php,
- Используйте использовать рабочую модель FCGI, как FPM и вы можете использовать pthreads все, что вы хотите.
Почему бы и нет? Для этого и нужна сериализация.
- Пока ты никогда принять его от пользователей или использовать вне PHP, serialize() это один из вариантов.
- Почти во всех других случаях json_encode() будет путь, чтобы пойти.
Если вы просто собираетесь списывать оптовые решения, подобные этим, у вас будут плохие времена, особенно если вы пытаетесь сделать что-то, что по своей сути противоречит PHP, например параллельную / асинхронную обработку.

1