როგორ და რატომ დავწერეთ მაღალი დატვირთვის მასშტაბირებადი სერვისი 1C-სთვის: Enterprise: Java, PostgreSQL, Hazelcast

ამ სტატიაში ვისაუბრებთ იმაზე, თუ როგორ და რატომ განვვითარდით ურთიერთქმედების სისტემა – მექანიზმი, რომელიც გადასცემს ინფორმაციას კლიენტის აპლიკაციებსა და 1C:Enterprise სერვერებს შორის - ამოცანის დაყენებიდან არქიტექტურასა და განხორციელების დეტალებზე ფიქრამდე.

ურთიერთქმედების სისტემა (შემდგომში SV) არის განაწილებული, შეცდომის ტოლერანტული შეტყობინებების სისტემა გარანტირებული მიწოდებით. SV შექმნილია როგორც მაღალი დატვირთვის სერვისი მაღალი მასშტაბურობით, ხელმისაწვდომი როგორც ონლაინ სერვისის სახით (მოწოდებული 1C-ის მიერ) და როგორც მასობრივი წარმოების პროდუქტი, რომელიც შეიძლება განთავსდეს თქვენს საკუთარ სერვერზე.

SV იყენებს განაწილებულ საცავს თხილი და საძიებო სისტემა ელასტიური ძებნა. ჩვენ ასევე ვისაუბრებთ Java-ზე და იმაზე, თუ როგორ გავაფართოვოთ PostgreSQL ჰორიზონტალურად.

პრობლემის შესახებ განცხადება

იმის გასაგებად, თუ რატომ შევქმენით ურთიერთქმედების სისტემა, მე გეტყვით ცოტას, თუ როგორ მუშაობს ბიზნეს აპლიკაციების განვითარება 1C-ში.

დასაწყისისთვის, ცოტა ჩვენს შესახებ მათთვის, ვინც ჯერ კიდევ არ იცის რას ვაკეთებთ :) ჩვენ ვამზადებთ 1C:Enterprise ტექნოლოგიურ პლატფორმას. პლატფორმა მოიცავს ბიზნეს აპლიკაციების შემუშავების ინსტრუმენტს, ასევე გაშვების დროს, რომელიც საშუალებას აძლევს ბიზნეს აპლიკაციებს აწარმოონ კროს-პლატფორმულ გარემოში.

კლიენტ-სერვერის განვითარების პარადიგმა

1C:Enterprise-ზე შექმნილი ბიზნეს აპლიკაციები მუშაობს სამ დონეზე კლიენტის სერვერი არქიტექტურა „DBMS – აპლიკაციის სერვერი – კლიენტი“. აპლიკაციის კოდი ჩაწერილია ჩაშენებული 1C ენა, შეიძლება შესრულდეს აპლიკაციის სერვერზე ან კლიენტზე. აპლიკაციის ობიექტებთან (დირექტორიები, დოკუმენტები და ა.შ.) ყველა სამუშაო, ასევე მონაცემთა ბაზის კითხვა და ჩაწერა ხორციელდება მხოლოდ სერვერზე. ფორმების ფუნქციონირება და ბრძანების ინტერფეისი ასევე დანერგილია სერვერზე. კლიენტი ახორციელებს ფორმების მიღებას, გახსნას და ჩვენებას, მომხმარებელთან „კომუნიკაციას“ (გაფრთხილებები, კითხვები...), მცირე გამოთვლებს ფორმებში, რომლებიც საჭიროებენ სწრაფ პასუხს (მაგალითად, ფასის რაოდენობაზე გამრავლება), ლოკალურ ფაილებთან მუშაობას, აღჭურვილობასთან მუშაობა.

აპლიკაციის კოდში პროცედურებისა და ფუნქციების სათაურებში ცალსახად უნდა იყოს მითითებული, თუ სად შესრულდება კოდი - &AtClient / &AtServer დირექტივების გამოყენებით (&AtClient / &AtServer ენის ინგლისურ ვერსიაში). 1C დეველოპერები ახლა შემისწორებენ იმით, რომ დირექტივები რეალურად არის მეტი, მაგრამ ჩვენთვის ეს ახლა არ არის მნიშვნელოვანი.

თქვენ შეგიძლიათ დარეკოთ სერვერის კოდი კლიენტის კოდიდან, მაგრამ არ შეგიძლიათ კლიენტის კოდის გამოძახება სერვერის კოდიდან. ეს არის ფუნდამენტური შეზღუდვა, რომელიც ჩვენ შევქმენით მრავალი მიზეზის გამო. კერძოდ, იმის გამო, რომ სერვერის კოდი უნდა იყოს დაწერილი ისე, რომ ის შესრულდეს იმავე გზით, სადაც არ უნდა იყოს დაძახებული - კლიენტიდან თუ სერვერიდან. ხოლო სერვერის კოდის სხვა სერვერის კოდიდან გამოძახების შემთხვევაში, კლიენტი, როგორც ასეთი, არ არსებობს. და იმის გამო, რომ სერვერის კოდის შესრულების დროს კლიენტს, რომელმაც მას დაურეკა, შეეძლო დახუროს, გასულიყო აპლიკაციიდან და სერვერს აღარ ეყოლება ვინმე დასარეკად.

კოდი, რომელიც ამუშავებს ღილაკზე დაწკაპუნებას: კლიენტისგან სერვერის პროცედურის გამოძახება იმუშავებს, სერვერიდან კლიენტის პროცედურის გამოძახება არა

ეს ნიშნავს, რომ თუ ჩვენ გვსურს სერვერის მხრიდან კლიენტის აპლიკაციაში გაგზავნა, მაგალითად, რომ "გრძელვადიანი" ანგარიშის გენერაცია დასრულდა და ანგარიშის ნახვა შესაძლებელია, ასეთი მეთოდი არ გვაქვს. თქვენ უნდა გამოიყენოთ ხრიკები, მაგალითად, პერიოდულად გამოკითხოთ სერვერი კლიენტის კოდიდან. მაგრამ ეს მიდგომა ატვირთავს სისტემას არასაჭირო ზარებით და ზოგადად არ გამოიყურება ძალიან ელეგანტური.

და ასევე არის საჭიროება, მაგალითად, როდესაც სატელეფონო ზარი მოდის SIP- ზარის განხორციელებისას შეატყობინეთ ამის შესახებ კლიენტის აპლიკაციას, რათა მან გამოიყენოს აბონენტის ნომერი, რათა იპოვოს იგი კონტრაგენტის მონაცემთა ბაზაში და აჩვენოს მომხმარებლის ინფორმაცია მოწოდებული კონტრაგენტის შესახებ. ან, მაგალითად, როდესაც შეკვეთა მოვა საწყობში, ამის შესახებ აცნობეთ მომხმარებლის კლიენტის აპლიკაციას. ზოგადად, არის ბევრი შემთხვევა, როდესაც ასეთი მექანიზმი გამოდგება.

თავად წარმოება

შექმენით შეტყობინებების მექანიზმი. სწრაფი, საიმედო, გარანტირებული მიწოდებით, შეტყობინებების მოქნილად ძიების შესაძლებლობით. მექანიზმიდან გამომდინარე, განახორციელეთ მესინჯერი (შეტყობინებები, ვიდეო ზარები), რომელიც მუშაობს 1C აპლიკაციებში.

შეიმუშავეთ სისტემა ისე, რომ ჰორიზონტალურად მასშტაბირებადი იყოს. მზარდი დატვირთვა უნდა დაიფაროს კვანძების რაოდენობის გაზრდით.

Реализация

ჩვენ გადავწყვიტეთ, რომ არ გაგვეერთიანებინა SV სერვერის ნაწილი პირდაპირ 1C:Enterprise პლატფორმაში, არამედ განვახორციელოთ იგი ცალკეულ პროდუქტად, რომლის API შეიძლება დარეკოთ 1C აპლიკაციის გადაწყვეტილებების კოდიდან. ეს გაკეთდა მრავალი მიზეზის გამო, რომელთაგან მთავარი იყო ის, რომ მე მინდოდა გამეკეთებინა შეტყობინებების გაცვლა სხვადასხვა 1C აპლიკაციებს შორის (მაგალითად, ვაჭრობის მენეჯმენტსა და ბუღალტრულ აღრიცხვას შორის). სხვადასხვა 1C აპლიკაციები შეიძლება იმუშაონ 1C:Enterprise პლატფორმის სხვადასხვა ვერსიაზე, განთავსდეს სხვადასხვა სერვერებზე და ა.შ. ასეთ პირობებში, SV-ის, როგორც ცალკეული პროდუქტის დანერგვა, რომელიც მდებარეობს 1C ინსტალაციების „გვერდით“ არის ოპტიმალური გადაწყვეტა.

ასე რომ, გადავწყვიტეთ SV გაგვეკეთებინა, როგორც ცალკე პროდუქტი. ჩვენ გირჩევთ, რომ მცირე კომპანიებმა გამოიყენონ CB სერვერი, რომელიც ჩვენ დავაინსტალირეთ ჩვენს ღრუბელში (wss://1cdialog.com), რათა თავიდან აიცილონ ზედმეტი ხარჯები, რომლებიც დაკავშირებულია სერვერის ლოკალურ ინსტალაციასთან და კონფიგურაციასთან. მსხვილ კლიენტებს შეიძლება მიზანშეწონილი აღმოჩნდნენ საკუთარი CB სერვერის დაყენება მათ ობიექტებში. ჩვენ გამოვიყენეთ მსგავსი მიდგომა ჩვენს ღრუბლოვან SaaS პროდუქტში 1cFresh - ის იწარმოება, როგორც მასობრივი წარმოების პროდუქტი კლიენტების საიტებზე ინსტალაციისთვის და ასევე განლაგებულია ჩვენს ღრუბელში https://1cfresh.com/.

განაცხადის

დატვირთვისა და შეცდომების ტოლერანტობის გასანაწილებლად, ჩვენ განვათავსებთ არა ერთ Java აპლიკაციას, არამედ რამდენიმე, მათ წინ დატვირთვის ბალანსერით. თუ თქვენ გჭირდებათ შეტყობინების გადატანა კვანძიდან კვანძზე, გამოიყენეთ გამოქვეყნება/გამოწერა Hazelcast-ში.

კლიენტსა და სერვერს შორის კომუნიკაცია ხდება ვებსოკეტის საშუალებით. ის კარგად შეეფერება რეალურ დროში სისტემებს.

განაწილებული ქეში

ჩვენ ავირჩიეთ Redis, Hazelcast და Ehcache-ს შორის. 2015 წელია. რედისმა ახლახან გამოუშვა ახალი კლასტერი (ზედმეტად ახალი, საშინელი), არის Sentinel უამრავი შეზღუდვით. Ehcache-მ არ იცის როგორ შეიკრიბოს კლასტერში (ეს ფუნქცია მოგვიანებით გამოჩნდა). ჩვენ გადავწყვიტეთ გამოგვეცადა ის Hazelcast 3.4-ით.
Hazelcast იკრიბება კასეტურად ყუთიდან. ერთი კვანძის რეჟიმში ის არ არის ძალიან გამოსადეგი და შეიძლება გამოყენებულ იქნას მხოლოდ ქეშად - მან არ იცის როგორ გადააგდოს მონაცემები დისკზე, თუ დაკარგავ ერთადერთ კვანძს, კარგავ მონაცემებს. ჩვენ ვაყენებთ რამდენიმე Hazelcast-ს, რომელთა შორისაც ვაკეთებთ კრიტიკულ მონაცემებს. ჩვენ არ ვაკეთებთ ქეშის სარეზერვო ასლს - ჩვენ არ გვაწუხებს ეს.

ჩვენთვის Hazelcast არის:

• მომხმარებლის სესიების შენახვა. ყოველ ჯერზე სესიისთვის მონაცემთა ბაზაში წასვლას დიდი დრო სჭირდება, ამიტომ ყველა სესიას ვათავსებთ Hazelcast-ში.
• ქეში. თუ თქვენ ეძებთ მომხმარებლის პროფილს, შეამოწმეთ ქეში. დაწერა ახალი მესიჯი - ჩადეთ ქეშში.
• აპლიკაციის ინსტანციებს შორის კომუნიკაციის თემები. კვანძი ქმნის მოვლენას და ათავსებს მას Hazelcast თემაში. ამ თემაზე გამოწერილი სხვა აპლიკაციის კვანძები იღებენ და ამუშავებენ ღონისძიებას.
• კასეტური საკეტები. მაგალითად, ჩვენ ვქმნით დისკუსიას უნიკალური გასაღების გამოყენებით (ერთჯერადი დისკუსია 1C მონაცემთა ბაზაში):

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

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

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

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

ჩვენ შევამოწმეთ, რომ არხი არ არის. ავიღეთ საკეტი, ისევ შევამოწმეთ და შევქმენით. თუ საკეტს არ შეამოწმებთ საკეტის აღების შემდეგ, მაშინ არის შანსი, რომ სხვა თემაც შემოწმდეს იმ მომენტში და ახლა შეეცდება შექმნას იგივე დისკუსია - მაგრამ ის უკვე არსებობს. თქვენ არ შეგიძლიათ ჩაკეტოთ სინქრონიზებული ან რეგულარული java Lock-ის გამოყენებით. მონაცემთა ბაზის საშუალებით - ეს ნელია და სამწუხაროა მონაცემთა ბაზისთვის; Hazelcast-ის საშუალებით - ეს არის ის, რაც გჭირდებათ.

DBMS-ის არჩევა

ჩვენ გვაქვს PostgreSQL-თან მუშაობისა და ამ DBMS-ის დეველოპერებთან თანამშრომლობის დიდი და წარმატებული გამოცდილება.

ეს ადვილი არ არის PostgreSQL კლასტერთან - არის XL, XC, ციტუსის, მაგრამ, ზოგადად, ეს არ არის NoSQL-ები, რომლებიც სკალირებას ახდენენ. ჩვენ არ მივიჩნიეთ NoSQL მთავარ საცავად; საკმარისი იყო, რომ ავიღეთ Hazelcast, რომლებთანაც აქამდე არ გვიმუშავია.

თუ თქვენ გჭირდებათ რელაციური მონაცემთა ბაზის მასშტაბირება, ეს ნიშნავს დაქუცმაცება. მოგეხსენებათ, sharding-ით ჩვენ ვყოფთ მონაცემთა ბაზას ცალკეულ ნაწილებად, რათა თითოეული მათგანი განთავსდეს ცალკე სერვერზე.

ჩვენი დაშლის პირველი ვერსია ითვალისწინებდა ჩვენი აპლიკაციის თითოეული ცხრილის განაწილების შესაძლებლობას სხვადასხვა სერვერებზე სხვადასხვა პროპორციით. A სერვერზე ბევრი შეტყობინებაა - გთხოვთ, გადავიტანოთ ამ ცხრილის ნაწილი B სერვერზე. ეს გადაწყვეტილება უბრალოდ ყვიროდა ნაადრევი ოპტიმიზაციის შესახებ, ამიტომ გადავწყვიტეთ შემოვიფარგლოთ საკუთარი თავი მრავალბინიანი მიდგომით.

თქვენ შეგიძლიათ წაიკითხოთ მრავალბინიანის შესახებ, მაგალითად, ვებსაიტზე ციტუსის მონაცემები.

SV-ს აქვს განაცხადის და აბონენტის ცნებები. აპლიკაცია არის ბიზნეს აპლიკაციის სპეციფიკური ინსტალაცია, როგორიცაა ERP ან Accounting, თავისი მომხმარებლებით და ბიზნეს მონაცემებით. აბონენტი არის ორგანიზაცია ან ფიზიკური პირი, რომლის სახელითაც აპლიკაცია რეგისტრირებულია SV სერვერზე. აბონენტს შეუძლია დაარეგისტრიროს რამდენიმე აპლიკაცია და ამ აპლიკაციებს შეუძლიათ შეტყობინებების გაცვლა ერთმანეთთან. აბონენტი გახდა მოიჯარე ჩვენს სისტემაში. რამდენიმე აბონენტის შეტყობინებები შეიძლება განთავსდეს ერთ ფიზიკურ მონაცემთა ბაზაში; თუ ჩვენ ვხედავთ, რომ აბონენტმა დაიწყო დიდი ტრაფიკის გენერირება, გადავიტანთ მას ცალკე ფიზიკურ მონაცემთა ბაზაში (ან თუნდაც ცალკე მონაცემთა ბაზის სერვერზე).

ჩვენ გვაქვს ძირითადი მონაცემთა ბაზა, სადაც მარშრუტიზაციის ცხრილი ინახება ყველა აბონენტის მონაცემთა ბაზის მდებარეობის შესახებ.

იმისთვის, რომ ძირითადი მონაცემთა ბაზა არ იყოს ბოთლი, ჩვენ ვინახავთ მარშრუტიზაციის ცხრილს (და სხვა ხშირად საჭირო მონაცემებს) ქეშში.

თუ აბონენტის მონაცემთა ბაზა შენელებას დაიწყებს, მას შიგნით დავჭრით დანაყოფებად. სხვა პროექტებზე ვიყენებთ pg_pathman.

ვინაიდან მომხმარებლის შეტყობინებების დაკარგვა ცუდია, ჩვენ ვინახავთ მონაცემთა ბაზებს რეპლიკებით. სინქრონული და ასინქრონული რეპლიკების კომბინაცია საშუალებას გაძლევთ დაიზღვიოთ თავი ძირითადი მონაცემთა ბაზის დაკარგვის შემთხვევაში. შეტყობინების დაკარგვა მოხდება მხოლოდ იმ შემთხვევაში, თუ პირველადი მონაცემთა ბაზა და მისი სინქრონული რეპლიკა ერთდროულად ვერ ხერხდება.

თუ სინქრონული რეპლიკა დაიკარგება, ასინქრონული რეპლიკა ხდება სინქრონული.
თუ ძირითადი მონაცემთა ბაზა დაიკარგება, სინქრონული რეპლიკა ხდება ძირითადი მონაცემთა ბაზა, ხოლო ასინქრონული რეპლიკა ხდება სინქრონული რეპლიკა.

Elastics-ის ძიება საძიებლად

ვინაიდან, სხვა საკითხებთან ერთად, SV ასევე არის მესინჯერი, ის მოითხოვს სწრაფ, მოსახერხებელ და მოქნილ ძიებას, მორფოლოგიის გათვალისწინებით, არაზუსტი შესატყვისების გამოყენებით. ჩვენ გადავწყვიტეთ არ გამოგვეგონა ბორბალი და გამოვიყენოთ უფასო საძიებო სისტემა Elasticsearch, რომელიც შექმნილია ბიბლიოთეკის საფუძველზე ლუსენი. ჩვენ ასევე ვაყენებთ Elasticsearch-ს კლასტერში (მასტერ - მონაცემები - მონაცემები) პრობლემების აღმოსაფხვრელად აპლიკაციის კვანძების წარუმატებლობის შემთხვევაში.

github-ზე ვიპოვეთ რუსული მორფოლოგიის მოდული Elasticsearch-ისთვის და გამოიყენეთ იგი. Elasticsearch ინდექსში ვინახავთ სიტყვების ფესვებს (რომელსაც დანამატი განსაზღვრავს) და N-გრამებს. როდესაც მომხმარებელი შეაქვს ტექსტს საძიებლად, ჩვენ ვეძებთ აკრეფილ ტექსტს N-გრამებს შორის. ინდექსში შენახვისას სიტყვა „ტექსტები“ დაიყოფა შემდეგ N-გრამებად:

[ისინი, ტეკ, ტექსი, ტექსტი, ტექსტები, ეკ, ყოფილი, ექსტ, ტექსტები, კს, ქს, ქსტი, ქ, სტი, შენ],

და შენარჩუნდება სიტყვა „ტექსტის“ ძირიც. ეს მიდგომა საშუალებას გაძლევთ მოძებნოთ სიტყვის დასაწყისში, შუაში და ბოლოს.

Დიდი სურათი

გაიმეორეთ სურათი სტატიის დასაწყისიდან, მაგრამ განმარტებებით:

• ინტერნეტში გამოვლენილი ბალანსერი; ჩვენ გვაქვს nginx, ეს შეიძლება იყოს ნებისმიერი.
• Java აპლიკაციის ინსტანციები ერთმანეთთან ურთიერთობენ Hazelcast-ის საშუალებით.
• ჩვენ ვიყენებთ ვებ სოკეტთან მუშაობისთვის ნეთი.
• Java აპლიკაცია დაწერილია Java 8-ში და შედგება პაკეტებისგან OSGi. გეგმები მოიცავს Java 10-ზე მიგრაციას და მოდულებზე გადასვლას.

განვითარება და ტესტირება

SV-ის შემუშავებისა და ტესტირების პროცესში ჩვენ შევხვდით ჩვენს მიერ გამოყენებული პროდუქტების არაერთ საინტერესო მახასიათებელს.

ჩატვირთვის ტესტირება და მეხსიერების გაჟონვა

თითოეული SV გამოშვების გამოშვება მოიცავს დატვირთვის ტესტირებას. წარმატებულია, როდესაც:

• ტესტმა რამდენიმე დღე იმუშავა და სერვისის შეფერხებები არ ყოფილა
• საკვანძო ოპერაციებზე რეაგირების დრო არ აღემატებოდა კომფორტულ ზღვარს
• მუშაობის გაუარესება წინა ვერსიასთან შედარებით არ არის 10% -ზე მეტი

ჩვენ ვავსებთ სატესტო მონაცემთა ბაზას მონაცემებით - ამისათვის ვიღებთ ინფორმაციას ყველაზე აქტიური აბონენტის შესახებ წარმოების სერვერიდან, ვამრავლებთ მის ნომრებს 5-ზე (შეტყობინებების, დისკუსიების, მომხმარებლების რაოდენობა) და ვამოწმებთ ამ გზით.

ჩვენ ვატარებთ ურთიერთქმედების სისტემის დატვირთვის ტესტირებას სამ კონფიგურაციაში:

1. სტრეს ტესტი
2. მხოლოდ კავშირები
3. აბონენტის რეგისტრაცია

სტრეს ტესტის დროს ჩვენ გავუშვით რამდენიმე ასეული თემა და ისინი იტვირთება სისტემას შეუჩერებლად: შეტყობინებების წერა, დისკუსიების შექმნა, შეტყობინებების სიის მიღება. ჩვენ ვაკეთებთ ჩვეულებრივი მომხმარებლების მოქმედებების სიმულაციას (მიიღეთ ჩემი წაუკითხავი შეტყობინებების სია, მივწერე ვინმეს) და პროგრამული გადაწყვეტილებები (სხვადასხვა კონფიგურაციის პაკეტის გადაცემა, განგაშის დამუშავება).

მაგალითად, ასე გამოიყურება სტრეს ტესტის ნაწილი:

• მომხმარებელი შედის სისტემაში
  • ითხოვს თქვენს წაუკითხავ დისკუსიებს
  • 50% სავარაუდოდ წაიკითხავს შეტყობინებებს
  • 50% სავარაუდოდ ტექსტს
  • შემდეგი მომხმარებელი:
    • აქვს ახალი დისკუსიის შექმნის 20% შანსი
    • შემთხვევით ირჩევს მის რომელიმე დისკუსიას
    • შიგნით მიდის
    • ითხოვს შეტყობინებებს, მომხმარებლის პროფილებს
    • ქმნის ხუთ შეტყობინებას შემთხვევითი მომხმარებლების მისამართით ამ დისკუსიიდან
    • ტოვებს დისკუსიას
    • მეორდება 20-ჯერ
    • გამოდის, ბრუნდება სცენარის დასაწყისში

  • ჩეთბოტი შედის სისტემაში (აპლიკაციის კოდიდან შეტყობინებების მიბაძვა)
    • აქვს 50% შანსი შექმნას ახალი არხი მონაცემთა გაცვლისთვის (სპეციალური განხილვა)
    • 50% სავარაუდოდ დაწერს შეტყობინებას რომელიმე არსებულ არხზე

"მხოლოდ კავშირების" სცენარი გაჩნდა მიზეზით. არის სიტუაცია: მომხმარებლებმა დააკავშირეს სისტემა, მაგრამ ჯერ არ ჩაერთნენ. თითოეული მომხმარებელი დილის 09:00 საათზე რთავს კომპიუტერს, ამყარებს კავშირს სერვერთან და დუმს. ეს ბიჭები სახიფათოა, ბევრი მათგანია - ერთადერთი პაკეტები, რაც მათ აქვთ არის PING/PONG, მაგრამ ისინი ინარჩუნებენ კავშირს სერვერთან (მათ არ შეუძლიათ ამის შენარჩუნება - რა მოხდება, თუ ახალი შეტყობინებაა). ტესტი ასახავს სიტუაციას, როდესაც ასეთი მომხმარებლების დიდი რაოდენობა ცდილობს სისტემაში შესვლას ნახევარ საათში. ეს სტრეს ტესტის მსგავსია, მაგრამ მისი ფოკუსირება სწორედ ამ პირველ შეყვანაზეა - ისე, რომ არ მოხდეს წარუმატებლობები (ადამიანი არ იყენებს სისტემას და ის უკვე იშლება - ძნელია რაიმე უარესის მოფიქრება).

აბონენტთა რეგისტრაციის სკრიპტი იწყება პირველი გაშვებიდან. ჩავატარეთ სტრეს ტესტი და დავრწმუნდით, რომ მიმოწერის დროს სისტემა არ შენელებულა. მაგრამ მომხმარებლები მოვიდნენ და რეგისტრაცია წარუმატებელი გახდა ტაიმაუტის გამო. რეგისტრაციისას გამოვიყენეთ / dev / შემთხვევითი, რომელიც დაკავშირებულია სისტემის ენტროპიასთან. სერვერს არ ჰქონდა დრო საკმარისი ენტროპიის დასაგროვებლად და როდესაც მოითხოვეს ახალი SecureRandom, ის გაიყინა ათობით წამით. ამ სიტუაციიდან მრავალი გამოსავალი არსებობს, მაგალითად: გადაერთეთ ნაკლებად უსაფრთხო /dev/urandom-ზე, დააინსტალირეთ სპეციალური დაფა, რომელიც წარმოქმნის ენტროპიას, წინასწარ გენერირება შემთხვევითი რიცხვები და შეინახეთ ისინი აუზში. დროებით დავხურეთ აუზთან დაკავშირებული პრობლემა, მაგრამ მას შემდეგ ახალი აბონენტების რეგისტრაციისთვის ცალკე ტესტირებას ვაწარმოებთ.

ჩვენ ვიყენებთ როგორც დატვირთვის გენერატორს ჯმეტერი. მან არ იცის როგორ იმუშაოს websocket-თან, მას სჭირდება მოდული. პირველი ძიების შედეგებში შეკითხვისთვის "jmeter websocket" არის: სტატიები BlazeMeter-დან, რომელიც გირჩევთ მოდული Maciej Zaleski-ის მიერ.

სწორედ აქედან გადავწყვიტეთ დაწყება.

სერიოზული ტესტირების დაწყებისთანავე, ჩვენ აღმოვაჩინეთ, რომ JMeter-მა მეხსიერების გაჟონვა დაიწყო.

დანამატი ცალკე დიდი ამბავია; 176 ვარსკვლავით, მას აქვს 132 ჩანგალი github-ზე. თავად ავტორს ამის ვალდებულება არ მიუღია 2015 წლიდან (ჩვენ ავიღეთ 2015 წელს, შემდეგ ეჭვი არ გაჩენილა), რამდენიმე გიტჰუბის პრობლემა მეხსიერების გაჟონვასთან დაკავშირებით, 7 დაუხურავი ამოღების მოთხოვნა.
თუ გადაწყვეტთ ჩაატაროთ დატვირთვის ტესტირება ამ მოდულის გამოყენებით, გთხოვთ, ყურადღება მიაქციოთ შემდეგ დისკუსიებს:

1. მრავალ ხრახნიან გარემოში გამოიყენეს რეგულარული LinkedList და შედეგი იყო 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).

ეს არის ერთ-ერთი მათგანი github-ზე. რაც ჩვენ გავაკეთეთ:

1. აიღეს ჩანგალი ელირან კოგანი (@elyrank) – ასწორებს 1 და 3 პრობლემებს
2. მოგვარებული პრობლემა 2
3. განახლებულია ბორცვი 9.2.14-დან 9.3.12-მდე
4. შეფუთული SimpleDateFormat ThreadLocal-ში; SimpleDateFormat არ არის ძაფისთვის უსაფრთხო, რამაც განაპირობა NPE გაშვების დროს
5. დაფიქსირდა მეხსიერების კიდევ ერთი გაჟონვა (კავშირი არასწორად დაიხურა გათიშვისას)

და მაინც ის მიედინება!

მეხსიერების ამოწურვა დაიწყო არა ერთ დღეში, არამედ ორში. დრო აღარ იყო დარჩენილი, ამიტომ გადავწყვიტეთ ნაკლები თემების გაშვება, მაგრამ ოთხ აგენტზე. ეს საკმარისი უნდა ყოფილიყო მინიმუმ ერთი კვირის განმავლობაში.

ორი დღე გავიდა...

ახლა Hazelcast-ს მეხსიერება ამოეწურა. ჟურნალებმა აჩვენა, რომ რამდენიმე დღის ტესტირების შემდეგ, ჰეზელკასტმა დაიწყო ჩივილი მეხსიერების ნაკლებობაზე და გარკვეული პერიოდის შემდეგ კლასტერი დაიშალა და კვანძები სათითაოდ განაგრძობდნენ სიკვდილს. ჩვენ დავუკავშირეთ JVisualVM hazelcast-ს და ვნახეთ „ამომავალი ხერხი“ - ის რეგულარულად უწოდებდა GC-ს, მაგრამ მეხსიერების გასუფთავება ვერ მოხერხდა.

აღმოჩნდა, რომ hazelcast 3.4-ში, რუკის / მულტიმაპის წაშლისას (map.destroy()), მეხსიერება მთლიანად არ არის განთავისუფლებული:

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

შეცდომა ახლა გამოსწორებულია 3.5-ში, მაგრამ მაშინ პრობლემა იყო. ჩვენ შევქმენით ახალი multiMaps დინამიური სახელებით და წავშალეთ ისინი ჩვენი ლოგიკის მიხედვით. კოდი ასე გამოიყურებოდა:

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");

multiMap შეიქმნა თითოეული გამოწერისთვის და წაიშალა, როცა არ იყო საჭირო. გადავწყვიტეთ, რომ დაგვეწყო Map , გასაღები იქნება გამოწერის სახელი, ხოლო მნიშვნელობები იქნება სესიის იდენტიფიკატორები (საიდანაც საჭიროების შემთხვევაში შეგიძლიათ მიიღოთ მომხმარებლის იდენტიფიკატორები).

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-თან ჩვენი გამოცდილების შესახებ

Hazelcast ჩვენთვის ახალი პროდუქტი იყო, ჩვენ დავიწყეთ მასთან მუშაობა 3.4.1 ვერსიიდან, ახლა ჩვენი წარმოების სერვერი მუშაობს 3.9.2 ვერსიაზე (წერის მომენტში Hazelcast-ის უახლესი ვერსია არის 3.10).

ID გენერაცია

ჩვენ დავიწყეთ მთელი რიცხვის იდენტიფიკატორებით. წარმოვიდგინოთ, რომ ჩვენ გვჭირდება კიდევ ერთი ლონგი ახალი ერთეულისთვის. მონაცემთა ბაზაში თანმიმდევრობა არ არის შესაფერისი, ცხრილები ჩართულია დაქუცმაცებაში - გამოდის, რომ DB1-ში არის შეტყობინების ID=1 და DB1-ში შეტყობინების ID=2, ამ ID-ს ვერც Elasticsearch-ში ჩადებ და ვერც Hazelcast-ში. , მაგრამ ყველაზე ცუდი ის არის, თუ გსურთ ორი მონაცემთა ბაზიდან მონაცემების ერთში გაერთიანება (მაგალითად, გადაწყვიტეთ, რომ ერთი მონაცემთა ბაზა საკმარისია ამ აბონენტებისთვის). თქვენ შეგიძლიათ დაამატოთ რამდენიმე AtomicLongs Hazelcast-ში და იქ შეინახოთ მრიცხველი, შემდეგ ახალი ID-ის მოპოვების შესრულება არის incrementAndGet პლუს Hazelcast-ისთვის მოთხოვნის დრო. მაგრამ Hazelcast-ს აქვს რაღაც უფრო ოპტიმალური - FlakeIdGenerator. თითოეულ კლიენტთან დაკავშირებისას მათ ეძლევათ ID დიაპაზონი, მაგალითად, პირველი - 1-დან 10-მდე, მეორეს - 000-დან 10-მდე და ა.შ. ახლა კლიენტს შეუძლია დამოუკიდებლად გასცეს ახალი იდენტიფიკატორები, სანამ მასზე გაცემული დიაპაზონი არ დასრულდება. ის სწრაფად მუშაობს, მაგრამ როდესაც თქვენ გადატვირთავთ აპლიკაციას (და Hazelcast კლიენტს), იწყება ახალი თანმიმდევრობა - აქედან გამომდინარე, გამოტოვებები და ა.შ. გარდა ამისა, დეველოპერებს ნამდვილად არ ესმით, რატომ არის ID-ები მთელი რიცხვი, მაგრამ ისინი ასე არათანმიმდევრულია. ყველაფერი ავწონეთ და UUID-ზე გადავედით.

სხვათა შორის, მათთვის, ვისაც Twitter მოსწონს, არის ასეთი Snowcast ბიბლიოთეკა - ეს არის Snowflake-ის განხორციელება Hazelcast-ის თავზე. მისი ნახვა შეგიძლიათ აქ:

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 შეფერხების გარეშე

პირველ რიგში, გადავწყვიტეთ ჩაგვეწერა ჩვენი კლასების ობიექტები Hazelcast-ში. მაგალითად, ჩვენ გვაქვს Application კლასი, გვინდა მისი შენახვა და წაკითხვა. Გადარჩენა:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

წაკითხვა:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

ყველაფერი მუშაობს. შემდეგ ჩვენ გადავწყვიტეთ შეგვექმნა ინდექსი Hazelcast-ში, რათა მოძებნოთ:

map.addIndex("subscriberId", false);

და ახალი ერთეულის დაწერისას, მათ დაიწყეს ClassNotFoundException-ის მიღება. Hazelcast-მა სცადა დაემატებინა ინდექსში, მაგრამ არაფერი იცოდა ჩვენი კლასის შესახებ და სურდა ამ კლასით JAR მიეწოდებინა მას. ჩვენ სწორედ ეს გავაკეთეთ, ყველაფერი მუშაობდა, მაგრამ გამოჩნდა ახალი პრობლემა: როგორ განვაახლოთ JAR კლასტერის სრულად შეჩერების გარეშე? Hazelcast არ იღებს ახალ 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 წლის ნოემბერში (იმ დროს ბეტა ვერსიის სტატუსში).

ფუნქციონირების ერთ წელზე მეტი ხნის განმავლობაში CB ონლაინ სერვისის მუშაობაში სერიოზული პრობლემები არ ყოფილა. ჩვენ ვაკვირდებით ონლაინ სერვისს ზაბქსი, შეგროვება და განლაგება Bamboo.

SV სერვერის განაწილება მოწოდებულია მშობლიური პაკეტების სახით: RPM, DEB, MSI. პლუს Windows-ისთვის ჩვენ გთავაზობთ ერთ ინსტალერს ერთი EXE-ის სახით, რომელიც დააინსტალირებს სერვერს, Hazelcast-ს და Elasticsearch-ს ერთ მანქანაზე. ჩვენ თავდაპირველად ინსტალაციის ამ ვერსიას ვუწოდებდით, როგორც „დემო“ ვერსიას, მაგრამ ახლა ცხადი გახდა, რომ ეს არის ყველაზე პოპულარული განლაგების ვარიანტი.

წყარო: www.habr.com