เหตุผลในการใช้ API แบบอะซิงโครนัส
เหตุผลที่แนวคิดของอะซิงโครนัสกลายเป็นที่นิยมใน Web2.0 เป็นเพราะ JavaScript ถูกดำเนินการในเธรดเดียวในเบราว์เซอร์และยังใช้เธรดที่มีการเรนเดอร์ UI ซึ่งหมายความว่าการเรนเดอร์และการตอบสนองของ UI อยู่ในสถานะนิ่งเมื่อมีการดำเนินการ JavaScript เพื่อประสบการณ์การใช้งานที่ดีขึ้นวิธีการแบบอะซิงโครนัส (แน่นอนว่านี่คือภาษาเดียวที่เรียกว่าเธรดเดี่ยว) ไม่ได้ปิดกั้นเธรดหลักและตอบสนองต่อการทำงานของผู้ใช้ต่อไป นี่เป็นหมวดหมู่ของประสบการณ์ผู้ใช้
ในทำนองเดียวกันหากวิศวกรที่มีประสบการณ์ในภาษาอื่น ๆ แน่นอนว่าเข้าใจว่าการสลับ CPU ระหว่างเธรดต้องใช้เวลามาก (ส่วนใหญ่สลับระหว่างบริบทและการแคช) ดังนั้นการปรับปรุงประสิทธิภาพจึงเป็นเหตุผลในการใช้ API แบบอะซิงโครนัส
แน่นอนว่าสิ่งเหล่านี้ไม่ถูกต้องอย่างแน่นอน แต่ทุกคนพูดอย่างนั้น เพราะถ้าค่าใช้จ่ายของการสร้าง multithreads น้อยกว่าการดำเนินการแบบขนานดังนั้นวิธีการมัลติเธรดเป็นตัวเลือกแรกซึ่งมักจะถือว่าเป็นงานประมวลผลที่ใช้ CPU มาก
ในระยะสั้น IO หรือ API แบบอะซิงโครนัสสามารถถือได้ว่าเป็นคุณสมบัติของโหนดเนื่องจากเป็นแพลตฟอร์มที่ใช้ IO แบบอะซิงโครนัสบนเลเยอร์แอปพลิเคชันในขนาดใหญ่และมุ่งมั่นที่จะจัดสรรทรัพยากรอย่างมีประสิทธิภาพมากขึ้นในเธรดเดียว
เกี่ยวกับสัญญา
ที่นี่บทความนี้ไม่ได้ตั้งใจที่จะอธิบายการใช้สัญญาโดยละเอียด แต่อธิบายสั้น ๆ ของ API และขอบเขตการทดลองของสัญญา: สั้น ๆ :
// การรวมฟังก์ชั่น fs.readdir ของ nodejs เพื่อสร้าง Promisevar Promisetask = สัญญาใหม่ (ฟังก์ชั่น (แก้ไข, ปฏิเสธ) {fs.readdir ('/var/www', ฟังก์ชั่น (err, ไฟล์) {ถ้า (! console.log ('เนื้อหาคือ:'+ไฟล์); PromisEtask.catch (ฟังก์ชั่น (err) {console.log ('รายงานข้อผิดพลาดเป็น:'+err);});วิธีรอหลายคำสัญญาที่จะดำเนินการให้เสร็จสมบูรณ์?
// เชื่อมต่อ PromisEtask ด้านบนแล้ว (ฟังก์ชั่น (ไฟล์) {var readfilSepromiselist = files.map (ฟังก์ชั่น (ไฟล์, ดัชนี) {ส่งคืนสัญญาใหม่ (ฟังก์ชั่น (แก้ไข, ปฏิเสธ) {fs.readfile (ไฟล์}} {returt); Promise.All (ReadFilSepromisElist);}) จากนั้น (ฟังก์ชั่น (filestrarray) {console.log ('ไฟล์ที่เรียกว่าการอ่านเสร็จสมบูรณ์:'+filestrarray);});รหัสนี้แสดงความสง่างามของการพัฒนา NodeJS
แล้วปัญหาคืออะไร?
ภาษาที่สง่างามที่สุดในปัจจุบันยังคงอาศัยระบบปฏิบัติการนั่นคือข้อ จำกัด ของระบบยังคงมีอยู่:
ฉันไม่ทราบว่าข้อผิดพลาดนี้สามารถตีความได้ว่าเป็นที่จับการทำงานของไฟล์ที่หมดลงหรือไม่ แต่ฉันหวังว่าคุณจะเข้าใจบทความนี้ว่าระบบปฏิบัติการไม่สามารถเปิดไฟล์หลายไฟล์ได้ไม่ จำกัด ในเวลาเดียวกัน
และสิ่งนี้:
นี่เป็นเรื่องง่ายที่จะเข้าใจและหน่วยความจำหมด แน่นอนขีด จำกัด ของหน่วยความจำสามารถปรับได้โดยการเพิ่มพารามิเตอร์การทำงานสองตัวต่อไปนี้:
Node-Max-old-space-size = 8192 ./index.js #Unit MB Node-Max-New-Space-Size = 2048 ./index.js #UNIT KB
พารามิเตอร์ข้างต้นมีผลเมื่อ V8 เริ่มต้นและไม่สามารถเปลี่ยนแปลงได้แบบไดนามิกเมื่อมีผล
หลายคนอาจเสนอว่าข้อ จำกัด ทั้งสองนี้มีอยู่เช่นกันในภาษาอื่น ๆ ใช่ภาษาอื่น ๆ ก็มีอยู่เช่นกัน
อย่างไรก็ตาม GC ที่ทรงพลังหรือโมเดลการเขียนโปรแกรมแบบมัลติเธรดในภาษาอื่น ๆ สามารถอนุญาตให้วิศวกรปล่อยพวกเขาได้ทันเวลาหลังจากสมัครใช้ทรัพยากรระบบ
แม้ว่าทรัพยากรของระบบที่ไม่จำเป็นสามารถเผยแพร่ด้วยตนเองใน NodeJs แต่การดำเนินการทุกครั้งในโปรแกรมอ้างอิงจะได้รับการปล่อยตัวในเวลาหรือไม่?
ตัวอย่างเช่น แพ็คเกจ NODEJS REDIS (NPM ติดตั้ง REDIS) ไม่ได้ให้วิธีการดำเนินการซิงโครไนซ์
ซึ่งหมายความว่าจำเป็นต้องมีการควบคุมกระบวนการมากขึ้นในกระบวนการพัฒนา น่าเสียดายที่ nodejs ในระบบเธรดเดี่ยวไม่ดีในเรื่องนี้เนื่องจากไม่มีแนวคิดของการทำมัลติเธรดไม่มีกลไกการล็อคและเป็นไปไม่ได้ที่จะรวมกลไกสัญญาณสัญญาณในความหมายปกติ ผลที่ได้คือวิศวกรไม่ทราบว่าจะปล่อยทรัพยากรด้วยตนเองเมื่อใด
หากคุณไม่สามารถควบคุมโครงการของคุณได้อย่างสมบูรณ์คุณจะไม่ใช้แพ็คเกจบุคคลที่สามที่ใช้ API แบบอะซิงโครนัส
ดังนั้นข้อสรุปในปัจจุบันคือสัญญาเป็นเพียงเทคนิคการพัฒนา การทำความเข้าใจสิ่งเหล่านี้ไม่เหมาะสำหรับทุกสถานการณ์การพัฒนา
สรุป
ข้างต้นเป็นเรื่องเกี่ยวกับ Node.js API แบบอะซิงโครนัสและข้อ จำกัด ฉันหวังว่าบทความนี้จะเป็นประโยชน์กับทุกคน หากคุณมีคำถามใด ๆ โปรดฝากข้อความเพื่อสื่อสาร