🥇FAQ babagan arsitektur lan karya ing VKontakte

Sejarah nggawe VKontakte ana ing Wikipedia, dicritakake dening Pavel dhewe. Kayane kabeh wong wis ngerti dheweke. Babagan internal, arsitektur lan struktur situs ing HighLoad ++ Pavel marang aku ing taun 2010. Akeh server sing bocor wiwit saiki, mula kita bakal nganyari informasi kasebut: kita bakal mbedah, njupuk bagian njero, nimbang, lan ndeleng piranti VK saka sudut pandang teknis.

Alexey Akulovich (AterCattus) pangembang backend ing tim VKontakte. Transkrip laporan iki minangka jawaban kolektif kanggo pitakonan sing kerep ditakoni babagan operasi platform, infrastruktur, server lan interaksi ing antarane, nanging ora babagan pembangunan, yaiku. bab wesi. Kapisah, babagan database lan apa sing ana ing VK, babagan ngumpulake log lan ngawasi kabeh proyek kanthi wutuh. Rincian ing ngisor potong.

Kanggo luwih saka patang taun aku wis dealing with kabeh limo tugas related kanggo backend.

Ngunggah, nyimpen, ngolah, nyebarake media: video, streaming langsung, audio, foto, dokumen.
Infrastruktur, platform, pemantauan pangembang, log, cache regional, CDN, protokol RPC proprietary.
Integrasi karo layanan eksternal: kabar push, parsing link eksternal, feed RSS.
Mbantu kolega karo macem-macem pitakonan, jawaban sing mbutuhake nyilem menyang kode dingerteni.

Sak iki wektu, Aku wis tangan ing akeh komponen saka situs. Aku pengin nuduhake pengalaman iki.

Arsitektur umum

Kabeh, kaya biasane, diwiwiti karo server utawa klompok server sing nampa panjaluk.

Server ngarep

Server ngarep nampa panjalukan liwat HTTPS, RTMP lan WSS.

https - iki minangka panjalukan kanggo versi web utama lan seluler situs kasebut: vk.com lan m.vk.com, lan klien resmi lan ora resmi liyane saka API kita: klien seluler, utusan. Kita duwe resepsi RTMP-lalu lintas kanggo siaran Live karo server ngarep kapisah lan WSS- sambungan kanggo Streaming API.

Kanggo HTTPS lan WSS ing server iku worth nginx. Kanggo siaran RTMP, kita bubar ngalih menyang solusi dhewe kive, nanging iku ngluwihi orane katrangan saka laporan. Kanggo toleransi kesalahan, server iki ngiklanake alamat IP umum lan tumindak ing klompok supaya yen ana masalah ing salah sawijining server, panjaluk pangguna ora ilang. Kanggo HTTPS lan WSS, server sing padha iki ngenkripsi lalu lintas supaya bisa njupuk bagian saka beban CPU.

Kita ora bakal ngomong maneh babagan WSS lan RTMP, nanging mung babagan panjalukan HTTPS standar, sing biasane digandhengake karo proyek web.

Backend

Ing mburi ngarep biasane ana server backend. Dheweke ngolah panjaluk sing ditampa dening server ngarep saka klien.

iki server kPHP, ing ngendi daemon HTTP mlaku, amarga HTTPS wis didekripsi. kPHP minangka server sing mlaku model prefork: miwiti proses master, Bunch saka proses anak, liwat sockets ngrungokake kanggo wong-wong mau lan padha proses panjalukan. Ing kasus iki, pangolahan ora diwiwiti maneh ing antarane saben panjalukan saka pangguna, nanging mung ngreset statuse menyang negara nilai nol asli - request sawise request, tinimbang miwiti maneh.

Distribusi beban

Kabeh backends kita ora blumbang gedhe saka mesin sing bisa proses request sembarang. Kita padha dipérang dadi klompok kapisah: umum, seluler, api, video, pementasan ... Masalah ing klompok kapisah saka mesin ora bakal mengaruhi kabeh liyane. Yen ana masalah karo video, pangguna sing ngrungokake musik ora bakal ngerti babagan masalah kasebut. Kang backend kanggo ngirim panjalukan kanggo mutusaké dening nginx ing ngarep miturut config.

Koleksi metrik lan rebalancing

Kanggo ngerti carane akeh mobil kita kudu duwe ing saben klompok, kita ora gumantung ing QPS. Backends beda-beda, padha duwe panjalukan beda, saben panjalukan wis kerumitan ngetung QPS beda. Mulane kita kita operate karo konsep mbukak ing server minangka kabèh - ing CPU lan perf.

Kita duwe ewonan server kasebut. Saben server fisik mbukak grup kPHP kanggo daur ulang kabeh intine (amarga kPHP iku siji thread).

Server Konten

CS utawa Content Server minangka panyimpenan. CS minangka server sing nyimpen file lan uga ngolah file sing diunggah lan kabeh jinis tugas sinkron latar mburi sing diwenehake dening frontend web utama.

Kita duwe puluhan ewu server fisik sing nyimpen file. Pangguna seneng ngunggah file, lan kita seneng nyimpen lan nuduhake. Sawetara server iki ditutup dening server pu / pp khusus.

pu/pp

Yen sampeyan mbukak tab jaringan ing VK, sampeyan ndeleng pu/pp.

Apa iku pu/pp? Yen kita nutup server siji-sijine, banjur ana rong pilihan kanggo ngunggah lan ndownload file menyang server sing ditutup: langsung liwat http://cs100500.userapi.com/path utawa liwat server penengah - http://pu.vk.com/c100500/path.

Pu minangka jeneng sajarah kanggo unggahan foto, lan pp minangka proxy foto. Tegese, siji server kanggo upload foto, lan liyane kanggo upload. Saiki ora mung foto sing dimuat, nanging jenenge wis dilestarekake.

Server-server iki mungkasi sesi HTTPSkanggo mbusak beban prosesor saka panyimpenan. Uga, amarga file pangguna diproses ing server kasebut, informasi sing kurang sensitif sing disimpen ing mesin kasebut, luwih apik. Contone, kunci enkripsi HTTPS.

Amarga mesin kasebut ditutup dening mesin liyane, kita ora bisa menehi IP eksternal "putih", lan menehi "abu-abu". Kanthi cara iki kita disimpen ing blumbang IP lan dijamin kanggo nglindhungi mesin saka akses njaba - ana mung ora IP kanggo njaluk menyang.

Ketahanan liwat IP sing dienggo bareng. Ing babagan toleransi kesalahan, skema kasebut padha - sawetara server fisik duwe IP fisik umum, lan hardware ing ngarepe milih ngendi ngirim panjaluk kasebut. Aku bakal ngomong babagan opsi liyane mengko.

Titik kontroversial yaiku ing kasus iki klien tetep kurang sambungan. Yen ana IP sing padha kanggo sawetara mesin - kanthi host sing padha: pu.vk.com utawa pp.vk.com, browser klien duwe watesan jumlah panjalukan simultaneous kanggo siji host. Nanging ing wektu HTTP / 2 ing ngendi-endi, aku percaya yen iki ora relevan maneh.

Kerugian sing jelas saka skema kasebut yaiku kudu kumpa kabeh lalu lintas, kang menyang panyimpenan, liwat server liyane. Amarga kita ngompa lalu lintas liwat mesin, kita durung bisa ngompa lalu lintas abot, contone, video, nggunakake skema sing padha. Kita ngirim langsung - sambungan langsung kapisah kanggo panyimpenan kapisah khusus kanggo video. Kita ngirim konten sing luwih entheng liwat proxy.

Ora suwe, kita entuk versi proxy sing luwih apik. Saiki aku bakal pitutur marang kowe carane padha beda-beda saka biasa lan apa iki perlu.

Sun

Ing September 2017, Oracle, sing sadurunge tuku Sun, mecat karyawan Sun sing akeh banget. Kita bisa ujar manawa saiki perusahaan kasebut ora ana. Nalika milih jeneng kanggo sistem anyar, pangurus kita mutusaké kanggo mbayar pajeg kanggo memori perusahaan iki lan jeneng sistem anyar Sun. Antarane awake dhewe kita mung nyebut dheweke "srengenge".

pp duwe sawetara masalah. Siji IP saben klompok - cache ora efektif. Sawetara server fisik nuduhake alamat IP umum, lan ora ana cara kanggo ngontrol server sing bakal dijaluk. Mulane, yen pangguna beda teka kanggo file sing padha, banjur yen ana cache ing server kasebut, file kasebut bakal ana ing cache saben server. Iki minangka skema sing ora efisien, nanging ora ana sing bisa ditindakake.

Akibate - kita ora bisa mecah isi, amarga kita ora bisa milih server tartamtu kanggo grup iki - padha duwe IP umum. Uga kanggo sawetara alasan internal kita duwe ora bisa nginstal server kasebut ing wilayah. Padha ngadeg mung ing St.

Kanthi srengenge, kita ngganti sistem pilihan. Saiki kita duwe routing anycast: nuntun dinamis, anycast, daemon mriksa dhewe. Saben server duwe IP individu dhewe, nanging subnet umum. Kabeh wis dikonfigurasi kanthi cara yen siji server gagal, lalu lintas bakal nyebar ing server liyane saka grup sing padha kanthi otomatis. Saiki sampeyan bisa milih server tartamtu, ora cache keluwih, lan linuwih ora kena pengaruh.

Dhukungan bobot. Saiki kita bisa nginstal mesin kanthi daya sing beda-beda yen perlu, lan uga, yen ana masalah sauntara, ngganti bobot "srengenge" sing digunakake kanggo nyuda beban kasebut, supaya bisa "ngaso" lan miwiti kerja maneh.

Sharding dening id konten. Bab sing lucu babagan sharding: biasane isi beling supaya pangguna beda menyang file sing padha liwat "srengenge" sing padha supaya padha duwe cache umum.

Kita bubar ngluncurake aplikasi "Semanggi". Iki minangka kuis online ing siaran langsung, ing ngendi host takon lan pangguna mangsuli kanthi nyata, milih pilihan. Aplikasi kasebut nduweni obrolan ing ngendi pangguna bisa ngobrol. Bisa bebarengan nyambung menyang siaran luwih saka 100 ewu wong. Kabeh padha nulis pesen sing dikirim menyang kabeh peserta, lan avatar teka bebarengan karo pesen kasebut. Yen 100 ewu wong teka kanggo siji avatar ing siji "srengenge", mula kadhangkala bisa muter ing mburi awan.

Supaya bisa tahan bledosan panjalukan kanggo file sing padha, kanggo jinis konten tartamtu, kita nguripake skema bodho sing nyebar file ing kabeh "srengenge" sing kasedhiya ing wilayah kasebut.

Srengenge saka njero

Proksi mbalikke ing nginx, cache ing RAM utawa ing disk Optane / NVMe sing cepet. Tuladha: http://sun4-2.userapi.com/c100500/path - link menyang "srengenge", kang dumunung ing wilayah papat, klompok server kapindho. Iku nutup file path, sing sacara fisik dumunung ing server 100500.

tutup

Kita nambah siji simpul liyane menyang skema arsitektur kita - lingkungan caching.

Ing ngisor iki diagram tata letak caches regional, ana udakara 20. Iki minangka papan sing ana cache lan "srengenge", sing bisa nyimpen lalu lintas dhewe.

Iki minangka cache konten multimedia; ora ana data pangguna sing disimpen ing kene - mung musik, video, foto.

Kanggo nemtokake wilayah pangguna, kita kita ngumpulake ater-ater jaringan BGP sing diumumake ing wilayah kasebut. Ing kasus fallback, kita uga kudu ngurai database geoip yen ora bisa nemokake IP kanthi prefiks. Kita nemtokake wilayah kanthi IP pangguna. Ing kode kasebut, kita bisa ndeleng siji utawa luwih wilayah pangguna - titik sing paling cedhak kanthi geografis.

Carane ora iku bisa?

Kita ngitung popularitas file miturut wilayah. Ana sawetara cache regional ing ngendi pangguna dumunung, lan pengenal file - kita njupuk pasangan iki lan nambah rating kanthi saben download.

Ing wektu sing padha, dhemit - layanan ing wilayah - saka wektu kanggo wektu teka menyang API lan ngomong: "Aku iki cache, menehi kula dhaptar file paling populer ing wilayah sing durung ana ing kula. ” API ngirim akeh file sing diurutake miturut rating, daemon ngundhuh, nggawa menyang wilayah lan ngirim file saka kono. Iki prabédan dhasar antarane pu / pp lan Sun saka caches: padha menehi file liwat piyambak langsung, malah yen file iki ora ing cache, lan cache pisanan ngundhuh file kanggo dhewe, lan banjur wiwit menehi bali.

Ing kasus iki kita njaluk isi sing luwih cedhak karo pangguna lan nyebarake beban jaringan. Contone, mung saka cache Moskow kita nyebarake luwih saka 1 Tbit / s sajrone jam sibuk.

Nanging ana masalah - server cache ora karet. Kanggo konten super populer, kadhangkala ora cukup jaringan kanggo server sing kapisah. Server cache kita 40-50 Gbit / s, nanging ana konten sing macet saluran kasebut. Kita pindhah menyang ngleksanakake panyimpenan luwih saka siji salinan file populer ing wilayah kasebut. Muga-muga kita bisa ngetrapake ing pungkasan taun.

Kita nyawang arsitektur umum.

Server ngarep sing nampa panjalukan.
Backends sing proses panjalukan.
Panyimpenan sing ditutup dening rong jinis proxy.
Cache regional.

Apa sing ilang saka diagram iki? Mesthi, database sing kita nyimpen data.

Database utawa mesin

Kita nyebat dudu database, nanging mesin - Mesin, amarga kita ora duwe database ing pangertèn sing ditampa sacara umum.

Iki minangka langkah sing perlu.. Iki kedaden amarga ing 2008-2009, nalika VK wis wutah mbledhos ing popularitas, project makarya tanggung ing MySQL lan Memcache lan ana masalah. MySQL seneng nabrak lan ngrusak file, sawise iku ora bakal pulih, lan Memcache mboko sithik mudhun ing kinerja lan kudu diwiwiti maneh.

Pranyata proyek sing tambah populer duwe panyimpenan sing terus-terusan, sing ngrusak data, lan cache, sing alon-alon. Ing kahanan kasebut, angel ngembangake proyek sing akeh. Diputusake kanggo nyoba nulis ulang perkara kritis sing difokusake proyek kasebut ing sepeda kita dhewe.

Solusi kasebut sukses. Ana kesempatan kanggo nindakake iki, uga kabutuhan nemen, amarga cara scaling liyane ora ana ing wektu iku. Ora ana pirang-pirang database, NoSQL durung ana, mung ana MySQL, Memcache, PostrgreSQL - lan iku.

Operasi universal. Pangembangan kasebut dipimpin dening tim pangembang C lan kabeh ditindakake kanthi konsisten. Preduli saka mesin, kabeh padha duwe kira-kira format file padha ditulis kanggo disk, paramèter Bukak padha, sinyal diproses ing cara sing padha, lan tumindak kira-kira padha ing cilik saka kahanan pinggiran lan masalah. Kanthi wutah saka mesin, iku trep kanggo administrator kanggo operate sistem - ora ana kebon binatang sing perlu kanggo maintained, lan padha kudu sinau maneh carane operate saben database pihak katelu anyar, kang ndadekake iku bisa kanggo nambah cepet lan trep. nomere.

Jinis-jinis mesin

Tim kasebut nulis sawetara mesin. Iki mung sawetara: kanca, pitunjuk, gambar, ipdb, huruf, dhaptar, log, memcached, meowdb, warta, nostradamus, foto, dhaptar lagu, pmemcached, kothak wedhi, telusuran, panyimpenan, seneng, tugas, ...

Kanggo saben tugas sing mbutuhake struktur data tartamtu utawa ngolah panjaluk atipikal, tim C nulis mesin anyar. Ngapa ora.

Kita duwe mesin sing kapisah memcached, kang padha karo biasa, nanging karo Bunch saka apik, lan kang ora alon mudhun. Ora ClickHouse, nanging uga dianggo. Kasedhiya kanthi kapisah pmecached Punika terus-terusan memcached, kang uga bisa nyimpen data ing disk, malih, saka pas menyang RAM, supaya ora ilang data nalika miwiti maneh. Ana macem-macem mesin kanggo tugas individu: antrian, dhaptar, set - kabeh sing dibutuhake proyek kita.

Kluster

Saka perspektif kode, ora perlu mikir mesin utawa database minangka proses, entitas, utawa instan. Kode kasebut bisa digunakake kanthi khusus karo klompok, kanthi klompok mesin - siji jinis saben kluster. Ayo dadi ngomong ana kluster memcached - iku mung klompok mesin.

Kode kasebut ora perlu ngerti lokasi fisik, ukuran, utawa jumlah server. Dheweke menyang kluster nggunakake pengenal tartamtu.

Kanggo nindakake iki, sampeyan kudu nambah siji entitas liyane sing ana ing antarane kode lan mesin - proxy.

proxy RPC

proxy bis nyambungake, sing meh kabeh situs mlaku. Ing wektu sing padha kita duwe ora nemokake layanan - tinimbang, ana config kanggo proxy iki, kang ngerti lokasi kabeh kluster lan kabeh shards kluster iki. Iki sing ditindakake para admin.

Programer ora preduli sepira, ing endi lan regane - mung menyang kluster. Iki ngidini kita akeh. Nalika nampa panjalukan, proxy pangalihan panjalukan, ngerti ngendi - iku nemtokake dhewe.

Ing kasus iki, proxy minangka titik perlindungan marang kegagalan layanan. Yen sawetara engine slows mudhun utawa tubrukan, proxy mangertèni iki lan nanggapi miturut klien sisih. Iki ngijini sampeyan kanggo mbusak wektu entek - kode ora ngenteni engine kanggo nanggapi, nanging mangertos sing ora bisa digunakake lan kudu tumindak piye wae beda. Kode kudu disiapake kanggo kasunyatan sing database ora tansah bisa.

Implementasi spesifik

Kadhangkala kita isih pengin duwe sawetara solusi non-standar minangka mesin. Ing wektu sing padha, diputusake ora nggunakake rpc-proxy sing wis siap, digawe khusus kanggo mesin kita, nanging nggawe proxy sing kapisah kanggo tugas kasebut.

Kanggo MySQL, sing isih ana ing kene, kita nggunakake db-proxy, lan kanggo ClickHouse - omah kucing.

Kerjane umume kaya iki. Ana server tartamtu, nganggo kPHP, Go, Python - umume, kode apa wae sing bisa nggunakake protokol RPC kita. Kode kasebut lumaku sacara lokal ing proxy RPC - saben server sing ana kode kasebut nganggo proxy lokal dhewe. Yen dijaluk, proxy ngerti arep menyang ngendi.

Yen siji mesin pengin pindhah menyang liyane, sanajan iku pepadhamu, iku liwat proxy, amarga pepadhamu bisa ing pusat data liyane. Engine ngirim ora gumantung ing ngerti lokasi apa liyane saka dhewe - iki solusi standar kita. Nanging mesthi ana pengecualian :)

Conto saka TL-skema miturut kang kabeh mesin operate.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

Iki minangka protokol binar, analog sing paling cedhak yaiku protobuf. Skema kasebut nemtokake kolom opsional, jinis kompleks - ekstensi skalar sing dibangun, lan pitakon. Kabeh tumindak miturut protokol iki.

RPC liwat TL liwat TCP/UDP... UDP?

Kita duwe protokol RPC kanggo nglakokake panjaluk mesin sing mlaku ing ndhuwur skema TL. Iki kabeh dianggo liwat sambungan TCP/UDP. TCP bisa dingerteni, nanging kenapa kita butuh UDP asring?

UDP mbantu supaya masalah nomer ageng sambungan antarane server. Yen saben server duwe proxy RPC lan, umume, bisa menyang mesin apa wae, mula ana puluhan ewu sambungan TCP saben server. Ana beban, nanging ora ana gunane. Ing kasus UDP masalah iki ora ana.

Ora ana salaman TCP sing berlebihan. Iki minangka masalah khas: nalika mesin anyar utawa server anyar diluncurake, akeh sambungan TCP diadegake bebarengan. Kanggo panjalukan entheng cilik, contone, UDP payload, kabeh komunikasi antarane kode lan mesin punika XNUMX paket UDP: siji mabur ing siji arah, liyane ing liyane. Siji babak trip - lan kode nampa respon saka mesin tanpa salaman.

Ya, iku kabeh mung dianggo kanthi persentase mundhut paket sing cilik banget. Protokol nduweni dhukungan kanggo retransmits lan wektu entek, nanging yen kita kelangan akeh, kita bakal entuk meh TCP, sing ora ana gunane. Kita ora nyopir UDP nyabrang segara.

We duwe ewu server kuwi, lan rencana padha: Pack saka mesin diinstal ing saben server fisik. Padha biasane single-threaded kanggo mbukak minangka cepet sabisa tanpa Watesan, lan sharded minangka solusi single-threaded. Ing wektu sing padha, kita ora duwe apa-apa sing luwih dipercaya tinimbang mesin kasebut, lan akeh perhatian sing dibayar kanggo panyimpenan data sing terus-terusan.

Panyimpenan data sing terus-terusan

Mesin nulis binlog. Binlog minangka file ing pungkasan sing ditambahake acara kanggo owah-owahan ing negara utawa data. Ing macem-macem solusi diarani beda: log binar, WALI, AOF, nanging prinsip padha.

Kanggo nyegah mesin saka maca maneh kabeh binlog kanggo akèh taun nalika miwiti maneh, nulis mesin snapshot - kahanan saiki. Yen perlu, padha maca saka iku pisanan, lan banjur rampung maca saka binlog. Kabeh binlog ditulis ing format binar sing padha - miturut skema TL, supaya admin bisa ngatur kanthi padha nggunakake piranti. Ora perlu snapshot kaya ngono. Ana header umum sing nuduhake gambar asline sing int, sihir mesin, lan awak sing ora penting kanggo sapa wae. Iki masalah karo mesin sing ngrekam gambar asli.

Aku bakal cepet njlèntrèhaké prinsip operasi. Ana server ing ngendi mesin mlaku. Dheweke mbukak binlog kosong anyar kanggo nulis lan nulis acara kanggo owah-owahan.

Ing sawetara titik, dheweke mutusake njupuk gambar dhewe, utawa nampa sinyal. Server nggawe file anyar, nulis kabeh negara menyang, nambah ukuran binlog saiki - offset - kanggo mburi file, lan terus nulis luwih. A binlog anyar ora digawe.

Ing sawetara titik, nalika mesin urip maneh, bakal ana loro binlog lan gambar asli seko ing disk. Mesin maca kabeh gambar asli lan mundhakaken negara ing titik tartamtu.

Maca posisi sing ana ing wektu snapshot digawe lan ukuran binlog.

Maca pungkasan binlog kanggo njaluk negara saiki lan terus nulis acara luwih. Iki minangka skema sing gampang; kabeh mesin kita bisa digunakake.

Replikasi data

Akibaté, replikasi data ing kita adhedhasar statement - kita nulis ing binlog ora owah-owahan kaca, nanging yaiku ngganti panjalukan. Banget padha karo apa teka liwat jaringan, mung rada dipunéwahi.

Skema sing padha digunakake ora mung kanggo replikasi, nanging uga kanggo nggawe serep. Kita duwe mesin - master nulis sing nulis menyang binlog. Ing sembarang panggonan liyane ngendi admins nyetel munggah, binlog iki disalin, lan iku - kita duwe serep.

Yen dibutuhake replika macaKanggo nyuda beban maca CPU, mesin maca mung diluncurake, sing maca pungkasan binlog lan nindakake perintah kasebut sacara lokal.

Lag kene cilik banget, lan iku bisa kanggo mangerteni carane akeh replika lags master.

Sharing data ing proxy RPC

Kepiye cara sharding? Kepiye proxy ngerti sing ngirim kluster shard? Kode ora ngandika: "Kirim kanggo 15 shards!" - ora, iki ditindakake dening proxy.

Skema sing paling gampang yaiku pisanan - nomer pisanan ing panjalukan.

get(photo100_500) => 100 % N.

Iki minangka conto kanggo protokol teks memcached sing prasaja, nanging, mesthi, pitakon bisa rumit lan terstruktur. Conto njupuk nomer pisanan ing pitakonan lan sisa nalika dibagi karo ukuran kluster.

Iki migunani yen kita pengin duwe lokalitas data saka siji entitas. Coba umpamane 100 minangka ID pangguna utawa grup, lan kita pengin kabeh data saka siji entitas ana ing siji beling kanggo pitakon kompleks.

Yen kita ora peduli kepiye panjaluk nyebar ing kluster, ana pilihan liyane - hashing kabeh beling.

hash(photo100_500) => 3539886280 % N

Kita uga entuk hash, sisa divisi lan nomer shard.

Loro-lorone opsi iki mung bisa digunakake yen kita wis siyap kanggo kasunyatan sing nalika kita nambah ukuran kluster, kita bakal pamisah utawa nambah kaping pirang-pirang. Contone, kita duwe 16 shards, kita ora cukup, kita pengin luwih - kita bisa kanthi aman 32 tanpa downtime. Yen kita pengin nambah ora kaping pirang-pirang, bakal ana downtime, amarga kita ora bakal bisa kanthi akurat pamisah kabeh tanpa mundhut. Pilihan iki migunani, nanging ora tansah.

Yen kita perlu kanggo nambah utawa mbusak nomer kasepakatan saka server, kita nggunakake Hashing konsisten ing ring a la Ketama. Nanging ing wektu sing padha, kita kelangan lokalitas data; kita kudu nggabungake panyuwunan menyang kluster supaya saben potongan ngasilake respon cilik dhewe, banjur gabungake tanggapan menyang proxy.

Ana panjalukan super-spesifik. Katon kaya iki: proxy RPC nampa panjalukan, nemtokake klompok sing bakal dituju lan nemtokake beling. Banjur ana master nulis, utawa, yen kluster duwe dhukungan tiron, dikirim menyang replika sing dikarepake. Proxy nindakake kabeh iki.

Log

Kita nulis log kanthi sawetara cara. Sing paling jelas lan prasaja yaiku nulis log menyang memcache.

ring-buffer: prefix.idx = line

Ana ater-ater tombol - jeneng log, baris, lan ana ukuran log iki - jumlah baris. We njupuk nomer acak saka 0 kanggo nomer garis minus 1. Tombol ing memcache punika ater-ater concatenated karo nomer acak iki. Kita nyimpen baris log lan wektu saiki kanggo nilai.

Nalika iku perlu kanggo maca log, kita nindakake Multi Get kabeh tombol, diurutake miturut wektu, lan kanthi mangkono entuk log produksi ing wektu nyata. Skema digunakake nalika sampeyan kudu debug soko ing produksi ing wektu nyata, tanpa bejat apa-apa, tanpa mandheg utawa ngidini lalu lintas menyang mesin liyane, nanging log iki ora tahan suwe.

Kanggo panyimpenan dipercaya saka log kita duwe engine log-mesin. Iki pancene digawe lan digunakake kanthi akeh ing pirang-pirang klompok. Kluster paling gedhe aku ngerti nyimpen 600 TB log sing dikemas.

Mesine wis tuwa banget, ana kluster sing wis umur 6-7 taun. Ana masalah karo sing kita nyoba kanggo ngatasi, contone, kita wiwit aktif nggunakake ClickHouse kanggo nyimpen log.

Nglumpukake log ing ClickHouse

Diagram iki nuduhake carane kita mlaku menyang mesin kita.

Ana kode sing dadi lokal liwat RPC kanggo RPC-proxy, lan mangertos ngendi kanggo pindhah menyang engine. Yen kita pengin nulis log ing ClickHouse, kita kudu ngganti rong bagean ing skema iki:

ngganti sawetara mesin karo ClickHouse;
ngganti proxy RPC, sing ora bisa ngakses ClickHouse, karo sawetara solusi sing bisa, lan liwat RPC.

Mesin iku prasaja - kita ngganti karo server utawa kluster server karo ClickHouse.

Lan kanggo pindhah menyang ClickHouse, kita nindakake Omah Kucing. Yen kita langsung saka KittenHouse menyang ClickHouse, ora bakal bisa ditindakake. Malah tanpa panjaluk, nambah saka sambungan HTTP saka akeh mesin. Kanggo rencana bisa, ing server karo ClickHouse proxy mbalikke lokal wungu, sing ditulis kanthi cara sing bisa nahan volume sambungan sing dibutuhake. Uga bisa buffer data ing dhewe relatif andal.

Kadhangkala kita ora pengin ngetrapake skema RPC ing solusi non-standar, contone, ing nginx. Mulane, KittenHouse nduweni kemampuan kanggo nampa log liwat UDP.

Yen pangirim lan panampa log bisa digunakake ing mesin sing padha, kemungkinan ilang paket UDP ing host lokal cukup sithik. Minangka kompromi antarane kabutuhan kanggo ngleksanakake RPC ing solusi pihak katelu lan linuwih, kita mung nggunakake UDP ngirim. Kita bakal bali menyang skema iki mengko.

Ngawasi

Kita duwe rong jinis log: sing diklumpukake dening administrator ing server lan sing ditulis dening pangembang saka kode. Padha cocog karo rong jinis metrik: sistem lan produk.

Metrik sistem

Kerjane ing kabeh server kita netdata, sing ngumpulake statistik lan dikirim menyang Karbon Grafit Kab. Mulane, ClickHouse digunakake minangka sistem panyimpenan, lan dudu Whisper, umpamane. Yen perlu, sampeyan bisa langsung maca saka ClickHouse, utawa nggunakake Grafana kanggo metrik, grafik lan laporan. Minangka pangembang, kita duwe cukup akses menyang Netdata lan Grafana.

metrik produk

Kanggo penak, kita wis nulis akeh perkara. Contone, ana sakumpulan fungsi biasa sing ngidini sampeyan nulis Counts, UniqueCounts nilai menyang statistik, sing dikirim nang endi wae.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

Sabanjure, kita bisa nggunakake saringan ngurutake lan ngelompokake lan nindakake kabeh sing dikarepake saka statistik - mbangun grafik, ngatur Watchdogs.

Kita nulis banget akeh metrik jumlah acara saka 600 milyar nganti 1 triliun saben dina. Nanging, kita pengin tetep paling saperangan taunkanggo mangerteni tren ing metrik. Nggabungake kabeh iku masalah gedhe sing durung rampung. Aku bakal pitutur marang kowe carane iku wis bisa kanggo sawetara taun pungkasan.

Kita duwe fungsi sing nulis metrik kasebut menyang memcache lokalkanggo ngurangi jumlah entri. Sawise ing wektu cendhak wektu lokal dibukak stats-daemon ngumpulake kabeh cathetan. Sabanjure, setan nggabungake metrik dadi rong lapisan server log-kolektor, kang aggregates statistik saka Bunch saka mesin kita supaya lapisan konco wong ora mati.

Yen perlu, kita bisa nulis langsung menyang log-kolektor.

Nanging nulis saka kode langsung menyang kolektor, ngliwati stas-daemom, minangka solusi sing ora bisa diukur amarga nambah beban ing kolektor. Solusi iki cocok mung yen sakperangan alesan kita ora bisa mundhakaken memcache stats-daemon ing mesin, utawa tabrakan lan kita langsung.

Sabanjure, kolektor log nggabungake statistik dadi meowDB - iki database kita, kang uga bisa nyimpen metrik.

Banjur kita bisa nggawe pilihan binar "near-SQL" saka kode kasebut.

Eksperimen

Ing musim panas 2018, kita duwe hackathon internal, lan ide kasebut muncul kanggo nyoba ngganti bagean abang saka diagram kanthi barang sing bisa nyimpen metrik ing ClickHouse. Kita duwe log ing ClickHouse - kenapa ora nyoba?

Kita duwe skema sing nulis log liwat KittenHouse.

Kita mutusake nambah liyane "* Omah" kanggo diagram, sing bakal nampa persis metrik ing format nalika kode kita nulis liwat UDP. Banjur iki *Omah dadi sisipan, kaya log, sing KittenHouse ngerti. Dheweke bisa ngirim log kasebut kanthi sampurna menyang ClickHouse, sing kudu bisa maca.

Skema karo database memcache, stats-daemon lan log-kolektor diganti karo iki.

Ana kiriman saka kode ing kene, sing ditulis sacara lokal ing StatsHouse.
StatsHouse nyerat metrik UDP, sing wis diowahi dadi sisipan SQL, menyang KittenHouse kanthi batch.
KittenHouse ngirim menyang ClickHouse.
Yen kita pengin maca, banjur kita maca kanthi ngliwati StatsHouse - langsung saka ClickHouse nggunakake SQL biasa.

Apa isih pacoban, nanging kita kaya carane dadi metu. Yen kita ndandani masalah karo skema kasebut, mula bisa uga kita bakal ngalih kanthi lengkap. Secara pribadi, muga-muga.

Skema ora nyimpen wesi. Server sing luwih sithik dibutuhake, stats-daemon lan log-kolektor lokal ora dibutuhake, nanging ClickHouse mbutuhake server sing luwih gedhe tinimbang sing ana ing skema saiki. Server luwih sithik dibutuhake, nanging kudu luwih larang lan luwih kuat.

nyebarake

Pisanan, ayo goleki penyebaran PHP. We berkembang ing Go: nggunakake GitLab и TeamCity kanggo penyebaran. Cabang pangembangan digabung dadi cabang master, saka master kanggo testing digabung dadi pementasan, lan saka pementasan dadi produksi.

Sadurunge panyebaran, cabang produksi saiki lan sing sadurunge dijupuk, lan file beda dianggep - owah-owahan: digawe, dibusak, diganti. Owah-owahan iki dicathet ing binlog mesin copyfast khusus, sing bisa cepet niru owah-owahan ing kabeh armada server kita. Sing digunakake ing kene ora nyalin langsung, nanging replikasi gosip, nalika siji server ngirim owah-owahan menyang tetanggan sing paling cedhak, sing menyang tanggane, lan liya-liyane. Iki ngidini sampeyan nganyari kode ing puluhan lan unit detik ing kabeh armada. Nalika owah-owahan tekan tiron lokal, ditrapake patch iki kanggo sawijining sistem file lokal. Rollback uga ditindakake miturut skema sing padha.

Kita uga nyebarake kPHP akeh lan uga duwe pangembangan dhewe Go miturut diagram ing ndhuwur. Wiwit iki binar server HTTP, banjur kita ora bisa gawé diff - release binar abot atusan MB. Mulane, ana pilihan liyane ing kene - versi ditulis kanggo binlog copyfast. Kanthi saben mbangun mundhak, lan sak rollback uga mundhak. Versi direplikasi menyang server. Copyfasts lokal ndeleng manawa versi anyar wis mlebu binlog, lan kanthi replikasi gosip sing padha, dheweke njupuk versi paling anyar saka binar kanggo awake dhewe, tanpa kesel server master kita, nanging kanthi ati-ati nyebarake beban ing jaringan. Apa nderek anggun relaunch kanggo versi anyar.

Kanggo mesin kita, sing uga binari, skema kasebut meh padha:

cabang master git;
binar ing .deb;
versi ditulis kanggo binlog copyfast;
direplikasi menyang server;
server narik metu .dep seger;
dpkg -i;
anggun relaunch kanggo versi anyar.

Bentenipun punika binar kita rangkep ing arsip .deb, lan nalika pumping metu padha dpkg -i diselehake ing sistem. Napa kPHP disebarake minangka binar, lan mesin dipasang minangka dpkg? Kedadeyan kuwi. Kerjane - aja ndemek.

Link migunani:

Laporan dening Anton Kiryushkin "Administrator sistem Vkontakte. Piye?" kanthi rincian babagan copyfast lan gosip.
Laporan dening Yuri Nasretdinov "Carane VK nglebokake data menyang CLickHouse saka puluhan ewu server".
Laporanku "Arsitektur proyek sing akeh nggunakake conto VKontakte", nanging saka sudut pandang pembangunan, ora hardware.

Alexey Akulovich minangka salah sawijining sing, minangka bagéan saka Komite Program, mbantu PHP Rusia ing 17 Mei bakal dadi acara paling gedhe kanggo pangembang PHP ing jaman saiki. Deleng apa PC kelangan kita duwe, apa pamicara (loro mau ngembangake inti PHP!) - misale jek kaya sing ora bisa kantun yen sampeyan nulis PHP.

Source: www.habr.com

FAQ babagan arsitektur lan karya VKontakte