مضمون جو ترجمو: ايلچي ٿريڊنگ ماڊل - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

مون کي هي مضمون ڏاڍو دلچسپ لڳو، ۽ جيئن ته ايلچي اڪثر ڪري ”اسٽيو“ جي حصي طور استعمال ڪيو ويندو آهي يا صرف ڪبرنيٽس جي ”انگريس ڪنٽرولر“ جي طور تي، اڪثر ماڻهن جو ان سان سڌو سنئون رابطو نه هوندو آهي، مثال طور، عام سان. Nginx يا Haproxy تنصيب. بهرحال، جيڪڏهن ڪجهه ڀڃي، اهو سمجهڻ سٺو هوندو ته اهو اندر کان ڪيئن ڪم ڪري ٿو. مون ڪوشش ڪئي ته جيترو ٿي سگهي متن جو روسي زبان ۾ ترجمو ڪرڻ جي، خاص لفظن سميت؛ جن لاءِ اهو ڏسڻ ڏکوئيندڙ آهي، مون اصل کي قوس ۾ ڇڏي ڏنو. ٻلي ۾ ڀليڪار.

Envoy codebase لاءِ گھٽ سطحي ٽيڪنيڪل دستاويز في الحال تمام گھٽ آھي. ان کي حل ڪرڻ لاءِ، مان رٿابندي ڪريان ٿو بلاگ پوسٽن جو هڪ سلسلو نمائندو جي مختلف سب سسٽم بابت. جيئن ته هي پهريون مضمون آهي، مهرباني ڪري مون کي خبر ڏيو ته توهان ڇا سوچيو ٿا ۽ توهان کي مستقبل جي مضمونن ۾ دلچسپي وٺندي.

سڀ کان عام ٽيڪنيڪل سوالن مان هڪ جيڪو مون کي ايلچي جي باري ۾ ملي ٿو، اهو پڇي رهيو آهي گهٽ-سطح جي وضاحت لاءِ ٿريڊنگ ماڊل جيڪو اهو استعمال ڪري ٿو. هن تحرير ۾، مان بيان ڪندس ته ڪيئن نمائندو نقشو ڪنيڪشن کي ٿريڊن سان گڏ ڪري ٿو، انهي سان گڏ ٿريڊ لوڪل اسٽوريج سسٽم اهو اندروني طور استعمال ڪري ٿو ڪوڊ کي وڌيڪ متوازي ۽ اعليٰ ڪارڪردگي ٺاهڻ لاءِ.

سلسلي جو جائزو

ايلچي ٽن مختلف قسمن جا اسٽريم استعمال ڪري ٿو:

مکيه: هي ٿريڊ پروسيسنگ جي شروعات ۽ ختم ٿيڻ تي ڪنٽرول ڪري ٿو، ايڪس ڊي ايس (xDiscovery سروس) API جي سڀني پروسيسنگ، بشمول DNS، صحت جي چڪاس، عام ڪلستر ۽ رن ٽائم مينيجمينٽ، شماريات ري سيٽ، انتظاميه ۽ جنرل پروسيس مئنيجمينٽ - لينڪس سگنل، گرم ٻيهر شروع، وغيره. هن سلسلي ۾ ٿئي ٿو هم وقت سازي ۽ "غير بلاڪ" آهي. عام طور تي، مکيه موضوع سڀني نازڪ ڪارڪردگي جي عملن کي همراه ڪري ٿو، جن کي هلائڻ لاء سي پي يو جي وڏي مقدار جي ضرورت ناهي. هي سڀ کان وڌيڪ ڪنٽرول ڪوڊ کي لکڻ جي اجازت ڏئي ٿو ڄڻ ته اهو اڪيلو موضوع هو.
ڪم ڪندڙ: ڊفالٽ طور، Envoy سسٽم ۾ هر هارڊويئر ٿريڊ لاءِ ورڪر ٿريڊ ٺاهي ٿو، اهو اختيار استعمال ڪندي ڪنٽرول ڪري سگهجي ٿو. --concurrency. هر ورڪر ٿريڊ هڪ ”غير بلاڪنگ“ ايونٽ لوپ هلائيندو آهي، جيڪو هر ٻڌندڙ کي ٻڌڻ لاءِ ذميوار هوندو آهي؛ لکڻ جي وقت (جولاءِ 29، 2017) ٻڌندڙ جي ڪا شارڊنگ ناهي، نوان ڪنيڪشن قبول ڪرڻ، فلٽر اسٽيڪ کي فوري ڪرڻ ڪنيڪشن، ۽ ڪنيڪشن جي زندگيءَ دوران سڀني ان پٽ/آئوٽ پُٽ (IO) عملن جي پروسيسنگ. ٻيهر، هي سڀ کان وڌيڪ ڪنيڪشن هينڊلنگ ڪوڊ کي لکڻ جي اجازت ڏئي ٿو ڄڻ ته اهو واحد موضوع هو.
فائل فلشر: هر فائل جيڪا ايلچي لکي ٿي، خاص طور تي لاگس تائين رسائي، هن وقت هڪ آزاد بلاڪنگ موضوع آهي. اهو حقيقت جي ڪري آهي ته فائلن کي لکڻ لاء فائل سسٽم طرفان محفوظ ڪيل فائلن کي پڻ استعمال ڪندي O_NONBLOCK ڪڏهن ڪڏهن بلاڪ ٿي سگهي ٿو (ساهه). جڏهن ڪم ڪندڙ موضوعن کي فائل ۾ لکڻ جي ضرورت آهي، ڊيٽا اصل ۾ ميموري ۾ هڪ بفر ڏانهن منتقل ڪيو ويندو آهي جتي آخرڪار ان سلسلي ذريعي فلش ڪيو ويندو آهي. فائل فلش. هي ڪوڊ جو هڪ علائقو آهي جتي ٽيڪنيڪل طور تي سڀئي ڪم ڪندڙ ٿريڊس ساڳئي تالا کي بلاڪ ڪري سگهن ٿا جڏهن ميموري بفر ڀرڻ جي ڪوشش ڪندا.

ڪنيڪشن سنڀالڻ

جيئن مٿي مختصر طور تي بحث ڪيو ويو آهي، سڀئي ڪم ڪندڙ موضوع سڀني ٻڌندڙن کي بغير ڪنهن شيڊنگ جي ٻڌندا آهن. اهڙيء طرح، ڪنيل استعمال ڪيو ويندو آهي خوشيء سان قبول ٿيل ساکٽ کي ڪم ڪندڙ موضوعن ڏانهن موڪلڻ لاء. جديد داڻا عام طور تي هن تي تمام سٺا هوندا آهن، اهي خاصيتون استعمال ڪندا آهن جهڙوڪ ان پٽ/آئوٽ پُٽ (IO) ترجيح وڌائڻ جي ڪوشش ڪرڻ لاءِ هڪ ٿريڊ کي ڪم سان ڀرڻ جي ڪوشش ڪرڻ کان اڳ اهي ٻئي ٿريڊ استعمال ڪرڻ شروع ڪن جيڪي پڻ ساڳي ساکٽ تي ٻڌي رهيا آهن ، ۽ پڻ استعمال نٿا ڪن گول رابن. locking (Spinlock) هر درخواست تي عمل ڪرڻ لاء.
هڪ دفعو ڪم ڪندڙ سلسلي تي هڪ ڪنيڪشن قبول ڪيو ويندو آهي، اهو ڪڏهن به ان سلسلي کي نه ڇڏيندو آهي. ڪنيڪشن جي وڌيڪ پروسيسنگ مڪمل طور تي ڪم ڪندڙ سلسلي ۾ سنڀاليو ويندو آهي، ڪنهن به اڳتي وڌڻ واري رويي سميت.

هن جا ڪيترائي اهم نتيجا آهن:

انسائيڪلوپيڊيا ۾ سڀئي ڪنيڪشن پول هڪ ڪم ڪندڙ سلسلي کي لڳايو ويو آهي. تنهن ڪري، جيتوڻيڪ HTTP/2 ڪنيڪشن پول هڪ وقت ۾ هر اپ اسٽريم هوسٽ سان صرف هڪ ڪنيڪشن ٺاهيندا آهن، جيڪڏهن چار ورڪر ٿريڊس آهن، اتي چار HTTP/2 ڪنيڪشن هوندا هر اپ اسٽريم هوسٽ هڪ مستحڪم حالت ۾.
Envoy هن طريقي سان ڪم ڪرڻ جو سبب اهو آهي ته هر شيءِ کي هڪ واحد ورڪر ٿريڊ تي رکڻ سان، لڳ ڀڳ سڀئي ڪوڊ بلاڪ ڪرڻ کان سواءِ لکي سگهجن ٿا ۽ ڄڻ ته اهو واحد ٿريڊ هجي. هي ڊزائين تمام گهڻو ڪوڊ لکڻ آسان بڻائي ٿو ۽ ڪم ڪندڙ سلسلي جي لڳ ڀڳ لامحدود تعداد ۾ ناقابل يقين حد تائين چڱي طرح.
جڏهن ته، مکيه طريقن مان هڪ اهو آهي ته ميموري پول ۽ ڪنيڪشن ڪارڪردگي جي نقطي نظر کان، اهو اصل ۾ ترتيب ڏيڻ تمام ضروري آهي. --concurrency. ضرورت کان وڌيڪ ڪم ڪندڙ ٿريڊس هجڻ سان ميموري ضايع ٿيندي، وڌيڪ بيڪار ڪنيڪشن ٺاهي، ۽ ڪنيڪشن پولنگ جي شرح گهٽجي ويندي. ليفٽ تي، اسان جو ايلچي سائڊ ڪار ڪنٽينر تمام گهٽ اتفاق سان هلن ٿا ته جيئن ڪارڪردگي تقريبن انهن خدمتن سان ملي ٿي جيڪي اهي اڳيان ويٺا آهن. اسان Envoy کي ايج پراکسي طور هلائيندا آهيون صرف وڌ کان وڌ اتفاق سان.

ڇا غير بلاڪ ڪرڻ جو مطلب آهي؟

اصطلاح "غير بلاڪنگ" اڃا تائين ڪيترائي ڀيرا استعمال ڪيو ويو آهي جڏهن بحث ڪيو ويو ته مکيه ۽ ڪم ڪندڙ موضوع ڪيئن ڪم ڪن ٿا. سڀ ڪوڊ ان فرض تي لکيل آهي ته ڪجھ به بند نه ڪيو ويو آهي. بهرحال، اهو مڪمل طور تي سچ ناهي (ڇا مڪمل طور تي سچ ناهي؟).

ايلچي ڪيترن ئي ڊگھي پروسيس لاڪ کي استعمال ڪري ٿو:

جيئن بحث ڪيو ويو آهي، جڏهن رسائي لاگ لکندا آهن، سڀ ڪم ڪندڙ موضوع ساڳيا تالا حاصل ڪندا آهن ان کان پهريان ان-ميموري لاگ بفر ڀرجي. تالا هڻڻ جو وقت تمام گهٽ هجڻ گهرجي، پر اهو ممڪن آهي ته تالا جي مقابلي ۾ مقابلو ڪيو وڃي اعلي اتفاق ۽ اعلي throughput تي.
نمائندو انگن اکرن کي سنڀالڻ لاءِ هڪ تمام پيچيده نظام استعمال ڪري ٿو جيڪي موضوع تي مقامي آهن. هي هڪ الڳ پوسٽ جو موضوع هوندو. بهرحال، مان مختصر طور تي ذڪر ڪندس ته مقامي طور تي پروسيسنگ سلسلي جي انگن اکرن جي حصي جي طور تي، ڪڏهن ڪڏهن مرڪزي "اسٽيٽس اسٽور" تي تالا حاصل ڪرڻ ضروري آهي. هي تالا ڪڏهن به گهربل نه هجڻ گهرجي.
مکيه سلسلي کي وقتي طور تي سڀني ڪم ڪندڙ موضوعن سان همراه ڪرڻ جي ضرورت آهي. اهو ڪم "پبلشنگ" ذريعي ڪيو ويندو آهي مکيه موضوع کان ڪم ڪندڙ سلسلي ڏانهن، ۽ ڪڏهن ڪڏهن ڪم ڪندڙ موضوعن کان واپس مکيه سلسلي ڏانهن. موڪلڻ لاءِ تالا جي ضرورت آهي ته جيئن شايع ٿيل پيغام بعد ۾ پهچائڻ لاءِ قطار ۾ رکي سگهجي. اهي تالا ڪڏهن به سنجيدگي سان مقابلو نه ٿيڻ گهرجن، پر اهي اڃا تائين ٽيڪنالاجي طور تي بلاڪ ٿي سگهن ٿيون.
جڏهن ايلچي سسٽم ايرر اسٽريم (معياري غلطي) ڏانهن لاگ لکي ٿو، اهو پوري عمل تي هڪ تالا حاصل ڪري ٿو. عام طور تي، ايلچي جي مقامي لاگنگ کي ڪارڪردگي جي نقطي نظر کان خوفناڪ سمجهيو ويندو آهي، تنهنڪري ان کي بهتر ڪرڻ تي گهڻو ڌيان نه ڏنو ويو آهي.
ڪجھ ٻيا بي ترتيب لاڪ آھن، پر انھن مان ڪو به ڪارڪردگي نازڪ نه آھي ۽ ڪڏھن به چئلينج نه ڪيو وڃي.

ٿريڊ مقامي اسٽوريج

ڇاڪاڻ ته جنهن طريقي سان نمائندو مکيه ٿريڊ جي ذميوارين کي ورڪر ٿريڊ جي ذميوارين کان الڳ ڪري ٿو، اتي هڪ ضرورت آهي ته پيچيده پروسيسنگ مکيه سلسلي تي ڪري سگهجي ۽ پوءِ هر ڪم ڪندڙ سلسلي کي انتهائي هم وقت سازي سان مهيا ڪيو وڃي. هي سيڪشن بيان ڪري ٿو Envoy Thread Local Storage (TLS) هڪ اعليٰ سطح تي. ايندڙ حصي ۾ آئون بيان ڪندس ته اهو ڪلستر کي منظم ڪرڻ لاء ڪيئن استعمال ڪيو ويندو آهي.

جيئن اڳ ۾ ئي بيان ڪيو ويو آهي، مکيه ڌاڳو انسائيڪلوپيڊيا جي عمل ۾ عملي طور تي سڀني انتظام ۽ ڪنٽرول جهاز جي ڪارڪردگي کي سنڀاليندو آهي. ڪنٽرول جهاز هتي ٿورڙو اوورلوڊ ٿيل آهي، پر جڏهن توهان ان کي اينوائي پروسيس جي اندر اندر ڏسو ٿا ۽ ان کي فارورڊنگ سان موازنہ ڪريو ٿا جيڪو ڪم ڪندڙ ٿريڊس ڪندا آهن، اهو سمجهه ۾ اچي ٿو. عام اصول اهو آهي ته مکيه ٿريڊ جو عمل ڪجهه ڪم ڪري ٿو، ۽ پوءِ ان ڪم جي نتيجي مطابق هر ڪم ڪندڙ ٿريڊ کي اپڊيٽ ڪرڻ جي ضرورت آهي. انهي حالت ۾، ڪم ڪندڙ سلسلي کي هر رسائي تي تالا حاصل ڪرڻ جي ضرورت ناهي.

سفير جو TLS (ٿريڊ لوڪل اسٽوريج) سسٽم هن ريت ڪم ڪري ٿو:

مکيه سلسلي تي هلندڙ ڪوڊ سڄي عمل لاءِ TLS سلاٽ مختص ڪري سگھي ٿو. جيتوڻيڪ اهو خلاصو آهي، عملي طور تي اهو هڪ ویکٹر ۾ هڪ انڊيڪس آهي، O(1) رسائي فراهم ڪري ٿو.
مکيه ڌاڳو ان جي سلاٽ ۾ خودمختيار ڊيٽا کي انسٽال ڪري سگھي ٿو. جڏهن اهو ٿي چڪو آهي، ڊيٽا شايع ٿيل آهي هر ڪم ڪندڙ سلسلي کي عام واقعي لوپ واقعي جي طور تي.
ڪم ڪندڙ موضوع پنهنجي TLS سلاٽ مان پڙهي سگهن ٿا ۽ اتي موجود ڪنهن به ٿريڊ-مقامي ڊيٽا کي ٻيهر حاصل ڪري سگهن ٿا.

جيتوڻيڪ اهو هڪ تمام سادو ۽ ناقابل يقين حد تائين طاقتور نمونو آهي، اهو RCU (Read-Copy-Update) بلاڪنگ جي تصور سان بلڪل ملندڙ جلندڙ آهي. لازمي طور تي، ڪم ڪندڙ ٿريڊس ڪڏهن به TLS سلاٽ ۾ ڊيٽا جي تبديلين کي نه ڏسندا آهن جڏهن ڪم هلندڙ آهي. تبديلي صرف ڪم جي واقعن جي وچ ۾ باقي عرصي دوران ٿيندي آهي.

سفير ان کي ٻن مختلف طريقن سان استعمال ڪري ٿو:

هر ڪم ڪندڙ سلسلي تي مختلف ڊيٽا محفوظ ڪرڻ سان، ڊيٽا کي بغير ڪنهن بلاڪ ڪرڻ جي رسائي ٿي سگهي ٿي.
هر ورڪر ٿريڊ تي صرف پڙهڻ واري موڊ ۾ عالمي ڊيٽا ڏانهن حصيداري پوائنٽر کي برقرار رکڻ سان. اهڙيء طرح، هر ڪم ڪندڙ سلسلي ۾ هڪ ڊيٽا ريفرنس جي ڳڻپ آهي جيڪا گهٽجي نه ٿي سگهي جڏهن ڪم هلندڙ آهي. صرف تڏهن جڏهن سڀئي ڪارڪن پرسڪون ٿين ۽ نئين شيئر ڪيل ڊيٽا کي اپلوڊ ڪن ته پراڻي ڊيٽا تباهه ٿي ويندي. هي RCU جي هڪجهڙائي آهي.

ڪلستر اپڊيٽ ٿريڊنگ

هن حصي ۾، مان بيان ڪندس ته ڪيئن TLS (Thread Local Storage) ڪلستر کي منظم ڪرڻ لاءِ استعمال ڪيو ويندو آهي. ڪلستر مينيجمينٽ ۾ xDS API ۽/يا DNS پروسيسنگ، گڏوگڏ صحت جي چڪاس شامل آهي.

ڪلستر جي وهڪري جي انتظام هيٺ ڏنل اجزاء ۽ مرحلا شامل آهن:

ڪلسٽر مئنيجر ايلچي جي اندر هڪ جزو آهي جيڪو سڀني سڃاتل ڪلسٽر اپ اسٽريمز کي منظم ڪري ٿو، ڪلسٽر دريافت سروس (سي ڊي ايس) API، سيڪريٽ ڊسڪوري سروس (SDS) ۽ اينڊ پوائنٽ ڊسڪوري سروس (EDS) APIs، DNS، ۽ فعال خارجي چيڪنگ. اهو هر اپ اسٽريم ڪلسٽر جو ”آخرڪار مسلسل“ ڏيک ٺاهڻ جو ذميوار آهي، جنهن ۾ دريافت ڪيل ميزبان ۽ صحت جي صورتحال شامل آهي.
صحت جي جانچ ڪندڙ هڪ فعال صحت جي جانچ ڪري ٿو ۽ ڪلستر مينيجر کي صحت جي صورتحال جي تبديلين جي رپورٽ ڪري ٿو.
CDS (ڪلسٽر دريافت سروس) / SDS (سيڪريٽ ڊسڪوري سروس) / اي ڊي ايس (آخري پوائنٽ دريافت سروس) / ڊي اين ايس ڪلستر رڪنيت کي طئي ڪرڻ لاء انجام ڏنو ويو آهي. رياست جي تبديلي ڪلستر مينيجر ڏانهن واپس ڪئي وئي آهي.
هر ڪم ڪندڙ ڌاڳو مسلسل هڪ ايونٽ لوپ تي عمل ڪري ٿو.
جڏهن ڪلسٽر مئنيجر اهو طئي ڪري ٿو ته ڪلستر جي رياست تبديل ٿي وئي آهي، اهو ڪلستر جي رياست جو هڪ نئون صرف پڙهڻ لاءِ سنيپ شاٽ ٺاهي ٿو ۽ ان کي هر ورڪر ٿريڊ ڏانهن موڪلي ٿو.
ايندڙ خاموش دور ۾، ڪم ڪندڙ ٿريڊ مختص ڪيل TLS سلاٽ ۾ سنيپ شاٽ کي اپڊيٽ ڪندو.
هڪ I/O ايونٽ جي دوران جيڪو ميزبان کي بيلنس لوڊ ڪرڻ لاءِ طئي ڪرڻ گهرجي، لوڊ بيلنس ڪندڙ ميزبان بابت معلومات حاصل ڪرڻ لاءِ TLS (Thread Local Storage) سلاٽ جي درخواست ڪندو. هي تالا جي ضرورت نه رکندو آھي. اهو پڻ نوٽ ڪريو ته TLS پڻ تازه ڪاري جي واقعن کي ٽريڪ ڪري سگهي ٿو ته جيئن لوڊ بيلنسرز ۽ ٻيا حصا ڪيش، ڊيٽا جي جوڙجڪ وغيره کي ٻيهر ڳڻپ ڪري سگهن. اهو هن پوسٽ جي دائري کان ٻاهر آهي، پر ڪوڊ ۾ مختلف هنڌن تي استعمال ڪيو ويو آهي.

مٿين طريقيڪار کي استعمال ڪندي، سفير هر درخواست کي بغير ڪنهن بلاڪ ڪرڻ جي عمل ڪري سگهي ٿو (سواءِ جيئن اڳ بيان ڪيو ويو آهي). TLS ڪوڊ جي پيچيدگي کان علاوه، اڪثر ڪوڊ کي اهو سمجهڻ جي ضرورت ناهي ته ملٽي ٿريڊنگ ڪيئن ڪم ڪري ٿي ۽ لکي سگهجي ٿو اڪيلو ٿريڊ. اهو سڀ کان وڌيڪ ڪوڊ آسان بڻائي ٿو لکڻ لاءِ بهتر ڪارڪردگي کان علاوه.

ٻيا سب سسٽم جيڪي استعمال ڪن ٿا TLS

TLS (Thread Local Storage) ۽ RCU (Read Copy Update) وڏي پيماني تي Envoy ۾ استعمال ٿيندا آهن.

استعمال جا مثال:

عمل جي دوران ڪارڪردگي کي تبديل ڪرڻ لاء ميڪانيزم: فعال ڪارڪردگي جي موجوده فهرست مکيه سلسلي ۾ شمار ڪئي وئي آهي. هر ڪم ڪندڙ سلسلي کي پوءِ ڏنو ويندو آهي صرف پڙهڻ لاءِ سنيپ شاٽ RCU سيمينٽڪس استعمال ڪندي.
رستي جي جدولن کي تبديل ڪرڻ: RDS (Route Discovery Service) پاران مهيا ڪيل روٽ جدولن لاءِ، روٽ جدولن کي مکيه ٿريڊ تي ٺاهيو ويو آهي. صرف پڙهڻ لاءِ سنيپ شاٽ بعد ۾ مهيا ڪيو ويندو هر ڪم ڪندڙ سلسلي کي RCU (Read Copy Update) سيمينٽڪس استعمال ڪندي. اهو رستو تبديل ڪرڻ واري جدولن کي ايٽمي طور تي موثر بڻائي ٿو.
HTTP هيڊر ڪيشنگ: جيئن ته اهو نڪتو، هر درخواست لاء HTTP هيڊر کي ڳڻڻ (جڏهن ته هلندڙ ~ 25K + RPS في ڪور) ڪافي مهانگو آهي. ايلچي مرڪزي طور تي هيڊر کي تقريباً هر اڌ سيڪنڊ ۾ شمار ڪري ٿو ۽ هر ڪم ڪندڙ کي TLS ۽ RCU ذريعي مهيا ڪري ٿو.

ٻيا به ڪيس آھن، پر پوئين مثالن کي چڱيءَ طرح سمجھڻ گھرجي ته TLS ڪھڙي لاءِ استعمال ٿئي ٿو.

معروف ڪارڪردگي نقصان

جڏهن ته ايلچي مجموعي طور تي تمام سٺو ڪم ڪري ٿو، اتي ڪجھ قابل ذڪر علائقا آهن جن تي ڌيان ڏيڻ جي ضرورت آهي جڏهن اهو تمام اعلي اتفاق ۽ ذريعي استعمال ڪيو ويندو آهي:

جيئن هن آرٽيڪل ۾ بيان ڪيو ويو آهي، في الحال سڀئي ڪم ڪندڙ موضوع هڪ تالا حاصل ڪندا آهن جڏهن رسائي لاگ ميموري بفر ڏانهن لکندا آهن. اعليٰ اتفاق ۽ اعليٰ ٿرو پُٽ تي، توهان کي هر ڪم ڪندڙ سلسلي لاءِ رسائي لاگس کي بيچ ڪرڻ جي ضرورت پوندي جڏهن حتمي فائل ۾ لکڻ وقت ٻاهر جي ترسيل جي خرچ تي. متبادل طور تي، توهان هر ڪم ڪندڙ سلسلي لاءِ الڳ رسائي لاگ ٺاهي سگهو ٿا.
جيتوڻيڪ انگ اکر ڏاڍا بهتر ڪيا ويا آهن، تمام اعلي اتفاق ۽ throughput تي انفرادي انگن اکرن تي ايٽمي تڪرار جو امڪان هوندو. ھن مسئلي جو حل آھي ڳڻپيوڪر في ورڪر ٿريڊ سان مرڪزي ڪائونٽرن جي وقتي ري سيٽ سان. اهو ايندڙ پوسٽ ۾ بحث ڪيو ويندو.
موجوده فن تعمير سٺو ڪم نه ڪندو جيڪڏهن ايلچي کي اهڙي صورتحال ۾ لڳايو ويو آهي جتي تمام گهٽ ڪنيڪشن آهن جن کي اهم پروسيسنگ وسيلن جي ضرورت آهي. ڪا به ضمانت نه آهي ته ڪنيڪشن هڪجهڙائي سان ڪم ڪندڙ سلسلي جي وچ ۾ ورهايا ويندا. اهو ڪم ڪندڙ ڪنيڪشن بيلنس کي لاڳو ڪرڻ سان حل ڪري سگهجي ٿو، جيڪو ڪم ڪندڙ سلسلي جي وچ ۾ ڪنيڪشن جي بدلي جي اجازت ڏيندو.

نتيجو

Envoy جي ٿريڊنگ ماڊل کي ڊزائين ڪيو ويو آهي پروگرامنگ جي آسانيءَ لاءِ ۽ وڏي پئماني تي ممڪن طور تي فضول ميموري ۽ ڪنيڪشن جي خرچ تي جيڪڏهن صحيح ترتيب نه ڏني وئي آهي. هي ماڊل ان کي اجازت ڏئي ٿو ته اهو تمام سٺو ڪم ڪري سگهي ٿو تمام گهڻي ٿريڊ ڳڻپ ۽ throughput تي.
جيئن مون مختصر طور تي Twitter تي ذڪر ڪيو آهي، ڊزائن مڪمل يوزر موڊ نيٽ ورڪنگ اسٽيڪ جي مٿي تي پڻ هلائي سگھي ٿي جهڙوڪ DPDK (ڊيٽا پلين ڊولپمينٽ کٽ)، جنهن جي نتيجي ۾ روايتي سرورز في سيڪنڊ لکين درخواستن کي مڪمل L7 پروسيسنگ سان سنڀالي سگهن ٿا. اهو ڏسڻ لاء تمام دلچسپ ٿيندو ته ايندڙ ڪجهه سالن ۾ ڇا تعمير ڪيو وڃي.
هڪ آخري تڪڙو تبصرو: مون کان ڪيترائي ڀيرا پڇيو ويو آهي ته اسان ڇو چونڊيو C ++ ايلچي لاءِ. سبب اهو آهي ته اها اڃا تائين واحد وڏي پيماني تي استعمال ٿيندڙ صنعتي گريڊ ٻولي آهي جنهن ۾ هن پوسٽ ۾ بيان ڪيل فن تعمير کي تعمير ڪري سگهجي ٿو. C++ يقيني طور تي سڀني يا ڪيترن ئي منصوبن لاءِ موزون نه آهي، پر ڪجهه استعمال جي ڪيسن لاءِ اهو اڃا تائين ڪم ڪرڻ جو واحد اوزار آهي.

ڪوڊ ڏانهن لنڪس

هن پوسٽ ۾ بحث ڪيل انٽرفيس ۽ هيڊر لاڳو ڪرڻ سان فائلن جا لنڪ:

جو ذريعو: www.habr.com

[ترجمو] اينوائي ٿريڊنگ ماڊل