أسباب استخدام واجهات برمجة التطبيقات غير المتزامنة
السبب في أن مفهوم عدم التزامن أصبح شائعًا في Web2.0 هو أن JavaScript يتم تنفيذه على مؤشر ترابط واحد في المتصفح ، ويستخدم أيضًا مؤشر ترابط مع عرض واجهة المستخدم. هذا يعني أن عرض واجهة المستخدم والردود في حالة راكدة عندما يتم تنفيذ JavaScript. للحصول على تجربة أفضل للمستخدم ، فإن النهج غير المتزامن (بالطبع ، هذا في اللغة المزعومة المزعومة) لا تمنع الخيط الرئيسي ويستمر في الاستجابة لعمليات المستخدم. هذا ينتمي إلى فئة تجربة المستخدم.
وبالمثل ، إذا فهم المهندسون الذين لديهم خبرة بلغات أخرى ، بالطبع ، أن تبديل وحدة المعالجة المركزية بين المواضيع يتطلب الكثير من الوقت (بشكل رئيسي التبديل بين السياقات والتخزين المؤقت) ، لذلك يعد تحسين الكفاءة أيضًا سببًا لاستخدام واجهات برمجة التطبيقات غير المتزامنة.
بالطبع ، هذه ليست صحيحة تمامًا ، لكن الجميع يقول ذلك. لأنه إذا كان النفقات العامة لإنشاء Multithreads أقل من التنفيذ المتوازي ، فإن طريقة MultiThreading هي الخيار الأول ، والذي غالبًا ما يعتبر مهمة معالجة كثيفة وحدة المعالجة المركزية.
باختصار ، يمكن اعتبار IO غير المتزامن أو واجهة برمجة تطبيقات غير متزامنة ميزة العقدة ، لأنها منصة تطبق IO غير المتزامن على طبقة التطبيق على نطاق واسع ، وتسعى إلى تخصيص الموارد بشكل أكثر كفاءة على موضوع واحد.
حول الوعد
هنا ، لا تنوي هذا المقال شرح استخدام الوعد بالتفصيل ، ولكنه يشرح باختصار فقط بعض واجهات برمجة التطبيقات ونطاق الوعد المحاكمة:
// الجمع بين الدالة nodejs 'fs.readdir لإنشاء promiseTask الأصلي = وعد جديد (دالة (حل ، رفض) {fs.readdir ('/var/www '، function (err ، files) {if (! err) {files (files) ؛ Console.log ("المحتوى هو:" ملفات) ؛ promisetask.catch (function (err) {console.log ('تم الإبلاغ عن الخطأ على أنه:'+err) ؛}) ؛كيف تنتظر إكمال وعود متعددة؟
// قم بتوصيل promiseTask.then (function (files) {var readFiLsePromIselist = files.map (function (file ، index) {return new promise (function (حل ، رفض) {fs.readfile (file ، 'utf-8' ، funct (err ، str) Promise.all (readfilsepromiselist) ؛}).هذا الرمز يظهر أناقة تطوير NodeJS.
إذن ما هي المشكلة؟
لا تزال اللغة الأكثر أناقة في الوقت الحاضر تعتمد على نظام التشغيل ، أي أن حدود النظام لا تزال موجودة:
لا أعرف ما إذا كان يمكن تفسير هذا الخطأ على أنه معملات تشغيل الملفات المنكوبة ، لكن آمل أن تتمكن من فهم هذه المقالة بأن نظام التشغيل لا يمكنه فتح ملفات متعددة غير محدودة في نفس الوقت.
وهذا:
هذا سهل الفهم ، والذاكرة استنفدت. بالطبع ، يمكن ضبط حد الذاكرة عن طريق إضافة معلمات التشغيل التالية:
العقدة-حجم الفضاء القديم-SIZE = 8192 ./INDEX.JS #UNIT MB NODE-MAX-NEW-Space-Size = 2048 ./INDEX.JS #UNIT KB
تتعلق المعلمات المذكورة أعلاه عند تهيئة V8 ولا يمكن تغييرها ديناميكيًا بمجرد سريان سريانها.
قد يقترح الكثير من الناس أن هذين القيدتين موجودان أيضًا بلغات أخرى. نعم ، توجد لغات أخرى أيضًا.
ومع ذلك ، فإن GC القوية أو نماذج البرمجة متعددة الترابطات بلغات أخرى يمكن أن تسمح للمهندسين بإصدارها في الوقت المناسب بعد التقدم بطلب للحصول على موارد النظام.
على الرغم من أنه يمكن إصدار موارد النظام غير الضرورية يدويًا في NodeJS ، هل يمكن إصدار كل عملية في البرنامج المرجعي في الوقت المناسب؟
على سبيل المثال ، لا توفر حزمة Redis NodeJS (NPM تثبيت Redis) طرق تشغيل المزامنة.
هذا يعني أن هناك حاجة إلى مزيد من التحكم في العملية في عملية التطوير. لسوء الحظ ، فإن Nodejs في نظام واحد لا يتجاوز هذا الأمر ، لأنه لا يوجد مفهوم للموثوقية المتعددة ، ولا توجد آلية قفل ، ومن المستحيل تضمين آليات Semaphore بالمعنى المعتاد. والنتيجة هي أن المهندسين لا يعرفون متى يتم إصدار الموارد يدويًا.
ما لم يكن لديك تحكم مطلق في مشروعك ، فأنت لا تستخدم أي حزم طرف ثالث تستخدم واجهات برمجة التطبيقات غير المتزامنة.
لذلك ، فإن الاستنتاج الحالي هو أن الوعد هو مجرد تقنية تطوير. فهم هذه ليست مناسبة لجميع سيناريوهات التطوير.
لخص
ما سبق هو كل شيء عن Node.js API غير المتزامن وقيودها. آمل أن يكون هذا المقال مفيدًا للجميع. إذا كان لديك أي أسئلة ، فيرجى ترك رسالة للتواصل.