[simpleQueue] Простая очередь сообщений для других компонентов
После подготовки статей решил довести до ума удобный компонент, который изначально был задуман как публичный и создан для нужд АСУ. Удобен, чтобы в каждом из компонентов, где требуется очередь, не реализовывать одно и то же.
Простая очередь сообщений для использования в любых сторонних компонентах.
Очередь сообщений удобно использовать в случаях, когда необходимо в одном потоке добавить сообщение о новом действии, а в другом потоке его выполнить.
Простой пример: отправка писем. В основном процессе добавляется сообщение о новом исходящем письме, а отдельным скриптом осуществляется отправка письма.
Использовать возможно как на уровне объектов, так и на уровне процессоров.
Стандартный вызов:
Сокращенный вызов:
Чтобы он стал возможен, необходимо однократно выполнить код (можно в Console):
Класс sqMessage
Класс sqLog
В комплекте с компонентом идут процессоры для сообщений:
Пример вызова процессора:
При использовании процессоров автоматически создаются записи лога sqLog, фиксирующие состояние сообщений после их сохранения.
Простая очередь сообщений для использования в любых сторонних компонентах.
Очередь сообщений удобно использовать в случаях, когда необходимо в одном потоке добавить сообщение о новом действии, а в другом потоке его выполнить.
Простой пример: отправка писем. В основном процессе добавляется сообщение о новом исходящем письме, а отдельным скриптом осуществляется отправка письма.
Использовать возможно как на уровне объектов, так и на уровне процессоров.
Подключение сервиса
Стандартный вызов:
sq = $this->modx->getService(
'simplequeue',
'simpleQueue',
$this->modx->getOption('simplequeue_core_path', null, $this->modx->getOption('core_path') . 'components/simplequeue/') . 'model/simplequeue/',
array()
);
Сокращенный вызов:
$sq = $modx->getService('simplequeue');
Чтобы он стал возможен, необходимо однократно выполнить код (можно в Console):
$modx->addExtensionPackage('simplequeue', '[[++core_path]]components/simplequeue/model/');
Объекты
Класс sqMessage
Поле | Назначение | Заполняется автоматически? | id | ID | Да | service | произвольное название сервиса, добавившего сообщение | Нет | action | произвольное название требуемого действия | Нет | subject | детали для выполнения действия. Например, ID обрабатываемого объекта | Нет | createdon | время создания, заполняется автоматически | Да | createdby | ID пользователя, создавшего сообщение | Да | processed | Флаг завершенности (bool) | Нет | status | Статус, устанавливаемый сервисом | Нет | properties | JSON массив с произвольными данными | Нет |
---|
Класс sqLog
Поле | Назначение | Заполняется автоматически? | id | ID | Да | message_id | ID измененного сообщения | Да | user_id | ID пользователя, изменившего сообщение | Да | timestamp | Штамп времени изменения | Да | operation | Произведенное действие | Да | entry | JSON массив с измененными полями и их значениями | Нет |
---|
Процессоры
В комплекте с компонентом идут процессоры для сообщений:
Процессор | Назначение | Принимаемые параметры | create | Создание | service, action, subject, properties | update | Обновление | id, status, properties | close | Завершение | id | open | Открытие | id | get | Получение | id | getlist | Получение списка | ids |
---|
Пример вызова процессора:
$response = $modx->runProcessor(
'message/update',
array('id' => 1, 'status' => '5'),
array('processors_path' => MODX_CORE_PATH . 'components/simplequeue/processors/');
);
При использовании процессоров автоматически создаются записи лога sqLog, фиксирующие состояние сообщений после их сохранения.
Комментарии: 10
Очень интересно!
Я активно использовал очереди Tickets для отправки и всех своих сообщений.
Я активно использовал очереди Tickets для отправки и всех своих сообщений.
Хороший вариант.
Однозначно в избранное.
Спасибо Михаил.
А как работает выполнение действий из очереди? по крону? или что то вроде постоянного запуска через sleep?
Как вообще правильнее всего подобные вещи делать?
Спасибо Михаил.
А как работает выполнение действий из очереди? по крону? или что то вроде постоянного запуска через sleep?
Как вообще правильнее всего подобные вещи делать?
Это уже выходит за пределы данного компонента. Он хранит очередь и отдает сообщения из нее желающим. Если будет необходимость, можно добавить выполнение системных команд с передачей им параметров из сообщений, но это отдельная песня. В любом случае, на текущий момент считаю правильным реализовывать свою логику получения и обработки сообщений из очереди в соответствии с задачей.
Хм. Давай разбираться, я пока не очень понимаю.
Задача — сделать рассылку тысяче клиентов о подходящей им заявке с сайта.
Я могу напрямую перебрать подходящих пользователей и отправить каждому сообщение через консоль. Это вызовет определенную нагрузку на сервер. Это я понимаю.
В чем польза очередей?
Я вместо отправки сообщений тысяче клиентов делаю тысячу записей в таблице очередей.
А что дальше?
Настроенный мною скрипт будет вызывать скажем по десять записей в минуту и отправлять письма? Нагрузка явно будет меньше. Я правильно понимаю суть компонента и его пользу? Только хранение очередей в заранее подготовленной таблице и упрощенное добавление\запрос из таблицы очередей?
Задача — сделать рассылку тысяче клиентов о подходящей им заявке с сайта.
Я могу напрямую перебрать подходящих пользователей и отправить каждому сообщение через консоль. Это вызовет определенную нагрузку на сервер. Это я понимаю.
В чем польза очередей?
Я вместо отправки сообщений тысяче клиентов делаю тысячу записей в таблице очередей.
А что дальше?
Настроенный мною скрипт будет вызывать скажем по десять записей в минуту и отправлять письма? Нагрузка явно будет меньше. Я правильно понимаю суть компонента и его пользу? Только хранение очередей в заранее подготовленной таблице и упрощенное добавление\запрос из таблицы очередей?
Расскажу мои впечатления от работы с очередями:
Например у меня на загруженном сайте при добавлении тикета с формы на фронте форма зависала почти на минуту. А в это время у меня в фоне в плагине просиходило куча действий + отправка различных писем разным людям.
Но как только я включил системную настройку tickets.mail_queue (ну и настроил крон на его выполнение) — время сохранения тикета сократилось вдвое.
После этого плагин на сохранение тикета переписал так, чтобы вместо отправки писем в момент публикации, данные письма сохранялись в базу в таблицу tickets_mail_queues — время сократилось до секунды!
Например у меня на загруженном сайте при добавлении тикета с формы на фронте форма зависала почти на минуту. А в это время у меня в фоне в плагине просиходило куча действий + отправка различных писем разным людям.
Но как только я включил системную настройку tickets.mail_queue (ну и настроил крон на его выполнение) — время сохранения тикета сократилось вдвое.
После этого плагин на сохранение тикета переписал так, чтобы вместо отправки писем в момент публикации, данные письма сохранялись в базу в таблицу tickets_mail_queues — время сократилось до секунды!
Абсолютно верно ты все понял и сформулировал суть компонента.
Добрый день
Может быть есть готовый код для ajaxform и минишопа?
А то когда из всех форм и заказы падают в АМОцрм, и врем отправки до секунд 10-12 доходит.
Может быть есть готовый код для ajaxform и минишопа?
А то когда из всех форм и заказы падают в АМОцрм, и врем отправки до секунд 10-12 доходит.
Если вы используете компонент amoCRM — то там уже встроена поддержка simpleQueue
Спасибо. Упустил момент :(
Немного пожив с включенным simpleQueue — почему-то дублируются заявки в AMO.
И ежедневно проскакивает ошибка 401 =/
1) Может быть связано с 401?
2) может ли помочь изменить CRON задачу с ежеминутного выполнения ~/www/core/components/amocrm/cron/secondlyrunner.php к примеру, на раз в 3 минуты?
Немного пожив с включенным simpleQueue — почему-то дублируются заявки в AMO.
И ежедневно проскакивает ошибка 401 =/
1) Может быть связано с 401?
2) может ли помочь изменить CRON задачу с ежеминутного выполнения ~/www/core/components/amocrm/cron/secondlyrunner.php к примеру, на раз в 3 минуты?
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.