Блог

Мне понадобились некоторые отзывы о веб-приложении на базе PHP / MySQL, которое я нахожусь в процессе разработки. Приложение представляет собой сайт на основе пользователей, который использует локальную базу данных для хранения данных для каждого пользователя по дням. Эти данные поступают из внешнего API и должны автоматически синхронизироваться ежедневно, чтобы в моей локальной базе данных были актуальные данные. Это методология, которую я имею в виду:

У меня есть 2 задания Cron:

1. Построитель очередей

2. Работник очереди

..и 3 таблицы базы данных:

1. Пользовательские данные (хранит все пользовательские данные, которые у меня есть на данный момент, если таковые имеются).

2. Сведения о пользователе (список всех участников, который включает пользователей, для которых у меня пока нет данных, иначе новых регистраций).

3. Очередь обработки

Построитель очередей — это PHP-скрипт, который будет запускаться через Cron через регулярные промежутки времени. Это будет:

• Сравните сведения о пользователе и таблицы пользовательских данных, чтобы определить, для каких новых пользователей у меня пока нет данных. Для этих пользователей он создаст список URL-адресов, начиная с 1/1/11 по сегодняшний день, и вставит их в таблицу Очереди обработки (это потому, что я хочу иметь данные с начала года для всех моих пользователей).

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

Таким образом, таблица очереди обработки будет содержать список всех URL-адресов, которые необходимо запросить.

Queue Worker также является скриптом PHP Cron, который будет:

• Выберите первые 20 элементов в таблице очереди обработки, получите их содержимое с помощью CURL multi, проверьте ошибки, а затем удалите первые 20 строк из таблицы. Я разбиваю его на 20 URL-адресов за раз, потому что, если я обработаю слишком много URL-адресов, скрипт может зависнуть, или мой хост может постучаться в мою дверь, вооруженный дробовиком.

Это также будет регулярно выполняться через задание Cron, поэтому идея заключается в том, что синхронизация данных должна быть автоматизирована, а пользователи должны иметь актуальные данные. Мои вопросы:

1. Каковы общие соображения по моей методологии? Есть ли какие-либо побочные эффекты при выполнении этого таким образом? Я разработчик-любитель без опыта работы в CS, поэтому всегда стремлюсь получить критику и узнать о лучших практиках! =)

2. Когда регистрируется новый пользователь, я планирую сообщить им «синхронизация ваших данных может занять xx минут», Перенаправляя их на ресурсы для начала работы и т.д. Вероятно, это нормально для моего первоначального выпуска, но в дальнейшем я хотел бы доработать его, чтобы пользователи получали уведомление по электронной почте о готовности синхронизации или могли видеть% прогресса. Легко ли мое текущее решение с этим справляется? Или у меня будут головные боли в дальнейшем?

Мнения приветствуются! Большое, БОЛЬШОЕ спасибо заранее — я надеюсь, что я это ясно объяснил!

Вероятно, лучший совет, который я могу вам дать, это: ПОЦЕЛУЙ!! Нет, я не преувеличиваю, это означает «Будь проще, глупый!» и, возможно, является очень важным инженерным принципом. Имея это в виду, первый вопрос, который я бы задал: «почему cron?» Возможно ли, чтобы все эти задачи выполнялись в режиме реального времени при регистрации пользователей? Если да, я бы посоветовал пока придерживаться этого и не заморачиваться с cron. Если вы решите использовать модуль cron, я бы порекомендовал следующее:

• Рассмотрите возможность использования файла блокировки, чтобы предотвратить одновременный запуск нескольких экземпляров вашего скрипта. Например, если вы запускаете скрипт каждые 5 минут, и каждый раз выполнение скрипта занимает 10 минут, то несколько экземпляров могут мешать друг другу.
• Использование curl multi, вероятно, создаст большую нагрузку на ваш целевой сервер, чем выполнение отдельных запросов в цикле, если вы хотите быть вежливым с целевым сервером, то, вероятно, лучше использовать одиночные запросы и иметь короткий спящий режим в цикле.
• Если вы обрабатываете только 20 заданий одновременно и ваш сервис очень популярен, вы можете столкнуться с постоянно расширяющейся рабочей очередью. Например, если вы получаете 40 задач в час и обрабатываете только 20 задач в час, вы никогда не дойдете до конца очереди, и очередь никогда не завершится.

HTH.