Синхронизация публикаций на связанных сайтах в Drupal

Краткая предыстория. Задача в общем виде ставилась так: есть каталог продукции на неком головном сайте и ряд шаблонных статей,  которые (и те и другие) являются материалом для наполнения сайтов-сателлитов. На этапе развертывания сайта-сателлита (спутника) необходимо импортировать какую то ветку товарного каталога с головного сайта, а также импортировать ряд шаблонных статей как основу разделов сайта-спутника. После развертывания сайта-спутника желательно, чтобы изменения в товарном каталоге на головном сайте транслировались и на сайт-спутник, где есть соответствующие импортированные статьи, т.е. нужна своеобразная синхронизация публикаций.

Частный случай. Конкретная реализация этой связки (головной сайт и сайт-спутник) уже практически завершена (остались штрихи по дизайну и наполнению, но это уже не моя забота :) ), это пара сайтов suet-co.ru и suet-motor.ru. Suet-motor.ru содержит ветку товарного каталога по моторам с головного сайта. Цель suet-motor — в привлечении покупателей по тематике «моторы». Он должен содержать несколько статей, посвященных данной тематике и каталог, ссылки из которого ведут на конечные позиции товаров на головном сайте. Там мы можем подробно изучить характеристики найденных на suet-motor товаров и заказать их.

Техника синхронизации.

Обмен данными. Первый вопрос в том как же обмениваться данными между сайтами, оставаясь в рамках движка drupal. Мне пришла идея воспользоваться техникой, которая применяется в drupal в случае ajax запросов. Для каждой стороны был написан модуль, в которых в объявляется hook_menu — зацепка для меню с элементами типа MENU_CALLBACK :

Т.е. создаётся специальная страница, которой можно передавать параметры, а в ответ получать какой то массив данных, обработанный, к примеру, serialize(). Параметры можно передавать, как часть url. Вот как было это сделано у меня. Специальная функция генерировала url из имени команды и массива параметров —

А принимающая сторона, реализующая страницу типа MENU_CALLBACK, обрабатывала запрос следующим образом :

Отложенное выполнение. Давайте посмотрим в какой момент лучше всего производить синхронизацию данных. Так как событие изменения статьи можно перехватить (в hook_form_alter добавляем обработчик $form[#submit] для формы нужного типа публикации ), то это наиболее удобный момент для синхронизации. Но это только на первый взгляд.

Когда мы меняем статью в каталоге на головном сайте, надо изменить её и на сайтах-спутниках. Для этого спутники надо каким то образом оповестить (выполнить запрос ко всем спутникам из какого-то известного списка). При этом можно либо помнить, кто из спутников запрашивал определенные статьи, а можно оповещать все спутники, и они сами должны решать — нужно ли запрашивать изменившуюся статью или нет.

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

Эти рассуждения привели меня к следующему решению. При сохранении статей на головном сайте, я добавляю запись в специальную очередь-таблицу обновлений с помощью  sql-команды replace. Записи имеют код статьи (node-id или nid) в качестве ключа, и потому новая команда для каждой ноды не добавляет строк. А сама команда может быть или delete или insert соответственно для удаления статьи и обновления/добавления.

После того как команда попадает в очередь, она там хранится до вызова cron. Обработчик (hook_cron) в моём модуле грузит весь текущий список команд и оповещает сайты-спутники. Те в свою очередь не бросаются сразу выполнять запросы на обновление статей, а тоже складывают команды, прошедшие проверку в уже собственные очереди команд. И, как вы уже поняли, очереди команд на спутниках выполняются также во время уже собственной зацепки hook_cron. Лучше запуски cron для спутников и головного сайта разнести по времени, чтобы они не накладывались.

Написать комментарий

Мало букафф? Читайте есчо !

Увеличить timeout в Mocha

Январь 5, 2023 г.

Тайм-аут, установленный в мокке по умолчанию равен 2сек, чего вполне достаточно для большинства тестов. Если вам не хватает, то используйте при вызове дополнительный параметр --timeout, время задаётся в мс, например, 10 секунд: [crayon-6758dc86d6043494793604/] ...

Читать

Проверка конфигурации nginx

Апрель 16, 2018 г.

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

Читать

 

Комментарии к «Синхронизация публикаций на связанных сайтах в Drupal»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: