અમે કેવી રીતે અને શા માટે 1C માટે હાઇ-લોડ સ્કેલેબલ સેવા લખી: એન્ટરપ્રાઇઝ: Java, PostgreSQL, Hazelcast

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

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

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

સમસ્યાની રચના

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

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

ક્લાયંટ-સર્વર ડેવલપમેન્ટ પેરાડાઈમ

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

એપ્લિકેશન કોડમાં, પ્રક્રિયાઓ અને કાર્યોના હેડરો સ્પષ્ટપણે સૂચવે છે કે કોડ ક્યાં ચલાવવામાં આવશે - &AtClient / &AtServer નિર્દેશોનો ઉપયોગ કરીને (&AtClient / &AtServer ભાષાના અંગ્રેજી સંસ્કરણમાં). 1C વિકાસકર્તાઓ હવે મને એમ કહીને સુધારશે કે નિર્દેશો ખરેખર છે કરતાં વધુ, પરંતુ અમારા માટે આ હવે મહત્વનું નથી.

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

કોડ કે જે બટન ક્લિકને હેન્ડલ કરે છે: ક્લાયંટ તરફથી સર્વર પ્રક્રિયાને કૉલ કરવાથી કાર્ય થશે, સર્વરથી ક્લાયંટ પ્રક્રિયાને કૉલ કરવાથી નહીં

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

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

ઉત્પાદન પોતે

મેસેજિંગ મિકેનિઝમ બનાવો. ઝડપી, વિશ્વસનીય, બાંયધરીકૃત ડિલિવરી સાથે, લવચીક રીતે સંદેશાઓ શોધવાની ક્ષમતા સાથે. મિકેનિઝમના આધારે, 1C એપ્લિકેશનની અંદર ચાલતા મેસેન્જર (સંદેશાઓ, વિડિયો કૉલ્સ) ને અમલમાં મૂકો.

સિસ્ટમને આડી રીતે માપી શકાય તેવી રીતે ડિઝાઇન કરો. નોડ્સની સંખ્યામાં વધારો કરીને વધતા ભારને આવરી લેવો આવશ્યક છે.

Реализация

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

તેથી, અમે એક અલગ ઉત્પાદન તરીકે SV બનાવવાનું નક્કી કર્યું. અમે ભલામણ કરીએ છીએ કે નાની કંપનીઓ CB સર્વરનો ઉપયોગ કરે જે અમે અમારા ક્લાઉડ (wss://1cdialog.com) માં ઇન્સ્ટોલ કર્યું છે જેથી સર્વરના સ્થાનિક ઇન્સ્ટોલેશન અને ગોઠવણી સાથે સંકળાયેલ ઓવરહેડ ખર્ચ ટાળી શકાય. મોટા ગ્રાહકોને તેમની સુવિધાઓ પર તેમનું પોતાનું CB સર્વર ઇન્સ્ટોલ કરવાનું સલાહભર્યું લાગે છે. અમે અમારા ક્લાઉડ SaaS પ્રોડક્ટમાં સમાન અભિગમનો ઉપયોગ કર્યો છે 1cફ્રેશ - તે ક્લાયંટની સાઇટ્સ પર ઇન્સ્ટોલેશન માટે મોટા પ્રમાણમાં ઉત્પાદિત ઉત્પાદન તરીકે બનાવવામાં આવે છે, અને અમારા ક્લાઉડમાં પણ જમાવવામાં આવે છે https://1cfresh.com/.

એપ્લિકેશન

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

ક્લાયંટ અને સર્વર વચ્ચેનો સંચાર વેબસોકેટ દ્વારા થાય છે. તે રીઅલ-ટાઇમ સિસ્ટમ્સ માટે સારી રીતે અનુકૂળ છે.

વિતરિત કેશ

અમે Redis, Hazelcast અને Ehcache વચ્ચે પસંદગી કરી. 2015ની વાત છે. રેડિસે હમણાં જ એક નવું ક્લસ્ટર (ખૂબ નવું, ડરામણું) બહાર પાડ્યું છે, ત્યાં ઘણા બધા નિયંત્રણો સાથે સેન્ટીનેલ છે. Ehcache ક્લસ્ટરમાં કેવી રીતે એસેમ્બલ કરવું તે જાણતું નથી (આ કાર્યક્ષમતા પછીથી દેખાઈ). અમે તેને હેઝલકાસ્ટ 3.4 સાથે અજમાવવાનું નક્કી કર્યું.
હેઝલકાસ્ટને બોક્સની બહાર ક્લસ્ટરમાં એસેમ્બલ કરવામાં આવે છે. સિંગલ નોડ મોડમાં, તે ખૂબ જ ઉપયોગી નથી અને માત્ર કેશ તરીકે ઉપયોગ કરી શકાય છે - તે ડિસ્ક પર ડેટા કેવી રીતે ડમ્પ કરવો તે જાણતું નથી, જો તમે એકમાત્ર નોડ ગુમાવો છો, તો તમે ડેટા ગુમાવો છો. અમે ઘણા હેઝલકાસ્ટ્સ જમાવીએ છીએ, જેની વચ્ચે અમે મહત્વપૂર્ણ ડેટાનો બેકઅપ લઈએ છીએ. અમે કેશનો બેકઅપ લેતા નથી - અમને તેનો વાંધો નથી.

અમારા માટે, હેઝલકાસ્ટ છે:

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

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

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

DBMS પસંદ કરી રહ્યા છીએ

અમારી પાસે PostgreSQL સાથે કામ કરવાનો અને આ DBMS ના વિકાસકર્તાઓ સાથે સહયોગ કરવાનો વ્યાપક અને સફળ અનુભવ છે.

PostgreSQL ક્લસ્ટર સાથે તે સરળ નથી - ત્યાં છે XL, XC, સિટસ, પરંતુ સામાન્ય રીતે આ NoSQL નથી કે જે બોક્સની બહાર સ્કેલ કરે છે. અમે NoSQL ને મુખ્ય સ્ટોરેજ તરીકે ધ્યાનમાં લીધું ન હતું; તે પૂરતું હતું કે અમે હેઝલકાસ્ટ લીધું, જેની સાથે અમે પહેલાં કામ કર્યું ન હતું.

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

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

તમે મલ્ટિ-ટેનન્ટ વિશે વાંચી શકો છો, ઉદાહરણ તરીકે, વેબસાઇટ પર સાઇટસ ડેટા.

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

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

મુખ્ય ડેટાબેઝને અડચણ બનતા અટકાવવા માટે, અમે રૂટીંગ ટેબલ (અને અન્ય વારંવાર જરૂરી ડેટા)ને કેશમાં રાખીએ છીએ.

જો સબ્સ્ક્રાઇબરનો ડેટાબેઝ ધીમું થવા લાગે છે, તો અમે તેને અંદરના પાર્ટીશનોમાં કાપી નાખીશું. અન્ય પ્રોજેક્ટ્સ પર અમે ઉપયોગ કરીએ છીએ pg_pathman.

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

જો સિંક્રનસ પ્રતિકૃતિ ખોવાઈ જાય, તો અસુમેળ પ્રતિકૃતિ સિંક્રનસ બની જાય છે.
જો મુખ્ય ડેટાબેઝ ખોવાઈ જાય, તો સિંક્રનસ પ્રતિકૃતિ મુખ્ય ડેટાબેઝ બની જાય છે, અને અસુમેળ પ્રતિકૃતિ સિંક્રનસ પ્રતિકૃતિ બની જાય છે.

શોધ માટે સ્થિતિસ્થાપક શોધ

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

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

[તેઓ, ટેક, ટેક્સ, ટેક્સ્ટ, ટેક્સ્ટ્સ, એક, ભૂતપૂર્વ, એક્સટ, ટેક્સ્ટ્સ, ks, kst, ksty, st, sty, તમે],

અને "ટેક્સ્ટ" શબ્દનું મૂળ પણ સાચવવામાં આવશે. આ અભિગમ તમને શરૂઆતમાં, મધ્યમાં અને શબ્દના અંતે શોધવાની મંજૂરી આપે છે.

સામાન્ય ચિત્ર

લેખની શરૂઆતથી ચિત્રનું પુનરાવર્તન કરો, પરંતુ સ્પષ્ટતા સાથે:

• બેલેન્સર ઇન્ટરનેટ પર ખુલ્લું; અમારી પાસે nginx છે, તે કોઈપણ હોઈ શકે છે.
• જાવા એપ્લિકેશન ઇન્સ્ટન્સ હેઝલકાસ્ટ દ્વારા એકબીજા સાથે વાતચીત કરે છે.
• વેબ સોકેટ સાથે કામ કરવા માટે અમે ઉપયોગ કરીએ છીએ નેટી.
• Java એપ્લિકેશન Java 8 માં લખાયેલ છે અને તેમાં બંડલ્સનો સમાવેશ થાય છે ઓએસજી. યોજનાઓમાં Java 10 માં સ્થળાંતર અને મોડ્યુલોમાં સંક્રમણનો સમાવેશ થાય છે.

વિકાસ અને પરીક્ષણ

SV ના વિકાસ અને પરીક્ષણની પ્રક્રિયામાં, અમે જે ઉત્પાદનોનો ઉપયોગ કરીએ છીએ તેની સંખ્યાબંધ રસપ્રદ સુવિધાઓ મળી.

લોડ પરીક્ષણ અને મેમરી લિક

દરેક SV રિલીઝના પ્રકાશનમાં લોડ પરીક્ષણનો સમાવેશ થાય છે. તે સફળ થાય છે જ્યારે:

• પરીક્ષણ ઘણા દિવસો સુધી કામ કર્યું અને ત્યાં કોઈ સેવા નિષ્ફળતા ન હતી
• મુખ્ય કામગીરી માટે પ્રતિભાવ સમય આરામદાયક થ્રેશોલ્ડ કરતાં વધી ગયો ન હતો
• પાછલા સંસ્કરણની તુલનામાં પ્રદર્શનમાં બગાડ 10% કરતા વધુ નથી

અમે ડેટા સાથે ટેસ્ટ ડેટાબેઝ ભરીએ છીએ - આ કરવા માટે, અમે પ્રોડક્શન સર્વરમાંથી સૌથી વધુ સક્રિય સબ્સ્ક્રાઇબર વિશેની માહિતી પ્રાપ્ત કરીએ છીએ, તેની સંખ્યાને 5 (સંદેશાઓ, ચર્ચાઓ, વપરાશકર્તાઓ) વડે ગુણાકાર કરીએ છીએ અને તે રીતે તેનું પરીક્ષણ કરીએ છીએ.

અમે ત્રણ રૂપરેખાંકનોમાં ક્રિયાપ્રતિક્રિયા સિસ્ટમનું લોડ પરીક્ષણ કરીએ છીએ:

1. તણાવ પરીક્ષણ
2. માત્ર જોડાણો
3. સબ્સ્ક્રાઇબર નોંધણી

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

ઉદાહરણ તરીકે, તણાવ પરીક્ષણનો આ ભાગ આવો દેખાય છે:

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

  • ચેટબોટ સિસ્ટમમાં પ્રવેશે છે (એપ્લિકેશન કોડમાંથી મેસેજિંગનું અનુકરણ કરે છે)
    • ડેટા એક્સચેન્જ માટે નવી ચેનલ બનાવવાની 50% તક છે (ખાસ ચર્ચા)
    • 50% વર્તમાન ચેનલોમાંથી કોઈપણને સંદેશ લખવાની સંભાવના છે

"માત્ર જોડાણો" દૃશ્ય એક કારણસર દેખાયું. એક પરિસ્થિતિ છે: વપરાશકર્તાઓએ સિસ્ટમને કનેક્ટ કરી છે, પરંતુ હજી સુધી તેમાં સામેલ થયા નથી. દરેક વપરાશકર્તા સવારે 09:00 વાગ્યે કમ્પ્યુટર ચાલુ કરે છે, સર્વર સાથે જોડાણ સ્થાપિત કરે છે અને શાંત રહે છે. આ વ્યક્તિઓ ખતરનાક છે, તેમાંના ઘણા છે - તેમની પાસે એકમાત્ર પેકેજ પિંગ/પોંગ છે, પરંતુ તેઓ સર્વર સાથે કનેક્શન રાખે છે (તેઓ તેને ચાલુ રાખી શકતા નથી - જો કોઈ નવો સંદેશ હોય તો શું થશે). પરીક્ષણ એવી પરિસ્થિતિનું પુનઃઉત્પાદન કરે છે જ્યાં મોટી સંખ્યામાં આવા વપરાશકર્તાઓ અડધા કલાકમાં સિસ્ટમમાં લૉગ ઇન કરવાનો પ્રયાસ કરે છે. તે તણાવ પરીક્ષણ જેવું જ છે, પરંતુ તેનું ધ્યાન આ પ્રથમ ઇનપુટ પર ચોક્કસપણે છે - જેથી ત્યાં કોઈ નિષ્ફળતા ન હોય (વ્યક્તિ સિસ્ટમનો ઉપયોગ કરતી નથી, અને તે પહેલેથી જ પડી જાય છે - કંઈક ખરાબ વિશે વિચારવું મુશ્કેલ છે).

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

અમે લોડ જનરેટર તરીકે ઉપયોગ કરીએ છીએ જેમીટર. તે વેબસોકેટ સાથે કેવી રીતે કામ કરવું તે જાણતું નથી; તેને પ્લગઇનની જરૂર છે. "jmeter વેબસોકેટ" ક્વેરી માટે શોધ પરિણામોમાં પ્રથમ છે: BlazeMeter ના લેખો, જે ભલામણ કરે છે Maciej Zaleski દ્વારા પ્લગઇન.

ત્યાંથી જ અમે શરૂ કરવાનું નક્કી કર્યું.

ગંભીર પરીક્ષણ શરૂ કર્યા પછી લગભગ તરત જ, અમે શોધ્યું કે JMeter મેમરી લીક કરવાનું શરૂ કર્યું.

પ્લગઇન એક અલગ મોટી વાર્તા છે; 176 તારાઓ સાથે, તેમાં ગીથબ પર 132 ફોર્ક છે. લેખકે પોતે 2015 થી તેને પ્રતિબદ્ધ કર્યું નથી (અમે તેને 2015 માં લીધું હતું, પછી તે શંકા પેદા કરી ન હતી), મેમરી લિકને લગતી ઘણી ગીથબ સમસ્યાઓ, 7 અનક્લોઝ્ડ પુલ વિનંતીઓ.
જો તમે આ પ્લગઇનનો ઉપયોગ કરીને લોડ પરીક્ષણ કરવાનું નક્કી કરો છો, તો કૃપા કરીને નીચેની ચર્ચાઓ પર ધ્યાન આપો:

1. મલ્ટિ-થ્રેડેડ વાતાવરણમાં, નિયમિત LinkedListનો ઉપયોગ કરવામાં આવ્યો હતો, અને પરિણામ આવ્યું હતું NPE રનટાઇમમાં. આ કાં તો ConcurrentLinkedDeque પર સ્વિચ કરીને અથવા સિંક્રનાઇઝ્ડ બ્લોક્સ દ્વારા ઉકેલી શકાય છે. અમે અમારા માટે પ્રથમ વિકલ્પ પસંદ કર્યો (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. મેમરી લીક; ડિસ્કનેક્ટ કરતી વખતે, કનેક્શન માહિતી કાઢી નાખવામાં આવતી નથી (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. સ્ટ્રીમિંગ મોડમાં (જ્યારે વેબસોકેટ નમૂનાના અંતે બંધ ન હોય, પરંતુ યોજનામાં પાછળથી ઉપયોગમાં લેવાય છે), પ્રતિસાદ પેટર્ન કામ કરતી નથી (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

આ ગીથબ પરના તેમાંથી એક છે. અમે શું કર્યું:

1. લઇ લીધું ફોર્ક Elyran કોગન (@elyrank) - તે 1 અને 3 સમસ્યાઓને ઠીક કરે છે
2. ઉકેલાયેલ સમસ્યા 2
3. 9.2.14 થી 9.3.12 સુધી જેટી અપડેટ કરી
4. થ્રેડલોકલમાં સિમ્પલડેટફોર્મેટ લપેટી; SimpleDateFormat થ્રેડ-સેફ નથી, જે રનટાઇમ પર NPE તરફ દોરી જાય છે
5. બીજી મેમરી લીકને ઠીક કરી (કનેક્શન ડિસ્કનેક્ટ થયું ત્યારે ખોટી રીતે બંધ થયું હતું)

અને છતાં તે વહે છે!

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

બે દિવસ વીતી ગયા...

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

તે બહાર આવ્યું છે કે હેઝલકાસ્ટ 3.4 માં, નકશો / મલ્ટિમેપ (map.destroy()) કાઢી નાખતી વખતે, મેમરી સંપૂર્ણપણે મુક્ત થતી નથી:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

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

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

કૉલ કરો:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

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

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

ચાર્ટમાં સુધારો થયો છે.

લોડ પરીક્ષણ વિશે આપણે બીજું શું શીખ્યા?

1. JSR223 ને ગ્રુવીમાં લખવાની જરૂર છે અને તેમાં કમ્પાઇલેશન કેશ શામેલ છે - તે ખૂબ ઝડપી છે. કડી.
2. Jmeter-Plugins ગ્રાફ પ્રમાણભૂત કરતાં સમજવામાં સરળ છે. કડી.

હેઝલકાસ્ટ સાથેના અમારા અનુભવ વિશે

હેઝલકાસ્ટ અમારા માટે એક નવું ઉત્પાદન હતું, અમે આવૃત્તિ 3.4.1 થી તેની સાથે કામ કરવાનું શરૂ કર્યું, હવે અમારું ઉત્પાદન સર્વર સંસ્કરણ 3.9.2 ચલાવી રહ્યું છે (લેખન સમયે, હેઝલકાસ્ટનું નવીનતમ સંસ્કરણ 3.10 છે).

આઈડી જનરેશન

અમે પૂર્ણાંક ઓળખકર્તાઓ સાથે શરૂઆત કરી. ચાલો કલ્પના કરીએ કે નવી એન્ટિટી માટે આપણને બીજા લાંબાની જરૂર છે. ડેટાબેઝમાં ક્રમ યોગ્ય નથી, કોષ્ટકો શાર્ડિંગમાં સામેલ છે - તે તારણ આપે છે કે DB1 માં એક સંદેશ ID=1 અને DB1 માં એક સંદેશ ID=2 છે, તમે આ ID ને Elasticsearchમાં મૂકી શકતા નથી, ન તો Hazelcast માં , પરંતુ સૌથી ખરાબ બાબત એ છે કે જો તમે બે ડેટાબેઝમાંથી ડેટાને એકમાં જોડવા માંગતા હોવ (ઉદાહરણ તરીકે, આ સબ્સ્ક્રાઇબર્સ માટે એક ડેટાબેઝ પૂરતો છે તે નક્કી કરવું). તમે Hazelcast માં ઘણા AtomicLongs ઉમેરી શકો છો અને ત્યાં એક કાઉન્ટર રાખી શકો છો, પછી નવી ID મેળવવાનું પ્રદર્શન એ incrementAndGet ઉપરાંત Hazelcast ને વિનંતી કરવા માટેનો સમય છે. પરંતુ હેઝલકાસ્ટ પાસે કંઈક વધુ શ્રેષ્ઠ છે - FlakeIdGenerator. દરેક ક્લાયન્ટનો સંપર્ક કરતી વખતે, તેમને ID શ્રેણી આપવામાં આવે છે, ઉદાહરણ તરીકે, પ્રથમ - 1 થી 10 સુધી, બીજી - 000 થી 10 સુધી, અને તેથી વધુ. હવે ક્લાયંટ જ્યાં સુધી તેને જારી કરવામાં આવેલ રેન્જ સમાપ્ત ન થાય ત્યાં સુધી તેની જાતે જ નવા ઓળખકર્તાઓ જારી કરી શકે છે. તે ઝડપથી કાર્ય કરે છે, પરંતુ જ્યારે તમે એપ્લિકેશન (અને હેઝલકાસ્ટ ક્લાયંટ) પુનઃપ્રારંભ કરો છો ત્યારે એક નવો ક્રમ શરૂ થાય છે - તેથી તે છોડે છે, વગેરે. વધુમાં, વિકાસકર્તાઓ ખરેખર સમજી શકતા નથી કે ID શા માટે પૂર્ણાંક છે, પરંતુ તે એટલા અસંગત છે. અમે દરેક વસ્તુનું વજન કર્યું અને UUID પર સ્વિચ કર્યું.

માર્ગ દ્વારા, જેઓ Twitter જેવા બનવા માંગે છે, ત્યાં આવી સ્નોકાસ્ટ લાઇબ્રેરી છે - આ હેઝલકાસ્ટની ટોચ પર સ્નોવફ્લેકનું અમલીકરણ છે. તમે તેને અહીં જોઈ શકો છો:

github.com/noctarius/snowcast
github.com/twitter/snowflake

પરંતુ અમે હવે તેની આસપાસ ગયા નથી.

TransactionalMap.replace

બીજું આશ્ચર્ય: TransactionalMap.replace કામ કરતું નથી. અહીં એક પરીક્ષણ છે:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

મને getForUpdate નો ઉપયોગ કરીને મારું પોતાનું બદલવું લખવું પડ્યું:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

માત્ર નિયમિત ડેટા સ્ટ્રક્ચર્સ જ નહીં, પરંતુ તેમના વ્યવહારિક સંસ્કરણોનું પણ પરીક્ષણ કરો. એવું બને છે કે IMap કામ કરે છે, પરંતુ TransactionalMap હવે અસ્તિત્વમાં નથી.

ડાઉનટાઇમ વિના નવો JAR દાખલ કરો

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

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

ચિતમે:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

બધું કામ કરી રહ્યું છે. પછી અમે આના દ્વારા શોધવા માટે હેઝલકાસ્ટમાં ઇન્ડેક્સ બનાવવાનું નક્કી કર્યું:

map.addIndex("subscriberId", false);

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

IMap. અમે 5000 વસ્તુઓ લખીએ છીએ, તેમને વાંચીએ છીએ. બધું અપેક્ષિત છે.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

પરંતુ તે વ્યવહારમાં કામ કરતું નથી, અમને ClassNotFoundException મળે છે:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 માં, યુઝર ક્લાસ ડિપ્લોયમેન્ટ મિકેનિઝમ દેખાયું. તમે એક માસ્ટર નોડ નિયુક્ત કરી શકો છો અને તેના પર JAR ફાઇલ અપડેટ કરી શકો છો.

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

અમે ઉચ્ચ પ્રદર્શન કેવી રીતે સુનિશ્ચિત કરીએ છીએ

હેઝલકાસ્ટની ચાર સફર - સારી, ડેટાબેઝમાં બે - ખરાબ

ડેટા માટે કેશમાં જવું એ ડેટાબેઝમાં જવા કરતાં હંમેશા વધુ સારું છે, પરંતુ તમે ન વપરાયેલ રેકોર્ડ્સ પણ સંગ્રહિત કરવા માંગતા નથી. અમે વિકાસના છેલ્લા તબક્કા સુધી શું કેશ કરવું તે અંગે નિર્ણય છોડીએ છીએ. જ્યારે નવી કાર્યક્ષમતા કોડેડ કરવામાં આવે છે, ત્યારે અમે PostgreSQL (log_min_duration_statement to 0) માં તમામ ક્વેરીઝનું લોગિંગ ચાલુ કરીએ છીએ અને 20 મિનિટ માટે લોડ પરીક્ષણ ચલાવીએ છીએ. એકત્રિત લૉગ્સનો ઉપયોગ કરીને, pgFouine અને pgBadger જેવી ઉપયોગિતાઓ વિશ્લેષણાત્મક અહેવાલો બનાવી શકે છે. અહેવાલોમાં, અમે મુખ્યત્વે ધીમી અને વારંવારની ક્વેરી શોધીએ છીએ. ધીમી ક્વેરી માટે, અમે એક્ઝેક્યુશન પ્લાન બનાવીએ છીએ (EXPLAIN) અને મૂલ્યાંકન કરીએ છીએ કે આવી ક્વેરી ઝડપી થઈ શકે છે કે કેમ. સમાન ઇનપુટ ડેટા માટે વારંવારની વિનંતીઓ કેશમાં સારી રીતે બંધબેસે છે. અમે પ્રશ્નોને “સપાટ” રાખવાનો પ્રયાસ કરીએ છીએ, ક્વેરી દીઠ એક ટેબલ.

શોષણ

ઓનલાઈન સેવા તરીકે SV 2017 ની વસંતઋતુમાં કાર્યરત કરવામાં આવી હતી, અને એક અલગ ઉત્પાદન તરીકે, SV નવેમ્બર 2017 માં રજૂ કરવામાં આવી હતી (તે સમયે બીટા સંસ્કરણની સ્થિતિમાં).

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

SV સર્વર વિતરણ મૂળ પેકેજોના સ્વરૂપમાં પૂરું પાડવામાં આવે છે: RPM, DEB, MSI. પ્લસ વિન્ડોઝ માટે અમે સિંગલ EXE ના રૂપમાં સિંગલ ઇન્સ્ટોલર પ્રદાન કરીએ છીએ જે એક મશીન પર સર્વર, હેઝલકાસ્ટ અને ઇલાસ્ટિકસર્ચ ઇન્સ્ટોલ કરે છે. અમે શરૂઆતમાં ઇન્સ્ટોલેશનના આ સંસ્કરણને "ડેમો" સંસ્કરણ તરીકે ઓળખાવ્યું હતું, પરંતુ હવે તે સ્પષ્ટ થઈ ગયું છે કે આ સૌથી લોકપ્રિય જમાવટ વિકલ્પ છે.

સોર્સ: www.habr.com