મિખાઇલ સલોસિન. ગોલાંગ મીટઅપ. લૂક+ એપ્લિકેશનના બેકએન્ડમાં ગોનો ઉપયોગ કરવો

મિખાઇલ સલોસિન (ત્યારબાદ - એમએસ): - કેમ છો બધા! મારું નામ માઈકલ છે. હું MC2 સોફ્ટવેરમાં બેકએન્ડ ડેવલપર તરીકે કામ કરું છું અને હું લૂક+ મોબાઇલ એપ્લિકેશનના બેકએન્ડમાં ગોનો ઉપયોગ કરવા વિશે વાત કરીશ.

શું અહીં કોઈને હોકી ગમે છે?

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

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

તમે વિકાસમાં શું ઉપયોગ કર્યો?

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

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

સિસ્ટમ API પરીક્ષણો માટે, અમે Python unittest નો ઉપયોગ કર્યો. Memcached નો ઉપયોગ API પેમેન્ટ કોલ્સ થ્રોટલ કરવા માટે થાય છે, "શેફ" નો ઉપયોગ રૂપરેખાંકનને નિયંત્રિત કરવા માટે થાય છે, Zabbix નો ઉપયોગ આંતરિક સિસ્ટમ આંકડા એકત્રિત કરવા અને તેનું નિરીક્ષણ કરવા માટે થાય છે. ગ્રેલોગ2 એ લૉગ્સ એકત્રિત કરવા માટે છે, સ્લેટ ક્લાયન્ટ્સ માટે API દસ્તાવેજીકરણ છે.

પ્રોટોકોલ પસંદગી

અમે જે પ્રથમ સમસ્યાનો સામનો કર્યો: અમારે નીચેના મુદ્દાઓના આધારે બેકએન્ડ અને મોબાઇલ ક્લાયંટ વચ્ચે ક્રિયાપ્રતિક્રિયા માટે પ્રોટોકોલ પસંદ કરવાની જરૂર હતી...

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

આના આધારે, અમારી પાસે બે પ્રોટોકોલ વિકલ્પો હતા:

1. વેબસોકેટ્સ. પરંતુ અમને ક્લાયંટથી સર્વર સુધીની ચેનલોની જરૂર નથી. અમારે ફક્ત સર્વરથી ક્લાયંટને અપડેટ્સ મોકલવાની જરૂર હતી, તેથી વેબસોકેટ એ એક નિરર્થક વિકલ્પ છે.
2. સર્વર-સેંટ ઇવેન્ટ્સ (SSE) બરાબર આવી! તે એકદમ સરળ છે અને મૂળભૂત રીતે આપણને જોઈતી દરેક વસ્તુને સંતોષે છે.

સર્વર દ્વારા મોકલેલ ઇવેન્ટ્સ

આ વસ્તુ કેવી રીતે કામ કરે છે તેના વિશે થોડાક શબ્દો...

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

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

હવે ચાલો વાત કરીએ કે ક્રિયાપ્રતિક્રિયા પોતે કેવી રીતે કાર્ય કરે છે.

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

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

લાઇવ કનેક્શન કેવી રીતે સર્વિસ કરવામાં આવે છે?

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

અમે જે પ્રથમ સમસ્યાનો સામનો કરવો પડ્યો તે નીચે મુજબ હતો: ક્લાયંટ સાથે ખોલવામાં આવેલા દરેક કનેક્શન માટે, અમે એક ટાઈમર બનાવ્યું જે દર 15 સેકન્ડમાં એક વાર ટિક કરે છે - તે તારણ આપે છે કે જો અમારી પાસે એક મશીન (એક API સર્વર સાથે) સાથે 6 હજાર કનેક્શન્સ ખુલ્લા હોય, તો 6. હજાર ટાઈમર બનાવવામાં આવ્યા હતા. આના કારણે મશીન જરૂરી લોડને પકડી શકતું ન હતું. સમસ્યા અમારા માટે એટલી સ્પષ્ટ ન હતી, પરંતુ અમને થોડી મદદ મળી અને તેને ઠીક કરી.

પરિણામે, હવે આપણું પિંગ એ જ ચેનલમાંથી આવે છે જેમાંથી અપડેટ આવે છે.

તદનુસાર, ત્યાં માત્ર એક જ ટાઈમર છે જે દર 15 સેકન્ડમાં એક વાર ટિક કરે છે.

અહીં ઘણા સહાયક કાર્યો છે - હેડર, પિંગ અને સ્ટ્રક્ચર પોતે મોકલવું. એટલે કે, ટેબલનું નામ (વ્યક્તિ, મેચ, સિઝન) અને આ એન્ટ્રી વિશેની માહિતી અહીં પ્રસારિત કરવામાં આવે છે:

અપડેટ્સ મોકલવા માટેની પદ્ધતિ

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

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

PostgreSQL: સાંભળો/સૂચિત કરો

Postgres માં Listen/Notify મિકેનિઝમ તમને ઇવેન્ટ સબ્સ્ક્રાઇબર્સને સૂચિત કરવાની મંજૂરી આપે છે કે કેટલીક ઇવેન્ટ બદલાઈ ગઈ છે - ડેટાબેઝમાં કેટલાક રેકોર્ડ બનાવવામાં આવ્યા છે. આ કરવા માટે, અમે એક સરળ ટ્રિગર અને ફંક્શન લખ્યું:

રેકોર્ડ દાખલ કરતી વખતે અથવા બદલતી વખતે, અમે ડેટા_અપડેટ્સ ચેનલ પર સૂચના કાર્યને કૉલ કરીએ છીએ, ત્યાં કોષ્ટકનું નામ અને બદલાયેલ અથવા દાખલ કરાયેલ રેકોર્ડના ઓળખકર્તાને પસાર કરીએ છીએ.

ક્લાયંટ સાથે સિંક્રનાઇઝ થનારી તમામ કોષ્ટકો માટે, અમે ટ્રિગરને વ્યાખ્યાયિત કરીએ છીએ, જે રેકોર્ડને બદલ્યા/અપડેટ કર્યા પછી, નીચેની સ્લાઇડ પર દર્શાવેલ ફંક્શનને કૉલ કરે છે.
API આ ફેરફારો માટે કેવી રીતે સબ્સ્ક્રાઇબ કરે છે?

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

અહીં પ્રમાણભૂત pq લાઇબ્રેરી, જે ડેટાબેઝ સાથે જોડાય છે અને કહે છે કે તે ચેનલ (ડેટા_અપડેટ્સ) સાંભળવા માંગે છે, તપાસે છે કે કનેક્શન ખુલ્લું છે અને બધું બરાબર છે. હું જગ્યા બચાવવા માટે ભૂલ તપાસવાનું છોડી રહ્યો છું (તપાસ ન કરવું જોખમી છે).

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

ફેન-આઉટ કેવી રીતે કાર્ય કરે છે?

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

તે Go માં કેવી રીતે લાગુ થાય છે:

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

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

ત્યાં એક સબ્સ્ક્રાઇબ પદ્ધતિ પણ છે જે ચેનલને "શ્રોતાઓ" માં ઉમેરે છે:

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

પ્રશ્ન: - આ ચેનલ દ્વારા શું પ્રસારિત થાય છે?

MS: - મોડલ કે જે બદલાયું છે અથવા પિંગ ટ્રાન્સમિટ થાય છે (આવશ્યક રીતે માત્ર એક સંખ્યા, પૂર્ણાંક).

MS: - તમે કંઈપણ મોકલી શકો છો, કોઈપણ માળખું મોકલી શકો છો, તેને પ્રકાશિત કરી શકો છો - તે ફક્ત JSON માં ફેરવાય છે અને બસ.

MS: - અમને પોસ્ટગ્રેસ તરફથી સૂચના પ્રાપ્ત થાય છે - તેમાં કોષ્ટકનું નામ અને ઓળખકર્તા છે. કોષ્ટકના નામ અને ઓળખકર્તાના આધારે, અમને જરૂરી રેકોર્ડ મળે છે, અને પછી અમે આ માળખું પ્રકાશન માટે મોકલીએ છીએ.

ઈન્ફ્રાસ્ટ્રક્ચર

ઇન્ફ્રાસ્ટ્રક્ચરના પરિપ્રેક્ષ્યમાં આ શું દેખાય છે? અમારી પાસે 7 હાર્ડવેર સર્વર છે: તેમાંથી એક સંપૂર્ણપણે ડેટાબેઝને સમર્પિત છે, અન્ય છ વર્ચ્યુઅલ મશીનો ચલાવે છે. API ની 6 નકલો છે: API સાથેની દરેક વર્ચ્યુઅલ મશીન અલગ હાર્ડવેર સર્વર પર ચાલે છે - આ વિશ્વસનીયતા માટે છે.

ઍક્સેસિબિલિટી સુધારવા માટે અમારી પાસે Keepalived સાથે બે ફ્રન્ટએન્ડ્સ ઇન્સ્ટોલ કરેલા છે, જેથી જો કંઈક થાય, તો એક ફ્રન્ટએન્ડ બીજાને બદલી શકે. પણ - CMS ની બે નકલો.

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

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

ગોના ગુણ

અમે આ એપ્લિકેશન પર કામ કર્યા પછી, Go ના આવા સ્પષ્ટ ફાયદાઓ બહાર આવ્યા.

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

અમે વિકાસકર્તાઓ શોધી રહ્યા છીએ! જો કોઈ ઈચ્છે છે, તો કૃપા કરીને.

પ્રશ્નો

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

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

IN: - શું તરત જ સાંભળવા/સૂચિત કરવા માટે રેકોર્ડ મોકલવાનું શક્ય નથી, અને ઓળખકર્તા ટેબલને નહીં?

MS: - તે મોકલે છે તે પ્રીલોડ પર Listen/Notify ની મર્યાદા 8 હજાર બાઇટ્સ છે. સૈદ્ધાંતિક રીતે, જો આપણે થોડી માત્રામાં ડેટા સાથે વ્યવહાર કરતા હોઈએ તો તે મોકલવું શક્ય બનશે, પરંતુ મને લાગે છે કે આ રીતે [આપણે તે કરીએ છીએ] તે વધુ વિશ્વસનીય છે. મર્યાદાઓ પોસ્ટગ્રેસમાં જ છે.

IN: - શું ગ્રાહકોને એવી મેચો વિશે અપડેટ મળે છે જેમાં તેઓને રસ નથી?

MS: - સામાન્ય રીતે, હા. નિયમ પ્રમાણે, ત્યાં 2-3 મેચો સમાંતર ચાલે છે, અને તે પછી પણ ભાગ્યે જ. જો કોઈ ક્લાયંટ કંઈક જોઈ રહ્યો હોય, તો તે સામાન્ય રીતે તે મેચ જોઈ રહ્યો છે જે ચાલી રહી છે. પછી, ક્લાયંટ પાસે એક સ્થાનિક ડેટાબેઝ છે જેમાં આ તમામ અપડેટ્સ ઉમેરવામાં આવે છે, અને ઇન્ટરનેટ કનેક્શન વિના પણ, ક્લાયન્ટ ભૂતકાળની બધી મેચ જોઈ શકે છે જેના માટે તેની પાસે અપડેટ્સ છે. આવશ્યકપણે, અમે સર્વર પર અમારા ડેટાબેઝને ક્લાયંટના સ્થાનિક ડેટાબેઝ સાથે સિંક્રનાઇઝ કરીએ છીએ જેથી કરીને તે ઑફલાઇન કામ કરી શકે.

IN: - તમે તમારું પોતાનું ORM કેમ બનાવ્યું?

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

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

IN: - કેટલા લોકોએ ભાગ લીધો?

MS: - પ્રારંભિક તબક્કે, બે લોકોએ ભાગ લીધો હતો. અમે જૂનમાં ક્યાંક શરૂ કર્યું, અને ઓગસ્ટમાં મુખ્ય ભાગ તૈયાર થઈ ગયો (પ્રથમ સંસ્કરણ). સપ્ટેમ્બરમાં રિલીઝ થઈ હતી.

IN: - જ્યાં તમે SSEનું વર્ણન કરો છો, ત્યાં તમે સમયસમાપ્તિનો ઉપયોગ કરતા નથી. તે શા માટે છે?

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

IN: - તમે કઈ વધારાની ઉપયોગિતાઓનો ઉપયોગ કર્યો?

MS: - અમે સૌથી વધુ સક્રિય રીતે ગોવેટ અને ગોલિન્ટનો ઉપયોગ શૈલીને એકીકૃત બનાવવા માટે, તેમજ gofmt. બીજું કંઈ વપરાયું ન હતું.

IN: - તમે ડીબગ કરવા માટે શું ઉપયોગ કર્યો?

MS: - ડીબગીંગ મોટાભાગે પરીક્ષણોનો ઉપયોગ કરીને હાથ ધરવામાં આવ્યું હતું. અમે કોઈપણ ડીબગર અથવા GOP નો ઉપયોગ કર્યો નથી.

IN: - શું તમે સ્લાઇડ પરત કરી શકો છો જ્યાં પબ્લિશ ફંક્શન લાગુ કરવામાં આવ્યું છે? શું સિંગલ-લેટર વેરિયેબલ નામો તમને મૂંઝવણમાં મૂકે છે?

MS: - ના. તેમની પાસે દૃશ્યતાનો એકદમ "સંકુચિત" અવકાશ છે. તેઓ અહીં સિવાય બીજે ક્યાંય ઉપયોગમાં લેવાતા નથી (આ વર્ગના આંતરિક સિવાય), અને તે ખૂબ જ કોમ્પેક્ટ છે - તે ફક્ત 7 લીટીઓ લે છે.

IN: - કોઈક રીતે તે હજી પણ સાહજિક નથી ...

MS: - ના, ના, આ એક વાસ્તવિક કોડ છે! તે શૈલી વિશે નથી. તે માત્ર એક ઉપયોગિતાવાદી, ખૂબ જ નાનો વર્ગ છે - વર્ગની અંદર માત્ર 3 ક્ષેત્રો...

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

IN: - શું ત્યાં કોઈ તૃતીય-પક્ષ નિર્ભરતા વ્યવસ્થાપન પેકેજો છે?

MS: - અમે ગો ડેપનો ઉપયોગ કર્યો.

IN: - રિપોર્ટના વિષયમાં વિડિઓ વિશે કંઈક હતું, પરંતુ વિડિઓ વિશેના અહેવાલમાં કંઈ નહોતું.

MS: - ના, મારી પાસે વિડિઓ વિશેના વિષયમાં કંઈ નથી. તેને "લુક+" કહેવામાં આવે છે - તે એપ્લિકેશનનું નામ છે.

IN: - તમે કહ્યું કે તે ગ્રાહકોને સ્ટ્રીમ કરવામાં આવે છે? ..

MS: - અમે વિડિઓ સ્ટ્રીમિંગમાં સામેલ ન હતા. આ સંપૂર્ણપણે મેગાફોન દ્વારા કરવામાં આવ્યું હતું. હા, મેં કહ્યું નથી કે એપ્લિકેશન મેગાફોન હતી.

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

કેટલીક જાહેરાતો 🙂

અમારી સાથે રહેવા બદલ આભાર. શું તમને અમારા લેખો ગમે છે? વધુ રસપ્રદ સામગ્રી જોવા માંગો છો? ઓર્ડર આપીને અથવા મિત્રોને ભલામણ કરીને અમને ટેકો આપો, $4.99 થી વિકાસકર્તાઓ માટે ક્લાઉડ VPS, એન્ટ્રી-લેવલ સર્વર્સનું એક અનન્ય એનાલોગ, જેની શોધ અમારા દ્વારા તમારા માટે કરવામાં આવી છે: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps વિશેનું સંપૂર્ણ સત્ય $19 થી અથવા સર્વર કેવી રીતે શેર કરવું? (RAID1 અને RAID10 સાથે ઉપલબ્ધ, 24 કોરો સુધી અને 40GB DDR4 સુધી).

એમ્સ્ટરડેમમાં ઇક્વિનિક્સ ટાયર IV ડેટા સેન્ટરમાં ડેલ R730xd 2 ગણું સસ્તું? માત્ર અહીં 2 x ઇન્ટેલ ટેટ્રાડેકા-કોર Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ટીવી $199 થી નેધરલેન્ડમાં! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 થી! વિશે વાંચો ઇન્ફ્રાસ્ટ્રક્ચર કોર્પોરેશન કેવી રીતે બનાવવું. ડેલ R730xd E5-2650 v4 સર્વર્સના ઉપયોગ સાથેનો વર્ગ એક પેની માટે 9000 યુરોના મૂલ્યના છે?

સોર્સ: www.habr.com