Берилген символдор тизмеги. 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
/* Берилген символдордун тизмеси. i жана j көрсөткүчтөрүнүн жуптарынын санын табыңыз (i <= j), алардын ортосунда кайталанган символдор жок. "aba" тизмеси үчүн жооп 5: тек гана ASCII эмес болушу мүмкүн [0, 0] ("a") [0, 1] ("ab") [1, 1] ("b") [1, 2] ("ba") [2, 2] ("a") */
/* Бизге белгилүү бир булактан белгилүү бир керектүүчүгө маалыматтарды өткөрүп берүү керек. Бул учурда булак кичинекей партиялар менен маалыматтарды берет (~ ондон ашык жазуу), ал эми керектүүчү чоң партиялар менен иштөөдө оптималдуу (~ миңден ашык жазуу). Чындык мисал - Kafka сыяктуу кезекчелерден Clickhouse базасына маалыматтарды берүү. Булак: - Шарттуу түрдө чексиз. - Булак ар бир Next чакыруусунда MaxItemsтен көп эмес жазууларды кайтарбайт. - Бир "сессия" (бир функция Pipe чакыруусу) ичинде булак ар дайым жаңы маалыматтарды кайтарат. - Бирок, кайра иштеткенде булак өткөн "тастыкталган" позициядан баштайт, ал cookie менен белгиленет. Ошондуктан, Next чакыруусу кайтарган ар бир мааниси, маалыматтарды кабыл алуучу жакта сакталган соң, Commit чакыруусу менен такталууга тийиш, жана аларды кайсы учурда кайтарганына карап, ошол эле тартипте болушу керек. Кабыл алуучу: - Бир жолу MaxItemsтен көп эмес иштетүүгө тийиш. Негизги деңгээл: func Pipe(p Producer, c Consumer) error функциясын ишке ашыруу керек, бул функция булактан маалыматтарды окуп, аларды MaxItems өлчөмүндөгү буферге топтоп, кабыл алуучуга сактайт, жана прогрессти булакка кайтарат. Кыйынчылык: Next, Process жана Commit методдору тармактык чакыруулар менен байланышкан жана узак иштеши мүмкүн. Маалымат алмашууну тездетүү үчүн, окуу, жазуу жана прогрессти ырастоону параллелдөө керек. Мындайча айтканда, Process же Commit чакыруусу учурунда, булактан окуу жана жаңы буфер түзүү улантылат. */
Төзүмдүүлүктөрдүн тескерисинче айлануу принцибин түшүндүрүп бериңиз жана эмне үчүн колдонуу учурунда репозиторийдин ыкмаларын түздөн-түз чакыруусу SOLID принципин бузат.
Бир датасы барбы?
Сиз кандайча жасалган суроолордун тактуулугун текшерип, текшерип өттүңүз?
Local, dev, stage, prod чөйрөлөрүнүн айырмачылыгы эмнеде?
JWT өзүүнүн түптүүлүгүн кантип текшерет? Токендин жасалма эместигин кантип тастыктайт?
Маалыматтар базалары жөнүндө айтып бер — кайсы менен иштеди жана азыр кайсы менен иштөөдөсүң?
/* Mikroservis arxitekturasy bilen programm. Mikroservis Backend interfeysı vasitəsilə abstraktsiya edilə bilər. Mikroservisin bir nüsxəsinə giriş üçün, artıq tətbiq olunmuş BackendImpl tipindən istifadə edə bilərsiniz. Hər mikroservisdə bir neçə onlarla işləyən nüsxə var, hər biri öz ünvanı addr ilə əlçatan. Ancaq, mikroservisin ayrı-ayrı nüsxələri etibarlı deyil: Onlar çökmə, əlçatan olmama və ya yüklənmə ilə qarşılaşa bilər. Buna görə, siz müştəri tərəfi yük balanslaşdırması həyata keçirən və hər dəfə **ən az yüklənmiş** nüsxəni seçən Balancer tipini tətbiq etməlisiniz. */ type Request interface{} type Response interface{} type Backend interface { Invoke(ctx context.Context, req Request) (Response, error) } var _ Backend = &BackendImpl{} // addr, müəyyən nüsxənin ip:port ünvanını ehtiva edir func NewBackend(addr string) *BackendImpl type Balancer struct { // TODO } var _ Backend = &Balancer{} // addrs, yüklənməni balanslaşdıran bütün nüsxələrin ünvanlarını ehtiva edir func NewBalancer(addrs []string) *Balancer { // TODO }
/* Микросервис архитектурасы бар колдонмо бар. Микросервис, Backend интерфейси аркылуу абстракцияланат. Микросервистин бир үлгүсүнө кирүү үчүн, сиз BackendImpl түрүн колдонсоңуз болот, ал алдын ала ишке ашырылган. Ар бир микросервиске ондон ашык иштеп жаткан үлгүлөр бар, алардын ар бири өзүнүн адреси addr аркылуу жеткиликтүү. Бирок, микросервисдин жеке үлгүлөрү ишенимдүү эмес: алар кулап кете алат, жеткиликтүү эмес же ашыкча жүктөлгөн болушу мүмкүн. Ошондуктан, сиз Balancer түрүн ишке ашырышыңыз керек, ал дагы Backend интерфейсин ишке ашырып, микросервис үлгүлөрүнүн ортосунда кардар тараптан жүктү теңдештирет, ар бир жолу **аз жүктөлгөн** үлгүнү тандайт. */
Команда башкаруу тажрыйбасыңыз барбы?
Терезе жарактуу болгондо жоопко эмне кошулат?
Параллел суранычтарды чектөө үчүн чечим катары семафор жана буферленген каналдын чектөөлөрү эмнеде?
Эң жогорку жүктөмдүү кызмат кандайча секундуна (RPS) эң көп суроо иштеткен?
Иш форматы: алыстан, кеңседе же гибриддик?
Карталардагы элементтерди кантип салыштыруу керек? Эки карта туура келеби деп кантип текшерсе болот?
JWT токен эмне? Кандай түзүлгөн?
Бардык уникалдуу белгилер менен субстрингдерди эсептөө алгоритмин сүрөттөп бериңиз
Go тилинде тапшырма жазуу — практик бөлүм (дастурчунун жашоосунан көйгөйлөр, алгоритмдерсиз): кызматты жакшыртуу же оңдоо. Убакыт — 1,5 саат.
