ფართომასშტაბიანმა ონლაინ აპლიკაციებმა დიდი გზა გაიარა წინა ორი ათწლეულის განმავლობაში. ამ ინოვაციებმა შეცვალა ჩვენი წარმოდგენა პროგრამული უზრუნველყოფის განვითარების შესახებ. მაგალითად, Facebook, Instagram და Twitter არის მასშტაბური პლატფორმები.
ეს სისტემები უნდა აშენდეს ტრაფიკისა და მონაცემების დიდი მოცულობის სამართავად, რადგან მილიარდობით ადამიანი იყენებს მათ ერთდროულად მთელ მსოფლიოში. ეს არის როდესაც სისტემის დიზაინი შედის სურათზე.
სისტემის არქიტექტურის, ინტერფეისების და მონაცემების დადგენის პროცესი, რომელიც აკმაყოფილებს გარკვეულ კრიტერიუმებს, ცნობილია როგორც სისტემის დიზაინი. შეკრული და ეფექტური სისტემების მეშვეობით, სისტემის დიზაინი აკმაყოფილებს თქვენი ბიზნესის ან ორგანიზაციის მოთხოვნებს.
მას შემდეგ რაც თქვენი კომპანია ან ორგანიზაცია განსაზღვრავს თავის კრიტერიუმებს, შეგიძლიათ დაიწყოთ მათი ჩართვა ფიზიკურ სისტემის დიზაინში, რომელიც აკმაყოფილებს თქვენი მომხმარებლების მოთხოვნებს.
აირჩევთ თუ არა შეკვეთით განვითარებას, კომერციულ გადაწყვეტილებებს თუ ამ ორის კომბინაციას, თქვენი სისტემის დიზაინი განსაზღვრავს როგორ ააშენებთ მას.
ჩვენ დეტალურად განვიხილავთ Twitter-ის ვადების სისტემურ დიზაინს ამ პოსტში, ინსტრუქციასთან ერთად. Დავიწყოთ.
ნაბიჯი 1: გამოიკვეთეთ გამოყენების შემთხვევა და შეზღუდვები
Გამოყენების შემთხვევაში
- მომხმარებელი ატვირთავს ტვიტს.
- სერვისი აგზავნის პრეს შეტყობინებებს და ელ.წერილს ტვიტების მიმდევრებს.
- მომხმარებლის ქრონოლოგიის ნახვა (აქტივობა მომხმარებლისგან)
- მომხმარებელი უყურებს სახლის ვადებს (აქტივობა ხალხისგან, რომელსაც მომხმარებელი თვალს ადევნებს)
- საკვანძო სიტყვები იძებნება მომხმარებლის მიერ.
- სერვისი ნამდვილად ხელმისაწვდომია.
ფარგლებს გარეთ
- ტვიტები იგზავნება Twitter Firehose-ზე და სხვა ნაკადებზე ამ სერვისის გამოყენებით.
- სერვისი შლის ტვიტებს მომხმარებლის ხილვადობის პარამეტრების საფუძველზე.
- თუ მომხმარებელი ასევე არ მიჰყვება იმ პირს, რომელსაც უპასუხეს, დამალეთ პასუხი.
- დააკვირდით „რეტვიტების დამალვას“ პარამეტრს.
- ანალიტიკა
შეზღუდვები და ვარაუდები
სახელმწიფო ვარაუდები
- მოძრაობა თანაბრად არ ნაწილდება.
- მარტივი უნდა იყოს ტვიტის გაგზავნა.
- თუ არ გყავთ მილიონობით მიმდევარი, თქვენი ყველა მიმდევრისთვის ტვიტის გაგზავნა სწრაფი უნდა იყოს.
- 100 მილიონი აქტიური მომხმარებელია.
- 15 მილიარდი ტვიტი ყოველთვიურად ან 500 მილიონი ტვიტი ყოველდღე
- თითოეულ ტვიტს აქვს საშუალოდ 10 მიწოდება.
- ყოველდღე, fanout აწვდის 5 მილიარდ ტვიტს.
- Fanout ყოველთვიურად აწვდის 150 მილიარდ ტვიტს.
- 250 მილიარდი ყოველთვიური წაკითხვის მოთხოვნა
- 10 მილიარდი ყოველთვიური ძებნა
Timeline
- დროის ხაზი უნდა იყოს მარტივი ნავიგაცია.
- Twitter უფრო კითხვაა, ვიდრე წერა.
- ოპტიმიზაცია ტვიტების სწრაფი წაკითხვისთვის
- ტვიტების მოხმარება შრომატევადია.
ძებნა
- ძიების პროცესი უნდა იყოს სწრაფი.
- ძიებას დრო სჭირდება.
გამოთვალეთ მოხმარება
თითოეული ტვიტის ზომა:
- 8 ბაიტი ტვიტის ID
- 32 ბაიტი მომხმარებლის ID
- 140 ბაიტი ტექსტი
- მედია – საშუალოდ 10 კბ
- სულ: ~10 KB
ყოველთვიურად, 150 ტბაიტი ახალი ტვიტის შინაარსი გენერირებულია.
- * 500 მილიონი ტვიტი ყოველდღე * 30 დღე თვეში * 10 KB თითო ტვიტზე
- სამი წლის განმავლობაში იყო 5.4 PB ახალი ტვიტის შინაარსი.
ყოველ წამში 100,000 XNUMX წაკითხვის მოთხოვნაა.
- * (400 მოთხოვნა წამში / 1 მილიარდი მოთხოვნა თვეში) 250 მილიარდი წაკითხვის მოთხოვნა ყოველთვიურად
ყოველ წამში არის 6,000 ტვიტი.
- * (400 მოთხოვნა წამში / 1 მილიარდი მოთხოვნა თვეში) 15 მილიარდი ტვიტი ყოველთვიურად
ფანაუტზე ყოველ წამში 60 ათასი ტვიტი იგზავნება.
- Fanout აწვდის 150 მილიარდ ტვიტს ყოველთვიურად* (400 მოთხოვნა წამში / 1 მილიარდი მოთხოვნა თვეში).
ყოველ წამში 4,000 მოთხოვნა ინფორმაციის მისაღებად
- * (400 მოთხოვნა წამში / 1 მილიარდი მოთხოვნა თვეში) 10 მილიარდი ძებნა ყოველთვიურად
ზოგიერთი სასარგებლო კონვერტაცია
- ყოველთვიურად 2.5 მილიონი წამი გადის.
- თვეში 2.5 მილიონი მოთხოვნა წამში 1 მოთხოვნით
- თვეში 100 მილიონი მოთხოვნა x 40 მოთხოვნა წამში
- 1 მილიარდი მოთხოვნა თვეში = 400 მოთხოვნა წამში
ნაბიჯი 2: მაღალი დონის დიაგრამა
ნაბიჯი 3: ძირითადი კომპონენტების ახსნა
ჩვენ შეგვიძლია შევინახოთ მომხმარებლის საკუთარი ტვიტები, რათა შევსებულიყო მომხმარებლის ვადები (მომხმარებლის აქტივობა) ურთიერთდამოკიდებულ მონაცემთა ბაზაში, თუ ისინი წარადგენენ ტვიტს. უფრო რთულია ტვიტების მიწოდება და სახლის ვადების შემუშავება (აქტივობა იმ პირებისგან, რომლებსაც მომხმარებელი მიჰყვება).
ტიპიური რელაციური მონაცემთა ბაზა გადატვირთული იქნება ყველა მიმდევრისთვის ტვიტების გავრცელებით (60 ათასი ტვიტი იგზავნება ყოველ წამში). ჩვენ, ალბათ, გვინდა ვიყოთ სწრაფი ჩაწერის მონაცემთა შესანახად, როგორიცაა NoSQL მონაცემთა ბაზა ან მეხსიერების ქეში.
მეხსიერებიდან 1 MB თანმიმდევრულად წაკითხვას დაახლოებით 250 მიკროწამი სჭირდება, მაგრამ SSD-დან კითხვას 4-ჯერ მეტი დრო სჭირდება, ხოლო დისკიდან კითხვას 80-ჯერ მეტი დრო სჭირდება.
Object Store შეიძლება გამოყენებულ იქნას ისეთი მონაცემების შესანახად, როგორიცაა სურათები და ვიდეო.
- ვებ სერვერი, რომელიც მოქმედებს როგორც საპირისპირო პროქსი, იღებს ტვიტს კლიენტისგან.
- მოთხოვნა იგზავნება Write API სერვერზე ვებ სერვერის მიერ.
- Write API ინახავს ტვიტს SQL მონაცემთა ბაზაში მომხმარებლის ვადებში.
Fan-Out სერვისს დაუკავშირდება Write API და ის ასრულებს შემდეგ დავალებებს.
- პოულობს მომხმარებლის მიმდევრებს მეხსიერების ქეშში მომხმარებლის გრაფიკის სერვისის შეკითხვით.
- მეხსიერების ქეშზე, ტვიტი ინახება მომხმარებლის მიმდევრების მთავარ ვადებში.
- 1,000 მიმდევარი = 1,000 ძიება და ჩასმა = O(n) ოპერაცია.
- ტვიტი ინახება Search Index Service-ში სწრაფი ძიებისთვის.
- Object Store გამოიყენება მედიის შესანახად.
- უგზავნის push-შეტყობინებებს მიმდევრებს შეტყობინებების სერვისის მეშვეობით.
- გაფრთხილებების ასინქრონულად გასაგზავნად, ის იყენებს რიგს.
ჩვენ შეგვიძლია გამოვიყენოთ მშობლიური Redis სია შემდეგი სტრუქტურით, თუ ჩვენი მეხსიერების ქეში არის Redis:
მომხმარებლის სახლის ვადები განახლდება ახალი ტვიტით, რომელიც შეინახება მეხსიერების ქეშში. ჩვენ გამოვიყენებთ შემდეგ საჯარო REST API-ს:
მომხმარებლის ვადებს მომხმარებელი ნახულობს.
- ვებ სერვერი იღებს მომხმარებლის ვადების მოთხოვნას კლიენტისგან.
- მოთხოვნა იგზავნება Read API სერვერზე ვებ სერვერის მიერ.
- Read API ითხოვს SQL მონაცემთა ბაზას მომხმარებლის ვადისთვის.
REST API იმუშავებს სახლის ქრონოლოგიის მსგავსად, გარდა იმისა, რომ ყველა ტვიტი წარმოიქმნება მომხმარებლისგან და არა იმ ადამიანებისგან, რომლებსაც ისინი მიჰყვებიან.
მომხმარებელი ეძებს საკვანძო სიტყვებს:
- ვებ სერვერი იღებს ძებნის მოთხოვნას კლიენტისგან.
- მოთხოვნა იგზავნება Search API სერვერზე ვებ სერვერის მიერ.
ნაბიჯი 4: Twitter-ის ვადები
ვადების შექმნა რთული ამოცანაა. საჭიროა ვადების გენერირების სერვერი, რომელიც უკავშირდება ვებ ან აპლიკაციის სერვერებს.
ყოველ ჯერზე, როდესაც მომხმარებელი შედის სისტემაში, დროის ხაზის სერვისი აკონტროლებს მომხმარებლების უახლეს ტვიტებს მიმდევრების ცხრილში და ანახლებს ან განაახლებს მომხმარებლის ვადებს.
ჩვენ აქ არ ვახორციელებთ რაიმე სახის რეიტინგის სისტემას; ამის ნაცვლად, ჩვენ ვვარაუდობთ, რომ მომხმარებლის მიმდევრების ტოპ 5 ტვიტი წარმოდგენილია თაიმლაინში შექმნის დროის მიხედვით. ჩვენ შეგვიძლია შევინარჩუნოთ 50-ტვიტის განახლების შეწყვეტა. ჩვენ კვლავ ვწყვეტთ განახლებას ან ვადების შექმნას ამ ზღურბლის მიღწევის შემდეგ, სანამ მომხმარებელი არ განაახლებს გვერდს.
მაღალი შეყოვნება და მუშაობის შეშფოთება გამოწვეული იქნება პირდაპირი მომხმარებლის არხის შექმნით. ამის ნაცვლად, ოფლაინ ნაკადის შექმნა, რომელიც შეიძლება მყისიერად იყოს წარმოდგენილი, საუკეთესო გზაა მუშაობის გასაუმჯობესებლად. გაუშვით გამოყოფილი ქრონოლოგიის სერვერები, რომლებიც რეგულარულად უგზავნიან აპლიკაციის სერვერს, რათა განაახლონ არხი მისი შექმნის დროის მიხედვით.
რეიტინგის ალგორითმმა უნდა გაითვალისწინოს გადამწყვეტი სიგნალები და უზრუნველყოს წონა, რათა გარანტირებული იყოს, რომ მომხმარებლის ვადებში არ დომინირებს მასალა ერთი ან რამდენიმე ანგარიშიდან, რომელსაც ისინი მიჰყვებიან.
უფრო ზუსტად, ჩვენ შეგვიძლია ავირჩიოთ ფუნქციები, რომლებიც დაკავშირებულია ნებისმიერი არხის ერთეულის შესაბამისობასთან, როგორიცაა მოწონებების რაოდენობა, კომენტარები, გაზიარებები და განახლების დრო. თითოეული ეს კრიტერიუმი უნდა იქნას გამოყენებული ტვიტის შესაფასებლად, შემდეგ კი ეს რანგი უნდა იყოს გამოყენებული ტვიტების თაიმლაინზე საჩვენებლად.
მუდმივად უნდა გავაფრთხილოთ მომხმარებლები, როცა მათი ახალი შინაარსის ახალი კონტენტი ხელმისაწვდომი გახდება? მომხმარებლებისთვის სასარგებლოა გაფრთხილება, როდესაც ახალი მონაცემები გახდება ხელმისაწვდომი. თუმცა, მობილურ მოწყობილობებზე, როდესაც მონაცემთა გამოყენება საკმაოდ ძვირია, ამან შეიძლება დაკარგოს სიჩქარე.
შედეგად, ჩვენ შეგვიძლია ავირჩიოთ არ გადავიტანოთ მონაცემები მობილურ მოწყობილობებზე და ნაცვლად მივცეთ მომხმარებლებს „გაახლოთ“ ახალი პოსტებისთვის.
ნაბიჯი 5: სკალირების დიზაინი
პოტენციური შეფერხება არის Fanout სერვისი. ტვიტერის მომხმარებლებს მილიონობით მიმდევარი მოუწევთ რამდენიმე წუთის ლოდინი მათი ტვიტების გასავრცელებლად. ამან შეიძლება გამოიწვიოს რბოლა ტვიტზე პასუხებით, რასაც ავიცილებთ თავიდან ტვიტების სერვისის დროს ხელახლა შეკვეთით.
ჩვენ ასევე შეგვეძლო თავიდან ავიცილოთ ტვიტების გავრცელება იმ ადამიანებისგან, რომლებსაც მიმდევრების დიდი რაოდენობა აქვთ. ამის ნაცვლად, ჩვენ შეგვიძლია მოვძებნოთ ტვიტები იმ ადამიანების მხრიდან, რომლებსაც ძალიან ხშირად ადევნებთ თვალს, გავაერთიანოთ ძიების შედეგები მომხმარებლის სახლის ქრონოლოგიის შედეგებთან და შემდეგ შევუკვეთოთ ტვიტები სერვისის დროს.
დამატებითი გაუმჯობესებები მოიცავს:
- შეინახეთ მხოლოდ რამდენიმე ასეული ტვიტი მეხსიერების ქეშში თითოეული სახლის ქრონოლოგიისთვის.
- მეხსიერების ქეშში შენახულია მხოლოდ აქტიური მომხმარებლების სახლის ვადების შესახებ ინფორმაცია.
- ჩვენ შეგვიძლია აღვადგინოთ ქრონოლოგია SQL მონაცემთა ბაზიდან, თუ მომხმარებელი არ იყო აქტიური წინა 30 დღის განმავლობაში.
- იმის გასარკვევად, თუ ვინ არის მომხმარებელი, გამოიყენეთ მომხმარებლის გრაფიკის სერვისი.
- დაამატეთ ტვიტები მეხსიერების ქეშში მათი SQL მონაცემთა ბაზიდან ამოღებით.
- Tweet Info Service-ს შეუძლია მხოლოდ ერთი თვის ღირებულების ტვიტების დაზოგვა.
- მომხმარებლის ინფორმაციის სერვისში მხოლოდ აქტიური მომხმარებლები ინახება.
- დაბალი შეყოვნების შესანარჩუნებლად, საძიებო კლასტერს, სავარაუდოდ, დასჭირდება ტვიტების მეხსიერებაში შენარჩუნება.
დასკვნა
მიუხედავად იმისა, რომ Twitter არის დიდი ორგანიზაცია, მას აქვს უკეთესი სისტემის დიზაინის გაგება. მე ყველაფერი გავაკეთე, რომ მოგაწოდოთ მაღალი დონის მიმოხილვა Twitter-ის ვადების შესახებ.
ვიმედოვნებ, რომ მისგან სასარგებლო ინფორმაცია მიიღეთ და შეძლებთ მის გამოყენებას.
დატოვე პასუხი