[PYTHON] Aucune raison de penser en écrivant un robot avec Django et Celery

Je vois souvent des robots dans mon travail, mais cette fois, j'utiliserai Django + Celery pour le moment si je crée un nouveau robot, alors j'essaierai d'écrire un échantillon et d'écrire ce que j'ai pensé en écrivant un échantillon.

Étape de traitement de base du robot d'exploration

Même s'il s'agit d'un robot d'exploration, on parle souvent dans un état où la définition est légèrement différente selon la personne, donc pour le moment, l'objectif de ce temps est

--Recueillir les liens de page Web selon certaines conditions

• Gratter le contenu de la page dans chaque lien
• Le traitement après grattage est exclu cette fois.

Je vais parler sur place.

Configuration de cet exemple

y-matsuwitter/django_sample_crawler

C'est la structure pour écrire l'échantillon,

• Python 3.4.3
• Django 1.9
• Celery 3.1.19
• lxml 3.5.0
• requests 2.8.1

J'ai créé celui qui implémente ce qui suit en utilisant.

• Peut être mis à l'échelle sur plusieurs serveurs --Explorer le référentiel de tendances sur github
• Les conditions d'exploration peuvent être ajoutées plus tard
• N'accédez pas à Github à un certain rythme ――Facile à réessayer

Exécution distribuée de chaque processus par Celery

Si le robot d'exploration est utilisé pendant une longue période, seule une partie du traitement du robot peut devenir gonflé et lent. Par exemple, le processeur est presque épuisé dans la section d'extraction de contenu. À ce stade, il est nécessaire de prendre des mesures telles que séparer uniquement ce processus, mais je pense qu'il est nécessaire de se mettre sur le système MessageQueue dès le début pour simplifier une telle opération distribuée. Cette fois, le céleri est utilisé pour traiter cette couche. En tant que processus interne d'acquisition des tendances github cette fois,

Il est exécuté dans l'ordre de. Chaque processus est traité comme une tâche de céleri distincte, et si vous ajustez les paramètres de travail, vous pouvez attribuer un cluster de serveurs différent pour chaque processus. À propos, c'est une grande division pour le robot d'exploration approprié cette fois, mais en spécifiant chaque processus séparément en tant que tâche, il sera plus facile de gérer les nouvelles tentatives lorsqu'une certaine tâche échoue. Par exemple, si vous téléchargez la page de tendances mais qu'elle s'arrête en raison d'une faille dans les règles au stade de l'analyse, vous pouvez récupérer en modifiant uniquement la tâche cible et en exécutant à nouveau uniquement cette tâche, et la tâche est bloquée sur cette couche. Même si vous le faites, vous pouvez facilement ajouter des ressources à cette couche.

Alternative à Cron par tâche périodique

Celery a un mécanisme appelé tâche périodique, et vous pouvez également spécifier la tâche à exécuter périodiquement en tant que tâche_périodique. Cette fois, la partie qui gère le robot d'exploration de chaque règle, qui est la plus basique, est spécifiée par planification.

from celery.schedules import crontab


CELERYBEAT_SCHEDULE = {
    'run_all_crawler_schedule': {
        'task': 'crawler.tasks.run_all_crawler',
        'schedule': crontab(minute='*/2'),
    },
}

Au fait, le fait qu'il soit exécuté toutes les deux minutes est juste écrit correctement dans le débogage, donc si vous voulez vraiment le faire fonctionner, il y aura un peu plus d'espace.

rate_limit Lors du scraping d'un site en détail, le processus d'acquisition html peut mettre une charge sur le site cible. céleri a un mécanisme appelé rate_limit, qui vous permet de spécifier à quelle fréquence exécuter chaque tâche.

@celery_app.task(rate_limit="60/m")
def fetch_trending(crawler_id):
    pass

Dans ce qui précède, vous pouvez restreindre l'opération afin qu'elle ne fonctionne pas plus de 60 fois par minute.

Avantages de la combinaison avec Django

Le céleri suffit à lui seul pour créer un robot d'exploration normal, mais en fonctionnement à long terme, l'ajout de règles et de sites augmentera régulièrement.Ainsi, tout en ajoutant de telles règles à la base de données, la situation peut être affichée sur l'écran de gestion côté Web. La combinaison avec Django sera pratique si vous considérez des choses telles que la vérification. Cette fois, c'est si simple que les règles du robot d'exploration sont similaires aux règles d'acquisition des tendances, mais vous pouvez définir ces informations dans django admin.

Lors de l'ajout de règles plus tard, peut-être que le plus gros problème concerne les règles de scraping, qui, je pense, peuvent être résolues en sauvegardant le sélecteur xpath ou css en règle générale. Vous voudrez peut-être vous référer au mécanisme de Scrapy.

finalement

Je pense que je n'ai pas beaucoup de connaissances sur Internet pour faire fonctionner un robot d'exploration à relativement grande échelle, alors j'aimerais avoir une session d'étude pour partager les connaissances dans ce domaine.