يا اسان ڪيئن لکيو ڪلائنٽ C++ لائبريري لاءِ ZooKeeper, etcd ۽ Consul KV
ورهايل سسٽم جي دنيا ۾، ڪيترائي عام ڪم آهن: ڪلستر جي جوڙجڪ بابت معلومات کي محفوظ ڪرڻ، نوڊس جي ترتيب کي منظم ڪرڻ، ناقص نوڊس کي ڳولڻ، ليڊر چونڊڻ. . انهن مسئلن کي حل ڪرڻ لاء، خاص ورهايل سسٽم ٺاهيا ويا آهن - ڪوآرڊينيشن خدمتون. هاڻي اسان انهن مان ٽن ۾ دلچسپي وٺنداسين: ZooKeeper، etcd ۽ قونصل. قونصل جي تمام ڀرپور ڪارڪردگي مان، اسان قونصل KV تي ڌيان ڏينداسين.
ذات ۾، اهي سڀئي سسٽم آهن غلطي برداشت ڪندڙ، لڪيرائيبل اهم-قيمتي اسٽور. جيتوڻيڪ انهن جي ڊيٽا ماڊل ۾ اهم اختلاف آهن، جن تي اسان بعد ۾ بحث ڪنداسين، اهي ساڳيون عملي مسئلا حل ڪن ٿا. ظاهر آهي، هر ايپليڪيشن جيڪا ڪوآرڊينيشن سروس استعمال ڪري ٿي انهن مان هڪ سان ڳنڍجي ٿي، جيڪا شايد هڪ ڊيٽا سينٽر ۾ ڪيترن ئي سسٽم کي سپورٽ ڪرڻ جي ضرورت پيدا ڪري ٿي جيڪا مختلف ايپليڪيشنن لاءِ ساڳيا مسئلا حل ڪري ٿي.
هن مسئلي کي حل ڪرڻ جو خيال هڪ آسٽريلوي صلاحڪار ايجنسي ۾ پيدا ٿيو، ۽ اهو اسان ڏانهن ويو، شاگردن جي هڪ ننڍڙي ٽيم، ان کي لاڳو ڪرڻ لاء، جنهن بابت آئون ڳالهائڻ وارو آهيان.
اسان هڪ لئبرري ٺاهڻ ۾ ڪامياب ٿي ويا آهيون جيڪا ZooKeeper، etcd ۽ Consul KV سان ڪم ڪرڻ لاءِ هڪ عام انٽرفيس مهيا ڪري ٿي. لائبريري C++ ۾ لکيل آهي، پر ان کي ٻين ٻولين ۾ پورٽ ڪرڻ جو منصوبو آهي.
ڊيٽا ماڊلز
ٽن مختلف سسٽم لاءِ هڪ عام انٽرفيس ٺاهڻ لاءِ، توهان کي اهو سمجهڻ جي ضرورت آهي ته انهن ۾ ڇا آهي عام ۽ ڪيئن اهي مختلف آهن. اچو ته ان جو اندازو لڳايو.
زو سنڀاليندڙ
چابيون هڪ وڻ ۾ منظم ڪيون وينديون آهن ۽ نوڊس سڏيو ويندو آهي. مطابق، هڪ نوڊ لاء توهان ان جي ٻارن جي هڪ فهرست حاصل ڪري سگهو ٿا. زنوڊ ٺاهڻ (ٺاهيو) ۽ قدر تبديل ڪرڻ (setData) جي عملن کي الڳ ڪيو ويو آهي: صرف موجوده چاٻيون پڙهي ۽ تبديل ڪري سگھجن ٿيون. واچون هڪ نوڊ جي وجود کي جانچڻ، قدر پڙهڻ، ۽ ٻارن کي حاصل ڪرڻ جي عملن سان ڳنڍيل ٿي سگهن ٿيون. واچ هڪ هڪ وقت جو محرڪ آهي جيڪو فائر ٿئي ٿو جڏهن سرور تي لاڳاپيل ڊيٽا جو نسخو تبديل ٿئي ٿو. Ephemeral nodes استعمال ڪيا ويندا آھن ناڪامين کي ڳولڻ لاءِ. اهي ڪلائنٽ جي سيشن سان ڳنڍيل آهن جيڪي انهن کي پيدا ڪيو. جڏهن هڪ ڪلائنٽ هڪ سيشن بند ڪري ٿو يا ZooKeeper کي ان جي وجود جي اطلاع ڏيڻ بند ڪري ٿو، اهي نوڊس خودڪار طريقي سان ختم ٿي ويا آهن. سادي ٽرانزيڪشن جي حمايت ڪئي وئي آهي - آپريشن جو هڪ سيٽ جيڪي يا ته سڀئي ڪامياب يا ناڪام آهن جيڪڏهن اهو ممڪن ناهي ته انهن مان گهٽ ۾ گهٽ هڪ لاء.
وغيره
هن سسٽم جا ڊولپر واضح طور تي ZooKeeper کان متاثر هئا، ۽ تنهن ڪري هر شيء مختلف طريقي سان ڪيو. چاٻين جو ڪو به درجو نه آهي، پر اهي هڪ ليڪسيگرافي ترتيب ڏنل سيٽ ٺاهيندا آهن. توھان حاصل ڪري سگھوٿا يا ختم ڪري سگھوٿا سڀ ڪنجيون ھڪڙي خاص حد سان تعلق رکندڙ. هي ڍانچو عجيب لڳي سگھي ٿو، پر اهو اصل ۾ تمام گهڻو اظهار ڪندڙ آهي، ۽ هڪ ترتيب وار منظر ان جي ذريعي آساني سان نقل ڪري سگهجي ٿو.
etcd وٽ معياري compare-and-set آپريشن نه آهي، پر ان ۾ ڪجهه بهتر آهي: ٽرانزيڪشن. يقينا، اهي سڀني ٽن سسٽم ۾ موجود آهن، پر وغيره ٽرانزيڪشن خاص طور تي سٺا آهن. اهي ٽي بلاڪ تي مشتمل آهن: چيڪ، ڪاميابي، ناڪامي. پهرين بلاڪ شرطن جو هڪ سيٽ تي مشتمل آهي، ٻيو ۽ ٽيون - آپريشن. ٽرانزيڪشن کي ايٽمي طور تي عمل ڪيو ويندو آهي. جيڪڏهن سڀئي حالتون صحيح آهن، پوء ڪاميابي بلاڪ تي عمل ڪيو ويندو، ٻي صورت ۾ ناڪامي بلاڪ تي عمل ڪيو ويندو. API 3.3 ۾، ڪاميابي ۽ ناڪامي بلاڪ ۾ شامل ٿي سگھي ٿو نسٽڊ ٽرانزيڪشن. اهو آهي، اهو ممڪن آهي ته ايٽمي طور تي مشروط تعميرات کي لڳ ڀڳ غير منقطع nesting سطح تي عمل ڪرڻ. توهان وڌيڪ سکو سگهو ٿا ته ڪهڙيون چيڪ ۽ آپريشن موجود آهن .
واچون هتي پڻ موجود آهن، جيتوڻيڪ اهي ٿورڙا وڌيڪ پيچيده آهن ۽ ٻيهر استعمال لائق آهن. اهو آهي، هڪ اهم رينج تي هڪ واچ نصب ڪرڻ کان پوء، توهان هن رينج ۾ سڀ تازه ڪاريون حاصل ڪندا جيستائين توهان واچ کي منسوخ نه ڪندا، ۽ صرف پهرين نه. وغيره ۾، ZooKeeper ڪلائنٽ سيشن جا اينالاگ ليز آهن.
قونصل K.V.
هتي ڪا به سخت درجه بندي واري جوڙجڪ ناهي، پر قونصل اهو ظاهر ڪري سگهي ٿو ته اهو موجود آهي: توهان حاصل ڪري سگهو ٿا ۽ حذف ڪري سگهو ٿا سڀئي چابيون مخصوص اڳياڙي سان، اهو آهي، ڪم جي "ذيلي وڻ" سان. اهڙن سوالن کي ريسرسيو چئبو آهي. ان کان علاوه، قونصل صرف ڪنجيون چونڊي سگھي ٿو جن ۾ اڳياڙيءَ کان پوءِ مخصوص اکر شامل نه ھجي، جيڪو فوري طور تي ”ٻارن“ حاصل ڪرڻ سان ملندو آھي. پر اهو ياد رکڻ جي قابل آهي ته اهو صحيح طور تي هڪ عمدي جوڙجڪ جي ظاهر آهي: اهو ممڪن آهي ته هڪ چاٻي ٺاهڻ لاء جيڪڏهن ان جي والدين موجود نه هجي يا هڪ چاٻي کي ختم ڪري ڇڏيو جنهن ۾ ٻار آهن، جڏهن ته ٻارن کي سسٽم ۾ محفوظ ڪيو ويندو.
واچ جي بدران، قونصل HTTP درخواستن کي بلاڪ ڪيو آهي. اصل ۾، اهي عام ڪالون آهن ڊيٽا پڙهڻ واري طريقي سان، جنهن لاءِ، ٻين پيٽرولن سان گڏ، ڊيٽا جو آخري ڄاتل نسخو ظاهر ڪيو ويو آهي. جيڪڏهن سرور تي لاڳاپيل ڊيٽا جو موجوده نسخو بيان ڪيل هڪ کان وڌيڪ آهي، جواب فوري طور تي واپس ڪيو ويندو، ٻي صورت ۾ - جڏهن قدر تبديل ٿي وڃي. اهڙا سيشن پڻ آهن جيڪي ڪنهن به وقت چابين سان ڳنڍيل هوندا. اها ڳالهه نوٽ ڪرڻ جي قابل آهي ته etcd ۽ ZooKeeper جي برعڪس، جتي سيشن کي حذف ڪرڻ سان لاڳاپيل ڪنجيز کي ختم ڪري ٿو، اتي هڪ موڊ آهي جنهن ۾ سيشن صرف انهن کان الڳ ٿيل آهي. دستياب بغير شاخن جي، پر سڀني قسمن جي چيڪن سان.
اهو سڀ ڪجهه گڏ ڪرڻ
ZooKeeper وٽ سڀ کان وڌيڪ سخت ڊيٽا ماڊل آهي. اي سي ڊي ۾ موجود ايڪسپريس رينج سوالن کي مؤثر طريقي سان ڪنهن به زو ڪيپر يا قونصل ۾ نقل نٿو ڪري سگهجي. سڀني خدمتن مان بھترين کي شامل ڪرڻ جي ڪوشش ڪندي، اسان ھڪڙي انٽرفيس سان ختم ڪيو جيڪو تقريبا ZooKeeper انٽرفيس جي برابر آھي ھيٺ ڏنل اھم استثنان سان:
- حمايت نه ڪئي
- ACLs سپورٽ نه آهن
- سيٽ جو طريقو هڪ ڪنجي ٺاهي ٿو جيڪڏهن اهو موجود ناهي (ZK سيٽ ڊيٽا ۾ هن صورت ۾ هڪ غلطي موٽائي ٿو)
- سيٽ ۽ ڪيس جا طريقا الڳ ڪيا ويا آهن (ZK ۾ اهي بنيادي طور تي ساڳيون شيون آهن)
- ختم ڪرڻ جو طريقو هڪ نوڊ کي ان جي سب ٽري سان گڏ حذف ڪري ٿو (ZK حذف ڪرڻ ۾ غلطي واپس اچي ٿي جيڪڏهن نوڊ کي ٻار آهن)
- هر چاٻي لاء صرف هڪ نسخو آهي - قدر جو نسخو (ZK ۾ )
ترتيب واري نوڊس کي رد ڪرڻ جو سبب اهو آهي ته etcd ۽ Consul وٽ انهن لاءِ بلٽ ان سپورٽ نه آهي، ۽ اهي آساني سان استعمال ڪندڙ طرفان نتيجو لائبريري انٽرفيس جي مٿان لاڳو ڪري سگھجن ٿيون.
ZooKeeper سان ملندڙ رويي کي لاڳو ڪرڻ جڏهن هڪ ورٽيڪس کي حذف ڪرڻ جي ضرورت پوندي ته هر ڪيچ لاءِ الڳ چائلڊ ڪائونٽر کي برقرار رکڻ etcd ۽ قونصل ۾. جيئن ته اسان ميٽا معلومات کي محفوظ ڪرڻ کان بچڻ جي ڪوشش ڪئي، اهو فيصلو ڪيو ويو ته سڄي ذيلي وڻ کي ختم ڪيو وڃي.
عملدرآمد جي ذخيري
اچو ته مختلف سسٽم ۾ لائبريري انٽرفيس کي لاڳو ڪرڻ جي ڪجهه پهلوئن تي ويجھو نظر رکون.
درجه بندي ۾ وغيره
etcd ۾ هڪ درجي بندي واري نظر کي برقرار رکڻ تمام دلچسپ ڪمن مان هڪ آهي. رينج جا سوال ان کي آسان بڻائين ٿا ڪنجي جي فهرست کي ٻيهر حاصل ڪرڻ لاءِ مخصوص اڳياڙي سان. مثال طور، جيڪڏهن توهان کي هر شي جي ضرورت آهي جيڪا شروع ٿئي ٿي "/foo"، توهان هڪ حد لاءِ پڇي رهيا آهيو ["/foo", "/fop"). پر اهو واپس ڪندو ته ڪيئي جو سڄو ذيلي وڻ، جيڪو شايد قابل قبول نه هجي جيڪڏهن ذيلي وڻ وڏو آهي. شروعات ۾ اسان هڪ اهم ترجمي واري ميڪانيزم کي استعمال ڪرڻ جي منصوبابندي ڪئي، . ان ۾ شامل ڪرڻ شامل آھي ھڪڙي بائيٽ کي چاٻي جي شروعات ۾، وڻ ۾ نوڊ جي کوٽائي جي برابر. اچو ته توهان کي هڪ مثال ڏيان.
"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"
ان کان پوء اهم جي سڀ فوري طور ٻارن حاصل "/foo" ممڪن حد تائين درخواست ڪندي ["u02/foo/", "u02/foo0"). ها، ASCII ۾ "0" بعد ۾ بيٺو آهي "/".
پر ڪيئن هن معاملي ۾ هڪ vertex کي ختم ڪرڻ تي عمل ڪرڻ لاء؟ اهو ظاهر ٿئي ٿو ته توهان کي قسم جي سڀني حدن کي ختم ڪرڻ جي ضرورت آهي ["uXX/foo/", "uXX/foo0") ايڪس اينڪس تائين 01 کان ايف ايف تائين. ۽ پوءِ اندر ڀڄي وياسين هڪ ٽرانزيڪشن ۾.
نتيجي طور، هڪ سادي ڪني بدلي وارو نظام ايجاد ڪيو ويو، جنهن اهو ممڪن ڪيو ته مؤثر طريقي سان ٻنهي کي ختم ڪرڻ ۽ ٻارن جي فهرست حاصل ڪرڻ. آخري ٽوڪن کان اڳ هڪ خاص ڪردار شامل ڪرڻ ڪافي آهي. مثال طور:
"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"
پوءِ ڪنجي کي ختم ڪرڻ "/very" حذف ٿيڻ ۾ بدلجي ٿو "/u00very" ۽ حد ["/very/", "/very0"), ۽ سڀني ٻارن کي حاصل ڪرڻ - حد کان چاٻين جي درخواست ۾ ["/very/u00", "/very/u01").
ZooKeeper ۾ چاٻي هٽائڻ
جيئن مون اڳ ۾ ئي ذڪر ڪيو آهي، ZooKeeper ۾ توهان هڪ نوڊ کي ختم نه ٿا ڪري سگهو جيڪڏهن ان ۾ ٻار آهن. اسان چاٻي کي ذيلي وڻ سان گڏ ختم ڪرڻ چاهيون ٿا. مونکي ڇا ڪرڻ گهرجي؟ اسان اهو اميد سان ڪندا آهيون. پهريون، اسان بار بار ذيلي وڻ کي ڇڪيندا آهيون، هر عمدي جي ٻارن کي الڳ سوال سان حاصل ڪندا آهيون. پوءِ اسان ھڪ ٽرانزيڪشن ٺاھيو آھي جيڪو صحيح ترتيب ۾ ذيلي وڻ جي سڀني نوڊس کي ختم ڪرڻ جي ڪوشش ڪري ٿو. يقينا، تبديليون ٿي سگهن ٿيون هڪ ذيلي وڻ پڙهڻ ۽ ان کي حذف ڪرڻ جي وچ ۾. هن معاملي ۾، ٽرانزيڪشن ناڪام ٿيندو. ان کان علاوه، ذيلي وڻ پڙهڻ جي عمل دوران تبديل ٿي سگھي ٿو. ايندڙ نوڊ جي ٻارن لاءِ هڪ درخواست شايد غلطي واپس ڪري سگهي ٿي جيڪڏهن، مثال طور، هي نوڊ اڳ ۾ ئي ڊهي چڪو آهي. ٻنهي صورتن ۾، اسان سڄي عمل کي ٻيهر ورجائيندا آهيون.
اهو طريقو هڪ ڪنجي کي حذف ڪرڻ تمام غير موثر بڻائي ٿو جيڪڏهن ان ۾ ٻار آهن، ۽ اڃا به وڌيڪ، جيڪڏهن ايپليڪيشن سب ٽري سان ڪم ڪرڻ جاري رکي، چاٻي کي حذف ڪرڻ ۽ ٺاهڻ. تنهن هوندي به، هن اسان کي اجازت ڏني ته ٻين طريقن تي عمل ڪرڻ جي پيچيدگي کان پاسو ڪيو etcd ۽ قونصل ۾.
ZooKeeper ۾ مقرر ڪريو
ZooKeeper ۾ اهڙا الڳ طريقا آهن جيڪي وڻ جي جوڙجڪ سان ڪم ڪن ٿا (create, delete, getChildren) ۽ جيڪي ڊيٽا سان ڪم ڪن ٿا نوڊس ۾ (setData, getData). ان کان علاوه، سڀني طريقن ۾ سخت شرطون آهن: Create هڪ غلطي واپس ڪندو جيڪڏهن نوڊ اڳ ۾ ئي موجود آهي. ٺاھيو ويو، حذف ڪريو يا سيٽ ڪريو ڊيٽا - جيڪڏھن اھو اڳ ۾ ئي موجود نه آھي. اسان کي هڪ سيٽ طريقو جي ضرورت آهي جنهن کي سڏي سگهجي ٿو بغير ڪنهن ڪنجي جي موجودگي بابت سوچڻ جي.
ھڪڙو اختيار آھي ھڪڙو پراميد انداز وٺڻ، جيئن حذف ڪرڻ سان. چيڪ ڪريو ته ڪو نوڊ موجود آهي. جيڪڏھن موجود آھي، ڪال ڪريو setData، ٻي صورت ۾ ٺاھيو. جيڪڏهن آخري طريقو هڪ غلطي واپس ڪيو، ان کي ٻيهر ورجايو. نوٽ ڪرڻ جي پهرين شيء اها آهي ته وجود جو امتحان بي معني آهي. توهان فوري طور تي ٺاهي سگهو ٿا. ڪامياب مڪمل ٿيڻ جو مطلب اهو ٿيندو ته نوڊ موجود نه هو ۽ اهو ٺهيل هو. ٻي صورت ۾، ٺاهي مناسب غلطي واپس آڻيندو، جنهن کان پوء توهان کي سيٽ ڊيٽا کي سڏڻ جي ضرورت آهي. يقينن، ڪالن جي وچ ۾، مقابلي واري ڪال ذريعي هڪ عمدي ختم ٿي سگهي ٿو، ۽ سيٽ ڊيٽا پڻ هڪ غلطي واپس آڻيندو. انهي حالت ۾، توهان اهو سڀ ڪجهه ٻيهر ڪري سگهو ٿا، پر ڇا اهو ان جي لائق آهي؟
جيڪڏهن ٻنهي طريقن سان هڪ غلطي موٽائي، پوء اسان کي پڪ ڄاڻون ٿا ته هڪ مقابلو ختم ٿي وئي آهي. اچو ته تصور ڪريو ته ڪالنگ سيٽ کان پوءِ هي حذف ٿي ويو آهي. پوءِ جيڪو به مطلب اسان قائم ڪرڻ جي ڪوشش ڪري رهيا آهيون اهو اڳ ئي ختم ٿي چڪو آهي. هن جو مطلب اهو آهي ته اسان اهو فرض ڪري سگهون ٿا ته سيٽ ڪاميابي سان عمل ڪيو ويو، جيتوڻيڪ حقيقت ۾ ڪجھ به نه لکيو ويو آهي.
وڌيڪ ٽيڪنيڪل تفصيل
هن حصي ۾ اسين ورهايل سسٽم مان هڪ وقفو وٺنداسين ۽ ڪوڊنگ بابت ڳالهائينداسين.
ڪسٽمر جي بنيادي ضرورتن مان هڪ ڪراس پليٽ فارم هو: گهٽ ۾ گهٽ هڪ خدمتن مان هڪ لازمي طور تي لينڪس، MacOS ۽ ونڊوز تي سهڪار ڪيو وڃي. شروعات ۾، اسان صرف لينڪس لاءِ ترقي ڪئي، ۽ بعد ۾ ٻين سسٽم تي جاچ شروع ڪئي. اهو ڪيترن ئي مسئلن جو سبب بڻيو، جيڪي ڪجهه وقت تائين مڪمل طور تي واضح نه هئا ته ڪيئن وڃو. نتيجي طور، سڀئي ٽي ڪوآرڊينيشن سروسز هاڻي لينڪس ۽ MacOS تي سپورٽ آهن، جڏهن ته صرف Consul KV ونڊوز تي سپورٽ ڪئي وئي آهي.
شروعات کان وٺي، اسان ڪوشش ڪئي ته تيار ڪيل لائبريريون استعمال ڪرڻ جي خدمتن تائين رسائي حاصل ڪرڻ لاء. ZooKeeper جي صورت ۾، چونڊ تي گر ٿي ويو ، جيڪو آخرڪار ونڊوز تي گڏ ڪرڻ ۾ ناڪام ٿيو. اهو، بهرحال، حيرت انگيز ناهي: لائبريري صرف لينڪس جي حيثيت ۾ رکيل آهي. قونصل لاءِ واحد آپشن ھو . ان ۾ سپورٽ شامل ڪرڻي هئي и . etcd لاءِ، پروٽوڪول جي جديد ورزن کي سپورٽ ڪندڙ هڪ مڪمل لائبريري نه ملي، تنهنڪري اسان صرف .
ZooKeeper C++ لائبريريءَ جي هم وقت ساز انٽرفيس کان متاثر ٿي، اسان هڪ هم وقت ساز انٽرفيس کي لاڳو ڪرڻ جو فيصلو ڪيو. ZooKeeper C++ هن لاءِ مستقبل/ وعدو پريم استعمال ڪندو آهي. STL ۾، بدقسمتي سان، اهي تمام معمولي طور تي لاڳو ڪيا ويا آهن. مثال طور، نه ، جيڪو منظور ٿيل فنڪشن کي مستقبل جي نتيجي تي لاڳو ڪري ٿو جڏهن اهو دستياب ٿئي ٿو. اسان جي صورت ۾، اهڙي طريقي جي ضرورت آهي نتيجو کي اسان جي لائبريري جي شڪل ۾ تبديل ڪرڻ لاء. هن مسئلي جي چوڌاري حاصل ڪرڻ لاء، اسان کي اسان جي پنهنجي سادي سلسلي جي تلاء تي عمل ڪرڻو پيو، ڇاڪاڻ ته صارف جي درخواست تي اسان استعمال نه ڪري سگهون ٿا وڏي ٽئين پارٽي لائبريريون جهڙوڪ بوسٽ.
اسان جي پوءِ عمل درآمد هن طرح ڪم ڪري ٿو. جڏهن سڏيو ويندو آهي، هڪ اضافي واعدو / مستقبل جو جوڙو ٺاهيو ويندو آهي. نئون مستقبل واپس ڪيو ويو آهي، ۽ منظور ٿيل هڪ سان لاڳاپيل فنڪشن ۽ قطار ۾ هڪ اضافي واعدو سان گڏ رکيل آهي. پول مان هڪ موضوع قطار مان ڪيترن ئي فيوچرز کي چونڊيندو آهي ۽ کين wait_for استعمال ڪندي پول ڪندو آهي. جڏهن نتيجو دستياب ٿي ويندو آهي، لاڳاپيل فنڪشن کي سڏيو ويندو آهي ۽ ان جي واپسي جي قيمت واعدو ڏانهن گذريو ويو آهي.
اسان ساڳيو ٿريڊ پول استعمال ڪيو etcd ۽ قونصل کي سوالن تي عمل ڪرڻ لاءِ. هن جو مطلب آهي ته هيٺيون لائبريريون ڪيترن ئي مختلف موضوعن ذريعي پهچائي سگھجن ٿيون. ppconsul ٿريڊ محفوظ نه آهي، تنهن ڪري ان تي ڪالون لاڪ سان محفوظ آهن.
توھان ڪيترن ئي موضوعن مان grpc سان ڪم ڪري سگھو ٿا، پر ذيلي ذوق آھن. وغيره ۾ واچون لاڳو ڪيون ويون آهن grpc اسٽريمز ذريعي. اهي هڪ خاص قسم جي پيغامن لاءِ ٻه طرفي چينل آهن. لائبريري سڀني واچن لاءِ هڪ واحد ٿريڊ ٺاهي ٿي ۽ هڪ واحد ٿريڊ جيڪو ايندڙ پيغامن تي عمل ڪري ٿو. تنهن ڪري grpc کي منع ڪري ٿو متوازي لکڻين کي وهڪرو ڪرڻ لاءِ. هن جو مطلب اهو آهي ته جڏهن هڪ واچ کي شروع ڪرڻ يا حذف ڪرڻ، توهان کي انتظار ڪرڻو پوندو جيستائين اڳئين درخواست موڪلڻ مڪمل ٿيڻ کان اڳ موڪلڻ کان اڳ. اسان هم وقت سازي لاءِ استعمال ڪندا آهيون .
نتيجو
پاڻ لاء ڏسو: .
اسان جي ٽيم: , , , , .
جو ذريعو: www.habr.com