მოსკოვის ბირჟის სავაჭრო და კლირინგული სისტემის არქიტექტურის ევოლუცია. Ნაწილი 1

Სალამი ყველას! მე მქვია სერგეი კოსტანბაევი, ბირჟაზე ვავითარებ სავაჭრო სისტემის ბირთვს.

როდესაც ჰოლივუდის ფილმები აჩვენებენ ნიუ-იორკის საფონდო ბირჟას, ის ყოველთვის ასე გამოიყურება: ხალხის ბრბო, ყველა რაღაცას ყვირის, ფურცლებს აფრიალებს, სრული ქაოსია. ეს არასდროს მომხდარა აქ მოსკოვის ბირჟაზე, რადგან ვაჭრობა თავიდანვე ელექტრონულად ტარდებოდა და ეფუძნება ორ ძირითად პლატფორმას - Spectra (ფორექსის ბაზარი) და ASTS (სავალუტო, საფონდო და ფულის ბაზარი). დღეს კი მინდა ვისაუბრო ASTS სავაჭრო და კლირინგის სისტემის არქიტექტურის ევოლუციაზე, სხვადასხვა გადაწყვეტილებებსა და აღმოჩენებზე. სიუჟეტი გრძელი იქნება, ამიტომ მომიწია მისი გაყოფა ორ ნაწილად.

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

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

ცოტა ისტორია

1994 წელს მოსკოვის ბანკთაშორისი ვალუტის ბირჟაზე (MICEX) ამოქმედდა ავსტრალიური ASTS სისტემა და ამ მომენტიდან შეიძლება დაითვალოს რუსული ელექტრონული ვაჭრობის ისტორია. 1998 წელს მოხდა ბირჟის არქიტექტურის მოდერნიზება ინტერნეტ ვაჭრობის დანერგვის მიზნით. მას შემდეგ, ყველა სისტემასა და ქვესისტემებში ახალი გადაწყვეტილებების და არქიტექტურული ცვლილებების დანერგვის სიჩქარე მხოლოდ იმპულსს იძენს.

იმ წლებში გაცვლითი სისტემა მუშაობდა მაღალხარისხიან აპარატურაზე - ულტრა სანდო HP Superdome 9000 სერვერებზე (აშენებული PA-RISC), რომელშიც აბსოლუტურად ყველაფერი იყო დუბლირებული: შემავალი/გამომავალი ქვესისტემები, ქსელი, ოპერატიული მეხსიერება (ფაქტობრივად, იყო RAM-ის RAID მასივი), პროცესორები (ცხელი swappable). შესაძლებელი იყო ნებისმიერი სერვერის კომპონენტის შეცვლა აპარატის გაჩერების გარეშე. ჩვენ ვეყრდნობოდით ამ მოწყობილობებს და ჩავთვალეთ ისინი პრაქტიკულად უსაფრთხოდ. ოპერაციული სისტემა იყო Unix-ის მსგავსი HP UX სისტემა.

მაგრამ დაახლოებით 2010 წლიდან გაჩნდა ფენომენი, სახელწოდებით მაღალი სიხშირის ვაჭრობა (HFT), ან მაღალი სიხშირის ვაჭრობა - მარტივად რომ ვთქვათ, საფონდო ბირჟის რობოტები. სულ რაღაც 2,5 წელიწადში ჩვენს სერვერებზე დატვირთვა 140-ჯერ გაიზარდა.

ძველი არქიტექტურითა და აღჭურვილობით ასეთი დატვირთვის გაძლება შეუძლებელი იყო. საჭირო იყო როგორმე ადაპტაცია.

დაწყება

მოთხოვნები გაცვლის სისტემაში შეიძლება დაიყოს ორ ტიპად:

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

სქემატურად, სისტემის ბირთვი შეიძლება დაიყოს სამ დონეზე:

• კლიენტის დონე, რომელზეც მუშაობენ ბროკერები და კლიენტები. ისინი ყველა ურთიერთქმედებენ წვდომის სერვერებთან.
• Gateway სერვერები არის ქეშირების სერვერები, რომლებიც ადგილობრივად ამუშავებენ ყველა ინფორმაციის მოთხოვნას. გსურთ იცოდეთ რა ფასში იყიდება სბერბანკის აქციები ამჟამად? მოთხოვნა მიდის წვდომის სერვერზე.
• მაგრამ თუ გსურთ აქციების ყიდვა, მაშინ მოთხოვნა მიდის ცენტრალურ სერვერზე (Trade Engine). თითოეული ტიპის ბაზრისთვის არის ერთი ასეთი სერვერი, ისინი თამაშობენ სასიცოცხლო როლს, სწორედ მათთვის შევქმენით ეს სისტემა.

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

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

სისტემის პირველი ვერსია შეიცავდა Gateway-ის ორ დონეს და სავაჭრო სისტემის ცენტრალურ სერვერს. სამუშაოს მიმდინარეობა ასეთი იყო:

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

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

მას შემდეგ, რაც კოდი იყო ერთნაკადიანი, კლასიკური სქემა პროცესის ჩანგლებით გამოიყენებოდა მრავალი კლიენტის მოსამსახურებლად. თუმცა, ძალიან ძვირი ღირდა მთელი მონაცემთა ბაზის გაფუჭება, ამიტომ გამოიყენებოდა მსუბუქი სერვისის პროცესები, რომლებიც აგროვებდნენ პაკეტებს TCP სესიებიდან და გადაიტანდნენ მათ ერთ რიგში (SystemV Message Queue). Gateway და Trade Engine მუშაობდნენ მხოლოდ ამ რიგთან და იქიდან იღებდნენ ტრანზაქციებს შესასრულებლად. მასზე პასუხის გაგზავნა ვეღარ მოხერხდა, რადგან გაურკვეველი იყო, რომელ სერვის პროცესს უნდა წაეკითხა. ასე რომ, ჩვენ მივმართეთ ხრიკს: ყოველი ჩანგალი პროცესი ქმნიდა პასუხების რიგს თავისთვის და როდესაც მოთხოვნა შემოსულ რიგში შევიდა, მას დაუყოვნებლივ დაემატა პასუხის რიგის ტეგი.

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

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

პირველი მოდერნიზაცია

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

მაღალი სიხშირის ვაჭრობის გავლენა

არქიტექტურის ზემოაღნიშნული ვერსია არსებობდა 2010 წლამდე. იმავდროულად, ჩვენ აღარ ვიყავით კმაყოფილი HP Superdome სერვერების მუშაობით. გარდა ამისა, PA-RISC არქიტექტურა პრაქტიკულად მკვდარი იყო; გამყიდველს არ შესთავაზა რაიმე მნიშვნელოვანი განახლება. შედეგად, ჩვენ დავიწყეთ გადასვლა HP UX/PA RISC-დან Linux/x86-ზე. გადასვლა დაიწყო წვდომის სერვერების ადაპტაციით.

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

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

ამ 50 ms ინტერვალში საშუალო სიჩქარე არის დაახლოებით 16 ათასი ტრანზაქცია წამში. თუ ფანჯარას 20 ms-მდე დავამცირებთ, მივიღებთ საშუალო სიჩქარეს 90 ათასი ტრანზაქციის წამში, პიკზე 200 ათასი ტრანზაქცია. სხვა სიტყვებით რომ ვთქვათ, დატვირთვა არ არის მუდმივი, უეცარი აფეთქებებით. და მოთხოვნების რიგი ყოველთვის სწრაფად უნდა დამუშავდეს.

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

ევოლუციის ახალი რაუნდი

ვრცელი ტესტირებისა და კვლევის შემდეგ, ჩვენ გადავედით რეალურ დროში ოპერაციული სისტემის ბირთვზე. ამისთვის ჩვენ ავირჩიეთ RedHat Enterprise MRG Linux, სადაც MRG ნიშნავს შეტყობინებების რეალურ დროში ქსელს. რეალურ დროში პატჩების უპირატესობა ის არის, რომ ისინი ოპტიმიზაციას უკეთებენ სისტემას რაც შეიძლება სწრაფად შესასრულებლად: ყველა პროცესი მოთავსებულია FIFO რიგში, ბირთვების იზოლირება შესაძლებელია, არ არის ამოღება, ყველა ტრანზაქცია მუშავდება მკაცრი თანმიმდევრობით.

წითელი - რიგით მუშაობა ჩვეულებრივ ბირთვში, მწვანე - მუშაობს რეალურ დროში ბირთვში.

მაგრამ რეგულარულ სერვერებზე დაბალი შეყოვნების მიღწევა არც ისე ადვილია:

• SMI რეჟიმი, რომელიც x86 არქიტექტურაში წარმოადგენს მნიშვნელოვან პერიფერიულ მოწყობილობებთან მუშაობის საფუძველს, დიდად ერევა. ყველა სახის ტექნიკის ღონისძიების დამუშავება და კომპონენტებისა და მოწყობილობების მენეჯმენტი ხდება firmware-ის მიერ ეგრეთ წოდებული გამჭვირვალე SMI რეჟიმში, რომელშიც ოპერაციული სისტემა საერთოდ ვერ ხედავს რას აკეთებს firmware. როგორც წესი, ყველა მსხვილი გამყიდველი გვთავაზობს სპეციალურ გაფართოებებს firmware სერვერებისთვის, რომლებიც საშუალებას გაძლევთ შეამციროთ SMI დამუშავების რაოდენობა.
• არ უნდა იყოს დინამიური კონტროლი პროცესორის სიხშირეზე, ეს იწვევს დამატებით შეფერხებას.
• როდესაც ფაილური სისტემის ჟურნალი იშლება, ბირთვში ხდება გარკვეული პროცესები, რომლებიც იწვევს არაპროგნოზირებად შეფერხებებს.
• ყურადღება უნდა მიაქციოთ ისეთ საკითხებს, როგორიცაა CPU Affinity, Interrupt Affinity, NUMA.

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

PA-RISC სერვერებიდან x86-ზე გადასვლისას, პრაქტიკულად არ დაგვჭირდა სისტემის კოდის დიდი შეცვლა, ჩვენ უბრალოდ მოვახდინეთ მისი ადაპტაცია და კონფიგურაცია. ამავდროულად, ჩვენ გამოვასწორეთ რამდენიმე ხარვეზი. მაგალითად, იმ ფაქტის შედეგები, რომ PA RISC იყო დიდი ენდიური სისტემა, ხოლო x86 იყო პატარა ენდიანი სისტემა, სწრაფად გამოჩნდა: მაგალითად, მონაცემები არასწორად იყო წაკითხული. უფრო რთული შეცდომა ის იყო, რომ PA RISC იყენებს თანმიმდევრულად თანმიმდევრული (თანმიმდევრულად თანმიმდევრული) მეხსიერების წვდომა, ხოლო x86-ს შეუძლია წაკითხვის ოპერაციების გადალაგება, ამიტომ კოდი, რომელიც აბსოლუტურად მოქმედი იყო ერთ პლატფორმაზე, გატეხილია მეორეზე.

x86-ზე გადასვლის შემდეგ, შესრულება თითქმის სამჯერ გაიზარდა, ტრანზაქციის დამუშავების საშუალო დრო 60 μs-მდე შემცირდა.

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

ცხელი სარეზერვო ეპოსი

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

გარდა ამისა, იყო სხვა მოთხოვნები:

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

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

შედეგად მივედით შემდეგ სქემამდე:

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

  

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

სქემა შემდეგნაირად მუშაობდა.

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

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

გაგრძელდება.

წყარო: www.habr.com