«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2018/10/02 12:41:20  №1273389 1
>>1255400

> Аноны, что делать, если я хочу свои говноподелия просматривать с мобилки/планшета, но именно через локальный сервер?

Проще всего на компьютере в конфиге сервера поставить привязку (bind) к адресу 0.0.0.0 - это значит "слушать на всех сетевых интерфейсах" (там может стоять 127.0.0.1 - слушать только на loopback-интерфейсе, к которому нельзя подключиться снаружи). После этого посмотреть IP компьютера и зайти на него с телефона (http://192.168.x.y/).

>>1253706

> Добрый вечер, такой вопрос по системам очередей (MQ). К примеру у меня есть определенные данные которые мне в любом случае надо обработать и ни в коем случае нельзя их потерять. На данный момент я вижу, что MQ тут реально был бы кстати, но встает следующий вопрос - нормальный ли подход если я организую работу в следующем ключе:
> 1. Создаем задачу с данными
> 2. Первый Consumer создает запись в БД и Продюсит следующую задачу с обработкой
> 3. Второй Consumer обрабатывает данные и Продюсит следующую задачу
> 4. Третий Consumer получает обработанные данные и создает ещё одну задачу
> 5. Четвертый Consumer делает реквест с отправкой данных конечному адресату

> Или можно как-то по другому всё сделать? Нельзя чтобы на каком нибудь из этапов потерялись данные.
> Ещё думаю над таким вариантом
> 1. Получаем данные и создаем тут же запись в БД (молимся чтобы БД была доступна, сеть работала и запись создалась успешно), тут же создаем задачу в RabbitMQ
> 2. Первый Consumer Обрабатывает данные и продюсит следующую задачу
> 3. Получаем данные вторым Consumer, обновляем БД (снова молимся) и отправляем данные конечному получателю

> ОП и другие небезразличные помогайте

Первый вопрос, который возникает: если для выполнения задачи надо сделать несколько действий, что мешает сделать их в одном скрипте? То есть берем задачу, делаем все нужные обработки и сохраняем результаты. Зачем разбивать это на части?

А в общем тут есть 2 подхода: хранить задачу в MQ либо хранить задачу в БД, а MQ использовать для уведомления воркера о ее появлении. Подход с БД имеет тот плюс, что ты всегда можешь увидеть список и статус задач.

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

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

Что касается надежности, надо смотреть на конкретную очередь - некоторые предоставляют гарантии сохранности данных.