"હડૂપ. Mail.Ru ગ્રુપ ટેક્નોસ્ટ્રીમ શ્રેણીમાંથી ZooKeeper "હાડુપમાં ડેટાના મોટા જથ્થાના વિતરિત પ્રક્રિયા માટેની પદ્ધતિઓ"

હું સૂચન કરું છું કે તમે "હાડુપમાં ડેટાના મોટા જથ્થાના વિતરિત પ્રક્રિયા માટેની પદ્ધતિઓ" શ્રેણીમાંથી "હેડુપ. ઝૂકીપર" વ્યાખ્યાનનું ટ્રાન્સક્રિપ્ટ વાંચો.

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

આજે આપણે ZooKeeper વિશે વાત કરીશું. આ વસ્તુ ખૂબ જ ઉપયોગી છે. તે, કોઈપણ Apache Hadoop ઉત્પાદનની જેમ, એક લોગો ધરાવે છે. તે એક માણસને દર્શાવે છે.

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

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

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

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

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

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

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

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

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

એક પ્રોસેસર સાથે એક કમ્પ્યુટર પર ચાલતો પ્રોગ્રામ લખવો સરળ છે.

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

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

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

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

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

આજે આપણે ZooKeeper વિશે વાત કરી રહ્યા છીએ. એક તરફ, તે એક માળખું છે, બીજી તરફ, તે એક સેવા છે જે વિકાસકર્તા માટે જીવન સરળ બનાવે છે અને શક્ય તેટલું અમારી પ્રક્રિયાઓના તર્ક અને સંકલનના અમલીકરણને સરળ બનાવે છે.

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

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

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

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

આમાંથી કઈ યોજના વધુ સારી રીતે કામ કરે છે તે કહેવું મુશ્કેલ છે. દરેકના પોતાના ફાયદા અને ગેરફાયદા છે.

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

અને આ યોજના (ઉપર) કદાચ વધુ જટિલ છે, પરંતુ વધુ વિશ્વસનીય છે.

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

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

ZooKeeper આવા ઇનકારનો સામનો કરવાની રીતો પ્રદાન કરે છે, જે આપણું જીવન પણ સરળ બનાવે છે.

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

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

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

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

ડાયનેમિક રૂપરેખાંકન પણ છે. આ એવા પરિમાણો છે જે અમે ફ્લાય પર બદલવા માંગીએ છીએ જેથી તેઓ ત્યાં લેવામાં આવે.

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

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

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

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

ZooKeeper તમને આ બધી સમસ્યાઓને એક અથવા બીજી રીતે હલ કરવાની મંજૂરી આપે છે. અને હું ઉદાહરણો સાથે બતાવીશ કે તે તમને આ કેવી રીતે કરવાની મંજૂરી આપે છે.

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

તમામ ક્લાયન્ટ વિનંતીઓ સામાન્ય કતારના ક્રમમાં પ્રક્રિયા કરવામાં આવે છે.

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

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

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

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

ગ્રાહક એ વપરાશકર્તા છે જે ZooKeeper નો ઉપયોગ કરે છે.

સર્વર એ ઝૂકીપર પ્રક્રિયા છે.

ઝનોડ એ ઝૂકીપરમાં મુખ્ય વસ્તુ છે. બધા ઝનોડ્સ ZooKeeper દ્વારા મેમરીમાં સંગ્રહિત થાય છે અને વૃક્ષના રૂપમાં અધિક્રમિક રેખાકૃતિના સ્વરૂપમાં ગોઠવવામાં આવે છે.

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

અને શક્ય છે કે ક્લાયંટ એક વિનંતી પૂર્ણ ન કરે અને ડિસ્કનેક્ટ થઈ જાય, પરંતુ તે એક સત્ર સ્થાપિત કરી શકે છે જેના દ્વારા તે ZooKeeper સાથે સંપર્ક કરે છે.

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

દરેક znode અમુક ડેટા સ્ટોર કરી શકે છે, સામાન્ય રીતે બહુ મોટો નથી, ઉદાહરણ તરીકે, 10 કિલોબાઈટ. અને દરેક ઝનોડમાં ચોક્કસ સંખ્યામાં બાળકો હોઈ શકે છે.

ઝનોડ્સ ઘણા પ્રકારોમાં આવે છે. તેઓ બનાવી શકાય છે. અને znode બનાવતી વખતે, અમે તે કયા પ્રકારનો હોવો જોઈએ તેનો ઉલ્લેખ કરીએ છીએ.

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

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

નિયમિત znode. તેણી હંમેશા જીવશે અને તેનું નામ હશે જે અમે તેણીને કહીએ છીએ.

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

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

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

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

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

બીજું, તમે તેને કાઢી શકો છો. અહીં યુક્તિ એ છે કે બીજું પરિમાણ, znode ના પાથ ઉપરાંત, સંસ્કરણને સ્પષ્ટ કરી શકે છે. તદનુસાર, તે znode કાઢી નાખવામાં આવશે જો તેનું વર્ઝન જે અમે ટ્રાન્સફર કર્યું છે તે વાસ્તવમાં અસ્તિત્વમાં છે તેની સમકક્ષ છે.

જો આપણે આ સંસ્કરણને તપાસવા માંગતા નથી, તો અમે ફક્ત "-1" દલીલ પસાર કરીએ છીએ.

ત્રીજું, તે ઝનોડના અસ્તિત્વની તપાસ કરે છે. જો નોડ અસ્તિત્વમાં હોય તો સાચું પરત કરે છે, અન્યથા ખોટું.

અને પછી ધ્વજ ઘડિયાળ દેખાય છે, જે તમને આ નોડને મોનિટર કરવાની મંજૂરી આપે છે.

તમે આ ધ્વજને અસ્તિત્વમાં ન હોય તેવા નોડ પર પણ સેટ કરી શકો છો અને જ્યારે તે દેખાય ત્યારે સૂચના પ્રાપ્ત કરી શકો છો. આ પણ ઉપયોગી થઈ શકે છે.

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

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

તમે આ ચેકને બાકાત રાખવા માટે "-1" નો પણ ઉલ્લેખ કરી શકો છો.

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

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

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

મોટે ભાગે અસુમેળ કૉલ્સનો ઉપયોગ થાય છે. આ ક્લાયંટને વિવિધ વિનંતીઓ સાથે સમાંતર કામ કરવાની મંજૂરી આપે છે. તમે સિંક્રનસ અભિગમનો ઉપયોગ કરી શકો છો, પરંતુ તે ઓછું ઉત્પાદક છે.

અમે જે બે ઑપરેશન વિશે વાત કરી છે તે અપડેટ/રાઇટ છે, જે ડેટાને બદલે છે. આ બનાવો, સેટડેટા, સિંક, ડિલીટ છે. અને રીડ અસ્તિત્વમાં છે, getData, getChildren.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZooKeeper શું સમાવે છે? ત્યાં 4 મુખ્ય વસ્તુઓ છે. આ પ્રક્રિયા પ્રક્રિયાઓ છે - વિનંતી. અને ઝૂકીપર એટોમિક બ્રોડકાસ્ટ પણ. ત્યાં એક કમિટ લોગ છે જ્યાં તમામ કામગીરી રેકોર્ડ કરવામાં આવે છે. અને ઇન-મેમરી રિપ્લિકેટેડ ડીબી પોતે, એટલે કે ડેટાબેઝ પોતે જ્યાં આ આખું વૃક્ષ સંગ્રહિત છે.

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

ડેટાબેઝ પોતે જ સંપૂર્ણપણે નકલ થયેલ છે. ZooKeeper ના તમામ ઉદાહરણો ડેટાની સંપૂર્ણ નકલ સંગ્રહિત કરે છે.

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

ZooKeeper એટોમિક બ્રોડકાસ્ટ એક એવી વસ્તુ છે જેનો ઉપયોગ પ્રતિકૃતિ ડેટા જાળવવા માટે થાય છે.

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

તે ફક્ત લખવાની વિનંતીઓ પર પ્રક્રિયા કરે છે. તેનું મુખ્ય કાર્ય એ છે કે તે ઓપરેશનને ટ્રાન્ઝેક્શનલ અપડેટમાં રૂપાંતરિત કરે છે. આ એક ખાસ જનરેટ કરેલી વિનંતી છે.

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

સોર્સ: www.habr.com