هن آرٽيڪل ۾ اسين ڳالهائينداسين ته اسان ڪيئن ۽ ڇو ترقي ڪئي - هڪ ميکانيزم جيڪو ڪلائنٽ ايپليڪيشنن ۽ 1C جي وچ ۾ معلومات منتقل ڪري ٿو: انٽرپرائز سرورز - هڪ ڪم کي ترتيب ڏيڻ کان وٺي فن تعمير ۽ عمل درآمد جي تفصيلن ذريعي سوچڻ تائين.
انٽرايڪشن سسٽم (هتان بعد ۾ SV جو حوالو ڏنو ويو آهي) هڪ ورهايل، غلطي برداشت ڪرڻ وارو پيغام رسائيندڙ نظام آهي جنهن جي ضمانت ڏني وئي آهي. SV هڪ اعلي لوڊ سروس جي طور تي ٺاهيو ويو آهي اعلي اسڪيلبلٽي سان، ٻنهي آن لائن سروس جي طور تي دستياب آهي (1C پاران مهيا ڪيل) ۽ وڏي پيماني تي پيداوار جي طور تي جيڪا توهان جي پنهنجي سرور سهولتن تي ترتيب ڏئي سگهجي ٿي.
SV ورهايل اسٽوريج استعمال ڪري ٿو ۽ سرچ انجڻ . اسان جاوا جي باري ۾ پڻ ڳالهائينداسين ۽ ڪيئن اسان افقي طور تي PostgreSQL ماپ ڪريون ٿا.
مسئلو جي ترتيب
اهو واضح ڪرڻ لاءِ ته اسان انٽرايڪشن سسٽم ڇو ٺاهيو، مان توهان کي ٿورڙو ٻڌائيندس ته 1C ۾ ڪاروباري ايپليڪيشنن جي ترقي ڪيئن ڪم ڪري ٿي.
شروع ڪرڻ لاءِ، اسان جي باري ۾ ٿورڙو انهن لاءِ جن کي اڃا تائين خبر ناهي ته اسان ڇا ڪريون ٿا :) اسان ٺاهي رهيا آهيون 1C:Enterprise ٽيڪنالاجي پليٽ فارم. پليٽ فارم ۾ ڪاروباري ايپليڪيشن ڊولپمينٽ ٽول شامل آهي، انهي سان گڏ هڪ رن ٽائم جيڪو ڪاروباري ايپليڪيشنن کي ڪراس پليٽ فارم ماحول ۾ هلائڻ جي اجازت ڏئي ٿو.
ڪلائنٽ-سرور جي ترقي جو نمونو
1C تي ٺاهيل ڪاروباري ايپليڪيشنون: انٽرپرائز ٽن سطحن تي ڪم ڪن ٿا فن تعمير "DBMS - ايپليڪيشن سرور - ڪلائنٽ". ايپليڪيشن ڪوڊ ۾ لکيل آهي ، ايپليڪيشن سرور تي يا ڪلائنٽ تي عمل ڪري سگھجي ٿو. سڀئي ڪم ايپليڪيشن شيون (ڊائريڪٽريز، دستاويز، وغيره) سان گڏ، انهي سان گڏ ڊيٽابيس پڙهڻ ۽ لکڻ، صرف سرور تي ڪيو ويندو آهي. فارم ۽ ڪمانڊ انٽرفيس جي ڪارڪردگي پڻ سرور تي لاڳو ٿئي ٿي. ڪلائنٽ فارم وصول ڪرڻ، کولڻ ۽ ظاهر ڪرڻ، صارف سان ”ڳالهائيندي“ (خبردار، سوال...)، فارمن ۾ ننڍڙا حساب جن کي تڪڙو جواب ڏيڻ جي ضرورت آهي (مثال طور، قيمت کي مقدار سان ضرب ڪرڻ)، مقامي فائلن سان ڪم ڪرڻ، سامان سان ڪم ڪرڻ.
ايپليڪيشن ڪوڊ ۾، طريقيڪار ۽ ڪمن جا هيڊر واضح طور تي ظاهر ڪن ٿا ته ڪوڊ ڪٿي عمل ڪيو ويندو - استعمال ڪندي &AtClient / &AtServer هدايتون (&AtClient / &AtServer ٻولي جي انگريزي ورزن ۾). 1C ڊولپرز هاڻي مون کي درست ڪندي چوندا آهن ته هدايتون اصل ۾ آهن ، پر اسان لاءِ اهو هاڻي اهم ناهي.
توهان ڪلائنٽ ڪوڊ مان سرور ڪوڊ ڪال ڪري سگهو ٿا، پر توهان سرور ڪوڊ مان ڪلائنٽ ڪوڊ ڪال نٿا ڪري سگهو. اها هڪ بنيادي حد آهي جيڪا اسان ڪيترن ئي سببن لاءِ ٺاهي آهي. خاص طور تي، ڇاڪاڻ ته سرور ڪوڊ لازمي طور تي لکيو وڃي ٿو ته اهو ساڳيو طريقي سان عمل ڪري ٿو، ان کان سواء ڪٿي به سڏيو ويندو آهي - ڪلائنٽ کان يا سرور کان. ۽ ٻئي سرور ڪوڊ کان سرور ڪوڊ ڪال ڪرڻ جي صورت ۾، ڪو به ڪلائنٽ ناهي. ۽ ڇاڪاڻ ته سرور ڪوڊ جي عمل جي دوران، ڪلائنٽ جيڪو ان کي سڏيندو هو بند ڪري سگهي ٿو، ايپليڪيشن کان ٻاهر نڪري سگهي ٿو، ۽ سرور کي هاڻي ڪو به ڪال ڪرڻ وارو نه هوندو.
ڪوڊ جيڪو هٿ ڪري ٿو هڪ بٽڻ تي ڪلڪ ڪريو: ڪلائنٽ کان سرور جي طريقيڪار کي ڪال ڪرڻ ڪم ڪندو، سرور کان ڪلائنٽ جي طريقيڪار کي ڪال ڪرڻ نه ڪندو
ان جو مطلب اهو آهي ته جيڪڏهن اسان سرور کان ڪلائنٽ ايپليڪيشن ڏانهن ڪجهه پيغام موڪلڻ چاهيون ٿا، مثال طور، "ڊگهي هلندڙ" رپورٽ جو نسل ختم ٿي چڪو آهي ۽ رپورٽ ڏسي سگهجي ٿي، اسان وٽ اهڙو طريقو ناهي. توھان کي استعمال ڪرڻو پوندو چالون، مثال طور، وقتي طور تي سرور کي ڪلائنٽ ڪوڊ مان پول ڪريو. پر اهو طريقو سسٽم کي غير ضروري ڪالن سان لوڊ ڪري ٿو، ۽ عام طور تي تمام خوبصورت نظر نٿو اچي.
۽ اتي به ضرورت آهي، مثال طور، جڏهن هڪ ٽيليفون ڪال اچي - ڪال ڪرڻ وقت، ڪلائنٽ ايپليڪيشن کي ان بابت اطلاع ڏيو ته جيئن اهو ڪالر جو نمبر استعمال ڪري ان کي ڪاؤنٽر پارٽي ڊيٽابيس ۾ ڳولھي سگهي ۽ صارف کي ڪال ڪرڻ واري ڪانٽي پارٽي بابت معلومات ڏيکاري. يا، مثال طور، جڏهن ڪو آرڊر گودام تي اچي ٿو، ان بابت ڪسٽمر جي ڪلائنٽ ايپليڪيشن کي اطلاع ڏيو. عام طور تي، اهڙا ڪيترائي ڪيس آهن جتي اهڙي ميکانيزم مفيد ثابت ٿيندو.
پيداوار پاڻ
پيغام رسائيندڙ ميڪانيزم ٺاهيو. تيز، قابل اعتماد، ضمانت واري ترسيل سان، لچڪدار طريقي سان پيغامن جي ڳولا ڪرڻ جي صلاحيت سان. ميکانيزم جي بنياد تي، 1C ايپليڪيشنن جي اندر هلندڙ ميسينجر (پيغام، وڊيو ڪالز) کي لاڳو ڪريو.
سسٽم کي افقي طور تي اسپيبل ڪرڻ لاء ڊزائين ڪريو. نوڊس جو تعداد وڌائڻ سان وڌندڙ لوڊ کي ڍڪڻ گهرجي.
عمل
اسان فيصلو ڪيو ته SV جي سرور واري حصي کي سڌو سنئون 1C:Enterprise پليٽ فارم ۾ ضم نه ڪيو وڃي، پر ان کي هڪ الڳ پراڊڪٽ طور لاڳو ڪرڻ لاءِ، جنهن جي API کي 1C ايپليڪيشن حلن جي ڪوڊ مان سڏي سگهجي ٿو. اهو ڪيترن ئي سببن جي ڪري ڪيو ويو، جن مان مکيه هڪ اهو هو ته مان مختلف 1C ايپليڪيشنن جي وچ ۾ پيغامن جي مٽائڻ کي ممڪن بڻائڻ چاهيندو هو (مثال طور، واپار جي انتظام ۽ اڪائونٽنگ جي وچ ۾). مختلف 1C ايپليڪيشنون 1C جي مختلف ورزن تي هلائي سگهن ٿيون: انٽرپرائز پليٽ فارم، مختلف سرورز تي موجود هجن، وغيره. اهڙين حالتن ۾، 1C تنصيب جي "پاسي" تي واقع هڪ الڳ پراڊڪٽ جي طور تي SV جو عمل هڪ بهترين حل آهي.
تنهن ڪري، اسان فيصلو ڪيو ته SV هڪ الڳ پيداوار جي طور تي. اسان سفارش ڪريون ٿا ته ننڍيون ڪمپنيون استعمال ڪن سي بي سرور جيڪو اسان پنهنجي ڪلائوڊ ۾ نصب ڪيو آهي (wss://1cdialog.com) سرور جي مقامي تنصيب ۽ ترتيب سان لاڳاپيل اوور هيڊ خرچن کان بچڻ لاءِ. وڏا گراهڪ شايد اهو مشورو ڏئي سگھن ٿا ته انهن جي سهولتن تي پنهنجو سي بي سرور انسٽال ڪريو. اسان اسان جي بادل SaaS پراڊڪٽ ۾ ساڳيو طريقو استعمال ڪيو - اهو هڪ وڏي پيماني تي پيداوار جي طور تي پيدا ڪيو ويو آهي گراهڪن جي سائيٽن تي تنصيب لاء، ۽ اسان جي ڪلائوڊ ۾ پڻ لڳايو ويو آهي .
درخواست
لوڊ ۽ غلطي رواداري کي ورهائڻ لاء، اسان هڪ جاوا ايپليڪيشن نه، پر ڪيترن ئي، انهن جي سامهون لوڊ بيلنس سان گڏ ڪنداسين. جيڪڏهن توهان کي پيغام منتقل ڪرڻ جي ضرورت آهي نوڊ کان نوڊ تائين، استعمال ڪريو شايع ڪريو / رڪنيت حاصل ڪريو Hazelcast ۾.
ڪلائنٽ ۽ سرور جي وچ ۾ رابطي ويب ساکٽ ذريعي آهي. اهو حقيقي وقت سسٽم لاء مناسب آهي.
ورهايل ڪيش
اسان Redis، Hazelcast ۽ Ehcache جي وچ ۾ چونڊيو. اهو 2015 آهي. ريڊس صرف هڪ نئون ڪلستر جاري ڪيو (ڏاڍو نئون، خوفناڪ)، اتي ڪيترن ئي پابندين سان سينٽينل آهي. Ehcache کي خبر ناهي ته هڪ ڪلستر ۾ ڪيئن گڏ ڪجي (هي ڪارڪردگي بعد ۾ ظاهر ٿيو). اسان ان کي ڪوشش ڪرڻ جو فيصلو ڪيو Hazelcast 3.4.
Hazelcast دٻي مان ٻاهر هڪ ڪلستر ۾ گڏ ڪيو ويو آهي. اڪيلو نوڊ موڊ ۾، اهو تمام مفيد نه آهي ۽ صرف هڪ ڪيش طور استعمال ڪري سگهجي ٿو - اهو نه ڄاڻندو آهي ته ڊيٽا کي ڊسڪ ۾ ڪيئن ڊمپ ڪجي، جيڪڏهن توهان صرف نوڊ وڃائي ڇڏيو، توهان ڊيٽا وڃائي ڇڏيو. اسان ڪيترن ئي Hazelcasts کي ترتيب ڏيون ٿا، جن جي وچ ۾ اسان نازڪ ڊيٽا کي بيڪ اپ ڪندا آهيون. اسان ڪيش کي بيڪ اپ نٿا ڪريون - اسان کي ان تي اعتراض ناهي.
اسان لاء، Hazelcast آهي:
- صارف سيشن جو ذخيرو. هر دفعي سيشن لاءِ ڊيٽابيس ۾ وڃڻ ۾ تمام گهڻو وقت لڳندو آهي، تنهن ڪري اسان سڀني سيشن کي Hazelcast ۾ رکيو.
- ڪيش. جيڪڏھن توھان ڳولي رھيا آھيو صارف پروفائل، چيڪ ڪريو ڪيش. هڪ نئون پيغام لکيو - ان کي ڪيش ۾ وجهي.
- اپليڪيشن مثالن جي وچ ۾ رابطي لاء موضوع. نوڊ هڪ واقعو پيدا ڪري ٿو ۽ ان کي Hazelcast موضوع ۾ رکي ٿو. ٻيا ايپليڪيشن نوڊس جيڪي رڪنيت حاصل ڪندا آھن ھن موضوع تي واقعا وصول ڪرڻ ۽ عمل ڪرڻ.
- ڪلستر تالا. مثال طور، اسان هڪ منفرد ڪيچ استعمال ڪندي بحث ٺاهيندا آهيون (1C ڊيٽابيس ۾ اڪيلو بحث):
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
doInClusterLock("БЕНЗОКОЛОНКА", () -> {
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
createChannel("БЕНЗОКОЛОНКА");
});اسان چيڪ ڪيو ته ڪو چينل ناهي. اسان تالا ورتو، ان کي ٻيهر چيڪ ڪيو، ۽ ان کي ٺاهيو. جيڪڏهن توهان لاڪ کڻڻ کان پوءِ لاڪ نه چيڪ ڪيو ته پوءِ موقعو آهي ته ان وقت هڪ ٻيو ٿريڊ به چيڪ ڪيو هجي ۽ هاڻي ڪوشش ڪندا ته اهو ئي بحث ٺاهيو- پر اهو اڳ ۾ ئي موجود آهي. توهان هم وقت سازي يا باقاعده جاوا لاڪ استعمال ڪندي لاڪ نٿا ڪري سگهو. ڊيٽابيس ذريعي - اهو سست آهي، ۽ اهو ڊيٽابيس لاءِ افسوس جوڳو آهي؛ Hazelcast ذريعي - اهو آهي جيڪو توهان کي گهربل آهي.
DBMS چونڊيو
اسان وٽ PostgreSQL سان ڪم ڪرڻ ۽ هن DBMS جي ڊولپرز سان تعاون ڪرڻ جو وسيع ۽ ڪامياب تجربو آهي.
PostgreSQL ڪلستر سان اهو آسان ناهي - اتي آهي , , ، پر عام طور تي اهي NoSQLs نه آهن جيڪي دٻي کان ٻاهر آهن. اسان NoSQL کي مکيه اسٽوريج طور نه سمجهيو؛ اهو ڪافي هو ته اسان Hazelcast ورتو، جنهن سان اسان اڳ ۾ ڪم نه ڪيو هو.
جيڪڏهن توهان کي گهربل ڊيٽابيس کي ماپڻ جي ضرورت آهي، انهي جو مطلب آهي . جيئن توهان کي خبر آهي، شارڊنگ سان اسان ڊيٽابيس کي الڳ الڳ حصن ۾ ورهايو ٿا ته جيئن انهن مان هر هڪ کي الڳ سرور تي رکي سگهجي.
اسان جي شارڊنگ جو پهريون نسخو اسان جي ايپليڪيشن جي هر جدول کي مختلف سرورن ۾ مختلف تناسب ۾ ورهائڻ جي صلاحيت رکي ٿو. سرور A تي تمام گھڻا نياپا آھن - مھرباني ڪري، اچو ته ھن ٽيبل جو حصو سرور B ڏانھن منتقل ڪريون. اھو فيصلو صرف وقت کان اڳ واري اصلاح جي باري ۾ رڙيون ڪري رھيو آھي، تنھنڪري اسان پاڻ کي ھڪ گھڻائي نوڪردار طريقي تائين محدود ڪرڻ جو فيصلو ڪيو.
توھان پڙھي سگھوٿا گھڻا نوڪردار بابت، مثال طور، ويب سائيٽ تي .
SV ۾ ايپليڪيشن ۽ سبسڪرائبر جا تصور آهن. ايپليڪيشن هڪ ڪاروباري ايپليڪيشن جي مخصوص تنصيب آهي، جهڙوڪ ERP يا اڪائونٽنگ، ان جي استعمال ڪندڙن ۽ ڪاروباري ڊيٽا سان. هڪ سبسڪرائبر هڪ تنظيم يا فرد آهي جنهن جي طرفان درخواست SV سرور ۾ رجسٽر ٿيل آهي. هڪ سبسڪرائبر ڪيترن ئي ايپليڪيشنن کي رجسٽرڊ ڪري سگهي ٿو، ۽ اهي ايپليڪيشنون هڪ ٻئي سان پيغام مٽائي سگهن ٿيون. سبسڪرائبر اسان جي سسٽم ۾ نوڪر بڻجي ويو. ڪيترن ئي رڪنن جا پيغام هڪ جسماني ڊيٽابيس ۾ واقع ٿي سگهن ٿا؛ جيڪڏهن اسان ڏسون ٿا ته هڪ سبسڪرائبر تمام گهڻو ٽرئفڪ پيدا ڪرڻ شروع ڪيو آهي، اسان ان کي هڪ الڳ جسماني ڊيٽابيس ڏانهن منتقل ڪريون ٿا (يا هڪ الڳ ڊيٽابيس سرور پڻ).
اسان وٽ هڪ مکيه ڊيٽابيس آهي جتي هڪ روٽنگ ٽيبل محفوظ ٿيل آهي معلومات سان گڏ سڀني سبسڪرائبر ڊيٽابيس جي مقام بابت.
بنيادي ڊيٽابيس کي رڪاوٽ ٿيڻ کان روڪڻ لاءِ، اسان روٽنگ ٽيبل (۽ ٻيون اڪثر گهربل ڊيٽا) کي ڪيش ۾ رکون ٿا.
جيڪڏهن سبسڪرائبر جو ڊيٽابيس سست ٿيڻ شروع ٿئي ٿو، اسان ان کي اندر حصن ۾ ڪٽي ڇڏينداسين. ٻين منصوبن تي اسان استعمال ڪندا آهيون .
جيئن ته صارف جي پيغامن کي وڃائڻ خراب آهي، اسان پنهنجي ڊيٽابيس کي نقل سان برقرار رکون ٿا. هم وقت سازي ۽ هم وقت سازي جي نقلن جو ميلاپ توهان کي بنيادي ڊيٽابيس جي نقصان جي صورت ۾ پنهنجو پاڻ کي بيمه ڪرڻ جي اجازت ڏئي ٿو. پيغام جو نقصان صرف ان صورت ۾ ٿيندو جڏهن بنيادي ڊيٽابيس ۽ ان جي هم وقت سازي ريپليڪا هڪ ئي وقت ناڪام ٿي وڃن.
جيڪڏهن هڪ هم وقت ساز نقل گم ٿي وڃي ته، هم وقت ساز نقل هم وقت ٿي ويندي آهي.
جيڪڏهن مکيه ڊيٽابيس گم ٿي وڃي ٿي، هم وقت سازي ريپليڪا مکيه ڊيٽابيس بڻجي ويندي آهي، ۽ هم وقت سازي نقل هڪ هم وقت ساز ريپليڪا بڻجي ويندي آهي.
لچڪدار ڳولھا ڳولھا
جيئن ته، ٻين شين جي وچ ۾، SV پڻ هڪ ميسينجر آهي، ان کي هڪ تيز، آسان ۽ لچڪدار ڳولا جي ضرورت آهي، اڪائونٽ ۾ مورفولوجي وٺڻ، غلط ميلاپ استعمال ڪندي. اسان فيصلو ڪيو ته ڦيٿي کي ٻيهر نه بڻايو ۽ استعمال ڪريو مفت سرچ انجڻ Elasticsearch، جيڪا لائبريري جي بنياد تي ٺاهي وئي . اسان ايپليڪيشن نوڊس جي ناڪامي جي صورت ۾ مسئلن کي ختم ڪرڻ لاءِ ڪلسٽر (ماسٽر - ڊيٽا - ڊيٽا) ۾ Elasticsearch کي پڻ ترتيب ڏيون ٿا.
github تي اسان کي مليو Elasticsearch لاءِ ۽ ان کي استعمال ڪريو. Elasticsearch index ۾ اسان لفظ روٽ (جنهن جو پلگ ان طئي ڪري ٿو) ۽ N-grams کي ذخيرو ڪندا آهيون. جيئن صارف ڳولهڻ لاءِ ٽيڪسٽ داخل ڪري ٿو، اسان ٽائپ ڪيل متن کي N-grams جي وچ ۾ ڳوليندا آهيون. جڏهن انڊيڪس ۾ محفوظ ڪيو ويندو، لفظ "متن" کي هيٺين N-گرامن ۾ ورهايو ويندو:
[اهي، ٽيڪ، ٽيڪسٽ، ٽيڪسٽ، ٽيڪسٽ، ايڪ، ايڪسٽ، ايڪسٽ، ٽيڪسٽ، ڪي ايس، ڪيسٽ، ڪيسٽ، اسٽ، اسٽائي، توهان]،۽ لفظ ”متن“ جو جڙ به محفوظ ڪيو ويندو. اهو طريقو توهان کي لفظ جي شروعات، وچ ۾ ۽ آخر ۾ ڳولڻ جي اجازت ڏئي ٿو.
مجموعي تصويري
مضمون جي شروعات کان تصوير کي ورجايو، پر وضاحت سان:
- بيلنسر انٽرنيٽ تي بي نقاب؛ اسان وٽ nginx آهي، اهو ڪنهن به ٿي سگهي ٿو.
- جاوا ايپليڪيشن جا مثال هڪ ٻئي سان Hazelcast ذريعي رابطو ڪن ٿا.
- ويب ساکٽ سان ڪم ڪرڻ لاءِ اسان استعمال ڪندا آهيون .
- جاوا ايپليڪيشن جاوا 8 ۾ لکيل آهي ۽ بنڊلن تي مشتمل آهي . منصوبن ۾ جاوا 10 ڏانهن لڏپلاڻ ۽ ماڊلز ڏانهن منتقلي شامل آهن.
ترقي ۽ جاچ
SV جي ترقي ۽ جانچ ڪرڻ جي عمل ۾، اسان کي پروڊڪٽس جون ڪيتريون ئي دلچسپ خاصيتون مليون جن کي اسين استعمال ڪندا آهيون.
لوڊ ٽيسٽ ۽ ميموري ليڪس
هر SV ڇڏڻ جي رليز ۾ لوڊ جاچ شامل آهي. اهو ڪامياب آهي جڏهن:
- ٽيسٽ ڪيترن ئي ڏينهن تائين ڪم ڪيو ۽ ڪابه خدمت ناڪامي نه هئي
- اهم عملن لاءِ جوابي وقت هڪ آرامده حد کان وڌيڪ نه هو
- گذريل ورزن جي مقابلي ۾ ڪارڪردگي جي خرابي 10٪ کان وڌيڪ ناهي
اسان ٽيسٽ ڊيٽابيس کي ڊيٽا سان ڀريندا آهيون - اهو ڪرڻ لاءِ، اسان پيداوار جي سرور کان سڀ کان وڌيڪ فعال سبسڪرائبر بابت معلومات حاصل ڪندا آهيون، ان جي انگن کي 5 سان ضرب ڪريو (پيغام جو تعداد، بحث، استعمال ڪندڙ) ۽ ان طريقي سان جانچ ڪريو.
اسان ٽن ترتيبن ۾ رابطي واري نظام جي لوڊ جاچ ڪريون ٿا:
- دٻاء جو امتحان
- رابطا صرف
- رڪنيت جي رجسٽريشن
دٻاءُ جي امتحان دوران، اسان ڪيترن ئي سؤ موضوعن کي لانچ ڪندا آهيون، ۽ اهي سسٽم کي بغير بغير لوڊ ڪن ٿا: پيغام لکڻ، بحث مباحثو ڪرڻ، پيغامن جي فهرست حاصل ڪرڻ. اسان عام استعمال ڪندڙن جي عملن کي نقل ڪريون ٿا (منهنجي اڻ پڙهيل پيغامن جي لسٽ حاصل ڪريو، ڪنهن کي لکو) ۽ سافٽ ويئر حل (هڪ مختلف ترتيبن جو پيڪيج منتقل ڪريو، هڪ الرٽ تي عمل ڪريو).
مثال طور، هي اهو آهي ته دٻاء جي امتحان جو ڪهڙو حصو ڏسڻ جهڙو آهي:
- استعمال ڪندڙ لاگ ان
- توهان جي اڻ پڙهيل بحثن جي درخواست
- 50٪ پيغام پڙهڻ جو امڪان
- 50٪ متن ڪرڻ جو امڪان
- اڳيون استعمال ڪندڙ:
- ھڪڙو نئون بحث ٺاھڻ جو 20٪ موقعو آھي
- بي ترتيب انداز ۾ ان جي ڪنهن به بحث کي چونڊيو
- اندر وڃي ٿو
- درخواستون پيغام، صارف پروفائلز
- هن بحث مان بي ترتيب استعمال ڪندڙن کي خطاب ڪيل پنج پيغام ٺاهي ٿو
- بحث ڇڏي ٿو
- 20 ڀيرا ورجائي ٿو
- لاگ آئوٽ، اسڪرپٽ جي شروعات ڏانهن واپس وڃي ٿو
- هڪ چيٽ بٽ سسٽم ۾ داخل ٿئي ٿو (ايپليڪيشن ڪوڊ مان پيغام پهچائڻ)
- ڊيٽا جي بدلي لاءِ هڪ نئون چينل ٺاهڻ جو 50٪ موقعو آهي (خاص بحث)
- 50٪ ممڪن آهي ته موجوده چينلن مان ڪنهن کي پيغام لکڻ لاء
"صرف ڪنيڪشن" منظر هڪ سبب لاء ظاهر ٿيو. اتي هڪ صورتحال آهي: صارفين سسٽم سان ڳنڍيو آهي، پر اڃا تائين شامل نه ڪيو آهي. هر يوزر صبح جو 09:00 تي ڪمپيوٽر آن ڪري ٿو، سرور سان ڪنيڪشن قائم ڪري ٿو ۽ خاموش رهي ٿو. اھي ماڻھو خطرناڪ آھن، انھن مان گھڻا آھن - انھن مان صرف پيڪيجز آھن PING/PONG، پر اھي سرور سان ڪنيڪشن رکندا آھن (اھي ان کي جاري نٿا رکي سگھن - جيڪڏھن ڪو نئون پيغام آھي). ٽيسٽ هڪ اهڙي صورتحال کي ٻيهر پيش ڪري ٿو جتي انهن صارفين جو هڪ وڏو تعداد اڌ ڪلاڪ ۾ سسٽم ۾ لاگ ان ٿيڻ جي ڪوشش ڪري ٿو. اهو هڪ دٻاء جي امتحان سان ملندڙ جلندڙ آهي، پر ان جو ڌيان خاص طور تي هن پهرين ان پٽ تي آهي - انهي ڪري ته ڪا به ناڪامي نه آهي (هڪ شخص سسٽم کي استعمال نٿو ڪري، ۽ اهو اڳ ۾ ئي بند ٿي ويو آهي - اهو ڪجهه بدترين سوچڻ ڏکيو آهي).
سبسڪرائبر رجسٽريشن اسڪرپٽ پهرين لانچ کان شروع ٿئي ٿو. اسان هڪ دٻاءُ وارو امتحان ڪيو ۽ پڪ ٿيس ته سسٽم خط و ڪتابت دوران سست نه ٿيو. پر صارف آيا ۽ رجسٽريشن ختم ٿيڻ جي ڪري ناڪام ٿيڻ شروع ڪيو. جڏهن رجسٽريشن اسان استعمال ڪيو ، جيڪو سسٽم جي اينٽروپي سان لاڳاپيل آهي. سرور وٽ ڪافي اينٽراپي گڏ ڪرڻ جو وقت نه هو ۽ جڏهن هڪ نئين SecureRandom جي درخواست ڪئي وئي، اهو ڏهن سيڪنڊن لاءِ منجمد ٿي ويو. ھن صورتحال مان نڪرڻ جا ڪيترائي طريقا آھن، مثال طور: گھٽ محفوظ /dev/urandom ڏانھن وڃو، ھڪڙو خاص بورڊ لڳايو جيڪو اينٽراپي ٺاھي، اڳ ۾ ئي بي ترتيب نمبر ٺاھيو ۽ انھن کي تلاءَ ۾ ذخيرو ڪريو. اسان عارضي طور تي پول سان مسئلو بند ڪيو، پر ان وقت کان وٺي اسان نئين سبسڪرائبرز جي رجسٽريشن لاءِ الڳ ٽيسٽ هلائي رهيا آهيون.
اسان لوڊ جنريٽر طور استعمال ڪندا آهيون . اهو نٿو ڄاڻي ته ويب ساکٽ سان ڪيئن ڪم ڪجي؛ ان کي هڪ پلگ ان جي ضرورت آهي. "jmeter websocket" جي سوال جي ڳولا جي نتيجن ۾ پهريون آهن: ، جيڪي سفارش ڪن ٿا .
اهو آهي جتي اسان شروع ڪرڻ جو فيصلو ڪيو.
لڳ ڀڳ فوري طور تي سنجيده جاچ شروع ڪرڻ کان پوء، اسان دريافت ڪيو ته JMeter ميموري کي لڪائڻ شروع ڪيو.
پلگ ان هڪ الڳ وڏي ڪهاڻي آهي؛ 176 تارن سان، ان ۾ 132 فورڪس گيٿب تي آهن. ليکڪ پاڻ 2015 کان وٺي ان کي انجام نه ڏنو آهي (اسان ان کي 2015 ۾ ورتو، پوء اهو شڪ نه وڌو)، ڪيترن ئي گٿب مسئلن جي حوالي سان ميموري ليکڪ، 7 اڻ کليل پل درخواستون.
جيڪڏهن توهان هن پلگ ان کي استعمال ڪندي لوڊ ٽيسٽ ڪرڻ جو فيصلو ڪيو، مهرباني ڪري هيٺ ڏنل بحثن تي ڌيان ڏيو:
- گھڻن موضوعن واري ماحول ۾، ھڪڙو باقاعده LinkedList استعمال ڪيو ويو، ۽ نتيجو ھو هلندڙ وقت ۾. اهو حل ڪري سگهجي ٿو يا ته تبديل ڪرڻ سان ConcurrentLinkedDeque يا هم وقت ٿيل بلاڪ ذريعي. اسان پاڻ لاء پهريون اختيار چونڊيو ().
- ميموري لڪ؛ جڏهن ڊسڪنيڪٽ، ڪنيڪشن جي معلومات ختم نه ڪئي وئي آهي ().
- اسٽريمنگ موڊ ۾ (جڏهن ويب ساکٽ نموني جي آخر ۾ بند نه ڪئي وئي آهي، پر بعد ۾ منصوبي ۾ استعمال ڪيو ويندو آهي)، جواب جا نمونا ڪم نٿا ڪن ().
هي انهن مان هڪ آهي github تي. اسان ڇا ڪيو:
- ورتو آهي (@ elyrank) - اهو مسئلو حل ڪري ٿو 1 ۽ 3
- حل ٿيل مسئلو 2
- تازه ڪاري جيٽي 9.2.14 کان 9.3.12 تائين
- ThreadLocal ۾ سمپل ڊيٽ فارميٽ لپي وئي؛ SimpleDateFormat ٿريڊ-محفوظ نه آهي، جنهن جي ڪري NPE رن ٽائم تي
- هڪ ٻي ميموري لڪ کي درست ڪيو (ڪنيڪشن غلط طور تي بند ڪيو ويو جڏهن ڊسڪ ڪيو ويو)
۽ اڃا به وهندو آهي!
يادگيري هڪ ڏينهن ۾ نه، پر ٻن ۾ ختم ٿيڻ لڳي. بلڪل ڪو وقت نه بچيو هو، تنهنڪري اسان فيصلو ڪيو ته گهٽ ٿريڊ شروع ڪيون، پر چئن ايجنٽن تي. اهو گهٽ ۾ گهٽ هڪ هفتي لاء ڪافي هجڻ گهرجي.
ٻه ڏينهن گذري ويا...
هاڻي Hazelcast ياداشت کان ٻاهر ڊوڙندو آهي. لاگ ان ڏيکاريو ته ڪجهه ڏينهن جي جاچ کانپوءِ، هيزل ڪاسٽ ياداشت جي کوٽ جي شڪايت ڪرڻ لڳو، ۽ ڪجهه وقت کان پوءِ ڪلسٽر جدا ٿي ويو، ۽ نوڊس هڪ هڪ ڪري مرڻ لڳا. اسان JVisualVM کي hazelcast سان ڳنڍيو ۽ هڪ ”اڀرندڙ آرو“ ڏٺو - ان کي باقاعده طور تي GC سڏيو ويو، پر ياداشت کي صاف نه ڪري سگهيو.
اهو ظاهر ٿيو ته hazelcast 3.4 ۾، جڏهن هڪ نقشو / multiMap (map.destroy()) کي حذف ڪندي، ياداشت مڪمل طور تي آزاد نه آهي:
بگ ھاڻي 3.5 ۾ طئي ڪيو ويو آھي، پر اھو ھڪڙو مسئلو ھو. اسان متحرڪ نالن سان نوان ملٽي ميپس ٺاهيا ۽ انهن کي پنهنجي منطق مطابق ڊاهي ڇڏيو. ڪوڊ ڪجهه هن طرح نظر آيو:
public void join(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.put(auth.getUserId(), auth);
}
public void leave(Authentication auth, String sub) {
MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
sessions.remove(auth.getUserId(), auth);
if (sessions.size() == 0) {
sessions.destroy();
}
}ويزا:
service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");ملٽي ميپ هر سبسڪرپشن لاءِ ٺاهي وئي ۽ ختم ڪئي وئي جڏهن اها ضرورت نه هئي. اسان فيصلو ڪيو ته اسان نقشو شروع ڪنداسين ، اهم هوندو سبسڪرپشن جو نالو، ۽ قيمتون هونديون سيشن جي سڃاڻپ ڪندڙ (جنهن مان توهان پوءِ حاصل ڪري سگهو ٿا صارف جي سڃاڻپ ڪندڙ، جيڪڏهن ضروري هجي).
public void join(Authentication auth, String sub) {
addValueToMap(sub, auth.getSessionId());
}
public void leave(Authentication auth, String sub) {
removeValueFromMap(sub, auth.getSessionId());
}چارٽ بهتر ٿي ويا آهن.
اسان لوڊ ٽيسٽ بابت ٻيو ڇا سکيو آهي؟
- JSR223 کي گرووي ۾ لکڻ جي ضرورت آهي ۽ گڏ ڪرڻ واري ڪيش شامل آهي - اهو تمام تيز آهي. .
- Jmeter-Plugins گرافس سمجھڻ ۾ آسان آھن معياري کان. .
Hazelcast سان اسان جي تجربي بابت
هيزل ڪاسٽ اسان لاءِ هڪ نئين پراڊڪٽ هئي، اسان ان سان ورزن 3.4.1 کان ڪم ڪرڻ شروع ڪيو، هاڻي اسان جو پروڊڪشن سرور ورزن 3.9.2 هلائي رهيو آهي (لکڻ جي وقت، Hazelcast جو جديد نسخو 3.10 آهي).
سڃاڻپ جي نسل
اسان انٽيجر جي سڃاڻپ ڪندڙ سان شروع ڪيو. اچو ته تصور ڪريون ته اسان کي نئين اداري لاءِ هڪ ٻي لانگ جي ضرورت آهي. ڊيٽابيس ۾ ترتيب مناسب نه آهي، ٽيبل شارڊنگ ۾ شامل آهن - اهو ظاهر ٿئي ٿو ته DB1 ۾ هڪ پيغام ID = 1 ۽ DB1 ۾ هڪ پيغام ID = 2 آهي، توهان هن ID کي Elasticsearch ۾ نه وجهي سگهو ٿا، نه ئي Hazelcast ۾. ، پر بدترين شيءِ اها آهي ته جيڪڏهن توهان ٻن ڊيٽابيس مان ڊيٽا کي گڏ ڪرڻ چاهيو ٿا هڪ ۾ (مثال طور، فيصلو ڪيو ته هڪ ڊيٽابيس انهن رڪنن لاءِ ڪافي آهي). توهان Hazelcast ۾ ڪيترائي AtomicLongs شامل ڪري سگهو ٿا ۽ اتي ئي ڪائونٽر رکو ٿا، پوءِ نئين ID حاصل ڪرڻ جي ڪارڪردگي انڪريمينٽ اينڊ گيٽ سان گڏ هيزل ڪاسٽ جي درخواست لاءِ وقت آهي. پر Hazelcast ڪجهه وڌيڪ بهتر آهي - FlakeIdGenerator. جڏهن هر ڪلائنٽ سان رابطو ڪريو، انهن کي هڪ ID جي حد ڏني وئي آهي، مثال طور، پهريون - 1 کان 10 تائين، ٻيو - 000 کان 10 تائين، وغيره. ھاڻي ڪلائنٽ پنھنجي طور تي نوان سڃاڻپ ڪندڙ جاري ڪري سگھي ٿو جيستائين ان کي جاري ڪيل حد ختم ٿي وڃي. اهو جلدي ڪم ڪري ٿو، پر جڏهن توهان اپليڪيشن کي ٻيهر شروع ڪيو (۽ Hazelcast ڪلائنٽ)، هڪ نئون سلسلو شروع ٿئي ٿو - تنهنڪري اسڪپس، وغيره. ان کان علاوه، ڊولپرز حقيقت ۾ نه سمجھندا آھن ڇو ته IDs integer آھن، پر ايترو متضاد آھن. اسان هر شي کي وزن ڪيو ۽ UUIDs ڏانهن تبديل ڪيو.
رستي جي ذريعي، انهن لاء جيڪي Twitter وانگر ٿيڻ چاهين ٿا، اتي هڪ سنوڪاسٽ لائبريري آهي - هي هيزل ڪاسٽ جي چوٽي تي سنو فلڪ جو عمل آهي. توهان ان کي هتي ڏسي سگهو ٿا:
پر اسان ان جي چوڌاري وڌيڪ حاصل نه ڪيو آهي.
TransactionalMap.replace
ٻيو تعجب: TransactionalMap.replace ڪم نٿو ڪري. هتي هڪ امتحان آهي:
@Test
public void replaceInMap_putsAndGetsInsideTransaction() {
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
context.getMap("map").put("key", "oldValue");
context.getMap("map").replace("key", "oldValue", "newValue");
String value = (String) context.getMap("map").get("key");
assertEquals("newValue", value);
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}
Expected : newValue
Actual : oldValueمون کي لکڻو پيو پنهنجو مٽ پاڻ getForUpdate استعمال ڪندي:
protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
if (context != null) {
log.trace("[CACHE] Replacing value in a transactional map");
TransactionalMap<K, V> map = context.getMap(mapName);
V value = map.getForUpdate(key);
if (oldValue.equals(value)) {
map.put(key, newValue);
return true;
}
return false;
}
log.trace("[CACHE] Replacing value in a not transactional map");
IMap<K, V> map = hazelcastInstance.getMap(mapName);
return map.replace(key, oldValue, newValue);
}ٽيسٽ نه رڳو باقاعده ڊيٽا جي جوڙجڪ، پر انهن جي ٽرانزيڪشنل ورزن پڻ. اهو ٿئي ٿو ته IMap ڪم ڪري ٿو، پر TransactionalMap هاڻي موجود ناهي.
بغير وقت جي نئين JAR داخل ڪريو
پهرين، اسان فيصلو ڪيو ته اسان جي طبقن جي شين کي رڪارڊ ڪرڻ لاء Hazelcast ۾. مثال طور، اسان وٽ هڪ ايپليڪيشن ڪلاس آهي، اسان ان کي محفوظ ڪرڻ ۽ پڙهڻ چاهيون ٿا. محفوظ ڪريو:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);چيتام:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);سڀ ڪجهه ڪم ڪري رهيو آهي. پوءِ اسان فيصلو ڪيو ته ھزيل ڪاسٽ ۾ ھڪڙي انڊيڪس ٺاھڻ لاءِ:
map.addIndex("subscriberId", false);۽ جڏهن هڪ نئون ادارو لکي رهيا آهن، انهن کي ClassNotFoundException حاصل ڪرڻ شروع ڪيو. Hazelcast انڊيڪس ۾ شامل ڪرڻ جي ڪوشش ڪئي، پر اسان جي طبقي جي باري ۾ ڪجھ به نه ڄاڻندا آھن ۽ ھن طبقي سان ھڪڙو JAR چاھيو ويو ان کي فراهم ڪيو وڃي. اسان صرف اهو ڪيو، سڀ ڪجهه ڪم ڪيو، پر هڪ نئون مسئلو ظاهر ٿيو: مڪمل طور تي ڪلستر کي روڪڻ کان سواء JAR کي ڪيئن تازه ڪاري ڪجي؟ هيزل ڪاسٽ نوڊ-بي-نوڊ اپڊيٽ دوران نئين JAR نه کڻندو آهي. هن موقعي تي اسان اهو فيصلو ڪيو ته اسان انڊيڪس جي ڳولا کان سواء رهي سگهون ٿا. سڀ کان پوء، جيڪڏهن توهان Hazelcast هڪ اهم-قيمتي اسٽور جي طور تي استعمال ڪيو، پوء سڀ ڪجهه ڪم ڪندو؟ سچي نه. هتي وري IMap ۽ TransactionalMap جو رويو مختلف آهي. جتي IMap پرواه ناهي، TransactionalMap هڪ غلطي اڇلائي ٿو.
IMap. اسان 5000 شيون لکون ٿا، انهن کي پڙهو. هر شي جي توقع آهي.
@Test
void get5000() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
UUID subscriberId = UUID.randomUUID();
for (int i = 0; i < 5000; i++) {
UUID id = UUID.randomUUID();
String title = RandomStringUtils.random(5);
Application application = new Application(id, title, subscriberId);
map.set(id, application);
Application retrieved = map.get(id);
assertEquals(id, retrieved.getId());
}
}پر اهو هڪ ٽرانزيڪشن ۾ ڪم نٿو ڪري، اسان حاصل ڪيو ClassNotFoundException:
@Test
void get_transaction() {
IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
UUID subscriberId = UUID.randomUUID();
UUID id = UUID.randomUUID();
Application application = new Application(id, "qwer", subscriberId);
map.set(id, application);
Application retrievedOutside = map.get(id);
assertEquals(id, retrievedOutside.getId());
hazelcastInstance.executeTransaction(context -> {
HazelcastTransactionContextHolder.setContext(context);
try {
TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
Application retrievedInside = transactionalMap.get(id);
assertEquals(id, retrievedInside.getId());
return null;
} finally {
HazelcastTransactionContextHolder.clearContext();
}
});
}3.8 ۾، يوزر ڪلاس ڊيپلائيمينٽ ميڪانيزم ظاهر ٿيو. توھان ھڪڙي ماسٽر نوڊ کي نامزد ڪري سگھو ٿا ۽ ان تي JAR فائل کي اپڊيٽ ڪري سگھو ٿا.
ھاڻي اسان پنھنجي طريقي کي مڪمل طور تي تبديل ڪيو آھي: اسان ان کي پاڻ کي JSON ۾ سيريل ڪيو ۽ ان کي Hazelcast ۾ بچايو. Hazelcast کي اسان جي طبقن جي جوڙجڪ کي ڄاڻڻ جي ضرورت ناهي، ۽ اسان بغير وقت جي تازه ڪاري ڪري سگهون ٿا. ڊومين جي شين جي ورشننگ ايپليڪيشن پاران ڪنٽرول ڪئي وئي آهي. ايپليڪيشن جا مختلف ورجن هڪ ئي وقت هلائي سگهجن ٿا، ۽ هڪ صورتحال ممڪن آهي جڏهن نئين ايپليڪيشن نوان شعبن سان شيون لکي، پر پراڻي کي اڃا تائين انهن شعبن بابت ڄاڻ ناهي. ۽ ساڳئي وقت، نئين ايپليڪيشن پراڻي ايپليڪيشن پاران لکيل شيون پڙهي ٿو جيڪي نوان فيلڊ نه آهن. اسان ايپليڪيشن ۾ اهڙين حالتن کي سنڀاليندا آهيون، پر سادگي لاءِ اسان فيلڊز کي تبديل يا ختم نه ڪندا آهيون، اسان صرف نوان شعبا شامل ڪندي ڪلاس کي وڌايو.
اسان ڪيئن اعلي ڪارڪردگي کي يقيني بڻائي
Hazelcast ڏانهن چار سفر - سٺو، ٻه ڊيٽابيس ڏانهن - خراب
ڊيٽا لاءِ ڪيش ڏانهن وڃڻ هميشه ڊيٽابيس ڏانهن وڃڻ کان بهتر آهي، پر توهان نٿا چاهيو ته غير استعمال ٿيل رڪارڊ محفوظ ڪريو. اسان ترقي جي آخري مرحلي تائين ڪيش ڪرڻ بابت فيصلو ڇڏي ڏيون ٿا. جڏهن نئين فنڪشنلٽي کي ڪوڊ ڪيو ويندو آهي، اسان PostgreSQL (log_min_duration_statement کان 0) ۾ سڀني سوالن جي لاگنگ کي آن ڪندا آهيون ۽ 20 منٽن لاءِ لوڊ ٽيسٽنگ هلائيندا آهيون. گڏ ڪيل لاگز کي استعمال ڪندي، يوٽيلٽيز جهڙوڪ pgFouine ۽ pgBadger تجزياتي رپورٽون ٺاهي سگهن ٿيون. رپورٽن ۾، اسان بنيادي طور تي سست ۽ بار بار سوالن کي ڳوليندا آهيون. سست سوالن لاءِ، اسان هڪ عملدرآمد پلان ٺاهيندا آهيون (EXPLAIN) ۽ اندازو لڳايو ته ڇا اهڙي سوال کي تيز ڪري سگهجي ٿو. ساڳئي ان پٽ ڊيٽا لاءِ بار بار درخواستون ڪيش ۾ چڱيءَ طرح ٺھيل آھن. اسان سوالن کي رکڻ جي ڪوشش ڪندا آهيون "فليٽ"، هڪ ٽيبل في سوال.
آپريشن
SV هڪ آن لائن سروس جي طور تي 2017 جي چشمي ۾ آپريشن ۾ رکيو ويو، ۽ هڪ الڳ پراڊڪٽ جي طور تي، SV نومبر 2017 ۾ جاري ڪيو ويو (ان وقت بيٽا ورزن جي حيثيت ۾).
آپريشن جي هڪ سال کان وڌيڪ عرصي ۾، سي بي آن لائن سروس جي آپريشن ۾ ڪي به سنگين مسئلا نه آهن. اسان جي ذريعي آن لائن سروس جي نگراني ، گڏ ڪرڻ ۽ ترتيب ڏيڻ کان .
SV سرور جي ورڇ ڏيهي پيڪيجز جي صورت ۾ فراهم ڪئي وئي آهي: RPM، DEB، MSI. ونڊوز لاءِ پلس اسان هڪ واحد انسٽالر مهيا ڪريون ٿا هڪ واحد EXE جي صورت ۾ جيڪو انسٽال ڪري ٿو سرور، Hazelcast ۽ Elasticsearch هڪ مشين تي. اسان شروعاتي طور تي انسٽاليشن جي هن ورزن کي "ڊيمو" ورزن جي طور تي حوالو ڏنو، پر اهو هاڻي واضح ٿي چڪو آهي ته اهو سڀ کان وڌيڪ مشهور لڳائڻ جو اختيار آهي.
جو ذريعو: www.habr.com