څنګه او ولې موږ د 1C لپاره د لوړ بار اندازه کولو وړ خدمت لیکلی: تصدۍ: جاوا ، پوسټگری ایس کیو ایل ، هیزلکاسټ

پدې مقاله کې به موږ د دې په اړه وغږیږو چې څنګه او ولې موږ وده کړې د تعامل سیسټم - یو میکانیزم چې د پیرودونکي غوښتنلیکونو او 1C: تصدۍ سرورونو ترمینځ معلومات لیږدوي - د دندې ترتیب کولو څخه د جوړښت او پلي کولو توضیحاتو له لارې فکر کولو پورې.

د تعامل سیسټم (له دې وروسته د SV په نوم یادیږي) یو توزیع شوی، د غلطۍ زغمونکی پیغام رسولو سیسټم دی چې تضمین شوي تحویلي لري. SV د لوړ توزیع کولو سره د لوړ بار خدمت په توګه ډیزاین شوی ، دواړه د آنلاین خدمت (د 1C لخوا چمتو شوي) او د ډله ایز تولید شوي محصول په توګه شتون لري چې ستاسو په سرور تاسیساتو کې ځای په ځای کیدی شي.

SV توزیع شوي ذخیره کاروي هیزلکاسټ او د لټون انجن الیسټسیکټ. موږ به د جاوا په اړه هم وغږیږو او څنګه چې موږ په افقی ډول د PostgreSQL اندازه کوو.

د ستونزې تشکیل

د دې روښانه کولو لپاره چې موږ ولې د متقابل عمل سیسټم رامینځته کړی ، زه به تاسو ته لږ څه ووایم چې په 1C کې د سوداګرۍ غوښتنلیکونو پراختیا څنګه کار کوي.

د پیل کولو لپاره، زموږ په اړه لږ څه د هغو کسانو لپاره چې لا تر اوسه نه پوهیږو چې موږ څه کوو :) موږ د 1C: Enterprise ټیکنالوژۍ پلیټ فارم جوړوو. په پلیټ فارم کې د سوداګرۍ غوښتنلیک پراختیا وسیله شامله ده ، په بیله بیا د چلولو وخت چې د سوداګرۍ غوښتنلیکونو ته اجازه ورکوي چې د کراس پلیټ فارم چاپیریال کې پرمخ بوځي.

د پیرودونکي - سرور پراختیا تمثیل

د سوداګرۍ غوښتنلیکونه چې په 1C کې رامینځته شوي: تصدۍ په دریو کچو کې فعالیت کوي د پیرودونکي سرور جوړښت "DBMS - غوښتنلیک سرور - پیرودونکي". د غوښتنلیک کوډ لیکل شوی په 1C ژبه کې جوړ شوی، د غوښتنلیک په سرور یا پیرودونکي کې اجرا کیدی شي. ټول کار د غوښتنلیک شیانو (ډائریکټریونو، اسنادو، او نور) سره، او همدارنګه د ډیټابیس لوستل او لیکل، یوازې په سرور کې ترسره کیږي. د فارمونو او کمانډ انٹرفیس فعالیت هم په سرور کې پلي کیږي. پیرودونکی د فورمو ترلاسه کول ، خلاصول او ښودل ، د کارونکي سره "خبرې کول" (خبرتیاوې ، پوښتنې ...) ، په فارمونو کې کوچني محاسبې چې ګړندي ځواب ته اړتیا لري (د مثال په توګه ، د مقدار لخوا قیمت ضرب کول) ، د ځایی فایلونو سره کار کول ، د تجهیزاتو سره کار کول.

د غوښتنلیک په کوډ کې، د پروسیجرونو او دندو سرلیکونه باید په واضح ډول په ګوته کړي چې کوډ به چیرته اجرا شي - د &AtClient / &AtServer لارښوونو (&AtClient / &AtServer د ژبې په انګلیسي نسخه کې). د 1C پراختیا کونکي به اوس ما د دې په ویلو سره سم کړي چې لارښوونې واقعیا دي له دې څخه زیات، مګر زموږ لپاره دا اوس مهم ندي.

تاسو کولی شئ د پیرودونکي کوډ څخه د سرور کوډ ته زنګ ووهئ ، مګر تاسو نشئ کولی د سرور کوډ څخه د پیرودونکي کوډ ته زنګ ووهئ. دا یو بنسټیز محدودیت دی چې موږ د یو شمیر دلایلو لپاره رامینځته کړی. په ځانګړې توګه، ځکه چې د سرور کوډ باید په داسې ډول ولیکل شي چې دا په ورته ډول اجرا کوي پرته له دې چې ورته ویل کیږي - د پیرودونکي یا سرور څخه. او د بل سرور کوډ څخه د سرور کوډ زنګ وهلو په حالت کې ، داسې هیڅ پیرودونکي شتون نلري. او ځکه چې د سرور کوډ اجرا کولو په جریان کې ، هغه پیرودونکی چې ورته یې غږ کړی کولی شي وتړي ، غوښتنلیک پریږدي ، او سرور به نور څوک ونه لري چې تلیفون وکړي.

کوډ چې د تڼۍ کلیک اداره کوي: د پیرودونکي څخه د سرور طرزالعمل زنګ وهل به کار وکړي، د سرور څخه د پیرودونکي طرزالعمل ته زنګ وهل به نه وي

دا پدې مانا ده چې که موږ غواړو د سرور څخه د پیرودونکي غوښتنلیک ته یو څه پیغام واستوو، د بیلګې په توګه، د "اوږدې مودې" راپور تولید پای ته رسیدلی او راپور لیدل کیدی شي، موږ داسې طریقه نلرو. تاسو باید چلونه وکاروئ ، د مثال په توګه ، په دوره توګه د پیرودونکي کوډ څخه سرور رایه ورکړئ. مګر دا طریقه سیسټم د غیر ضروري تلیفونونو سره باروي، او عموما ډیر ښکلی نه ښکاري.

او اړتیا هم شتون لري، د بیلګې په توګه، کله چې تلیفون راشي د وون- کله چې زنګ ووهئ، د دې په اړه د پیرودونکي غوښتنلیک ته خبر ورکړئ ترڅو دا کولی شي د زنګ وهونکي شمیره وکاروي ترڅو دا د کاونټر پارټي ډیټابیس کې ومومي او کارونکي ته د تلیفون کونکي کاونټر پارټي په اړه معلومات وښیې. یا، د مثال په توګه، کله چې یو امر ګودام ته راشي، د دې په اړه د پیرودونکي پیرودونکي غوښتنلیک ته خبر ورکړئ. په عموم کې، ډیری قضیې شتون لري چیرې چې دا ډول میکانیزم به ګټور وي.

تولید پخپله

د پیغام رسولو میکانیزم جوړ کړئ. ګړندی ، د باور وړ ، د تضمین تحویل سره ، د انعطاف وړ پیغامونو لټون کولو وړتیا سره. د میکانیزم پراساس ، د 1C غوښتنلیکونو دننه یو میسنجر (پیغامونه ، ویډیو زنګونه) پلي کړئ.

سیسټم ډیزاین کړئ ترڅو په افقی ډول د توزیع وړ وي. زیاتیدونکی بار باید د نوډونو د شمیر په زیاتولو سره پوښل شي.

پلي کول

موږ پریکړه وکړه چې د SV سرور برخه په مستقیم ډول په 1C کې مدغم نه کړو: تصدۍ پلیټ فارم ، مګر دا د جلا محصول په توګه پلي کولو لپاره ، چې API یې د 1C غوښتنلیک حلونو کوډ څخه بلل کیدی شي. دا د یو شمیر دلایلو لپاره ترسره شوی ، چې اصلي یې دا و چې ما غوښتل دا ممکنه کړم چې د مختلف 1C غوښتنلیکونو ترمینځ پیغامونه تبادله کړم (د مثال په توګه ، د سوداګرۍ مدیریت او محاسبې ترمینځ). مختلف 1C غوښتنلیکونه د 1C په مختلف نسخو کې پرمخ وړل کیدی شي: د تصدۍ پلیټ فارم ، په مختلف سرورونو کې موقعیت لري ، او داسې نور. په داسې شرایطو کې ، د SV پلي کول د جلا محصول په توګه چې د 1C تاسیساتو په "څیر" کې موقعیت لري غوره حل دی.

نو، موږ پریکړه وکړه چې SV د جلا محصول په توګه جوړ کړو. موږ وړاندیز کوو چې کوچني شرکتونه د CB سرور وکاروي چې موږ په خپل کلاوډ (wss://1cdialog.com) کې نصب کړی ترڅو د سرور ځایی نصب او تنظیم کولو پورې اړوند د سر لګښتونو مخه ونیسي. لوی پیرودونکي ممکن د دوی په تاسیساتو کې د خپل CB سرور نصبولو مشوره وکړي. موږ زموږ د بادل SaaS محصول کې ورته چلند کارولی 1c تازه - دا د پیرودونکو سایټونو کې د نصب کولو لپاره د ډله ایز تولید شوي محصول په توګه تولید شوی ، او زموږ په بادل کې هم ځای په ځای شوی https://1cfresh.com/.

کاریال

د بار او غلطۍ زغم توزیع کولو لپاره ، موږ به یو جاوا اپلیکیشن نه ځای په ځای کړو ، مګر څو د دوی په مخ کې د بار بیلنسر سره. که تاسو اړتیا لرئ یو پیغام له نوډ څخه نوډ ته انتقال کړئ، په هزیلکاسټ کې خپرول/سبسکرایب وکاروئ.

د پیرودونکي او سرور ترمنځ اړیکه د ویب ساکټ له لارې ده. دا د ریښتیني وخت سیسټمونو لپاره ښه مناسب دی.

توزیع شوي زیرمه

موږ د Redis، Hazelcast او Ehcache ترمنځ غوره کړه. دا د 2015 کال دی. ریډیس یوازې یو نوی کلستر خپور کړ (ډیر نوی ، ویرونکی) ، د ډیری محدودیتونو سره سینټینیل شتون لري. Ehcache نه پوهیږي چې څنګه په کلستر کې راټول شي (دا فعالیت وروسته څرګند شو). موږ پریکړه وکړه چې دا د Hazelcast 3.4 سره هڅه وکړو.
Hazelcast د بکس څخه بهر په کلستر کې راټول شوی. په واحد نوډ حالت کې، دا خورا ګټور نه دی او یوازې د کیچ په توګه کارول کیدی شي - دا نه پوهیږي چې څنګه ډیسک ته ډیټا ډمپ کړئ، که تاسو یوازینی نوډ له لاسه ورکړئ، تاسو ډاټا له لاسه ورکوئ. موږ ډیری هیزلکاسټونه ځای په ځای کوو، چې په منځ کې موږ مهم معلومات بیک اپ کوو. موږ د کیچ بیک اپ نه کوو - موږ یې په اړه فکر نه کوو.

زموږ لپاره، هیزلکاسټ دی:

• د کاروونکو غونډو ذخیره کول. دا ډیر وخت نیسي چې هر ځل د ناستې لپاره ډیټابیس ته لاړ شي، نو موږ ټولې ناستې په هیزلکاسټ کې واچوو.
• کیچ. که تاسو د کارن پروفایل په لټه کې یاست، کیچ وګورئ. یو نوی پیغام یې ولیکه - په کیچ کې یې واچوه.
• د غوښتنلیک مثالونو ترمنځ د اړیکو لپاره موضوعات. نوډ یوه پیښه رامینځته کوي او د هیزلکاسټ موضوع کې یې ځای په ځای کوي. نور غوښتنلیک نوډونه چې پدې موضوع کې ګډون کوي ​​پیښه ترلاسه کوي او پروسس کوي.
• کلستر قلفونه. د مثال په توګه، موږ د یو ځانګړي کیلي په کارولو سره بحث رامینځته کوو (د 1C ډیټابیس دننه واحد بحث):

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

موږ چک کړه چې هیڅ چینل نشته. موږ قفل واخیست، بیا یې وڅیړل، او هغه یې جوړ کړ. که تاسو د تالاشۍ وروسته تالاش چیک نه کړئ، نو د دې چانس شتون لري چې په هغه وخت کې یو بل تار هم چک شوی وي او اوس به هڅه وکړي چې ورته بحث رامینځته کړي - مګر دا دمخه شتون لري. تاسو نشئ کولی د همغږي شوي یا منظم جاوا لاک په کارولو سره لاک کړئ. د ډیټابیس له لارې - دا ورو دی، او دا د ډیټابیس لپاره افسوس دی؛ د هیزلکاسټ له لارې - دا هغه څه دي چې تاسو ورته اړتیا لرئ.

د DBMS غوره کول

موږ د PostgreSQL سره کار کولو پراخه او بریالۍ تجربه لرو او د دې DBMS پراختیا کونکو سره همکاري کوو.

دا د PostgreSQL کلستر سره اسانه نده - شتون لري XL, XC, سیتوس، مګر په عموم کې دا NoSQLs ندي چې د بکس څخه بهر اندازه کیږي. موږ NoSQL د اصلي ذخیرې په توګه په پام کې نه و نیولی؛ دا کافي و چې موږ هیزلکاسټ واخیست ، کوم چې موږ دمخه ورسره کار نه و کړی.

که تاسو د اړونده ډیټابیس اندازه کولو ته اړتیا لرئ ، پدې معنی ټوټه کول. لکه څنګه چې تاسو پوهیږئ، د شارډینګ سره موږ ډیټابیس په جلا برخو ویشو ترڅو هر یو یې په جلا سرور کې کیښودل شي.

زموږ د شارډینګ لومړۍ نسخه د دې وړتیا په غاړه اخیستې چې زموږ د غوښتنلیک هر جدول په مختلف سرورونو کې په مختلف تناسب کې توزیع کړي. په سرور A کې ډیر پیغامونه شتون لري - مهرباني وکړئ د دې میز یوه برخه سرور B ته انتقال کړئ. دا پریکړه په ساده ډول د وخت څخه مخکې د اصلاح کولو په اړه چیغې وه، نو موږ پریکړه وکړه چې خپل ځان د څو کرایه کونکي طریقې پورې محدود کړو.

تاسو کولی شئ د څو کرایه کونکي په اړه ولولئ، د بیلګې په توګه، په ویب پاڼه کې د سایټس ډاټا.

SV د غوښتنلیک او پیرودونکي مفکورې لري. یو اپلیکیشن د سوداګریز غوښتنلیک ځانګړی نصب دی، لکه ERP یا محاسبه، د خپلو کاروونکو او سوداګریزو معلوماتو سره. یو پیرودونکی یو سازمان یا فرد دی چې د هغې په استازیتوب غوښتنلیک په SV سرور کې ثبت شوی. یو پیرودونکي کولی شي ډیری غوښتنلیکونه ثبت کړي، او دا غوښتنلیکونه کولی شي یو بل سره پیغامونه تبادله کړي. پیرودونکي زموږ په سیسټم کې کرایه کونکی شو. د ډیری پیرودونکو پیغامونه په یوه فزیکي ډیټابیس کې موقعیت لري؛ که موږ وګورو چې پیرودونکي د ډیری ترافیک رامینځته کول پیل کړي ، موږ دا جلا فزیکي ډیټابیس (یا حتی یو جلا ډیټابیس سرور) ته لیږدوو.

موږ یو اصلي ډیټابیس لرو چیرې چې د روټینګ میز د ټولو پیرودونکو ډیټابیسونو موقعیت په اړه معلوماتو سره زیرمه کیږي.

د دې لپاره چې اصلي ډیټابیس د خنډ کیدو مخه ونیسي، موږ د روټینګ میز (او نور مکرر اړین ډیټا) په کیچ کې ساتو.

که چیرې د پیرودونکي ډیټابیس ورو پیل شي، موږ به یې دننه په برخو کې پرې کړو. په نورو پروژو کې چې موږ یې کاروو pg_pathman.

څرنګه چې د کاروونکو پیغامونو له لاسه ورکول بد دي، موږ خپل ډیټابیسونه د نقلونو سره ساتو. د همغږي او غیر متناسب نقلونو ترکیب تاسو ته اجازه درکوي د اصلي ډیټابیس له لاسه ورکولو په صورت کې خپل ځان بیمه کړئ. د پیغام ضایع یوازې هغه وخت پیښیږي کله چې لومړني ډیټابیس او د هغې همغږي عکس په ورته وخت کې ناکام شي.

که یو همغږي عکس له لاسه ورکړي، د غیر متناسب نقل هم همغږي کیږي.
که چیرې اصلي ډیټابیس له لاسه ورکړل شي ، همغږي عکس اصلي ډیټابیس کیږي ، او غیر متناسب نقل په همغږي عکس بدلیږي.

د لټون لپاره لچک وړ لټون

څرنګه چې، د نورو شیانو په منځ کې، SV هم یو میسنجر دی، دا ګړندۍ، اسانه او انعطاف وړ لټون ته اړتیا لري، د مورفولوژي په پام کې نیولو سره، د ناسم میچونو په کارولو سره. موږ پریکړه وکړه چې څرخ بیا نه ایجاد کړو او د وړیا لټون انجن Elasticsearch څخه کار واخلو، چې د کتابتون پراساس رامینځته شوی لوسین. موږ د غوښتنلیک نوډونو د ناکامۍ په صورت کې ستونزې له مینځه وړو لپاره په کلستر (ماسټر - ډیټا - ډیټا) کې Elasticsearch هم ځای په ځای کوو.

په ګیتوب کې موږ وموندل د روسیې مورفولوژي پلگ ان د Elasticsearch لپاره او دا وکاروئ. په Elasticsearch index کې موږ د کلمې ریښې ذخیره کوو (کوم چې پلگ ان ټاکي) او N-grams. لکه څنګه چې کاروونکي د لټون لپاره متن ته ننوځي، موږ د N-grams ترمنځ ټایپ شوي متن ته ګورو. کله چې په شاخص کې خوندي شي، د "متن" کلمه به په لاندې N-ګرامو ویشل شي:

[هغه، ټیک، ټیک، متن، متن، متن، ek، ext، متن، ks، kst، ksty، st، sty، تاسو]،

او د "متن" کلمې ریښه به هم وساتل شي. دا طریقه تاسو ته اجازه درکوي چې د کلمې په پیل، مینځ کې او په پای کې لټون وکړئ.

ټول انځور

د مقالې له پیل څخه انځور تکرار کړئ، مګر د توضیحاتو سره:

• بیلانسر په انټرنیټ کې افشا شوی؛ موږ nginx لرو، دا هر یو کیدی شي.
• د جاوا غوښتنلیک مثالونه د هیزلکاسټ له لارې یو بل سره اړیکه نیسي.
• د ویب ساکټ سره کار کولو لپاره موږ کاروو نيټي.
• د جاوا غوښتنلیک په جاوا 8 کې لیکل شوی او بنډلونه لري OSGi. په پلانونو کې جاوا 10 ته مهاجرت او ماډلونو ته لیږد شامل دي.

پراختیا او ازموینه

د SV د پراختیا او ازموینې په بهیر کې، موږ د هغو محصولاتو یو شمیر په زړه پورې ځانګړتیاوو سره مخ شو چې موږ یې کاروو.

د بار ازموینې او حافظې لیک

د هر SV خوشې کول د بار ازموینه شامله ده. دا بریالی دی کله چې:

• ازموینې د څو ورځو لپاره کار وکړ او هیڅ خدمت ناکامي نه وه
• د کلیدي عملیاتو لپاره د غبرګون وخت د آرامۍ حد څخه ډیر نه و
• د پخوانۍ نسخې په پرتله د فعالیت خرابوالی له 10٪ څخه ډیر نه دی

موږ د ازموینې ډیټابیس د ډیټا سره ډک کوو - د دې کولو لپاره ، موږ د تولید سرور څخه د خورا فعال پیرودونکي په اړه معلومات ترلاسه کوو ، د هغې شمیرې 5 سره ضرب کړئ (د پیغامونو شمیر ، بحثونو ، کاروونکو) او پدې توګه یې ازموینه کوو.

موږ په دریو ترتیبونو کې د متقابل عمل سیسټم بار ازموینه ترسره کوو:

1. فشار ازموینه
2. یوازې اړیکې
3. د ګډون کونکي ثبت کول

د فشار ازموینې په جریان کې ، موږ څو سوه تارونه پیل کوو ، او دوی پرته له ځنډه سیسټم پورته کوي: د پیغامونو لیکل ، بحثونه رامینځته کول ، د پیغامونو لیست ترلاسه کول. موږ د عادي کاروونکو عملونه تقلید کوو (زما د نه لوستل شوي پیغامونو لیست ترلاسه کړئ ، یو چا ته ولیکئ) او د سافټویر حلونه (د مختلف ترتیب کڅوړه لیږدئ ، یو خبرتیا پروسس کړئ).

د مثال په توګه، دا د فشار ازموینې کومه برخه داسې ښکاري:

• کارن ننوتل
  • ستاسو نه لوستل شوي بحثونه غوښتنه کوي
  • 50٪ احتمال لري چې پیغامونه ولولي
  • د متن احتمال 50٪
  • راتلونکی کارونکی:
    • د نوي بحث د جوړولو لپاره 20٪ چانس لري
    • په تصادفي توګه د هغې هرې خبرې اترې غوره کوي
    • دننه ځي
    • د پیغامونو، د کاروونکي پروفایل غوښتنه کوي
    • د دې بحث څخه تصادفي کاروونکو ته په ګوته شوي پنځه پیغامونه رامینځته کوي
    • بحث پریږدي
    • 20 ځله تکرار کړئ
    • ننوتل، بیرته د سکریپټ پیل ته ځي

  • یو چیټ بوټ سیسټم ته ننوځي (د غوښتنلیک کوډ څخه پیغامونه جذبوي)
    • د ډیټا تبادلې لپاره د نوي چینل رامینځته کولو 50٪ چانس لري (ځانګړي بحث)
    • 50٪ احتمال لري چې کوم موجوده چینلونو ته پیغام ولیکئ

د "یوازې اړیکې" سناریو د یو دلیل لپاره څرګند شو. یو وضعیت شتون لري: کاروونکو سیسټم سره وصل کړی ، مګر لاهم ښکیل ندي. هر کارونکی د سهار په 09:00 بجو کمپیوټر چالان کوي، له سرور سره اړیکه ټینګوي او خاموش پاتې کیږي. دا هلکان خطرناک دي، ډیری یې شتون لري - یوازینۍ کڅوړې چې دوی لري PING / PONG دي، مګر دوی سرور ته پیوستون ساتي (دوی نشي کولی دا وساتي - څه شی که نوی پیغام وي). ازموینه داسې حالت رامینځته کوي چیرې چې د ورته کاروونکو لوی شمیر په نیم ساعت کې سیسټم ته د ننوتلو هڅه کوي. دا د فشار ازموینې ته ورته دی ، مګر د دې تمرکز دقیقا پدې لومړي ان پټ باندې دی - ترڅو هیڅ ناکامي شتون ونلري (یو سړی سیسټم نه کاروي ، او دا دمخه له مینځه ځي - د یو څه بد په اړه فکر کول ستونزمن دي).

د پیرودونکي راجسټریشن سکریپټ د لومړي لانچ څخه پیل کیږي. موږ د فشار ازموینه ترسره کړه او ډاډه یو چې سیسټم د لیک په جریان کې سست نه دی. مګر کاروونکي راغلل او راجسټریشن د وخت پای ته رسیدو له امله ناکام شو. کله چې ثبت کول موږ کارول / dev / تصادفي، کوم چې د سیسټم انټروپي پورې اړه لري. سرور د کافي انټروپي راټولولو لپاره وخت نه درلود او کله چې د نوي سیکور رینډم غوښتنه وشوه ، دا د لسګونو ثانیو لپاره کنګل شو. د دې حالت څخه د وتلو ډیری لارې شتون لري، د بیلګې په توګه: لږ خوندي /dev/urandom ته لاړ شئ، یو ځانګړی بورډ نصب کړئ چې انټروپي تولیدوي، تصادفي شمیرې مخکې له مخکې تولید کړئ او په حوض کې یې ذخیره کړئ. موږ په موقتي ډول د حوض سره ستونزه وتړله، مګر له هغه وخت راهیسې موږ د نویو ګډون کونکو راجستر کولو لپاره جلا ازموینه ترسره کوو.

موږ د بار جنراتور په توګه کاروو JMeter. دا نه پوهیږي چې څنګه د ویب ساکټ سره کار وکړي؛ دا یو پلگ ان ته اړتیا لري. د "jmeter websocket" پوښتنې لپاره د لټون پایلو کې لومړی دا دي: د بلیز میټر څخه مقالې، کوم چې سپارښتنه کوي د ماکیج زالیسکي لخوا پلگ ان.

دا هغه ځای دی چې موږ پریکړه وکړه چې پیل وکړو.

نږدې سمدلاسه د جدي ازموینې پیل کولو وروسته ، موږ وموندله چې JMeter د حافظې لیک کول پیل کړي.

پلگ ان یو جلا لوی کیسه ده؛ د 176 ستورو سره، دا په ګیتوب کې 132 فورک لري. لیکوال پخپله د 2015 راهیسې دې ته ژمن ندي (موږ دا په 2015 کې اخیستي ، بیا یې شک نه دی راپورته کړی) ، د حافظې لیک په اړه ډیری ګیتوب مسلې ، د 7 نه تړل شوي پل غوښتنې.
که تاسو پریکړه وکړئ چې د دې پلگ ان په کارولو سره د بار ازموینې ترسره کړئ، مهرباني وکړئ لاندې بحثونو ته پام وکړئ:

1. په څو اړخیزه چاپیریال کې، یو منظم لینک شوي لیست کارول شوی و، او پایله یې وه NPE د چلولو په وخت کې. دا یا هم د ConcurrentLinkedDeque یا همغږي شوي بلاکونو په بدلولو سره حل کیدی شي. موږ د ځان لپاره لومړی انتخاب غوره کړ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. د حافظې لیک؛ کله چې منحل شي، د پیوستون معلومات نه حذف کیږي (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. په سټرینګ حالت کې (کله چې ویب ساکټ د نمونې په پای کې نه تړل کیږي ، مګر وروسته په پلان کې کارول کیږي) ، د ځواب نمونې کار نه کوي (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

دا یو له هغو څخه دی چې په ګیتوب کې دي. هغه څه چې موږ وکړل:

1. اخیستي دي فورک ایلیران کوګان (@elyrank) - دا د 1 او 3 ستونزې حل کوي
2. ۲ـ ستونزه حل کړه
3. د 9.2.14 څخه تر 9.3.12 پورې تازه جیټي
4. په ThreadLocal کې د ساده ډیټ فارمټ پوښل؛ SimpleDateFormat د تار څخه خوندي نه دی، کوم چې د چلولو په وخت کې د NPE لامل شوی
5. د حافظې بل لیک حل کړئ (پیوستون په غلط ډول تړل شوی و کله چې منحل شو)

او بیا هم جریان لري!

حافظه په یوه ورځ کې نه، بلکې په دوو کې له منځه تلل پیل شول. هیڅ وخت پاتې نه و، نو موږ پریکړه وکړه چې لږ تارونه پیل کړو، مګر په څلورو اجنټانو. دا باید لږترلږه د یوې اونۍ لپاره کافي وي.

دوه ورځې تېرې شوې...

اوس هیزلکاسټ د حافظې څخه تیریږي. لاګونو وښودله چې د څو ورځو ازموینې وروسته ، هیزلکاسټ د حافظې د نشتوالي په اړه شکایت کول پیل کړل ، او یو څه وخت وروسته کلستر جلا شو ، او نوډونه یو له بل سره مړه کیدو ته دوام ورکړ. موږ JVisualVM د هزیلکاسټ سره وصل کړ او یو "زیاتېدونکی آری" مو ولید - دا په منظم ډول د GC په نوم یادیږي ، مګر حافظه یې پاکه نشوه.

دا معلومه شوه چې په هیزلکاسټ 3.4 کې ، کله چې نقشه / ملټي میپ (map.destroy()) حذف کول ، حافظه په بشپړ ډول نه خلاصیږي:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

بګ اوس په 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());
}

چارټونه ښه شوي دي.

موږ د بار ازموینې په اړه نور څه زده کړل؟

1. JSR223 اړتیا لري چې په ګرووي کې ولیکل شي او د تالیف کیچ پکې شامل وي - دا خورا ګړندی دی. مخونه.
2. د Jmeter-Plugins ګرافونه د معیاري ګرافونو په پرتله پوهیدل اسانه دي. مخونه.

د Hazelcast سره زموږ د تجربې په اړه

هیزلکاسټ زموږ لپاره نوی محصول و ، موږ د 3.4.1 نسخه څخه ورسره کار پیل کړ ، اوس زموږ د تولید سرور نسخه 3.9.2 پرمخ وړي (د لیکلو په وخت کې ، د هیزلکاسټ وروستۍ نسخه 3.10 ده).

د ID نسل

موږ د بشپړ پیژندونکو سره پیل وکړ. راځئ چې تصور وکړو چې موږ د یوې نوې ادارې لپاره بل لونګ ته اړتیا لرو. په ډیټابیس کې ترتیب مناسب نه دی، میزونه په شارډینګ کې ښکیل دي - دا معلومه شوه چې په DB1 کې یو پیغام ID = 1 او په DB1 کې یو پیغام ID = 2 شتون لري، تاسو نشئ کولی دا ID په Elasticsearch کې واچوئ، او نه په هیزلکاسټ کې ، مګر ترټولو بد شی دا دی که تاسو غواړئ د دوه ډیټابیسونو ډاټا په یو کې یوځای کړئ (د مثال په توګه ، پریکړه کول چې یو ډیټابیس د دې پیرودونکو لپاره کافي دی). تاسو کولی شئ په هیزلکاسټ کې ډیری اتومیک لونګونه اضافه کړئ او کاونټر هلته وساتئ ، بیا د نوي ID ترلاسه کولو فعالیت د انکریمینټ او ګیټ او هیزلکاسټ ته د غوښتنې لپاره وخت دی. مګر Hazelcast یو څه ډیر غوره لري - FlakeIdGenerator. کله چې د هر پیرودونکي سره اړیکه ونیسئ، دوی ته د ID رینج ورکول کیږي، د بیلګې په توګه، لومړی - له 1 څخه تر 10 پورې، دویم - له 000 څخه تر 10 پورې، او داسې نور. اوس پیرودونکی کولی شي نوي پیژندونکي پخپله جاري کړي تر هغه چې هغې ته صادر شوی حد پای ته ونه رسیږي. دا په چټکۍ سره کار کوي، مګر کله چې تاسو اپلیکیشن بیا پیل کړئ (او د هیزلکاسټ مراجع)، یو نوی ترتیب پیل کیږي - له همدې امله پریښودل، او نور. سربیره پردې، پراختیا کونکي په ریښتیا نه پوهیږي چې ولې IDs بشپړ دي، مګر خورا متضاد دي. موږ هرڅه وزن کړل او UUIDs ته مو واړول.

په هرصورت، د هغو کسانو لپاره چې غواړي د ټویټر په څیر وي، د سنوکاسټ کتابتون شتون لري - دا د هیزلکاسټ په سر کې د سنو فلیک تطبیق دی. تاسو یې دلته لیدلی شئ:

github.com/noctarius/snowcast
github.com/twitter/snowflake

مګر موږ نور دې ته نه یو رسیدلي.

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 داخل کړئ

لومړی، موږ پریکړه وکړه چې زموږ د ټولګیو شیان په هیزلکاسټ کې ثبت کړو. د مثال په توګه، موږ د غوښتنلیک ټولګي لرو، موږ غواړو چې دا خوندي او ولولئ. خوندي کول:

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 ترلاسه کول پیل کړل. هیزلکاسټ هڅه وکړه چې په شاخص کې اضافه کړي، مګر زموږ د ټولګي په اړه هیڅ نه پوهیدل او غوښتل یې چې د دې ټولګي سره یو 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 ته څلور سفرونه - ښه، دوه ډیټابیس ته - خراب

د ډیټا لپاره کیچ ته تلل تل ډیټابیس ته د تګ څخه غوره دي ، مګر تاسو نه غواړئ غیر کارول شوي ریکارډونه هم ذخیره کړئ. موږ د پرمختګ وروستي مرحلې پورې د څه شی کولو په اړه پریکړه پریږدو. کله چې نوی فعالیت کوډ شوی وي، موږ په PostgreSQL کې د ټولو پوښتنو لاګ کول (log_min_duration_statement to 0) او د 20 دقیقو لپاره د بار ازموینې پرمخ وړو. د راټول شوي لاګونو په کارولو سره د pgFouine او pgBadger په څیر اسانتیاوې کولی شي تحلیلي راپورونه رامینځته کړي. په راپورونو کې، موږ په ابتدايي توګه ورو او پرله پسې پوښتنو ته ګورو. د ورو پوښتنو لپاره، موږ د اجرا کولو پلان جوړوو (وضاحت) او ارزونه کوو چې ایا دا ډول پوښتنې ګړندۍ کیدی شي. د ورته ان پټ ډیټا لپاره بار بار غوښتنې په کیچ کې ښه فټ کیږي. موږ هڅه کوو چې پوښتنې "فلیټ" وساتو، د هرې پوښتنې یو میز.

عملیات

SV د آنلاین خدمت په توګه د 2017 په پسرلي کې په کار واچول شو، او د جلا محصول په توګه، SV د نومبر په 2017 کې خپور شو (په هغه وخت کې د بیټا نسخه حالت کې).

د عملیاتو له یو کال څخه ډیر وخت کې ، د CB آنلاین خدماتو عملیاتو کې کومه جدي ستونزه شتون نلري. موږ د آنلاین خدماتو له لارې څارنه کوو زبیبکس، څخه راټول او ځای په ځای کړئ بانسو.

د SV سرور توزیع د اصلي کڅوړو په بڼه چمتو کیږي: RPM، DEB، MSI. د وینډوز لپاره پلس موږ د یو واحد EXE په شکل کې یو واحد انسټالر چمتو کوو چې په یو ماشین کې سرور ، هیزلکاسټ او ایلیسټیسټیرچ نصبوي. موږ په پیل کې د نصب کولو دې نسخې ته د "ډیمو" نسخه په توګه اشاره وکړه، مګر دا اوس څرګنده شوه چې دا د ځای پرځای کولو خورا مشهور انتخاب دی.

سرچینه: www.habr.com