કેવી રીતે ચિંતા કરવાનું બંધ કરવું અને મોનોલિથ વિના જીવવાનું શરૂ કરવું

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

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

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

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

આજે, CI/CD, K8S, વગેરેના સ્વરૂપમાં ફેરફારો કરવા માટે ઘણા બધા સાધનો અને સાધનો છે. "મોનોલિથિક" સમયમાં, અમને ઘણા વિદેશી શબ્દોની જરૂર નહોતી. ડેટાબેઝમાં ફક્ત "સ્ટોરેજ" સુધારવા માટે તે પૂરતું હતું.

પરંતુ સમય આગળ વધ્યો, અને વિનંતીઓની સંખ્યા તેની સાથે આગળ વધી, કેટલીકવાર અમારી ક્ષમતાઓથી આગળ RPS શૂટ કરે છે. બજારમાં CIS દેશોના પ્રવેશ સાથે, પ્રથમ મોનોલિથના ડેટાબેઝ પ્રોસેસર પરનો ભાર 90% થી નીચે ન આવ્યો, અને RPS 2400 ના સ્તરે રહ્યો. અને આ માત્ર નાના પસંદગીકારો ન હતા, પરંતુ ભારે પ્રશ્નો હતા. ચેક અને જોડાઓનો સમૂહ જે મોટા IO ની પૃષ્ઠભૂમિ સામે લગભગ અડધા ડેટા માટે ચાલી શકે છે.

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

તમે શું કરી શકો - ફેશન તકનીકમાં સહજ છે. લગભગ 5 વર્ષ પહેલાં, અમારે .NET અને MS SQL સર્વર પર હાલની સાઇટના રૂપમાં આ મોડ્સમાંથી એક પર પુનર્વિચાર કરવો પડ્યો હતો, જે સાઇટના તમામ તર્કને કાળજીપૂર્વક સંગ્રહિત કરે છે. મેં તેને એટલી કાળજીપૂર્વક રાખ્યું કે આવા મોનોલિથને જોવું એ લાંબો અને સરળ આનંદ નથી.
એક નાનું વિષયાંતર.

વિવિધ ઇવેન્ટ્સમાં હું કહું છું: "જો તમે મોનોલિથ ન જોયું હોય, તો તમે વધ્યા નથી!" મને આ બાબતે તમારા અભિપ્રાયમાં રસ છે, કૃપા કરીને તેને ટિપ્પણીઓમાં લખો.

એ સાઉન્ડ ઓફ થન્ડર

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

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

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

અમે તરત જ અમારા ક્લાયન્ટ વિશેના ડેટાને શાર્ડેડ સિસ્ટમમાં ટ્રાન્સફર કરવાની યોજના બનાવી છે. માલની અંતિમ કિંમતની ગણતરી કરવા માટેની કાર્યક્ષમતાને દૂર કરવા માટે વાંચન માટે સારી માપનીયતાની જરૂર હતી, કારણ કે તે સૌથી વધુ RPS લોડ બનાવે છે અને ડેટાબેઝ માટે અમલમાં મૂકવું સૌથી મુશ્કેલ હતું (ગણતરી પ્રક્રિયામાં ઘણો ડેટા સામેલ છે).

પરિણામે, અમે એક સ્કીમ લઈને આવ્યા છીએ જે ટેરન્ટૂલ સાથે સારી રીતે બંધબેસે છે.

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

આર્કિટેક્ચર. વિકલ્પ 1. વપરાશકર્તા સેવા

વર્તમાન સમયે, ત્યાં 24 શાર્ડ્સ છે, જેમાંના દરેકમાં 2 દાખલાઓ છે (દરેક DC માટે એક), બધા માસ્ટર-માસ્ટર મોડમાં છે.

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

આ કિસ્સામાં, શાર્ડ્સના સંદર્ભમાં પ્રતિકૃતિ પસંદગી નીતિને ગોઠવવાનું શક્ય છે. ઉદાહરણ તરીકે, રાઉન્ડરોબિન.

આર્કિટેક્ચર. વિકલ્પ 2. માલની અંતિમ કિંમતની ગણતરી કરવા માટેની સેવા

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

સેવા ડેટાબેઝમાં 4 માસ્ટર્સનો સમાવેશ થાય છે જેમાં સિંક્રોનાઇઝર ડેટા એકત્રિત કરે છે, અને આ દરેક પ્રતિકૃતિ માસ્ટર્સ ફક્ત વાંચન પ્રતિકૃતિઓ માટે ડેટાનું વિતરણ કરે છે. દરેક માસ્ટર પાસે આવી લગભગ 15 પ્રતિકૃતિઓ છે.

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

તે નોંધવું યોગ્ય છે કે ટેરેન્ટૂલમાં પ્રતિકૃતિ તદ્દન લવચીક છે અને રનટાઇમ પર ગોઠવી શકાય છે. અન્ય સિસ્ટમોમાં, મુશ્કેલીઓ ઊભી થઈ. ઉદાહરણ તરીકે, PostgreSQL માં max_wal_senders અને max_replication_slots પરિમાણોને બદલવા માટે વિઝાર્ડને પુનઃપ્રારંભ કરવાની જરૂર છે, જે કેટલાક કિસ્સાઓમાં એપ્લિકેશન અને DBMS વચ્ચેના જોડાણોને તોડવા તરફ દોરી શકે છે.

શોધો અને તમને મળશે!

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

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

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

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

આખરે અમે ટેરન્ટૂલ પર સ્થાયી થયા.

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

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

અમલીકરણની રફ શરૂઆત થઈ

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

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

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

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

ભાગલા પાડો અને રાજ કરો. લુઆ સાથે શું ડીલ છે?

ત્યાં એક ગંભીર મૂંઝવણ હતી: કેટલીક ટીમો લુઆમાં ઘણાં તર્ક સાથે સેવામાં ફેરફારોને વિશ્વસનીય રીતે રોલ આઉટ કરવામાં અસમર્થ હતી. આ સાથે ઘણી વખત સેવા કામ કરતી નથી.

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

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

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

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

સૌથી મહત્વપૂર્ણ સેવાઓમાંની એક વપરાશકર્તા પ્રોફાઇલ છે. એટલે કે, તમામ વાઇલ્ડબેરી વપરાશકર્તાઓ ટેરેન્ટૂલમાં સંગ્રહિત છે, અને તેમાંથી લગભગ 50 મિલિયન છે. વપરાશકર્તા ID દ્વારા વહેંચાયેલ સિસ્ટમ, Go સેવાઓ સાથે જોડાયેલા કેટલાક DC પર વિતરિત કરવામાં આવે છે.
RPS મુજબ, પ્રમોટર એક સમયે નેતા હતા, 6 હજાર વિનંતીઓ સુધી પહોંચતા હતા. એક સમયે અમારી પાસે 50-60 નકલો હતી. હવે RPS માં લીડર વપરાશકર્તા પ્રોફાઇલ્સ છે, લગભગ 12 હજાર. આ સેવા કસ્ટમ શાર્ડિંગનો ઉપયોગ કરે છે, જે વપરાશકર્તા ID ની શ્રેણી દ્વારા વિભાજિત થાય છે. સેવા 20 થી વધુ મશીનો સેવા આપે છે, પરંતુ આ ઘણી બધી છે; અમે ફાળવેલ સંસાધનોને ઘટાડવાની યોજના બનાવીએ છીએ, કારણ કે તેના માટે 4-5 મશીનોની ક્ષમતા પૂરતી છે.

સત્ર સેવા એ vshard અને Cartridge પરની અમારી પ્રથમ સેવા છે. vshard ને સેટ કરવા અને કાર્ટ્રિજને અપડેટ કરવા માટે અમારા તરફથી થોડો પ્રયત્ન કરવો જરૂરી હતો, પરંતુ અંતે બધું કામ કરી ગયું.

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

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

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

નિષ્કર્ષ

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

વિષય પર બીજું શું વાંચવું

• ટેરન્ટૂલનો ઉપયોગ કરીને શરૂઆતથી હાઇ-લોડ એપ્લિકેશન બનાવવી habr.com/ru/company/mailru/blog/510440
• ટેરેન્ટૂલ કારતૂસમાં વિશ્વસનીય નેતાની પસંદગી habr.com/ru/company/mailru/blog/513912
• ઉત્પાદન વિશે સમાચાર સાથે ટેલિગ્રામ ચેનલ ટેરન્ટૂલ t.me/tarantool_news
• કોમ્યુનિટી ચેટમાં ટેરન્ટૂલની ચર્ચા કરો t.me/tarantoolru

સોર્સ: www.habr.com