Terdapat senario sedemikian di mana data yang diserahkan pengguna perlu diproses di bawah laluan '/blog'
Anggap bahawa tiga keping data perlu disimpan dalam tiga kekunci, dan kemudian kod menjadi seperti ini
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()
}
})
})
})
}Saya tidak kisah sama ada ia kelihatan baik atau tidak. . Walaupun ia kelihatan lebih baik dibalut dengan janji, adakah terdapat masalah dengan res.end() dalam panggilan balik terakhir untuk menutup sambungan? Adakah permintaan ini akan menunggu lama? Bagaimana kita harus berurusan dengan tempat seperti ini? Kerana anda hanya perlu menetapkan dan tidak perlu mengembalikan hasilnya kepada pengguna, bolehkah anda menutup sambungan terus dengan res.end() selepas menerima permintaan?
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Ia bergantung pada sama ada anda mahu hasil pemulangan permintaan HTTP ini dikaitkan dengan hasil operasi pangkalan data dan sama ada reka bentuk interaksi pengguna bertolak ansur dengan masa yang digunakan untuk operasi ini.
Apabila anda mereka bentuk antara muka '/blog' ini, anda perlu menyatakan dengan jelas maksudnya apabila HTTP mengembalikan 200. Jika senario perniagaan anda hanya mengambil berat tentang penghantaran data ke bahagian belakang dan tidak mengambil berat sama ada bahagian belakang disimpan dengan betul dalam pangkalan data, maka anda pasti boleh menamatkan permintaan HTTP secara langsung. Jika anda mahu pengguna akhir mendapatkan hasil penyerahan yang tepat ini, anda perlu mempertimbangkan tahap interaksi Reka bentuk kesan interaksi yang baik, tunggu selama 2-6 saat, dan pengalaman pengguna tidak akan menjadi buruk (merujuk kepada senario permintaan AJAX, pembukaan. senario halaman baharu) Tetap berhati-hati). Menulis ke redis tiga kali hampir tidak mengambil masa, dan tidak ada apa-apanya jika dibandingkan dengan kelewatan pautan permintaan HTTP itu sendiri.
Senario perniagaan khusus perlu dianalisis secara terperinci. Apabila menghadapi operasi yang memakan masa terutamanya, ia juga merupakan penyelesaian untuk memutarkan keputusan selepas menyerahkan permintaan operasi di bahagian hadapan.
Lihat jika terdapat sebarang korelasi antara paparan halaman dan hasil operasi pangkalan data. Sekiranya terdapat korelasi, anda boleh menunggu sehingga operasi pangkalan data selesai dan kembali. Ia juga boleh dikembalikan terus dalam baris gilir tak segerak, dan hasilnya akan ditolak selepas kejayaan. Pada akhirnya, semuanya bergantung pada keperluan anda.