Il existe un tel scénario dans lequel les données soumises par l'utilisateur doivent être traitées via la route « /blog »
Supposons que trois éléments de données doivent être stockés dans trois clés, puis le code devient comme ceci
function handlePostBlog(req, res){
resid_client.set( key1, data1, function(err, response){
resid_client.set(key2, data2, function(err,response){
resid_client.set(key3, data3, function(err, response){
if(response === 'ok'){
res.writeHead(200, ...)
res.end()
}
})
})
})
}Je m'en fiche si ça a l'air bien ou pas. . Bien que cela semble mieux enveloppé de promesse, y a-t-il un problème avec res.end() lors du dernier rappel pour fermer la connexion ? Cette demande sera-t-elle en attente depuis longtemps ? Comment devrions-nous gérer ce genre d’endroit ? Parce que vous avez seulement besoin de définir et que vous n'avez pas besoin de renvoyer le résultat à l'utilisateur, pouvez-vous simplement fermer la connexion directement avec res.end() après avoir reçu la demande ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Cela dépend si vous souhaitez que les résultats de retour de cette requête HTTP soient corrélés aux résultats de l'opération de base de données et si la conception de l'interaction utilisateur tolère le temps passé sur cette opération.
Lorsque vous concevez cette interface '/blog', vous devez indiquer clairement ce que cela signifie lorsque HTTP renvoie 200. Si votre scénario commercial ne se soucie que de la livraison des données au backend et ne se soucie pas de savoir si le backend est correctement stocké dans la base de données, vous pouvez certainement mettre fin directement à la requête HTTP. Si vous souhaitez que les utilisateurs finaux obtiennent ce résultat de soumission exact, vous devez prendre en compte le niveau d'interaction, concevoir un bon effet d'interaction, attendre 2 à 6 secondes et l'expérience utilisateur ne sera pas mauvaise (en vous référant au scénario de requête AJAX, ouverture). un scénario de nouvelle page) Soyez toujours prudent). Écrire trois fois sur Redis ne prend presque pas de temps et n'est rien comparé au délai de liaison de la requête HTTP elle-même.
Des scénarios commerciaux spécifiques doivent être analysés en détail. Lorsque vous rencontrez des opérations particulièrement chronophages, il est également possible de faire alterner les résultats après avoir soumis la demande d'opération au front-end.
Vérifiez s'il existe une corrélation entre l'affichage de la page et les résultats de l'opération de la base de données. S'il existe une corrélation, vous pouvez attendre que l'opération de base de données soit terminée et revenir. Il peut également être renvoyé directement dans une file d'attente asynchrone, et le résultat sera poussé après succès. En fin de compte, tout dépend de vos besoins.