🥇FAQ ngeunaan arsitéktur sareng damel di VKontakte

Sajarah kreasi VKontakte aya dina Wikipédia, éta dicaritakeun ku Pavel sorangan. Sigana sarerea geus nyaho manehna. Ngeunaan internal, arsitéktur jeung struktur situs on HighLoad ++ Pavel ceuk kuring deui di 2010. Seueur server anu bocor ti saprak éta, ku kituna kami bakal ngapdet inpormasi: kami bakal ngabedahna, ngaluarkeun jerona, beuratna, sareng ningali alat VK tina sudut pandang téknis.

Alexey Akulovich (AterCattus) pamekar backend di tim VKontakte. Transkrip laporan ieu mangrupikeun jawaban koléktif pikeun patarosan anu sering ditaroskeun ngeunaan operasi platform, infrastruktur, server sareng interaksi antara aranjeunna, tapi sanés ngeunaan pamekaran, nyaéta. ngeunaan beusi. Kapisah, ngeunaan basis data sareng naon anu gaduh VK, ngeunaan ngumpulkeun log sareng ngawaskeun sadayana proyék sacara gembleng. Rinci handapeun cut.

Pikeun leuwih ti opat taun kuring geus kaayaan sagala sorts tugas patali backend nu.

Ngunggah, nyimpen, ngolah, nyebarkeun média: pidéo, streaming langsung, audio, poto, dokumén.
Infrastruktur, platform, ngawaskeun pamekar, log, cache régional, CDN, protokol RPC proprietary.
Integrasi sareng jasa éksternal: béwara push, parsing tautan éksternal, feed RSS.
Ngabantosan kolega sareng sababaraha patarosan, jawaban anu peryogi nyilem kana kode anu teu dipikanyaho.

Antukna, kuring kungsi leungeun dina loba komponén loka. Abdi hoyong bagikeun pangalaman ieu.

Arsitéktur umum

Sagalana, sakumaha biasa, dimimitian ku server atawa grup server nu narima requests.

server hareup

Server hareup narima requests via HTTPS, RTMP na WSS.

HTTPS - ieu mangrupikeun pamundut kanggo vérsi wéb utama sareng mobile dina situs: vk.com sareng m.vk.com, sareng klien resmi sareng henteu resmi API kami: klien mobile, utusan. Simkuring gaduh panarimaan RTMP-lalulintas pikeun siaran Live kalawan server hareup misah tur WSS- sambungan pikeun Streaming API.

Pikeun HTTPS sareng WSS dina server éta patut nginx. Pikeun siaran RTMP, urang nembé ngalih ka solusi urang sorangan kive, tapi éta saluareun ruang lingkup laporan. Pikeun kasabaran lepat, server ieu Ngaiklan alamat IP umum tur polah dina grup ambéh lamun aya masalah dina salah sahiji server, requests pamaké teu leungit. Pikeun HTTPS sareng WSS, server anu sami ieu énkripsi lalu lintas supados nyandak bagian tina beban CPU kana diri.

Urang moal ngobrol salajengna ngeunaan WSS na RTMP, tapi ngan ngeunaan requests HTTPS baku, nu biasana pakait sareng proyék web.

Backend

Tukangeun hareup biasana aya server backend. Aranjeunna ngolah requests yén server hareup narima ti klien.

ieu server kPHP, dimana daemon HTTP dijalankeun, sabab HTTPS parantos didekripsi. kPHP mangrupakeun server anu dijalankeun dina modél prefork: dimimitian prosés master, kebat prosés anak, ngalirkeun sockets ngadangukeun aranjeunna sarta aranjeunna ngolah requests maranéhna. Dina hal ieu, prosés teu restarted antara unggal pamundut ti pamaké, tapi ngan ngareset kaayaan maranéhna pikeun kaayaan enol-nilai aslina - pamundut sanggeus pamundut, tinimbang balikan deui.

Sebaran beban

Kabéh backends kami henteu kolam renang badag mesin nu bisa ngolah pamundut nanaon. Urang aranjeunna dibagi kana grup misah: umum, mobile, api, video, pementasan ... Masalah dina grup misah mesin moal mangaruhan sakabeh séjén. Upami aya masalah sareng pidéo, pangguna anu ngadangukeun musik malah moal terang ngeunaan masalah éta. Nu backend pikeun ngirim pamundut ka mutuskeun ku nginx on hareup nurutkeun config nu.

kempelan métrik jeung rebalancing

Pikeun ngarti sabaraha mobil urang kudu boga di unggal grup, urang ulah ngandelkeun QPS. The backends béda, maranéhna boga requests béda, unggal pamundut boga pajeulitna béda tina ngitung QPS. Éta sababna urang kami beroperasi kalawan konsép beban dina server sakabéhna - dina CPU jeung perf.

Simkuring gaduh rébuan server sapertos. Unggal server fisik ngajalankeun grup kPHP pikeun ngadaur mulangkeunana sakabeh cores (sabab kPHP nyaeta single threaded).

Server eusi

CS atawa Content Server mangrupakeun gudang. CS mangrupikeun server anu nyimpen file sareng ogé ngolah file anu diunggah sareng sadaya jinis tugas sinkron latar anu ditugaskeun ku frontend wéb utama.

Kami ngagaduhan puluhan rébu server fisik anu nyimpen file. Pamaké resep unggah file, sareng urang resep nyimpen sareng ngabagikeunana. Sababaraha server ieu ditutup ku server pu / pp husus.

pu/pp

Upami anjeun muka tab jaringan dina VK, anjeun ningali pu/pp.

Naon ari pu/pp? Upami urang nutup hiji server saatosna, teras aya dua pilihan pikeun unggah sareng ngaunduh file ka server anu ditutup: langsung через http://cs100500.userapi.com/path atawa via server panengah - http://pu.vk.com/c100500/path.

Pu mangrupikeun nami sajarah pikeun unggah poto, sareng pp mangrupikeun proxy poto. Hartina, hiji server keur ngamuat poto, sarta séjén pikeun unggah. Ayeuna henteu ngan ukur poto anu dimuat, tapi nami parantos dilestarikan.

server ieu nungtungan sesi HTTPSpikeun nyoplokkeun beban processor ti gudang. Ogé, saprak file pamaké diolah dina server ieu, informasi kirang sénsitip disimpen dina mesin ieu, anu hadé. Contona, konci enkripsi HTTPS.

Kusabab mesin ditutup ku mesin urang anu sanés, urang tiasa mampuh henteu masihan aranjeunna IP éksternal "bodas", sareng masihan "abu". Ku cara ieu kami disimpen dina kolam renang IP sareng ngajamin ngajagi mesin tina aksés luar - ngan saukur teu aya IP pikeun asup kana éta.

Resiliency leuwih IP dibagikeun. Dina watesan kasabaran sesar, skéma gawéna sarua - sababaraha server fisik boga IP fisik umum, jeung hardware di hareup aranjeunna milih dimana ngirim pamundut teh. Kuring bakal ngobrol ngeunaan pilihan séjén engké.

Titik kontroversial nyaéta dina hal ieu klien nu ngajaga sambungan pangsaeutikna. Upami aya IP anu sami pikeun sababaraha mesin - sareng host anu sami: pu.vk.com atanapi pp.vk.com, browser klien ngagaduhan wates jumlah pamundut sakaligus ka hiji host. Tapi dina waktos HTTP ubiquitous / 2, abdi yakin yén ieu geus euweuh jadi relevan.

The disadvantage atra tina skéma téh nya éta kudu ngompa sakabéh lalulintas, nu mana ka gudang, ngaliwatan server sejen. Kusabab urang ngompa lalulintas ngaliwatan mesin, urang teu acan tiasa ngompa lalulintas beurat, contona, video, ngagunakeun skéma sarua. Kami ngirimkeunana langsung - sambungan langsung anu misah pikeun panyimpenan anu misah khusus pikeun pidéo. Urang ngirimkeun eusi torek ngaliwatan proxy a.

Teu lami pisan urang ngagaduhan versi proksi anu langkung saé. Ayeuna kuring bakal nyarioskeun ka anjeun kumaha aranjeunna béda ti anu biasa sareng naha ieu diperyogikeun.

panonpoe

Dina Séptémber 2017, Oracle, anu sateuacana mésér Sun, dipecat sajumlah ageung karyawan Sun. Urang tiasa nyebatkeun yén dina waktos ayeuna perusahaan parantos teu aya. Nalika milih nami pikeun sistem énggal, pangurus kami mutuskeun pikeun ngahormatan mémori perusahaan ieu sareng namina sistem anyar Sun. Di antara urang urang ngan saukur nyebut dirina "suns".

pp ngagaduhan sababaraha masalah. Hiji IP per grup - cache teu epektip. Sababaraha server fisik ngabagi alamat IP umum, sareng teu aya deui jalan pikeun ngontrol server mana anu bakal dituju. Ku alatan éta, lamun pamaké béda datangna pikeun file sarua, lajeng lamun aya cache dina server ieu, file ends up dina cache unggal server. Ieu mangrupikeun skéma anu teu cekap, tapi teu aya anu tiasa dilakukeun.

Akibatna- urang teu bisa beling eusi, sabab urang teu bisa milih server husus pikeun grup ieu - aranjeunna gaduh IP umum. Ogé pikeun sababaraha alesan internal urang gaduh teu mungkin pikeun masang server sapertos di daérah. Aranjeunna nangtung ngan di St.

Kalayan panonpoé, urang ngarobih sistem pamilihan. Ayeuna urang gaduh routing anycast: routing dinamis, anycast, timer pariksa daemon. Unggal server boga IP individu sorangan, tapi subnet umum. Sagalana geus ngonpigurasi dina cara sapertos nu lamun hiji server gagal, lalulintas anu sumebar ka sakuliah server séjén grup sarua otomatis. Ayeuna kasebut nyaéta dimungkinkeun pikeun milih hiji server husus, euweuh cache kaleuleuwihan, jeung reliabilitas teu kapangaruhan.

Pangrojong beurat. Ayeuna urang tiasa mampuh masang mesin tina kakuatan anu béda-béda upami diperyogikeun, sareng ogé, upami aya masalah samentawis, ngarobih beurat "panonpoé" kerja pikeun ngirangan beban aranjeunna, supados aranjeunna "istirahat" sareng ngamimitian damel deui.

Sharding ku id eusi. Hiji hal lucu ngeunaan sharding: urang biasana beling eusi ambéh pamaké béda buka file sarua ngaliwatan "panonpoé" sarua ambéh maranéhanana boga cache umum.

Kami nembe ngaluncurkeun aplikasi "Clover". Ieu mangrupikeun kuis online dina siaran langsung, dimana host naroskeun patarosan sareng pangguna ngajawab sacara real waktos, milih pilihan. Aplikasina gaduh obrolan dimana pangguna tiasa ngobrol. Bisa sakaligus nyambung ka siaran leuwih ti 100 rébu urang. Éta kabéh nulis pesen nu dikirim ka sadaya pamilon, sarta avatar datangna babarengan jeung pesen. Lamun 100 sarébu jalma datang pikeun hiji avatar dina hiji "panonpoé", éta kadang bisa gulung balik awan.

Dina raraga tahan bursts of requests pikeun file sarua, éta pikeun jenis nu tangtu eusi nu urang ngahurungkeun skéma bodo nu nyebarkeun file sakuliah sadaya sadia "suns" di wewengkon.

Panonpoé ti jero

Proksi sabalikna dina nginx, cache boh dina RAM atanapi dina disk Optane / NVMe gancang. conto: http://sun4-2.userapi.com/c100500/path - tumbu ka "panonpoé", anu perenahna di wewengkon kaopat, grup server kadua. Éta nutup file jalur, anu sacara fisik aya dina server 100500.

tutup

Urang tambahkeun hiji titik deui kana skéma arsitéktur urang - lingkungan cache.

Di handap ieu diagram perenah caches régional, aya kira-kira 20 di antarana. Di handap ieu mangrupakeun tempat dimana caches jeung "suns" lokasina, nu bisa cache lalulintas ngaliwatan sorangan.

Ieu cache eusi multimedia; euweuh data pamaké disimpen di dieu - ngan musik, video, poto.

Pikeun nangtukeun wewengkon pamaké, urang urang ngumpulkeun awalan jaringan BGP ngumumkeun di wewengkon. Dina kasus fallback, urang ogé kudu parse database geoip lamun urang teu bisa manggihan IP ku awalan. Urang nangtukeun wewengkon ku IP pamaké. Dina kode, urang tiasa ningali hiji atanapi langkung daérah pangguna - titik-titik anu pangdeukeutna sacara geografi.

Kumaha carana sangkan eta pagawean?

Urang ngitung popularitas file dumasar wewengkon. Aya sajumlah cache régional dimana pangguna aya, sareng identifier file - urang nyandak pasangan ieu sareng ningkatkeun rating sareng unggal undeuran.

Dina waktos anu sami, setan - jasa di daérah - ti waktos ka waktos sumping ka API sareng ucapkeun: "Kuring mangrupikeun cache sapertos kitu, pasihan abdi daptar file anu pang populerna di daérah kuring anu henteu acan aya. ” API ngirimkeun sakumpulan file anu diurutkeun dumasar rating, daemon ngaunduhana, nyandak ka daérah sareng ngirim file ti dinya. Ieu beda fundamental antara pu / pp na Sun ti caches: aranjeunna masihan file ngaliwatan sorangan geuwat, sanajan file ieu teu di cache, sarta cache mimiti ngundeur file ka dirina, lajeng dimimitian masihan deui.

Dina hal ieu urang meunang eusi ngadeukeutan ka pamaké sareng nyebarkeun beban jaringan. Contona, ngan ti cache Moscow urang ngadistribusikaeun leuwih ti 1 Tbit/s salila jam puncak.

Tapi aya masalah - server cache teu karét. Pikeun eusi super populér, kadang teu cukup jaringan pikeun server misah. server cache kami téh 40-50 Gbit / s, tapi aya eusi nu sagemblengna clogs saluran misalna. Kami nuju ngalaksanakeun panyimpen langkung ti hiji salinan file populér di daérah éta. Abdi ngarepkeun urang bakal ngalaksanakeunana dina ahir taun.

Urang nempo arsitektur umum.

server hareup nu nampa requests.
Backends yén prosés requests.
Panyimpenan anu ditutup ku dua jinis proxy.
caches régional.

Naon anu leungit tina diagram ieu? Tangtosna, pangkalan data dimana urang nyimpen data.

Basis data atanapi mesin

Urang nelepon aranjeunna teu database, tapi mesin - Mesin, sabab urang praktis teu boga database dina rasa ditarima sacara umum.

Ieu ukuran perlu. Ieu kajantenan kusabab dina 2008-2009, nalika VK ngagaduhan popularitas anu ngabeledug, proyék éta damel sadayana dina MySQL sareng Memcache sareng aya masalah. MySQL resep ngadat sareng ngaruksak file, saatos éta moal pulih, sareng Memcache laun-laun didegradasi dina pagelaran sareng kedah di-restart.

Tétéla yén proyék beuki populér miboga gudang pengkuh, nu corrupts data, sarta cache, nu slows turun. Dina kaayaan kitu, hese ngembangkeun hiji proyék tumuwuh. Diputuskeun pikeun nyobaan nulis deui hal-hal kritis anu dipuseurkeun ku proyék kana sapédah urang sorangan.

Solusina suksés. Aya kasempetan pikeun ngalakukeun ieu, kitu ogé hiji kabutuhan ekstrim, sabab cara séjén skala teu aya dina waktu éta. Henteu aya seueur pangkalan data, NoSQL teu acan aya, ngan ukur aya MySQL, Memcache, PostrgreSQL - sareng éta.

Operasi universal. Pangwangunan ieu dipimpin ku tim pamekar C kami sareng sadayana dilakukeun sacara konsisten. Henteu paduli mesinna, aranjeunna sadayana gaduh format file anu sami anu ditulis kana disk, parameter peluncuran anu sami, sinyal anu diprosés ku cara anu sami, sareng kalakuanana kirang langkung sami upami aya kaayaan sareng masalah. Kalayan tumuwuhna mesin, éta merenah pikeun pangurus pikeun beroperasi sistem - teu aya kebon binatang nu kudu dijaga, sarta maranéhanana kudu diajar deui kumaha carana beroperasi unggal database pihak-katilu anyar, nu ngamungkinkeun pikeun gancang sarta merenah pikeun ngaronjatkeun. jumlah maranéhanana.

Jinis mesin

Tim éta nyerat sababaraha mesin. Ieu ngan sababaraha di antarana: sobat, petunjuk, gambar, ipdb, hurup, daptar, log, memcached, meowdb, warta, nostradamus, poto, playlist, pmemcached, sandbox, pilarian, neundeun, likes, tugas, ...

Pikeun unggal tugas anu merlukeun struktur data husus atawa prosés requests atypical, tim C nulis mesin anyar. Naha henteu.

Simkuring boga mesin misah memcached, nu sarupa jeung nu biasa, tapi ku kebat goodies, jeung nu teu ngalambatkeun turun. Teu ClickHouse, tapi ogé jalan. Sadia misah pmecached - eta pengkuh memcached, nu ogé bisa nyimpen data dina disk, komo deui, ti fits kana RAM, ku kituna teu leungit data nalika restarting. Aya sababaraha mesin pikeun tugas individu: antrian, daptar, set - sadayana anu diperyogikeun ku proyék kami.

Kluster

Tina sudut pandang kode, teu kedah nganggap mesin atanapi pangkalan data salaku prosés, éntitas, atanapi instansi. Kodeu dianggo sacara khusus sareng klaster, sareng grup mesin - hiji tipe per klaster. Hayu urang nyebutkeun aya klaster memcached - éta ngan grup mesin.

Kodeu teu kedah terang lokasi fisik, ukuran, atanapi jumlah server pisan. Anjeunna mana kana klaster ngagunakeun identifier tangtu.

Jang ngalampahkeun ieu, anjeun kedah nambihan hiji éntitas deui anu aya di antara kode sareng mesin - proxy.

proxy RPC

Proksi beus nyambungkeun, dimana ampir sakabéh situs dijalankeun. Dina waktu nu sarua urang boga euweuh kapanggihna jasa - tibatan, aya config pikeun proxy ieu, nu terang lokasi sadaya klaster sarta sakabeh shards klaster ieu. Ieu anu dilakukeun ku admin.

Programer henteu paduli pisan sabaraha, dimana sareng naon hargana - aranjeunna ngan ukur angkat ka kluster. Hal ieu ngamungkinkeun urang pisan. Nalika nampi pamundut, proxy alihan pamundut, terang dimana - éta nangtukeun ieu sorangan.

Dina hal ieu, proxy mangrupikeun titik panyalindungan ngalawan kagagalan jasa. Upami sababaraha mesin ngalambatkeun atanapi ngadat, maka proxy ngartos ieu sareng ngabales sasuai ka sisi klien. Ieu ngidinan Anjeun pikeun miceun timeout nu - kode teu ngadagoan mesin pikeun ngabales, tapi ngarti yén éta teu bisa dipake jeung kudu kalakuanana kumaha bae age béda. Kode kudu disiapkeun pikeun kanyataan yén database teu salawasna jalan.

palaksanaan husus

Kadang-kadang urang masih hoyong gaduh sababaraha jinis solusi non-standar salaku mesin. Dina waktos anu sami, éta diputuskeun pikeun henteu nganggo rpc-proxy kami anu siap-siap, didamel khusus pikeun mesin kami, tapi ngadamel proxy anu misah pikeun tugas éta.

Pikeun MySQL, anu masih aya di ditu di dieu, kami nganggo db-proxy, sareng pikeun ClickHouse - Imah anak ucing.

Gawéna umumna kawas kieu. Aya server tangtu, éta ngajalankeun kPHP, Go, Python - sacara umum, sagala kode nu bisa ngagunakeun protokol RPC urang. Kodeu dijalankeun sacara lokal dina proksi RPC - unggal server dimana kodeu lokasina ngajalankeun proxy lokalna sorangan. Upami dipénta, proksi ngartos dimana angkat.

Lamun hiji mesin hayang buka sejen, sanajan tatanggana, eta ngaliwatan proxy, sabab tatanggana bisa jadi di puseur data sejen. Mesin teu kedah ngandelkeun uninga lokasi nanaon lian ti dirina - ieu téh solusi baku urang. Tapi tangtu aya pengecualian :)

Conto TL-skéma nurutkeun nu sagala mesin beroperasi.

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;

Ieu mangrupikeun protokol binér, analog pangdeukeutna nyaéta protobuf. Skéma éta predescribes widang pilihan, tipe kompléks - ekstensi tina skalar diwangun-di, sarta queries. Sagalana jalan nurutkeun protokol ieu.

RPC leuwih TL leuwih TCP/UDP… UDP?

Simkuring boga protokol RPC pikeun executing requests engine nu dijalankeun dina luhureun skéma TL. Ieu sadayana dianggo dina sambungan TCP/UDP. TCP kaharti, tapi naha urang peryogi UDP sering?

UDP mantuan Ngahindarkeun masalah sajumlah ageung sambungan antara server. Upami unggal server ngagaduhan proxy RPC sareng, sacara umum, éta tiasa angkat ka mesin naon waé, teras aya puluhan rébu sambungan TCP per server. Aya beban, tapi teu aya gunana. Dina kasus UDP masalah ieu teu aya.

Taya sasalaman TCP kaleuleuwihan. Ieu mangrupikeun masalah anu biasa: nalika mesin énggal atanapi server énggal diluncurkeun, seueur sambungan TCP didamel sakaligus. Pikeun requests lightweight leutik, Contona, UDP payload, sadaya komunikasi antara kode jeung mesin téh dua pakét UDP: hiji flies dina hiji arah, nu kadua di séjén. Hiji perjalanan babak - sareng kode nampi réspon ti mesin tanpa sasalaman.

Sumuhun, eta sadayana ngan jalan kalawan persentase leutik pisan pakét leungitna. Protokol ngagaduhan dukungan pikeun ngirimkeun deui sareng waktosna, tapi upami urang kaleungitan pisan, urang bakal nampi ampir TCP, anu henteu aya mangpaatna. Kami henteu ngajalankeun UDP meuntas sagara.

Kami gaduh rébuan server sapertos kitu, sareng skémana sami: sabungkus mesin dipasang dina unggal server fisik. Aranjeunna lolobana single-threaded pikeun ngajalankeun gancang-gancang tanpa blocking, sarta sharded salaku solusi single-threaded. Dina waktos anu sami, urang teu gaduh anu langkung dipercaya tibatan mesin ieu, sareng seueur perhatian anu dibayar pikeun neundeun data anu pengkuh.

neundeun data pengkuh

Mesin nulis binlogs. A binlog mangrupakeun file dina tungtung nu hiji acara pikeun parobahan kaayaan atawa data ditambahkeun. Dina leyuran béda disebut béda: log binér, WAL, AOF, tapi prinsipna sarua.

Pikeun nyegah mesin tina ulang maca sakabéh binlog salila sababaraha taun nalika restarting, mesin nulis snapshots - kaayaan ayeuna. Upami diperlukeun, aranjeunna maca ti dinya heula, lajeng rengse maca ti binlog nu. Kabéh binlogs ditulis dina format binér sarua - nurutkeun skéma TL, ku kituna admins bisa administer aranjeunna sarua jeung parabot maranéhanana. Henteu aya kabutuhan sapertos snapshots. Aya lulugu umum nu nunjukkeun snapshot nu int, magic mesin, jeung awak nu teu penting pikeun saha. Ieu masalah jeung mesin nu dirékam snapshot nu.

Kuring bakal gancang ngajelaskeun prinsip operasi. Aya server dimana mesin dijalankeun. Anjeunna muka binlog kosong anyar pikeun nulis jeung nulis hiji acara pikeun robah eta.

Dina sababaraha waktos, anjeunna mutuskeun nyandak snapshot nyalira, atanapi anjeunna nampi sinyal. Server nyiptakeun file anyar, nyerat sadayana kaayaan na, nambihan ukuran binlog ayeuna - offset - ka tungtung file, sareng teras nyerat salajengna. A binlog anyar teu dijieun.

Di sawatara titik, nalika mesin restarted, bakal aya duanana binlog na snapshot on disk. Mesin maca sakabéh snapshot na raises kaayaan na dina titik nu tangtu.

Maca posisi anu dina waktu snapshot dijieun jeung ukuran binlog nu.

Maca tungtung binlog pikeun meunangkeun kaayaan ayeuna terus nulis acara salajengna. Ieu mangrupikeun skéma saderhana; sadaya mesin urang tiasa dianggo dumasar kana éta.

Réplikasi data

Hasilna, réplikasi data di urang dumasar-pernyataan - urang nulis dina binlog teu sagala parobahan kaca, tapi nyaéta requests robah. Sarupa pisan jeung naon asalna ngaliwatan jaringan, ngan rada dirobah.

Skéma anu sami dianggo henteu ngan ukur pikeun réplikasi, tapi ogé pikeun nyieun cadangan. Kami gaduh mesin - master tulisan anu nyerat kana binlog. Di mana waé tempat anu admin nyetél éta, binlog ieu disalin, sareng éta - urang gaduh cadangan.

Upami diperyogikeun réplika bacaanPikeun ngurangan beban maca CPU, mesin bacaan saukur dibuka, nu maca tungtung binlog jeung executes Paréntah ieu lokal.

Lag dieu pisan leutik, jeung kasebut nyaéta dimungkinkeun pikeun manggihan sabaraha replica lags tukangeun master.

Sharding data dina proxy RPC

Kumaha sharding jalan? Kumaha proxy ngartos mana cluster shard pikeun ngirim? Kodeu henteu nyarios: "Kirim pikeun 15 beling!" - henteu, ieu dilakukeun ku proxy.

Skéma pangbasajanna nyaéta firstint - angka kahiji dina pamundut.

get(photo100_500) => 100 % N.

Ieu conto pikeun protokol téks memcached basajan, tapi, tangtosna, queries tiasa rumit sarta terstruktur. Conto nyokot nomer kahiji dina pamundut jeung sésana lamun dibagi ku ukuran klaster.

Ieu mangpaat nalika urang hoyong gaduh data lokalitas hiji éntitas tunggal. Sebutkeun 100 mangrupikeun pangguna atanapi ID grup, sareng kami hoyong sadaya data tina hiji éntitas aya dina hiji beling pikeun patarosan kompleks.

Upami urang henteu paduli kumaha pamenta disebarkeun ka kluster, aya pilihan sanés - hashing sakabéh beling.

hash(photo100_500) => 3539886280 % N

Urang ogé meunang Hash, sésa division jeung jumlah beling.

Kadua pilihan ieu ngan tiasa dianggo upami urang disiapkeun kanyataan yén nalika urang ningkatkeun ukuran klaster, kami bakal ngabagi atanapi ningkatkeun sababaraha kali. Salaku conto, urang ngagaduhan 16 beling, urang henteu cekap, urang hoyong langkung seueur - urang tiasa nampi 32 kalayan aman tanpa downtime. Lamun urang hayang ningkatkeun teu lilipetan, bakal aya downtime, sabab urang moal bisa akurat dibeulah sagalana nepi tanpa karugian. pilihan ieu mangpaat, tapi teu salawasna.

Upami urang kedah nambihan atanapi mupus sajumlah server anu sawenang, kami nganggo Hashing konsisten dina ring a la Ketama. Tapi dina waktos anu sami, urang kaleungitan lokalitas data; urang kedah ngahijikeun pamundut ka kluster supados masing-masing sapotong mulihkeun réspon anu alit, teras ngahijikeun réspon kana proxy.

Aya requests super-spésifik. Sigana mah kieu: proxy RPC narima pamundut nu, nangtukeun mana klaster buka jeung nangtukeun beling nu. Lajeng aya boh tulisan Masters, atawa, lamun klaster boga rojongan replica, eta ngirimkeun ka replica on pamundut. Proxy ngalakukeun sadayana ieu.

Log

Urang nulis log ku sababaraha cara. Anu paling atra sareng sederhana nyaéta nulis log mun memcache.

ring-buffer: prefix.idx = line

Aya awalan konci - nami log, garis, sareng aya ukuran log ieu - jumlah garis. Simkuring nyandak angka acak tina 0 kana jumlah garis dikurangan 1. Konci dina memcache mangrupakeun awalan concatenated kalawan angka acak ieu. Urang nyimpen garis log jeung waktu ayeuna kana nilai.

Nalika perlu maca log, urang ngalaksanakeun Multi Meunang kabéh konci, diurutkeun dumasar kana waktu, sahingga meunang log produksi sacara real waktos. Skéma ieu dipaké nalika anjeun kudu debug hal dina produksi sacara real waktu, tanpa megatkeun nanaon, tanpa eureun atawa ngidinan lalulintas keur mesin séjén, tapi log ieu teu lepas panjang.

Pikeun neundeun dipercaya tina log kami boga mesin log-mesin. Éta pisan sababna naha éta dijieun tur loba dipaké dina sajumlah badag klaster. Kluster panggedéna anu kuring terang toko 600 TB log anu dipak.

Mesinna tos lami pisan, aya klaster anu tos umur 6-7 taun. Aya masalah anu urang nyobian pikeun ngajawab, contona, urang mimiti aktip ngagunakeun ClickHouse pikeun nyimpen log.

Ngumpulkeun log di ClickHouse

Diagram ieu nunjukkeun kumaha urang leumpang kana mesin urang.

Aya kode nu mana lokal via RPC ka RPC-proxy, sarta eta understands dimana buka mesin. Upami urang hoyong nyerat log di ClickHouse, urang kedah ngarobih dua bagian dina skéma ieu:

ngaganti sababaraha mesin jeung ClickHouse;
ngaganti proxy RPC, nu teu bisa ngakses ClickHouse, kalawan sababaraha solusi nu bisa, sarta via RPC.

mesin téh basajan - urang ngaganti eta ku server atawa klaster server kalawan ClickHouse.

Sareng angkat ka ClickHouse, kami ngalakukeun Imah Ucing. Lamun urang balik langsung ti KittenHouse mun ClickHouse, éta moal Cope. Sanaos tanpa pamundut, éta nambihan tina sambungan HTTP tina sajumlah ageung mesin. Pikeun skéma jalan, dina server kalawan ClickHouse proxy sabalikna lokal diangkat, nu ditulis dina cara nu bisa tahan volume diperlukeun sambungan. Éta ogé tiasa nyangga data dina dirina sacara rélatif dipercaya.

Kadang-kadang urang teu hoyong nerapkeun skéma RPC dina solusi non-standar, contona, dina nginx. Ku alatan éta, KittenHouse mibanda kamampuhan pikeun nampa log via UDP.

Upami pangirim sareng panampi log damel dina mesin anu sami, maka kamungkinan kaleungitan pakét UDP dina host lokal rada rendah. Salaku kompromi antara kabutuhan pikeun nerapkeun RPC dina solusi pihak katilu jeung reliabilitas, urang ngan ngagunakeun UDP ngirim. Urang bakal balik deui ka skéma ieu engké.

Ngawaskeun

Kami ngagaduhan dua jinis log: anu dikumpulkeun ku pangurus dina serverna sareng anu ditulis ku pamekar tina kode. Éta pakait sareng dua jinis métrik: sistem jeung produk.

metrics Sistim

Gawéna dina sadaya server kami netdata, nu ngumpulkeun statistik sarta ngirimkeunana ka Karbon grafit. Ku alatan éta, ClickHouse dianggo salaku sistem panyimpen, sareng sanés Whisper, contona. Upami diperlukeun, anjeun bisa langsung maca ti ClickHouse, atawa ngagunakeun grafana pikeun metrics, grafik na laporan. Salaku pamekar, urang boga cukup aksés ka Netdata jeung Grafana.

metrics produk

Pikeun genah, kami geus nulis loba hal. Salaku conto, aya sakumpulan fungsi biasa anu ngamungkinkeun anjeun nyerat Counts, UniqueCounts nilai kana statistik, anu dikirimkeun ka mana waé.

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

$stats = statlogsStatData($params)

Salajengna, urang tiasa nganggo asihan sareng ngagolongkeun saringan sareng ngalakukeun sadayana anu dipikahoyong tina statistik - ngawangun grafik, ngonpigurasikeun Watchdogs.

Urang nulis pisan loba metrics jumlah acara ti 600 milyar nepi ka 1 triliun per poé. Najan kitu, urang rék tetep aranjeunna sahenteuna sababaraha taunngartos tren dina métrik. Ngahijikeun éta sadayana mangrupikeun masalah anu ageung anu teu acan direngsekeun. Kuring gé ngabejaan ka maneh kumaha eta geus jalan pikeun sababaraha taun ka tukang.

Kami ngagaduhan fungsi anu nyerat métrik ieu mun memcache lokalpikeun ngurangan jumlah éntri. Sakali dina periode pondok waktu lokal dibuka stats-daemon ngumpulkeun sakabéh rékaman. Salajengna, sétan ngahijikeun métrik kana dua lapisan server log-kolektor, nu aggregates statistik tina kebat mesin urang ku kituna lapisan tukangeun maranéhna teu maot.

Upami diperlukeun, urang bisa nulis langsung ka log-kolektor.

Tapi nulis tina kode langsung ka kolektor, bypassing stas-daemom, mangrupakeun leyuran kirang scalable sabab naek beban dina kolektor. Leyuran anu cocog ngan lamun pikeun sababaraha alesan urang teu bisa ngangkat memcache stats-daemon dina mesin, atanapi eta nabrak jeung urang indit langsung.

Salajengna, log-kolektor ngagabungkeun statistik kana meowDB - ieu database urang, nu ogé bisa nyimpen metrics.

Teras urang tiasa ngadamel pilihan binér "deukeut-SQL" tina kode éta.

Eksperimen

Dina usum panas 2018, urang tadi hiji hackathon internal, sarta ideu datang nepi ka nyoba ngaganti bagian beureum tina diagram jeung hal anu bisa nyimpen metrics di ClickHouse. Simkuring gaduh log on ClickHouse - naha henteu coba eta?

Kami ngagaduhan skéma anu nyerat log ngalangkungan KittenHouse.

Urang mutuskeun tambahkeun sejen "* Imah" pikeun diagram, nu bakal nampa persis metrics dina format sakumaha kode urang nyerat aranjeunna via UDP. Lajeng ieu * House kabukti kana inserts, kawas log, nu KittenHouse understands. Anjeunna sampurna tiasa nganteurkeun log ieu ka ClickHouse, anu kedah tiasa maca aranjeunna.

Skéma sareng memcache, stats-daemon sareng database log-collectors diganti ku ieu.

Aya kiriman ti kode di dieu, anu ditulis sacara lokal di StatsHouse.
StatsHouse nyerat métrik UDP, parantos dirobih kana sisipan SQL, ka KittenHouse dina bets.
KittenHouse ngirimkeunana ka ClickHouse.
Upami urang hoyong maca aranjeunna, maka urang maca aranjeunna ngalangkungan StatsHouse - langsung ti ClickHouse nganggo SQL biasa.

Naha masih ékspérimén, tapi urang resep kumaha tétéla. Upami urang ngalereskeun masalah sareng skéma, panginten urang bakal ngalih ka éta lengkep. Sacara pribadi, kuring miharep kitu.

Skéma teu nyimpen beusi. Pangsaeutikna server anu diperlukeun, stats-daemons lokal jeung log-kolektor teu diperlukeun, tapi ClickHouse merlukeun server leuwih badag batan nu aya dina skéma ayeuna. Pangsaeutikna server anu diperyogikeun, tapi kedah langkung mahal sareng langkung kuat.

Nyebarkeun

Kahiji, hayu urang nempo deployment PHP. Kami ngembang di séwang: ngagunakeun GitLab и TeamCity pikeun deployment. Cabang pamekaran dihijikeun kana cabang master, tina master pikeun nguji aranjeunna dihijikeun kana pementasan, sareng tina pementasan kana produksi.

Sateuacan panyebaran, cabang produksi ayeuna sareng anu sateuacana dicandak, sareng file diff dianggap di antarana - parobihan: didamel, dihapus, dirobih. Parobahan ieu kacatet dina binlog mesin copyfast husus, nu bisa gancang ngayakeun réplikasi parobahan ka sakabéh armada server urang. Anu dianggo di dieu sanés nyalin langsung, tapi réplikasi gosip, lamun hiji server ngirimkeun parobahan ka tatanggana pangdeukeutna, maranéhanana ka tatanggana, jeung saterusna. Ieu ngidinan Anjeun pikeun ngapdet kode dina puluhan sarta unit detik sakuliah sakabéh armada. Nalika parobahanana ngahontal réplika lokal, éta nerapkeun patches ieu ka na sistem file lokal. Rollback ogé dilaksanakeun dumasar kana skéma anu sami.

Urang ogé nyebarkeun kPHP pisan sarta eta oge boga ngembangkeun sorangan dina séwang nurutkeun diagram di luhur. Kusabab ieu binér server HTTP, mangka urang teu bisa ngahasilkeun diff - binér release beuratna ratusan MB. Ku alatan éta, aya pilihan sejen di dieu - versi ditulis pikeun binlog copyfast. Kalawan unggal ngawangun eta naek, sarta salila rollback ogé naek. Vérsi replicated ka server. Copyfasts lokal ningali yén versi anyar geus diasupkeun binlog, sarta ku réplikasi gosip sarua maranéhna nyokot versi panganyarna tina binér keur diri, tanpa capé server master urang, tapi taliti nyebarkeun beban sakuliah jaringan. Naon kieu peluncuran deui anggun pikeun versi anyar.

Pikeun mesin kami, anu ogé dasarna binér, skéma éta sami pisan:

git master cabang;
binér di .deb;
versi ditulis ka binlog copyfast;
replicated ka server;
server narik kaluar .dep seger;
dpkg -i;
anggun relaunch kana versi anyar.

Bédana nyaéta binér urang dibungkus dina arsip .deb, sarta nalika ngompa kaluar aranjeunna dpkg -i disimpen dina sistem. Naha kPHP disebarkeun salaku binér, sareng mesin dipasang salaku dpkg? Kajadian kitu. Gawéna - ulah noél.

Tumbu mangpaat:

Laporan ku Anton Kiryushkin "Administrator sistem Vkontakte. Kumaha?" kalayan detil ngeunaan copyfast sareng gosip.
Laporan ku Yuri Nasretdinov "Kumaha VK nyelapkeun data kana CLickHouse tina puluhan rébu server".
laporan kuring "Arsitéktur proyék ngembang nganggo conto VKontakte", Tapi tina sudut pandang pamekaran, sanés hardware.

Alexey Akulovich mangrupakeun salah sahiji jalma anu, salaku bagian tina Panitia Program, mantuan PHP Rusia on 17 Méi bakal jadi acara pangbadagna pikeun pamekar PHP di kali panganyarna. Tingali naon PC keren kami, naon speaker (dua di antarana anu ngamekarkeun inti PHP!) - Sigana kawas hal nu teu bisa sono lamun nulis PHP.

sumber: www.habr.com

FAQ ngeunaan arsitéktur sareng karya VKontakte