Pastāstiet mums par saviem nesenajiem projektiem un izmantoto tehnoloģiju steku.
Golang
Kur tu dzīvo, kur atrodies?
Parunāsim par mikroservisu arhitektūru. Kas pēdējā laikā bija biežāk: atbalsts vai izstrāde?
Kā pārbaudīt, vai logs satur visus nepieciešamos simbolus?
Pastāstiet, kas notiek galā — kā mēs uzkrājam buferi?
Aprakstiet algoritmu maxSegment uzdevuma risināšanai
4 - ātri pieņem ienākošos uzdevumus, 5 - atgriezt uzdevuma rezultātu pēc pieprasījuma 6 - ja rezultāts nav, atgriezt atbilstošo statusu /* Procesors - pakalpojums, kas veic ilgu, resursu intensīvu operāciju. Tas jau ir īstenots Atgrieztās kļūdas ir saistītas tikai ar nepareiziem ievades datiem, ir stabilas un atkārtota pieprasīšana ir bezjēdzīga */ type Processor interface { Process([]byte) ([]byte, error) } /* Pieņemam, ka mums ir unikālu identifikatoru ģenerators (piemēram, UUID). Ģenerators garantē, ka nebūs sadursmju */ type ID string // func NewID() ID /* Grafiks pieņem uzdevumus no klientiem, tos pievieno rindai un sāk apstrādi. Nodrošina, ka vienlaicīgi darbojas ne vairāk kā 'threads' metodes Sniedz iespēju pārbaudīt uzdevuma statusu un saņemt rezultātu ne bloķē savas publiskās metodes apstrādei */ type Scheduler struct { processor Processor } func NewScheduler( prc Processor, threads int, ) *Scheduler { // inicializācijas loģika return &Scheduler{ processor: prc, } } func (s *Scheduler) Queue(request []byte) ID { // īstenošana return "" }
/* Mums jānodod dati no avota uz patērētāju. Avots sniedz datus mazās partijās (~desmit ieraksti), kamēr patērētājs efektīvāk strādā ar lielākām partijām (~tūkstotis ierakstu). Reāls piemērs ir datu pārnešana no Kafka tipa rindām uz Clickhouse datu bāzi. Avots: - Praktiski bezgalīgs. - Avots nekad neatgriež vairāk par MaxItems ierakstiem vienā Next izsaukumā. - Vienas "sesijas" (viena Pipe funkcijas izsaukuma) laikā avots katru reizi atgriež jaunus datus. - Tomēr, pēc restartēšanas, avots sāk no iepriekšējās "apstiprinātās" pozīcijas, kas noteikta ar cookie. Tādēļ, *katra* cookie vērtība, ko Next atgriež, pēc datu saglabāšanas saņēmējā, ir jāapstiprina ar Commit izsaukumu, tādā pašā secībā, kādā tie tika atgriezti no Next. Saņēmējs: - Nevar apstrādāt vairāk par MaxItems vienlaikus. Nepieciešams īstenot funkciju func Pipe(p Producer, c Consumer) error, kura lasa datus no avota, tos grupē buferī ar izmēru ne lielāku par MaxItems un saglabā saņēmējā, pēc tam apstiprina progresu avotā. */ const MaxItems = 9999 type Producer interface { // Next atgriež: // - partiju elementu, kurus apstrādāt // - cookie, ko apstiprināt, kad apstrāde ir pabeigta // - kļūdu Next() (items []any, cookie int, err error) // Commit tiek izmantots, lai marķētu datu partiju kā apstrādātu Commit(cookie int) error } type Consumer interface { Process(items []any) error } func Pipe(p Producer, c Consumer) error { // TODO }
Kādi ir jūsu algas gaidījumi?
Kādus anti-modelus microservice arhitektūrā jūs zināt?
Vai jums ir pieredze programmu rakstīšanā ar daudzvītņu vai asenhroniskām operācijām?
Apskatīsim piemēru: first=[1,1,2], second=[1,2]. Ko jūsu algoritms būtu jāatgriež un vai tas pareizi darbojas ar dublikātiem?
Ja jums tiks darba piedāvājums un jūs to pieņemsiet, cik ātri būtu gatavs sākt darbu?
[vārds] jautāja: saglabājot elementa pozīciju, kas ir mazāka par X, kāda būs pozīcija?
Balanceram jāapzinās, ka backend atbild ar kļūdām, un pārsniedzot slieksni noteiktā laikā, to izslēgt no balansēšanas (Circuit Breaker)
Vai jums ir pieredze izstrādājot un atbalstot izplatītās sistēmas?
Ar ar kādām datu bāzēm vai citām datu glabāšanas vietām esat strādājis? Cik pieprasījumu sekundē (RPS) rakstīšanai un lasīšanai?
Vai visa darba laikā esat veicis vadības uzdevumus?
Vai ir pareizi, ka jūs pašreiz dzīvojat [pilsētā] un jums būtu ērti strādāt hibrīdā formātā ar biroja apmeklējumiem?
Kāda ir maksimālā slodze pieprasījumos sekundē, ko apstrādājusi vislielākā slodze serviss? Vai ir pareizi, ka tas ir līdz 5–8 tūkstošiem pieprasījumu sekundē?