Какой яп лучше подойдет для метапоисковой системы?

Question

[Сергей]

Хочу попробовать сделать метапоиск, что-то вроде aviasales. Неплохо знаю php, но почему-то, кажется, что он для этих целей не очень подойдет. Причины:

• Такой поиск подразумевает одновременный опрос большого количества партнеров, а php в асинхронность, либо многопоточность не очень может.
  
• Как я понимаю, после начала поиска скрипт отдает http 200 и уходит опрашивать партнеров в фон, потом кладет в какое-нибудь хранилище результаты и другой скрипт оттуда вытаскивает эти результаты. Соответственно, если будет искать одновременно много человек, то в памяти будут плодиться php процессы, которые живут дольше запроса и это может довольно быстро положить сервер.
  

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

Comments

[Vitsliputsli]

php в асинхронность, либо многопоточность не очень может.

А что там не очень, отдельно с тем и другим?

[Сергей]

Vitsliputsli, Асинхронности там в принципе нет. Многопоточность возможна с помощью pthread расширения, но для распараллеливания опроса api партнеров, возможно, это не очень эффективно будет.

[Vitsliputsli]

Сергей, асинхронность есть, ReactPHP неплохая библиотека. Потоки сами уже написали, что есть, до рабочего состояния их довели уже несколько лет назад. То что параллелизм предпочитают реализовывать процессно зачастую связано с тем, что это в разы проще. Распараллелить "опрос api партнёров" можно и встроенной асинхронной функцией.
Не теоретизируя, есть практические сложности? Решали задачу, но из-за проблем в языке не смогли решить и пришлось менять язык?

Answer 1

[d-sem]

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

Поэтому выход в архитектуре. Асинхронность реализуется через очереди, а снижение нагрузки через кеширование.

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

Пример:
1. Точка API где собираются результаты паралельных запросов - Node.js с промисами которые работают с очередями для общения с п.2 и п.3, при необходимости в будущем переписать на golang, если будет тормозить;
2. Точки где не нужны высокие нагрузки и много логики - php, python, любой язык который хорошо знаете. Если будет что-то становиться узким местом - переписывать компилирируемое и оптимизировать;
3. Где высокая нагрузка - что-то компилируемое вроде golang.

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