Golang

Mērogo ziņojumu sistēmas projektēšana, kas atbalsta 150 miljonus lietotāju, 75 miljonus DAU, 225 miljonus MAU, 1,2 miljonus lasījumu / 300 tūkstošus rakstu QPS, 5 miljonus vienlaicīgu lietotāju, 60 PB jaunu datu gadā, 30% gada pieaugumu, P99 <200 ms lasīšanai, <300 ms rakstīšanai, SLA 99,95%. KONTEKSTS Nepieciešams izstrādāt izplatītu ziņojumu sistēmu, līdzīgu WhatsApp, kas atbalsta 1:1 un grupu tērzēšanu, nodrošina ziņojumu piegādi, parāda lietotāju tiešsaistes statusus un pārsūta multimediju failus (attēlus, video, audio). Sistēma jānodrošina ar augstu pieejamību un zemu latentumu, jāatbalsta augsts paralēlisms un jāpaplašina globālā mērogā. FUNKCIONĀLIE PRASĪBAS - Atbalsts personīgiem (1:1) un grupu tērzēšanas ar iespēju pievienot/noņemt dalībniekus - Teksta ziņojumu un multimediju failu sūtīšana un saņemšana NEFUNKCIONĀLIE PRASĪBAS - Nav skaidras end-to-end šifrēšanas īstenošanas pakalpojumu vai klientu līmenī, izņemot vispārēju piezīmi. - Nav skaidri aprakstīts sharding un replikācija datu bāzēs pēc chat_id vai user_id, lai nodrošinātu mērogojamību un kļūdu tolerance. - Nav skaidrs komponentu vai mehānisma offline ziņojumu sinhronizācijai un piegādes apliecinājumiem. - Nav skaidrs, kā tiek veikta slodzes balansēšana starp datu bāzēm un pakalpojumiem, īpaši plūsmu laikā. **Svarīgi aspekti, kas jāņem vērā:** (Diagrama rāda arhitektūru ar Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage un CDN)

Senior

Яндекс

220

Kāda bija pēdējā darba komandas sastāvs?

Junior — Middle

Яндекс

219

Vai tev ir aktīvs GitHub vai LinkedIn?

Senior

Яндекс

218

Pastāsti īsi, ar ko nodarbojies iepriekšējās darba vietās un kādas funkcijas esi realizējis.

Middle+

Яндекс

214

Kā ir strukturēti testi komandā — kas ko raksta, kāda ir pārklājuma, vai ir E2E?

Senior

Яндекс

213

/* Mums nepieciešams nodot datus no noteikta avota noteiktam patērētājam. Šajā gadījumā avots sniedz mazākas partijas (~ desmitiem ierakstu), bet patērētājs efektīvāk strādā ar lielākām partijām (~ tūkstošiem ierakstu). Reāls piemērs - datu nodošana no Kafka tipa rindām uz Clickhouse datu bāzi. Avots: - Puslīdz bezgalīgs. - Avots nekad neatgriež vairāk par MaxItems ierakstiem vienā Next izsaukumā. - Vienā "sesijā" (viena Pipe funkcijas izsaukuma laikā) avots katru reizi atgriež jaunus datus. - Tomēr, pārstartējot, avots atsāks no iepriekšējās "apstiprinātās" pozīcijas, kas norādīta ar cookie. Tādēļ katra vērtība, ko atgrieza Next izsaukums, pēc datu saglabāšanas saņēmējam, ir jāapstiprina ar Commit izsaukumu, un tas jāveic tieši tajā pašā secībā, kurā tie tika atgriezti ar Next. Saņēmējs: - Nevar apstrādāt vairāk par MaxItems vienlaikus. Galvenais līmenis: Jāievieš funkcija func Pipe(p Producer, c Consumer) error, kura lasa datus no avota, tos grupē buferī, kura izmērs nav lielāks par MaxItems, un saglabā saņēmējā, tad atjauno progresu avotā. Grūtības: Next, Process un Commit metodes ir saistītas ar tīkla izsaukumiem un var darboties diezgan ilgi. Lai paātrinātu datu pārraidi, nepieciešams paralēli veikt lasīšanu, ierakstīšanu un apstiprināšanu. Tādējādi, izsaucot Process vai Commit, turpinās lasīšana no avota un jauna bufera veidošana. */

Senior

Яндекс

213

Kā uzlabot elementu meklēšanas efektivitāti Map datu struktūrā?

Junior — Middle

Яндекс

212

Plānojot mēru skalojamu ziņojumapmaiņas sistēmu, kas atbalsta 150 miljonus lietotāju, ar 75 miljoniem DAU, 225 miljoniem MAU, 1,2 miljoniem peak QPS lasīšanai / 300k rakstīšanai, 5 miljoniem vienlaicīgu lietotāju, ar 60 PB jauniem datiem gadā, 30% gada pieaugumu, SLA 99,95%, p99 <200 ms lasīšanai, <300 ms rakstīšanai. KONTEKSTS Nepieciešams izstrādāt izplatītu ziņojumapmaiņas sistēmu, līdzīgu WhatsApp, kas atbalsta 1:1 un grupu tērzēšanu, nodrošina ziņojumu piegādi, parāda lietotāju tiešsaistes statusus un ļauj pārsūtīt multimediju failus (attēlus, video, audio). Sistēma jānodrošina ar augstu pieejamību un zemu latentumu, jāatbalsta augsts paralēlisms un jāskala globāli. FUNKCIONĀLIE PRASĪBAS - Atbalsts personīgajiem (1:1) un grupu tērzēšanas ar iespēju pievienot/noņemt dalībniekus - Teksta ziņojumu un multimediju failu sūtīšana un saņemšana Nav skaidri redzama end-to-end šifrēšanas mehānisma īstenošana pakalpojumu vai klientu līmenī, izņemot vispārēju piezīmi. - Trūkst skaidra apraksta par sharding un replikāciju datu bāzēs pēc chat_id vai user_id, lai nodrošinātu mērogojamību un kļūdu tolerance. - Nav skaidrs komponentu vai mehānisma offline ziņojumu sinhronizācijai un piegādes apstiprinājumiem. - Nav skaidrs, kā tiek veikta slodzes līdzsvarošana starp datu bāzēm un pakalpojumiem, īpaši virsotnes slodzēs. **Kritiskie punkti, kas jāņem vērā:**

Senior

Яндекс

211

/* PostgreSQL-ā ir divi serveri: * PROD - OLTP serveris, * STATS - serveris ilgām analītiskajām vaicājumiem. Pašreizējā serverī, prod datu bāzē, ir liela (10Tb) tabula ar šādu struktūru: CREATE TABLE profiles( id SERIAL, data JSONB ) Tabulā var būt "caurumi", t.i., dažiem `id` var būt izlaisti. Ir nepieciešams uzrakstīt programmu, kas kopē tabulu profiles no PROD uz STATS. Pieņemts, ka tiks izmantoti šādi interfeisi darbam ar datu bāzēm: type Row []interface{} type Database interface { // realizācija var atkārtoti izveidot savienojumus // SaveRows izsaukums ir idempotents 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 // Ja full=false, turpināt datu pārnešanu no iepriekšējās kļūdas vietas // Ja full=true, pārnest visus datus func CopyTable(fromName string, toName string, full bool) error { // ... jūsu kods } Ja tiek nodota opcija `full=false`, programmai jāturpina datu pārnešana no iepriekšējās kļūdas vietas. Ja `full=true`, jāpārnes visi dati. **Pamata līmenis**: - secīgs datu pārnešanas process vienā plūsmā - atjaunošana pēc kļūdas (opcijas `full=false`) Papildu informācija: - ja nepieciešams, vari paplašināt interfeisu, pievienojot savas metodes - ja nepieciešams, vari tieši izmantot **database/sql** paketi

Senior

Яндекс

211

/* Dota ir rakstzīmju virkne. Atrodi indeksu pāru i un j skaitu (i <= j), starp kuriem nav atkārtotu rakstzīmju. "aba" virknei atbilde ir 5: var nebūt tikai ASCII [0, 0] ("a") [0, 1] ("ab") [1, 1] ("b") [1, 2] ("ba") [2, 2] ("a") */

Intern

Яндекс

211

Dotā ir rakstzīmju virkne. Atrodiet indeksu i un j pāri (i <= j), starp kuriem, ieskaitot, nav atkārtotu rakstzīmju. "aba" virknes gadījumā atbilde ir 5: [0, 0] ("a") [0, 1] ("ab") [1, 1] ("b") [1, 2] ("ba") [2, 2] ("a") "abcb" virknes gadījumā atbilde ir ?: aba 3 + 2 = 5 abcb 4 (a, b, c, d) + 1 (ab) + 1 (bc) + 1 (cb) + 1 (abc) = 8

Intern

Яндекс

209

/* Ir ir pastāv lietojumprogramma ar mikroservisu arhitektūra. Mikroserviss var tikt apstrādāts ar Backend interfeisa palīdzību. Lai piekļūtu mikroservisa eksemplāram, var izmantot jau realizēto BackendImpl tipu. Katrs mikroserviss ir vairākas desmiti darbojošu eksemplāru, katrs pieejams ar savu adresi addr. Tomēr atsevišķi mikroservisa eksemplāri nav uzticami: tie var krist, būt nepieejami vai pārslogoti. Tādēļ jums jārealizē Balancer tips, kas arī realizē Backend interfeisu un veic klienta puses slodzes līdzsvarošanu starp mikroservisa eksemplāriem, katru reizi izvēloties **mazāk noslogoto** eksemplāru. */ type Request interface{} type Response interface{} type Backend interface { Invoke(ctx context.Context, req Request) (Response, error) } var _ Backend = &BackendImpl{} // addr satur konkrēta eksemplāra ip:port adresi func NewBackend(addr string) *BackendImpl type Balancer struct { // TODO } var _ Backend = &Balancer{} // addrs satur visu balansēto eksemplāru adreses func NewBalancer(addrs []string) *Balancer { // TODO }

Middle

Яндекс

209

Kā darbojas WebSocket savienojums arhitektūrā — kad tas tiek izveidots un ar ko kas sazinās?

Senior

Яндекс

209

Vai jums ir pieredze ar izplatītām sistēmām?

Senior

Яндекс

209

Kāda ir problēma ar pašreizējo kartes atjaunināšanas ieviešanu darbā (tasksRes[t.id][task{...}])?

Middle+

Яндекс

209

/11