Учурдагы киреше деңгээлиңизди айта аласызбы?
Golang
Эң кыйын жана кызыктуу тапшырмаңыз жөнүндө айтып бериңиз, өзгөчө архитектуралык тажрыйбаңыз жөнүндө.
Аз азыр Москвада жашайсыңбы? Эмне шаарды карап жатасың? Гибриддүү иш форматын карап жатасыңбы? Издөө кандай стадиядасың?
Башка ишке кабыл алуу процесстериңиз барбы?
Бул метрикалык маалыматтар кандайча интеграцияланып, Grafanaда көрсөтүлөт?
Акыркы жолу иштеген командаңыздын курамы кандай болчу?
Масштабдуу билдирүү системасын долбоорлоо, ал 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 шифрлөө так ишке ашырылбайт, жалпы белгилөө менен гана. - chat_id же user_id боюнча базалардын sharding жана репликациясы так сүрөттөлбөйт, масштабдуулук жана каталарга туруктуулук үчүн. - Offline билдирүүлөрдүн синхрондоштуруу жана жеткирүү маалымдамалары үчүн так компонент же механизм жок. - Жүктүн балансировкасы базалар жана кызматтар арасында, өзгөчө чокулук жүктөөлөрдө, кандай ишке ашырылары так эмес. **Маанилүү эскертүүлөр:** (Диаграмма Load Balancer, API Gateway, Message Queue, Service, Cache, Database, Object Storage жана CDN менен архитектураны көрсөтөт)
Сизде иштөөчү GitHub же LinkedIn барбы?
Өткөн жумуш орундарда эмне менен алектендиңиз жана кандай функцияларды ишке ашырдыңыз, кыскача айтып бериңиз.
/* PostgreSQL-нин эки сервери бар: * PROD - OLTP сервери, * STATS - узак аналитикалык суроолор үчүн сервер. Учурдагы сервердеги prod базасында чоң (10Tb) таблица бар: CREATE TABLE profiles( id SERIAL, data JSONB ) Таблицада "жарыктар" болушу мүмкүн, башкача айтканда, кээ бир `id`лер пропущен болушу мүмкүн. PROD-тан STATSке profiles таблицасын көчүрүү үчүн программа жазуу керек. Келтирилген интерфейстерди колдонуу болжолдонууда: 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** пакетин колдонсоңуз болот
150 миллион колдонуучуну колдоо менен масштабдуу билдирүү системасын долбоорлоо, 75 миллион DAU, 225 миллион MAU, 1.2М окулуш / 300k жазуу чеги QPS, 5 миллион бир убакта колдонучулар, жылына 60 PB жаңы маалымат, жылдык 30% өсүш, SLA 99.95%, p99 <200 ms окуу үчүн, <300 ms жазуу үчүн. КОНТЕКСТ WhatsApp сыяктуу, 1:1 жана топ чаттарды колдогон, билдирүүлөрдү жеткирүүнү камсыздаган, колдонуучулардын онлайн абалын көрсөтүүчү жана мультимедиалык файлдарды (сүрөттөр, видеолор, аудио) өткөрүүчү бөлүштүрүлгөн билдирүү системасын долбоорлоо керек. Система жогорку жеткиликтүүлүк жана төмөн кечигүү менен камсыз кылышы керек, жогорку параллелизмди колдошу жана глобалдык масштабда кеңейиши керек. Функционалдык талаптар - жеке (1:1) жана топ чаттарды колдоо, катышуучуларды кошуу/алып салуу мүмкүнчүлүгү менен - тексттик билдирүүлөрдү жана мультимедиалык файлдарды жөнөтүү жана кабыл алуу Кызматтар же кардарлар деңгээлинде end-to-end шифрлөө механизми так ишке ашырылганы көрүнбөйт, жалпы эскертүү менен гана. - chat_id же user_id боюнча базалардын sharding жана репликациясынын так сүрөттөмөсү жок, масштабдуулук жана каталарга туруктуулук үчүн. - Offline билдирүүлөрдү жана жеткирүү тастыктарынын синхрондоштуруу үчүн так компонент же механизми жок. - Жүктүн балансын базалар жана кызматтар арасында, өзгөчө чокулук учурунда, кантип жүргүзүлөрү так эмес. **Көз караштар жана эскертүүлөр:**
Тимдеги тесттер кандайча түзүлгөн — ким эмне жазат, кандай камтылуу, барбы E2E?
/* Бизге белгилүү бир булактан белгилүү бир керектүүчүгө маалыматтарды өткөрүп берүү керек. Бул учурда булак кичинекей партиялар менен маалыматтарды берет (~ ондон ашык жазуу), ал эми керектүүчү чоң партиялар менен иштөөдө оптималдуу (~ миңден ашык жазуу). Чындык мисал - Kafka сыяктуу кезекчелерден Clickhouse базасына маалыматтарды берүү. Булак: - Шарттуу түрдө чексиз. - Булак ар бир Next чакыруусунда MaxItemsтен көп эмес жазууларды кайтарбайт. - Бир "сессия" (бир функция Pipe чакыруусу) ичинде булак ар дайым жаңы маалыматтарды кайтарат. - Бирок, кайра иштеткенде булак өткөн "тастыкталган" позициядан баштайт, ал cookie менен белгиленет. Ошондуктан, Next чакыруусу кайтарган ар бир мааниси, маалыматтарды кабыл алуучу жакта сакталган соң, Commit чакыруусу менен такталууга тийиш, жана аларды кайсы учурда кайтарганына карап, ошол эле тартипте болушу керек. Кабыл алуучу: - Бир жолу MaxItemsтен көп эмес иштетүүгө тийиш. Негизги деңгээл: func Pipe(p Producer, c Consumer) error функциясын ишке ашыруу керек, бул функция булактан маалыматтарды окуп, аларды MaxItems өлчөмүндөгү буферге топтоп, кабыл алуучуга сактайт, жана прогрессти булакка кайтарат. Кыйынчылык: Next, Process жана Commit методдору тармактык чакыруулар менен байланышкан жана узак иштеши мүмкүн. Маалымат алмашууну тездетүү үчүн, окуу, жазуу жана прогрессти ырастоону параллелдөө керек. Мындайча айтканда, Process же Commit чакыруусу учурунда, булактан окуу жана жаңы буфер түзүү улантылат. */
Map маалыматтардын түзүмүндө элементтерди издөө эффективдүүлүгүн кантип жогорулатса болот?
Берилген символдор тизмеги. 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
Жумушчуда (tasksRes[t.id][task{...}]) карта жаңыртуунун азыркы ишке ашырылышында кандай көйгөй бар?
/* Берилген символдордун тизмеси. i жана j көрсөткүчтөрүнүн жуптарынын санын табыңыз (i <= j), алардын ортосунда кайталанган символдор жок. "aba" тизмеси үчүн жооп 5: тек гана ASCII эмес болушу мүмкүн [0, 0] ("a") [0, 1] ("ab") [1, 1] ("b") [1, 2] ("ba") [2, 2] ("a") */
Төзүмдүүлүктөрдүн тескерисинче айлануу принцибин түшүндүрүп бериңиз жана эмне үчүн колдонуу учурунда репозиторийдин ыкмаларын түздөн-түз чакыруусу SOLID принципин бузат.
/* 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 }
WebSocket байланышы архитектурада кандай иштейт — кай орнотулат жана ким ким менен байланышта болот?