როგორ მუშაობს WebSocket კავშირი არქიტექტურაში — როდის იქმნება და ვინ ვისთან კომუნიკაციას ახორციელებს?
Senior
227
Golang
8384
0
როგორ გადავიტანოთ ფანჯარა სლაიდინგ ვინდოუს ალგორითმში?
Senior
226
შეგიძლიათ თქვენი მიმდინარე შემოსავლის დონე მიუთითოთ?
Junior — Middle
225
გააზიარეთ ყველაზე რთული და საინტერესო დავალება, რომელსაც გადაწყვეტდით, განსაკუთრებით არქიტექტურული გამოცდილების შესახებ.
Senior
225
ახლა მოსკოვში ცხოვრობ? რომელ ქალაქს განიხილავ? განიხილავ ჰიბრიდული სამუშაო ფორმატს? რომელ ეტაპზე ხარ ძიებაში?
Senior
225
გაქვთ სხვა აქტიური ინტერვიუ პროცესები?
Senior
222
ბოლო დროს მუშაობის დროს გუნდის შემადგენლობა რა იყო?
Junior — Middle
221
როგორ ინტეგრირდება და გამოისახება ეს მეტრიკული მონაცემები Grafana-ში?
Junior — Middle
221
მასშტაბირებადი შეტყობინების სისტემის პროექტირება, რომელიც მხარს უჭერს 150 მილიონ მომხმარებელს, 75 მილიონ DAU-ს, 225 მილიონ MAU-ს, 1.2 მილიონ წაკითხვას / 300k დაწერას QPS-ზე, 5 მილიონ ერთდროულ მომხმარებელს, 60 PB ახალი მონაცემებს წელიწადში, 30%-იანი წლიური ზრდით, P99 <200 მს წაკითხვისთვის, <300 მს დაწერისთვის, SLA 99.95%. კონტექსტი საჭიროა განაწილებული შეტყობინების სისტემის პროექტირება, რომელიც მსგავსია WhatsApp-ის, რომელიც მხარს უჭერს 1:1 და ჯგუფურ ჩატებს, უზრუნველყოფს შეტყობინებების მიწოდებას, მომხმარებლების ონლაინ სტატუსების ჩვენებას და მულტიმედიური ფაილების გადაცემას (ფოტოები, ვიდეოები, აუდიო). სისტემა უნდა უზრუნველყოს მაღალი ხელმისაწვდომობა და დაბალი ლატენტურობა, მხარი დაუჭიროს მაღალი პარალელიზმს და გლობალურ დონეზე გაფართოვდეს. ფუნქციური მოთხოვნები - მხარდაჭერა პირად (1:1) და ჯგუფურ ჩატებს, მონაწილეების დამატებისა/ამოღების შესაძლებლობით - ტექსტური შეტყობინებების და მულტიმედიური ფაილების გაგზავნა და მიღება ნეფუნქციური მოთხოვნები: - არ არსებობს გამოკვეთილი end-to-end დაშიფვრის განხორციელება სერვისების ან მომხმარებლების დონეზე, გარდა ზოგადი შენიშვნის. - არ არის ნათლად აღწერილი sharding და რეპლიკაცია ბაზების chat_id ან user_id მიხედვით, გაფართოებისა და შეცდომების წინააღმდეგობისთვის. - არ არსებობს გამოკვეთილი კომპონენტი ან მექანიზმი offline შეტყობინებების სინქრონიზაციის და მიწოდების ცნობებისთვის. - არ არის ნათელი, როგორ ხორციელდება დატვირთვის ბალანსი მონაცემთა ბაზებსა და სერვისებს შორის, განსაკუთრებით პიკების დროს. **მნიშვნელოვანი საკითხები, რომელთა გათვალისწინებაც საჭიროა:** (დიაგრამა აჩვენებს არქიტექტურას Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage და CDN-თან ერთად)
Senior
220
როგორ შეიძლება გაუმჯობესდეს Map მონაცემთა სტრუქტურაში ელემენტების მოძებნის ეფექტიანობა?
Junior — Middle
220
რა პრობლემაა ამჟამინდელ map განახლებაში სამუშაოში (tasksRes[t.id][task{...}])?
Middle+
219
შენ გაქვს მოქმედი GitHub ან LinkedIn?
Senior
218
მოკლედ მოყევით, რა საქმიანობით იყავით დაკავებული წინა სამუშაო ადგილებზე და რა ფუნქციებს განახორციელეთ.
Middle+
216
[სახელი] მიუთითებს მეხსიერების შეფასებაში შეუთანხმებლობაზე: ერთს აცხადებს, მეორეს წერს. როგორ უნდა შეფასდეს მეხსიერება სწორად?
Senior
215
/* ჩვენს უნდა გადავცეთ მონაცემები გარკვეული წყაროდან გარკვეულ მომხმარებელს. ამ დროს წყარო მცირე პარტიებს აძლევს (~ ათეულობით ჩანაწერი), ხოლო მომხმარებელი ოპტიმალურად მუშაობს დიდ პარტიებთან (~ ათასობით ჩანაწერი). რეალური მაგალითი - მონაცემების მიწოდება Kafka ტიპის რიგებიდან Clickhouse ბაზაში. წყარო: - პირობითად უსასრულო. - წყარო არასდროს აბრუნებს MaxItems-ზე მეტ ჩანაწერს ერთ გამოძახებაზე Next. - ერთ "სესიაში" (ფუნქცია Pipe-ის ერთ გამოძახებაში) წყარო ყოველ ჯერზე ახალ მონაცემებს აბრუნებს. - თუმცა, გადატვირთვის შემდეგ წყარო დაიწყებს წინა "დადასტურებულ" პოზიციიდან, რომელიც cookie-სით არის განსაზღვრული. ამიტომ, თითოეული მნიშვნელობა cookie-ს, რომელიც Next-ის გამოძახებამ დააბრუნა, უნდა იყოს დადასტურებული Commit-ის გამოძახებით, და ეს უნდა მოხდეს ზუსტად იმავე სერიაში, სადაც Next-მა დააბრუნა. მიღება: - არ შეუძლია ერთდროულად MaxItems-ზე მეტი დამუშავება. ძირითადი დონე: ფუნქცია func Pipe(p Producer, c Consumer) error-ის განხორციელება, რომელიც წყაროდან მონაცემებს კითხულობს, მათ დიდ ბუფერში აგროვებს და შემდეგ იღებს მას მიმღებში, და პროგრესს წყაროსთან ერთად განახლებას. რთულობა: Next, Process და Commit მეთოდები დაკავშირებულია ქსელურ გამოძახებებთან და შეიძლება დიდხანს გაგრძელდეს. მოსწრაფვისთვის, მონაცემების წაკითხვა, ჩაწერა და პროგრესის დადასტურება პარალელურად უნდა მოხდეს. ასე რომ, Process ან Commit-ის გამოძახების დროს, წყაროსგან კითხვა და ახალი ბუფერის შექმნა გაგრძელდეს. */
Senior
213
150 მილიონი მომხმარებლის მხარდაჭერით მასშტაბირებადი შეტყობინებების სისტემის პროექტირება, რომელიც მხარს უჭერს 75 მილიონ DAU-ს, 225 მილიონ MAU-ს, 1.2M წაკითხვას / 300k დაწერას პიკ QPS-ზე, 5 მილიონ ერთდროულ მომხმარებელს, 60 PB ახალი მონაცემებით წელიწადში, 30%-იანი წლიური ზრდით, SLA 99.95%, p99 <200 ms წაკითხვისთვის, <300 ms დაწერისთვის. საკვანძო კონტექსტი აუცილებელია პროექტირება განაწილებული შეტყობინებების სისტემის, რომელიც მსგავსია WhatsApp-ის, რომელიც მხარს უჭერს 1:1 და ჯგუფურ ჩატებს, უზრუნველყოფს შეტყობინებების მიწოდებას, მომხმარებლების ონლაინ სტატუსებს და მულტიმედია ფაილების (ფოტოები, ვიდეოები, აუდიო) გადაცემას. სისტემა უნდა უზრუნველყოს მაღალი ხელმისაწვდომობა და დაბალი ლაგი, მხარი დაუჭიროს მაღალი პარალელიზმს და გლობალურად მასშტაბირდეს. ფუნქციური მოთხოვნები - მხარდაჭერა პირადი (1:1) და ჯგუფური ჩატებისთვის, მონაწილეების დამატებისა/ამოღების შესაძლებლობით - ტექსტური შეტყობინებების და მულტიმედია ფაილების გაგზავნა და მიღება არ ჩანს end-to-end დაშიფვრის მექანიზმის მკაფიო განხორციელება სერვისების ან მომხმარებლების დონეზე, გარდა ზოგადი შენიშვნის. - არ არის მკაფიო აღწერა sharding-ის და რეპლიკაციის შესახებ chat_id ან user_id-ის მიხედვით, მასშტაბურობის და შეცდომების წინააღმდეგობისთვის. - არ არსებობს მკაფიო კომპონენტი ან მექანიზმი offline შეტყობინებების და მიწოდების დადასტურებების სინქრონიზაციისთვის. - არ არის ნათელი, როგორ ხორციელდება დატვირთვის ბალანსი მონაცემთა ბაზებსა და სერვისებს შორის, განსაკუთრებით პიკების დროს. **მნიშვნელოვანი საკითხები, რომლებიც უნდა განიხილოს:**
Senior
213
/* PostgreSQL-ის ორი სერვერი არსებობს: * PROD - OLTP სერვერი, * STATS - სერვერი გრძელვადიანი ანალიტიკური შეკვეთებისთვის. მიმდინარე სერვერზე, prod მონაცემთა ბაზაში, არსებობს დიდი (10Tb) ცხრილი შემდეგი სტრუქტურით: CREATE TABLE profiles( id SERIAL, data JSONB ) ცხრილში შეიძლება იყოს "ფუჭი ადგილები", ანუ ზოგი `id` შეიძლება გამოტოვებული იყოს. პროგრამის დაწერა საჭიროა, რომელიც კოპირებს ცხრილს profiles PROD-დან STATS-მდე. განსაზღვრილია, რომ გამოიყენება შემდეგი ინტერფეისები მონაცემთა ბაზებთან მუშაობისთვის: type Row []interface{} type Database interface { // ინტერფეისის რეალიზაცია შეუძლია კავშირების აღდგენა // SaveRows-ის გამოძახება არის იდემპოტენტური io.Closer GetMaxID(ctx context.Context) (uint64, error) LoadRows(ctx context.Context, minID, maxID uint64) ([]Row, error) // [minID, maxID] SaveRows(ctx context.Context, rows []Row) error } func Connect(ctx context.Context, dbname string) (Database, error) // CopyTable // თუ full=false, განაგრძეთ მონაცემების გადაცემა წინა შეცდომის ადგილიდან // თუ full=true, გადაიტანეთ ყველა მონაცემი func CopyTable(fromName string, toName string, full bool) error { // ... თქვენი კოდი } თუ გადაეცემა ვარიანტი `full=false`, პროგრამა უნდა განაგრძოს მონაცემების გადაცემა წინა შეცდომის ადგილიდან. თუ `full=true`, უნდა გადაიტანოს ყველა მონაცემი. **ძირითადი დონე**: - მონაცემების სერიული გადაცემა ერთ ნაკადში - შეცდომის შემდეგ აღდგენა (ვარიანტი `full=false`) დამატებითი ინფორმაცია: - თუ საჭიროია, შეგიძლიათ ინტერფეისი გააფართოვოთ თქვენი საკუთარი მეთოდებით - თუ საჭიროია, შეგიძლიათ პირდაპირ გამოიყენოთ **database/sql** პაკეტი
Senior
213
გთხოვთ, ისაუბრეთ თქვენს ბოლო პროექტზე — რა არის და რა საქმიანობას აკეთებთ მასში?
Senior
213
Տրված է նիշերի շղթա։ Գտեք i և j ցուցանիշների զույգը (i <= j), որոնց միջև, ներառյալ, կրկնվող նիշեր չկան։ "aba" շղթայի համար պատասխանն է 5: [0, 0] ("a") [0, 1] ("ab") [1, 1] ("b") [1, 2] ("ba") [2, 2] ("a") "abcb" շղթայի համար պատասխանն է ?: aba 3 + 2 = 5 abcb 4 (a, b, c, d) + 1 (ab) + 1 (bc) + 1 (cb) + 1 (abc) = 8
Intern
211
არსებობს თუ არა რაიმე ვადა?
Senior
211