Последние сообщения

Важны не статьи, а контент. Если вы можете дать такое же разнообразие предложение, как авито, то действительно, можно и без статей успешно продвигаться.

Т.е. если у вас трастовая доска объявлений, то да, грамотной структурой, перелинковкой, мета-тэгами можно добиться хороших результатов без применения статей.

Тут все просто, хранить удаленные объявления некоторое время, а новые добавлять только если их нет среди недавно удаленных, в DST Board тем более есть 2 типа удаления, удаление в корзину, это как бы идет в системе в архив и другое безвозвратное, так что немного доработки и проблема решена 

Единственное что сейчас есть, это у drom.ru проверка фотографий. Невозможно одну и туже фотографию загрузить дважды (ну по крайней мере чисто теоретически для рядовых пользователей(смена имени или расширения файла не помогут)). Выход это не полное удаление объявлений, а помещение их в архив. Также необходима привязка аккаунтов к телефонам и ящикам. 1 телефон — 1 юзер. При добавлении проверяем не подавал ли ранее пользователь похожее объявление, если нет то продолжаем, если да то предлагаем ему воспользоваться платными услугами 

Хранить удаленные сообщения в БД со статусом «deleted», перед добавлением нового объявления проверять на совпадения «deleted». Через определенное время можно/нужно собирать и выпиливать этот мусор из БД.

Выбор хостинга для парсера — задача, требующая особого внимания к техническим характеристикам. Оптимальным решением будет выделенный сервер или качественный VPS, где нет ограничений на время работы скриптов. При выборе обратите внимание на следующие параметры:

— Наличие root-доступа для настройки окружения

— Достаточный объем RAM для обработки данных

— Стабильное сетевое подключение

— Возможность масштабирования ресурсов при необходимости

Многие хостинг-провайдеры предлагают специальные тарифы для подобных задач. Рекомендую также обратить внимание на облачные платформы, которые позволяют гибко настраивать ресурсы и легко масштабировать их при росте нагрузки. Важно заранее обсудить с провайдером условия использования — некоторые хостинги могут иметь негласные ограничения на интенсивный парсинг, поэтому лучше прояснить этот момент до покупки.

При выборе хостинга для парсера объявлений важно учитывать несколько ключевых факторов. Прежде всего, обратите внимание на ограничения по времени выполнения скриптов — для парсинга Авито вам потребуется хостинг без жестких лимитов или с возможностью их увеличения. Рекомендую рассмотреть VPS/VDS-хостинг, так как он дает полный контроль над сервером и позволяет настроить все необходимые параметры.

Обязательно проверьте наличие SSH-доступа и возможности установки дополнительных библиотек, так как парсер может требовать специфического программного обеспечения. Для периодического запуска по расписанию отлично подойдет cron-планировщик, который есть практически на всех серьезных хостингах. Также обратите внимание на полосу пропускания — парсинг может генерировать значительный трафик, поэтому выбирайте тариф с достаточным объемом или безлимитом.

Лично мое мнение что выбор подходящего хостинга для парсера объявлений, особенно для такого ресурса как Авито, требует внимательного подхода. Вот ключевые факторы и рекомендации:

1. Требования к ресурсам:

— Процессор (CPU): Парсинг Авито может быть ресурсоемким, особенно если вы парсите большое количество страниц или используете сложные алгоритмы. Начните с виртуального сервера (VPS) с 2-4 ядрами CPU. Если парсинг занимает слишком много времени, увеличьте количество ядер.

— Оперативная память (RAM): Парсеру потребуется достаточно памяти для хранения данных, обработки HTML и выполнения скриптов. Рекомендуется начать с 4-8 ГБ RAM. Если видите, что парсер использует всю память, увеличьте ее.

— Дисковое пространство: Определите, сколько данных вы планируете хранить. SSD-диски предпочтительнее для скорости. Начните с 50-100 ГБ и масштабируйте при необходимости.

— Трафик: Парсинг Авито генерирует трафик. Убедитесь, что ваш хостинг-провайдер предоставляет достаточный объем трафика или предлагает безлимитный трафик.

2. Тип хостинга:

— Виртуальный сервер (VPS/VDS): Это наиболее подходящий вариант для парсера. Вы получаете выделенные ресурсы (CPU, RAM, дисковое пространство) и полный контроль над операционной системой. Это позволяет устанавливать необходимое программное обеспечение и настраивать окружение под ваши нужды.

— Выделенный сервер: Самый мощный вариант, но и самый дорогой. Подходит, если вам требуется максимальная производительность и полный контроль над оборудованием. В большинстве случаев для парсера Авито VPS будет достаточно.

— Облачный хостинг: Предоставляет гибкость и масштабируемость. Вы платите только за те ресурсы, которые используете. Хороший вариант, если нагрузка на парсер меняется со временем.

— Shared хостинг: Не рекомендуется. Обычно имеет ограничения на использование ресурсов, время выполнения скриптов и установку необходимого программного обеспечения. Парсер может быть заблокирован из-за высокой нагрузки.

3. Операционная система:

— Linux (Ubuntu, Debian, CentOS): Наиболее популярный выбор для веб-разработки и парсинга. Предоставляет широкий выбор инструментов и библиотек для работы с данными. Рекомендуется Ubuntu или Debian из-за их простоты использования и большого сообщества.

4. Язык программирования и библиотеки:

— Python: Один из самых популярных языков для парсинга. Имеет множество библиотек для работы с HTML (Beautiful Soup, lxml), HTTP-запросами (requests), и асинхронным программированием (asyncio, aiohttp).

— PHP: Также можно использовать, но Python обычно более предпочтителен для парсинга.

— Node.js: Подходит для асинхронного парсинга и обработки данных в реальном времени.

5. Возможность запуска по расписанию (Cron):

— Убедитесь, что хостинг-провайдер предоставляет доступ к Cron или аналогичному планировщику задач. Cron позволяет запускать скрипты автоматически по заданному расписанию. Это необходимо для периодического парсинга Авито.

6. Отсутствие ограничений на длительность выполнения скрипта:

— Это критически важно. Многие shared хостинги имеют ограничения на время выполнения скриптов (например, 30 секунд или 1 минута). 

С этой задачей почти любой хостинг справится. Задачу можно запускать по cron. Ограничения на использование ресурсов у хостера — это у него и надо уточнять. Много зависит от используемых ресурсов. Только так. Можете еще в ветке searchengines задать этот вопрос. Там много представителей хостеров тусуется. Может быть, что-то посоветуют и даже предложат. В идеале надо все уточнять у хостера (у одного может быть выставлено max_execution_time в 30 секунд, у другого — 600 и т. д.)

А еще можно настроить окружение прямо на компьютере заказчика.
А еще можно взять VPS.

Ну если взять основные решения диагностики то:

— Проблемы с CORS: Хотя вы используете CORS, убедитесь, что конфигурация на бэкенде абсолютно корректна. Неправильная настройка CORS может приводить к неожиданному поведению браузера, включая повторные запросы. Проверьте заголовки Access-Control-* в ответах сервера. Особенно обратите внимание на Access-Control-Allow-Origin, Access-Control-Allow-Methods, и Access-Control-Allow-Headers.

— Проблемы с Nginx: Редко, но возможно, что Nginx может дублировать запросы. Проверьте логи Nginx на наличие ошибок или предупреждений, связанных с этими запросами. Убедитесь, что в конфигурации Nginx нет никаких директив, которые могли бы вызывать повторную отправку запросов (например, proxy_next_upstream).

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

— Проблемы с Laravel: Убедитесь, что в вашем Laravel приложении нет middleware или других компонентов, которые могли бы вызывать повторную обработку запроса. Проверьте логи Laravel на наличие ошибок или предупреждений.

— Проблемы с планшетами/браузером: Хотя вы используете распространенную конфигурацию (Android 14 + Яндекс.Браузер), попробуйте воспроизвести проблему на других устройствах и браузерах, чтобы исключить специфические баги конкретной комбинации. Обновите Яндекс.Браузер до последней версии.

— Проблемы с Wi-Fi роутером: Проверьте настройки вашего Wi-Fi роутера. Убедитесь, что он работает стабильно и не имеет проблем с пропускной способностью или перегрузкой. Попробуйте использовать другой Wi-Fi роутер или подключиться к сети через Ethernet, чтобы исключить проблемы с Wi-Fi.

— Логирование на клиенте: Добавьте более детальное логирование 

Да, браузер теоретически может дублировать POST запросы, хотя это и не является штатным поведением. Учитывая вашу ситуацию и проведенный анализ, вот более развернутый ответ и дополнительные варианты для рассмотрения:

Ваши варианты и их расширение:

1. Axios дублирует POST запрос: Хотя это маловероятно, полностью исключать нельзя. Даже без плагинов, в редких случаях могут возникать ошибки в самом Axios или в его взаимодействии с Vue.js. Однако, раз идентификаторы запросов на бэке одинаковые, это делает эту версию менее вероятной.

2. Браузер дублирует запрос из-за нестабильности сети: Это наиболее вероятная причина, особенно учитывая использование Wi-Fi на планшетах. Вот почему:

— Wi-Fi нестабильность: Wi-Fi соединения подвержены помехам и перебоям. В момент отправки POST запроса может произойти кратковременный разрыв соединения.

— Браузерные механизмы повторных попыток: Браузеры часто имеют встроенные механизмы для повторной отправки запросов, если они не получили подтверждение об успешной доставке в течение определенного времени. В условиях нестабильной сети, браузер может ошибочно решить, что первый запрос не был доставлен и повторить его.

— HTTP/2: Хотя HTTP/2 обычно повышает производительность, в некоторых случаях он может усложнить отладку проблем с сетью. Например, multiplexing может затруднить отслеживание отдельных запросов.

Понятно, а как можно использовать UUID для отслеживания запросов? 

Ирина Савельева

Для использования UUID (Universally Unique Identifier) для отслеживания запросов можно применить следующий подход:

Генерация UUID: создайте уникальный идентификатор для каждого запроса, используя алгоритм генерации UUID. Это обеспечит высокую вероятность уникальности идентификатора для каждого отдельного запроса.

Добавление UUID в запрос: включите сгенерированный UUID в данные запроса, чтобы он передавался на сервер вместе с остальными параметрами запроса.

Сохранение UUID на сервере: при получении запроса на сервере сохраняйте UUID вместе с другими данными запроса. Это позволит отслеживать и идентифицировать каждый запрос индивидуально.

Обработка дубликатов: если на сервер поступает запрос с уже существующим UUID, это может указывать на дублирование запроса. В таком случае можно принять решение о том, как обрабатывать такие ситуации, например, игнорировать повторные запросы или принимать их с определёнными условиями.

Использование UUID для корреляции: UUID также можно использовать в качестве «Correlation ID» для отслеживания жизненного цикла запроса через различные сервисы и системы. Это поможет связать логи и события, относящиеся к одному запросу, даже если они обрабатываются разными компонентами системы.

Понятно, а как можно использовать UUID для отслеживания запросов? 

Похожая ситуация и у нас, а как можно решить проблему с дублированием запросов в браузере? 

Ирина Савельева

Для решения проблемы с дублированием запросов в браузере можно предпринять следующие шаги:

Используйте уникальный идентификатор: добавьте уникальный идентификатор в запрос, чтобы убедиться, что проблема не связана с дублированием из-за нестабильности сети или других факторов.

Проверьте код на наличие ошибок: убедитесь, что код не содержит ошибок, которые могут привести к дублированию запросов. Например, проверьте, не вызываются ли запросы в lifecycle-хуках или в watch.

Используйте плагин Vuejs devtools: если есть возможность запустить фронтенд на локалке в development environment, установите в браузер плагин Vuejs devtools и посмотрите поведение компонента, кидающего запросы.

Проверьте вкладку Network в devtools браузера: откройте devtools браузера и на вкладке Network кликните ссылку в колонке Initiator у повторяющихся запросов. Если будут показаны разные участки кода, значит, где-то ещё в коде затерялся такой же запрос.

Добавьте console.log перед вызовом запроса: прямо перед строчкой с вызовом запроса axios (прямо перед запросом, в этой же функции, не где-то вне её, а прямо в предыдущей строчке) напишите банальный console.log(«Gotcha!!!!»). Если сообщение в консоли браузера появится дважды, значит, проблема исключительно в логике вашей программы.

Сгенерируйте UUID для уникальных идентификаторов: если ваш ID действительно генерируется прямо рядом с вызовом запроса, прямо в той же самой функции, и это действительно подлый Chromium повторяет запросы из-за крайне нестабильного коннекта у пользователя, то тогда генерируйте ID не просто рандомом, который всё же может повториться, а сгенерируйте нормальный UUID. При приходе запроса сохраняйте этот UUID на короткое время где вам удобнее, и если придёт такой же запрос с таким же UUID, то не обрабатывайте его.

Похожая ситуация и у нас, а как можно решить проблему с дублированием запросов в браузере? 

Такое обычно происходит, когда запрос кидается в lifecycle-хуках, которые могут сработать много раз (например, updated), либо в watch. И когда у вас что-то ошибочно повторно перерендерится, то может бахнуть второй запрос. Дабл-клик по кнопке, которую вы не выключаете сразу после первого клика также не исключается.

Насчёт идентификатора вашего ничего не могу сказать, потому что не вижу, где и как вы его генерируете.

Дебажить, дебажить, и ещё раз дебажить VUE.

1. Если есть возможность запустить фронтенд на локалке в development environment, установите в браузер плагин Vuejs devtools, и посмотрите поведение компонента, кидающего запросы, может быть там что-то увидите.

2. Откройте devtools браузера и на вкладке Network и кликните ссылку в колонке Initiator (не знаю, как по-русски, не пользуюсь русским в браузере) у этих повторяющихся запросов. Если будут показаны разные участки кода, значит, где-то еще в коде затерялся такой же запрос.

3. Самое простое: прямо перед строчкой с вызовом запроса axios (прямо перед запросом, в этой же функции, не где-то вне её, а прямо в предыдущей строчке) напишите банальный console.log(«Gotcha!!!!»). Если сообщение в консоли браузера появится дважды, значит, проблема исключительно в логике вашей программы.

4. Если ваш ID действительно генерируется прямо рядом с вызовом запроса, прямо в той же самой функции (что исключает баг с тем, что в запрос подставляется где-то сохранённый и кэшированный фреймворком ID), и это действительно подлый Chromium повторяет запросы из-за крайне нестабильного коннекта у пользователя, то тогда генерируйте ID не просто рандомом, который всё же может повториться, а сгенерируйте нормальный UUID, вероятность повторения которого ЗНАЧИТЕЛЬНО ниже. При приходе запроса сохраняете этот UUID на короткое время где вам удобнее, и если придёт такой же запрос с таким же UUID, то не обрабатываете его. Этот же UUID вам может помочь и в других аспектах: например, вы можете его использовать как «Correlation ID» данного конкретного запроса. Его можно отражать в логах, передавать в другие сервисы, если у вас их несколько. И тогда вы сможете без проблем отслеживать жизненный цикл каждого конкретного запроса.