Share
Ce que vous allez créerBien que l'API REST de Twitter convienne à de nombreuses applications, si vous souhaitez des mises à jour immédiates et un accès à un plus grand nombre de notifications, l'API Twitter Streaming est essentielle. Par exemple, seule l’API de diffusion en continu vous dira quand un autre utilisateur ajoute un de vos tweets.
L'utilisation de l'API Streaming nécessite une connexion persistante et continue entre votre serveur Web et Twitter. Ce type d'implémentation peut ne pas être familier à de nombreux développeurs PHP. Dès que les tweets arrivent, Twitter avertit votre serveur en temps réel, ce qui vous permet de les stocker dans votre base de données sans délai d'interrogation de l'API REST. L'utilisation de l'API Streaming n'est pas non plus soumise aux limites de taux de l'API de Twitter..
Voici une visualisation de la façon dont cela fonctionne:
Il existe trois variantes de l'API Twitter Streaming:
La mise en œuvre de votre diffusion en continu consiste à enregistrer les événements entrants le plus rapidement possible et à les traiter en arrière-plan à l'aide de l'API REST, selon les besoins, pour collecter des données plus profondes. Les flux de sites nécessitent une approbation préalable de Twitter, qui est probablement réservée aux grandes entreprises et aux développeurs..
Heureusement, il existe une bibliothèque libre et open-source appelée Phirehose, qui met en œuvre la plupart des exigences relatives aux API de diffusion en continu. Ce tutoriel décrira comment intégrer Phirehose à notre application open-source Birdcage.
Phirehose est une fantastique implémentation PHP à code source ouvert des exigences de l’API Twitter Stream écrites par Fenn Bailey. Comme il le décrit, Phirehose est censé:
J'ai trouvé la bibliothèque fonctionner parfaitement. Il y a plus de documentation Phirehose ici.
Il est conçu pour maintenir la connexion avec Twitter et répondre au flux de données de Twitter tout en fonctionnant indéfiniment sans interruption. Il n'est pas destiné à effectuer un traitement détaillé sur tweet et une hydratation des données, ce que nous avons décrit dans la deuxième partie de cette série. Cela peut être fait séparément.
En règle générale, vous ne pouvez pas exécuter une tâche périodique Web typique en tant qu'opération de maintien en activité indéfinie. Il vaut mieux créer un démon en ligne de commande.
L'une des fonctionnalités puissantes offertes par Yii est la possibilité d'exécuter des applications basées sur une console à partir de la ligne de commande. Cela nous permettra d’exécuter une application en ligne de commande keep-alive qui utilise l’ensemble du framework Birdcage PHP et MySQL que nous avons construit..
dans le / app / répertoire, en dehors de la racine accessible Web, nous allons ajouter un stream.php fichier qui exécute notre commande de console de streaming Phirehose:
courir();
Ensuite, nous allons construire le fichier de commande réel, StreamCommand.php, dans le / app / protected / orders annuaire:
findByPk (1); $ c = nouveau consommateur ($ result ['oauth_token'], $ result ['oauth_token_secret'], Phirehose :: METHOD_USER); // charge les clés de l'application Twitter $ app = UserSetting :: model () -> loadPrimarySettings (); $ c-> consommateurKey = $ app ['twitter_key']; $ c-> consumerSecret = $ app ['twitter_secret']; $ c-> consomme ();
Il lancera le processus Phirehose, Consumer, à l'aide de notre application Twitter et de nos clés d'utilisateur..
Remarque: aux fins de l'exemple de diffusion en continu de Birdcage, nous supposons qu'un seul compte Twitter est enregistré et que le code matériel chargeant les informations d'identification, par exemple. account_id = 1.
Pour intégrer Phirehose dans Birdcage, j'ai déménagé OAuthPhirehose.php et UserstreamPhirehose.php dans le / app / protected / components annuaire. Dans mon main.php fichier de configuration, j'ai ajouté phirehose à la liste des composants chargés:
Accentsconagua
'précharge' => tableau ('log', 'bootstrap', 'mailgun', 'phirehose', 'advanced'), Ensuite, j'ai créé une migration de base de données pour créer une table dans laquelle stocker les données brutes du flux Twitter:
la classe m140919_193106_create_stream_table étend CDbMigration protected $ MySqlOptions = 'ENGINE = InnoDB CHARSET = utf8 COLLATE = utf8_unicode_ci'; public $ tablePrefix; public $ tableName; fonction publique before () $ this-> tablePrefix = Yii :: app () -> getDb () -> tablePrefix; if ($ this-> tablePrefix <> ") $ this-> tableName = $ this-> tablePrefix.'stream '; fonction publique safeUp () $ this-> before (); $ this-> createTable ($ this -> tableName, array ('id' => 'pk', 'tweet_id' => 'bigint (20) unsigned NOT NULL', 'code' => 'text NULL', 'is_processed' => 'tinyint default 0' , 'created_at' => 'DATETIME NOT NULL DEFAULT 0', 'modified_at' => 'TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP',), $ this-> MySqlOptions); $ this-> createIndex ('tweet_id', $ this- > nom_table, 'tweet_id', true);J'ai aussi créé un nouveau modèle appelé Consumer.php qui s'étend OauthPhirehose avec son requis enqueueStatus méthode.
Nous souhaitons minimiser le temps de traitement requis par la réponse en temps réel. Essentiellement, nous souhaitons simplement enregistrer les données reçues de Twitter dans notre base de données, et rien d’autre. Nous pouvons effectuer d'autres traitements dans nos propres tâches d'arrière-plan sans ralentir la connexion en continu de Phirehose. Ma fonction prend juste les données tweet du flux entrant et les stocke dans la table des flux:
id_str))) return; $ s = new Stream; $ s-> tweet_id = $ stream_item-> id_str; $ s-> code = base64_encode (serialize ($ stream_item)); $ s-> is_processed = 0; $ s-> created_at = new CDbExpression ('NOW ()'); $ s-> modified_at = new CDbExpression ('NOW ()'); $ s-> save (); var_dump ($ stream_item); ?> Nous nous appuierons sur les tâches d’arrière-plan exécutées par notre DaemonController pour traiter les données dans le modèle Bircdcage Tweet. Ceci est décrit plus en détail ci-dessous.
Vous pouvez tester Phirehose en utilisant la commande de la console PHP:
php ./app/stream.php Stream
Twitter enverra un flux d’informations suivies pour le compte de l’utilisateur, suivies des données en temps réel à l’arrivée..
Pour activer Phirehose en tant que commande de console persistante, toujours active, nous allons utiliser la commande nohup, par exemple. pas de blocage, et redirige la sortie vers dev / null:
nohup php ./app/stream.php Flux> / dev / null 2> & 1 &
Ubuntu répondra avec un identifiant de travail de votre processus pour une surveillance et une résiliation futures:
[1] 9768
Si vous souhaitez vérifier que le processus est en cours d'exécution, recherchez dans la liste des tâches l'identifiant du travail:
ps -e tous | grep 9768
Vous devriez voir quelque chose comme ça:
0 1000 9768 9743 20 0 273112 16916 sondages Pts / 0 0:00 php ./app/stream.php Flux
Et vous pouvez mettre fin à Phirehose en éliminant l'identifiant du travail:
tuer 9768
D'après mon expérience, Phirehose a parfaitement fonctionné avec cette technique sans interruption au cours des deux dernières semaines..
Nous devons également créer un processus d'arrière-plan dans Birdcage, qui traitera les données en continu dans nos tables Tweet, Mention, URL et Hashtag, comme si elles provenaient de l'API REST..
Change ton twitter.ini paramètre de fichier pour utiliser les flux:
twitter_stream = true
Et nous pouvons utiliser le même travail cron de la deuxième partie pour exécuter cette opération:
# Pour définir l'heure, vous pouvez fournir des valeurs concrètes pour # minute (m), heure (h), jour du mois (dom), mois (lun), # et jour de la semaine (Dow) ou utilisez '*' dans ces champs. (pour 'any'). # # Notez que les tâches seront démarrées en fonction de la notion de temps et de fuseaux horaires du démon système de cron. # # Par exemple, vous pouvez exécuter une sauvegarde de tous vos comptes utilisateurs # à 5 heures du matin chaque semaine avec: # 0 5 * * 1 tar -zcf /var/backups/home.tgz / home / # # mh commande mon mon * / 5 * * * * wget -O / dev / null http://birdcage.votredomaine.com/daemon/index
Ensuite, lorsque DaemonController est appelé, il activera le flux modèle() méthode de traitement:
fonction publique actionIndex () // si nous n'utilisons pas les flux Twitter, nous traiterons les tweets par l'API REST si (! Yii :: app () -> params ['twitter_stream']) Tweet :: model () -> getStreams (); else Stream :: model () -> process ();
La méthode de processus décompresse les données du flux codé et analyse chaque entrée comme nous l'avons fait avec le contenu de l'API REST:
public function process () // récupère les tweets non traités du moteur de flux // à faire $ account_id = 1; $ items = Stream :: model () -> non traité () -> findAll (); foreach ($ items en tant que $ i) $ tweet = unserialize (base64_decode ($ i ['code']))); Tweet :: model () -> parse ($ account_id, $ tweet); $ this-> setStatus ($ i ['id'], self :: STREAM_PROCESSED);
Birdcage ignore actuellement les données du flux qui ne sont pas un tweet, par exemple. notifications, messages directs, etc. Je vous laisse développer, ou vous pouvez consulter mon application étendue, Birdhouse.
J'espère que vous avez trouvé cette série d'API Twitter en trois parties informative et utile. A présent, vous avez découvert OAuth, l'API REST, l'API Streaming, la construction d'une base de données pour Twitter, le traitement de la timeline avec les deux types d'API, le comptage correct des caractères dans les tweets et leur publication, et plus encore..
S'il vous plaît poster des commentaires, des corrections ou des idées supplémentaires ci-dessous. Vous pouvez parcourir mes autres tutoriels Tuts + sur ma page d’auteur ou me suivre sur Twitter @reifman.
