Badoo માં ફોટા સ્ટોર કરવા અને શેર કરવા માટેનું આર્કિટેક્ચર

આર્ટેમ ડેનિસોવ ( bo0rsh201, Badoo)

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

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

હવે ચાલો શરુ કરીએ.

મેં કહ્યું તેમ, આ એક પૂર્વવર્તી હશે, અને તેને ક્યાંકથી શરૂ કરવા માટે, ચાલો સૌથી સામાન્ય ઉદાહરણ લઈએ.

અમારી પાસે એક સામાન્ય કાર્ય છે, અમારે વપરાશકર્તાના ફોટા સ્વીકારવા, સંગ્રહિત કરવા અને મોકલવાની જરૂર છે. આ ફોર્મમાં, કાર્ય સામાન્ય છે, અમે કોઈપણ વસ્તુનો ઉપયોગ કરી શકીએ છીએ:

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

બદુ ઐતિહાસિક રીતે - હવે અને પછી બંને (તે સમયે જ્યારે તે તેની બાલ્યાવસ્થામાં હતો) - આપણા પોતાના ડીસીની અંદર તેના પોતાના સર્વર પર રહે છે. તેથી, આ વિકલ્પ અમારા માટે શ્રેષ્ઠ હતો.

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

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

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

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

થોડો સમય અમારા માટે આમ જ હતું.

આ 2009 ની આસપાસ હતું. તેઓએ કાર પહોંચાડી, પહોંચાડી ...

અને અમુક સમયે અમે નોંધવાનું શરૂ કર્યું કે આ યોજનામાં ચોક્કસ ગેરફાયદા છે. ગેરફાયદા શું છે?

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

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

આ બધું 2009 માટે હતું, પરંતુ, સૈદ્ધાંતિક રીતે, આ જરૂરિયાતો આજે પણ સુસંગત છે. અમારી પાસે એક પૂર્વવર્તી છે, તેથી 2009 માં આ સાથે બધું સંપૂર્ણપણે ખરાબ હતું.

અને છેલ્લો મુદ્દો કિંમત છે.

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

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

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

આ નિર્ણયના સ્પષ્ટ ફાયદા હતા. આ SHD છે. તે ફોટા સંગ્રહિત કરવાનો છે. આ ફક્ત હાર્ડ ડ્રાઈવો સાથે મશીનોને સજ્જ કરવા કરતાં સસ્તું કામ કરે છે.

બીજું વત્તા.

આ એ છે કે ક્ષમતા ઘણી મોટી થઈ ગઈ છે, એટલે કે. અમે ઘણા ઓછા વોલ્યુમમાં વધુ સ્ટોરેજ સમાવી શકીએ છીએ.

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

જેમ કે અમારા ફોટાના કિસ્સામાં છે, કારણ કે ફોટાની વિનંતી અસંગત રીતે કરવામાં આવી છે, અને આ તેમના પ્રદર્શનને ખૂબ અસર કરશે.

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

ઑપ્ટિમાઇઝ કરવા માટે, અમે તે સમયે નક્કી કર્યું, દેખીતી રીતે, લોડ પ્રોફાઇલ જોવાનું - સામાન્ય રીતે, શું થઈ રહ્યું છે, શું ઑપ્ટિમાઇઝ કરવાની જરૂર છે.

અને અહીં બધું આપણા હાથમાં ચાલે છે.

મેં પ્રથમ સ્લાઇડમાં પહેલેથી જ કહ્યું છે: અમારી પાસે પ્રતિ સેકન્ડ 80 હજાર વાંચન વિનંતીઓ છે અને દરરોજ માત્ર 3,5 મિલિયન અપલોડ થાય છે. એટલે કે, આ તીવ્રતાના ત્રણ ઓર્ડરનો તફાવત છે. તે સ્પષ્ટ છે કે વાંચનને ઑપ્ટિમાઇઝ કરવાની જરૂર છે અને તે વ્યવહારીક રીતે સ્પષ્ટ છે કે કેવી રીતે.

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

તે. અમારી પાસે ખૂબ જ નાનો હોટ ડેટાસેટ છે. પરંતુ તે જ સમયે તેના માટે ઘણી વિનંતીઓ છે. અને અહીં એક સંપૂર્ણ સ્પષ્ટ ઉકેલ કેશ ઉમેરવાનો છે.

LRU સાથેનો કેશ અમારી બધી સમસ્યાઓ હલ કરશે. આપણે શું કરી રહ્યા છીએ?

અમે સ્ટોરેજ સાથે અમારા મોટા ક્લસ્ટરની સામે અન્ય પ્રમાણમાં નાનું ઉમેરીએ છીએ, જેને ફોટોકૅચ કહેવામાં આવે છે. આ અનિવાર્યપણે માત્ર એક કેશીંગ પ્રોક્સી છે.

તે અંદરથી કેવી રીતે કામ કરે છે? અહીં અમારા વપરાશકર્તા છે, અહીં સંગ્રહ છે. બધું પહેલા જેવું જ છે. આપણે વચ્ચે શું ઉમેરીશું?

તે માત્ર ભૌતિક સ્થાનિક ડિસ્ક સાથેનું એક મશીન છે, જે ઝડપી છે. આ એક SSD સાથે છે, ઉદાહરણ તરીકે. અને અમુક પ્રકારની સ્થાનિક કેશ આ ડિસ્ક પર સંગ્રહિત છે.

શાના જેવું લાગે છે? વપરાશકર્તા ફોટો માટે વિનંતી મોકલે છે. NGINX તેને સ્થાનિક કેશમાં પ્રથમ શોધે છે. જો નહીં, તો ફક્ત અમારા સ્ટોરેજમાં proxy_pass કરો, ત્યાંથી ફોટો ડાઉનલોડ કરો અને તેને વપરાશકર્તાને આપો.

પરંતુ આ ખૂબ જ મામૂલી છે અને અંદર શું થઈ રહ્યું છે તે અસ્પષ્ટ છે. તે આના જેવું કંઈક કામ કરે છે.

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

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

આ કામ કરવા માટે, આપણે આ કેશને કોઈક રીતે મેનેજ કરવાની જરૂર છે, અમારે તેમાં ફોટાને ફરીથી ગોઠવવાની જરૂર છે, વગેરે. આ પણ ખૂબ જ આદિમ પ્રક્રિયા છે.

Nginx દરેક વિનંતી માટે ફક્ત RAMDisk access.log પર લખે છે, જેમાં તે હાલમાં આપેલા ફોટાનો પાથ સૂચવે છે (અલબત્ત સંબંધિત પાથ), અને તે કયું પાર્ટીશન આપવામાં આવ્યું હતું. તે. તે "ફોટો 1" કહી શકે છે અને પછી કાં તો બફર, અથવા હોટ કેશ, અથવા કોલ્ડ કેશ, અથવા પ્રોક્સી.

આના પર આધાર રાખીને, આપણે કોઈક રીતે ફોટો સાથે શું કરવું તે નક્કી કરવાની જરૂર છે.

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

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

જે ફોટાઓ ભાગ્યે જ વિનંતી કરવામાં આવે છે અને ઓછી વારંવાર વિનંતી કરવામાં આવી હોય તે ફોટાને ધીમે ધીમે ગરમ કેશમાંથી ઠંડામાં ધકેલવામાં આવે છે.

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

ફોટોને બફર પર પ્રોક્સી કરતી વખતે તરત જ સાચવી શકાય તે માટે, અમે proxy_store ડાયરેક્ટિવનો ઉપયોગ કરીએ છીએ અને બફર એ RAMDisk પણ છે, એટલે કે. વપરાશકર્તા માટે તે ખૂબ જ ઝડપથી કામ કરે છે. આ કેશીંગ સર્વરના આંતરિક ભાગની ચિંતા કરે છે.

બાકીનો પ્રશ્ન એ છે કે આ સર્વર્સ પર વિનંતીઓ કેવી રીતે વિતરિત કરવી.

ચાલો કહીએ કે ત્યાં વીસ સ્ટોરેજ મશીન અને ત્રણ કેશીંગ સર્વર્સનું ક્લસ્ટર છે (આ રીતે તે થયું).

અમારે કોઈ રીતે નક્કી કરવાની જરૂર છે કે કઈ વિનંતીઓ કયા ફોટા માટે છે અને તેમને ક્યાં ઉતારવા.

સૌથી સામાન્ય વિકલ્પ રાઉન્ડ રોબિન છે. અથવા આકસ્મિક રીતે કરો?

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

અમારે કોઈક રીતે અસ્પષ્ટપણે નિર્ધારિત કરવાની જરૂર છે કે કયું સર્વર કઈ વિનંતી પર ઉતરવું.

એક મામૂલી માર્ગ છે. અમે URL માંથી હેશ લઈએ છીએ અથવા અમારી શાર્ડિંગ કીમાંથી હેશ લઈએ છીએ, જે URL માં છે અને તેને સર્વરની સંખ્યા દ્વારા વિભાજીત કરીએ છીએ. આ કામ કરશે? વિલ.

તે. અમારી પાસે 2% વિનંતિ છે, ઉદાહરણ તરીકે, અમુક “example_url” માટે તે હંમેશા ઇન્ડેક્સ “XNUMX” સાથે સર્વર પર ઉતરશે, અને કેશનો શક્ય તેટલો શ્રેષ્ઠ નિકાલ કરવામાં આવશે.

પરંતુ આવી સ્કીમમાં રિશાર્ડિંગમાં સમસ્યા છે. રીશેર્ડિંગ - મારો મતલબ સર્વરની સંખ્યા બદલવાનો છે.

ચાલો ધારીએ કે અમારું કેશીંગ ક્લસ્ટર હવે સામનો કરી શકશે નહીં અને અમે બીજું મશીન ઉમેરવાનું નક્કી કરીએ છીએ.

ચાલો ઉમેરીએ.

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

આ વિકલ્પ પણ અમને અનુકૂળ નથી.

તે. આપણે શું કરવું જોઈએ? આપણે કોઈક રીતે કેશનો કાર્યક્ષમ ઉપયોગ કરવો જોઈએ, એક જ સર્વર પર વારંવાર એક જ વિનંતી કરવી જોઈએ, પરંતુ ફરીથી શેર કરવા માટે પ્રતિરોધક રહેવું જોઈએ. અને આવા ઉકેલ છે, તે એટલું જટિલ નથી. તેને સતત હેશિંગ કહેવામાં આવે છે.

શાના જેવું લાગે છે?

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

દરેક સર્વરને એક બિંદુ દ્વારા વ્યાખ્યાયિત કરવામાં આવે છે, અને તે ક્ષેત્ર જે ઘડિયાળની દિશામાં જાય છે, તે મુજબ, આ હોસ્ટ દ્વારા સેવા આપવામાં આવે છે. જ્યારે અમારી પાસે વિનંતીઓ આવે છે, ત્યારે અમે તરત જ જોઈ શકીએ છીએ કે, ઉદાહરણ તરીકે, વિનંતી A - તેમાં હેશ છે - અને તે સર્વર 2 દ્વારા આપવામાં આવે છે. વિનંતી B - સર્વર 3 દ્વારા. અને તેથી વધુ.

રીશાર્ડિંગ દરમિયાન આ પરિસ્થિતિમાં શું થાય છે?

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

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

એકમાત્ર પ્રશ્ન ઇનકાર સાથે રહે છે. ચાલો ધારીએ કે અમુક પ્રકારની કાર ઓર્ડરની બહાર છે.

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

આ કેશીંગ સિસ્ટમ વિશે છે. ચાલો પરિણામો જોઈએ.

એવું લાગે છે કે અહીં કંઈ જટિલ નથી. પરંતુ કેશ મેનેજ કરવાની આ પદ્ધતિએ અમને લગભગ 98% નો ટ્રીક રેટ આપ્યો. તે. આ 80 હજાર વિનંતીઓમાંથી પ્રતિ સેકન્ડ, ફક્ત 1600 જ સ્ટોરેજ સુધી પહોંચે છે, અને આ એક સંપૂર્ણ સામાન્ય ભાર છે, તેઓ શાંતિથી તેને સહન કરે છે, અમારી પાસે હંમેશા અનામત છે.

અમે આ સર્વર્સને અમારા ત્રણ ડીસીમાં મૂક્યા, અને હાજરીના ત્રણ બિંદુઓ પ્રાપ્ત કર્યા - પ્રાગ, મિયામી અને હોંગકોંગ.

તે. તેઓ અમારા દરેક લક્ષ્ય બજારોમાં વધુ કે ઓછા સ્થાનિક રીતે સ્થિત છે.

અને એક સરસ બોનસ તરીકે, અમને આ કેશીંગ પ્રોક્સી મળી છે, જેના પર CPU ખરેખર નિષ્ક્રિય છે, કારણ કે સામગ્રી સેવા આપવા માટે તેની એટલી જરૂર નથી. અને ત્યાં, NGINX+ Lua નો ઉપયોગ કરીને, અમે ઘણા બધા ઉપયોગિતાવાદી તર્કનો અમલ કર્યો.

ઉદાહરણ તરીકે, અમે webp અથવા પ્રગતિશીલ jpeg (આ અસરકારક આધુનિક ફોર્મેટ છે) સાથે પ્રયોગ કરી શકીએ છીએ, તે ટ્રાફિકને કેવી રીતે અસર કરે છે તે જોઈ શકીએ છીએ, કેટલાક નિર્ણયો લઈ શકીએ છીએ, અમુક દેશો માટે તેને સક્ષમ કરી શકીએ છીએ, વગેરે; ગતિશીલ માપ બદલો અથવા ફ્લાય પર ફોટા કાપો.

આ એક સારો ઉપયોગ કેસ છે જ્યારે, ઉદાહરણ તરીકે, તમારી પાસે એક મોબાઇલ એપ્લિકેશન છે જે ફોટા પ્રદર્શિત કરે છે, અને મોબાઇલ એપ્લિકેશન ક્લાયંટના CPUને મોટા ફોટાની વિનંતી કરવા અને પછી તેને દબાણ કરવા માટે તેને ચોક્કસ કદમાં માપવા પર બગાડવા માંગતી નથી. દૃશ્ય અમે UPort શરતી URL માં કેટલાક પરિમાણોને ગતિશીલ રીતે સ્પષ્ટ કરી શકીએ છીએ, અને ફોટો કેશ ફોટોનું માપ બદલશે. એક નિયમ તરીકે, તે ડિસ્ક પર આપણી પાસે ભૌતિક રૂપે હોય તે કદને પસંદ કરશે, વિનંતી કરેલ એકની શક્ય તેટલી નજીક, અને તેને ચોક્કસ કોઓર્ડિનેટ્સમાં ડાઉનસેલ કરશે.

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

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

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

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

અને, સંભવત,, એક અત્યાધુનિક શ્રોતા પાસે પ્રશ્ન હોઈ શકે છે: શા માટે ફક્ત બધું જ CDN માં બદલવું નહીં? તે લગભગ સમાન હશે; બધા આધુનિક CDN આ કરી શકે છે. અને ત્યાં ઘણા કારણો છે.

પ્રથમ ફોટોગ્રાફ્સ છે.

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

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

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

અને પાછલા એક થી અનુસરે છે તે મુદ્દો છે

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

આ શું નિષ્કર્ષ સૂચવે છે? અમારા કિસ્સામાં, CDN એ બહુ સારો વિકલ્પ નથી.

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

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

અને આધુનિક CDN પાસે લગભગ બધું જ છે જે મેં તમને હમણાં કહ્યું હતું. પ્લસ અથવા માઈનસ કેટલીક સુવિધાઓના અપવાદ સાથે.

આ ફોટા આપવા વિશે છે.

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

2013 પસાર થઈ રહ્યું હતું.

કેશીંગ સર્વર્સ ઉમેરવામાં આવ્યા, પ્રદર્શન સમસ્યાઓ દૂર થઈ. બધું બરાબર છે. ડેટાસેટ વધી રહ્યો છે. 2013 સુધીમાં, અમારી પાસે સ્ટોરેજ સાથે લગભગ 80 સર્વર જોડાયેલા હતા, અને દરેક DCમાં લગભગ 40 કેશીંગ હતા. આ દરેક ડીસી પર 560 ટેરાબાઇટ ડેટા છે, એટલે કે. કુલ લગભગ એક પેટાબાઇટ.

અને ડેટાસેટની વૃદ્ધિ સાથે, સંચાલન ખર્ચ નોંધપાત્ર રીતે વધવા લાગ્યો. આનો અર્થ શું હતો?

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

પ્રથમ, સ્ટોરેજ એરિયા નેટવર્ક (SAN) પોતે, જે નિષ્ફળ થઈ શકે છે.

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

અલબત્ત, તેમાંના ઘણા બધા SAN સાથે નથી, પરંતુ, તેમ છતાં, આ નિષ્ફળતાના મુદ્દાઓ પણ છે.

આગળ મશીન પોતે છે, જે સ્ટોરેજ સાથે જોડાયેલ છે. તે નિષ્ફળ પણ થઈ શકે છે.

કુલ મળીને, અમારી પાસે નિષ્ફળતાના ત્રણ બિંદુઓ છે.

આગળ, નિષ્ફળતાના મુદ્દાઓ ઉપરાંત, સ્ટોરેજની જ ભારે જાળવણી છે.

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

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

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

આ વિશે કંઈક કરવું જરૂરી હતું. અને અમે નક્કી કર્યું કે અમારે ફક્ત ડેટાનો બેકઅપ લેવાની જરૂર છે. આ વાસ્તવમાં એક સ્પષ્ટ ઉકેલ અને સારો છે. અમે શું કર્યું છે?

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

અમે હમણાં જ બીજો વિભાગ ઉમેર્યો છે.

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

અહીં આપણે નજીકમાં અસુમેળ કતાર બનાવીએ છીએ.

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

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

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

અને અમે ત્રીજી ડિસ્ક ઉમેરી, જે નાની SSD છે, અને તેને બફર કહે છે.

તે હવે કેવી રીતે કામ કરે છે.

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

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

સારું, અને સૌથી અગત્યનું: અમે ડેટા ગુમાવવાનું બંધ કર્યું.

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

પ્રથમ, આ ભૌતિક યજમાનના સ્વરૂપમાં નિષ્ફળતાનો એક બિંદુ છે જેના પર આ બધી મશીનરી ચાલે છે; તે દૂર થઈ નથી.

બીજું, SAN માં હજુ પણ સમસ્યાઓ છે, તેમની ભારે જાળવણી વગેરે બાકી છે. એવું ન હતું કે તે એક નિર્ણાયક પરિબળ હતું, પરંતુ હું તેના વિના કોઈક રીતે જીવવાનો પ્રયાસ કરવા માંગતો હતો.

અને અમે ત્રીજું સંસ્કરણ બનાવ્યું (હકીકતમાં, હકીકતમાં બીજું) - આરક્ષણ સંસ્કરણ. તે શું દેખાતું હતું?

આ તે હતું -

અમારી મુખ્ય સમસ્યાઓ એ હકીકત સાથે છે કે આ ભૌતિક યજમાન છે.

પ્રથમ, અમે SAN ને દૂર કરી રહ્યા છીએ કારણ કે અમે પ્રયોગ કરવા માંગીએ છીએ, અમે ફક્ત સ્થાનિક હાર્ડ ડ્રાઈવો અજમાવવા માંગીએ છીએ.

આ પહેલેથી જ 2014-2015 છે, અને તે સમયે ડિસ્કની પરિસ્થિતિ અને એક હોસ્ટમાં તેમની ક્ષમતા વધુ સારી બની હતી. અમે નક્કી કર્યું કે શા માટે તેનો પ્રયાસ ન કરવો.

અને પછી અમે ફક્ત અમારું બેકઅપ પાર્ટીશન લઈએ છીએ અને તેને ભૌતિક રીતે અલગ મશીનમાં સ્થાનાંતરિત કરીએ છીએ.

આમ, આપણને આ રેખાકૃતિ મળે છે. અમારી પાસે બે કાર છે જે સમાન ડેટાસેટ્સ સ્ટોર કરે છે. તેઓ એકબીજાનો સંપૂર્ણ બેકઅપ લે છે અને સમાન MySQL માં અસુમેળ કતાર દ્વારા નેટવર્ક પર ડેટાને સિંક્રનાઇઝ કરે છે.

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

આ કેવી રીતે કાર્ય કરે છે, જો તમે થોડી વધુ વિગતવાર જુઓ.

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

કાર્ય થોડું વધારે મુશ્કેલ છે.

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

જો તે ત્યાં ન હોય, તો અમે ફક્ત અમારા પાડોશીને વિનંતી કરીએ છીએ અને ત્યાંથી તે પ્રાપ્ત કરવાની ખાતરી આપીએ છીએ.

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

અમારી પરિસ્થિતિમાં, આ ધીમે ધીમે કામ કરતું નથી.

અમે આ સિસ્ટમ પર મેટ્રિક્સનો સમૂહ એકત્રિત કરીએ છીએ, અને આવી મિકેનિઝમનો શરતી સ્માર્ટ રેટ લગભગ 95% છે. તે. આ બેકઅપનો લેગ નાનો છે, અને તેના કારણે અમે લગભગ ખાતરી આપીએ છીએ, ફોટો અપલોડ થયા પછી, અમે તેને પ્રથમ વખત લઈશું અને બે વાર ક્યાંય જવું પડશે નહીં.

તો આપણી પાસે બીજું શું છે જે ખરેખર સરસ છે?

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

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

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

એક કાર બગડે છે.

કોઇ વાંધો નહી! સિસ્ટમ એન્જિનિયર કદાચ રાત્રે પણ જાગી ન શકે, તે સવાર સુધી રાહ જોશે, કંઈ ખરાબ થશે નહીં.

જો આ મશીન નિષ્ફળ જાય તો પણ, કતાર વ્યવસ્થિત નથી, ત્યાં પણ કોઈ સમસ્યા નથી, લોગ ફક્ત લિવિંગ મશીન પર એકઠા કરવામાં આવશે, અને પછી તે કતારમાં ઉમેરવામાં આવશે, અને પછી કાર પર જે થોડા સમય પછી ઓપરેશનમાં જાઓ.

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

આ રીડન્ડન્સી સ્કીમમાંથી કયા તારણો કાઢી શકાય?

અમને દોષ સહિષ્ણુતા મળી છે.

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

અમને ડબલ રીડિંગ એલાઉન્સ મળ્યું.

આ દોષ સહિષ્ણુતા ઉપરાંત ખૂબ જ સારો બોનસ છે.

પરંતુ સમસ્યાઓ પણ છે. હવે અમારી પાસે આને લગતી કેટલીક સુવિધાઓનો વધુ જટિલ વિકાસ છે, કારણ કે સિસ્ટમ આખરે 100% સુસંગત બની ગઈ છે.

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

અને અહીં ફરીથી કેટલાક સંઘર્ષ ઊભો થાય છે.

મેં શરૂઆતમાં કહ્યું હતું કે સ્થાનિક હાર્ડ ડ્રાઇવ્સ પર બધું સંગ્રહિત કરવું ખરાબ છે. અને હવે હું કહું છું કે અમને તે ગમ્યું.

હા, ખરેખર, સમય જતાં પરિસ્થિતિ ઘણી બદલાઈ ગઈ છે, અને હવે આ અભિગમના ઘણા ફાયદા છે. સૌપ્રથમ, અમને ઘણું સરળ ઓપરેશન મળે છે.

બીજું, તે વધુ ઉત્પાદક છે, કારણ કે અમારી પાસે આ સ્વચાલિત નિયંત્રકો અથવા ડિસ્ક છાજલીઓ સાથે જોડાણો નથી.

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

પરંતુ ગેરફાયદા પણ છે.

આજના ભાવે પણ SAN નો ઉપયોગ કરતાં આ લગભગ 1,5 ગણું મોંઘું છે. તેથી, અમે હિંમતભેર અમારા સમગ્ર મોટા ક્લસ્ટરને સ્થાનિક હાર્ડ ડ્રાઈવોવાળી કારમાં રૂપાંતરિત ન કરવાનું નક્કી કર્યું અને હાઇબ્રિડ સોલ્યુશન છોડવાનું નક્કી કર્યું.

અમારા અડધા મશીનો હાર્ડ ડ્રાઈવો સાથે કામ કરે છે (સારી રીતે, અડધા નહીં - કદાચ 30 ટકા). અને બાકીની જૂની કાર છે જેમાં પહેલા રિઝર્વેશન સ્કીમ હતી. અમે ફક્ત તેમને ફરીથી માઉન્ટ કર્યા, કારણ કે અમને નવા ડેટા અથવા અન્ય કંઈપણની જરૂર નથી, અમે ફક્ત એક ભૌતિક હોસ્ટમાંથી માઉન્ટ્સને બેમાં ખસેડ્યા.

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

ચાલો આપણે શું પરિપૂર્ણ કર્યું, આપણે શું લડ્યા અને શું આપણે સફળ થયા તેનો સંક્ષિપ્ત સારાંશ લઈએ.

પરિણામો

અમારી પાસે વપરાશકર્તાઓ છે - 33 મિલિયન જેટલા.

અમારી પાસે હાજરીના ત્રણ બિંદુઓ છે - પ્રાગ, મિયામી, હોંગકોંગ.

તેમાં એક કેશીંગ લેયર હોય છે, જેમાં ફાસ્ટ લોકલ ડિસ્ક (SSD) વાળી કાર હોય છે, જેના પર NGINX, તેની access.log અને Python ડિમન ચાલે છે, જે આ બધી પ્રક્રિયા કરે છે અને કેશનું સંચાલન કરે છે.

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

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

વધુમાં, આમાંના કેટલાક મશીનો સ્થાનિક હાર્ડ ડ્રાઈવો સાથે કામ કરે છે.

આમાંના કેટલાક મશીનો SAN સાથે જોડાયેલા છે.

અને, એક તરફ, તે વાપરવા માટે વધુ અનુકૂળ છે અને થોડી વધુ ઉત્પાદક છે, બીજી તરફ, તે પ્લેસમેન્ટની ઘનતા અને ગીગાબાઈટ દીઠ કિંમતની દ્રષ્ટિએ અનુકૂળ છે.

આપણને શું મળ્યું અને તે બધું કેવી રીતે વિકસિત થયું તેના આર્કિટેક્ચરની આ સંક્ષિપ્ત ઝાંખી છે.

કેપ્ટન તરફથી થોડી વધુ ટીપ્સ, ખૂબ જ સરળ.

પ્રથમ, જો તમે અચાનક નક્કી કરો કે તમારે તમારા ફોટો ઈન્ફ્રાસ્ટ્રક્ચરમાં તાત્કાલિક બધું સુધારવાની જરૂર છે, તો પહેલા માપો, કારણ કે કદાચ કંઈપણ સુધારવાની જરૂર નથી.

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

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

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

પહેલા અમે તેને માપ્યું, પછી અમે તેને સુધાર્યું.

આગળ. અમે કેશ સાથે વાંચનને ઑપ્ટિમાઇઝ કરીએ છીએ, શાર્ડિંગ સાથે લખીએ છીએ, પરંતુ આ એક સ્પષ્ટ મુદ્દો છે.

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

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

આગામી બિંદુ. ફ્લાય પર માપ બદલવા વિશે.

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

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

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

અને ઇન્ક્રીમેન્ટલ અસિંક્રોનસ બેકઅપ સારું છે.

અમારી પ્રેક્ટિસ બતાવે છે તેમ, આ સ્કીમ બદલાયેલી ફાઈલોની વિલંબિત નકલ સાથે સારી રીતે કામ કરે છે.

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

સંપર્કો

» bo0rsh201
» Badoo બ્લોગ

આ અહેવાલ ઉચ્ચ-લોડ સિસ્ટમ્સના વિકાસકર્તાઓની પરિષદમાંના શ્રેષ્ઠ ભાષણોમાંના એકની ટ્રાન્સક્રિપ્ટ છે હાઇલોડ++. HighLoad++ 2017 કોન્ફરન્સમાં એક મહિના કરતાં ઓછો સમય બાકી છે.

અમારી પાસે તે પહેલેથી જ તૈયાર છે કોન્ફરન્સ કાર્યક્રમ, શેડ્યૂલ હવે સક્રિય રીતે બનાવવામાં આવી રહ્યું છે.

આ વર્ષે અમે આર્કિટેક્ચર અને સ્કેલિંગના વિષયનું અન્વેષણ કરવાનું ચાલુ રાખીએ છીએ:

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

અમે આમાંની કેટલીક સામગ્રીનો ઉપયોગ હાઈ-લોડ સિસ્ટમ્સ વિકસાવવાના અમારા ઑનલાઇન તાલીમ અભ્યાસક્રમમાં પણ કરીએ છીએ હાઇલોડ.ગાઇડ ખાસ પસંદ કરેલા પત્રો, લેખો, સામગ્રી, વિડીયોની સાંકળ છે. અમારા પાઠ્યપુસ્તકમાં પહેલેથી જ 30 થી વધુ અનન્ય સામગ્રી છે. જોડાવા!

સોર્સ: www.habr.com