VKontakte ના આર્કિટેક્ચર અને કાર્ય પર FAQ

વીકોન્ટાક્ટેની રચનાનો ઇતિહાસ વિકિપીડિયા પર છે; તે પાવેલ દ્વારા પોતે જ કહેવામાં આવ્યું હતું. એવું લાગે છે કે દરેક તેને પહેલેથી જ જાણે છે. HighLoad++ Pavel પર સાઇટના આંતરિક, આર્કિટેક્ચર અને બંધારણ વિશે મને 2010 માં કહ્યું. ત્યારથી ઘણા સર્વર લીક થઈ ગયા છે, તેથી અમે માહિતી અપડેટ કરીશું: અમે તેનું વિચ્છેદન કરીશું, અંદરથી બહાર કાઢીશું, તેનું વજન કરીશું અને VK ઉપકરણને તકનીકી દૃષ્ટિકોણથી જોઈશું.

એલેક્સી અકુલોવિચ (એટરકેટસ) VKontakte ટીમમાં બેકએન્ડ ડેવલપર. આ રિપોર્ટની ટ્રાન્સક્રિપ્ટ એ પ્લેટફોર્મ, ઈન્ફ્રાસ્ટ્રક્ચર, સર્વર્સ અને તેમની વચ્ચેની ક્રિયાપ્રતિક્રિયા વિશે વારંવાર પૂછાતા પ્રશ્નોના સામૂહિક જવાબ છે, પરંતુ વિકાસ વિશે નહીં, એટલે કે આયર્ન વિશે. અલગથી, ડેટાબેસેસ વિશે અને તેના બદલે VK પાસે શું છે, લોગ એકત્રિત કરવા અને સમગ્ર પ્રોજેક્ટનું સંપૂર્ણ નિરીક્ષણ કરવા વિશે. કટ હેઠળ વિગતો.

ચાર વર્ષથી વધુ સમયથી હું બેકએન્ડથી સંબંધિત તમામ પ્રકારના કાર્યો સાથે કામ કરી રહ્યો છું.

• અપલોડ કરવું, સ્ટોર કરવું, પ્રક્રિયા કરવી, મીડિયાનું વિતરણ કરવું: વિડિયો, લાઇવ સ્ટ્રીમિંગ, ઑડિઓ, ફોટા, દસ્તાવેજો.
• ઈન્ફ્રાસ્ટ્રક્ચર, પ્લેટફોર્મ, ડેવલપર મોનિટરિંગ, લોગ, પ્રાદેશિક કેશ, CDN, માલિકીનું RPC પ્રોટોકોલ.
• બાહ્ય સેવાઓ સાથે એકીકરણ: પુશ સૂચનાઓ, બાહ્ય લિંક પાર્સિંગ, RSS ફીડ.
• વિવિધ પ્રશ્નો સાથે સહકાર્યકરોને મદદ કરવી, જેના જવાબો માટે અજાણ્યા કોડમાં ડાઇવિંગની જરૂર છે.

આ સમય દરમિયાન, સાઇટના ઘણા ઘટકોમાં મારો હાથ હતો. હું આ અનુભવ શેર કરવા માંગુ છું.

સામાન્ય આર્કિટેક્ચર

બધું, હંમેશની જેમ, સર્વર અથવા સર્વર્સના જૂથથી શરૂ થાય છે જે વિનંતીઓ સ્વીકારે છે.

ફ્રન્ટ સર્વર

આગળનું સર્વર HTTPS, RTMP અને WSS દ્વારા વિનંતીઓ સ્વીકારે છે.

HTTPS - આ સાઇટના મુખ્ય અને મોબાઇલ વેબ સંસ્કરણો માટેની વિનંતીઓ છે: vk.com અને m.vk.com, અને અમારા API ના અન્ય સત્તાવાર અને બિનસત્તાવાર ક્લાયન્ટ્સ: મોબાઇલ ક્લાયન્ટ્સ, મેસેન્જર્સ. અમારી પાસે રિસેપ્શન છે આરટીએમપી- અલગ ફ્રન્ટ સર્વર સાથે લાઈવ બ્રોડકાસ્ટ માટે ટ્રાફિક અને WSS- સ્ટ્રીમિંગ API માટે જોડાણો.

સર્વર પર HTTPS અને WSS માટે તે મૂલ્યવાન છે nginx. RTMP પ્રસારણ માટે, અમે તાજેતરમાં અમારા પોતાના ઉકેલ પર સ્વિચ કર્યું છે કિવ, પરંતુ તે અહેવાલના અવકાશની બહાર છે. ખામી સહિષ્ણુતા માટે, આ સર્વર્સ સામાન્ય IP સરનામાંની જાહેરાત કરે છે અને જૂથોમાં કાર્ય કરે છે જેથી કરીને જો કોઈ સર્વર પર સમસ્યા હોય, તો વપરાશકર્તા વિનંતીઓ ખોવાઈ ન જાય. HTTPS અને WSS માટે, આ જ સર્વર્સ CPU લોડનો ભાગ પોતાના પર લેવા માટે ટ્રાફિકને એન્ક્રિપ્ટ કરે છે.

અમે WSS અને RTMP વિશે વધુ વાત કરીશું નહીં, પરંતુ માત્ર પ્રમાણભૂત HTTPS વિનંતીઓ વિશે, જે સામાન્ય રીતે વેબ પ્રોજેક્ટ સાથે સંકળાયેલી હોય છે.

પાશ્વભાગ

આગળની પાછળ સામાન્ય રીતે બેકએન્ડ સર્વર્સ હોય છે. તેઓ વિનંતીઓ પર પ્રક્રિયા કરે છે જે ફ્રન્ટ સર્વર ક્લાયંટ પાસેથી મેળવે છે.

આ kPHP સર્વર્સ, જેના પર HTTP ડિમન ચાલી રહ્યું છે, કારણ કે HTTPS પહેલેથી જ ડિક્રિપ્ટ થયેલ છે. kPHP એ સર્વર છે જે ચાલે છે પ્રીફોર્ક મોડલ્સ: એક માસ્ટર પ્રક્રિયા શરૂ કરે છે, બાળ પ્રક્રિયાઓનો સમૂહ, તેમને સાંભળવાના સોકેટ્સ પસાર કરે છે અને તેઓ તેમની વિનંતીઓ પર પ્રક્રિયા કરે છે. આ કિસ્સામાં, વપરાશકર્તાની દરેક વિનંતી વચ્ચે પ્રક્રિયાઓ પુનઃપ્રારંભ કરવામાં આવતી નથી, પરંતુ ફક્ત તેમની સ્થિતિને મૂળ શૂન્ય-મૂલ્ય સ્થિતિમાં રીસેટ કરો - પુનઃપ્રારંભ કરવાને બદલે વિનંતી પછી વિનંતી કરો.

લોડ વિતરણ

અમારા બધા બેકએન્ડ એ મશીનોનો વિશાળ પૂલ નથી જે કોઈપણ વિનંતી પર પ્રક્રિયા કરી શકે. અમે તેમને અલગ જૂથોમાં વિભાજિત: સામાન્ય, મોબાઇલ, api, વિડિઓ, સ્ટેજીંગ... મશીનોના અલગ જૂથ પરની સમસ્યા અન્ય તમામને અસર કરશે નહીં. વિડિયો સાથે સમસ્યાઓના કિસ્સામાં, જે વપરાશકર્તા સંગીત સાંભળે છે તે સમસ્યાઓ વિશે જાણશે પણ નહીં. ક્યા બેકએન્ડને વિનંતી મોકલવી તે રૂપરેખા અનુસાર આગળના ભાગમાં nginx દ્વારા નક્કી કરવામાં આવે છે.

મેટ્રિક સંગ્રહ અને પુનઃસંતુલન

દરેક જૂથમાં આપણી પાસે કેટલી કાર હોવી જરૂરી છે તે સમજવા માટે, અમે QPS પર આધાર રાખશો નહીં. બેકએન્ડ અલગ છે, તેમની પાસે અલગ-અલગ વિનંતીઓ છે, દરેક વિનંતીમાં QPSની ગણતરી કરવાની અલગ જટિલતા છે. તેથી જ અમે અમે સર્વર પર લોડની વિભાવના સાથે કામ કરીએ છીએ - CPU અને perf પર.

અમારી પાસે આવા હજારો સર્વર છે. દરેક ભૌતિક સર્વર તમામ કોરોને રિસાયકલ કરવા માટે kPHP જૂથ ચલાવે છે (કારણ કે kPHP સિંગલ થ્રેડેડ છે).

સામગ્રી સર્વર

CS અથવા સામગ્રી સર્વર એક સંગ્રહ છે. CS એ એક સર્વર છે જે ફાઇલોને સંગ્રહિત કરે છે અને અપલોડ કરેલી ફાઇલો અને તમામ પ્રકારના પૃષ્ઠભૂમિ સિંક્રનસ કાર્યોની પ્રક્રિયા પણ કરે છે જે મુખ્ય વેબ ફ્રન્ટએન્ડ તેને સોંપે છે.

અમારી પાસે હજારો ભૌતિક સર્વર્સ છે જે ફાઇલોને સંગ્રહિત કરે છે. વપરાશકર્તાઓ ફાઇલો અપલોડ કરવાનું પસંદ કરે છે, અને અમે તેને સંગ્રહિત અને શેર કરવાનું પસંદ કરીએ છીએ. આમાંના કેટલાક સર્વરો ખાસ pu/pp સર્વર્સ દ્વારા બંધ કરવામાં આવ્યા છે.

pu/pp

જો તમે VK માં નેટવર્ક ટેબ ખોલ્યું, તો તમે pu/pp જોયું.

pu/pp શું છે? જો આપણે એક પછી એક સર્વર બંધ કરીએ, તો બંધ કરાયેલ સર્વર પર ફાઇલ અપલોડ કરવા અને ડાઉનલોડ કરવા માટેના બે વિકલ્પો છે: સીધા દ્વારા http://cs100500.userapi.com/path અથવા મધ્યવર્તી સર્વર દ્વારા - http://pu.vk.com/c100500/path.

ફોટો અપલોડ માટે પુ એ ઐતિહાસિક નામ છે અને pp એ ફોટો પ્રોક્સી છે. એટલે કે, એક સર્વર ફોટા અપલોડ કરવા માટે છે, અને બીજું અપલોડ કરવા માટે છે. હવે માત્ર ફોટા જ નથી લોડવામાં આવતા, પરંતુ નામ પણ સાચવી રાખવામાં આવ્યું છે.

આ સર્વરો HTTPS સત્રો સમાપ્ત કરોસ્ટોરેજમાંથી પ્રોસેસર લોડ દૂર કરવા માટે. ઉપરાંત, વપરાશકર્તાની ફાઇલો આ સર્વર્સ પર પ્રક્રિયા કરવામાં આવતી હોવાથી, આ મશીનો પર જેટલી ઓછી સંવેદનશીલ માહિતી સંગ્રહિત થશે, તેટલી સારી. ઉદાહરણ તરીકે, HTTPS એન્ક્રિપ્શન કી.

મશીનો અમારા અન્ય મશીનો દ્વારા બંધ હોવાથી, અમે તેમને "સફેદ" બાહ્ય IP ન આપવાનું પરવડી શકીએ છીએ, અને "ગ્રે" આપો. આ રીતે અમે IP પૂલ પર બચત કરી અને મશીનોને બહારના પ્રવેશથી સુરક્ષિત કરવાની ખાતરી આપી - તેમાં પ્રવેશવા માટે કોઈ IP નથી.

વહેંચાયેલ આઈપી પર સ્થિતિસ્થાપકતા. ખામી સહિષ્ણુતાના સંદર્ભમાં, યોજના એ જ રીતે કાર્ય કરે છે - ઘણા ભૌતિક સર્વર્સમાં સામાન્ય ભૌતિક IP હોય છે, અને તેમની સામે હાર્ડવેર વિનંતી ક્યાં મોકલવી તે પસંદ કરે છે. હું અન્ય વિકલ્પો વિશે પછીથી વાત કરીશ.

વિવાદાસ્પદ મુદ્દો એ છે કે આ કિસ્સામાં ક્લાયન્ટ ઓછા જોડાણો રાખે છે. જો ઘણી મશીનો માટે સમાન IP હોય તો - સમાન હોસ્ટ સાથે: pu.vk.com અથવા pp.vk.com, ક્લાયંટ બ્રાઉઝર પાસે એક હોસ્ટને એક સાથે વિનંતીઓની સંખ્યા પર મર્યાદા છે. પરંતુ સર્વવ્યાપક HTTP/2 ના સમયમાં, હું માનું છું કે આ હવે એટલું સુસંગત નથી.

સ્કીમનો સ્પષ્ટ ગેરલાભ એ છે કે તે છે તમામ ટ્રાફિકને પંપ કરો, જે બીજા સર્વર દ્વારા સ્ટોરેજમાં જાય છે. અમે મશીનો દ્વારા ટ્રાફિકને પમ્પ કરીએ છીએ, અમે હજી પણ ભારે ટ્રાફિકને પંપ કરી શકતા નથી, ઉદાહરણ તરીકે, વિડિઓ, સમાન યોજનાનો ઉપયોગ કરીને. અમે તેને સીધું પ્રસારિત કરીએ છીએ - ખાસ કરીને વિડિયો માટે અલગ સ્ટોરેજ માટે એક અલગ ડાયરેક્ટ કનેક્શન. અમે પ્રોક્સી દ્વારા હળવી સામગ્રી પ્રસારિત કરીએ છીએ.

થોડા સમય પહેલા અમને પ્રોક્સીનું સુધારેલું સંસ્કરણ મળ્યું. હવે હું તમને કહીશ કે તેઓ સામાન્ય લોકોથી કેવી રીતે અલગ છે અને આ શા માટે જરૂરી છે.

સન

સપ્ટેમ્બર 2017 માં, ઓરેકલ, જેણે અગાઉ સન ખરીદ્યું હતું, મોટી સંખ્યામાં સન કર્મચારીઓને કાઢી મૂક્યા. અમે કહી શકીએ કે આ ક્ષણે કંપનીનું અસ્તિત્વ બંધ થઈ ગયું છે. નવી સિસ્ટમ માટે નામ પસંદ કરતી વખતે, અમારા સંચાલકોએ આ કંપનીની સ્મૃતિને શ્રદ્ધાંજલિ આપવાનું નક્કી કર્યું અને નવી સિસ્ટમનું નામ સન રાખ્યું. આપણી વચ્ચે આપણે તેને ફક્ત "સૂર્ય" કહીએ છીએ.

pp ને થોડી સમસ્યાઓ હતી. જૂથ દીઠ એક IP - બિનઅસરકારક કેશ. કેટલાક ભૌતિક સર્વર એક સામાન્ય IP સરનામું શેર કરે છે, અને વિનંતી કયા સર્વર પર જશે તે નિયંત્રિત કરવાની કોઈ રીત નથી. તેથી, જો એક જ ફાઇલ માટે જુદા જુદા વપરાશકર્તાઓ આવે છે, તો જો આ સર્વર્સ પર કેશ હોય, તો ફાઇલ દરેક સર્વરની કેશમાં સમાપ્ત થાય છે. આ ખૂબ જ બિનકાર્યક્ષમ યોજના છે, પરંતુ કંઇ કરી શકાયું નથી.

પરિણામે - અમે કન્ટેન્ટને અલગ કરી શકતા નથી, કારણ કે અમે આ જૂથ માટે ચોક્કસ સર્વર પસંદ કરી શકતા નથી - તેમની પાસે સામાન્ય IP છે. કેટલાક આંતરિક કારણોસર પણ અમારી પાસે છે પ્રદેશોમાં આવા સર્વરોને ઇન્સ્ટોલ કરવું શક્ય ન હતું. તેઓ ફક્ત સેન્ટ પીટર્સબર્ગમાં જ ઊભા હતા.

સૂર્ય સાથે, અમે પસંદગી પદ્ધતિ બદલી. હવે અમારી પાસે છે કોઈપણ કાસ્ટ રૂટીંગ: ડાયનેમિક રૂટીંગ, કોઈપણ કાસ્ટ, સ્વ-ચેક ડિમન. દરેક સર્વરનો પોતાનો વ્યક્તિગત IP હોય છે, પરંતુ સામાન્ય સબનેટ હોય છે. બધું એવી રીતે ગોઠવવામાં આવ્યું છે કે જો એક સર્વર નિષ્ફળ જાય, તો ટ્રાફિક તે જ જૂથના અન્ય સર્વર પર આપમેળે ફેલાય છે. હવે ચોક્કસ સર્વર પસંદ કરવાનું શક્ય છે, કોઈ રીડન્ડન્ટ કેશીંગ નથી, અને વિશ્વસનીયતાને અસર થઈ નથી.

વજન આધાર. હવે આપણે જરૂરિયાત મુજબ વિવિધ શક્તિના મશીનો ઇન્સ્ટોલ કરવાનું પરવડી શકીએ છીએ, અને અસ્થાયી સમસ્યાઓના કિસ્સામાં, તેમના પરનો ભાર ઘટાડવા માટે કાર્યકારી "સૂર્ય" ના વજનમાં ફેરફાર કરો, જેથી તેઓ "આરામ" કરે અને ફરીથી કામ કરવાનું શરૂ કરે.

સામગ્રી આઈડી દ્વારા શેરિંગ. શાર્ડિંગ વિશે એક રમુજી વસ્તુ: અમે સામાન્ય રીતે સામગ્રીને છીણી કરીએ છીએ જેથી વિવિધ વપરાશકર્તાઓ સમાન "સૂર્ય" દ્વારા એક જ ફાઇલ પર જાય જેથી તેમની પાસે સામાન્ય કેશ હોય.

અમે તાજેતરમાં "ક્લોવર" એપ્લિકેશન લોન્ચ કરી છે. લાઈવ બ્રોડકાસ્ટમાં આ એક ઓનલાઈન ક્વિઝ છે, જ્યાં હોસ્ટ પ્રશ્નો પૂછે છે અને વપરાશકર્તાઓ વિકલ્પો પસંદ કરીને વાસ્તવિક સમયમાં જવાબ આપે છે. એપ્લિકેશનમાં એક ચેટ છે જ્યાં વપરાશકર્તાઓ ચેટ કરી શકે છે. એકસાથે બ્રોડકાસ્ટ સાથે કનેક્ટ થઈ શકે છે 100 હજારથી વધુ લોકો. તેઓ બધા સંદેશાઓ લખે છે જે બધા સહભાગીઓને મોકલવામાં આવે છે, અને સંદેશની સાથે અવતાર આવે છે. જો 100 હજાર લોકો એક "સૂર્ય" માં એક અવતાર માટે આવે છે, તો તે ક્યારેક વાદળની પાછળ ફરે છે.

સમાન ફાઇલ માટેની વિનંતીઓના વિસ્ફોટનો સામનો કરવા માટે, તે ચોક્કસ પ્રકારની સામગ્રી માટે છે જે અમે એક મૂર્ખ યોજના ચાલુ કરીએ છીએ જે ફાઇલોને આ પ્રદેશમાં ઉપલબ્ધ તમામ "સૂર્ય" પર ફેલાવે છે.

અંદરથી સૂર્ય

nginx પર રિવર્સ પ્રોક્સી, RAM માં કે ફાસ્ટ Optane/NVMe ડિસ્ક પર કેશ. ઉદાહરણ: http://sun4-2.userapi.com/c100500/path — “સૂર્ય” ની લિંક, જે ચોથા ક્ષેત્રમાં સ્થિત છે, બીજા સર્વર જૂથ. તે પાથ ફાઇલને બંધ કરે છે, જે ભૌતિક રીતે સર્વર 100500 પર રહે છે.

કવર

અમે અમારી આર્કિટેક્ચરલ સ્કીમમાં વધુ એક નોડ ઉમેરીએ છીએ - કેશિંગ એન્વાયર્નમેન્ટ.

નીચે લેઆઉટ ડાયાગ્રામ છે પ્રાદેશિક કેશ, તેમાંના લગભગ 20 છે. આ તે સ્થાનો છે જ્યાં કેશ અને "સન" સ્થિત છે, જે પોતાના દ્વારા ટ્રાફિકને કેશ કરી શકે છે.

આ મલ્ટીમીડિયા સામગ્રીનું કેશીંગ છે; અહીં કોઈ વપરાશકર્તા ડેટા સંગ્રહિત નથી - ફક્ત સંગીત, વિડિઓ, ફોટા.

વપરાશકર્તાના પ્રદેશને નિર્ધારિત કરવા માટે, અમે અમે પ્રદેશોમાં જાહેર કરાયેલ BGP નેટવર્ક ઉપસર્ગ એકત્રિત કરીએ છીએ. ફોલબેકના કિસ્સામાં, જો આપણે ઉપસર્ગ દ્વારા IP શોધી શક્યા નથી, તો અમારે geoip ડેટાબેઝને પણ પાર્સ કરવું પડશે. અમે વપરાશકર્તાના IP દ્વારા પ્રદેશ નક્કી કરીએ છીએ. કોડમાં, અમે વપરાશકર્તાના એક અથવા વધુ પ્રદેશોને જોઈ શકીએ છીએ - તે બિંદુઓ કે જ્યાં તે ભૌગોલિક રીતે સૌથી નજીક છે.

તે કેવી રીતે કામ કરે છે?

અમે પ્રદેશ દ્વારા ફાઇલોની લોકપ્રિયતા ગણીએ છીએ. ત્યાં સંખ્યાબંધ પ્રાદેશિક કેશ છે જ્યાં વપરાશકર્તા સ્થિત છે, અને એક ફાઇલ ઓળખકર્તા - અમે આ જોડી લઈએ છીએ અને દરેક ડાઉનલોડ સાથે રેટિંગમાં વધારો કરીએ છીએ.

તે જ સમયે, રાક્ષસો - પ્રદેશોમાં સેવાઓ - સમય સમય પર API પર આવે છે અને કહે છે: “હું આવો અને એવો કેશ છું, મને મારા પ્રદેશની સૌથી લોકપ્રિય ફાઇલોની સૂચિ આપો જે હજી સુધી મારા પર નથી. " API રેટિંગ દ્વારા સૉર્ટ કરેલી ફાઇલોનો સમૂહ પહોંચાડે છે, ડિમન તેમને ડાઉનલોડ કરે છે, તેમને પ્રદેશોમાં લઈ જાય છે અને ત્યાંથી ફાઇલો પહોંચાડે છે. કેશમાંથી pu/pp અને સન વચ્ચેનો આ મૂળભૂત તફાવત છે: તેઓ તરત જ પોતાના દ્વારા ફાઇલ આપે છે, ભલે આ ફાઇલ કેશમાં ન હોય, અને કેશ પહેલા ફાઇલને પોતાની પાસે ડાઉનલોડ કરે છે, અને પછી તેને પાછું આપવાનું શરૂ કરે છે.

આ કિસ્સામાં આપણે મેળવીએ છીએ સામગ્રી વપરાશકર્તાઓની નજીક છે અને નેટવર્ક લોડ ફેલાવો. ઉદાહરણ તરીકે, માત્ર મોસ્કો કેશમાંથી અમે પીક અવર્સ દરમિયાન 1 Tbit/s કરતાં વધુ વિતરિત કરીએ છીએ.

પરંતુ ત્યાં સમસ્યાઓ છે - કેશ સર્વર્સ રબર નથી. સુપર લોકપ્રિય સામગ્રી માટે, કેટલીકવાર અલગ સર્વર માટે પૂરતું નેટવર્ક હોતું નથી. અમારા કેશ સર્વર્સ 40-50 Gbit/s છે, પરંતુ એવી સામગ્રી છે જે આવી ચેનલને સંપૂર્ણપણે બંધ કરે છે. અમે પ્રદેશમાં લોકપ્રિય ફાઇલોની એક કરતાં વધુ નકલોના સંગ્રહને અમલમાં મૂકવા તરફ આગળ વધી રહ્યા છીએ. હું આશા રાખું છું કે વર્ષના અંત સુધીમાં અમે તેનો અમલ કરીશું.

અમે સામાન્ય સ્થાપત્ય તરફ જોયું.

• ફ્રન્ટ સર્વર્સ જે વિનંતીઓ સ્વીકારે છે.
• બેકએન્ડ કે પ્રક્રિયા વિનંતીઓ.
• સ્ટોરેજ કે જે બે પ્રકારના પ્રોક્સીઓ દ્વારા બંધ છે.
• પ્રાદેશિક કેશ.

આ રેખાકૃતિમાંથી શું ખૂટે છે? અલબત્ત, ડેટાબેઝ કે જેમાં આપણે ડેટા સ્ટોર કરીએ છીએ.

ડેટાબેઝ અથવા એન્જિન

અમે તેમને ડેટાબેઝ નહીં, પરંતુ એન્જિન - એન્જિન કહીએ છીએ, કારણ કે અમારી પાસે સામાન્ય રીતે સ્વીકૃત અર્થમાં વ્યવહારીક રીતે ડેટાબેસેસ નથી.

આ એક જરૂરી માપ છે. આવું એટલા માટે થયું કારણ કે 2008-2009માં, જ્યારે VKની લોકપ્રિયતામાં વિસ્ફોટક વૃદ્ધિ થઈ હતી, ત્યારે પ્રોજેક્ટ સંપૂર્ણપણે MySQL અને Memcache પર કામ કરતો હતો અને તેમાં સમસ્યાઓ હતી. MySQL ફાઈલોને ક્રેશ અને બગડવાનું પસંદ કરે છે, જેના પછી તે પુનઃપ્રાપ્ત થશે નહીં, અને Memcache ધીમે ધીમે કાર્યક્ષમતામાં ઘટાડો થયો અને તેને પુનઃપ્રારંભ કરવો પડ્યો.

તે તારણ આપે છે કે વધુને વધુ લોકપ્રિય પ્રોજેક્ટમાં સતત સ્ટોરેજ હતો, જે ડેટાને દૂષિત કરે છે, અને કેશ, જે ધીમો પડી જાય છે. આવી પરિસ્થિતિઓમાં, વિકાસશીલ પ્રોજેક્ટ વિકસાવવો મુશ્કેલ છે. નિર્ણાયક બાબતોને ફરીથી લખવાનો પ્રયાસ કરવાનો નિર્ણય લેવામાં આવ્યો કે જે પ્રોજેક્ટ અમારી પોતાની સાયકલ પર કેન્દ્રિત હતો.

ઉકેલ સફળ થયો. આ કરવાની તક હતી, સાથે સાથે આત્યંતિક આવશ્યકતા પણ હતી, કારણ કે તે સમયે સ્કેલિંગની અન્ય રીતો અસ્તિત્વમાં ન હતી. ત્યાં ડેટાબેઝનો સમૂહ ન હતો, NoSQL હજી અસ્તિત્વમાં નહોતું, ત્યાં ફક્ત MySQL, Memcache, PostrgreSQL હતા - અને બસ.

સાર્વત્રિક કામગીરી. વિકાસની આગેવાની અમારી C વિકાસકર્તાઓની ટીમ દ્વારા કરવામાં આવી હતી અને બધું જ સુસંગત રીતે કરવામાં આવ્યું હતું. એન્જિનને ધ્યાનમાં લીધા વિના, તે બધા પાસે લગભગ એક જ ફાઇલ ફોર્મેટ ડિસ્ક પર લખાયેલું હતું, સમાન લોંચ પેરામીટર્સ, એ જ રીતે સિગ્નલોની પ્રક્રિયા કરવામાં આવી હતી અને ધારની પરિસ્થિતિઓ અને સમસ્યાઓના કિસ્સામાં લગભગ સમાન વર્તન કર્યું હતું. એન્જિનના વિકાસ સાથે, પ્રબંધકો માટે સિસ્ટમનું સંચાલન કરવું અનુકૂળ છે - ત્યાં કોઈ પ્રાણી સંગ્રહાલય નથી જેની જાળવણી કરવાની જરૂર છે, અને તેઓએ દરેક નવા તૃતીય-પક્ષ ડેટાબેઝને કેવી રીતે સંચાલિત કરવું તે ફરીથી શીખવું પડશે, જેણે તેને ઝડપથી અને સગવડતાપૂર્વક વધારવાનું શક્ય બનાવ્યું. તેમની સંખ્યા.

એન્જિનના પ્રકાર

ટીમે ઘણા બધા એન્જિન લખ્યા. અહીં ફક્ત તેમાંથી કેટલાક છે: મિત્ર, સંકેતો, છબી, ipdb, અક્ષરો, સૂચિઓ, લૉગ્સ, memcached, meowdb, સમાચાર, nostradamus, ફોટો, પ્લેલિસ્ટ, pmemcached, સેન્ડબોક્સ, શોધ, સંગ્રહ, પસંદ, કાર્યો, …

દરેક કાર્ય માટે કે જેને ચોક્કસ ડેટા સ્ટ્રક્ચરની જરૂર હોય અથવા બિનજરૂરી વિનંતીઓ પર પ્રક્રિયા કરવામાં આવે, C ટીમ નવું એન્જિન લખે છે. કેમ નહિ.

અમારી પાસે અલગ એન્જિન છે memcached, જે નિયમિત સમાન છે, પરંતુ ગુડીઝના સમૂહ સાથે, અને જે ધીમું થતું નથી. ક્લિકહાઉસ નથી, પરંતુ તે પણ કામ કરે છે. અલગથી ઉપલબ્ધ છે pmemcached છે સતત memcached, જે ડિસ્ક પર ડેટા સ્ટોર પણ કરી શકે છે, વધુમાં, RAM માં બંધબેસે છે, જેથી પુનઃપ્રારંભ કરતી વખતે ડેટા ગુમાવવો નહીં. વ્યક્તિગત કાર્યો માટે વિવિધ એન્જિનો છે: કતાર, સૂચિ, સેટ - અમારા પ્રોજેક્ટ માટે જરૂરી છે તે બધું.

ક્લસ્ટરો

કોડના પરિપ્રેક્ષ્યમાં, એન્જિન અથવા ડેટાબેસેસને પ્રક્રિયાઓ, સંસ્થાઓ અથવા દાખલાઓ તરીકે વિચારવાની જરૂર નથી. કોડ ખાસ કરીને ક્લસ્ટરો સાથે, એન્જિનના જૂથો સાથે કામ કરે છે - ક્લસ્ટર દીઠ એક પ્રકાર. ચાલો કહીએ કે ત્યાં એક મેમકેશ્ડ ક્લસ્ટર છે - તે ફક્ત મશીનોનું જૂથ છે.

કોડને ભૌતિક સ્થાન, કદ અથવા સર્વરની સંખ્યાને બિલકુલ જાણવાની જરૂર નથી. તે ચોક્કસ ઓળખકર્તાનો ઉપયોગ કરીને ક્લસ્ટરમાં જાય છે.

આ કામ કરવા માટે, તમારે એક વધુ એન્ટિટી ઉમેરવાની જરૂર છે જે કોડ અને એન્જિન વચ્ચે સ્થિત છે - પ્રોક્સી.

RPC પ્રોક્સી

પ્રોક્સી કનેક્ટિંગ બસ, જેના પર લગભગ આખી સાઇટ ચાલે છે. તે જ સમયે અમારી પાસે છે કોઈ સેવા શોધ નથી — તેના બદલે, આ પ્રોક્સી માટે એક રૂપરેખા છે, જે તમામ ક્લસ્ટરો અને આ ક્લસ્ટરના તમામ શાર્ડ્સનું સ્થાન જાણે છે. આ એડમિન્સ કરે છે.

પ્રોગ્રામરો તેની કિંમત કેટલી, ક્યાં અને શું છે તેની બિલકુલ કાળજી લેતા નથી - તેઓ ફક્ત ક્લસ્ટરમાં જાય છે. આ અમને ઘણું પરવાનગી આપે છે. વિનંતી પ્રાપ્ત કરતી વખતે, પ્રોક્સી વિનંતીને રીડાયરેક્ટ કરે છે, તે જાણીને કે ક્યાં છે - તે આ પોતે જ નક્કી કરે છે.

આ કિસ્સામાં, પ્રોક્સી એ સેવાની નિષ્ફળતા સામે રક્ષણનું એક બિંદુ છે. જો અમુક એન્જીન ધીમી પડે છે અથવા ક્રેશ થાય છે, તો પ્રોક્સી આને સમજે છે અને ક્લાયન્ટની બાજુએ તે મુજબ પ્રતિભાવ આપે છે. આ તમને સમયસમાપ્તિને દૂર કરવાની મંજૂરી આપે છે - કોડ એન્જિનના પ્રતિસાદની રાહ જોતો નથી, પરંતુ સમજે છે કે તે કામ કરી રહ્યું નથી અને તેને કોઈક રીતે અલગ રીતે વર્તવાની જરૂર છે. કોડ એ હકીકત માટે તૈયાર હોવો જોઈએ કે ડેટાબેસેસ હંમેશા કામ કરતા નથી.

ચોક્કસ અમલીકરણો

કેટલીકવાર આપણે ખરેખર એન્જિન તરીકે કોઈ પ્રકારનું બિન-માનક સોલ્યુશન મેળવવા માંગીએ છીએ. તે જ સમયે, અમારા એન્જિન માટે ખાસ બનાવેલ અમારી તૈયાર આરપીસી-પ્રોક્સીનો ઉપયોગ ન કરવાનો નિર્ણય લેવામાં આવ્યો, પરંતુ કાર્ય માટે એક અલગ પ્રોક્સી બનાવવાનું.

MySQL માટે, જે અમારી પાસે હજી પણ અહીં અને ત્યાં છે, અમે db-proxy નો ઉપયોગ કરીએ છીએ, અને ClickHouse માટે - બિલાડીનું ઘર.

તે સામાન્ય રીતે આ રીતે કામ કરે છે. ત્યાં એક ચોક્કસ સર્વર છે, તે kPHP, Go, Python ચલાવે છે - સામાન્ય રીતે, કોઈપણ કોડ કે જે અમારા RPC પ્રોટોકોલનો ઉપયોગ કરી શકે છે. કોડ સ્થાનિક રીતે RPC પ્રોક્સી પર ચાલે છે - દરેક સર્વર જ્યાં કોડ સ્થિત છે તેની પોતાની સ્થાનિક પ્રોક્સી ચલાવે છે. વિનંતી પર, પ્રોક્સી સમજે છે કે ક્યાં જવું છે.

જો એક એન્જિન બીજામાં જવા માંગે છે, ભલે તે પાડોશી હોય, તે પ્રોક્સી દ્વારા જાય છે, કારણ કે પાડોશી બીજા ડેટા સેન્ટરમાં હોઈ શકે છે. એન્જિને પોતાના સિવાય અન્ય કોઈ પણ વસ્તુનું સ્થાન જાણવા પર આધાર રાખવો જોઈએ નહીં - આ અમારું પ્રમાણભૂત ઉકેલ છે. પરંતુ અલબત્ત ત્યાં અપવાદો છે :)

TL-સ્કીમનું ઉદાહરણ જે મુજબ તમામ એન્જિન કામ કરે છે.

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;

આ એક બાઈનરી પ્રોટોકોલ છે, જેનું સૌથી નજીકનું એનાલોગ છે પ્રોટોબફ સ્કીમા વૈકલ્પિક ક્ષેત્રો, જટિલ પ્રકારો - બિલ્ટ-ઇન સ્કેલર્સના એક્સ્ટેન્શન્સ અને ક્વેરીઝનું પૂર્વવર્ણન કરે છે. આ પ્રોટોકોલ અનુસાર બધું કામ કરે છે.

TCP/UDP પર TL પર RPC... UDP?

અમારી પાસે એન્જિન વિનંતીઓ ચલાવવા માટે એક RPC પ્રોટોકોલ છે જે TL સ્કીમની ટોચ પર ચાલે છે. આ બધું TCP/UDP કનેક્શન પર કામ કરે છે. TCP સમજી શકાય તેવું છે, પરંતુ શા માટે આપણને વારંવાર UDP ની જરૂર પડે છે?

UDP મદદ કરે છે સર્વર્સ વચ્ચે મોટી સંખ્યામાં જોડાણોની સમસ્યાને ટાળો. જો દરેક સર્વર પાસે RPC પ્રોક્સી હોય અને, સામાન્ય રીતે, તે કોઈપણ એન્જિન પર જઈ શકે, તો સર્વર દીઠ હજારો TCP કનેક્શન્સ હોય છે. ત્યાં એક ભાર છે, પરંતુ તે નકામું છે. UDP ના કિસ્સામાં આ સમસ્યા અસ્તિત્વમાં નથી.

કોઈ રીડન્ડન્ટ TCP હેન્ડશેક નથી. આ એક સામાન્ય સમસ્યા છે: જ્યારે નવું એન્જિન અથવા નવું સર્વર લોંચ કરવામાં આવે છે, ત્યારે ઘણા TCP કનેક્શન એકસાથે સ્થાપિત થાય છે. નાની લાઇટવેઇટ વિનંતીઓ માટે, ઉદાહરણ તરીકે, UDP પેલોડ, કોડ અને એન્જિન વચ્ચેનો તમામ સંચાર છે બે UDP પેકેટો: એક એક દિશામાં ઉડે છે, બીજો બીજી દિશામાં. એક રાઉન્ડ ટ્રીપ - અને કોડને હેન્ડશેક વિના એન્જિન તરફથી પ્રતિસાદ મળ્યો.

હા, તે બધું જ કામ કરે છે પેકેટ નુકશાનની ખૂબ ઓછી ટકાવારી સાથે. પ્રોટોકોલ રીટ્રાન્સમિટ અને સમયસમાપ્તિ માટે સપોર્ટ ધરાવે છે, પરંતુ જો આપણે ઘણું ગુમાવીએ છીએ, તો અમને લગભગ TCP મળશે, જે નફાકારક નથી. અમે UDPને મહાસાગરોમાં ચલાવતા નથી.

અમારી પાસે આવા હજારો સર્વર્સ છે, અને સ્કીમ સમાન છે: દરેક ભૌતિક સર્વર પર એન્જિનનો પેક ઇન્સ્ટોલ કરેલો છે. બ્લોક કર્યા વિના શક્ય તેટલી ઝડપથી ચલાવવા માટે તે મોટે ભાગે સિંગલ-થ્રેડેડ હોય છે, અને સિંગલ-થ્રેડેડ સોલ્યુશન તરીકે શાર્ડ કરવામાં આવે છે. તે જ સમયે, અમારી પાસે આ એન્જિનો કરતાં વધુ વિશ્વસનીય કંઈ નથી, અને સતત ડેટા સ્ટોરેજ પર ઘણું ધ્યાન આપવામાં આવે છે.

સતત ડેટા સ્ટોરેજ

એન્જિનો બિનલોગ લખે છે. બિનલોગ એ એક ફાઇલ છે જેના અંતે રાજ્ય અથવા ડેટામાં ફેરફાર માટેની ઇવેન્ટ ઉમેરવામાં આવે છે. વિવિધ ઉકેલોમાં તેને અલગ રીતે કહેવામાં આવે છે: બાઈનરી લોગ, દિવાલ, AOF, પરંતુ સિદ્ધાંત સમાન છે.

પુનઃપ્રારંભ કરતી વખતે એન્જિનને ઘણા વર્ષો સુધી સમગ્ર બિનલોગને ફરીથી વાંચતા અટકાવવા માટે, એન્જિન લખે છે સ્નેપશોટ - વર્તમાન સ્થિતિ. જો જરૂરી હોય તો, તેઓ પહેલા તેમાંથી વાંચે છે, અને પછી બિનલોગમાંથી વાંચન સમાપ્ત કરે છે. બધા બિનલોગ્સ સમાન દ્વિસંગી ફોર્મેટમાં લખવામાં આવે છે - TL સ્કીમ અનુસાર, જેથી સંચાલકો તેમના ટૂલ્સ વડે તેમને સમાન રીતે સંચાલિત કરી શકે. સ્નેપશોટ માટે આવી કોઈ જરૂર નથી. ત્યાં એક સામાન્ય હેડર છે જે સૂચવે છે કે કોનો સ્નેપશોટ પૂર્ણાંક છે, એન્જિનનો જાદુ છે અને કયું શરીર કોઈ માટે મહત્વપૂર્ણ નથી. સ્નેપશોટ રેકોર્ડ કરનાર એન્જિનમાં આ સમસ્યા છે.

હું ઝડપથી ઓપરેશનના સિદ્ધાંતનું વર્ણન કરીશ. એક સર્વર છે જેના પર એન્જિન ચાલે છે. તે લખવા માટે એક નવો ખાલી બિનલોગ ખોલે છે અને તેમાં ફેરફાર કરવા માટે એક ઇવેન્ટ લખે છે.

અમુક સમયે, તે કાં તો પોતે સ્નેપશોટ લેવાનું નક્કી કરે છે, અથવા તેને સિગ્નલ મળે છે. સર્વર નવી ફાઈલ બનાવે છે, તેની સંપૂર્ણ સ્થિતિ તેમાં લખે છે, વર્તમાન બિનલોગ કદ - ઓફસેટ - ફાઈલના અંતમાં જોડે છે અને આગળ લખવાનું ચાલુ રાખે છે. નવો બિનલોગ બનાવવામાં આવ્યો નથી.

અમુક સમયે, જ્યારે એન્જિન પુનઃપ્રારંભ થશે, ત્યારે ડિસ્ક પર બિનલોગ અને સ્નેપશોટ બંને હશે. એન્જિન સમગ્ર સ્નેપશોટ વાંચે છે અને ચોક્કસ બિંદુએ તેની સ્થિતિને વધારે છે.

સ્નેપશોટ બનાવતી વખતે જે સ્થિતિ હતી અને બિનલોગનું કદ વાંચે છે.

વર્તમાન સ્થિતિ જાણવા માટે બિનલોગનો અંત વાંચે છે અને આગળની ઘટનાઓ લખવાનું ચાલુ રાખે છે. આ એક સરળ યોજના છે; અમારા બધા એન્જિન તેના અનુસાર કાર્ય કરે છે.

ડેટા પ્રતિકૃતિ

પરિણામે, અમારામાં ડેટા પ્રતિકૃતિ નિવેદન આધારિત - અમે બિનલોગમાં પૃષ્ઠમાં કોઈ ફેરફાર નહીં, પણ નામ લખીએ છીએ વિનંતીઓ બદલો. નેટવર્ક પર જે આવે છે તેના જેવું જ છે, માત્ર થોડું સુધારેલ છે.

સમાન યોજનાનો ઉપયોગ માત્ર નકલ માટે જ નહીં, પણ થાય છે બેકઅપ બનાવવા માટે. અમારી પાસે એક એન્જિન છે - એક લેખન માસ્ટર જે બિનલોગ પર લખે છે. અન્ય કોઈપણ જગ્યાએ જ્યાં એડમિન્સ તેને સેટ કરે છે, આ બિનલોગ કૉપિ કરવામાં આવે છે, અને બસ - અમારી પાસે બેકઅપ છે.

જો જરૂરી હોય તો વાંચન પ્રતિકૃતિCPU રીડિંગ લોડને ઘટાડવા માટે, રીડિંગ એન્જીન ખાલી લોન્ચ કરવામાં આવે છે, જે બિનલોગનો અંત વાંચે છે અને આ આદેશોને સ્થાનિક રીતે એક્ઝિક્યુટ કરે છે.

અહીંનો લેગ ખૂબ નાનો છે, અને પ્રતિકૃતિ માસ્ટરની પાછળ કેટલી છે તે શોધવાનું શક્ય છે.

RPC પ્રોક્સીમાં ડેટા શેરિંગ

શાર્ડિંગ કેવી રીતે કામ કરે છે? પ્રોક્સી કેવી રીતે સમજે છે કે કયા ક્લસ્ટર શાર્ડને મોકલવું? કોડ કહેતો નથી: "15 શાર્ડ્સ માટે મોકલો!" - ના, આ પ્રોક્સી દ્વારા કરવામાં આવે છે.

સૌથી સરળ યોજના ફર્સ્ટન્ટ છે - વિનંતીમાં પ્રથમ નંબર.

get(photo100_500) => 100 % N.

આ એક સરળ મેમકેશ્ડ ટેક્સ્ટ પ્રોટોકોલ માટેનું ઉદાહરણ છે, પરંતુ, અલબત્ત, ક્વેરી જટિલ અને સંરચિત હોઈ શકે છે. ઉદાહરણ ક્વેરીમાં પ્રથમ નંબર લે છે અને જ્યારે ક્લસ્ટરના કદ દ્વારા વિભાજિત કરવામાં આવે ત્યારે બાકીનો નંબર લે છે.

જ્યારે આપણે એક જ એન્ટિટીનો ડેટા લોકેલિટી ધરાવવા માંગતા હોઈએ ત્યારે આ ઉપયોગી છે. ચાલો કહીએ કે 100 એ વપરાશકર્તા અથવા જૂથ ID છે, અને અમે ઇચ્છીએ છીએ કે એક એન્ટિટીનો તમામ ડેટા જટિલ પ્રશ્નો માટે એક શાર્ડ પર હોય.

જો અમે ક્લસ્ટરમાં વિનંતીઓ કેવી રીતે ફેલાય છે તેની કાળજી લેતા નથી, તો બીજો વિકલ્પ છે - સમગ્ર શાર્ડને હેશ કરવું.

hash(photo100_500) => 3539886280 % N

અમને હેશ, ડિવિઝનનો બાકીનો ભાગ અને શાર્ડ નંબર પણ મળે છે.

આ બંને વિકલ્પો ફક્ત ત્યારે જ કામ કરે છે જો આપણે એ હકીકત માટે તૈયાર હોઈએ કે જ્યારે આપણે ક્લસ્ટરનું કદ વધારીશું, ત્યારે આપણે તેને વિભાજિત કરીશું અથવા તેને ઘણી વખત વધારીશું. ઉદાહરણ તરીકે, અમારી પાસે 16 શાર્ડ્સ હતા, અમારી પાસે પૂરતું નથી, અમને વધુ જોઈએ છે - અમે ડાઉનટાઇમ વિના સુરક્ષિત રીતે 32 મેળવી શકીએ છીએ. જો આપણે ગુણાંકમાં વધારો કરવા માંગીએ છીએ, તો ડાઉનટાઇમ હશે, કારણ કે અમે નુકસાન વિના દરેક વસ્તુને ચોક્કસ રીતે વિભાજિત કરી શકીશું નહીં. આ વિકલ્પો ઉપયોગી છે, પરંતુ હંમેશા નહીં.

જો આપણે સર્વરોની મનસ્વી સંખ્યા ઉમેરવા અથવા દૂર કરવાની જરૂર હોય, તો અમે ઉપયોગ કરીએ છીએ રિંગ એ લા કેટામા પર સતત હેશિંગ. પરંતુ તે જ સમયે, અમે ડેટાની સ્થાનિકતાને સંપૂર્ણપણે ગુમાવીએ છીએ; અમારે વિનંતીને ક્લસ્ટરમાં મર્જ કરવી પડશે જેથી કરીને દરેક ભાગ તેનો પોતાનો નાનો પ્રતિસાદ આપે, અને પછી પ્રતિસાદોને પ્રોક્સીમાં મર્જ કરીએ.

અતિ-વિશિષ્ટ વિનંતીઓ છે. તે આના જેવું દેખાય છે: RPC પ્રોક્સી વિનંતી પ્રાપ્ત કરે છે, તે નક્કી કરે છે કે કયા ક્લસ્ટરમાં જવું છે અને શાર્ડ નક્કી કરે છે. પછી કાં તો લેખન માસ્ટર્સ હોય છે, અથવા, જો ક્લસ્ટરમાં પ્રતિકૃતિ આધાર હોય, તો તે માંગ પર પ્રતિકૃતિને મોકલે છે. પ્રોક્સી આ બધું કરે છે.

લોગ્સ

અમે ઘણી રીતે લોગ લખીએ છીએ. સૌથી સ્પષ્ટ અને સરળ છે memcache પર લોગ લખો.

ring-buffer: prefix.idx = line

ત્યાં એક કી ઉપસર્ગ છે - લોગનું નામ, એક લીટી, અને ત્યાં આ લોગનું કદ છે - લીટીઓની સંખ્યા. અમે 0 થી લીટીઓની સંખ્યા બાદ 1 સુધી રેન્ડમ નંબર લઈએ છીએ. મેમકેશમાં કી આ રેન્ડમ નંબર સાથે જોડાયેલ ઉપસર્ગ છે. અમે લોગ લાઇન અને વર્તમાન સમયને મૂલ્યમાં સાચવીએ છીએ.

જ્યારે લૉગ્સ વાંચવા માટે જરૂરી હોય, ત્યારે અમે હાથ ધરીએ છીએ મલ્ટી ગેટ બધી કીઓ, સમય દ્વારા સૉર્ટ કરવામાં આવે છે, અને આમ રીઅલ ટાઇમમાં ઉત્પાદન લોગ મેળવો. આ સ્કીમનો ઉપયોગ ત્યારે થાય છે જ્યારે તમારે ઉત્પાદનમાં રીઅલ ટાઇમમાં કોઈ વસ્તુને ડિબગ કરવાની જરૂર હોય, કંઈપણ તોડ્યા વિના, અન્ય મશીનો પર ટ્રાફિકને અટકાવ્યા અથવા મંજૂરી આપ્યા વિના, પરંતુ આ લોગ લાંબો સમય ચાલતો નથી.

લોગના વિશ્વસનીય સંગ્રહ માટે અમારી પાસે એક એન્જિન છે લોગ-એન્જિન. આ ચોક્કસપણે શા માટે તે બનાવવામાં આવ્યું હતું અને વિશાળ સંખ્યામાં ક્લસ્ટરોમાં તેનો વ્યાપકપણે ઉપયોગ થાય છે. 600 TB પેક્ડ લોગ સ્ટોર્સનું હું જાણું છું તે સૌથી મોટું ક્લસ્ટર.

એન્જિન ખૂબ જૂનું છે, ત્યાં ક્લસ્ટરો છે જે પહેલેથી જ 6-7 વર્ષ જૂના છે. તેની સાથે એવી સમસ્યાઓ છે કે જેને અમે હલ કરવાનો પ્રયાસ કરી રહ્યા છીએ, ઉદાહરણ તરીકે, અમે લોગ સ્ટોર કરવા માટે ક્લિકહાઉસનો સક્રિયપણે ઉપયોગ કરવાનું શરૂ કર્યું.

ક્લિકહાઉસમાં લૉગ્સ એકત્રિત કરી રહ્યાં છે

આ રેખાકૃતિ બતાવે છે કે આપણે આપણા એન્જિનમાં કેવી રીતે જઈએ છીએ.

ત્યાં કોડ છે જે સ્થાનિક રીતે RPC દ્વારા RPC-પ્રોક્સીમાં જાય છે, અને તે સમજે છે કે એન્જિન પર ક્યાં જવું છે. જો આપણે ક્લિકહાઉસમાં લોગ લખવા માંગતા હોય, તો અમારે આ યોજનામાં બે ભાગો બદલવાની જરૂર છે:

• ક્લિકહાઉસ સાથે કેટલાક એન્જિનને બદલો;
• RPC પ્રોક્સીને બદલો, જે ક્લિકહાઉસને ઍક્સેસ કરી શકતું નથી, કેટલાક ઉકેલો સાથે અને RPC દ્વારા.

એન્જિન સરળ છે - અમે તેને સર્વર અથવા ક્લિકહાઉસ સાથે સર્વર્સના ક્લસ્ટરથી બદલીએ છીએ.

અને ક્લિકહાઉસ પર જવા માટે, અમે કર્યું બિલાડીનું બચ્ચું હાઉસ. જો આપણે કિટનહાઉસથી સીધા જ ક્લિકહાઉસ પર જઈએ, તો તે સામનો કરશે નહીં. વિનંતીઓ વિના પણ, તે મોટી સંખ્યામાં મશીનોના HTTP કનેક્શન્સમાંથી ઉમેરે છે. સ્કીમ કામ કરવા માટે, ક્લિકહાઉસવાળા સર્વર પર સ્થાનિક રિવર્સ પ્રોક્સી ઊભી થાય છે, જે એવી રીતે લખાયેલ છે કે તે કનેક્શન્સના જરૂરી વોલ્યુમોનો સામનો કરી શકે છે. તે પ્રમાણમાં વિશ્વસનીય રીતે પોતાની અંદર ડેટા બફર પણ કરી શકે છે.

કેટલીકવાર અમે બિન-માનક ઉકેલોમાં RPC યોજના અમલમાં મૂકવા માંગતા નથી, ઉદાહરણ તરીકે, nginx માં. તેથી, KittenHouse પાસે UDP દ્વારા લોગ પ્રાપ્ત કરવાની ક્ષમતા છે.

જો લોગ મોકલનાર અને પ્રાપ્તકર્તા એક જ મશીન પર કામ કરે છે, તો સ્થાનિક હોસ્ટની અંદર UDP પેકેટ ગુમાવવાની સંભાવના ઘણી ઓછી છે. તૃતીય-પક્ષ સોલ્યુશન અને વિશ્વસનીયતામાં RPC લાગુ કરવાની જરૂરિયાત વચ્ચે સમાધાન તરીકે, અમે ફક્ત UDP મોકલવાનો ઉપયોગ કરીએ છીએ. અમે પછીથી આ યોજના પર પાછા આવીશું.

મોનીટરીંગ

અમારી પાસે બે પ્રકારના લોગ છે: એડમિનિસ્ટ્રેટર્સ દ્વારા તેમના સર્વર પર એકત્રિત કરાયેલ અને કોડમાંથી વિકાસકર્તાઓ દ્વારા લખાયેલા. તેઓ બે પ્રકારના મેટ્રિક્સને અનુરૂપ છે: સિસ્ટમ અને ઉત્પાદન.

સિસ્ટમ મેટ્રિક્સ

તે અમારા બધા સર્વર પર કામ કરે છે નેટડાટા, જે આંકડા એકત્રિત કરે છે અને તેમને મોકલે છે ગ્રેફાઇટ કાર્બન. તેથી, ક્લિકહાઉસનો ઉપયોગ સ્ટોરેજ સિસ્ટમ તરીકે થાય છે, ઉદાહરણ તરીકે વ્હિસ્પર તરીકે નહીં. જો જરૂરી હોય તો, તમે ક્લિકહાઉસમાંથી સીધા જ વાંચી શકો છો અથવા ઉપયોગ કરી શકો છો ગ્રાફના મેટ્રિક્સ, ગ્રાફ અને રિપોર્ટ્સ માટે. વિકાસકર્તાઓ તરીકે, અમારી પાસે નેટડેટા અને ગ્રાફનાની પૂરતી ઍક્સેસ છે.

ઉત્પાદન મેટ્રિક્સ

સગવડ માટે, અમે ઘણી બધી વસ્તુઓ લખી છે. ઉદાહરણ તરીકે, ત્યાં સામાન્ય કાર્યોનો સમૂહ છે જે તમને આંકડાઓમાં ગણતરીઓ, અનન્ય ગણના મૂલ્યો લખવાની મંજૂરી આપે છે, જે ક્યાંક આગળ મોકલવામાં આવે છે.

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

$stats = statlogsStatData($params)

ત્યારબાદ, અમે સૉર્ટિંગ અને ગ્રૂપિંગ ફિલ્ટર્સનો ઉપયોગ કરી શકીએ છીએ અને આંકડાઓમાંથી અમને જે જોઈએ છે તે બધું કરી શકીએ છીએ - ગ્રાફ્સ બનાવો, વૉચડોગ્સ ગોઠવો.

અમે ખૂબ લખીએ છીએ ઘણા મેટ્રિક્સ ઘટનાઓની સંખ્યા 600 બિલિયન થી 1 ટ્રિલિયન પ્રતિ દિવસ છે. જો કે, અમે તેમને રાખવા માંગીએ છીએ ઓછામાં ઓછા બે વર્ષમેટ્રિક્સમાં વલણોને સમજવા માટે. તે બધાને એકસાથે મૂકવું એ એક મોટી સમસ્યા છે જે આપણે હજી સુધી હલ કરી નથી. હું તમને જણાવીશ કે છેલ્લા કેટલાક વર્ષોથી તે કેવી રીતે કામ કરી રહ્યું છે.

અમારી પાસે એવા કાર્યો છે જે આ મેટ્રિક્સ લખે છે સ્થાનિક memcache માટેપ્રવેશોની સંખ્યા ઘટાડવા માટે. ટૂંકા ગાળામાં એકવાર સ્થાનિક રીતે લોન્ચ કરવામાં આવ્યું આંકડા-ડિમન તમામ રેકોર્ડ એકત્રિત કરે છે. આગળ, રાક્ષસ મેટ્રિક્સને સર્વરના બે સ્તરોમાં મર્જ કરે છે લોગ-કલેક્ટર્સ, જે અમારા મશીનોના સમૂહમાંથી આંકડાઓને એકત્ર કરે છે જેથી તેમની પાછળનું સ્તર મરી ન જાય.

જો જરૂરી હોય તો, અમે લોગ-કલેક્ટર્સને સીધા જ લખી શકીએ છીએ.

પરંતુ stas-daemom ને બાયપાસ કરીને કોડથી સીધા કલેક્ટર્સ પર લખવું એ ખરાબ રીતે માપી શકાય તેવું સોલ્યુશન છે કારણ કે તે કલેક્ટર પરનો ભાર વધારે છે. ઉકેલ ત્યારે જ યોગ્ય છે જો કોઈ કારણસર આપણે મશીન પર મેમકેશ સ્ટેટ્સ-ડિમન વધારી શકતા નથી, અથવા તે ક્રેશ થાય છે અને અમે સીધા જ જઈએ છીએ.

આગળ, લોગ-કલેક્ટર્સ આંકડાઓને તેમાં મર્જ કરે છે meowDB - આ અમારો ડેટાબેઝ છે, જે મેટ્રિક્સ પણ સ્ટોર કરી શકે છે.

પછી આપણે કોડમાંથી દ્વિસંગી "નજીક-SQL" પસંદગીઓ કરી શકીએ છીએ.

એક પ્રયોગ

2018 ના ઉનાળામાં, અમારી પાસે એક આંતરિક હેકાથોન હતું, અને આકૃતિના લાલ ભાગને ક્લિકહાઉસમાં મેટ્રિક્સ સંગ્રહિત કરી શકે તેવી કોઈ વસ્તુ સાથે બદલવાનો પ્રયાસ કરવાનો વિચાર આવ્યો. અમારી પાસે ક્લિકહાઉસ પર લોગ્સ છે - શા માટે તેનો પ્રયાસ કરશો નહીં?

અમારી પાસે એક સ્કીમ હતી જેમાં કિટનહાઉસ દ્વારા લોગ લખવામાં આવ્યા હતા.

અમે નક્કી કર્યું ડાયાગ્રામમાં બીજું "*હાઉસ" ઉમેરો, જે અમારો કોડ UDP દ્વારા લખે છે તેમ ફોર્મેટમાં બરાબર મેટ્રિક્સ પ્રાપ્ત કરશે. પછી આ *હાઉસ તેમને દાખલમાં ફેરવે છે, જેમ કે લોગ, જે KittenHouse સમજે છે. તે આ લોગને ક્લિકહાઉસ પર સંપૂર્ણ રીતે પહોંચાડી શકે છે, જે તેને વાંચવામાં સક્ષમ હોવા જોઈએ.

memcache, stats-deemon અને logs-collectors database સાથેની સ્કીમને આ સાથે બદલવામાં આવી છે.

memcache, stats-deemon અને logs-collectors database સાથેની સ્કીમને આ સાથે બદલવામાં આવી છે.

• અહીં કોડમાંથી એક રવાનગી છે, જે સ્ટેટ હાઉસમાં સ્થાનિક રીતે લખાયેલ છે.
• StatsHouse UDP મેટ્રિક્સ લખે છે, જે પહેલાથી જ SQL ઇન્સર્ટમાં રૂપાંતરિત છે, બેચમાં KittenHouse પર.
• KittenHouse તેમને ClickHouse પર મોકલે છે.
• જો આપણે તેમને વાંચવા માગીએ છીએ, તો અમે સ્ટેટ હાઉસને બાયપાસ કરીને વાંચીએ છીએ - નિયમિત SQL નો ઉપયોગ કરીને સીધા ક્લિકહાઉસથી.

તે હજુ પણ છે પ્રયોગ, પરંતુ તે કેવી રીતે બહાર આવ્યું તે અમને ગમે છે. જો આપણે સ્કીમ સાથેની સમસ્યાઓને ઠીક કરીએ, તો કદાચ આપણે તેના પર સંપૂર્ણપણે સ્વિચ કરીશું. અંગત રીતે, હું એવી આશા રાખું છું.

આ યોજના આયર્ન બચાવતું નથી. ઓછા સર્વરોની જરૂર છે, સ્થાનિક આંકડા-ડિમન અને લોગ-કલેક્ટરની જરૂર નથી, પરંતુ ક્લિકહાઉસને વર્તમાન સ્કીમ કરતાં મોટા સર્વરની જરૂર છે. ઓછા સર્વર્સની જરૂર છે, પરંતુ તે વધુ ખર્ચાળ અને વધુ શક્તિશાળી હોવા જોઈએ.

જમાવટ કરો

પ્રથમ, ચાલો PHP જમાવટ જોઈએ. અમે વિકાસ કરી રહ્યા છીએ ગિટ: વાપરવુ GitLab и ટીમસિટી જમાવટ માટે. વિકાસ શાખાઓને માસ્ટર બ્રાન્ચમાં મર્જ કરવામાં આવે છે, ટેસ્ટિંગ માટે માસ્ટરમાંથી તેઓ સ્ટેજીંગમાં અને સ્ટેજીંગમાંથી પ્રોડક્શનમાં મર્જ કરવામાં આવે છે.

જમાવટ પહેલાં, વર્તમાન ઉત્પાદન શાખા અને પાછલી એક લેવામાં આવે છે, અને તેમાં વિવિધ ફાઇલો ધ્યાનમાં લેવામાં આવે છે - ફેરફારો: બનાવેલ, કાઢી નાખેલ, બદલાયેલ. આ ફેરફાર ખાસ કોપીફાસ્ટ એન્જિનના બિનલોગમાં રેકોર્ડ કરવામાં આવે છે, જે ઝડપથી અમારા સમગ્ર સર્વર ફ્લીટમાં ફેરફારોની નકલ કરી શકે છે. અહીં શું વપરાય છે તે સીધી નકલ નથી, પરંતુ ગપસપ નકલ, જ્યારે એક સર્વર તેના નજીકના પડોશીઓને ફેરફારો મોકલે છે, તે તેમના પડોશીઓને, વગેરે. આ તમને સમગ્ર કાફલામાં કોડને દસ અને સેકંડના એકમોમાં અપડેટ કરવાની મંજૂરી આપે છે. જ્યારે ફેરફાર સ્થાનિક પ્રતિકૃતિ સુધી પહોંચે છે, ત્યારે તે તેના પર આ પેચો લાગુ કરે છે સ્થાનિક ફાઇલ સિસ્ટમ. સમાન યોજના અનુસાર રોલબેક પણ હાથ ધરવામાં આવે છે.

અમે kPHP ને પણ ઘણો જમાવીએ છીએ અને તેનો પોતાનો વિકાસ પણ છે ગિટ ઉપરના ચિત્ર મુજબ. આથી HTTP સર્વર બાઈનરી, તો પછી આપણે તફાવત પેદા કરી શકતા નથી - પ્રકાશન બાઈનરીનું વજન સેંકડો MB છે. તેથી, અહીં બીજો વિકલ્પ છે - સંસ્કરણ પર લખાયેલ છે બિનલોગ કોપીફાસ્ટ. દરેક બિલ્ડ સાથે તે વધે છે, અને રોલબેક દરમિયાન તે પણ વધે છે. સંસ્કરણ સર્વરો પર નકલ. સ્થાનિક કોપીફાસ્ટ્સ જુએ છે કે બિનલોગમાં નવું સંસ્કરણ દાખલ થયું છે, અને તે જ ગપસપ પ્રતિકૃતિ દ્વારા તેઓ અમારા મુખ્ય સર્વરને થાક્યા વિના, પરંતુ કાળજીપૂર્વક સમગ્ર નેટવર્ક પર ભાર ફેલાવ્યા વિના, બાઈનરીનું નવીનતમ સંસ્કરણ લે છે. શું અનુસરે છે આકર્ષક ફરીથી લોંચ નવા સંસ્કરણ માટે.

અમારા એન્જિનો માટે, જે અનિવાર્યપણે દ્વિસંગી પણ છે, યોજના ખૂબ સમાન છે:

• git માસ્ટર શાખા;
• માં બાઈનરી .deb;
• સંસ્કરણ binlog કોપીફાસ્ટ પર લખાયેલ છે;
• સર્વરો પર નકલ;
• સર્વર તાજી .dep બહાર ખેંચે છે;
• dpkg -i;
• નવા સંસ્કરણ પર આકર્ષક ફરીથી લોંચ કરો.

તફાવત એ છે કે અમારી દ્વિસંગી આર્કાઇવ્સમાં પેક કરેલી છે .deb, અને જ્યારે તેઓ બહાર પંપીંગ dpkg -i સિસ્ટમ પર મૂકવામાં આવે છે. શા માટે kPHP ને દ્વિસંગી તરીકે તૈનાત કરવામાં આવે છે, અને એન્જિનોને dpkg તરીકે તૈનાત કરવામાં આવે છે? તે તે રીતે થયું. તે કામ કરે છે - તેને સ્પર્શ કરશો નહીં.

ઉપયોગી લિંક્સ:

• એન્ટોન કિરીયુશકિન દ્વારા અહેવાલ "Vkontakte સિસ્ટમ એડમિનિસ્ટ્રેટર. કેવી રીતે?" કોપીફાસ્ટ અને ગપસપ વિશે વિગતો સાથે.
• યુરી Nasretdinov દ્વારા અહેવાલ "વીકે કેવી રીતે હજારો સર્વર્સમાંથી ક્લીકહાઉસમાં ડેટા દાખલ કરે છે".
• મારો અહેવાલ "VKontakte ના ઉદાહરણનો ઉપયોગ કરીને વિકસતા પ્રોજેક્ટનું આર્કિટેક્ચર", પરંતુ વિકાસના દૃષ્ટિકોણથી, હાર્ડવેર નહીં.

એલેક્સી અકુલોવિચ તેમાંથી એક છે જેઓ, પ્રોગ્રામ કમિટીના ભાગ રૂપે, મદદ કરે છે PHP રશિયા તાજેતરના સમયમાં PHP વિકાસકર્તાઓ માટે 17મી મેની સૌથી મોટી ઇવેન્ટ બની જશે. અમારી પાસે શું સરસ પીસી છે તે જુઓ વક્તાઓ (તેમાંથી બે PHP કોર વિકસાવી રહ્યા છે!) - એવું લાગે છે કે જો તમે PHP લખો તો તમે ચૂકી ન શકો.

સોર્સ: www.habr.com