• ترجمة

قياس الاختناقات الإنتاجية عن طريق مرور الوقت المزدوج للحزمة

بكل المقاييس ، لا يمكن للإنترنت اليوم نقل البيانات بالسرعة المطلوبة. يعاني معظم مستخدمي الهواتف الخلوية في العالم من تأخيرات تتراوح من بضع ثوانٍ إلى عدة دقائق: عامة نقاط WiFiإنه أسوأ في المطارات والمؤتمرات. يحتاج الفيزيائيون وعلماء المناخ إلى تبادل بيتابايت من البيانات مع زملائهم في جميع أنحاء العالم ، لكنهم يجدون أن بنيتهم ​​التحتية المعقدة متعددة الجيجابت غالبًا ما تدفع بضع ميغا بت في الثانية على الروابط العابرة للقارات.

نشأت هذه المشاكل من اختيار البنية التي تم إجراؤها أثناء إنشاء التحكم في الازدحام في برنامج التعاون الفني في الثمانينيات - ثم تقرر تفسير فقدان الحزم على أنه "ازدحام". كان تكافؤ هذه المفاهيم صحيحًا في ذلك الوقت ، ولكن فقط بسبب قيود التكنولوجيا ، وليس من خلال التعريف. عندما تمت ترقية NIC (وحدات التحكم في واجهة الشبكة) من ميغا بت إلى جيجابت وشرائح الذاكرة من كيلوبايت إلى جيجابايت ، أصبحت العلاقة بين فقدان الحزمة والازدحام أقل وضوحًا.

في بروتوكول TCP الحديث ، يعد التحكم في ازدحام حزم البيانات - حتى في أكثر التقنيات تقدمًا من نوعها ، CUBIC - السبب الجذري لهذه المشكلات. إذا كانت المخازن المؤقتة لعنق الزجاجة كبيرة جدًا ، فإن التحكم في ازدحام الحزمة يبقيها ممتلئة ، مما يتسبب في تخزين مؤقت للشبكة غير ضروري. إذا كانت المخازن المؤقتة صغيرة جدًا ، فإن التحكم في ازدحام فقدان الحزمة سوف يسيء تفسير فقدان الحزمة كإشارة إلى الازدحام ، مما يؤدي إلى انخفاض الإنتاجية. يتطلب حل هذه المشكلات بديلاً للتحكم في ازدحام فقدان الحزمة. للعثور على هذا البديل ، تحتاج إلى فهم مكان وكيفية حدوث الازدحام.

الازدحام والاختناق

لا يوجد سوى ارتباط أبطأ واحد على اتصال TCP (مزدوج كامل) في أي وقت معين ، أو عنق الزجاجةفي كل اتجاه. عنق الزجاجة مهم للأسباب التالية:

• يحدد الحد الأقصى لمعدل نقل البيانات على الاتصال. هذه هي الخاصية الرئيسية لتيار بيانات غير مضغوط (على سبيل المثال ، تخيل طريقًا سريعًا مكونًا من ستة حارات خلال ساعة الذروة ، إذا تسبب حادث في اقتصار جزء صغير واحد من الطريق على حارة واحدة فقط. وستكون حركة المرور أمام موقع الاصطدام التحرك ليس أسرع من حركة المرور عبر هذا الممر.
• هذا هو المكان الذي تتشكل فيه قوائم الانتظار باستمرار. إنها تنخفض فقط إذا تجاوزت شدة التدفق الخارج من عنق الزجاجة شدة التدفق الوارد. بالنسبة للوصلات التي تعمل بأعلى معدل بت ، فإن جميع التدفقات الصادرة إلى عنق الزجاجة لها دائمًا معدل صادر أعلى ، وبالتالي تنتقل قوائم الانتظار إلى عنق الزجاجة.

بغض النظر عن عدد الروابط الموجودة في الاتصال وما هي سرعاتها الفردية ، من وجهة نظر TCP ، يتم تمثيل المسار المعقد بشكل تعسفي كاتصال واحد مع نفس RTT (وقت التمرير المزدوج للحزمة ، أي ، ذهابا وإيابا) وعرض النطاق الترددي للاختناق ... اثنين من القيود المادية RTprop(وقت الانتشار ذهابًا وإيابًا) و BtlBw(عرض النطاق الترددي الاختناق) يؤثر على أداء الإرسال. (إذا كان مسار الشبكة عبارة عن أنبوب مادة ، فسيكون RTprop هو طول الأنبوب ، وسيكون BtlBw هو قطره).

يوضح الشكل 1 التركيبات المختلفة لـ RTT ومعدل البت مع كمية البيانات. في الرحلة، أي على متن الطائرة (البيانات المرسلة ، ولكن بدون تأكيد التسليم). تُظهر الخطوط الزرقاء حد RTprop ، بينما تُظهر الخطوط الخضراء حد BtlBw ، وتُظهر الخطوط الحمراء مخزن عنق الزجاجة المؤقت. العمليات في المناطق الرمادية غير ممكنة لأنها تتعارض مع قيد واحد على الأقل. أدت التحولات بين القيود إلى تشكيل ثلاث مناطق (محدودة التطبيق ، محدودة النطاق الترددي ومحدودة المخزن المؤقت) بسلوك مختلف نوعيًا.

الصورة 1

عندما لا توجد بيانات كافية في الرحلة لملء الأنبوب ، يحدد RTprop السلوك ؛ خلاف ذلك ، BtlBw يهيمن. تتقاطع الخطوط المحددة عند نقطة ، وهي أيضًا أنبوب BDP (منتج تأخير عرض النطاق الترددي ، مشتق عرض النطاق الترددي والتأخير). نظرًا لأن الأنبوب ممتلئ بعد هذه النقطة ، فإن الزيادة تؤدي إلى إنشاء قائمة انتظار إلى عنق الزجاجة ، مما ينتج عنه علاقة خطية بين بيانات RTT وبيانات الرحلة ، كما هو موضح في الرسم البياني العلوي. يتم التخلص من الحزم عندما يتجاوز الفائض سعة المخزن المؤقت. ازدحامهو مجرد موقع مستمر على يمين خط BDP ، و التحكم في الازدحام- نوع من المخطط لوضع حد لمدى نقل البيانات على يمين خط BDP ، في المتوسط.

يعمل التحكم في ازدحام الخسارة على الحافة اليمنى للمنطقة محدودة النطاق الترددي ، مما يوفر نطاقًا تردديًا كاملاً للاختناق على حساب زمن الوصول العالي وفقدان الحزمة المتكرر. في الأيام التي كانت فيها الذاكرة باهظة الثمن ، كانت أحجام المخزن المؤقت أكبر قليلاً من BDP ، مما قلل من الكمون الزائد للتحكم في الازدحام الضائع. أدت التخفيضات اللاحقة في أسعار الذاكرة إلى زيادة التخزين المؤقت للشبكة الزائدة وزيادة في RTT إلى ثوانٍ بدلاً من ميلي ثانية.

توجد نقطة تشغيل أفضل على الحافة اليسرى للمنطقة المحدودة للقناة مقارنة باليمين. في عام 1979 ، أظهر ليونارد كلينروك أن نقطة التشغيل هذه هي الأمثل ، فهي تزيد من الإنتاجية الفعلية مع تقليل زمن الوصول والخسارة ، سواء بالنسبة للاتصالات الفردية أو للشبكة ككل. لسوء الحظ ، في نفس الوقت تقريبًا ، أثبت جيفري يافي أنه من المستحيل إنشاء خوارزمية موزعة تتقارب عند نقطة التشغيل هذه. هذا الاكتشاف غير اتجاه البحث. بدلاً من البحث عن خوارزمية موزعة تبحث عن نقطة تشغيل Kleinrock المثلى ، بدأ الباحثون في استكشاف طرق بديلة للتحكم في الازدحام.

تقضي مجموعتنا في Google ساعات كل يوم في فحص سجلات اعتراض رؤوس حزم TCP من جميع أنحاء العالم ، لفهم الانحرافات وأمراض السلوك. عادة ، أول شيء نبحث عنه هو الخصائص الرئيسية للمسار ، RTprop و BtlBw. تشير حقيقة أنه يمكن استنتاجها من آثار الشبكة إلى أن استنتاج جاف قد لا يكون واضحًا كما كان يبدو من قبل. يعتمد استنتاجه على عدم اليقين الأساسي في القياس (على سبيل المثال ، ما إذا كانت الزيادة المقاسة في RTT ناتجة عن تغيير في طول المسار ، أو انخفاض في معدل نقل الاختناق ، أو زيادة في زمن انتقال قائمة الانتظار بسبب حركة المرور من اتصال آخر). في حين أنه من المستحيل القضاء على الارتياب في كل قياس معين ، فإن سلوك المركب بمرور الوقت يوفر صورة أوضح ، مما يشير إلى إمكانية تطبيق استراتيجيات القياس المصممة للقضاء على عدم اليقين.

من خلال الجمع بين هذه القياسات مع حلقة تتبع موثوقة وتطبيق أحدث التطورات في أنظمة التحكم ، فإن الأمل هو تطوير بروتوكول التحكم في الازدحام الموزع الذي يستجيب للازدحام الفعلي ، بدلاً من فقدان الحزم أو تأخير قائمة الانتظار القصيرة. وسوف تتقارب مع احتمالية عالية عند نقطة تشغيل Kleinrock المثلى. وهكذا بدأ مشروعنا الذي مدته ثلاث سنوات لتطوير نظام إدارة الازدحام على أساس قياس اثنين من العوامل التي تميز المسار: سعة عنق الزجاجة ووقت مرور الحزمة المزدوج ، أو BBR.

خاصية عنق الزجاجة

يعمل الاتصال بأقصى عرض نطاق ترددي وأدنى زمن انتقال عندما يكون (توازن السرعة) معدل وصول الحزمة عند عنق الزجاجة يساوي BtlBw و (القناة الكاملة) إجمالي كمية البيانات في الرحلة يساوي BDP ().

يضمن الشرط الأول استخدام عنق الزجاجة بنسبة 100٪. والثاني يضمن أن لدينا بيانات كافية لمنع حدوث اختناق بسيط ، ولكن دون تجاوز القناة. شرط توازن السرعة نفسه ليسيضمن عدم وجود قائمة انتظار ، فقط حجمه غير متغير (على سبيل المثال ، إذا بدأ الاتصال بإرسال نافذة أولية مكونة من 10 حزم إلى BDP من خمس حزم ، ثم يعمل بنفس سرعة الاختناق بالضبط ، ثم خمس من أصل عشر حزم أولية سيملأ القناة ، وسيشكل الفائض قائمة انتظار دائمة في مكان ضيق لا يمكن أن يتحلل). وبالمثل ، لا يضمن شرط القناة الكاملة عدم وجود قائمة انتظار (على سبيل المثال ، يرسل الاتصال BDP في رشقات عبر BDP / 2 ويستفيد استفادة كاملة من الاختناق ، لكن متوسط ​​قائمة الانتظار هو BDP / 4). الطريقة الوحيدة لتقليل قائمة الانتظار عند عنق الزجاجة وعبر القناة بأكملها هي تلبية كلا الشرطين في نفس الوقت.

تتغير قيم BtlBw و RTprop على مدار عمر الاتصال ، لذلك يجب تقييمها باستمرار. حاليًا ، يراقب TCP RTT (الفاصل الزمني بين إرسال حزمة بيانات إلى الرسالة التي تم تسليمها) ، لأنه مطلوب لتحديد الخسارة. في أي وقت،

أين هي "الضوضاء" من قوائم الانتظار على طول الطريق ، واستراتيجية المتلقي مع تأخير الإقرارات ، وتراكم إقرارات الاستلام ، وما إلى ذلك. RTprop هي الخاصية المادية للرابط وتتغير فقط عندما تتغير القناة نفسها. منذ تغييرات القناة تحدث على نطاق زمني ≥ RTprop، عندها سيكون هناك تقييم محايد وفعال للوقت
أي ، ابدأ في نافذة زمنية (والتي عادة ما تكون من عشرات الثواني إلى الدقائق).

على عكس RTT ، لا شيء في مواصفات TCP يتطلب تنفيذًا لتتبع صبيب عنق الزجاجة ، ولكن يمكن الحصول على تقدير جيد لهذا من تتبع معدل التسليم. عندما يتم إرجاع تأكيد تسليم الحزمة إلى المرسل ، فإنه يعرض RTT للحزمة ويعلن تسليم البيانات أثناء الرحلة عندما تغادر الحزمة. متوسط ​​سرعة التسليم بين إرسال حزمة وتلقي إقرار بالاستلام هو نسبة البيانات التي تم تسليمها إلى الوقت المنقضي :. يجب أن يكون هذا المعدل أقل من أو يساوي إنتاجية عنق الزجاجة (الكمية عند الوصول معروفة تمامًا ، لذلك يكمن عدم اليقين الكامل الذي يجب أن يكون أكبر من أو يساوي الفاصل الزمني الحالي للوصول ؛ لذلك ، يجب أن تكون النسبة أقل من أو يساوي معدل التسليم الحقيقي ، والذي ، في قائمة الانتظار الخاصة به ، مقيَّد من الأعلى بقدرة الاختناق). لذلك ، فإن نافذة معدل التسليم القصوى هي تقدير فعال وغير جزئي لـ BtlBw:

حيث تكون النافذة الزمنية عادةً من ستة إلى عشرة أوقات RTT.

يجب أن يسجل TCP الوقت الذي تم فيه إرسال كل حزمة من أجل حساب وقت الإرسال والاستقبال. تعمل BBR على زيادة هذه السجلات بالمقدار الإجمالي للبيانات التي يتم تسليمها بحيث يبلغ وصول كل إقرار بالاستلام عن كل من RTT وقياس معدل التسليم ، والذي تترجمه المرشحات إلى تقديرات RTprop و BtlBw.

لاحظ أن هذه القيم مستقلة تمامًا: يمكن أن تتغير RTprop (على سبيل المثال ، عند تغيير المسار) ، ولكن لها نفس عنق الزجاجة ، أو يمكن تغيير BtlBw (على سبيل المثال ، عندما يتغير عرض النطاق الترددي اللاسلكي) دون تغيير المسار. (استقلالية كلا القيدتين هي سبب وجوب معرفتهما لربط سلوك الشحن بطريق التسليم). نظرًا لأن RTprop مرئي فقط على الجانب الأيسر من BDP ، و BtlBw مرئي فقط على الجانب الأيمن في الشكل 1 ، فإنهم يخضعون لمبدأ عدم اليقين: عندما يمكن قياس أحدهما ، لا يمكن قياس الآخر. بشكل بديهي ، يمكن فهم ذلك على النحو التالي: لتحديد سعة القناة ، يجب أن تكون ممتلئة بشكل زائد ، مما يؤدي إلى إنشاء قائمة انتظار لا تجعل من الممكن قياس طول القناة. على سبيل المثال ، قد لا يرسل التطبيق الذي يحتوي على بروتوكول طلب / استجابة بيانات كافية لملء القناة ومراقبة BtlBw. يمكن لساعات عديدة من نقل كمية كبيرة من البيانات قضاء كل وقتها في منطقة ذات عرض نطاق ترددي محدود وتلقي عينة واحدة فقط من RTP من RTT من الحزمة الأولى. يعني مبدأ عدم اليقين المتأصل أنه بالإضافة إلى التقديرات الخاصة بإعادة بناء معلمتين للمسار ، يجب أن تكون هناك حالات يتم تتبعها في وقت واحد وما يمكن تعلمه في نقطة التشغيل الحالية ، ومع فقدان المعلومات للحداثة ، كيفية الانتقال إلى التشغيل نقطة حيث يمكن الحصول عليها. بيانات أكثر حداثة.

تعيين دفق الحزمة إلى مسار التسليم

تتكون خوارزمية BBR الرئيسية من جزأين:

عندما نتلقى تأكيدًا (ack)

يوفر كل تأكيد RTT جديدًا ومتوسط ​​قياسات معدل التسليم التي تُحدِّث تقديرات RTprop و BtlBw:

الوظيفة onAck (packet) rtt = الآن - packet.sendtime update_min_filter (RTpropFilter، rtt) تم تسليمها + = packet.size delivery_time = now deliveryRate = (تم التسليم - packet.delivered) / (delivery_time - packet.delivered_time) إذا (معدل التسليم> BtlBwFilter. CurrentMax ||! packet.app_limited) update_max_filter (BtlBwFilter، deliveryRate) if (app_limited_until> 0) app_limited_until = app_limited_until - packet.size
تحقق ما إذا كان مطلوبًا بسبب مشكلة الغموض التي تمت مناقشتها في الفقرة الأخيرة: يمكن تقييد المرسلين بواسطة التطبيق ، أي أن التطبيق يمكن أن ينفد من البيانات لملء الشبكة. هذا موقف شائع إلى حد ما بسبب حركة الطلب / الاستجابة. عندما تكون هناك فرصة للإرسال ، ولكن لا يتم إرسال أي بيانات ، فإن BBR يشير إلى عينات النطاق الترددي المقابلة على أنها "محدودة التطبيق" ، أي app_limited (انظر الرمز الزائف للإرسال ()). يحدد هذا الرمز الأنماط التي يجب تضمينها في نموذج النطاق الترددي ، لذا فهو يعكس حدود الشبكة ، وليس حدود التطبيق. BtlBw هو حد أعلى ثابت لمعدل التسليم ، لذا فإن معدل التسليم المقاس أكبر من تقدير BtlBw الحالي يجب أن يعني التقليل من BtlBw ، سواء كانت العينة مقيدة بالتطبيق أم لا. خلاف ذلك ، يتم تجاهل الأنماط المقيدة بالتطبيق. (يوضح الشكل 1 أنه في المنطقة التي بها قيود تطبيق deliveryRate ، يتم التقليل من قيمة المعلمة BtlBw). تمنع هذه الفحوصات مرشح BtlBw من الامتلاء بقيم تم التقليل من شأنها ، مما قد يؤدي إلى إبطاء إرسال البيانات.

عندما يتم إرسال البيانات

لربط معدل وصول الحزم بمعدل المغادرة من عنق الزجاجة ، تراقب BBR كل حزمة بيانات. (يجب أن تتطابق BBR معدلعنق الزجاجة: هذا يعني أن التتبع جزء لا يتجزأ من البنية وجزء أساسي من الوظيفة - لذلك معدل السرعةهي معلمة التحكم الرئيسية. المعلمة المساعدة cwnd_gainيربط الرحلةمع مجموعة صغيرة من BDPs للتعامل مع الأمراض النموذجية للشبكة والمتلقي (انظر الفصل الخاص بالإشعارات المتأخرة والممتدة أدناه). من الناحية المفاهيمية ، يبدو إجراء إرسال TCP مشابهًا للشفرة التالية. (في Linux ، يستخدم إرسال البيانات نظام FQ / pacing الفعال ، والذي يمنح BBR الأداء الخطي لاتصال واحد على روابط متعددة جيجابت ويتعامل مع الآلاف من الاتصالات الأبطأ مع حمل ضئيل لوحدة المعالجة المركزية.)

وظيفة إرسال (حزمة) bdp = BtlBwFilter.currentMax × RTpropFilter.currentMin if (inflight> = cwnd_gain × bdp) // انتظر عودة ack أو مهلة إعادة الإرسال إذا (الآن> = nextSendTime) packet = nextPacketToSend () if (! Packet) app_until = حزمة الإرجاع أثناء الرحلة .app_limited = (app_limited_until> 0) packet.sendtime = now packet.delivered = حزمة تم تسليمها. التالي
سلوك دولة ثابت

تعتمد سرعة وكمية البيانات المرسلة عبر BBR فقط على BtlBw و RTprop ، وبالتالي فإن المرشحات لا تتحكم فقط في تقديرات قيود عنق الزجاجة ، ولكن أيضًا في تطبيقها. يؤدي هذا إلى إنشاء حلقة التحكم المخصصة الموضحة في الشكل 2 ، والتي تُظهر RTT (باللون الأزرق) والطائرة (الأخضر) ومعدل التسليم (الأحمر) أكثر من 700 مللي ثانية لتيار 10 ميجا بت 40 مللي ثانية. الخط الرمادي الغامق أعلى معدل التسليم هو حالة مرشح BtlBw max. يتم الحصول على الأشكال المثلثة من خلال تطبيق معامل pacing_gain دوريًا في BBR لتحديد الزيادة في BtlBw. يتم عرض المكسب في كل جزء من الدورة في محاذاة الوقت مع البيانات التي أثرت عليها. نجح هذا العامل في وقت مبكر من وقت إرسال البيانات عند إرسال البيانات. يظهر هذا من خلال المخالفات الأفقية في وصف تسلسل الأحداث على الجانب الأيسر.

الصورة 2

تقلل BBR من وقت الاستجابة لأن معظم الوقت يمر مع نفس BDP أثناء العمل. نتيجة لذلك ، ينتقل عنق الزجاجة إلى المرسل ، بحيث تصبح الزيادة في BtlBw غير مرئية. لذلك ، تقضي BBR بشكل دوري فترة RTprop عند pacing_gain> 1 ، مما يزيد من سرعة الإرسال وكمية البيانات المرسلة دون تأكيد التسليم (على متن الطائرة). إذا لم يتغير BtlBw ، فسيتم إنشاء قائمة الانتظار أمام عنق الزجاجة ، مما يؤدي إلى زيادة RTT ، مما يحافظ على ثبات معدل التسليم. (يمكن مسح قائمة الانتظار عن طريق إرسال بيانات بقيمة إزاحة pacing_gain< 1 для следующего RTprop). Если BtlBw увеличивается, то скорость deliveryRate тоже увеличивается, а новое максимальное значение фильтра немедленно увеличивает базовую скорость отслеживания (معدل السرعة). لهذا السبب ، تتكيف BBR مع حجم عنق الزجاجة الجديد بسرعة كبيرة. يوضح الشكل 3 هذا التأثير على تدفق 10 ميغابت في الثانية 40 مللي ثانية ، والذي يزيد BtlBw فجأة حتى 20 ميغابت في الثانية بعد 20 ثانية من التشغيل الثابت (على الجانب الأيسر من الرسم البياني) ، ثم ينخفض ​​إلى 10 ميغابت في الثانية بعد 20 ثانية أخرى من التشغيل المستمر بواسطة 20 ميجابت في الثانية (الجانب الأيمن من الرسم البياني).

الشكل 3

(أساسًا ، BBR هو مثال بسيط لنظام التحكم "max-plus" ، وهو نهج جديد لأنظمة التحكم يعتمد على جبر max-plus غير قياسي. يسمح هذا النهج بتكييف السرعة [التي يتم التحكم فيها بواسطة نسبة التروس الأعلى] بغض النظر عن نمو قائمة الانتظار [التي تسيطر عليها نسبة الإرسال معدل]. كما هو مطبق على مشكلتنا ، فإنه يتحول إلى حلقة تحكم بسيطة وغير مشروطة ، حيث يتم تنفيذ التكيف مع التغييرات في القيود المادية تلقائيًا عن طريق تغيير المرشحات التي تعبر عن هذه القيود. قد يتطلب النظام التقليدي إنشاء العديد من حلقات التحكم المدمجة في آلة حالة معقدة لتحقيق هذه النتيجة.)

السلوك عند بدء خيط BBR واحد

تتعامل التطبيقات الحديثة مع أحداث مثل بدء التشغيل وإيقاف التشغيل واسترداد الخسارة باستخدام خوارزميات "مستجيبة للأحداث" مع الكثير من أسطر التعليمات البرمجية. يستخدم BBR الكود أعلاه (في الفصل السابق "مطابقة تدفق الحزمة إلى مسار التسليم") لكل شيء. يتم التعامل مع الأحداث من خلال اجتياز سلسلة من "الحالات". يتم تحديد "الحالات" نفسها بواسطة جدول به قيمة ثابتة واحدة أو أكثر من المعاملات ومعايير الخروج. يتم قضاء معظم الوقت في حالة ProbeBW ، والتي تم وصفها في فصل Steady State Behavior. يتم استخدام حالات بدء التشغيل والاستنزاف عند بدء الاتصال (الشكل 4). للتعامل مع اتصال حيث يزيد معدل النقل بمقدار 12 أمرًا من حيث الحجم ، تنفذ حالة بدء التشغيل خوارزمية بحث ثنائية لـ BtlBw ، والتي تستخدم عامل إرسال لمضاعفة معدل الإرسال عند زيادة معدل التسليم. يعرّف هذا BtlBw في RTT ، ولكن في نفس الوقت يُنشئ قائمة انتظار غير ضرورية من قبل. بمجرد أن يجد Startup BtlBw ، ينتقل نظام BBR إلى حالة Drain ، والتي تستخدم نسب التروس العكسية لبدء التشغيل للتخلص من قائمة الانتظار المفرطة ، ثم إلى حالة ProbeBW بمجرد أن تنخفض الطائرة إلى خط BDP.

الشكل 4

يوضح الشكل 4 الثانية الأولى لتيار BBR بسرعة 10 ميجابت 40 مللي ثانية. يوضح الرسم البياني العلوي وقت الأحداث وتسلسلها ، بالإضافة إلى تقدم المرسل (باللون الأخضر) والمستلم (باللون الأزرق): مقدار البيانات المرسلة والمستلمة. يوضح الخط الأحمر أداء المرسل باستخدام تقنية CUBIC في ظل نفس الظروف. تشير الخطوط الرمادية العمودية إلى أوقات الانتقال بين حالات BBR. يوضح الرسم البياني السفلي التغيير في وقت الذهاب والإياب (RTT) لكلا الوصلات. يرجى ملاحظة أن الجدول الزمني لهذا الجدول يتوافق مع وقت استلام تأكيد الوصول (ack). لذلك ، قد يبدو أن الرسوم البيانية قد تغيرت بمرور الوقت ، ولكن في الواقع تتوافق الأحداث أدناه مع تلك اللحظات التي يتعلم فيها نظام BBR عن هذه الأحداث ويتفاعل معها.

يقارن الرسم البياني السفلي في الشكل 4 BBR و CUBIC. في البداية ، كان سلوكهم متماثلًا تقريبًا ، لكن BBR يفرغ تمامًا قائمة الانتظار التي تشكلت في بداية الاتصال ، ولا يمكن لـ CUBIC القيام بذلك. لا يحتوي على نموذج تتبع يخبرك بكمية البيانات المرسلة الزائدة عن الحاجة. لذلك ، يعمل CUBIC بشكل أقل على زيادة نقل البيانات دون تأكيد التسليم ، ولكن هذا النمو يستمر حتى يفيض المخزن المؤقت للاختناق ويبدأ في إسقاط الحزم ، أو حتى يصل المستلم إلى الحد الأقصى للبيانات المرسلة دون تأكيد (نافذة استقبال TCP).

يوضح الشكل 5 سلوك RTT في الثواني الثماني الأولى من الاتصال الموضح في الشكل 4 السابق. تملأ تقنية CUBIC (باللون الأحمر) المخزن المؤقت المتاح بالكامل ، ثم تدور بين 70٪ و 100٪ تعبئة كل بضع ثوانٍ. بعد بدء الاتصال ، يعمل BBR (باللون الأخضر) تقريبًا بدون إنشاء قائمة انتظار.

الشكل 5

السلوك عندما تلتقي عدة تيارات BBR في عنق الزجاجة

يوضح الشكل 6 كيف يتقارب معدل نقل تيارات BBR المتعددة في قسم صادق من عنق الزجاجة 100 ميجابت / 10 مللي ثانية. الهياكل المثلثية المواجهة للأسفل هي حالات من اتصالات ProbeRTT حيث تعمل المزامنة الذاتية على تسريع التقارب النهائي.

الشكل 6

تحفز دورات كسب ProbeBW (الشكل 2) تدفقات أكبر لإنتاج عرض النطاق الترددي إلى تدفقات أصغر ، ونتيجة لذلك يفهم كل تيار حالته الصادقة. يحدث هذا بسرعة كبيرة (عدة دورات ProbeBW) ، على الرغم من أن الظلم يمكن أن يستمر إذا بالغت الخيوط في وقت متأخر في بداية إعادة التوزيع في تقدير RTprop نظرًا لحقيقة أن الخيوط التي بدأت سابقًا (مؤقتًا) تنشئ قائمة انتظار.

لاكتشاف RTProp الحقيقي ، ينتقل الدفق إلى يسار خط BDP باستخدام حالة ProbeRTT: إذا لم يتم تحديث تقدير RTProp (أي بقياس RTT أصغر) لعدة ثوانٍ ، فإن BBR يدخل حالة ProbeRTT ، وتقليل كمية البيانات المرسلة (في الجو) إلى أربع حزم لمرور مزدوج واحد على الأقل ، ثم العودة إلى الحالة السابقة. عندما تدخل الخيوط الكبيرة إلى حالة ProbeRTT ، تتم إزالة العديد من الحزم من قائمة الانتظار ، بحيث ترى عدة سلاسل في وقت واحد قيمة RTprop الجديدة (الحد الأدنى الجديد لـ RTT). بفضل هذا ، يتم إعادة تعيين تقديرات RTprop الخاصة بهم إلى الصفر في نفس الوقت ، بحيث يدخلون جميعًا معًا في حالة ProbeRTT - وتقل قائمة الانتظار أكثر ، ونتيجة لذلك ترى المزيد من سلاسل الرسائل قيمة RTprop الجديدة ، وما إلى ذلك. . هذا التنسيق الموزع هو عامل رئيسي في عدالة واستقرار عرض النطاق الترددي.

تقوم BBR بمزامنة الخيوط حول الحدث المطلوب ، وهو عبارة عن قائمة انتظار فارغة في عنق الزجاجة. على النقيض من ذلك ، فإن اختناق ازدحام فقدان الحزمة يزامن التدفقات حول الأحداث غير المرغوب فيها مثل النمو الدوري لقائمة الانتظار وتدفقات المخزن المؤقت ، مما يزيد من زمن الوصول وفقدان الحزمة.

تجربة تنفيذ B4 WAN في Google

B4 من Google عبارة عن شبكة WAN عالية السرعة (شبكة واسعة النطاق) مبنية على محولات تقليدية منخفضة التكلفة. ترجع الخسائر على مفاتيح التبديل العازلة الضحلة بشكل أساسي إلى الارتفاع العرضي في رشقات صغيرة من حركة المرور. في عام 2015 ، بدأت Google في نقل حركة مرور العمل من CUBIC إلى BBR. لم يتم الإبلاغ عن أي مشاكل أو تراجع ، ومنذ عام 2016 ، كانت جميع حركات مرور B4 TCP تستخدم BBR. يوضح الشكل 7 سببًا واحدًا لذلك: معدل نقل BBR ثابتًا بمقدار 2-25 مرة من CUBIC. لقد رأينا تحسنًا أكبر ، ولكن وجدنا أن 75٪ من اتصالات BBR مقيدة بمخزن استقبال TCP المؤقت في النواة ، والذي عمد فريق عمليات الشبكة إلى تعيينه على قيمة منخفضة (8 ميجابايت) لمنع CUBIC من إغراق الشبكة بالميغابايت الزائدة. حركة المرور دون تأكيد التسليم (إذا قسمت 8 ميجا بايت على 200 مللي ثانية من RTT العابر للقارات ، فستحصل على 335 ميجا بايت في الثانية كحد أقصى). أدت زيادة المخزن المؤقت للاستقبال يدويًا على طريق واحد من الولايات المتحدة إلى أوروبا إلى زيادة معدل بيانات BBR إلى 2 جيجابت في الثانية ، بينما ظل CUBIC عند 15 ميجابت في الثانية - زيادة نسبية بمقدار 133 ضعفًا تنبأ بها عمل Matis et al في عام 1997.

الشكل 7

يوضح الشكل 7 التحسن النسبي في BBR على CUBIC ؛ أقحم - وظائف التوزيع التراكمي (CDF) للصبيب. تم أخذ القياسات باستخدام خدمة الاستشعار النشط ، والتي تفتح اتصالات BBR و CUBIC الدائمة لمراكز البيانات البعيدة ، ثم تنقل 8 ميجا بايت من البيانات كل دقيقة. تستكشف المجسات العديد من طرق B4 بين أمريكا الشمالية وأوروبا وآسيا.

التحسن الهائل هو نتيجة مباشرة لـ BBR ليسيستخدم فقدان الحزمة كمؤشر ازدحام. لتحقيق صبيب كامل ، تتطلب تقنيات التحكم في ازدحام فقدان الحزمة الحالية أن يكون معدل الخسارة أقل من المربع العكسي لـ BDP (على سبيل المثال ، أقل من خسارة واحدة لكل 30 مليون رزمة لتوصيل 10 جيجابت في الثانية / 100 مللي ثانية). يقارن الشكل 8 الصبيب القابل للاستخدام المقاس عند مستويات مختلفة لخسارة الحزمة. في CUBIC ، يعتبر تحمل فقدان الحزمة خاصية هيكلية للخوارزمية ، وفي BBR هو معلمة تكوين. مع اقتراب مستوى خسارة BBR من الحد الأقصى لمكاسب ProbeBW ، ينخفض ​​احتمال قياس معدل تسليم BtlBw الحقيقي بشكل حاد ، مما يؤدي إلى التقليل من جانب المرشح الأقصى.

الشكل 8

يقارن الشكل 8 عرض النطاق الترددي القابل للاستخدام لـ BBR و CUBIC في تدفق 60 ثانية على ارتباط 100 ميجابت في الثانية و 100 مللي ثانية مع خسائر عشوائية تتراوح من 0.001٪ إلى 50٪. يتم تقليل إنتاجية CUBIC بمقدار 10 مرات بخسارة 0.1٪ وتتوقف تمامًا عند أكثر من 1٪. الحد الأقصى لعرض النطاق الترددي هو جزء عرض النطاق الترددي مطروحًا منه خسارة الحزمة (). BBR مستقر عند هذا المستوى عند مستوى خسائر 5٪ وقريب منه يصل إلى 15٪.

تجربة تنفيذ YouTube Edge

يتم نشر BBR على خوادم فيديو YouTube و Google.com. تجري Google تجربة صغيرة يتم فيها نقل نسبة صغيرة من المستخدمين عن طريق الخطأ إلى BBR أو CUBIC. يُظهر تشغيل فيديو BBR تحسنًا كبيرًا في جميع تقييمات المستخدمين لجودة الخدمة. ربما لأن سلوك BBR أكثر اتساقًا ويمكن التنبؤ به. تعمل BBR على تحسين النطاق الترددي للاتصال بشكل طفيف فقط لأن YouTube يقوم بالفعل بتكييف معدل البث إلى أقل بكثير من BtlBw لتقليل التخزين المؤقت غير الضروري للشبكة وإعادة التخزين المؤقت. ولكن حتى هنا ، تعمل BBR على تقليل متوسط ​​وقت الإرسال والاستقبال بنسبة 53٪ على مستوى العالم وأكثر من 80٪ في البلدان النامية.

يوضح الشكل 9 متوسط ​​التحسن في RTT مقابل BBR و CUBIC أكثر من 200 مليون مشاهدة فيديو على YouTube تم قياسها عبر خمس قارات على مدار أسبوع. أكثر من نصف الاتصالات المحمولة في العالم البالغ عددها 7 مليارات هي 2.5 جيجا بسرعة 8 كيلو بت في الثانية إلى 114 كيلو بت في الثانية ، مع وجود مشاكل موثقة جيدًا تتعلق بتقنيات التحكم في ازدحام فقدان الحزمة التي تميل إلى تجاوز المخازن المؤقتة. عادة ما يكون الاختناق في هذه الأنظمة بين SGSN (عقدة دعم خدمة GPRS) والجهاز المحمول. يتم تشغيل برنامج SGSN على نظام أساسي للكمبيوتر الشخصي مع ذاكرة وصول عشوائي كبيرة ، وغالبًا ما يكون ذلك بميغابايت من المخزن المؤقت بين الإنترنت والجهاز المحمول. يقارن الشكل 10 زمن انتقال SGSN (المقلد) بين الإنترنت والجوال لـ BBR و CUBIC. تشير الخطوط الأفقية إلى أحد أخطر العواقب: يتكيف بروتوكول TCP مع فترات التأخير الطويلة في وقت الإرسال والاستقبال باستثناء حزمة SYN التي تبدأ الاتصال ، والتي لها مهلة ثابتة ، اعتمادًا على نظام التشغيل. عندما يتلقى جهاز محمول كمية كبيرة من البيانات (على سبيل المثال ، من تحديث أوتوماتيكيالبرنامج) من خلال SGSN مع مخزن مؤقت كبير ، لا يمكن للجهاز إنشاء أي اتصال بالإنترنت حتى يتم تحرير قائمة الانتظار (يتأخر SYN ACK لفترة أطول من مهلة SYN الثابتة).

الشكل 9

يوضح الشكل 10 تغييرات RTT المتوسطة في الحالة الثابتة للرابط مقابل حجم المخزن المؤقت على ارتباط 128 كيلو بت في الثانية و 40 مللي ثانية مع ثمانية تدفقات BBR (خضراء) أو CUBIC (حمراء). تحافظ BBR على قائمة الانتظار عند القيم الدنيا ، بغض النظر عن حجم المخزن المؤقت للاختناق وعدد الخيوط النشطة. تملأ تدفقات CUBIC دائمًا المخزن المؤقت ، لذلك يزداد زمن الوصول خطيًا مع حجم المخزن المؤقت.

الشكل 10

النطاق التكيفي في الهاتف الخلوي المحمول

تقوم الأنظمة الخلوية بتكييف عرض النطاق الترددي لكل مستخدم جزئيًا بناءً على توقعات الطلب ، والتي تأخذ في الاعتبار قائمة انتظار الحزم المخصصة لذلك المستخدم. تم ضبط الإصدارات المبكرة من BBR لإنشاء قوائم انتظار صغيرة جدًا ، مما تسبب في توقف التوصيلات سرعات منخفضة... أدت زيادة ذروة pacing_gain لـ ProbeBW وزيادة قوائم الانتظار إلى عدد أقل من الاتصالات المتوقفة. هذا يدل على قدرة كبيرة على التكيف مع بعض الشبكات. مع قيمة كسب الذروة الحالية ، لا يوجد تدهور في أي شبكة مقارنة بشبكة CUBIC.

حزم ack المتأخرة والممتدة

غالبًا ما تؤخر الشبكات الخلوية وشبكات WiFi وشبكات النطاق العريض وتراكم حزم ack. عندما تقتصر الرحلة على BDP واحد ، فإنها تسبب توقفًا ، مما يقلل من عرض النطاق الترددي. أدت زيادة عامل كسب ProbeBW إلى اثنين إلى السماح باستمرار الإرسال السلس بمعدل التسليم المتوقع ، حتى عندما تتأخر حزم ack بما يصل إلى RTT واحد. هذا يمنع إلى حد كبير الأعطال.

محددات الجرافة الحالية

أظهر الإطلاق الأولي لـ BBR على YouTube أن معظم مزودي خدمة الإنترنت في العالم يشوهون حركة المرور باستخدام محددات معدل الجرافة الحالية. عادة ما تكون الحاوية ممتلئة في بداية الاتصال ، لذلك تتعرف BBR على معلمة BtlBw للشبكة الأساسية. ولكن بمجرد أن تصبح الحاوية فارغة ، يتم التخلص من جميع الحزم التي يتم إرسالها بشكل أسرع من معدل تعبئة الدلو (أقل بكثير من BtlBw). تتعلم BBR في النهاية معدل التسليم الجديد هذا ، ولكن يؤدي تدوير كسب ProbeBW إلى خسائر معتدلة ثابتة. لتقليل فقد عرض النطاق الترددي المنبع وزيادة زمن انتقال التطبيق من هذه الخسارة ، أضفنا كاشف مقص مخصصًا ونموذج مقص صريح في BBR. نحن أيضًا نستكشف بنشاط أفضل الطرق للتخلص من الضرر الناجم عن محددات السرعة.

التنافس مع طرق التحكم في ازدحام فقدان الحزم

يتلخص BBR في المشاركة العادلة لاختناق عرض النطاق الترددي ، سواء كان ذلك في منافسة مع تدفقات BBR أخرى أو تدفقات مدفوعة بتقنيات التحكم في ازدحام فقدان الحزمة. حتى عندما يملأ الأخير المخزن المؤقت المتاح ، فإن ProbeBW لا يزال يتحيز بشكل موثوق به لتقدير BtlBw نحو الانقسام العادل ، ويعتبر ProbeRTT تقدير RTProp مرتفعًا بما يكفي لتقريب الحل مقابل واحد إلى الانقسام العادل. ومع ذلك ، فإن المخازن المؤقتة للموجهات غير المُدارة التي تتجاوز بعض نقاط BDP تجبر منافسي التحكم في الازدحام الموروث على تضخيم قائمة الانتظار والاستيلاء على أكثر من حصتهم العادلة. القضاء على هذا هو مجال آخر للبحث النشط.

استنتاج

إعادة التفكير في إدارة الازدحام فائدة كبيرة. بدلاً من استخدام أحداث مثل خسائر المخزن المؤقت أو نوبات المخزن المؤقت التي ترتبط ارتباطًا ضعيفًا بالازدحام فقط ، يبدأ BBR بنموذج الازدحام الرسمي لكلينروك ونقطة التشغيل المثلى المرتبطة به. الاستنتاج المزعج القائل بأنه "من المستحيل" تحديد وقت الاستجابة الحرج وعرض النطاق الترددي في نفس الوقت يتم تجاوزه بملاحظة أنه يمكن توقعهما في وقت واحد. بعد ذلك ، يتم تطبيق أحدث التطورات في أنظمة التحكم ونظرية التقدير لإنشاء حلقة تحكم موزعة بسيطة تقترب من المستوى الأمثل ، مع الاستفادة الكاملة من الشبكة مع الحفاظ على قائمة انتظار صغيرة. يتوفر تطبيق BBR من Google في Linux kernel مفتوح المصدر وهو مفصل في ملحق هذه المقالة.

تُستخدم تقنية BBR في العمود الفقري لـ Google B4 ، مما يؤدي إلى تحسين النطاق الترددي بأوامر من حيث الحجم على CUBIC. يتم نشره أيضًا على خوادم الويب الخاصة بـ Google و YouTube ، مما يقلل بشكل كبير من زمن الوصول عبر جميع القارات الخمس التي تم اختبارها حتى الآن ، وقوي بشكل خاص في البلدان النامية. تعمل تقنية BBR حصريًا من جانب المرسل ولا تتطلب تغييرات في البروتوكول أو المستلم أو الشبكة ، مما يسمح بنشرها تدريجيًا. يعتمد فقط على RTT وإشعارات تسليم الحزم ، لذا يمكن استخدامه في معظم بروتوكولات النقل عبر الإنترنت.

شكر وتقدير

المؤلفون ممتنون لـ Len Kleinrock للحصول على إرشادات حول كيفية التعامل مع الازدحام بشكل صحيح. نحن مدينون للاري براكمو للعمل الرائد في أنظمة إدارة الازدحام في فيجاس ونيو فيجاس التي توقعت العديد من عناصر BBR ، وعلى نصائحه وتوجيهاته خلال الأيام الأولى لتطوير BBR. نود أيضًا أن نشكر Eric Dumazet و Nandita Dukkipati و Jana Iyengar و Ian Swett و M. Fitz Nowlan و David Wetherall و Leonid Leonidas Kontothanassis و Amin Vahdat وفريق Google BwE و YouTube Infrastructure على مساعدتهم ودعمهم القيمين.

الملحق - وصف مفصل

آلة الدولة للتحقيق المتسلسل

يتحكم pacing_gain في مدى سرعة إرسال الحزم بالنسبة إلى BtlBw ، وهذا هو مفتاح ميزة BBR الذكية. عندما يكون pacing_gain أكبر من واحد ، تزداد الرحلة وتنخفض الفجوة بين الحزم ، مما يحرك الرابط إلى الجانب الأيمن في الشكل 1. عندما يكون pacing_gain أقل من واحد ، يحدث التأثير المعاكس ، ينتقل الرابط إلى اليسار.

تستخدم BBR pacing_gain لتنفيذ آلة استشعار الحالة المتسلسلة البسيطة التي تتناوب بين الاختبار للحصول على مزيد من النطاق الترددي والاختبار لأوقات مرور مزدوجة أقل. (ليس من الضروري اختبار النطاق الترددي الأصغر ، لأنه يتم معالجته تلقائيًا بواسطة مرشح BtlBw msx: القياسات الجديدة تعكس الانخفاض ، لذلك BtlBw سوف يصحح نفسه بمجرد إزالة آخر التغييرات القديمة من الفلتر بواسطة المهلة. يعالج مرشح RTprop min الزيادة في مسار التسليم بنفس الطريقة) ...

إذا زاد عرض النطاق الترددي للاختناق ، يجب أن ترسل BBR البيانات بشكل أسرع لاكتشافها. وبالمثل ، إذا تغير وقت المرور المزدوج الفعلي للحزمة ، فإن هذا يغير BDP وبالتالي يجب على BDP إرسال البيانات بشكل أبطأ لإبقاء الطائرة أسفل BDP لقياس RTprop الجديد. لهذا السبب الطريقة الوحيدةاكتشاف هذه التغييرات - التجريب ، والإرسال بشكل أسرع للتحقق من زيادة BtlBw ، أو الإرسال بشكل أبطأ للتحقق من وجود انخفاض في RTprop. يختلف تكرار هذه التجارب ونطاقها ومدتها وهيكلها اعتمادًا على ما هو معروف بالفعل (بدء الاتصال أو الحالة المستقرة) وعلى سلوك التطبيق الذي يرسل البيانات (متقطع أو مستمر).

حالة مستقرة

تقضي تدفقات BBR معظم وقتها في حالة ProbeBW ، وتبحث في الخط باستخدام طريقة تسمى اكتساب ركوب الدراجاتيساعد هذا تدفقات BBR على تحقيق إنتاجية عالية وزمن انتقال منخفض لقائمة الانتظار وتقارب عادل في المشاركة. استخدام اكتساب ركوب الدراجاتتحاول BBR بشكل دوري سلسلة من القيم للكسب pacing_gain... يتم استخدام ثماني مراحل للدورة مع القيم التالية: 5/4 ، 3/4 ، 1 ، 1 ، 1 ، 1 ، 1 ، 1. تستمر كل مرحلة عادةً لـ RTprop المتوقعة. يسمح هذا التصميم لحلقة المعامل بالتحقيق أولاً في القناة للحصول على عرض نطاق ترددي أعلى بقيمة pacing_gainأكبر من 1.0 ، ثم قم بتوزيع أي قائمة انتظار ناتجة باستخدام pacing_gainبنفس المقدار أقل من 1.0 ، ثم تحرك بسرعة إبحار مع دفعة قصيرة من المعاملات 1.0 بالضبط. متوسط ​​الكسب لجميع المراحل هو 1.0 لأن ProbeBW يميل إلى المتوسط ​​لموازنة عرض النطاق الترددي المتاح وبالتالي الحفاظ على استخدام النطاق الترددي العالي دون زيادة قائمة الانتظار. لاحظ أنه على الرغم من أن دورات النسبة تتغير pacing_gainلكن القيمة cwnd_gainتظل دائمًا تساوي اثنين ، نظرًا لأن حزم ack المتأخرة والممتدة يمكن أن تظهر في أي وقت (انظر الفصل الخاص بحزم ack المتأخرة والممتدة).

علاوة على ذلك ، لتحسين خلط التدفق وتقسيم النطاق الترددي العادل ، ولتقليل قائمة الانتظار عندما تشترك تدفقات BBR المتعددة في عنق الزجاجة ، BBR بطريقة عشوائيةيغير مراحل دورة ProbeBW ، ويختار عشوائيًا المرحلة الأولى من جميع القيم باستثناء 3/4. لماذا لا تبدأ الدورة عند 3/4؟ الغرض الرئيسي من قيمة النسبة هذه هو تشتيت أي قائمة انتظار قد تتشكل أثناء تطبيق نسبة 5/4 ، عندما تكون القناة ممتلئة بالفعل. عندما تغادر إحدى العمليات حالة Drain أو ProbeRTT وتدخل ProbeBW ، فلا توجد قائمة انتظار ، وبالتالي فإن العامل 3/4 لا يؤدي وظيفته. استخدام 3/4 في مثل هذا السياق له تأثير سلبي فقط: سيكون ملء القناة في هذه المرحلة 3/4 وليس 1. وبالتالي ، فإن بداية الدورة من 3/4 لها تأثير سلبي فقط ، ولكن ليس له تأثير إيجابي ، وبما أن مدخل الحالة ProbeBW يستغرق وقتًا طويلاً في بداية أي اتصال ، فإن BBR يستخدم هذا التحسين القليل.

تعمل سلاسل BBR معًا لتفريغ قائمة الانتظار بشكل دوري عند عنق الزجاجة باستخدام حالة تسمى ProbeRTT. في أي حالة بخلاف ProbeRTT نفسه ، إذا لم يتم تحديث تقدير RTProp (على سبيل المثال ، عن طريق قياس RTT أقل) لأكثر من 10 ثوانٍ ، فإن BBR يدخل حالة ProbeRTT ويقلل cwnd إلى قيمة صغيرة جدًا (أربع حزم ). من خلال الاحتفاظ بهذا الحد الأدنى من عدد الحزم أثناء الرحلة التي لا تقل عن 200 مللي ثانية ولمدة مرور مزدوجة انفجارية واحدة ، تخرج BBR من حالة ProbeRTT وتدخل إما Startup أو ProbeBW ، اعتمادًا على ما إذا كانت القناة ممتلئة بالفعل أم لا.

تم تصميم BBR للعمل معظم الوقت (حوالي 98٪) في حالة ProbeBW وبقية الوقت في ProbeRTT ، بناءً على مجموعة من المقايضات. تدوم حالة ProbeRTT لفترة كافية (200 مللي ثانية على الأقل) للسماح للسلاسل ذات RTTs المختلفة بالحصول على حالات ProbeRTT متزامنة ، ولكنها في نفس الوقت تستمر لفترة قصيرة بما يكفي للحد من تدهور الأداء إلى حوالي 2 بالمائة (200 مللي ثانية / 10 ثوانٍ). نافذة مرشح RTprop (10 ثوان) صغيرة بما يكفي لاستيعاب التغييرات في مستويات حركة المرور أو إعادة التوجيه بسرعة ، ولكنها كبيرة بما يكفي للتطبيقات التفاعلية. غالبًا ما تعرض مثل هذه التطبيقات (على سبيل المثال ، صفحات الويب ، واستدعاءات الإجراءات عن بُعد ، ومقاطع الفيديو) فترات طبيعية من الصمت أو نشاط منخفض في نوافذ هذه النافذة ، حيث يكون معدل التدفق بطيئًا بدرجة كافية أو طويلًا بما يكفي لتفريق قائمة الانتظار في عنق الزجاجة. يقوم مرشح RTprop بعد ذلك بضبط قياسات RTprop هذه بشكل انتهازي ويقوم بتحديث RTProp دون الحاجة إلى استخدام ProbeRTT. وبالتالي ، لا تحتاج التدفقات عادةً إلا إلى التضحية بنسبة 2٪ من عرض النطاق الترددي إذا تملأ التدفقات المتعددة القناة بكثرة عبر نافذة RTProp بأكملها.

سلوك بدء التشغيل

عندما يبدأ مؤشر ترابط BBR ، فإنه ينفذ أول (وأسرع) عملية فحص / إفراغ متسلسلة في قائمة الانتظار. يختلف عرض النطاق الترددي للشبكة في نطاق 10 12 - من بضع بتات إلى 100 جيجابت في الثانية. لمعرفة قيمة BtlBw لمثل هذا التغيير العملاق في النطاق ، تقوم BBR بإجراء بحث ثنائي في مساحة السرعة. وسرعان ما يجد BtlBw (تمريرات مزدوجة للحزم) ، ولكن على حساب إنشاء قائمة انتظار في 2BDP في المرحلة الأخيرة من البحث. يتم إجراء البحث في حالة بدء التشغيل في BBR ، ويتم تفريغ قائمة الانتظار التي تم إنشاؤها في حالة استنزاف.

أولاً ، يزيد بدء التشغيل بشكل كبير من سرعة إرسال البيانات ، ويضاعفها في كل جولة. من أجل تحقيق مثل هذا الإحساس السريع بأكثر الطرق استرخاءً ، عند بدء قيم الكسب pacing_gainو cwnd_gainإلى الحد الأدنى للقيمة التي تسمح لك بمضاعفة سرعة التحميل لكل جولة. بمجرد امتلاء القناة ، المعامل cwnd_gainيحد من حجم قائمة الانتظار إلى قيمة.

في حالة بدء الاتصال ، تحدد BBR ما إذا كانت القناة ممتلئة من خلال البحث عن هضبة في تقدير BtlBw. إذا وجد أن عدة (ثلاث) جولات قد مرت ، حيث محاولات مضاعفة سرعة التسليم لا تعطي بالفعل زيادة كبيرة في السرعة (أقل من 25٪) ، فهو يعتبر أنه وصل إلى BtlBw ، لذلك خرج من Startup الدولة ويدخل في حالة الصرف. تنتظر BBR ثلاث جولات للحصول على دليل مقنع على أن معدل التسليم المرصود للمرسل ليس تأثيرًا عابرًا بسبب نافذة الاستلام. انتظار ثلاث جولات يعطي وقتًا كافيًا ضبط تلقائيمن جانب المستلم ، لفتح نافذة الاستلام وحتى يكتشف المرسل عبر BBR الحاجة إلى زيادة BtlBw: في الجولة الأولى ، تزيد خوارزمية الضبط التلقائي لنافذة الاستلام من نافذة الاستلام ؛ في الجولة الثانية ، يملأ المرسل نافذة الاستقبال الموسعة ؛ في الجولة الثالثة ، يتلقى المرسل عينات مع زيادة سرعة التسليم. لقد أثبت هذا الحد من ثلاث جولات نفسه في تطبيق YouTube.

في حالة الاستنزاف ، تسعى خوارزمية BBR إلى إفراغ قائمة الانتظار التي تشكلت في حالة بدء الاتصال بسرعة عن طريق التبديل إلى pacing_gainبقيم معاكسة لتلك المستخدمة في حالة بدء التشغيل. عندما يتطابق عدد الحزم أثناء الرحلة مع تقدير BDP ، فهذا يعني أن BBR تعتبر قائمة الانتظار فارغة تمامًا ، لكن القناة لا تزال ممتلئة. ثم يترك BBR حالة الصرف ويدخل ProbeBW.

لاحظ أن بدء اتصال BBR وبدء CUBIC البطيء يتعلمان سرعة نقل عنق الزجاجة بشكل كبير ، مما يضاعف معدل الإرسال في كل جولة. ومع ذلك ، فهي مختلفة اختلافًا جوهريًا. أولاً ، تعد BBR أكثر موثوقية في تحديد النطاق الترددي المتاح ، حيث إنها لا تتوقف عن البحث في حالة فقد الحزمة أو (مثل CUBIC's Hystart) زيادة زمن الوصول. ثانيًا ، تزيد BBR من سرعة الإرسال تدريجيًا ، في حين أن CUBIC لديها مجموعة من الحزم في كل جولة (حتى مع السرعة) ، ثم فترة من الصمت. يوضح الشكل 4 عدد الحزم في الرحلة ويلاحظ RTT لكل رسالة إقرار من BBR و CUBIC.

الاستجابة للحالات العابرة

يمكن أن يتعرض مسار الشبكة وتدفق حركة المرور من خلالها لتغييرات جذرية مفاجئة. من أجل التكيف معها بسلاسة وموثوقية ، وكذلك تقليل فقدان الحزمة في هذه المواقف ، تستخدم BBR عددًا من الاستراتيجيات لتنفيذ نموذجها الأساسي. أولاً ، تعتبر BBR الهدف الذي من أجله التيار كونديقترب بحذر من أسفل ، زيادة كوندفي كل مرة لا يزيد عن مقدار البيانات التي تم استلام تأكيد التسليم من أجلها. ثانيًا ، مع مهلة إعادة الإرسال ، مما يعني أن المرسل يعتبر أن جميع الحزم في الرحلة مفقودة ، يقلل BBR بشكل متحفظ كوندما يصل إلى حزمة واحدة ويرسل حزمة واحدة (تمامًا مثل خوارزميات التحكم في ازدحام فقدان الحزمة مثل CUBIC). بعد كل شيء ، عندما يلاحظ المرسل فقد حزمة ، ولكن لا تزال هناك حزم في الرحلة ، في الخطوة الأولى من عملية استرداد الخسارة ، يقلل BBR مؤقتًا من معدل الإرسال إلى معدل التسليم الحالي ؛ في الجولات الثانية واللاحقة لاسترداد الخسارة ، يتحقق من أن معدل الإرسال لا يتجاوز أبدًا معدل التسليم الحالي بأكثر من الضعف. هذا يقلل بشكل كبير من الخسارة العابرة عندما يواجه BBR محددات المعدل أو يتنافس مع التدفقات الأخرى في مخزن مؤقت بحجم BDP.

الروابط

1. Abrahamsson، M. 2015. TCP ACK قمع. القائمة البريدية لـ IETF AQM ؛

في هذه المقالة ، سنحدد بعض المفاهيم التي تحتاج إلى استخدامها عند اختيار مروحة حالة ونخبرك عن الميزات النموذجية لأنواع مختلفة من المعجبين. بالإضافة إلى ذلك ، سنختبر مروحة akasa Amber AK-183-L2B بقطر 120 ملم ، والتي كانت تعمل كعنصر نشط في نظام تبريد معالج ثيرمال تيك سونيك تاور منذ أكثر من عام حتى الآن ، والتي تُستخدم في اختبار المعالجات وبطاقات الفيديو . وتجدر الإشارة إلى أنه يستحق تمامًا الحق في أن يصبح البطل الأول في سلسلة من المراجعات المخصصة للجماهير على مواردنا.

الأسئلة التي سنحاول الإجابة عليها ستكون ...

ما هي متطلبات مروحة الهيكل؟

1. مستوى الأداء.
2. مستوى الضوضاء.
3. المظهر (وجود ونوع الإضاءة).
4. ميزات إضافية (دعم مزود الطاقة PWM ، وجود وحدة تحكم في السرعة ، كاملة مع حامل مضاد للاهتزاز).

ما هي الاختلافات الرئيسية بين مراوح الكيس؟

1. الأبعاد- حجم المكره.

لإنشاء تهوية داخلية في العلبة ، في معظم الحالات ، يتم استخدام مراوح بحجم قياسي يساوي 80 مم أو 92 مم أو 120 مم ، حيث يتم توفير فتحات التثبيت مبدئيًا لتركيبها في العلبة. من الواضح تمامًا أنه كلما زاد حجم المكره للمروحة ، زادت قدرتها على ضخ تدفق الهواء. لذلك ، سيتعين على مروحة أصغر أن تدور أكثر من السرعه العاليهوبالتالي ، تحدث ضوضاء أكثر بكثير. لهذا السبب ، فإن المراوح الكبيرة التي يبلغ قطرها 120 ملم هي الأكثر شعبية.

لتوضيح هذه الخصائص ، يمكنك مقارنة خصائص نماذج المراوح لنفس السلسلة من Xinruilian Science & Technology Co. لها أحجام مختلفة:

الحجم ، مم
سرعة rpm
تدفق الهواء CFM
مستوى الضوضاء ، ديسيبل
الضغط ، مم H 2 0

انطلاقًا من الخصائص المحددة للنماذج ، يمكننا أن نستنتج أنه عند نفس سرعة الدوران البالغة 92 ملم ، ستكون المروحة أكثر كفاءة بمقدار 1.65 مرة من 80 ملم ، وستكون المروحة 120 ملم ضعف كفاءة الموديل 92 ملم ، مع الأخذ في الاعتبار أن جميع المراوح لديها نوع واحد من المكره.

بالإضافة إلى أقطار المكره المختلفة ، فإن حجم الملف التعريفي أو عمق المروحة مهم أيضًا بنفس القدر. ملف تعريف 25 مم "كلاسيكي" للحاويات التقليدية. يُطلق على المعجبين ذوي المظهر الجانبي الأصغر اسمًا منخفضًا وذو مظهر أكبر وشخصية عالية. تعتمد قوة تدفق الهواء بشكل مباشر على حجم الملف الشخصي ، والذي يتميز في المواصفات بأقصى قيمة للضغط.

على سبيل المثال ، دعنا نقارن خصائص نموذجين مقاس 120 مم - بمظهر جانبي عادي ومظهر عالٍ ، يعملان بنفس سرعة الدوران.

الحجم ، مم
سرعة rpm
تدفق الهواء CFM
مستوى الضوضاء ، ديسيبل
الضغط ، مم ارتفاع 20

يمكن أن نرى من الجدول أن المروحة البارزة تختلف فقط في أفضل مؤشر لأقصى ضغط لتدفق الهواء. عادي أنظمة الكمبيوترليست هناك حاجة لتكوين ضغط زائد ، لذلك لا يتم استخدام هذه المراوح فيها. في معظم الحالات ، يتم استخدام مراوح عالية المستوى في الخوادم ، بالإضافة إلى زيادة سرعة دورانها ، ونتيجة لذلك ، ضجيج تشغيل مرتفع إلى حد ما.

2. نوع تحمل.

هناك ثلاثة أنواع رئيسية من المحامل المستخدمة في المراوح: محامل انزلاقية ومتدحرجة عادية ، ومحامل متدحرجة ، واثنان من المحامل المتدحرجة. بالإضافة إلى هذه الأنواع من المحامل ، هناك أنواع هيدروديناميكية أقل تكرارًا ، والتي تم تطويرها بشكل منفصل من قبل بعض الشركات المصنعة.

في أغلب الأحيان ، يمكن تحديد نوع المحمل من خلال وجود المؤشرات التالية في اسم نموذج المروحة ، على الرغم من أنه يُنصح دائمًا بالتحقق من المواصفات الرسمية:

س (تكميم) - محمل الكم ، وهو في الأساس جلبة ؛
مع (كومبو) - محمل كروي واحد وجلبة قصيرة ؛
ب (كرة)أو 2B (2 كرة)- اثنان من الكرات.

أبسط وأرخص ، ولكن ، للأسف ، غير دائم بشكل خاص ، هو محمل الأكمام. هذا المحمل على شكل جلبة نحاسية صغيرة ، ينزلق داخلها عمود الدفع (قضيب) أثناء الدوران. قد تكون المروحة الجديدة ذات محمل الجلبة المشحمة صامتة تمامًا ، ولكن قد يتم فقد هذه الخاصية بمرور الوقت. في حالة عدم وجود مستوى مناسب من التزييت ، فإن البطانة "تستنفد" بسرعة كبيرة ، مما يتسبب في إحداث ضوضاء من المروحة. بالإضافة إلى ذلك ، في حالة عدم وجود تزييت ، والعمل في منطقة ذات درجة حرارة عالية ، يمكن أن تنحشر المروحة تمامًا. تتضح هذه الحقيقة بشكل خاص من خلال الحالات التي تحتوي على مصادر طاقة صينية رخيصة الثمن ، والتي غالبًا ما كانت هناك حالات توقف فيها مروحة على محمل كمي ، مما يوفر تبريدًا لعناصر أشباه موصلات الطاقة. نتيجة لذلك ، فشل مزود الطاقة.

النسخة المدمجة من المحمل لها عمر أطول نسبيًا.

يعتبر المحمل ذو الكراتين هو الأغلى ثمناً ، ولكنه في نفس الوقت خيار أكثر متانة. هذا النوع من المحامل يمكن أن يعمل بحرية في منطقة درجة حرارة عالية. ولكن في الوقت نفسه ، من بين هؤلاء المعجبين ، يمكنك غالبًا العثور على عينات تصدر ضوضاء عالية وغير سارة إلى حد ما. تتميز الصورة المماثلة بشكل خاص بالمراوح الرخيصة ، لأن خصائص الضوضاء للهيكل بأكمله تعتمد بشكل مباشر على جودة تصنيع المحمل المصغر. لذلك ، إذا اخترت منتجًا به محامل كروية ، فلا تحاول بأي حال من الأحوال أن تكون رخيصة الثمن ، لأن النماذج الأكثر تكلفة نادراً ما تكون هادئة.

3. فئة المحرك.

يتم تشغيل جميع مراوح الصندوق بواسطة محركات DC ذات 4 أقطاب. من حيث السرعة ، تم تصنيفهم جميعًا إلى ثلاث فئات: سرعة منخفضة تصل إلى 2000 دورة في الدقيقة ، وسرعة متوسطة من 2000 إلى 3000 دورة في الدقيقة ، وسرعة عالية تزيد عن 3000 دورة في الدقيقة. يمكنك غالبًا معرفة فئة محرك المروحة من خلال الفهرس الموجود في اسمه ، والذي يشار إليه غالبًا على الملصق:

لام (قليل) - حركة بطيئة ( حتى 2000دورة في الدقيقة) ؛
م (وسط) - معدل ( من 2000 إلى 3000دورة في الدقيقة) ؛
ح (عالي) - السرعه العاليه ( أكثر من 3000دورة في الدقيقة).

ما هي خصائص البيانات في مواصفات المصنع؟

سرعة المروحةتقاس بعدد الدورات في الدقيقة (RPM - الدورات في الدقيقة). نظرًا لأن سرعة المروحة نفسها يمكن أن تختلف تقريبًا بالتناسب المباشر مع جهد الإمداد ، فإن القيمة الواردة في المواصفات تتوافق مع جهد الإمداد الاسمي. كلما زادت سرعة الدوران ، زادت كفاءة المروحة ، ولكن أيضًا كانت الضوضاء أعلى في العادة.

تدفق الهواءيمكن تحديدها في CFM (قدم مكعب في الدقيقة ، CFM) - قدم مكعب في الدقيقة أو متر مكعب في الساعة (م 3 / ساعة). في هذه الحالة ، 1 CFM ≈ 1.7 م 3 / ساعة. تعكس هذه القيمة كمية الهواء "الذي يتم ضخه فوق" لفترة زمنية معينة ، بشرط عدم وجود مقاومة لتدفق الهواء ، أي بضغط هواء متساوٍ على جانبي المروحة. بالطبع ، كلما كانت هذه القيمة أكبر ، كان ذلك أفضل.

ضغط تدفق الهواء الثابتعادةً ما تُعطى المروحة بالملليمتر من عمود الماء وتميز قوة تدفق الهواء التي يمكن أن تولدها المروحة.

تذكر أن الضغط يتم حسابه بواسطة الصيغة P = F / S. أي أن الضغط هو نسبة قوة تدفق الهواء إلى المنطقة التي يعمل فيها. تشير المواصفات إلى الحد الأقصى لتدفق الهواء الذي تخلقه المروحة عندما يتعذر عليها إنشاء تدفق للهواء بسبب المقاومة.

يمكن رؤية خصائص المروحة بالكامل على الرسم البياني "منحنى الأداء".

يمثل منحنى الأداء العلاقة بين تدفق الهواء والضغط. النقطة العلوية من المنحنى ، الواقعة على المحور ، ليست أكثر من الحد الأقصى للضغط المعطى في المواصفات. تتوافق النقطة السفلية من المنحنى ، الواقعة على المحور الآخر ، مع الحد الأقصى لتدفق الهواء للمروحة عندما لا تضطر إلى زيادة الضغط. في الظروف الحقيقية ، وبالتحديد في هذه الحالة ، يجب أن يتغلب تدفق الهواء على بعض المقاومة. كل جسم له درجة المقاومة الخاصة به بشكل فردي. سيتم التعبير عن مقاومة النظام على أنها منحدرة على الرسم البياني ، ونقطة تقاطع الخط المستقيم والمنحنى ليست أكثر من نقطة تشغيل المروحة في نظامنا الشرطي.

مورد المعجبينتقاس بعدد الألف ساعة التي يجب أن تعمل خلالها المروحة وتوفر الخصائص المعلنة. لا يدرك مؤلف المقال تمامًا ظروف التشغيل التي يتم بموجبها تحقيق القيم المقتبسة ، نظرًا لأن عمر الخدمة يعتمد بشكل مباشر على ظروف التشغيل. من المفترض أن المروحة قادرة على العمل لعدد ساعات محدد دون أن تفقد خصائص الضوضاء. يعتمد المورد إلى حد كبير على نوع وجودة المحمل. تشير المحامل العادية عادةً إلى 30000 ساعة ومحامل مجمعة 45000 ساعة ومحامل كروية مزدوجة تبلغ 60000 ساعة أو أكثر.

في معظم الحالات ، يمكن أن تعمل المروحة الموجودة على محمل الأكمام بهدوء تام لمدة عام تقريبًا ، على الرغم من أن الشركات المصنعة تعلن رقمًا قدره 30 ألفًا.لذلك ، لا ينبغي للمرء أن يكون متحيزًا بشأن هذه الأرقام - فهي نسبية تمامًا. وإذا بحثت ، اتضح أن الشركة المصنعة تعني أيضًا الصيانة الدورية للمراوح ، أي مادة تشحيم نادرا ما ينتجها المستخدمون العاديون.

الآن دعنا نعود إلى بطل مراجعة المعجبين لدينا. اكاسا AK-183-L2Bوإلقاء نظرة على مواصفاته:

	اكاساAK-183-L2B
الحجم ، مم
سرعة الدوران ، دورة في الدقيقة
تدفق الهواء CFM
الضغط ، مم ارتفاع 20
الموارد ، ح
نوع محدد	اثنان المتداول
	3 دبوس
مستوى الضوضاء ، ديسيبل
جهد الإمداد ، V
صفحة ويب المنتجات
متوسط ​​السعر

مروحة اكاسا AK-183-L2B معبأة في كيس بلاستيكي شفاف. معبأة مع الجانب الخلفيهناك ورقة زرقاء من الورق المقوى تؤكد على العلبة الشفافة والمروحة الشفافة ذات اللون الأصفر الكهرماني للمروحة. بشكل عام ، تم تزيين كل شيء باللون الأزرق والأصفر المعتاد لمجموعة Akasa.

توجد ورقة مواصفات على الجزء الخلفي من إدراج الورق المقوى بخمس لغات مختلفة.

بالإضافة إلى المروحة ، يوجد في الجزء السفلي من العبوة صندوق صغير من الورق المقوى الأسود به نقش في الترجمة يبدو مثل "محول ذو 3-4 سنون".

لذلك ، ليس من المستغرب على الإطلاق أن يكون الصندوق يحتوي على نفس المحول الذي يسمح لك بتوصيل المروحة من موصلات الأجهزة الطرفية ، بالإضافة إلى وجود موصل ثلاثي السنون للتحكم في سرعة المروحة. أيضًا في الصندوق الأسود الصغير كان هناك أربعة مسامير لتثبيت المروحة في العلبة.

علبة المروحة akasa AK-183-L2B مصنوعة من البلاستيك الشفاف الأبيض ، ودفاعتها مصنوعة من البلاستيك الشفاف الأصفر الكهرماني. في الواقع ، إذا أخذنا في الاعتبار النطاق الكامل لمنتجات شركة akasa ، فنادراً ما تأتي عبر بعض الحلول البسيطة والقياسية ، لأن الشركة تعمل في الغالب على توزيع البضائع المصممة خصيصًا للتعديل. لكن هذا لا يعني على الإطلاق أنك إذا كنت لا تنتمي إلى طبقة المودعين وكنت معتادًا على تقييم المنتج لأسباب عملية فقط ، فلن تناسبك هذه المروحة وبقية المنتج المماثل. في الواقع ، عند تصنيع المنتجات لمن يسمونهم مستخدمين صعبين أو مودرين أو أوفرلوكرز ، فهذا يعني دائمًا زيادة الاهتمام ، أولاً وقبل كل شيء ، بجودة التصنيع وخصائصه الأعلى إلى حد ما. لذلك ، ليس من المستغرب على الإطلاق أن تكون صفات المستهلك لهذه المنتجات أعلى دائمًا من صفات المنتجات البسيطة.

ظاهريًا ، تبرز المروحة ، بالطبع ، أولاً وقبل كل شيء للمزيج الجميل من اللونين الأصفر والأبيض ، ويبدو أن مثل هذه المروحة يجب أن يكون لها ببساطة إضاءة خلفية ، لكنها في الحقيقة ليست كذلك. من وجهة نظر الديناميكية الهوائية ، لم يتم تنفيذ أي ابتكار أو معرفة فنية في المروحة - دفاعة بسيطة من سبع شفرات.

تنتمي مروحة akasa AK-183-L2B إلى طرازات منخفضة السرعة ، وسرعة دورانها المقدرة هي 1400 دورة في الدقيقة ، في حين أن أقصى تدفق للهواء يمكن أن يصل إلى 44.8 قدم مكعب في الدقيقة ، والضغط الساكن هو 1.1 ملم عمود الماء. المواصفات ليست عالية جدًا ولا عادية تمامًا ، لكن هذا ليس مفاجئًا ، لأنه بالنسبة لمحبي الهيكل في نظام منزلي ، يتم وضع متطلبات ضوضاء أعلى في المقام الأول.

وفي هذا الصدد ، تشير المواصفات إلى مستوى ضوضاء منخفض إلى حد ما يبلغ 18 ديسيبل. وتجدر الإشارة إلى أن مروحة akasa AK-183-L2B تعتمد على محملين كرويين ، وموردها وفقًا لبيانات الشركة المصنعة هو 80000 ساعة. القيمة المعتادة للمحامل الكروية هي 60.000 ساعة ، لذا فإن الزيادة الطفيفة في القيمة تعطي سببًا للأمل في نهج أفضل لتصنيعها ، لأنه كما أشرنا بالفعل ، فإن جودة تصنيع محمل الكرة هي التي تحدد خصائص ضوضاءها .

يتم تشغيل المروحة بواسطة موصل طاقة 3 سنون لا يدعم مصادر الطاقة PWM.

اختبارات

يتكون الجزء العملي من الاختبار من مرحلتين لاختبار تدفق الهواء المتولد من المروحة بالسرعة الاسمية ، بالإضافة إلى تقييم جهارة الصوت عن طريق الأذن.

رقم الاختبار 1

في الاختبار الأول ، ستعمل المروحة كعنصر نشط في مبرد Thermalright SI-128. يتم إجراء الاختبار في علبة مفتوحة ، والمعلمة الرئيسية التي يتم التحكم فيها هي درجة حرارة تسخين المعالج إلى 2.8 جيجاهرتز إنتل كور 2 Duo E6300 ودرجة حرارة اللوحة الأم.

رقم الاختبار 2

في الاختبار الثاني ، سيتم استخدام المروحة للغرض المقصود منها كمروحة هيكل مثبتة على اللوحة الخلفية وتعمل على النفخ. أثناء الاختبار ، سيتم إغلاق العلبة ولن يكون هناك أي مراوح أخرى قيد التشغيل. ستكون المعلمة الرئيسية القابلة للتحكم أيضًا هي درجة حرارة التسخين لمعالج Intel Core 2 Duo E6300 ، ولكن الآن بدون رفع تردد التشغيل ، حيث يتم تثبيت نظام التبريد السلبي Thermake Sonic Tower (CL-P0071) ودرجة حرارة اللوحة الأم. يتم تسجيل نتيجة الاختبار بعد 10 دقائق من "تشغيل" اختبار تحمل المعالج في تطبيق Everest.

يتكون تكوين اختبار النظام الأساسي لمعالج Intel من المكونات التالية:

اللوحة الأم	جيجابايت GA-965P-DS4 (Intel P965 Express)
وحدة المعالجة المركزية	Intel Core 2 Duo E6300 (LGA775 ، 1.86 جيجاهرتز ، L2 2 ميجابايت) @ 2.8 جيجاهرتز
الرامات "الذاكرة العشوائية في الهواتف والحواسيب	2 х DDR2-800 1024 ميجا بايت Apacer PC6400
بطاقة فيديو	EVGA GeForce 8600GTS 256 ميجابايت DDR3 PCI-E
HDD	سامسونج HD080HJ 80 جيجا SATA-300
محرك الأقراص الضوئية	ASUS DRW-1814BLT SATA
مزود الطاقة	مروحة Chieftec CFT-500-A12S 500W 120mm
	كوديجن M603 ميديتور

تُظهر مروحة akasa AK-183-L2B أداءً جيدًا على قدم المساواة مع المنافسين الآخرين. يمكننا تأكيد مستوى الضوضاء المنخفض نوعًا ما البالغ 18 ديسيبل فقط من خلال رأينا الشخصي. تتوافق القيمة المشار إليها تمامًا مع المستوى الحقيقي للضوضاء - بأقصى سرعة تصدر صوتًا صغيرًا.

الاستنتاجات.

مروحة akasa AK-183-L2B ليست زخرفة جميلة بشكل حصري ، كما قد يظن المشتري على الفور. يمكن أن يخلق تدفق هواء كبير إلى حد ما ، والأهم من ذلك أنه ينبعث منه ما يكفي مستوى منخفضالضوضاء. إذا أخذنا في الاعتبار تكلفتها المقبولة بالنسبة لنموذج عالي الجودة لمروحة محمل كروي ، فستكون هذه الفئة من السلع من حيث السعر / صفات المستهلك من الأفضل. دعنا نكرر أنه في مختبر الاختبار الخاص بنا ، تعمل مروحة akasa AK-183-L2B منذ أكثر من عام ، ولم تتغير خصائص الضوضاء الخاصة بها عمليًا خلال هذا الوقت.

مزايا:

• يخلق تدفق هواء كبير.
• مستوى ضوضاء منخفض
• سعر جيد / نسبة جودة المستهلك.

تشمل العيوب ما يلي:

• عدم وجود دعم PWM.

نعرب عن امتناننا لشركة PF Service LLC (Dnepropetrovsk) على المعدات المقدمة للاختبار.

تمت قراءة المقال 4669 مرة

اشترك في قنواتنا

أصبحت البرامج مفتوحة المصدر لبنة أساسية لبعض أكبر مواقع الويب. مع نمو هذه المواقع ، ظهرت أفضل الممارسات والمبادئ التوجيهية لبنيتها. يهدف هذا الفصل إلى تغطية بعض القضايا الرئيسية التي يجب مراعاتها عند تصميم مواقع الويب الكبيرة ، بالإضافة إلى بعض المكونات الأساسية المستخدمة لتحقيق تلك الأهداف.

ينصب التركيز في هذا الفصل على تحليل أنظمة الويب ، على الرغم من إمكانية استقراء بعض المواد في الأنظمة الموزعة الأخرى أيضًا.

1.1 مبادئ بناء أنظمة الويب الموزعة

ماذا يعني بالضبط إنشاء وإدارة موقع أو تطبيق قابل للتطوير؟ على المستوى البدائي ، يقوم ببساطة بتوصيل المستخدمين بالموارد البعيدة عبر الإنترنت. والموارد ، أو الوصول إلى تلك الموارد ، المنتشرة عبر خوادم متعددة ، هي الرابط الذي يجعل موقع الويب قابلاً للتوسع.

مثل معظم الأشياء في الحياة ، يمكن أن يساعدك قضاء الوقت في التخطيط المسبق لبناء خدمة الويب الخاصة بك. يمكن لفهم بعض الاعتبارات والمفاضلات وراء مواقع الويب الكبيرة أن تؤتي ثمارها في قرارات أكثر ذكاءً عند إنشاء مواقع ويب أصغر. فيما يلي بعض المبادئ الأساسية التي تؤثر على تصميم أنظمة الويب واسعة النطاق:

• التوفر:المدة الزمنية ظرف العمليعد موقع الويب أمرًا بالغ الأهمية لسمعة العديد من الشركات ووظائفها. بالنسبة لبعض أكبر متاجر البيع بالتجزئة عبر الإنترنت ، فإن عدم توفرها حتى لبضع دقائق يمكن أن يؤدي إلى خسارة آلاف أو ملايين الدولارات. وبالتالي ، فإن تطوير أنظمتها المتاحة دائمًا والمرنة للفشل هو أيضًا مطلب أساسي للأعمال والتكنولوجيا. يتطلب التوافر العالي في الأنظمة الموزعة دراسة متأنية للتكرار للمكونات الرئيسية ، والتعافي السريع من حالات فشل النظام الجزئي ، وتقليص الحجم بشكل سلس عند ظهور المشاكل.
• أداء:أصبح أداء موقع الويب مقياسًا مهمًا لمعظم المواقع. تؤثر سرعة موقع الويب على تجربة المستخدم ورضاه ، بالإضافة إلى تصنيفات محرك البحث - وهو عامل يؤثر بشكل مباشر على الاحتفاظ بالجمهور والأرباح. ونتيجة لذلك ، فإن المفتاح هو إنشاء نظام مُحسَّن للاستجابات السريعة وزمن انتقال منخفض.
• مصداقية:يجب أن يكون النظام قويًا بحيث أن طلبًا محددًا للبيانات سيعيد باستمرار بيانات محددة. في حالة تغيير البيانات أو تحديثها ، يجب أن يُرجع الاستعلام نفسه بيانات جديدة. يحتاج المستخدمون إلى معرفة ما إذا كان هناك شيء مكتوب على النظام أو مخزن فيه ، ثم يمكنهم التأكد من أنه سيظل في مكانه لإمكانية استرجاع البيانات لاحقًا.
• قابلية التوسع:عندما يتعلق الأمر بأي نظام موزع كبير ، فإن الحجم هو مجرد واحد من العديد من الأشياء التي يجب مراعاتها. لا تقل أهمية عن الجهود المبذولة لزيادة الإنتاجية للتعامل مع كميات كبيرة من أعباء العمل ، والتي يشار إليها عادةً بقابلية تطوير النظام. يمكن أن تشير قابلية التوسع إلى معلمات مختلفة للنظام: مقدار حركة المرور الإضافية التي يمكنه التعامل معها ، أو مدى سهولة زيادة سعة التخزين ، أو مقدار المزيد من المعاملات الأخرى التي يمكن معالجتها.
• السيطرة:يعد تصميم نظام سهل التشغيل عاملاً مهمًا آخر. تتساوى إمكانية إدارة النظام مع قابلية توسيع العمليات "الصيانة" و "التحديثات". لضمان سهولة الإدارة ، من الضروري النظر في مسائل سهولة التشخيص وفهم المشكلات الناشئة ، وسهولة التحديث أو التعديل ، والنظام غريب الأطوار قيد التشغيل (بمعنى ، هل يعمل بالشكل المتوقع دون إخفاقات أو استثناءات؟)
• سعر:التكلفة عامل مهم. من الواضح أن هذا يمكن أن يشمل تكاليف الأجهزة والبرامج ، ولكن من المهم أيضًا مراعاة الجوانب الأخرى المطلوبة لنشر النظام وصيانته. يجب توقع مقدار الوقت الذي يستغرقه المطور لبناء النظام ، ومقدار الجهد التشغيلي المطلوب لتشغيل النظام ، وحتى مستوى كافٍ من التدريب. التكلفة هي التكلفة الإجمالية للملكية.

كل من هذه المبادئ هو الأساس لاتخاذ القرار في تصميم بنية الويب الموزعة. ومع ذلك ، يمكن أن تتعارض أيضًا مع بعضها البعض لأن تحقيق أهداف أحدهم يأتي على حساب إهمال الآخرين. مثال بسيط: اختيار إضافة خوادم متعددة كحل للأداء (قابلية التوسع) يمكن أن يزيد من تكاليف الإدارة (عليك تشغيل خادم إضافي) ومشتريات الخادم.

عند تطوير أي نوع من تطبيقات الويب ، من المهم مراعاة هذه المبادئ الأساسية ، حتى لو كان ذلك لتأكيد أن المشروع يمكنه التبرع بواحد أو أكثر منها.

1.2 الأساسيات

عند التفكير في بنية النظام ، هناك العديد من المشكلات التي يجب تسليط الضوء عليها ، مثل المكونات التي تستحق الاستخدام ، وكيف تتلاءم معًا ، وما هي المقايضات التي يمكن إجراؤها. لا يمكن اعتبار استثمار الأموال في التوسع دون الحاجة الواضحة لذلك قرارًا تجاريًا ذكيًا. ومع ذلك ، فإن بعض التبصر في التخطيط يمكن أن يوفر بشكل كبير الوقت والموارد في المستقبل.

يركز هذا القسم على بعض العوامل الأساسية التي تعتبر بالغة الأهمية لجميع تطبيقات الويب الكبيرة تقريبًا: خدمات,
وفرة, تجزئة، و التعامل مع الرفض... يتضمن كل عامل من هذه العوامل اختيارات ومقايضات ، خاصة في سياق المبادئ الموضحة في القسم السابق. دعنا نعطي مثالا للتوضيح.

مثال: تطبيق استضافة الصور

ربما تكون قد نشرت صورًا على الويب من قبل. بالنسبة للمواقع الكبيرة التي تخزن وتقدم صورًا متعددة ، هناك تحديات في إنشاء بنية فعالة من حيث التكلفة وموثوقة للغاية تتميز بزمن استجابة منخفض (استرداد سريع).

تخيل نظامًا حيث يمكن للمستخدمين تحميل صورهم إلى خادم مركزي ويمكن طلب الصور من خلال رابط موقع أو واجهة برمجة تطبيقات ، على غرار Flickr أو Picasa. لتبسيط الوصف ، لنفترض أن هذا التطبيق له مهمتان رئيسيتان: القدرة على تحميل (كتابة) الصور على الخادم وطلب الصور. بالطبع ، يعد التحميل الفعال أمرًا مهمًا ، ولكن سيكون التسليم السريع أولوية عند طلب المستخدمين (على سبيل المثال ، قد يُطلب عرض الصور على صفحة ويب أو تطبيق آخر). تشبه هذه الوظيفة ما يمكن أن يوفره خادم الويب أو خادم حافة شبكة توصيل المحتوى (CDN). عادةً ما يخزن خادم CDN كائنات البيانات في العديد من المواقع ، بحيث يكون موقعها الجغرافي / المادي أقرب إلى المستخدمين ، مما يؤدي إلى أداء أفضل.

جوانب أخرى مهمة للنظام:

• يمكن أن يكون عدد الصور المخزنة غير محدود ، لذا يجب مراعاة قابلية التوسع في التخزين من وجهة النظر هذه.
• يجب أن يكون هناك وقت استجابة منخفض لتنزيلات / طلبات الصور.
• إذا قام المستخدم بتحميل صورة إلى الخادم ، فيجب أن تظل بياناته دائمًا كاملة ويمكن الوصول إليها.
• يجب أن يكون النظام سهل الصيانة (قابلية للإدارة).
• نظرًا لأن استضافة الصور ليست مربحة جدًا ، يجب أن يكون النظام فعالاً من حيث التكلفة.

هناك مشكلة أخرى محتملة في هذا التصميم وهي أن خادم الويب مثل Apache أو lighttpd عادة ما يكون له حد أعلى لعدد الاتصالات المتزامنة التي يمكنه التعامل معها (الافتراضي هو حوالي 500 ، ولكن يمكن أن يكون أعلى بكثير). ومع حركة المرور العالية ، يكتب يمكن أن تستهلك بسرعة ما يصل إلى هذا الحد. نظرًا لأن القراءات يمكن أن تكون غير متزامنة ، أو تستفيد من تحسينات الأداء الأخرى مثل ضغط gzip أو التقسيم ، يمكن لخادم الويب تبديل القراءات بشكل أسرع والتبديل بين العملاء ، وتقديم طلبات أكثر من أقصى عدداتصالات (مع Apache والحد الأقصى لعدد الاتصالات المحددة عند 500 ، من الممكن تمامًا خدمة عدة آلاف من طلبات القراءة في الثانية). من ناحية أخرى ، تميل الإدخالات إلى الحفاظ على اتصال مفتوح طوال وقت التنزيل بالكامل. على سبيل المثال ، قد يستغرق نقل ملف 1 ميجا بايت إلى الخادم أكثر من ثانية واحدة على معظم الشبكات المنزلية ، مما يؤدي إلى أن خادم الويب سيكون قادرًا فقط على معالجة 500 من هذه الكتابات المتزامنة.

الشكل 1.2: فصل القراءة والكتابة

يشير توقع هذه المشكلة المحتملة إلى أن هناك حاجة لفصل قراءة الصور وكتابتها إلى الخدمات المستقلة الموضحة في. سيسمح هذا ليس فقط بتوسيع نطاق كل منها على حدة (حيث من المحتمل أننا سنقوم دائمًا بقراءات أكثر من الكتابة) ، ولكن أيضًا لمواكبة ما يحدث في كل خدمة. أخيرًا ، سيحدد المشكلات المستقبلية ، مما يسهل تشخيص وتقييم مشكلات الوصول للقراءة البطيئة.

ميزة هذا النهج هي أننا قادرون على حل المشكلات بشكل مستقل عن بعضنا البعض - دون الحاجة إلى التفكير في الحاجة إلى تسجيل والحصول على صور جديدة في نفس السياق. لا تزال كلتا الخدمتين تستخدمان مجموعة الصور العالمية ، ولكن عند استخدام الأساليب المناسبة لخدمة معينة ، فإنهما قادران على تحسين أدائهما (على سبيل المثال ، عن طريق وضع الطلبات في قائمة الانتظار ، أو تخزين الصور الشائعة في ذاكرة التخزين المؤقت - المزيد حول ذلك لاحقًا). من حيث الصيانة والتكلفة ، يمكن توسيع نطاق كل خدمة بشكل مستقل حسب الحاجة. وهذا عامل إيجابي ، حيث إن دمجها وخلطها قد يؤثر بشكل غير مقصود على أدائها كما في السيناريو الموصوف أعلاه.

بالطبع ، سيعمل النموذج أعلاه بشكل أفضل إذا كان لديك نقطتا نهاية مختلفتان (في الواقع ، هذا مشابه جدًا للعديد من تطبيقات موفري التخزين السحابي وشبكات توصيل المحتوى). هناك طرق عديدة لحل هذه المشاكل ، وفي كل حالة يمكن إيجاد حل وسط.

على سبيل المثال ، يحل Flickr مشكلة القراءة والكتابة هذه عن طريق توزيع المستخدمين على وحدات مختلفة بحيث يمكن لكل وحدة أن تخدم فقط عددًا محدودًا من المستخدمين المحددين ، ومع زيادة عدد المستخدمين ، تتم إضافة المزيد من الوحدات إلى المجموعة (انظر عرض مقياس Flickr .
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). في المثال الأول ، من الأسهل قياس الأجهزة استنادًا إلى حمل الاستخدام الفعلي (عدد عمليات القراءة والكتابة عبر النظام بأكمله) ، بينما يتم إجراء قياس Flickr بناءً على قاعدة المستخدمين (ومع ذلك ، يفترض هذا الاستخدام المتساوي عبر مستخدمين مختلفين ، لذلك السعة يحتاج إلى التخطيط مع الاحتياطي). في الماضي ، أدى عدم توفر أو وجود مشكلة في إحدى الخدمات إلى جعل وظيفة النظام بأكمله غير قابلة للتشغيل (على سبيل المثال ، لا يمكن لأحد كتابة الملفات) ، وبالتالي فإن عدم توفر إحدى وحدات Flickr النمطية سيؤثر فقط على المستخدمين المرتبطين بها. في المثال الأول ، يكون من الأسهل إجراء عمليات على مجموعة بيانات كاملة - على سبيل المثال ، تحديث خدمة الكاتب لتضمين بيانات وصفية جديدة ، أو البحث في جميع البيانات الوصفية للصور - بينما مع بنية Flickr ، يجب تحديث كل وحدة أو البحث عنها (أو يجب إنشاء خدمة البحث لفرز البيانات الوصفية المخصصة بالفعل لهذا).

بالنسبة لهذه الأنظمة ، لا يوجد علاج شامل ، ولكن يجب دائمًا المضي قدمًا من المبادئ الموضحة في بداية هذا الفصل: تحديد احتياجات النظام (تحميل مع عمليات "قراءة" أو "كتابة" أو الكل مرة واحدة ، مستوى التوازي ، والاستفسارات حول مجموعات البيانات ، والنطاقات ، والتجارب ، وما إلى ذلك) ، وإجراء مقارنة معيارية للبدائل المختلفة ، وفهم شروط فشل النظام المحتمل ، وتطوير خطة فشل شاملة.

وفرة

للتعامل مع الفشل بأناقة ، يجب أن تحتوي بنية الويب على التكرار في خدماتها وبياناتها. على سبيل المثال ، إذا كانت هناك نسخة واحدة فقط من الملف المخزن على خادم واحد ، فإن فقدان هذا الخادم يعني فقدان الملف أيضًا. من غير المحتمل أن يتم تمييز هذا الموقف بشكل إيجابي ، وعادة ما يمكن تجنبه عن طريق إنشاء نسخ أو نسخ احتياطية متعددة.

ينطبق هذا المبدأ نفسه على الخدمات. يمكنك الحماية من فشل العقدة المفردة من خلال توفير جزء لا يتجزأ من وظائف التطبيق لضمان تشغيل نسخ أو إصدارات متعددة من التطبيق بشكل متزامن.

يتيح لك إنشاء التكرار في النظام التخلص من نقاط الضعفوتوفير وظائف احتياطية أو زائدة عن الحاجة في حالة الطوارئ. على سبيل المثال ، إذا كانت هناك حالتان من نفس الخدمة قيد التشغيل في "الإنتاج" ، وفشل أحدهما كليًا أو جزئيًا ، يمكن للنظام التغلب على الفشل على حساب التحول إلى نسخة صالحة للاستعمال.
يمكن أن يحدث التبديل تلقائيًا أو يتطلب تدخلاً يدويًا.

دور رئيسي آخر لتكرار الخدمة هو الخلق العمارة غير المشتركة... مع هذه البنية ، تكون كل عقدة قادرة على العمل بشكل مستقل ، علاوة على ذلك ، في غياب "دماغ" مركزي يتحكم في الحالات أو ينسق إجراءات العقد الأخرى. يعزز قابلية التوسع لأن إضافة عقد جديدة لا تتطلب شروطًا أو معرفة خاصة. والأهم من ذلك ، أنه لا توجد نقطة حرجة للفشل في هذه الأنظمة ، مما يجعلها أكثر مرونة بكثير في مواجهة الفشل.

على سبيل المثال ، في تطبيق خادم الصور الخاص بنا ، سيكون لجميع الصور نسخ زائدة عن الحاجة في مكان آخر في الجهاز (من الناحية المثالية مع موقع جغرافي مختلف في حالة وقوع كارثة مثل الزلزال أو حريق مركز البيانات) ، وستكون خدمات الوصول إلى الصور زائدة عن الحاجة ، مع كل منهم يحتمل أن يخدم الطلبات. (سم. .)
بالنظر إلى المستقبل ، تعتبر موازين التحميل طريقة رائعة لجعل ذلك ممكنًا ، ولكن المزيد عن ذلك أدناه.

الشكل 1.3: تطبيق استضافة الصور الزائدة عن الحاجة

تجزئة

يمكن أن تكون مجموعات البيانات كبيرة جدًا بحيث لا يمكن استيعابها على خادم واحد. قد يحدث أيضًا أن العمليات الحسابية تستهلك الكثير من موارد الكمبيوتر ، مما يقلل من الأداء ويستلزم زيادة الطاقة. على أي حال ، لديك خياران: القياس الرأسي أو الأفقي.

التوسع يعني إضافة المزيد من الموارد إلى خادم واحد. لذلك ، بالنسبة لمجموعة البيانات الكبيرة جدًا ، قد يعني هذا إضافة المزيد (أو أكثر) من محركات الأقراص الثابتة ، وبالتالي يمكن أن تتلاءم مجموعة البيانات بأكملها على خادم واحد. في حالة العمليات الحسابية ، قد يعني ذلك نقل الحساب إلى خادم أكبر مزود بوحدة معالجة مركزية أسرع أو ذاكرة أكبر. في أي حال ، يتم إجراء القياس الرأسي من أجل جعل مورد منفصل لنظام الحوسبة قادرًا على معالجة البيانات الإضافية.

من ناحية أخرى ، يتضمن التحجيم الأفقي إضافة المزيد من العقد. في حالة مجموعة البيانات الكبيرة ، قد يعني هذا إضافة خادم ثانٍ لتخزين جزء من حجم البيانات بالكامل ، وبالنسبة لمورد حسابي ، فإن هذا يعني تقسيم العمل أو التحميل من خلال بعض العقد الإضافية. للاستفادة الكاملة من إمكانات التوسع ، يجب تنفيذها كمبدأ تصميم داخلي لبنية النظام. خلاف ذلك ، فإن تغيير وإبراز السياق المطلوب للقياس الأفقي يمكن أن يكون مشكلة.

الطريقة الأكثر شيوعًا للتوسع هي تقسيم الخدمات إلى أجزاء أو وحدات. يمكن توزيعها بطريقة تجعل كل مجموعة منطقية من الوظائف تعمل بشكل منفصل. يمكن القيام بذلك عن طريق الحدود الجغرافية ، أو معايير أخرى مثل المستخدمين الذين يدفعون والذين لا يدفعون. ميزة هذه المخططات هي أنها توفر خدمة أو مخزن بيانات بوظائف محسنة.

في مثال خادم الصور الخاص بنا ، من الممكن أن يتم استبدال خادم الملف الفردي المستخدم لتخزين الصورة بخوادم ملفات متعددة ، يحتوي كل منها على مجموعته الفريدة من الصور. (انظر) ستسمح هذه البنية للنظام بملء كل خادم ملفات بالصور ، وإضافة خوادم إضافية عند ملئه مساحة القرص... سيتطلب التصميم نظام تسمية يربط اسم ملف الصورة بالخادم المحتوي. يمكن إنشاء اسم الصورة من مخطط تجزئة متسق مرتبط بالخوادم. أو بدلاً من ذلك ، يمكن أن تحتوي كل صورة على معرّف تزايدي ، مما سيسمح لخدمة التوصيل بمعالجة نطاق المعرفات المرتبط بكل خادم فقط (كفهرس) عند طلب صورة.

الشكل 1.4: تطبيق استضافة الصور مع التكرار والتجزئة

بالطبع ، هناك صعوبات في توزيع البيانات أو الوظائف عبر خوادم متعددة. أحد الأسئلة الرئيسية - موقع البيانات؛ في الأنظمة الموزعة ، كلما كانت البيانات أقرب إلى موقع العمليات أو نقطة الحساب ، كان أداء النظام أفضل. وبالتالي ، فإن توزيع البيانات عبر خوادم متعددة قد يمثل مشكلة ، نظرًا لأنه في أي وقت قد تكون هناك حاجة إلى هذه البيانات ، هناك خطر من أنها قد لا تكون متاحة في مكان الطلب ، وسيتعين على الخادم إجراء أخذ عينات مكلفة من المعلومات الضرورية عبر شبكة الاتصال.

مشكلة أخرى محتملة تنشأ في النموذج
تناقض (تناقض)عندما تقرأ خدمات مختلفة وتكتب على مورد مشترك ، أو خدمة أخرى أو مخزن بيانات ، فهناك احتمال لظروف السباق - حيث تعتبر بعض البيانات محدثة لحالتها الحالية ، ولكن في الواقع تتم قراءتها قبل تحديثها - في هذه الحالة البيانات غير متسقة. على سبيل المثال ، في سيناريو استضافة الصور ، يمكن أن تحدث حالة سباق إذا أرسل أحد العملاء طلبًا لتحديث صورة الكلب ، وتغيير العنوان "Dog" إلى "Gizmo" ، بينما كان عميل آخر يقرأ الصورة. في مثل هذه الحالة ، ليس من الواضح أي لقب ، "Dog" أو "Gizmo" ، كان سيحصل عليه العميل الثاني.

هناك ، بالطبع ، بعض العوائق المرتبطة بتجزئة البيانات ، لكن التجزئة تسمح لك بتمييز كل مشكلة عن المشكلات الأخرى: حسب البيانات ، والحمل ، وأنماط الاستخدام ، وما إلى ذلك. إلى كتل خاضعة للرقابة. يمكن أن يساعد هذا في قابلية التوسع والإدارة ، ولكن المخاطر لا تزال قائمة. هناك العديد من الطرق لتخفيف المخاطر والتعامل مع الاضطراب ؛ ومع ذلك ، من أجل الإيجاز ، لم يتم تناولها في هذا الفصل. إذا كنت تريد مزيدًا من المعلومات حول هذا الموضوع ، فيجب عليك إلقاء نظرة على منشور المدونة الخاص بالتسامح مع الخطأ ومراقبته.

1.3 المكونات الهيكلية للوصول السريع والقابل إلى البيانات

بعد تغطية بعض المبادئ الأساسية في تطوير الأنظمة الموزعة ، دعنا ننتقل الآن إلى النقطة الأكثر صعوبة - توسيع نطاق الوصول إلى البيانات.

تتشابه معظم تطبيقات الويب الأساسية ، مثل تطبيقات LAMP stack ، مع الصورة الموجودة في.

الشكل 1.5: تطبيقات الويب البسيطة

مع نمو التطبيق ، يظهر تحديان رئيسيان: توسيع نطاق الوصول إلى خادم التطبيق وقاعدة البيانات. في تصميم تطبيق قابل للتوسع بدرجة كبيرة ، عادةً ما يتم تصغير خادم الويب أو خادم التطبيق وغالبًا ما يتم تنفيذ بنية لا تشارك الموارد. هذا يجعل طبقة خادم التطبيق الخاصة بالنظام قابلة للتوسع. نتيجة لهذا التصميم ، سينتقل العمل الجاد إلى أسفل المكدس إلى خادم قاعدة البيانات والخدمات الداعمة ؛ هذا هو المكان الذي تدخل فيه مشكلات القياس والأداء الحقيقية.

يركز الجزء المتبقي من هذا الفصل على بعض الاستراتيجيات والتقنيات الأكثر شيوعًا لتحسين الأداء وقابلية التوسع لهذه الأنواع من الخدمات من خلال توفير وصول سريع إلى البيانات.

الشكل 1.6: تطبيق ويب مبسط

يمكن تبسيط معظم الأنظمة إلى رسم تخطيطي ،
وهي نقطة انطلاق جيدة للبدء في التفكير فيها. إذا كان لديك الكثير من البيانات ، فيمكنك افتراض أنك تريد أن يكون الوصول إليها سهلاً وسريعًا مثل صندوق الحلوى في الدرج العلوي من مكتبك. في حين أن هذه المقارنة مفرطة في التبسيط ، إلا أنها تشير إلى مشكلتين صعبتين: قابلية التوسع في مستودع البيانات والوصول السريع إلى البيانات.

بالنسبة لهذا القسم ، لنفترض أن لديك الكثير من تيرابايت (TB) من البيانات ، وأنك تسمح للمستخدمين بالوصول إلى أجزاء صغيرة من تلك البيانات دون ترتيب معين. (سم. .)
مهمة مماثلة هي تحديد موقع ملف الصورة في مكان ما على خادم الملفات في نموذج تطبيق استضافة الصور.

الشكل 1.7: الوصول إلى بيانات محددة

هذا صعب بشكل خاص لأن تحميل تيرابايت من البيانات في الذاكرة يمكن أن يكون مكلفًا للغاية ويؤثر بشكل مباشر على عدد عمليات الإدخال / الإخراج على القرص. سرعة القراءة من القرص أقل بعدة مرات من سرعة القراءة من ذاكرة الوصول العشوائي - يمكننا القول أن الوصول إلى الذاكرة يكون بنفس سرعة تشاك نوريس ، في حين أن الوصول إلى القرص يكون أبطأ من قائمة الانتظار في العيادة. هذا الاختلاف في السرعة ملحوظ بشكل خاص لمجموعات البيانات الكبيرة ؛ في الأرقام الجافة ، يكون الوصول إلى الذاكرة أسرع 6 مرات من قراءات القرص للقراءات المتسلسلة ، وأسرع 100000 مرة للقراءات العشوائية (انظر Pathology of Big Data، http://queue.acm.org/detail. cfm؟ id = 1563874). ). بالإضافة إلى ذلك ، حتى مع المعرفات الفريدة ، يمكن أن يكون حل مشكلة تحديد موقع جزء صغير من البيانات أمرًا صعبًا مثل سحب آخر حلوى مملوءة بالشوكولاتة من علبة بها مئات الحلوى الأخرى دون النظر.

لحسن الحظ ، هناك العديد من الأساليب التي يمكنك اتباعها لتبسيط الأمور ، ومن أهمها: ذاكرات التخزين المؤقت ، والوكلاء ، والفهارس ، وموازنات التحميل. يناقش الجزء المتبقي من هذا القسم كيف يمكن استخدام كل من هذه المفاهيم لجعل الوصول إلى البيانات أسرع بكثير.

مخابئ

يستفيد التخزين المؤقت من مبدأ أساسي يفيد بأنه من المحتمل أن تكون البيانات المطلوبة مؤخرًا مطلوبة مرة أخرى. تُستخدم ذاكرات التخزين المؤقت في كل طبقة من طبقات الحوسبة تقريبًا: الأجهزة وأنظمة التشغيل ومتصفحات الويب وتطبيقات الويب والمزيد. تشبه ذاكرة التخزين المؤقت الذاكرة قصيرة المدى: محدودة الحجم ، ولكنها أسرع من مصدر البيانات الأصلي ، وتحتوي على عناصر تم الوصول إليها مؤخرًا. يمكن أن توجد ذاكرات التخزين المؤقت على جميع المستويات في البنية ، ولكن غالبًا ما تكون في أقرب مستوى من الواجهة الأمامية ، حيث يتم تنفيذها لإرجاع البيانات بسرعة دون تحميل كبير للجهة الخلفية.

فكيف يمكن استخدام ذاكرة التخزين المؤقت لتسريع الوصول إلى البيانات ضمن نموذج API الخاص بنا؟ في هذه الحالة ، هناك العديد من مواقع التخزين المؤقت المناسبة. كواحد من الخيارات الممكنةالتنسيب ، يمكنك تحديد العقد على مستوى الاستعلام كما هو موضح في
.

الشكل 1.8: وضع ذاكرة تخزين مؤقت على عقدة مستوى الاستعلام

يسمح وضع ذاكرة تخزين مؤقت مباشرة على عقدة على مستوى الاستعلام التخزين المحليبيانات الاستجابة. في كل مرة يتم فيها تقديم طلب خدمة ، سيعيد المضيف بسرعة البيانات المحلية المخزنة مؤقتًا ، إن وجدت. إذا لم تكن موجودة في ذاكرة التخزين المؤقت ، فستطلب عقدة الطلب البيانات من القرص. يمكن أيضًا وضع ذاكرة التخزين المؤقت على عقدة واحدة من مستوى الاستعلام في الذاكرة (وهي سريعة جدًا) وعلى القرص المحلي للعقدة (أسرع من محاولة الوصول إلى NAS).

الشكل 1.9: أنظمة التخزين المؤقت

ماذا يحدث عند نشر التخزين المؤقت لعقد متعددة؟ كما ترى ، إذا كانت طبقة الاستعلام ستتضمن العديد من العقد ، فمن المحتمل أن يكون لكل عقدة ذاكرة تخزين مؤقت خاصة بها. ومع ذلك ، إذا قام موازن التحميل الخاص بك بتوزيع الطلبات بشكل عشوائي بين العقد ، فسيذهب نفس الطلب إلى عقد مختلفة ، مما يؤدي إلى زيادة حالات فشل ذاكرة التخزين المؤقت. ذاكرة التخزين المؤقت العالمية والموزعة طريقتان للتغلب على هذه العقبة.

ذاكرة التخزين المؤقت العالمية

معنى ذاكرة التخزين المؤقت العامة واضح من الاسم: تستخدم جميع العقد مساحة تخزين مؤقت واحدة. في هذه الحالة ، تتم إضافة خادم أو مخزن ملفات من نوع ما يكون أسرع من متجرك الأصلي وسيكون متاحًا لجميع العقد على مستوى الاستعلام. تطلب كل عقد من عقد الطلب ذاكرة التخزين المؤقت بنفس الطريقة كما لو كانت محلية. يمكن أن يتسبب هذا النوع من نظام التخزين المؤقت في حدوث بعض الارتباك ، حيث من السهل جدًا زيادة التحميل على ذاكرة تخزين مؤقت واحدة مع زيادة عدد العملاء والطلبات. في الوقت نفسه ، يكون مثل هذا المخطط فعالًا جدًا لبعض البنى (خاصة عندما يتعلق الأمر بالأجهزة المتخصصة التي تجعل ذاكرة التخزين المؤقت العالمية سريعة جدًا ، أو التي تحتوي على مجموعة ثابتة من البيانات التي يجب تخزينها مؤقتًا).

هناك نوعان قياسيان من ذاكرات التخزين المؤقت العالمية ، موضحة في الرسوم البيانية. يتم تصوير الموقف عندما لا يتم العثور على استجابة مخزنة مؤقتًا في ذاكرة التخزين المؤقت ، تصبح ذاكرة التخزين المؤقت نفسها مسؤولة عن تلقي الجزء المفقود من البيانات من وحدة التخزين الأساسية. يوضح مسؤولية عقد الطلب لاسترداد أي بيانات غير موجودة في ذاكرة التخزين المؤقت.

الشكل 1.10: ذاكرة التخزين المؤقت العالمية ، حيث تكون ذاكرة التخزين المؤقت مسؤولة عن الجلب

الشكل 1.11: ذاكرة التخزين المؤقت العالمية حيث تكون عقد الطلب مسؤولة عن الاسترداد

تميل معظم تطبيقات تقوية ذاكرة التخزين المؤقت العالمية إلى استخدام النوع الأول ، حيث تدير ذاكرة التخزين المؤقت نفسها استبدال البيانات وجلبها لمنع العملاء من إغراق الطلبات لنفس البيانات. ومع ذلك ، هناك بعض الحالات التي يكون فيها التنفيذ الثاني أكثر منطقية. على سبيل المثال ، إذا تم استخدام ذاكرة التخزين المؤقت لملف ملفات كبيرة، سيؤدي معدل إصابة ذاكرة التخزين المؤقت المنخفض إلى زيادة تحميل ذاكرة التخزين المؤقت مع عدد مرات الوصول إلى ذاكرة التخزين المؤقت الفاشلة ؛ في هذه الحالة ، من المفيد وجود نسبة كبيرة من إجمالي مجموعة البيانات (أو مجموعة البيانات الساخنة) في ذاكرة التخزين المؤقت. مثال آخر هو بنية حيث تكون الملفات المخزنة في ذاكرة التخزين المؤقت ثابتة ولا يجب حذفها. (قد يكون هذا بسبب خصائص الأداء الأساسية لوقت الاستجابة هذا - ربما يلزم أن تكون أجزاء معينة من البيانات سريعة جدًا لمجموعات البيانات الكبيرة - عندما يفهم منطق التطبيق استراتيجية الاستبدال أو النقاط الفعالة بشكل أفضل من ذاكرة التخزين المؤقت.)

ذاكرة التخزين المؤقت الموزعة

غالبًا ما يتم تخزين هذه الفهارس في الذاكرة أو في مكان ما محلي جدًا لطلب العميل الوارد. تعتبر Berkeley DB (BDB) وهياكل البيانات الشجرية ، والتي تُستخدم عادة لتخزين البيانات في قوائم مرتبة ، مثالية للوصول المفهرس.

غالبًا ما يكون هناك العديد من مستويات الفهارس التي تعمل كخريطة ، وتنقلك من موقع إلى آخر ، وهكذا ، حتى تحصل على قطعة البيانات التي تريدها. (سم. )

الشكل 1.17: فهارس متعددة المستويات

يمكن أيضًا استخدام الفهارس لإنشاء عدة طرق عرض أخرى لنفس البيانات. بالنسبة لمجموعات البيانات الكبيرة ، تعد هذه طريقة رائعة لتحديد عوامل التصفية وطرق العرض المختلفة دون الحاجة إلى إنشاء العديد من النسخ الإضافية من البيانات.

على سبيل المثال ، لنفترض أن نظام استضافة الصور المذكور أعلاه يستضيف فعليًا صورًا لصفحات الكتب ، وتتيح الخدمة استعلامات العميل على النص الموجود في تلك الصور ، والبحث عن كل المحتوى النصي في موضوع معين ، تمامًا كما تسمح لك محركات البحث بالبحث عن HTML . المحتوى. في هذه الحالة ، تستخدم جميع صور الكتاب هذه الكثير من الخوادم لتخزين الملفات ، وقد يكون العثور على صفحة واحدة لتقديمها للمستخدم أمرًا صعبًا للغاية. في البداية ، يجب أن تكون الفهارس العكسية للاستعلام عن الكلمات ومجموعات الكلمات التعسفية متاحة بسهولة ؛ ثم هناك مهمة التنقل إلى الصفحة المحددة والمكان في ذلك الكتاب واستخراج الصورة الصحيحة لنتائج البحث. وبالتالي ، في هذه الحالة ، سيتم تعيين الفهرس المقلوب إلى موقع (مثل الكتاب B) ، ومن ثم يمكن أن يحتوي B على فهرس بكل الكلمات والمواقع وعدد التكرارات في كل جزء.

سيبدو الفهرس المقلوب الذي يمكن أن يعرضه الفهرس 1 في الرسم البياني أعلاه كما يلي: تعمل كل كلمة أو مجموعة كلمات كفهرس للكتب التي تحتوي عليها.

سيبدو الفهرس الوسيط مشابهًا ، ولكنه سيحتوي فقط على الكلمات والموقع والمعلومات الخاصة بالكتاب ب. تسمح هذه البنية متعددة الطبقات لكل من الفهارس بأن يشغل مساحة أقل مما لو تم تخزين جميع هذه المعلومات في فهرس واحد كبير مقلوب .

وهذه نقطة أساسية في الأنظمة واسعة النطاق ، لأنه حتى عند ضغطها ، يمكن أن تكون هذه الفهارس كبيرة جدًا ومكلفة للتخزين. لنفترض أن لدينا العديد من الكتب من جميع أنحاء العالم على هذا النظام - 100،000،000 (انظر منشور المدونة "داخل كتب Google") - وأن كل كتاب يتكون من 10 صفحات فقط (لتبسيط العمليات الحسابية) مع 250 كلمة لكل صفحة: هذا يعطينا إجمالي 250 مليار كلمة. إذا أخذنا متوسط ​​عدد الأحرف في كلمة ما على أنه 5 ، وقمنا بترميز كل حرف في 8 بت (أو 1 بايت ، على الرغم من أن بعض الأحرف تأخذ 2 بايت بالفعل) ، وبالتالي إنفاق 5 بايت لكل كلمة ، فإن الفهرس يحتوي على كل كلمة فقط مرة واحدة سيتطلب أكثر من 1 تيرابايت من التخزين. لذلك يمكنك أن ترى أن الفهارس التي تحتوي على معلومات أخرى ، مثل مجموعات الكلمات ، ومواقع البيانات ، وتعداد الاستخدام ، يمكن أن تنمو في الحجم بسرعة كبيرة.

يؤدي إنشاء هذه الفهارس الوسيطة وتقديم البيانات في أجزاء أصغر إلى تسهيل حل مشكلة البيانات الضخمة. يمكن توزيع البيانات عبر خوادم متعددة وفي نفس الوقت تكون متاحة بسرعة. الفهارس هي حجر الزاوية لاسترجاع المعلومات والأساس لمحركات البحث الحديثة اليوم. بالطبع ، هذا القسم عام فقط حول موضوع الفهرسة ، وقد تم إجراء الكثير من الأبحاث حول كيفية جعل الفهارس أصغر وأسرع وتحتوي على مزيد من المعلومات (مثل الصلة) وتحديثها بسلاسة. (هناك بعض المشكلات المتعلقة بإمكانية إدارة المصطلحات المتنافسة وعدد التحديثات المطلوبة لإضافة بيانات جديدة أو تغيير البيانات الحالية ، خاصةً عندما يتعلق الأمر بالملاءمة أو تسجيل النقاط.)

من الضروري أن تكون قادرًا على العثور على بياناتك بسرعة وسهولة ، والفهارس هي الأداة الأبسط والأكثر فاعلية لتحقيق ذلك.

موازين التحميل

أخيرًا ، جزء مهم آخر من أي نظام موزع هو موازن التحميل. تعتبر موازنات التحميل جزءًا أساسيًا من أي بنية لأن دورها هو توزيع الحمل بين العقد المسؤولة عن خدمة الطلبات. يتيح ذلك للعقد المتعددة أداء الوظيفة نفسها في النظام بشفافية. (انظر) الغرض الرئيسي منها هو التعامل مع العديد من الاتصالات المتزامنة وتوجيه تلك الاتصالات إلى إحدى العقد المطلوبة ، مما يسمح للنظام بالتوسع عن طريق إضافة العقد ببساطة لخدمة المزيد من الطلبات.

الشكل 1.18: موازن التحميل

هناك العديد من الخوارزميات المختلفة لخدمة الطلبات ، بما في ذلك اختيار العقدة العشوائي ، أو جولة روبن ، أو حتى اختيار العقدة بناءً على معايير معينة مثل استخدام وحدة المعالجة المركزية أو ذاكرة الوصول العشوائي. يمكن تنفيذ موازنات التحميل كأجهزة أو برامج. بين موازين التحميل على البرمجياتالمصدر المفتوح ، HAProxy هو الأكثر استخدامًا.

في النظام الموزع ، غالبًا ما تكون موازنات التحميل في الواجهة الأمامية للنظام بحيث تمر جميع الطلبات الواردة مباشرةً من خلالها. من المحتمل جدًا أنه في النظام الموزع المعقد ، سيتعين على الطلب المرور عبر عدة موازين تحميل ، كما هو موضح في
.

الشكل 1.19: موازين الحمل المتعددة

مثل الخوادم الوكيلة ، يمكن لبعض موازنات التحميل أيضًا توجيه الطلبات بشكل مختلف ، اعتمادًا على نوع الطلب. تُعرف أيضًا باسم الوكلاء العكسيين.

تعد إدارة البيانات الخاصة بجلسة مستخدم معينة أحد التحديات عند استخدام موازين التحميل. في موقع التجارة الإلكترونية ، عندما يكون لديك عميل واحد فقط ، يكون من السهل جدًا السماح للمستخدمين بوضع الأشياء في سلة التسوق الخاصة بهم وحفظ محتوياتها بين الزيارات (وهذا أمر مهم ، لأن احتمالية بيع المنتج تزداد بشكل كبير إذا ، بعد ذلك يعود المستخدم إلى الموقع ، والمنتج لا يزال في سلته). ومع ذلك ، إذا تم توجيه المستخدم إلى موقع واحد للجلسة الأولى ، ثم إلى موقع آخر أثناء زيارته التالية ، فقد تظهر تناقضات لأن الموقع الجديد قد لا يحتوي على بيانات تتعلق بمحتويات عربة التسوق الخاصة بهذا المستخدم. (ألن تنزعج إذا وضعت عبوة من Mountain Dew في سلتك وعندما تعيدها لن تكون موجودة؟) قد يكون أحد الحلول هو جعل الجلسات "ثابتة" بحيث يتم توجيه المستخدم دائمًا إلى نفس العقدة. ومع ذلك ، سيكون من الصعب للغاية الاستفادة من بعض ميزات الموثوقية ، مثل تجاوز الفشل التلقائي. في هذه الحالة ، ستحتوي عربة المستخدم دائمًا على محتوى ، ولكن إذا أصبحت العقدة اللاصقة غير متاحة ، فستكون هناك حاجة إلى نهج خاص ، ولن يكون الافتراض حول محتويات العربة صحيحًا (على الرغم من أن هذا الافتراض ، نأمل أن يكون لا يتم تضمينها في التطبيق). بالطبع ، يمكن حل هذه المشكلة بالاستراتيجيات والأدوات الأخرى كما هو موضح في هذا الفصل ، مثل الخدمات والعديد من الآخرين (مثل ذاكرة التخزين المؤقت للمتصفح وملفات تعريف الارتباط وإعادة كتابة عنوان URL).

إذا كان النظام يحتوي على عدد قليل فقط من العقد ، فمن المرجح أن تكون التقنيات مثل نظام DNS الدائري أكثر عملية من موازنات الأحمال ، والتي يمكن أن تكون باهظة الثمن وتضيف طبقة غير ضرورية إلى تعقيد النظام. بالطبع ، تحتوي الأنظمة الكبيرة على جميع أنواع خوارزميات الجدولة وموازنة الحمل المختلفة ، بما في ذلك الخوارزميات البسيطة مثل الاختيار العشوائي أو خوارزميات الدوارة ، فضلاً عن الآليات الأكثر تعقيدًا التي تأخذ في الاعتبار ميزات الأداء لأنماط استخدام النظام. كل هذه الخوارزميات توزع حركة المرور والطلبات ، ويمكن أن توفر أدوات مفيدةالموثوقية ، مثل تجاوز الفشل التلقائي أو الإزالة التلقائية لعقدة تالفة (على سبيل المثال ، عندما تصبح غير مستجيبة). ومع ذلك ، يمكن لهذه الميزات المتقدمة أن تجعل تشخيص المشكلات أمرًا مرهقًا. على سبيل المثال ، في حالات التحميل العالي ، ستزيل موازنات الأحمال العقد التي قد تكون بطيئة أو تنتهي مهلتها (بسبب سلسلة من الطلبات) ، الأمر الذي سيؤدي فقط إلى تفاقم الوضع بالنسبة للعقد الأخرى. في هذه الحالات ، يعد التحكم الشامل أمرًا مهمًا لأنه حتى لو بدا أن حركة مرور النظام الإجمالية والحمل يتناقصان (نظرًا لأن العقد تخدم عددًا أقل من الطلبات) ، فقد تكون العقد الفردية محملة بشكل زائد.

موازين التحميل هي طريقة سهلة لإضافة سعة إلى نظامك. مثل التقنيات الأخرى الموضحة في هذه المقالة ، فإنها تلعب دورًا أساسيًا في بنية النظام الموزع. توفر موازنات الأحمال أيضًا وظيفة مهمة للتحقق من صحة العقد. إذا كانت العقدة ، وفقًا لنتائج هذا الفحص ، لا تستجيب أو يتم تحميلها بشكل زائد ، فيمكن إزالتها من مجموعة معالجة الطلبات ، وبسبب التكرار في نظامك ، سيتم إعادة توزيع الحمل بين العمل المتبقي العقد.

قوائم الانتظار

حتى الآن ، نظرنا في العديد من الطرق لقراءة البيانات بسرعة. في الوقت نفسه ، تعد الإدارة الفعالة للسجلات جزءًا مهمًا آخر من توسيع نطاق البيانات. عندما تكون الأنظمة بسيطة مع الحد الأدنى من أحمال المعالجة وقواعد البيانات الصغيرة ، يمكن أن تكون عمليات الكتابة سريعة بشكل متوقع. ومع ذلك ، في أكثر أنظمة معقدةيمكن أن تستغرق هذه العملية وقتًا طويلاً إلى أجل غير مسمى. لذلك ، على سبيل المثال ، قد يلزم كتابة البيانات إلى مواقع متعددة على خوادم أو فهارس مختلفة ، أو قد يكون النظام ببساطة تحت عبء ثقيل. في الحالات التي تستغرق فيها الكتابة أو حتى أي مهمة وقتًا طويلاً ، يتطلب تحقيق الأداء والتوافر بناء عدم التزامن في النظام. الطريقة الشائعة للقيام بذلك هي ترتيب الطلبات في قائمة الانتظار.

الشكل 1.20: طلب متزامن

تخيل نظامًا يطلب فيه كل عميل مهمة خدمة عن بُعد. يرسل كل من هؤلاء العملاء طلبهم إلى الخادم ، والذي يكمل المهام في أسرع وقت ممكن ويعيد نتائجهم إلى العملاء المناسبين. في الأنظمة الصغيرة ، حيث يمكن لخادم واحد (أو خدمة منطقية) أن يخدم العملاء القادمين بأسرع ما يصلون ، يجب أن يعمل هذا النوع من المواقف بشكل جيد. ومع ذلك ، عندما يتلقى الخادم طلبات أكثر مما يمكنه التعامل معها ، يضطر كل عميل إلى الانتظار حتى يكمل العملاء الآخرون المعالجة قبل إنشاء استجابة لطلبه الخاص. هذا مثال على طلب متزامن تم تصويره في.

يمكن أن يؤدي هذا النوع من السلوك المتزامن إلى تدهور أداء العميل بشكل ملحوظ ؛ في الواقع ، في وضع الخمول ، يضطر العميل إلى الانتظار حتى يتلقى ردًا على الطلب. إن إضافة خوادم إضافية للتعامل مع حمل النظام لا يحل المشكلة في الواقع ؛ حتى مع الموازنة الفعالة للحمل في الموقع ، من الصعب للغاية ضمان موازنة الحمل المتكافئة والعادلة المطلوبة لزيادة إنتاجية العميل إلى الحد الأقصى. علاوة على ذلك ، إذا لم يكن الخادم متاحًا لمعالجة هذا الطلب (أو فشل) ، فسيتوقف العميل المتصل به أيضًا عن العمل. يتطلب الحل الفعال لهذه المشكلة تجريدًا بين طلب العميل والعمل الفعلي الذي يتم القيام به لخدمته.

الشكل 1.21: استخدام قوائم الانتظار لإدارة الطلبات

طوابير الدخول. آلية قائمة الانتظار بسيطة للغاية: تصل مهمة ، وتدخل في قائمة الانتظار ، ثم يقبل "العاملون" المهمة التالية بمجرد أن تتاح لهم الفرصة لمعالجتها. (راجع) يمكن أن تكون هذه المهام بسيطة مثل الكتابة إلى قاعدة بيانات ، أو معقدة مثل إنشاء صورة معاينة للمستند. عندما يرسل العميل طلبات إلى قائمة انتظار المهام ، فإنه لم يعد بحاجة إلى انتظار نتائج التنفيذ ؛ بدلاً من ذلك ، لا يلزم سوى الإقرار بالطلبات على النحو الواجب. يمكن أن يعمل هذا التأكيد لاحقًا كمرجع لنتائج العمل عندما يطلبها العميل.

تسمح قوائم الانتظار للعملاء بالعمل بطريقة غير متزامنة من خلال توفير تجريد استراتيجي لطلب العميل واستجابته. من ناحية أخرى ، في النظام المتزامن ، لا يوجد تمييز بين الطلب والاستجابة وبالتالي لا يمكن التحكم فيه بشكل منفصل. في النظام غير المتزامن ، يقوم العميل بإعداد مهمة ، وتستجيب الخدمة برسالة تؤكد استلام المهمة ، ومن ثم يمكن للعميل التحقق بشكل دوري من حالة المهمة ، ويطلب النتيجة بمجرد اكتمالها فقط. أثناء قيام العميل بتقديم طلب غير متزامن ، فإنه مجاني للقيام بأعمال أخرى ، وحتى تقديم طلبات غير متزامنة إلى خدمات أخرى. هذا الأخير هو مثال على كيفية عمل قوائم الانتظار والرسائل في الأنظمة الموزعة.

توفر قوائم الانتظار أيضًا بعض الحماية ضد انقطاع الخدمة ورفضها. على سبيل المثال ، من السهل جدًا إنشاء قائمة انتظار ثابتة للغاية يمكنها تكرار طلبات الخدمة التي توقفت عن العمل بسبب انقطاع الخادم المؤقت. من الأفضل استخدام قائمة انتظار لفرض ضمانات جودة الخدمة (QoS) بدلاً من تعريض العملاء لانقطاع مؤقت للخدمة ، الأمر الذي يتطلب معالجة أخطاء معقدة وغير متسقة من جانب العميل في كثير من الأحيان.

1.4 استنتاج

تطور ال أنظمة فعالةمع وصول سريعإلى عدد كبيرتعتبر البيانات موضوعًا مثيرًا للاهتمام ، ولا يزال هناك عدد كبير من الأدوات الجيدة التي تسمح لك بتكييف جميع أنواع التطبيقات الجديدة. لقد تطرق هذا الفصل إلى أمثلة قليلة فقط ، ولكن في الواقع هناك العديد من الأمثلة الأخرى - وسيستمر إنشاء ابتكارات جديدة في هذا المجال فقط.

يتم توزيع هذا العمل بموجب ترخيص Creative Commons Attribution 3.0 بدون تغيير. انظر التفاصيل في

الرجاء تمكين Javascript لاستخدام محول الوحدات

›› مزيد من المعلومات من وحدة المحول

كم قدم مكعب في 1 متر مكعب / دقيقة؟ الجواب هو 35.314666212661.
نفترض أنك تقوم بالتحويل بين قدم مكعب / دقيقةو متر مكعب / دقيقة.
يمكنك عرض مزيد من التفاصيل حول كل وحدة قياس:
قدم مكعب في الدقيقة أو متر مكعب / دقيقة
الوحدة المشتقة من النظام الدولي للوحدات لـ معدل تدفق الحجمهو المتر المكعب / الثانية.
1 متر مكعب / ثانية يساوي 2118.8799727597 قدم مكعب / دقيقة ، أو 60 متر مكعب / دقيقة.
لاحظ أنه قد تحدث أخطاء التقريب ، لذا تحقق دائمًا من النتائج.
استخدم هذه الصفحة لمعرفة كيفية التحويل بين قدم مكعب / دقيقة ومتر مكعب / دقيقة.
اكتب الأرقام الخاصة بك في النموذج لتحويل الوحدات!

›› مخطط تحويل سريع من cfm إلى متر مكعب / دقيقة

1 قدم مكعب إلى متر مكعب / دقيقة = 0.02832 متر مكعب / دقيقة

10 قدم مكعب إلى متر مكعب / دقيقة = 0.28317 متر مكعب / دقيقة

20 قدم مكعب إلى متر مكعب / دقيقة = 0.56634 متر مكعب / دقيقة

30 قدم مكعب إلى متر مكعب / دقيقة = 0.84951 متر مكعب / دقيقة

40 قدم مكعب إلى متر مكعب / دقيقة = 1.13267 متر مكعب / دقيقة

50 قدم مكعب إلى متر مكعب / دقيقة = 1.41584 متر مكعب / دقيقة

100 قدم مكعب إلى متر مكعب / دقيقة = 2.83168 متر مكعب / دقيقة

200 قدم مكعب إلى متر مكعب / دقيقة = 5.66337 متر مكعب / دقيقة

›› تريد وحدات أخرى؟

›› التعريف: قدم مكعب / دقيقة

قدم مكعب في الدقيقة (CFM) هو مقياس يستخدم في النظافة الصناعية وهندسة التهوية. يصف معدل تدفق حجم الغاز أو الهواء داخل الفضاء أو خارجه.

مقياس قياسي لتدفق الهواء يشير إلى عدد الأقدام المكعبة من الهواء التي تمر بنقطة ثابتة في دقيقة واحدة. كلما زاد الرقم ، زاد دفع الهواء عبر النظام. معدل التدفق الحجمي للسائل أو الغاز بالأقدام المكعبة في الدقيقة. 1 CFM تساوي حوالي 0.47 لتر في الثانية.

›› تحويلات متري وأكثر

موقعيوفر حاسبة تحويل عبر الإنترنت لجميع أنواع وحدات القياس. يمكنك العثور على جداول التحويل المتري لوحدات النظام الدولي للوحدات ، بالإضافة إلى الوحدات الإنجليزية والعملة والبيانات الأخرى. اكتب رموز الوحدة أو الاختصارات أو الأسماء الكاملة لوحدات الطول والمساحة والكتلة والضغط وأنواع أخرى. تتضمن الأمثلة مم ، بوصة ، 100 كجم ، أونصة سائلة أمريكية ، 6 "3" ، 10 أحجار 4 ، سم مكعب ، متر مربع ، جرامات ، مولات ، قدم في الثانية ، وغيرها الكثير!