Комментарии 36
-module(my_server46).
Какой ужас…
Если честно, не понимаю, зачем для взаимодействия php и erlang нужен RabbitMQ? Что бы периодически что-то передавать в erlang достаточно post/socket запроса из php и ranch в erlang. Обмен можно сделать в json или MessagePack . Из вашего примера не понятно зачем вам каналы. Если же они всё-таки нужны, то можно рулить ими на уровне транспорта ranch передавая канал в качестве одного из параметров запроса. В общем, ИМХО, забивание гвоздей микроскопом…
В принципе вы правы, в одном из проектов я так и делал, из erlanga вызывал php и нормально все обменивалась, просто если более детально описывать задачу, там была проблема, что не хватало мощностей все обрабатывать на одном сервере, и для этого мне и понадобился RabbitMQ, чтобы разнести задачи на несколько серверов.
module(my_server46). — ну это да ужас, но вы же понимаете, что это код не с production версии, а просто для тестирования, написанный с нуля, чтобы быть уверенным, что все действительно будет работать + код production мне бы никто и не дал выложить.
module(my_server46). — ну это да ужас, но вы же понимаете, что это код не с production версии, а просто для тестирования, написанный с нуля, чтобы быть уверенным, что все действительно будет работать + код production мне бы никто и не дал выложить.
Эм, я как-то не очень понимаю при чём здесь RabbitMQ и масштабирование? Вы масштабируете RabbitMQ вместо своего приложения? Или у вас нет функционала управления очередями? Что мешает взять какой-нибудь готовый пул, например, разнести своё приложение на несколько серверов, и на каждом используя пул воркеров обрабатывать запросы? При этом работу с очередью возьмёт на себя сам пул.
Это да, просто у нас в компании мало erlang разработчиков, и некоторые обработчики очередей мы планировали реализовывать средствами Python или Java.
Вы даете неправильные и глупые советы. Что значит " Вы масштабируете RabbitMQ вместо своего приложения". Это вообще чушь!
Вы предлагаете сочинять свой пул воркеров..? Чем для этого не подошел RabbitMQ?
RabbitMQ — отличное средство для распределения задач между процессами и серверами. И не нужно изобретать свои поделки. А особенно не нужно писать в комментах призывы к их изобретению.
Автор правильно поступил, что взял готовое средство, а не потратил деньги заказчика и нервы того, кто будет дорабатывать проект.
Вы предлагаете сочинять свой пул воркеров..? Чем для этого не подошел RabbitMQ?
RabbitMQ — отличное средство для распределения задач между процессами и серверами. И не нужно изобретать свои поделки. А особенно не нужно писать в комментах призывы к их изобретению.
Автор правильно поступил, что взял готовое средство, а не потратил деньги заказчика и нервы того, кто будет дорабатывать проект.
Научитесь читать! В каком месте я предлагаю запилить свой пул? Из текста поста я могу сделать только один выводд — RabbitMQ для решения этой задачи избыточен! Для того чтобы послать сообщение из php в erlang RabbitMQ не нужен! В посте нет ни слова о том, что используется множество очередей, нет чёткого описания задачи, нет предпосылок к использованию RabbitMQ.
Честно говоря, не хотел грузить особенно описанием задачи, и последовательностью принятия тех или иных решений. Возможно в следующей статье буду использовать спойлер с максимально, на сколько это возможно, детальным описанием проекта в целом.
детальным описанием проекта в целом
Не совсем так. Детальное описание проекта не нужно. Нужно детальное описание задачи. Ведь ваше приложение решает определённую задачу. Достаточно было добавить картинку из коммента habrahabr.ru/post/251927/#comment_8309905 и всё было бы гораздо понятнее.
Вообще-то я ответил на Ваш комментарий, который относится не к самой статье, а к комментарию Alexc5c5c5, в котором он поясняет: «разнести задачи на несколько серверов».
Вы же в своем комментарии явно даете неправильные советы.
Вы же в своем комментарии явно даете неправильные советы.
Иллюзия… Я даю советы руководствуясь исключительно текстом поста и ветки комментариев. Если из текста и заголовка поста следует, что RabbitMQ используется исключительно для передачи сообщений между php и erlang, из-за того, что не справляется одна нода клиентского приложения на сервере, то это не повод ставить и настраивать RabbitMQ, а повод добавить ещё одну ноду и задуматься над производительностью всего приложения. Если же узким местом является стек сообщений каждого процесса, при этом каждое сообщение использует свой канал, то да, я согласен кролик частично снимет здесь проблему нагрузки, но тем не менее стоит задуматься над общей производительностью воркера.
RabbitMQ (или другие MQ) как минимум потому что в этом случае нет привязки к конкретной реализации воркеров. В итогде спустя время воркеры можно реализовать на rust/go в особо критичных местах. Так же есть возможность маршрутизировать по приоритетам задачи и т.д. Словом… зачем изобретать для этого всего свой велосипед?
Это да, просто у нас в компании мало erlang разработчиков, и некоторые обработчики очередей мы планировали реализовывать средствами Python или Java
С помощью RabbitMQ в свое время реализовывал связь между PHP, Python и NodeJS. Прелесть в том, что я могу разнести worker'ов по серверам и при необходимости переписать его, используя другой язык программирования. Все зависит от задач.
Gearman не рассматривали как один из вариантов?
Буквально мельком, особенно не тестировал, меня удивило, что для его нормальной работы нужно дополнительно mysql. Плюс ходят слухи, что он медленнее.
Насколько я помню MySQL является только одним из вариантов хранения очередей и только если вам нужна надежность. Gearman предоставляет чуть больше возможностей (скажем отложенные задачи, выполнение задач по рассписанию и т.д.) и посему просто хранить очередь в файле, как это делает кролик, не очень продуктивно. Ну а писать для этого свою СУБД возможно просто накладно.
Просто хранить очередь в файле, как это делает кролик, не очень продуктивно — могу ошибаться, но FIFO в примитивном описании работает, как запись в начало файла, считывание с конца и все. А СУБД, в частности Mysql -> InnoDB например в конечном итоге записывает все в один файл, но тут мы тратимся дополнительно на саму прослойку взаимосвязи с СУБД.
Gearman предоставляет чуть больше возможностей — это да, реализовывать отложенные задачи на RabbitMQ приходится, немного костыльным способом.
Gearman предоставляет чуть больше возможностей — это да, реализовывать отложенные задачи на RabbitMQ приходится, немного костыльным способом.
Просто хранить очередь в файле, как это делает кролик, не очень продуктивно — могу ошибаться, но FIFO в примитивном описании работает, как запись в начало файла, считывание с конца и все.Скажите это Apache Kafka, ага.
> хранить очередь в файле, как это делает кролик
RabbitMQ хранит очередь в Mnesia, а не в файле
RabbitMQ хранит очередь в Mnesia, а не в файле
«REST-функция на PHP», «приложение на erlange», ну ёшкин кот, невозможно же читать. По сути: так и не понятно, чего добивались и чего добились. Ну хорошо, для чего-то использовали erlang-приложение для обмена сообщениями, и?..
Ну да, его для этого создавали вообще-то, в основном php мне нужен был по той причине, что приложение клиентов добавляла задачи используя rest. Плюс я для обработки, а точнее для для распаривания html страниц, так как erlang не очень хорошо умеет работать с текстом, а там достаточно сложная модель. По сути обработчик или говорил все ок, пользователь нечего не поменял, отправляй меня в конец очереди, или изменились данные и нужно сделать ещё 5-10 запросов к источнику информации, чтобы определить изменившиеся данные, ну и уведомление пользователю заодно посылает.
Сама идея использование Rest, в будущем позволит изменить обработчик, сделать его более эффективным, написать на любом языке.
Сама идея использование Rest, в будущем позволит изменить обработчик, сделать его более эффективным, написать на любом языке.
В простейшем случае, это выглядит вот так
"
Плюс дополнительно есть например очереди удаления пользователей, обработка которой полностью проходит без участия php, и другие…
"Плюс дополнительно есть например очереди удаления пользователей, обработка которой полностью проходит без участия php, и другие…
Вы должны понимать, при такой архитектуре, я могу менять любой из этих модулей.
И один из бонусов, отказ 90% серверов с демонами Erlanga, повлияет в плане снижения скорости, но не более… RabbitMQ не дождется подтверждения, отправит задачи на другой сервер. Поверьте решения принимаются не просто так.
И один из бонусов, отказ 90% серверов с демонами Erlanga, повлияет в плане снижения скорости, но не более… RabbitMQ не дождется подтверждения, отправит задачи на другой сервер. Поверьте решения принимаются не просто так.
.
Интереса ради спрошу почему не написали консюмер на php?)
php есть у Вас в стеке технологий, amqp расширение уже стоит, для написания воркеров есть миллион туториалов, меня интересует кто и зачем принял это, на мой взгляд абсурдное, решение добавлять эрланг в стек технологий ради простейшей задачи, которую можно решить на php или любом другом языке из Вашего стека.
php есть у Вас в стеке технологий, amqp расширение уже стоит, для написания воркеров есть миллион туториалов, меня интересует кто и зачем принял это, на мой взгляд абсурдное, решение добавлять эрланг в стек технологий ради простейшей задачи, которую можно решить на php или любом другом языке из Вашего стека.
Была идея написать сначала на нем, чтоб вообще не париться, но через некоторое время, начинала течь память, да конечно оптимизировать и так далее, но все равно, php не очень хорошо для этого. Была статья habrahabr.ru/post/179399/, очень подробно расписывается данная проблема.
А вот почему Erlang, а не java например, вот это интересный вопрос :) Я конечно могу вам сказать, что в subscribe на Erlange сразу вызывается swapn для дальнейшей обработки, и таким образом скорость достаточно приличная получается…
Но в целом, вопрос религиозный, можно было и на чем то другом написать, ради разнообразия, да и сравнить консюмеры на разных языках, какой будет лучше справляться…
А вот почему Erlang, а не java например, вот это интересный вопрос :) Я конечно могу вам сказать, что в subscribe на Erlange сразу вызывается swapn для дальнейшей обработки, и таким образом скорость достаточно приличная получается…
Но в целом, вопрос религиозный, можно было и на чем то другом написать, ради разнообразия, да и сравнить консюмеры на разных языках, какой будет лучше справляться…
> После заходим в папочку deps, которую создал rebar и, используя git, все скачиваем
зачем же это делать самому, если есть
rebar get-deps
?
зачем же это делать самому, если есть
rebar get-deps
?
Далее возникли сложности с оставшимися библиотеками, поэтому пришлось использовать то, что написано на официальном сайте RabbitMQ
Как я понимаю вы предлагаете что-то типо вот этого
{deps, [
{rabbit_common, ".*", {git, "git://github.com/jbrisbin/rabbit_common.git", {tag, "rabbitmq-3.0.2"}}},
{rabbitmq_erlang_client, ".*", {git, "git://github.com/rabbitmq/rabbitmq-erlang-client.git", {tag, "rabbitmq_v3_0_2"}}},
{rabbitmq_server, ".*", {git, "git://github.com/rabbitmq/rabbitmq-server.git", {tag, "rabbitmq_v3_0_2"}}},
{rabbitmq_codegen, ".*", {git, "git://github.com/rabbitmq/rabbitmq-codegen.git", {tag, "rabbitmq_v3_0_2"}}}
]}.
Но это выдаст ошибку
Cloning into 'rabbitmq_erlang_client'…
ERROR: Dependency dir 1/deps/rabbitmq_erlang_client failed application validation with reason:
{missing_app_file,«1/deps/rabbitmq_erlang_client»}.
Как я понял на гите в папке src нет ни одного файла с расширением *.app.src. И собственно он конечно загрузит rabbit_common и даже rabbitmq_erlang_client, но далее не продвинется. И единственное решение, которое мне пришло это просто установить все, как написано в официальной инструкции www.rabbitmq.com/build-erlang-client.html. Если вы знаете, как это сделать через rebar, поделитесь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взаимодействие PHP и Erlang посредством RabbitMQ