મોસ્કો એક્સચેન્જની ટ્રેડિંગ અને ક્લિયરિંગ સિસ્ટમના આર્કિટેક્ચરની ઉત્ક્રાંતિ. ભાગ 1

કેમ છો બધા! મારું નામ સેર્ગેઈ કોસ્તાનબાઈવ છે, એક્સચેન્જમાં હું ટ્રેડિંગ સિસ્ટમનો મુખ્ય વિકાસ કરી રહ્યો છું.

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

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

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

થોડો ઇતિહાસ

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

તે વર્ષોમાં, એક્સચેન્જ સિસ્ટમ હાઇ-એન્ડ હાર્ડવેર પર કામ કરતી હતી - અલ્ટ્રા-વિશ્વસનીય HP સુપરડોમ 9000 સર્વર્સ (આના પર બિલ્ટ પીએ-આરઆઈએસસી), જેમાં સંપૂર્ણપણે બધું ડુપ્લિકેટ કરવામાં આવ્યું હતું: ઇનપુટ/આઉટપુટ સબસિસ્ટમ્સ, નેટવર્ક, RAM (હકીકતમાં, RAM નો RAID એરે હતો), પ્રોસેસર્સ (હોટ-સ્વેપેબલ). મશીનને રોક્યા વિના કોઈપણ સર્વર ઘટકને બદલવું શક્ય હતું. અમે આ ઉપકરણો પર આધાર રાખ્યો અને તેમને વર્ચ્યુઅલ રીતે નિષ્ફળ-સલામત માન્યા. ઓપરેટિંગ સિસ્ટમ યુનિક્સ જેવી HP UX સિસ્ટમ હતી.

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

જૂના આર્કિટેક્ચર અને સાધનો સાથે આવા ભારનો સામનો કરવો અશક્ય હતું. કોઈક રીતે અનુકૂલન કરવું જરૂરી હતું.

શરૂઆત

વિનિમય સિસ્ટમની વિનંતીઓને બે પ્રકારમાં વિભાજિત કરી શકાય છે:

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

યોજનાકીય રીતે, સિસ્ટમના મૂળને ત્રણ સ્તરોમાં વિભાજિત કરી શકાય છે:

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

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

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

સિસ્ટમના પ્રથમ સંસ્કરણમાં ગેટવેના બે સ્તર અને ટ્રેડિંગ સિસ્ટમનું કેન્દ્રિય સર્વર હતું. કામનો પ્રવાહ આના જેવો હતો:

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

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

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

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

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

પ્રથમ આધુનિકીકરણ

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

ઉચ્ચ આવર્તન ટ્રેડિંગની અસર

આર્કિટેક્ચરનું ઉપરનું સંસ્કરણ 2010 સુધી અસ્તિત્વમાં હતું. દરમિયાન, અમે HP સુપરડોમ સર્વર્સના પ્રદર્શનથી સંતુષ્ટ નહોતા. વધુમાં, PA-RISC આર્કિટેક્ચર વર્ચ્યુઅલ રીતે મૃત હતું; વિક્રેતાએ કોઈ નોંધપાત્ર અપડેટ્સ ઓફર કર્યા ન હતા. પરિણામે, અમે HP UX/PA RISC માંથી Linux/x86 પર જવાનું શરૂ કર્યું. એક્સેસ સર્વરના અનુકૂલન સાથે સંક્રમણની શરૂઆત થઈ.

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

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

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

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

ઉત્ક્રાંતિનો નવો રાઉન્ડ

વ્યાપક પરીક્ષણ અને સંશોધન પછી, અમે રીઅલ-ટાઇમ ઑપરેટિંગ સિસ્ટમ કર્નલ પર સ્વિચ કર્યું. આ માટે અમે RedHat Enterprise MRG Linux ને પસંદ કર્યું છે, જ્યાં MRG નો અર્થ મેસેજિંગ રીઅલ-ટાઇમ ગ્રીડ છે. રીઅલ-ટાઇમ પેચનો ફાયદો એ છે કે તેઓ શક્ય તેટલા ઝડપી અમલ માટે સિસ્ટમને ઑપ્ટિમાઇઝ કરે છે: બધી પ્રક્રિયાઓ FIFO કતારમાં ગોઠવવામાં આવે છે, કોરોને અલગ કરી શકાય છે, કોઈ ઇજેક્શન નથી, બધા વ્યવહારો કડક ક્રમમાં પ્રક્રિયા કરવામાં આવે છે.

લાલ - નિયમિત કર્નલમાં કતાર સાથે કામ કરવું, લીલો - રીઅલ-ટાઇમ કર્નલમાં કામ કરવું.

પરંતુ નિયમિત સર્વર પર ઓછી વિલંબતા પ્રાપ્ત કરવી એટલી સરળ નથી:

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

મારે કહેવું જ જોઇએ કે રીઅલટાઇમ પ્રોસેસિંગ માટે Linux હાર્ડવેર અને કર્નલ સેટ કરવાનો વિષય એક અલગ લેખને પાત્ર છે. અમે સારું પરિણામ પ્રાપ્ત કરતા પહેલા પ્રયોગ અને સંશોધન કરવામાં ઘણો સમય પસાર કર્યો.

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

x86 પર સ્વિચ કર્યા પછી, પ્રદર્શન લગભગ ત્રણ ગણું વધ્યું, સરેરાશ વ્યવહાર પ્રક્રિયા સમય ઘટીને 60 μs થયો.

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

હોટ અનામત મહાકાવ્ય

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

આ ઉપરાંત, અન્ય આવશ્યકતાઓ હતી:

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

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

પરિણામે, અમે નીચેની યોજના પર આવ્યા:

• મુખ્ય સર્વર ગેટવે સર્વર્સ સાથે સીધો સંપર્ક કરે છે.
• મુખ્ય સર્વર પર પ્રાપ્ત થયેલા તમામ વ્યવહારો એક અલગ ચેનલ દ્વારા બેકઅપ સર્વર પર તરત જ નકલ કરવામાં આવ્યા હતા. આર્બિટર (રાજ્યપાલ) જો કોઈ સમસ્યા ઊભી થાય તો સ્વિચિંગનું સંકલન કરે છે.

  

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

આ યોજના નીચે મુજબ કામ કરતી હતી.

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

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

ચાલુ રાખવા માટે.

સોર્સ: www.habr.com