මිහායිල් සලෝසින් (මෙතැන් සිට - MS): - ආයුබෝවන් සියල්ලටම! මගේ නම මයිකල්. මම MC2 මෘදුකාංගයේ පසුබිම් සංවර්ධකයෙකු ලෙස වැඩ කරන අතර, මම Look+ ජංගම යෙදුමේ පසු අන්තයේ Go භාවිතා කිරීම ගැන කතා කරමි.
මෙතන ඉන්න කවුරුහරි හොකී වලට කැමතිද?
එවිට මෙම යෙදුම ඔබ සඳහා වේ. එය ඇන්ඩ්‍රොයිඩ් සහ iOS සඳහා වන අතර විවිධ ක්‍රීඩා ඉසව් අන්තර්ජාලය හරහා විකාශනය කිරීමට සහ පටිගත කිරීමට භාවිතා කරයි. යෙදුමේ විවිධ සංඛ්‍යාලේඛන, පෙළ විකාශන, සම්මන්ත්‍රණ සඳහා වගු, තරඟාවලි සහ රසිකයින්ට ප්‍රයෝජනවත් වෙනත් තොරතුරු ද අඩංගු වේ.
යෙදුමේ වීඩියෝ අවස්ථා වැනි දෙයක් තිබේ, එනම් ඔබට තරඟවල වැදගත්ම අවස්ථා (ඉලක්ක, සටන්, වෙඩි තැබීම් ආදිය) නැරඹිය හැකිය. ඔබට සම්පූර්ණ විකාශනය නැරඹීමට අවශ්ය නැතිනම්, ඔබට නැරඹිය හැක්කේ වඩාත් රසවත් ඒවා පමණි.
සංවර්ධනයේදී ඔබ භාවිතා කළේ කුමක්ද?
ප්රධාන කොටස ලිව්වේ Go වලින්. ජංගම සේවාලාභීන් සන්නිවේදනය කළ API Go හි ලියා ඇත. ජංගම දුරකථන වෙත තල්ලු දැනුම්දීම් යැවීමේ සේවාවක් ද Go හි ලියා ඇත. අපිට අපේම ORM එකක් ලියන්නත් සිද්ධ වුණා, ඒක අපි කවදා හරි කතා කරන්න පුළුවන්. හොඳයි, සමහර කුඩා සේවාවන් Go හි ලියා ඇත: සංස්කාරකවරුන් සඳහා රූප ප්‍රමාණය වෙනස් කිරීම සහ පූරණය කිරීම...
අපි PostgreSQL දත්ත ගබඩාව ලෙස භාවිතා කළෙමු. සංස්කාරක අතුරුමුහුණත Ruby on Rails හි ActiveAdmin මැණික් භාවිතයෙන් ලියා ඇත. සංඛ්‍යාලේඛන සපයන්නෙකුගෙන් සංඛ්‍යාලේඛන ආනයනය කිරීම ද Ruby හි ලියා ඇත.
පද්ධති API පරීක්ෂණ සඳහා, අපි Python unittest භාවිතා කළෙමු. Memcached API ගෙවීම් ඇමතුම් අවහිර කිරීමට භාවිතා කරයි, "Chef" වින්‍යාසය පාලනය කිරීමට භාවිතා කරයි, Zabbix අභ්‍යන්තර පද්ධති සංඛ්‍යාලේඛන එකතු කිරීමට සහ අධීක්ෂණය කිරීමට භාවිතා කරයි. Graylog2 යනු ලඝු-සටහන් එකතු කිරීම සඳහා වන අතර, Slate යනු සේවාලාභීන් සඳහා API ලියකියවිලි වේ.
ප්රොටෝකෝලය තේරීම
අප මුහුණ දුන් පළමු ගැටළුව: පහත කරුණු මත පදනම්ව, පසුපෙළ සහ ජංගම සේවාලාභීන් අතර අන්තර්ක්‍රියා සඳහා ප්‍රොටෝකෝලයක් තෝරා ගැනීමට අපට අවශ්ය විය...
- වැදගත්ම අවශ්‍යතාවය: සේවාදායකයින් පිළිබඳ දත්ත තත්‍ය කාලීනව යාවත්කාලීන කළ යුතුය. එනම්, දැනට විකාශනය නරඹන සෑම කෙනෙකුටම ක්ෂණිකව පාහේ යාවත්කාලීනයන් ලැබිය යුතුය.
- දේවල් සරල කිරීම සඳහා, අපි සේවාදායකයින් සමඟ සමමුහුර්ත කර ඇති දත්ත මකා නොදමනු ඇතැයි උපකල්පනය කළෙමු, නමුත් විශේෂ කොඩි භාවිතයෙන් සඟවා ඇත.
- සියලුම ආකාරයේ දුර්ලභ ඉල්ලීම් (සංඛ්‍යාලේඛන, කණ්ඩායම් සංයුතිය, කණ්ඩායම් සංඛ්‍යාලේඛන වැනි) සාමාන්‍ය GET ඉල්ලීම් මගින් ලබා ගනී.
- ඊට අමතරව, පද්ධතියට එකවර පරිශීලකයින් 100 කට පහසුවෙන් සහාය වීමට සිදු විය.
මේ මත පදනම්ව, අපට ප්‍රොටෝකෝල විකල්ප දෙකක් තිබුණි:
- වෙබ්සොකට්. නමුත් අපට සේවාදායකයාගෙන් සේවාදායකයට නාලිකා අවශ්ය නොවීය. අපට අවශ්ය වූයේ සේවාදායකයෙන් සේවාදායකයාට යාවත්කාලීන යැවීමට පමණි, එබැවින් වෙබ්සොකට් යනු අතිරික්ත විකල්පයකි.
- Server-Sent Events (SSE) හරියටම ආවා! එය තරමක් සරල වන අතර මූලික වශයෙන් අපට අවශ්ය සියල්ල තෘප්තිමත් කරයි.
සේවාදායකය-යවන ලද සිදුවීම්
මෙය ක්‍රියාත්මක වන ආකාරය ගැන වචන කිහිපයක්...
එය http සම්බන්ධතාවයක් මත ක්‍රියාත්මක වේ. සේවාලාභියා ඉල්ලීමක් යවයි, සේවාදායකය අන්තර්ගතය-වර්ගය: පෙළ/සිදුවීම්-ප්‍රවාහය සමඟ ප්‍රතිචාර දක්වයි සහ සේවාලාභියා සමඟ සම්බන්ධතාව වසා නොගනියි, නමුත් සම්බන්ධතාවයට දත්ත ලිවීම දිගටම කරගෙන යයි:
ගනුදෙනුකරුවන් සමඟ එකඟ වූ ආකෘතියකින් දත්ත යැවිය හැක. අපගේ නඩුවේදී, අපි එය මෙම පෝරමයට යවා ඇත: වෙනස් කළ ව්‍යුහයේ නම (පුද්ගලයා, ක්‍රීඩකයා) සිදුවීම් ක්ෂේත්‍රයට යවන ලද අතර, ක්‍රීඩකයා සඳහා නව, වෙනස් කළ ක්ෂේත්‍ර සහිත JSON දත්ත ක්ෂේත්‍රයට යවන ලදි.
දැන් අපි කතා කරමු අන්තර්ක්‍රියාවම ක්‍රියාත්මක වන ආකාරය ගැන.
- සේවාලාභියා කරන පළමු දෙය නම් සේවාව සමඟ අවසන් වරට සමමුහුර්ත කිරීම සිදු කළ කාලය තීරණය කිරීමයි: එය එහි දේශීය දත්ත ගබඩාව දෙස බලා එය විසින් අවසන් වරට වෙනස් කළ දිනය තීරණය කරයි.
- එය මෙම දිනය සමඟ ඉල්ලීමක් යවයි.
- ප්‍රතිචාරයක් වශයෙන්, එදින සිට සිදු වූ සියලුම යාවත්කාලීන කිරීම් අපි ඔහුට යවන්නෙමු.
- ඊට පසු, එය සජීවී නාලිකාවට සම්බන්ධයක් ඇති කරන අතර එයට මෙම යාවත්කාලීන අවශ්ය වන තෙක් වසා නොයනු ඇත:
අපි ඔහුට වෙනස්කම් ලැයිස්තුවක් යවමු: යමෙකු ගෝලයක් ලබා ගන්නේ නම්, අපි තරඟයේ ලකුණු වෙනස් කරමු, ඔහු ආබාධයකට ලක් වුවහොත්, මෙයද තථ්‍ය කාලය තුළ යවනු ලැබේ. මේ අනුව, ගැලපුම් සිදුවීම් සංග්‍රහය තුළ ගනුදෙනුකරුවන්ට ක්ෂණිකව යාවත්කාලීන දත්ත ලැබේ. වරින් වර, සේවාදායකයා මිය ගොස් නැති බවත්, එයට කිසිවක් සිදු නොවූ බවත්, අපි සෑම තත්පර 15 කට වරක් වේලා මුද්‍රාවක් යවමු - එවිට සෑම දෙයක්ම පිළිවෙලට ඇති බවත් නැවත සම්බන්ධ වීමට අවශ්ය නොවන බවත් එය දැනගත හැකිය.
සජීවී සම්බන්ධතාවය සේවා කරන්නේ කෙසේද?
- පළමුවෙන්ම, අපි නාලිකාවක් සාදන්නෙමු, එහි බෆර කළ යාවත්කාලීන ලැබෙනු ඇත.
- ඊට පසු, යාවත්කාලීන ලබා ගැනීමට අපි මෙම නාලිකාවට දායක වන්නෙමු.
- අපි නිවැරදි ශීර්ෂකය සකසමු එවිට සේවාදායකයාට සියල්ල හරි බව දැන ගන්න.
- පළමු පිං එක යවන්න. අපි සරලව වත්මන් සම්බන්ධතා කාල මුද්රාව සටහන් කරමු.
- ඊට පසු, යාවත්කාලීන නාලිකාව වසා දමන තුරු අපි නාලිකාවෙන් ලූප් එකකින් කියවමු. නාලිකාවට වරින් වර වත්මන් වේලා මුද්රාව හෝ සම්බන්ධතා විවෘත කිරීමට අප දැනටමත් ලියන වෙනස්කම් ලැබේ.
අපට හමු වූ පළමු ගැටළුව වූයේ: සේවාදායකයා සමඟ විවෘත කරන ලද සෑම සම්බන්ධතාවයක් සඳහාම, අපි සෑම තත්පර 15 කට වරක් සලකුණු කරන ටයිමරයක් නිර්මාණය කළෙමු - එයින් පෙනී යන්නේ අපට එක් යන්ත්‍රයකින් (එක් API සේවාදායකයක් සමඟ) සම්බන්ධතා 6 ක් විවෘත කර ඇත්නම්, 6 ටයිමර් දහසක් නිර්මාණය කරන ලදී. මෙය යන්ත්‍රය අවශ්ය බර රඳවා නොගැනීමට හේතු විය. ගැටලුව අපට එතරම් පැහැදිලිව පෙනෙන්නට නොතිබුණත්, අපි කුඩා උපකාරයක් ලබාගෙන එය විසඳා ගත්තෙමු.
ඒක නිසා දැන් අපේ ping එක එන්නේ update එන channel එකෙන්මයි.
ඒ අනුව තත්පර 15කට වරක් ටික් කරන ටයිමරය ඇත්තේ එකකි.
මෙහි සහායක කාර්යයන් කිහිපයක් තිබේ - ශීර්ෂකය, පිං සහ ව්යුහයම යැවීම. එනම්, මේසයේ නම (පුද්ගලයා, තරගය, වාරය) සහ මෙම ප්‍රවේශය පිළිබඳ තොරතුරු මෙහි සම්ප්රේෂණය වේ:
යාවත්කාලීන යැවීමේ යාන්ත්‍රණය
දැන් වෙනස්කම් පැමිණෙන්නේ කොහෙන්ද යන්න ගැන ටිකක්. තථ්‍ය කාලය තුළ විකාශනය නරඹන කිහිප දෙනෙක්, සංස්කාරකවරුන්, අප සතුව ඇත. ඔවුන් සියලු සිදුවීම් නිර්මාණය කරයි: යමෙකු පිටත් කර යවා ඇත, යමෙකු තුවාල ලැබීය, යම් ආකාරයක ආදේශනයක් ...
CMS භාවිතයෙන්, දත්ත දත්ත සමුදායට ඇතුල් වේ. මෙයින් පසු, දත්ත සමුදාය API සේවාදායකයන්ට මේ පිළිබඳව Listen/Notify යාන්ත්‍රණය භාවිතයෙන් දැනුම් දෙයි. API සේවාදායකයන් දැනටමත් මෙම තොරතුරු සේවාදායකයින් වෙත යවයි. මේ අනුව, අපට අත්‍යවශ්‍යයෙන්ම දත්ත සමුදායට සම්බන්ධ කර ඇත්තේ සේවාදායකයන් කිහිපයක් පමණක් වන අතර දත්ත සමුදාය මත විශේෂ බරක් නොමැත, මන්ද සේවාදායකයා කිසිදු ආකාරයකින් දත්ත සමුදාය සමඟ කෙලින්ම අන්තර්ක්‍රියා නොකරන බැවිනි:
PostgreSQL: සවන් දෙන්න/දැන දෙන්න
Postgres හි Listen/Notify යාන්ත්‍රණය මඟින් යම් සිදුවීමක් වෙනස් වී ඇති බව සිදුවීම් ග්‍රාහකයින්ට දැනුම් දීමට ඔබට ඉඩ සලසයි - දත්ත සමුදායේ යම් වාර්තාවක් නිර්මාණය කර ඇත. මෙය සිදු කිරීම සඳහා, අපි සරල ප්‍රේරකයක් සහ කාර්යයක් ලිව්වෙමු:
වාර්තාවක් ඇතුළත් කිරීමේදී හෝ වෙනස් කිරීමේදී, අපි දත්ත_යාවත්කාලීන නාලිකාවේ දැනුම්දීමේ ශ්‍රිතය ලෙස හඳුන්වනු ලබන අතර, වෙනස් කළ හෝ ඇතුළත් කළ වාර්තාවේ වගුවේ නම සහ හඳුනාගැනීම් යවමින්.
සේවාදායකයා සමඟ සමමුහුර්ත කළ යුතු සියලුම වගු සඳහා, අපි ප්‍රේරකයක් නිර්වචනය කරමු, එය වාර්තාවක් වෙනස් කිරීමෙන් / යාවත්කාලීන කිරීමෙන් පසුව, පහත විනිවිදකයේ දක්වා ඇති ශ්‍රිතය ලෙස හැඳින්වේ.
API මෙම වෙනස්කම් වලට දායක වන්නේ කෙසේද?
Fanout යාන්ත්‍රණයක් සාදනු ලැබේ - එය සේවාදායකයාට පණිවිඩ යවයි. එය සියලුම පාරිභෝගික නාලිකා එකතු කර මෙම නාලිකා හරහා ලැබුණු යාවත්කාලීන යවයි:
මෙහිදී දත්ත සමුදායට සම්බන්ධ වන සම්මත pq පුස්තකාලය, එය නාලිකාවට සවන් දීමට අවශ්ය බව පවසන (data_updates), සම්බන්ධතාවය විවෘත වී ඇති අතර සියල්ල හොඳින් දැයි පරීක්ෂා කරයි. ඉඩ ඉතිරි කර ගැනීම සඳහා මම දෝෂ පරීක්ෂාව මග හරිමි (පරීක්ෂා නොකිරීම භයානකයි).
මීළඟට, අපි Ticker එක අසමමිතිකව සකසන්නෙමු, එය සෑම තත්පර 15කට වරක් පිං එකක් යවන අතර අප දායක වූ නාලිකාවට සවන් දීමට පටන් ගනිමු. අපිට ping එකක් ලැබුනොත් අපි මේ ping එක publish කරනවා. අපට යම් ආකාරයක ප්‍රවේශයක් ලැබෙන්නේ නම්, අපි මෙම Fanout හි සියලුම ග්‍රාහකයින් වෙත මෙම ප්‍රවේශය ප්‍රකාශයට පත් කරන්නෙමු.
Fan-out වැඩ කරන්නේ කෙසේද?
රුසියානු භාෂාවෙන් මෙය "splitter" ලෙස පරිවර්තනය කරයි. සමහර යාවත්කාලීන ලබා ගැනීමට කැමති ග්‍රාහකයින් ලියාපදිංචි කරන එක් වස්තුවක් අප සතුව ඇත. තවද මෙම වස්තුව වෙත යාවත්කාලීනයක් පැමිණි විගස, එය මෙම යාවත්කාලීනය එහි සියලුම ග්‍රාහකයින් වෙත බෙදා හරියි. ප්රමාණවත් තරම් සරල:
එය Go හි ක්‍රියාත්මක වන ආකාරය:
ව්යුහයක් ඇත, එය Mutexes භාවිතයෙන් සමමුහුර්ත කර ඇත. එහි දත්ත සමුදායට Fanout ගේ සම්බන්ධතාවයේ තත්වය සුරකින ක්ෂේත්‍රයක් ඇත, එනම් එය දැනට සවන් දී ඇති අතර යාවත්කාලීන කිරීම් ලැබෙනු ඇත, මෙන්ම පවතින සියලුම නාලිකා ලැයිස්තුවක් - සිතියම, එහි යතුර නාලිකාව වන අතර එය ස්වරූපයෙන් ව්යුහය වේ. අගයන් (අත්‍යවශ්‍යයෙන්ම එය කිසිම ආකාරයකින් භාවිතා නොවේ).
ක්‍රම දෙකක් - සම්බන්ධිත සහ විසන්ධි වූ - අපට පාදයට සම්බන්ධයක් ඇති බවත්, එය දර්ශනය වී ඇති බවත්, පාදයට සම්බන්ධය කැඩී ඇති බවත් ෆැනවුට් වෙත පැවසීමට අපට ඉඩ සලසයි. දෙවන අවස්ථාවෙහිදී, ඔබ සියලු සේවාලාභීන් විසන්ධි කර ඔවුන්ට තවදුරටත් කිසිම දෙයකට සවන් දිය නොහැකි බවත් ඔවුන් වෙත සම්බන්ධතාවය වසා ඇති නිසා ඔවුන් නැවත සම්බන්ධ වන බවත් ඔවුන්ට පැවසිය යුතුය.
"සවන් දෙන්නන්" වෙත නාලිකාව එක් කරන දායක ක්‍රමයක් ද ඇත:
ග්‍රාහකයා විසන්ධි වුවහොත් නාලිකාව සවන්දෙන්නන්ගෙන් ඉවත් කරන Unsubscribe ක්‍රමයක් මෙන්ම, සියලුම ග්‍රාහකයින් වෙත පණිවිඩයක් යැවීමට ඔබට ඉඩ සලසන Publish ක්‍රමයක් ද ඇත.
ප්රශ්නය: - මෙම නාලිකාව හරහා සම්ප්රේෂණය වන්නේ කුමක්ද?
මෙනෙවිය: – වෙනස් වී ඇති හෝ ping සම්ප්රේෂණය කරන ලද ආකෘතිය (අත්‍යවශ්‍යයෙන්ම සංඛ්‍යාවක්, පූර්ණ සංඛ්‍යාවක්).
මෙනෙවිය: - ඔබට ඕනෑම දෙයක් යැවීමට, ඕනෑම ව්යුහයක් යැවීමට, එය ප්‍රකාශ කිරීමට හැකිය - එය JSON බවට හැරේ, එපමණයි.
මෙනෙවිය: - අපට Postgres වෙතින් දැනුම්දීමක් ලැබේ - එහි වගු නම සහ හඳුනාගැනීම අඩංගු වේ. වගුවේ නම සහ හැඳුනුම්කාරකය මත පදනම්ව, අපට අවශ්ය වාර්තාව ලබා ගනී, පසුව අපි මෙම ව්යුහය ප්රකාශනය සඳහා එවන්නෙමු.
යටිතල පහසුකම්
යටිතල පහසුකම් ඉදිරිදර්ශනයකින් මෙය පෙනෙන්නේ කෙසේද? අපට දෘඩාංග සේවාදායකයන් 7 ක් ඇත: ඒවායින් එකක් සම්පූර්ණයෙන්ම දත්ත ගබඩාවට කැපවී ඇත, අනෙක් හය අථත්‍ය යන්ත්‍ර ධාවනය කරයි. API හි පිටපත් 6 ක් ඇත: API සහිත සෑම අතථ්‍ය යන්ත්‍රයක්ම වෙනම දෘඩාංග සේවාදායකයක් මත ක්‍රියාත්මක වේ - මෙය විශ්වසනීයත්වය සඳහා වේ.
ප්‍රවේශ්‍යතාව වැඩි දියුණු කිරීම සඳහා අපි Keepalived සමඟ ඉදිරිපස දෙකක් ස්ථාපනය කර ඇත, එවිට යමක් සිදුවුවහොත්, එක් ඉදිරිපස අනෙක් පැත්ත ප්‍රතිස්ථාපනය කළ හැකිය. එසේම - CMS පිටපත් දෙකක්.
සංඛ්‍යාලේඛන ආනයනකරුවෙක් ද සිටී. කාලානුරූපව උපස්ථ සාදන DB Slave එකක් ඇත. Pigeon Pusher ඇත, සේවාදායකයින්ට තල්ලු දැනුම්දීම් යවන යෙදුමක් මෙන්ම යටිතල පහසුකම් දේවල්: Zabbix, Graylog2 සහ Chef.
ඇත්ත වශයෙන්ම, මෙම යටිතල පහසුකම් අතිරික්තය, මන්ද 100 ක් අඩු සේවාදායකයන් සමඟ සේවය කළ හැකිය. නමුත් යකඩ තිබුණා - අපි එය භාවිතා කළා (එය කළ හැකි බව අපට පැවසුවා - ඇයි නැත්තේ).
Go හි වාසි
අපි මෙම යෙදුම මත වැඩ කිරීමෙන් පසුව, Go හි එවැනි පැහැදිලි වාසි මතු විය.
- සිසිල් http පුස්තකාලය. එය සමඟ ඔබට පෙට්ටියෙන් බොහෝ දේ නිර්මාණය කළ හැකිය.
- තවද, ගනුදෙනුකරුවන්ට දැනුම්දීම් යැවීමේ යාන්ත්‍රණයක් ඉතා පහසුවෙන් ක්‍රියාත්මක කිරීමට අපට ඉඩ සලසන නාලිකා.
- රේස් අනාවරකය අපට තීරණාත්මක දෝෂ කිහිපයක් (වේදිකාගත යටිතල පහසුකම්) ඉවත් කිරීමට ඉඩ දුන් අපූරු දෙයයි. වේදිකාගත කිරීමේදී ක්‍රියා කරන සෑම දෙයක්ම දියත් කර, රේස් යතුර සමඟ සම්පාදනය කර ඇත; සහ ඒ අනුව, අපට ඇති විය හැකි ගැටළු මොනවාදැයි බැලීමට වේදිකාගත යටිතල පහසුකම් දෙස බැලිය හැකිය.
- භාෂාවේ අවමවාදය සහ සරල බව.
අපි සංවර්ධකයින් සොයමින් සිටිමු! කාට හරි අවශ්ය නම් කරුණාකරලා.
ඔබගේ ප්රශ්න
ප්‍රේක්ෂකයන්ගෙන් ප්රශ්නය (මෙතැන් සිට - B): - Fan-out සම්බන්ධයෙන් ඔබට එක් වැදගත් කරුණක් මග හැරී ඇති බව මට පෙනේ. ඔබ සේවාදායකයෙකුට ප්‍රතිචාරයක් යවන විට, සේවාලාභියාට කියවීමට අවශ්ය නැතිනම් ඔබ අවහිර කරන බව මා තේරුම් ගැනීම නිවැරදිද?
මෙනෙවිය: - නැහැ, අපි අවහිර කරන්නේ නැහැ. පළමුව, අපට මේ සියල්ල nginx පිටුපස ඇත, එනම් මන්දගාමී සේවාදායකයින් සමඟ කිසිදු ගැටළුවක් නොමැත. දෙවනුව, සේවාදායකයාට බෆරයක් සහිත නාලිකාවක් ඇත - ඇත්ත වශයෙන්ම, අපට එහි යාවත්කාලීන සියයක් දක්වා තැබිය හැකිය ... අපට නාලිකාවට ලිවිය නොහැකි නම්, එය එය මකා දමයි. නාලිකාව අවහිර වී ඇති බව අපි දුටුවහොත්, අපි නාලිකාව වසා දමමු, එපමණයි - කිසියම් ගැටළුවක් ඇති වුවහොත් සේවාදායකයා නැවත සම්බන්ධ වනු ඇත. එබැවින්, ප්රතිපත්තිමය වශයෙන්, මෙහි අවහිර කිරීමක් නොමැත.
බී: - හඳුනාගැනීමේ වගුවක් නොව, සවන්දීම/දැනුම්දීම වෙත වාර්තාවක් වහාම යැවීමට නොහැකිද?
මෙනෙවිය: – Listen/Notify එය යවන පූර්ව පූරණයේ බයිට් 8 ක සීමාවක් ඇත. ප්රතිපත්තිමය වශයෙන්, අපි කුඩා දත්ත ප්‍රමාණයක් සමඟ කටයුතු කරන්නේ නම් යැවීමට හැකි වනු ඇත, නමුත් මට පෙනෙන්නේ මෙම ක්‍රමය [අපි එය කරන ආකාරය] සරලව වඩා විශ්වාසදායක බවයි. සීමාවන් Postgres තුළම ඇත.
බී: - පාරිභෝගිකයින්ට ඔවුන් උනන්දුවක් නොදක්වන තරඟ පිළිබඳ යාවත්කාලීන කිරීම් ලැබේද?
මෙනෙවිය: - පොදුවේ, ඔව්. රීතියක් ලෙස, තරඟ 2-3 ක් සමාන්තරව සිදු වන අතර, පසුව පවා ඉතා කලාතුරකිනි. සේවාදායකයෙක් යමක් නරඹන්නේ නම්, ඔහු සාමාන්‍යයෙන් සිදුවෙමින් පවතින තරඟය නරඹයි. එවිට, සේවාදායකයාට මෙම සියලු යාවත්කාලීන එකතු කරන ලද දේශීය දත්ත ගබඩාවක් ඇති අතර, අන්තර්ජාල සම්බන්ධතාවයක් නොමැතිව වුවද, සේවාදායකයාට ඔහු යාවත්කාලීන ඇති සියලුම අතීත ගැලපීම් නැරඹිය හැකිය. අත්‍යවශ්‍යයෙන්ම, අපි සේවාදායකයාගේ දේශීය දත්ත සමුදාය සමඟ සේවාදායකයේ අපගේ දත්ත සමුදාය සමමුහුර්ත කරමු, එවිට ඔහුට නොබැඳිව වැඩ කළ හැකිය.
බී: - ඔබ ඔබේම ORM එකක් සාදා ගත්තේ ඇයි?
ඇලෙක්සි (Luk+ හි සංවර්ධකයින්ගෙන් කෙනෙකි): – ඒ කාලයේ (එය වසරකට පෙර) ORM බොහෝ ප්‍රමාණයක් ඇති විට, දැන් වඩා අඩු විය. බොහෝ ORM වල මගේ ප්‍රියතම දෙය නම් ඒවායින් බොහොමයක් හිස් අතුරුමුහුණත් මත ක්‍රියාත්මක වීමයි. එනම්, මෙම ORM වල ඇති ක්‍රම ඕනෑම දෙයක් භාර ගැනීමට සූදානම්ය: ව්යුහයක්, ව්‍යුහ දර්ශකයක්, අංකයක්, සම්පූර්ණයෙන්ම අදාළ නොවන දෙයක්...
අපගේ ORM දත්ත ආකෘතිය මත පදනම්ව ව්‍යුහයන් ජනනය කරයි. මා. එබැවින් සියලු ක්‍රම කොන්ක්‍රීට් ය, පරාවර්තනය භාවිතා නොකරන්න, යනාදිය ඔවුන් ව්‍යුහයන් පිළිගෙන එන ව්‍යුහයන් භාවිතා කිරීමට අපේක්ෂා කරයි.
බී: - කී දෙනෙක් සහභාගී වුණාද?
මෙනෙවිය: - ආරම්භක අදියරේදී පුද්ගලයන් දෙදෙනෙකු සහභාගී විය. අපි ජූනි මාසයේදී කොහේ හරි ආරම්භ කළ අතර, අගෝස්තු මාසයේදී ප්රධාන කොටස සූදානම් විය (පළමු අනුවාදය). සැප්තැම්බර් මාසයේදී නිකුත් කිරීමක් තිබුණා.
බී: - ඔබ SSE විස්තර කරන තැන, ඔබ කල් ඉකුත්වීම භාවිතා නොකරයි. ඇයි ඒ?
මෙනෙවිය: - අවංකව කිවහොත්, SSE තවමත් html5 ප්‍රොටෝකෝලයකි: SSE ප්‍රමිතිය නිර්මාණය කර ඇත්තේ බ්‍රව්සර් සමඟ සන්නිවේදනය කිරීමට, මා තේරුම් ගත් පරිදි. බ්‍රවුසරවලට නැවත සම්බන්ධ වීමට (සහ එසේ) හැකි වන පරිදි එහි අමතර විශේෂාංග ඇත, නමුත් අපට ඒවා අවශ්ය නොවේ, මන්ද අපට තොරතුරු සම්බන්ධ කිරීම සහ ලබා ගැනීම සඳහා ඕනෑම තර්කයක් ක්‍රියාත්මක කළ හැකි සේවාදායකයින් සිටි බැවිනි. අපි SSE හැදුවේ නැහැ, නමුත් SSE වලට සමාන දෙයක්. මෙය ප්රොටෝකෝලයම නොවේ.
අවශ්‍යතාවක් තිබුණේ නැහැ. මා තේරුම් ගත් පරිදි, සේවාදායකයින් මුල සිටම පාහේ සම්බන්ධතා යාන්ත්‍රණය ක්‍රියාත්මක කළේය. ඔවුන් ඇත්තටම ගණන් ගත්තේ නැහැ.
බී: - ඔබ භාවිතා කළ අමතර උපයෝගිතා මොනවාද?
මෙනෙවිය: - අපි වඩාත් සක්‍රීයව govt සහ golint භාවිතා කළේ ශෛලිය ඒකාබද්ධ කිරීමට මෙන්ම gofmt කිරීමටය. වෙනත් කිසිවක් භාවිතා නොකළේය.
බී: - ඔබ දෝෂහරණය කිරීමට භාවිතා කළේ කුමක්ද?
මෙනෙවිය: - නිදොස්කරණය බොහෝ දුරට පරීක්ෂණ භාවිතයෙන් සිදු කරන ලදී. අපි කිසිදු නිදොස්කරණයක් හෝ GOP භාවිතා නොකළෙමු.
බී: – ප්‍රකාශන කාර්යය ක්‍රියාත්මක කර ඇති ස්ලයිඩය ඔබට ආපසු ලබා දිය හැකිද? තනි අකුරු විචල්‍ය නම් ඔබව ව්‍යාකූල කරයිද?
මෙනෙවිය: - නැත. ඔවුන්ට තරමක් "පටු" දෘශ්‍ය විෂය පථයක් ඇත. ඒවා මෙහි හැර වෙනත් තැනක භාවිතා නොකෙරේ (මෙම පන්තියේ අභ්‍යන්තරය හැර), එය ඉතා සංයුක්ත වේ - එයට ගත වන්නේ පේළි 7 ක් පමණි.
බී: - කෙසේ හෝ එය තවමත් බුද්ධිමය නොවේ ...
මෙනෙවිය: - නෑ, නෑ, මේක නියම කේතයක්! එය ශෛලිය ගැන නොවේ. එය එතරම් ප්‍රයෝජනවත්, ඉතා කුඩා පන්තියකි - පන්තිය තුළ ක්ෂේත්‍ර 3ක් පමණි...
මෙනෙවිය: - විශාල වශයෙන්, සේවාදායකයින් සමඟ සමමුහුර්ත කර ඇති සියලුම දත්ත (වාර තරඟ, ක්‍රීඩකයින්) වෙනස් නොවේ. දළ වශයෙන් කිවහොත්, අපි තරඟය වෙනස් කිරීමට අවශ්ය වෙනත් ක්රීඩාවක් කළහොත්, අපි සේවාදායකයාගේ නව අනුවාදයේ සෑම දෙයක්ම සරලව සැලකිල්ලට ගනිමු, සහ සේවාදායකයාගේ පැරණි අනුවාදයන් තහනම් කරනු ලැබේ.
බී: - තෙවන පාර්ශවීය යැපුම් කළමනාකරණ පැකේජ තිබේද?
මෙනෙවිය: - අපි go dep භාවිතා කළා.
බී: - වාර්තාවේ මාතෘකාවේ වීඩියෝව ගැන යමක් තිබුනා, නමුත් වීඩියෝව ගැන වාර්තාවේ කිසිවක් තිබුණේ නැත.
මෙනෙවිය: - නැහැ, මට වීඩියෝව ගැන මාතෘකාවේ කිසිවක් නැත. එය "Look+" ලෙස හැඳින්වේ - එය යෙදුමේ නමයි.
බී: - ඔබ එය ගනුදෙනුකරුවන් වෙත ප්රවාහනය කරන බව කීවාද? ..
මෙනෙවිය: - අපි වීඩියෝ ප්‍රවාහයට සම්බන්ධ නොවීය. මෙය සම්පූර්ණයෙන්ම Megafon විසින් සිදු කරන ලදී. ඔව්, මම යෙදුම MegaFon බව කීවේ නැත.
මෙනෙවිය: – යන්න – සියලු දත්ත යැවීම සඳහා – ලකුණු මත, තරග ඉසව්, සංඛ්‍යාලේඛන... Go යනු යෙදුම සඳහා සම්පූර්ණ පසුබිමයි. පරිශීලකයාට තරගය නැරඹිය හැකි වන පරිදි ක්‍රීඩකයා සඳහා කුමන සබැඳිය භාවිතා කළ යුතුද යන්න සේවාදායකයා දැන සිටිය යුතුය. සකස් කර ඇති වීඩියෝ සහ ප්‍රවාහ වෙත සබැඳි අප සතුව ඇත.
සමහර දැන්වීම් 🙂
අප සමඟ රැඳී සිටීම ගැන ඔබට ස්තුතියි. ඔබ අපේ ලිපි වලට කැමතිද? වඩාත් රසවත් අන්තර්ගතය බැලීමට අවශ්‍යද? ඇණවුමක් කිරීමෙන් හෝ මිතුරන්ට නිර්දේශ කිරීමෙන් අපට සහාය වන්න, , ඔබ වෙනුවෙන් අප විසින් නිර්මාණය කරන ලද ප්‍රවේශ මට්ටමේ සේවාදායකයන්ගේ අද්විතීය ප්‍රතිසමයක්: (RAID1 සහ RAID10, cores 24 දක්වා සහ 40GB DDR4 දක්වා ඇත).
Dell R730xd ඇම්ස්ටර්ඩෑම් හි Equinix Tier IV දත්ත මධ්‍යස්ථානයේ 2 ගුණයක් ලාභදායීද? මෙතන විතරයි නෙදර්ලන්තයේ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 සිට! ගැන කියවන්න
මූලාශ්රය: www.habr.com