សំណួរគេសួរញឹកញាប់អំពីស្ថាបត្យកម្មនិងការងាររបស់ VKontakte

ប្រវត្តិនៃការបង្កើត VKontakte មាននៅលើវិគីភីឌា វាត្រូវបានប្រាប់ដោយ Pavel ខ្លួនឯង។ វា​ហាក់​ដូច​ជា​អ្នក​រាល់​គ្នា​បាន​ស្គាល់​នាង​រួច​ហើយ។ អំពីផ្នែកខាងក្នុង ស្ថាបត្យកម្ម និងរចនាសម្ព័ន្ធនៃគេហទំព័រនៅលើ HighLoad++ Pavel ប្រាប់ខ្ញុំវិញកាលពីឆ្នាំ ២០១០. ម៉ាស៊ីនមេជាច្រើនបានលេចធ្លាយតាំងពីពេលនោះមក ដូច្នេះយើងនឹងធ្វើបច្ចុប្បន្នភាពព័ត៌មាន៖ យើងនឹងបំបែកវា យកផ្នែកខាងក្នុងចេញ ថ្លឹងទម្ងន់ និងមើលឧបករណ៍ VK តាមទស្សនៈបច្ចេកទេស។

Alexey Akulovich (AterCattus) អ្នកអភិវឌ្ឍន៍ផ្នែកខាងក្រោយនៅក្នុងក្រុម VKontakte ។ ប្រតិចារិកនៃរបាយការណ៍នេះគឺជាចម្លើយរួមចំពោះសំណួរដែលសួរញឹកញាប់អំពីប្រតិបត្តិការនៃវេទិកា ហេដ្ឋារចនាសម្ព័ន្ធ ម៉ាស៊ីនមេ និងអន្តរកម្មរវាងពួកគេ ប៉ុន្តែមិនមែនអំពីការអភិវឌ្ឍន៍នោះទេ ពោលគឺ អំពីជាតិដែក. ដោយឡែកពីគ្នាអំពីមូលដ្ឋានទិន្នន័យ និងអ្វីដែល VK មានជំនួសវិញ អំពីការប្រមូលកំណត់ហេតុ និងការត្រួតពិនិត្យគម្រោងទាំងមូលទាំងមូល។ ព័ត៌មានលម្អិតនៅក្រោមការកាត់។

អស់រយៈពេលជាង 4 ឆ្នាំហើយដែលខ្ញុំបានដោះស្រាយជាមួយនឹងកិច្ចការគ្រប់ប្រភេទដែលទាក់ទងនឹងផ្នែកខាងក្រោយ។

• ការបង្ហោះ រក្សាទុក ដំណើរការ ចែកចាយប្រព័ន្ធផ្សព្វផ្សាយ៖ វីដេអូ ការផ្សាយផ្ទាល់ អូឌីយ៉ូ រូបថត ឯកសារ។
• ហេដ្ឋារចនាសម្ព័ន្ធ វេទិកា ការត្រួតពិនិត្យអ្នកអភិវឌ្ឍន៍ កំណត់ហេតុ ឃ្លាំងសម្ងាត់ក្នុងតំបន់ CDN ពិធីការ RPC កម្មសិទ្ធិ។
• ការរួមបញ្ចូលជាមួយសេវាកម្មខាងក្រៅ៖ ការជូនដំណឹងជំរុញ ការញែកតំណខាងក្រៅ មតិព័ត៌មាន RSS ។
• ជួយមិត្តរួមការងារជាមួយនឹងសំណួរផ្សេងៗ ចម្លើយដែលតម្រូវឱ្យជ្រមុជចូលទៅក្នុងកូដដែលមិនស្គាល់។

ក្នុងអំឡុងពេលនេះ ខ្ញុំមានដៃនៅក្នុងផ្នែកជាច្រើននៃគេហទំព័រ។ ខ្ញុំចង់ចែករំលែកបទពិសោធន៍នេះ។

ស្ថាបត្យកម្មទូទៅ

អ្វីគ្រប់យ៉ាងដូចធម្មតា ចាប់ផ្តើមដោយម៉ាស៊ីនមេ ឬក្រុមនៃម៉ាស៊ីនមេដែលទទួលយកសំណើ។

ម៉ាស៊ីនបម្រើខាងមុខ

ម៉ាស៊ីនមេខាងមុខទទួលយកសំណើតាមរយៈ HTTPS, RTMP និង WSS ។

HTTPS - ទាំងនេះគឺជាសំណើសម្រាប់កំណែគេហទំព័រសំខាន់ និងចល័តរបស់គេហទំព័រ៖ vk.com និង m.vk.com និងអតិថិជនផ្លូវការ និងក្រៅផ្លូវការផ្សេងទៀតនៃ API របស់យើង៖ អតិថិជនទូរស័ព្ទ អ្នកនាំសារ។ យើងមានកន្លែងទទួលភ្ញៀវ RTMP ។-traffic សម្រាប់ការផ្សាយបន្តផ្ទាល់ជាមួយម៉ាស៊ីនមេដាច់ដោយឡែក និង WSS- ការតភ្ជាប់សម្រាប់ស្ទ្រីម API ។

សម្រាប់ HTTPS និង WSS នៅលើ servers វាមានតម្លៃ nginx. សម្រាប់ការផ្សាយ RTMP ថ្មីៗនេះ យើងបានប្តូរទៅដំណោះស្រាយផ្ទាល់ខ្លួនរបស់យើង។ កូវប៉ុន្តែវាហួសពីវិសាលភាពនៃរបាយការណ៍។ សម្រាប់ការអត់ឱនចំពោះកំហុស ម៉ាស៊ីនមេទាំងនេះផ្សព្វផ្សាយអាសយដ្ឋាន IP ទូទៅ និងធ្វើសកម្មភាពជាក្រុម ដូច្នេះប្រសិនបើមានបញ្ហានៅលើម៉ាស៊ីនមេណាមួយ សំណើរបស់អ្នកប្រើប្រាស់មិនត្រូវបានបាត់បង់ឡើយ។ សម្រាប់ HTTPS និង WSS ម៉ាស៊ីនមេដូចគ្នាទាំងនេះអ៊ិនគ្រីបចរាចរណ៍ ដើម្បីយកផ្នែកមួយនៃការផ្ទុកស៊ីភីយូមកលើខ្លួនគេ។

យើងនឹងមិននិយាយបន្ថែមអំពី WSS និង RTMP ទេ ប៉ុន្តែគ្រាន់តែអំពីសំណើ HTTPS ស្តង់ដារ ដែលជាធម្មតាត្រូវបានភ្ជាប់ជាមួយគម្រោងបណ្តាញ។

កម្មវិធីខាងក្រោយ។

នៅខាងក្រោយផ្នែកខាងមុខជាធម្មតាមានម៉ាស៊ីនមេខាងក្រោយ។ ពួកគេដំណើរការសំណើដែលម៉ាស៊ីនមេខាងមុខទទួលបានពីអតិថិជន។

នេះ ម៉ាស៊ីនមេ kPHPដែលដេមិន HTTP កំពុងដំណើរការ ពីព្រោះ HTTPS ត្រូវបានឌិគ្រីបរួចហើយ។ kPHP គឺជាម៉ាស៊ីនមេដែលដំណើរការ ម៉ូដែល prefork៖ ចាប់ផ្តើមដំណើរការមេ ជាបណ្តុំនៃដំណើរការកុមារ ឆ្លងកាត់រន្ធស្តាប់ទៅពួកគេ ហើយពួកគេដំណើរការសំណើរបស់ពួកគេ។ ក្នុងករណីនេះ ដំណើរការមិនត្រូវបានចាប់ផ្តើមឡើងវិញរវាងសំណើនីមួយៗពីអ្នកប្រើប្រាស់ទេ ប៉ុន្តែគ្រាន់តែកំណត់ស្ថានភាពរបស់ពួកគេឡើងវិញទៅស្ថានភាពសូន្យតម្លៃដើម - សំណើបន្ទាប់ពីការស្នើសុំ ជំនួសឱ្យការចាប់ផ្តើមឡើងវិញ។

ផ្ទុកការចែកចាយ

ផ្នែកខាងក្រោយរបស់យើងទាំងអស់មិនមែនជាម៉ាស៊ីនដ៏ធំសម្បើមដែលអាចដំណើរការសំណើណាមួយបានទេ។ យើងពួកគេ។ បែងចែកជាក្រុមដាច់ដោយឡែក៖ general, mobile, api, video, staging... បញ្ហានៅលើក្រុមដាច់ដោយឡែកនៃម៉ាស៊ីននឹងមិនប៉ះពាល់ដល់អ្នកផ្សេងទៀតទាំងអស់ ក្នុង​ករណី​មាន​បញ្ហា​ជាមួយ​វីដេអូ អ្នក​ប្រើ​ដែល​ស្តាប់​តន្ត្រី​នឹង​មិន​ដឹង​អំពី​បញ្ហា​នោះ​ទេ។ ផ្នែកខាងក្រោយមួយណាដែលត្រូវផ្ញើសំណើទៅគឺត្រូវសម្រេចដោយ nginx នៅផ្នែកខាងមុខយោងតាមការកំណត់។

ការប្រមូលម៉ែត្រនិងតុល្យភាពឡើងវិញ

ដើម្បីយល់ពីចំនួនរថយន្តដែលយើងត្រូវមានក្នុងក្រុមនីមួយៗ យើង កុំពឹងផ្អែកលើ QPS. ផ្នែកខាងក្រោយមានភាពខុសគ្នា ពួកគេមានសំណើខុសៗគ្នា សំណើនីមួយៗមានភាពស្មុគស្មាញខុសៗគ្នាក្នុងការគណនា QPS ។ នោះហើយជាមូលហេតុដែលយើង យើងដំណើរការជាមួយនឹងគំនិតនៃការផ្ទុកនៅលើម៉ាស៊ីនមេទាំងមូល - នៅលើ CPU និង perf.

យើងមានម៉ាស៊ីនមេបែបនេះរាប់ពាន់។ ម៉ាស៊ីនមេរាងកាយនីមួយៗដំណើរការក្រុម kPHP ដើម្បីកែច្នៃស្នូលទាំងអស់ឡើងវិញ (ដោយសារតែ kPHP គឺជាខ្សែតែមួយ)។

ម៉ាស៊ីនមេមាតិកា

CS ឬ Content Server គឺជាកន្លែងផ្ទុក. CS គឺជាម៉ាស៊ីនមេដែលរក្សាទុកឯកសារ និងដំណើរការឯកសារដែលបានផ្ទុកឡើង និងគ្រប់ប្រភេទនៃកិច្ចការធ្វើសមកាលកម្មផ្ទៃខាងក្រោយដែលផ្នែកខាងមុខគេហទំព័រសំខាន់ប្រគល់ឱ្យវា។

យើង​មាន​ម៉ាស៊ីន​បម្រើ​រូបវន្ត​រាប់ម៉ឺន​ដែល​រក្សាទុក​ឯកសារ។ អ្នកប្រើប្រាស់ចូលចិត្តផ្ទុកឡើងឯកសារ ហើយយើងចូលចិត្តរក្សាទុក និងចែករំលែកវា។ ម៉ាស៊ីនមេទាំងនេះមួយចំនួនត្រូវបានបិទដោយម៉ាស៊ីនមេ pu/pp ពិសេស។

pu/pp

ប្រសិនបើអ្នកបើកផ្ទាំងបណ្តាញនៅក្នុង VK អ្នកឃើញ pu/pp ។

តើ pu/pp ជាអ្វី? ប្រសិនបើយើងបិទម៉ាស៊ីនមេមួយបន្ទាប់ពីមួយផ្សេងទៀត នោះមានជម្រើសពីរសម្រាប់ការផ្ទុកឡើង និងទាញយកឯកសារទៅម៉ាស៊ីនមេដែលត្រូវបានបិទ៖ ដោយ​ផ្ទាល់ តាមរយៈការ http://cs100500.userapi.com/path ឬ តាមរយៈម៉ាស៊ីនមេកម្រិតមធ្យម - http://pu.vk.com/c100500/path.

Pu គឺជាឈ្មោះប្រវត្តិសាស្ត្រសម្រាប់ការបង្ហោះរូបថត ហើយ pp គឺជាប្រូកស៊ីរូបថត. នោះ​គឺ​ម៉ាស៊ីន​មេ​មួយ​គឺ​សម្រាប់​ផ្ទុក​រូប​ថត ហើយ​មួយ​ទៀត​គឺ​សម្រាប់​ផ្ទុក​ឡើង។ ឥឡូវនេះមិនត្រឹមតែរូបថតត្រូវបានផ្ទុកទេ ប៉ុន្តែឈ្មោះត្រូវបានរក្សាទុក។

ម៉ាស៊ីនមេទាំងនេះ បញ្ចប់វគ្គ HTTPSដើម្បីដកបន្ទុកដំណើរការចេញពីកន្លែងផ្ទុក។ ដូចគ្នានេះផងដែរ ដោយសារឯកសាររបស់អ្នកប្រើប្រាស់ត្រូវបានដំណើរការនៅលើម៉ាស៊ីនមេទាំងនេះ ព័ត៌មានរសើបតិចត្រូវបានរក្សាទុកនៅលើម៉ាស៊ីនទាំងនេះ កាន់តែប្រសើរ។ ឧទាហរណ៍ សោអ៊ិនគ្រីប HTTPS ។

ដោយសារម៉ាស៊ីនត្រូវបានបិទដោយម៉ាស៊ីនផ្សេងទៀតរបស់យើង យើងអាចមានលទ្ធភាពមិនផ្តល់ឱ្យពួកគេនូវ IP ខាងក្រៅ "ពណ៌ស" និង ផ្តល់ឱ្យ "ពណ៌ប្រផេះ". វិធីនេះយើងបានរក្សាទុកនៅលើ IP pool និងធានាដើម្បីការពារម៉ាស៊ីនពីការចូលពីខាងក្រៅ - វាមិនមាន IP ដើម្បីចូលទៅក្នុងវាទេ។

ភាពធន់នឹង IPs ដែលបានចែករំលែក. នៅក្នុងលក្ខខណ្ឌនៃការអត់ឱនកំហុស គ្រោងការណ៍នេះដំណើរការដូចគ្នា - ម៉ាស៊ីនមេរាងកាយជាច្រើនមាន IP រាងកាយទូទៅ ហើយផ្នែករឹងនៅពីមុខពួកគេជ្រើសរើសកន្លែងដែលត្រូវផ្ញើសំណើ។ ខ្ញុំនឹងនិយាយអំពីជម្រើសផ្សេងទៀតនៅពេលក្រោយ។

ចំណុចចម្រូងចម្រាសគឺថាក្នុងករណីនេះ អតិថិជនរក្សាការតភ្ជាប់តិចជាងមុន។. ប្រសិនបើមាន IP ដូចគ្នាសម្រាប់ម៉ាស៊ីនជាច្រើន - ជាមួយម៉ាស៊ីនដូចគ្នា៖ pu.vk.com ឬ pp.vk.com កម្មវិធីរុករកតាមអ៊ីនធឺណិតរបស់អតិថិជនមានដែនកំណត់លើចំនួនសំណើដំណាលគ្នាចំពោះម៉ាស៊ីនតែមួយ។ ប៉ុន្តែនៅក្នុងពេលនៃ HTTP/2 គ្រប់ទីកន្លែង ខ្ញុំជឿថាវាលែងពាក់ព័ន្ធទៀតហើយ។

គុណវិបត្តិជាក់ស្តែងនៃគ្រោងការណ៍គឺថាវាត្រូវតែ បូមចរាចរទាំងអស់។ដែលចូលទៅកាន់កន្លែងផ្ទុក តាមរយៈម៉ាស៊ីនមេផ្សេងទៀត។ ដោយសារយើងបូមចរាចរតាមម៉ាស៊ីន យើងមិនទាន់អាចបូមចរាចរណ៍ធ្ងន់បានទេ ឧទាហរណ៍ វីដេអូ ដោយប្រើគ្រោងការណ៍ដូចគ្នា។ យើងបញ្ជូនវាដោយផ្ទាល់ - ការតភ្ជាប់ដោយផ្ទាល់ដាច់ដោយឡែកសម្រាប់ការផ្ទុកដាច់ដោយឡែកជាពិសេសសម្រាប់វីដេអូ។ យើងបញ្ជូនមាតិកាស្រាលជាងមុនតាមរយៈប្រូកស៊ី។

មិនយូរប៉ុន្មានយើងទទួលបានកំណែប្រូកស៊ីប្រសើរឡើង។ ឥឡូវនេះខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលពួកគេខុសពីធម្មតា ហើយហេតុអ្វីបានជាវាចាំបាច់។

ស៊ុន

កាលពីខែកញ្ញា ឆ្នាំ 2017 ក្រុមហ៊ុន Oracle ដែលធ្លាប់បានទិញ Sun ។ បានបណ្តេញបុគ្គលិក Sun មួយចំនួនធំ. យើងអាចនិយាយបានថានៅពេលនេះក្រុមហ៊ុនឈប់មាន។ នៅពេលជ្រើសរើសឈ្មោះសម្រាប់ប្រព័ន្ធថ្មី អ្នកគ្រប់គ្រងរបស់យើងបានសម្រេចចិត្តផ្តល់កិត្តិយសដល់ការចងចាំរបស់ក្រុមហ៊ុននេះ ហើយដាក់ឈ្មោះប្រព័ន្ធថ្មីថា Sun ។ ក្នុងចំណោមខ្លួនយើងយើងគ្រាន់តែហៅនាងថា "ព្រះអាទិត្យ" ។

pp មានបញ្ហាមួយចំនួន។ IP មួយក្នុងមួយក្រុម - ឃ្លាំងសម្ងាត់គ្មានប្រសិទ្ធភាព. ម៉ាស៊ីនមេរាងកាយជាច្រើនចែករំលែកអាសយដ្ឋាន IP ទូទៅ ហើយមិនមានវិធីគ្រប់គ្រងម៉ាស៊ីនមេណាមួយដែលសំណើនឹងទៅនោះទេ។ ដូច្នេះ ប្រសិនបើអ្នកប្រើផ្សេងគ្នាមកសម្រាប់ឯកសារដូចគ្នា នោះប្រសិនបើមានឃ្លាំងសម្ងាត់នៅលើម៉ាស៊ីនមេទាំងនេះ ឯកសារនឹងបញ្ចប់នៅក្នុងឃ្លាំងសម្ងាត់នៃម៉ាស៊ីនមេនីមួយៗ។ នេះ​ជា​គម្រោង​មិន​មាន​ប្រសិទ្ធភាព​ខ្លាំង​ណាស់ ប៉ុន្តែ​មិន​អាច​ធ្វើ​អ្វី​បាន​ទេ។

ជាលទ្ធផល - យើងមិនអាចបំបែកមាតិកាបានទេ។ពីព្រោះយើងមិនអាចជ្រើសរើសម៉ាស៊ីនមេជាក់លាក់សម្រាប់ក្រុមនេះទេ ពួកគេមាន IP ទូទៅ។ ផងដែរសម្រាប់ហេតុផលផ្ទៃក្នុងមួយចំនួនដែលយើងមាន វាមិនអាចដំឡើងម៉ាស៊ីនមេបែបនេះនៅក្នុងតំបន់បានទេ។. ពួកគេបានឈរតែនៅ St.

ជាមួយនឹងព្រះអាទិត្យ យើងបានផ្លាស់ប្តូរប្រព័ន្ធជ្រើសរើស។ ឥឡូវនេះយើងមាន anycast នាំផ្លូវ៖ ការកំណត់ផ្លូវថាមវន្ត, anycast, ដេមិនត្រួតពិនិត្យខ្លួនឯង។ ម៉ាស៊ីនមេនីមួយៗមាន IP ផ្ទាល់ខ្លួនរបស់វា ប៉ុន្តែបណ្តាញរងទូទៅមួយ។ អ្វីគ្រប់យ៉ាងត្រូវបានកំណត់រចនាសម្ព័ន្ធតាមរបៀបដែលប្រសិនបើម៉ាស៊ីនមេមួយបរាជ័យ ចរាចរណ៍ត្រូវបានរីករាលដាលនៅទូទាំងម៉ាស៊ីនមេផ្សេងទៀតនៃក្រុមដូចគ្នាដោយស្វ័យប្រវត្តិ។ ឥឡូវនេះ វាអាចជ្រើសរើសម៉ាស៊ីនមេជាក់លាក់មួយ គ្មាន​ឃ្លាំង​សម្ងាត់​ដដែលៗនិងភាពជឿជាក់មិនត្រូវបានប៉ះពាល់ទេ។

ការគាំទ្រទំងន់. ឥឡូវនេះយើងអាចមានលទ្ធភាពដំឡើងម៉ាស៊ីនដែលមានថាមពលខុសៗគ្នាតាមតម្រូវការ ហើយក្នុងករណីមានបញ្ហាបណ្តោះអាសន្ន ផ្លាស់ប្តូរទម្ងន់នៃ "ព្រះអាទិត្យ" ដែលធ្វើការដើម្បីកាត់បន្ថយបន្ទុកលើពួកវា ដូច្នេះពួកគេ "សម្រាក" ហើយចាប់ផ្តើមធ្វើការម្តងទៀត។

ការចែករំលែកតាមលេខសម្គាល់មាតិកា. រឿងគួរឱ្យអស់សំណើចអំពីការបែងចែក៖ ជាធម្មតាយើងចែករំលែកមាតិកាដើម្បីឱ្យអ្នកប្រើប្រាស់ផ្សេងគ្នាចូលទៅកាន់ឯកសារដូចគ្នាតាមរយៈ "ព្រះអាទិត្យ" ដូចគ្នាដើម្បីឱ្យពួកគេមានឃ្លាំងសម្ងាត់ទូទៅ។

ថ្មីៗនេះយើងបានចាប់ផ្តើមកម្មវិធី "Clover" ។ នេះគឺជាកម្រងសំណួរតាមអ៊ិនធរណេតក្នុងការផ្សាយផ្ទាល់ ដែលម្ចាស់ផ្ទះសួរសំណួរ ហើយអ្នកប្រើប្រាស់ឆ្លើយក្នុងពេលជាក់ស្តែង ដោយជ្រើសរើសជម្រើស។ កម្មវិធីនេះមានកម្មវិធីជជែកដែលអ្នកប្រើប្រាស់អាចជជែកបាន។ អាចភ្ជាប់ទៅការផ្សាយក្នុងពេលដំណាលគ្នា។ ជាង 100 ពាន់នាក់។. ពួកគេទាំងអស់សរសេរសារដែលត្រូវបានផ្ញើទៅកាន់អ្នកចូលរួមទាំងអស់ ហើយរូបតំណាងភ្ជាប់មកជាមួយសារ។ ប្រសិនបើមនុស្ស 100 ពាន់នាក់មករករូបតំណាងមួយនៅក្នុង "ព្រះអាទិត្យ" មួយនោះ ជួនកាលវាអាចវិលនៅពីក្រោយពពក។

ដើម្បីទប់ទល់នឹងការផ្ទុះសំណើសុំឯកសារដូចគ្នា វាគឺសម្រាប់ប្រភេទជាក់លាក់នៃមាតិកាដែលយើងបើកគ្រោងការណ៍ឆោតល្ងង់ដែលរីករាលដាលឯកសារនៅទូទាំង "ព្រះអាទិត្យ" ដែលមានទាំងអស់នៅក្នុងតំបន់។

ព្រះអាទិត្យពីខាងក្នុង

ប្រូកស៊ីបញ្ច្រាសនៅលើ nginx ឃ្លាំងសម្ងាត់ទាំងនៅក្នុង RAM ឬនៅលើថាស Optane/NVMe ដែលមានល្បឿនលឿន។ ឧទាហរណ៍៖ http://sun4-2.userapi.com/c100500/path - តំណភ្ជាប់ទៅ "ព្រះអាទិត្យ" ដែលមានទីតាំងនៅតំបន់ទី 100500 ដែលជាក្រុមម៉ាស៊ីនមេទីពីរ។ វាបិទឯកសារផ្លូវ ដែលស្ថិតនៅលើម៉ាស៊ីនមេ XNUMX។

គ្របដណ្តប់

យើងបន្ថែមថ្នាំងមួយបន្ថែមទៀតទៅក្នុងគ្រោងការណ៍ស្ថាបត្យកម្មរបស់យើង - បរិយាកាសឃ្លាំងសម្ងាត់។

ខាងក្រោមនេះជាដ្យាក្រាមប្លង់ ឃ្លាំងសម្ងាត់ក្នុងតំបន់មានប្រហែល 20 ក្នុងចំណោមពួកគេ។ ទាំងនេះគឺជាកន្លែងដែលឃ្លាំងសម្ងាត់ និង "ព្រះអាទិត្យ" ស្ថិតនៅ ដែលអាចរក្សាទុកចរាចរណ៍តាមរយៈខ្លួនពួកគេ។

នេះគឺជាឃ្លាំងសម្ងាត់នៃមាតិកាពហុមេឌៀ គ្មានទិន្នន័យអ្នកប្រើប្រាស់ត្រូវបានរក្សាទុកនៅទីនេះទេ - គ្រាន់តែជាតន្ត្រី វីដេអូ រូបថត។

ដើម្បីកំណត់តំបន់របស់អ្នកប្រើ យើង យើងប្រមូលបុព្វបទបណ្តាញ BGP ដែលបានប្រកាសនៅក្នុងតំបន់. នៅក្នុងករណីនៃការធ្លាក់ចុះ យើងក៏ត្រូវញែកមូលដ្ឋានទិន្នន័យ Geoip ប្រសិនបើយើងមិនអាចស្វែងរក IP ដោយបុព្វបទ។ យើងកំណត់តំបន់ដោយ IP របស់អ្នកប្រើប្រាស់. នៅក្នុងកូដ យើងអាចមើលតំបន់មួយ ឬច្រើនរបស់អ្នកប្រើប្រាស់ - ចំណុចទាំងនោះដែលគាត់នៅជិតបំផុតតាមភូមិសាស្ត្រ។

តើវាដំណើរការយ៉ាងដូចម្តេច?

យើងរាប់ចំនួនប្រជាប្រិយភាពនៃឯកសារតាមតំបន់. មានឃ្លាំងសម្ងាត់ក្នុងតំបន់មួយចំនួនដែលអ្នកប្រើប្រាស់មានទីតាំងនៅ និងឯកសារកំណត់អត្តសញ្ញាណ - យើងយកគូនេះ ហើយបង្កើនការវាយតម្លៃជាមួយនឹងការទាញយកនីមួយៗ។

ក្នុងពេលជាមួយគ្នានោះ អារក្ស - សេវាកម្មក្នុងតំបន់ - ពីពេលមួយទៅពេលមួយមក API ហើយនិយាយថា៖ "ខ្ញុំជាឃ្លាំងសម្ងាត់បែបនេះ សូមផ្តល់ឱ្យខ្ញុំនូវបញ្ជីឯកសារពេញនិយមបំផុតនៅក្នុងតំបន់របស់ខ្ញុំដែលមិនទាន់មានសម្រាប់ខ្ញុំ។ ” API ផ្តល់នូវឯកសារជាច្រើនដែលតម្រៀបតាមចំណាត់ថ្នាក់ ដេមិនទាញយកពួកវា នាំពួកគេទៅកាន់តំបន់ និងបញ្ជូនឯកសារពីទីនោះ។ នេះគឺជាភាពខុសគ្នាជាមូលដ្ឋានរវាង pu/pp និង Sun ពីឃ្លាំងសម្ងាត់៖ ពួកគេផ្តល់ឯកសារតាមរយៈខ្លួនពួកគេភ្លាមៗ ទោះបីជាឯកសារនេះមិននៅក្នុងឃ្លាំងសម្ងាត់ក៏ដោយ ហើយឃ្លាំងសម្ងាត់ដំបូងទាញយកឯកសារទៅខ្លួនវា ហើយបន្ទាប់មកចាប់ផ្តើមផ្តល់វាមកវិញ។

ក្នុងករណីនេះយើងទទួលបាន មាតិកាកាន់តែជិតស្និទ្ធជាមួយអ្នកប្រើប្រាស់ និងចែកចាយបន្ទុកបណ្តាញ។ ជាឧទាហរណ៍ មានតែពីឃ្លាំងសម្ងាត់ទីក្រុងម៉ូស្គូប៉ុណ្ណោះដែលយើងចែកចាយច្រើនជាង 1 Tbit/s ក្នុងអំឡុងពេលម៉ោងខ្ពស់បំផុត។

ប៉ុន្តែមានបញ្ហា - ម៉ាស៊ីនមេឃ្លាំងសម្ងាត់មិនមែនជាកៅស៊ូទេ។. សម្រាប់ខ្លឹមសារដ៏ពេញនិយម ជួនកាលមិនមានបណ្តាញគ្រប់គ្រាន់សម្រាប់ម៉ាស៊ីនមេដាច់ដោយឡែកទេ។ ម៉ាស៊ីនមេឃ្លាំងសម្ងាត់របស់យើងគឺ 40-50 Gbit/s ប៉ុន្តែមានមាតិកាដែលបិទឆានែលបែបនេះទាំងស្រុង។ យើងកំពុងឆ្ពោះទៅរកការអនុវត្តការផ្ទុកច្រើនជាងមួយច្បាប់ចម្លងនៃឯកសារពេញនិយមនៅក្នុងតំបន់។ ខ្ញុំ​សង្ឃឹម​ថា​យើង​នឹង​អនុវត្ត​វា​នៅ​ចុង​ឆ្នាំ​នេះ។

យើងក្រឡេកមើលស្ថាបត្យកម្មទូទៅ។

• ម៉ាស៊ីនមេខាងមុខដែលទទួលយកសំណើ។
• កម្មវិធីខាងក្រោយដែលដំណើរការសំណើ។
• កន្លែងផ្ទុកដែលត្រូវបានបិទដោយប្រូកស៊ីពីរប្រភេទ។
• ឃ្លាំងសម្ងាត់ក្នុងតំបន់។

តើមានអ្វីបាត់ពីដ្យាក្រាមនេះ? ជាការពិតណាស់ មូលដ្ឋានទិន្នន័យដែលយើងរក្សាទុកទិន្នន័យ។

មូលដ្ឋានទិន្នន័យឬម៉ាស៊ីន

យើងហៅពួកគេថាមិនមែនជាមូលដ្ឋានទិន្នន័យទេ ប៉ុន្តែម៉ាស៊ីន - ម៉ាស៊ីន ពីព្រោះយើងអនុវត្តមិនមានមូលដ្ឋានទិន្នន័យក្នុងន័យទទួលយកជាទូទៅ។

នេះគឺជាវិធានការចាំបាច់. វាបានកើតឡើងដោយសារតែក្នុងឆ្នាំ 2008-2009 នៅពេលដែល VK មានការកើនឡើងយ៉ាងខ្លាំងនៅក្នុងប្រជាប្រិយភាព គម្រោងនេះបានធ្វើការទាំងស្រុងលើ MySQL និង Memcache ហើយមានបញ្ហា។ MySQL ចូលចិត្តការគាំង និងឯកសារខូច បន្ទាប់មកវានឹងមិនងើបឡើងវិញទេ ហើយ Memcache ថយចុះបន្តិចម្តងៗក្នុងដំណើរការ ហើយត្រូវចាប់ផ្តើមឡើងវិញ។

វាប្រែថាគម្រោងដែលពេញនិយមកាន់តែខ្លាំងឡើងមានការផ្ទុកជាប់លាប់ ដែលបំផ្លាញទិន្នន័យ និងឃ្លាំងសម្ងាត់ដែលថយចុះ។ នៅក្នុងលក្ខខណ្ឌបែបនេះវាពិបាកក្នុងការអភិវឌ្ឍគម្រោងដែលកំពុងរីកចម្រើន។ វាត្រូវបានសម្រេចចិត្តដើម្បីព្យាយាមសរសេរឡើងវិញនូវអ្វីដែលសំខាន់ដែលគម្រោងនេះត្រូវបានផ្តោតលើកង់របស់យើងផ្ទាល់។

ដំណោះស្រាយបានជោគជ័យ. មានឱកាសដើម្បីធ្វើកិច្ចការនេះ ក៏ដូចជាភាពចាំបាច់បំផុត ពីព្រោះវិធីផ្សេងទៀតនៃការធ្វើមាត្រដ្ឋានមិនមាននៅពេលនោះ។ មិនមានមូលដ្ឋានទិន្នន័យច្រើនទេ NoSQL មិនទាន់មាននៅឡើយទេ មានតែ MySQL, Memcache, PostrgreSQL - ហើយនោះជាវា។

ប្រតិបត្តិការជាសកល. ការអភិវឌ្ឍន៍ត្រូវបានដឹកនាំដោយក្រុមអ្នកអភិវឌ្ឍន៍ C របស់យើង ហើយអ្វីៗគ្រប់យ៉ាងត្រូវបានធ្វើក្នុងលក្ខណៈស្របគ្នា។ ដោយមិនគិតពីម៉ាស៊ីន ពួកវាទាំងអស់មានទ្រង់ទ្រាយឯកសារដូចគ្នាដែលសរសេរទៅឌីស ប៉ារ៉ាម៉ែត្រនៃការបើកដំណើរការដូចគ្នា ដំណើរការសញ្ញាក្នុងវិធីដូចគ្នា ហើយមានឥរិយាបទប្រហាក់ប្រហែលគ្នាក្នុងករណីស្ថានភាពគែម និងបញ្ហា។ ជាមួយនឹងការរីកចម្រើននៃម៉ាស៊ីន វាជាការងាយស្រួលសម្រាប់អ្នកគ្រប់គ្រងក្នុងការដំណើរការប្រព័ន្ធ ពោលគឺមិនមានសួនសត្វដែលត្រូវការការថែទាំទេ ហើយពួកគេត្រូវរៀនពីរបៀបដំណើរការមូលដ្ឋានទិន្នន័យភាគីទីបីថ្មីនីមួយៗ ដែលធ្វើឱ្យវាអាចបង្កើនបានយ៉ាងឆាប់រហ័ស និងងាយស្រួល។ លេខរបស់ពួកគេ។

ប្រភេទនៃម៉ាស៊ីន

ក្រុមនេះបានសរសេរម៉ាស៊ីនមួយចំនួន។ នេះគ្រាន់តែជាព័ត៌មានមួយចំនួនប៉ុណ្ណោះ៖ មិត្តភ័ក្តិ ការណែនាំ រូបភាព ipdb អក្សរ បញ្ជី កំណត់ហេតុ memcached meowdb ព័ត៌មាន nostradamus រូបថត បញ្ជីចាក់ pmemcached ប្រអប់ខ្សាច់ ស្វែងរក ការផ្ទុក ចូលចិត្ត ភារកិច្ច ...

សម្រាប់កិច្ចការនីមួយៗដែលទាមទាររចនាសម្ព័ន្ធទិន្នន័យជាក់លាក់ ឬដំណើរការសំណើ atypical ក្រុម C សរសេរម៉ាស៊ីនថ្មី។ ហេតុអ្វីបានជាមិនមាន។

យើងមានម៉ាស៊ីនដាច់ដោយឡែក memcachedដែល​ស្រដៀង​នឹង​របស់​ធម្មតា ប៉ុន្តែ​មាន​ចង្កោម​ល្អ ហើយ​ដែល​មិន​បង្អង់​យូរ។ មិនមែន ClickHouse ទេ ប៉ុន្តែវាក៏ដំណើរការផងដែរ។ អាចរកបានដោយឡែកពីគ្នា។ pmemcached - នេះ​គឺជា memcached ជាប់លាប់ដែលអាចរក្សាទុកទិន្នន័យនៅលើថាស លើសពីនេះទៅទៀតគឺសមនឹង RAM ដូច្នេះដើម្បីកុំឱ្យបាត់បង់ទិន្នន័យនៅពេលចាប់ផ្តើមឡើងវិញ។ មានម៉ាស៊ីនផ្សេងៗគ្នាសម្រាប់កិច្ចការនីមួយៗ៖ ជួរ បញ្ជី សំណុំ - អ្វីគ្រប់យ៉ាងដែលគម្រោងរបស់យើងទាមទារ។

ចង្កោម

តាមទស្សនៈនៃកូដ មិនចាំបាច់គិតពីម៉ាស៊ីន ឬមូលដ្ឋានទិន្នន័យជាដំណើរការ អង្គភាព ឬឧទាហរណ៍ទេ។ លេខកូដដំណើរការជាពិសេសជាមួយចង្កោម ជាមួយនឹងក្រុមម៉ាស៊ីន - ប្រភេទមួយក្នុងមួយក្រុម. ចូរនិយាយថាមានចង្កោម memcached - វាគ្រាន់តែជាក្រុមនៃម៉ាស៊ីនប៉ុណ្ណោះ។

លេខកូដមិនចាំបាច់ដឹងពីទីតាំងជាក់ស្តែង ទំហំ ឬចំនួនម៉ាស៊ីនមេទាល់តែសោះ។ គាត់ទៅចង្កោមដោយប្រើឧបករណ៍សម្គាល់ជាក់លាក់។

ដើម្បីឱ្យវាដំណើរការ អ្នកត្រូវបន្ថែមអង្គភាពមួយបន្ថែមទៀត ដែលមានទីតាំងនៅចន្លោះកូដ និងម៉ាស៊ីន - ប្រូកស៊ី.

ប្រូកស៊ី RPC

ប្រូកស៊ី ឡានក្រុងតភ្ជាប់ដែលស្ទើរតែគ្រប់គេហទំព័រដំណើរការ។ ក្នុងពេលជាមួយគ្នានេះយើងមាន គ្មានការរកឃើញសេវាកម្មទេ។ — ផ្ទុយទៅវិញ មានការកំណត់សម្រាប់ប្រូកស៊ីនេះ ដែលដឹងពីទីតាំងនៃចង្កោមទាំងអស់ និងផ្នែកទាំងអស់នៃចង្កោមនេះ។ នេះជាអ្វីដែលអ្នកគ្រប់គ្រងធ្វើ។

អ្នកសរសេរកម្មវិធីមិនខ្វល់ពីចំនួនប៉ុន្មាន កន្លែងណា និងតម្លៃប៉ុន្មាននោះទេ - ពួកគេគ្រាន់តែចូលទៅកាន់ចង្កោមប៉ុណ្ណោះ។ នេះអនុញ្ញាតឱ្យយើងច្រើន។ នៅពេលទទួលសំណើ ប្រូកស៊ីប្តូរទិសសំណើដោយដឹងថាកន្លែងណា - វាកំណត់វាដោយខ្លួនឯង។

ក្នុងករណីនេះប្រូកស៊ីគឺជាចំណុចការពារប្រឆាំងនឹងការបរាជ័យនៃសេវាកម្ម។ ប្រសិនបើម៉ាស៊ីនខ្លះបន្ថយល្បឿន ឬគាំង នោះប្រូកស៊ីយល់អំពីបញ្ហានេះ ហើយឆ្លើយតបទៅតាមភាគីអតិថិជន។ នេះអនុញ្ញាតឱ្យអ្នកដកការអស់ពេលចេញ - លេខកូដមិនរង់ចាំឱ្យម៉ាស៊ីនឆ្លើយតបទេ ប៉ុន្តែយល់ថាវាមិនដំណើរការទេ ហើយត្រូវមានឥរិយាបថខុសគ្នាខ្លះ។ កូដត្រូវតែត្រូវបានរៀបចំសម្រាប់ការពិតដែលថាមូលដ្ឋានទិន្នន័យមិនដំណើរការជានិច្ច។

ការអនុវត្តជាក់លាក់

ពេលខ្លះយើងនៅតែចង់មានប្រភេទនៃដំណោះស្រាយមិនស្តង់ដារជាម៉ាស៊ីន។ ក្នុងពេលជាមួយគ្នានេះ វាត្រូវបានសម្រេចចិត្តមិនប្រើ rpc-proxy ដែលត្រៀមរួចជាស្រេចរបស់យើង ដែលបង្កើតជាពិសេសសម្រាប់ម៉ាស៊ីនរបស់យើង ប៉ុន្តែដើម្បីបង្កើតប្រូកស៊ីដាច់ដោយឡែកសម្រាប់កិច្ចការ។

សម្រាប់ MySQL ដែលយើងនៅតែមាននៅទីនេះ និងទីនោះ យើងប្រើ db-proxy និងសម្រាប់ ClickHouse - ផ្ទះកូនឆ្មា.

វាដំណើរការជាទូទៅដូចនេះ។ មានម៉ាស៊ីនមេជាក់លាក់មួយ វាដំណើរការ kPHP, Go, Python - ជាទូទៅ កូដណាមួយដែលអាចប្រើពិធីការ RPC របស់យើង។ កូដដំណើរការក្នុងមូលដ្ឋានលើប្រូកស៊ី RPC - ម៉ាស៊ីនមេនីមួយៗដែលលេខកូដមានទីតាំងនៅដំណើរការប្រូកស៊ីមូលដ្ឋានរបស់វា។ តាមការស្នើសុំ ប្រូកស៊ីយល់កន្លែងដែលត្រូវទៅ។

ប្រសិនបើម៉ាស៊ីនមួយចង់ទៅមួយទៀត ទោះបីវាជាអ្នកជិតខាងក៏ដោយ វាឆ្លងកាត់ប្រូកស៊ី ព្រោះអ្នកជិតខាងអាចស្ថិតនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀត។ ម៉ាស៊ីនមិនគួរពឹងផ្អែកលើការដឹងពីទីតាំងរបស់អ្វីក្រៅពីខ្លួនវា - នេះគឺជាដំណោះស្រាយស្តង់ដាររបស់យើង។ ប៉ុន្តែជាការពិតណាស់មានករណីលើកលែង :)

ឧទាហរណ៍នៃគ្រោងការណ៍ TL យោងទៅតាមម៉ាស៊ីនទាំងអស់ដំណើរការ។

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

នេះគឺជាពិធីការប្រព័ន្ធគោលពីរ ដែលជា analogue ជិតបំផុតគឺ protobuf ។ គ្រោងការណ៍ពិពណ៌នាអំពីវាលស្រេចចិត្ត ប្រភេទស្មុគស្មាញ - ផ្នែកបន្ថែមនៃមាត្រដ្ឋានដែលភ្ជាប់មកជាមួយ និងសំណួរ។ អ្វីៗដំណើរការដោយអនុលោមតាមពិធីការនេះ។

RPC លើ TL លើ TCP/UDP… UDP?

យើងមានពិធីការ RPC សម្រាប់អនុវត្តសំណើម៉ាស៊ីនដែលដំណើរការលើគ្រោងការណ៍ TL ។ ទាំងអស់នេះដំណើរការលើការតភ្ជាប់ TCP/UDP ។ TCP គឺអាចយល់បាន ប៉ុន្តែហេតុអ្វីបានជាយើងត្រូវការ UDP ញឹកញាប់?

UDP ជួយ ជៀសវាងបញ្ហានៃចំនួនដ៏ច្រើននៃការតភ្ជាប់រវាងម៉ាស៊ីនមេ. ប្រសិនបើម៉ាស៊ីនមេនីមួយៗមានប្រូកស៊ី RPC ហើយជាទូទៅវាអាចទៅម៉ាស៊ីនណាមួយ នោះមានការតភ្ជាប់ TCP រាប់ម៉ឺនក្នុងមួយម៉ាស៊ីនមេ។ មានបន្ទុកប៉ុន្តែវាគ្មានប្រយោជន៍ទេ។ ក្នុងករណី UDP បញ្ហានេះមិនមានទេ។

គ្មានការចាប់ដៃ TCP ដែលលែងត្រូវការគ្នាទេ។. នេះគឺជាបញ្ហាធម្មតា៖ នៅពេលដែលម៉ាស៊ីនថ្មី ឬម៉ាស៊ីនមេថ្មីត្រូវបានបើកដំណើរការ ការតភ្ជាប់ TCP ជាច្រើនត្រូវបានបង្កើតឡើងក្នុងពេលតែមួយ។ សម្រាប់សំណើទម្ងន់ស្រាលតូចៗ ឧទាហរណ៍ UDP payload ការទំនាក់ទំនងទាំងអស់រវាងកូដ និងម៉ាស៊ីនគឺ កញ្ចប់ UDP ពីរ៖ មួយហោះក្នុងទិសដៅមួយ ទីពីរនៅទិសផ្សេងទៀត។ ការធ្វើដំណើរមួយជុំ - ហើយលេខកូដបានទទួលការឆ្លើយតបពីម៉ាស៊ីនដោយមិនចាប់ដៃ។

បាទ វាគ្រាន់តែដំណើរការប៉ុណ្ណោះ។ ជាមួយនឹងភាគរយតិចតួចនៃការបាត់បង់កញ្ចប់ព័ត៌មាន. ពិធីការមានការគាំទ្រសម្រាប់ការបញ្ជូនសារឡើងវិញ និងការអស់ពេល ប៉ុន្តែប្រសិនបើយើងខាតបង់ច្រើន យើងនឹងទទួលបាន TCP ស្ទើរតែដែលមិនទទួលបានផលចំណេញ។ យើងមិនបើក UDP ឆ្លងកាត់មហាសមុទ្រទេ។

យើងមានម៉ាស៊ីនមេបែបនេះរាប់ពាន់ ហើយគ្រោងការណ៍គឺដូចគ្នា៖ កញ្ចប់ម៉ាស៊ីនត្រូវបានដំឡើងនៅលើម៉ាស៊ីនមេនីមួយៗ។ ពួកវាភាគច្រើនជាខ្សែតែមួយ ដើម្បីដំណើរការឱ្យបានលឿនតាមដែលអាចធ្វើបានដោយមិនមានការទប់ស្កាត់ និងត្រូវបានបំបែកជាដំណោះស្រាយដែលមានខ្សែតែមួយ។ ក្នុងពេលជាមួយគ្នានេះ យើងមិនមានអ្វីគួរឱ្យទុកចិត្តជាងម៉ាស៊ីនទាំងនេះទេ ហើយការយកចិត្តទុកដាក់ជាច្រើនគឺត្រូវបានបង់ទៅលើការផ្ទុកទិន្នន័យជាប់លាប់។

ការផ្ទុកទិន្នន័យជាប់លាប់

ម៉ាស៊ីនសរសេរ binlogs. binlog គឺជាឯកសារនៅចុងបញ្ចប់នៃព្រឹត្តិការណ៍សម្រាប់ការផ្លាស់ប្តូរនៅក្នុងរដ្ឋ ឬទិន្នន័យត្រូវបានបន្ថែម។ នៅក្នុងដំណោះស្រាយផ្សេងៗគេហៅថាខុសគ្នា៖ កំណត់ហេតុគោលពីរ។ វ៉ាល។, អេហ្វប៉ុន្តែគោលការណ៍គឺដូចគ្នា។

ដើម្បីបងា្ករម៉ាស៊ីនពីការអានឡើងវិញនូវ binlog ទាំងមូលអស់រយៈពេលជាច្រើនឆ្នាំនៅពេលចាប់ផ្តើមឡើងវិញ ម៉ាស៊ីនសរសេរ រូបថត - ស្ថានភាពបច្ចុប្បន្ន. បើចាំបាច់ ពួកគេអានពីវាជាមុន ហើយបន្ទាប់មកបញ្ចប់ការអានពី binlog ។ binlogs ទាំងអស់ត្រូវបានសរសេរក្នុងទម្រង់គោលពីរដូចគ្នា - យោងតាមគ្រោងការណ៍ TL ដូច្នេះអ្នកគ្រប់គ្រងអាចគ្រប់គ្រងពួកវាដោយស្មើៗគ្នាជាមួយនឹងឧបករណ៍របស់ពួកគេ។ មិនចាំបាច់មានរូបថតបែបនេះទេ។ មាន​បឋមកថា​ទូទៅ​ដែល​បង្ហាញ​ថា​រូបថត​របស់​អ្នក​ណា​ជា int, វេទមន្ត​របស់​ម៉ាស៊ីន ហើយ​តួ​ណា​មិន​សំខាន់​សម្រាប់​អ្នក​ណា​ម្នាក់។ នេះគឺជាបញ្ហាជាមួយម៉ាស៊ីនដែលបានកត់ត្រារូបថត។

ខ្ញុំនឹងរៀបរាប់អំពីគោលការណ៍នៃប្រតិបត្តិការយ៉ាងឆាប់រហ័ស។ មានម៉ាស៊ីនមេដែលម៉ាស៊ីនដំណើរការ។ គាត់បើក binlog ទទេថ្មីមួយសម្រាប់សរសេរ និងសរសេរព្រឹត្តិការណ៍មួយសម្រាប់ការផ្លាស់ប្តូរទៅវា។

នៅចំណុចខ្លះ គាត់សម្រេចចិត្តថតរូបខ្លួនឯង ឬគាត់ទទួលសញ្ញា។ ម៉ាស៊ីនមេបង្កើតឯកសារថ្មី សរសេរស្ថានភាពទាំងមូលទៅក្នុងវា បន្ថែមទំហំ binlog បច្ចុប្បន្ន - offset - ទៅចុងបញ្ចប់នៃឯកសារ ហើយបន្តសរសេរបន្ថែមទៀត។ binlog ថ្មីមិនត្រូវបានបង្កើតទេ។

នៅចំណុចមួយចំនួន នៅពេលដែលម៉ាស៊ីនចាប់ផ្តើមឡើងវិញ នឹងមានទាំង binlog និងរូបថតនៅលើឌីស។ ម៉ាស៊ីនអានរូបថតទាំងមូល និងបង្កើនស្ថានភាពរបស់វានៅចំណុចជាក់លាក់មួយ។

អាន​ទីតាំង​ដែល​នៅ​ពេល​ដែល​ការ​ថត​រូប​ត្រូវ​បាន​បង្កើត​ឡើង និង​ទំហំ​នៃ binlog ។

អានចុងបញ្ចប់នៃ binlog ដើម្បីទទួលបានស្ថានភាពបច្ចុប្បន្ន ហើយបន្តសរសេរព្រឹត្តិការណ៍បន្ថែមទៀត។ នេះគឺជាគ្រោងការណ៍ដ៏សាមញ្ញមួយ ម៉ាស៊ីនរបស់យើងទាំងអស់ដំណើរការទៅតាមវា។

ការចម្លងទិន្នន័យ

ជាលទ្ធផល ការចម្លងទិន្នន័យនៅក្នុងរបស់យើង។ ផ្អែកលើសេចក្តីថ្លែងការណ៍ - យើងសរសេរក្នុង binlog មិនមានការផ្លាស់ប្តូរទំព័រណាមួយទេ ប៉ុន្តែគឺ ការផ្លាស់ប្តូរសំណើ. ស្រដៀង​គ្នា​ទៅ​នឹង​អ្វី​ដែល​មក​លើ​បណ្ដាញ​នេះ​ដែរ គឺ​បាន​កែប្រែ​បន្តិចបន្តួច​ប៉ុណ្ណោះ។

គ្រោងការណ៍ដូចគ្នានេះត្រូវបានប្រើមិនត្រឹមតែសម្រាប់ការចម្លងប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងផងដែរ។ ដើម្បីបង្កើតការបម្រុងទុក. យើងមានម៉ាស៊ីន - មេសរសេរដែលសរសេរទៅ binlog ។ នៅកន្លែងផ្សេងទៀតដែលអ្នកគ្រប់គ្រងរៀបចំវា binlog នេះត្រូវបានចម្លង ហើយនោះហើយជាវា - យើងមានការបម្រុងទុក។

ប្រសិនបើ​ត្រូវការ ការអានចម្លងដើម្បីកាត់បន្ថយបន្ទុកអានស៊ីភីយូ ម៉ាស៊ីនអានត្រូវបានបើកដំណើរការយ៉ាងសាមញ្ញ ដែលអានចុងបញ្ចប់នៃ binlog និងប្រតិបត្តិពាក្យបញ្ជាទាំងនេះក្នុងមូលដ្ឋាន។

ភាពយឺតយ៉ាវនៅទីនេះគឺតូចណាស់ ហើយគេអាចដឹងថាតើការចម្លងនេះយឺតយ៉ាវប៉ុណ្ណាពីម្ចាស់។

ការចែករំលែកទិន្នន័យនៅក្នុងប្រូកស៊ី RPC

តើ sharding ដំណើរការយ៉ាងដូចម្តេច? តើ​ប្រូកស៊ី​យល់​ថា​ចង្កោម​មួយ​ណា​ដែល​ត្រូវ​ផ្ញើ​ទៅ​ដោយ​របៀប​ណា? លេខកូដមិននិយាយថា "ផ្ញើសម្រាប់ 15 shards!" - ទេ នេះត្រូវបានធ្វើដោយប្រូកស៊ី។

គ្រោងការណ៍សាមញ្ញបំផុតគឺដំបូង - លេខដំបូងក្នុងសំណើ។

get(photo100_500) => 100 % N.

នេះ​ជា​ឧទាហរណ៍​សម្រាប់​ពិធីការ​អត្ថបទ memcached សាមញ្ញ ប៉ុន្តែ​ពិតណាស់ សំណួរ​អាច​ស្មុគស្មាញ និង​មាន​រចនាសម្ព័ន្ធ។ ឧទាហរណ៍យកលេខទីមួយក្នុងសំណួរ និងលេខដែលនៅសល់នៅពេលបែងចែកដោយទំហំចង្កោម។

វាមានប្រយោជន៍នៅពេលដែលយើងចង់មានមូលដ្ឋានទិន្នន័យនៃអង្គភាពតែមួយ។ ឧបមាថា 100 គឺជាលេខសម្គាល់អ្នកប្រើប្រាស់ ឬក្រុម ហើយយើងចង់ឱ្យទិន្នន័យទាំងអស់នៃអង្គភាពមួយស្ថិតនៅលើផ្នែកតែមួយសម្រាប់សំណួរស្មុគស្មាញ។

ប្រសិនបើយើងមិនខ្វល់ពីរបៀបដែលសំណើត្រូវបានរីករាលដាលនៅទូទាំងចង្កោមនោះ មានជម្រើសមួយផ្សេងទៀត - រុះរើ shard ទាំងមូល.

hash(photo100_500) => 3539886280 % N

យើង​ក៏​ទទួល​បាន​លេខ​សញ្ញា​ដែល​នៅ​សេសសល់​នៃ​ការ​បែងចែក​និង​លេខ​ shard ។

ជម្រើសទាំងពីរនេះដំណើរការបានលុះត្រាតែយើងរៀបចំសម្រាប់ការពិតដែលថានៅពេលដែលយើងបង្កើនទំហំនៃចង្កោម យើងនឹងបំបែកវា ឬបង្កើនវាដោយច្រើនដង។ ឧទាហរណ៍ យើងមាន 16 shards យើងមិនមានគ្រប់គ្រាន់ទេ យើងចង់បានបន្ថែមទៀត - យើងអាចទទួលបាន 32 ​​ដោយសុវត្ថិភាពដោយមិនមានពេលវេលារងចាំ។ បើ​យើង​ចង់​បង្កើន​មិន​បាន​ច្រើន​ទេ វា​នឹង​មាន​ពេល​ទំនេរ ព្រោះ​យើង​នឹង​មិន​អាច​បំបែក​អ្វី​គ្រប់​យ៉ាង​បាន​ត្រឹម​ត្រូវ​ដោយ​មិន​ខាត។ ជម្រើសទាំងនេះមានប្រយោជន៍ ប៉ុន្តែមិនតែងតែទេ។

ប្រសិនបើយើងត្រូវការបន្ថែម ឬដកចំនួនម៉ាស៊ីនមេតាមអំពើចិត្ត យើងប្រើ ការ​ជាប់​គាំង​នៅ​លើ​សង្វៀន a la Ketama. ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ យើងបាត់បង់មូលដ្ឋានទិន្នន័យទាំងស្រុង យើងត្រូវបញ្ចូលសំណើទៅចង្កោម ដើម្បីឱ្យដុំនីមួយៗត្រឡប់ការឆ្លើយតបតិចតួចរបស់វា ហើយបន្ទាប់មកបញ្ចូលការឆ្លើយតបទៅប្រូកស៊ី។

មានសំណើជាក់លាក់ពិសេស។ វាមើលទៅដូចនេះ៖ ប្រូកស៊ី RPC ទទួលសំណើ កំណត់ចង្កោមណាដែលត្រូវទៅ និងកំណត់ shard ។ បន្ទាប់មកមានមេការសរសេរ ឬប្រសិនបើចង្កោមមានការគាំទ្រចម្លង វាផ្ញើទៅចម្លងតាមតម្រូវការ។ ប្រូកស៊ីធ្វើអ្វីៗទាំងអស់នេះ។

កំណត់ហេតុ

យើងសរសេរកំណត់ហេតុតាមវិធីជាច្រើន។ ជាក់ស្តែង និងសាមញ្ញបំផុតគឺ សរសេរកំណត់ហេតុទៅ memcache.

ring-buffer: prefix.idx = line

មានបុព្វបទគន្លឹះ - ឈ្មោះនៃកំណត់ហេតុបន្ទាត់មួយហើយមានទំហំនៃកំណត់ហេតុនេះ - ចំនួនបន្ទាត់។ យើងយកលេខចៃដន្យពី 0 ទៅចំនួនបន្ទាត់ដក 1។ គន្លឹះក្នុង memcache គឺជាបុព្វបទដែលភ្ជាប់ជាមួយលេខចៃដន្យនេះ។ យើងរក្សាទុកបន្ទាត់កំណត់ហេតុនិងពេលវេលាបច្ចុប្បន្នទៅជាតម្លៃ។

នៅពេលដែលវាចាំបាច់ដើម្បីអានកំណត់ហេតុយើងអនុវត្ត ទទួលបានច្រើន។ គ្រាប់ចុចទាំងអស់ តម្រៀបតាមពេលវេលា ហើយដូច្នេះទទួលបានកំណត់ហេតុផលិតកម្មក្នុងពេលវេលាជាក់ស្តែង។ គ្រោងការណ៍នេះត្រូវបានប្រើនៅពេលដែលអ្នកត្រូវការបំបាត់កំហុសអ្វីមួយនៅក្នុងផលិតកម្មក្នុងពេលវេលាជាក់ស្តែង ដោយមិនបំបែកអ្វីទាំងអស់ ដោយមិនបញ្ឈប់ ឬអនុញ្ញាតឱ្យចរាចរទៅកាន់ម៉ាស៊ីនផ្សេងទៀត ប៉ុន្តែកំណត់ហេតុនេះមិនមានរយៈពេលយូរទេ។

សម្រាប់ការផ្ទុកកំណត់ហេតុដែលអាចទុកចិត្តបាន យើងមានម៉ាស៊ីន logs-ម៉ាស៊ីន. នេះ​ជា​មូលហេតុ​ដែល​វា​ត្រូវ​បាន​បង្កើត​ឡើង និង​ត្រូវ​បាន​គេ​ប្រើ​យ៉ាង​ទូលំទូលាយ​ក្នុង​ចំនួន​ដ៏ច្រើន​នៃ​ចង្កោម។ ចង្កោមដ៏ធំបំផុតដែលខ្ញុំស្គាល់ រក្សាទុក 600 TB នៃកំណត់ហេតុវេចខ្ចប់។

ម៉ាស៊ីនគឺចាស់ណាស់មានចង្កោមដែលមានអាយុ 6-7 ឆ្នាំរួចទៅហើយ។ មានបញ្ហាជាមួយវាដែលយើងកំពុងព្យាយាមដោះស្រាយ ឧទាហរណ៍ យើងបានចាប់ផ្តើមប្រើប្រាស់ ClickHouse យ៉ាងសកម្មដើម្បីរក្សាទុកកំណត់ហេតុ។

ការប្រមូលកំណត់ហេតុនៅក្នុង ClickHouse

ដ្យាក្រាមនេះបង្ហាញពីរបៀបដែលយើងដើរចូលទៅក្នុងម៉ាស៊ីនរបស់យើង។

មានលេខកូដដែលទៅក្នុងតំបន់តាមរយៈ RPC ទៅ RPC-proxy ហើយវាយល់ពីកន្លែងដែលត្រូវទៅម៉ាស៊ីន។ ប្រសិនបើយើងចង់សរសេរកំណត់ហេតុនៅក្នុង ClickHouse យើងត្រូវផ្លាស់ប្តូរផ្នែកពីរនៅក្នុងគ្រោងការណ៍នេះ៖

• ជំនួសម៉ាស៊ីនមួយចំនួនជាមួយ ClickHouse;
• ជំនួសប្រូកស៊ី RPC ដែលមិនអាចចូលប្រើ ClickHouse ជាមួយនឹងដំណោះស្រាយមួយចំនួនដែលអាច និងតាមរយៈ RPC ។

ម៉ាស៊ីនគឺសាមញ្ញ - យើងជំនួសវាដោយម៉ាស៊ីនមេឬចង្កោមម៉ាស៊ីនមេជាមួយ ClickHouse ។

ហើយដើម្បីទៅ ClickHouse យើងបានធ្វើ ផ្ទះកូនឆ្មា. ប្រសិនបើយើងទៅដោយផ្ទាល់ពី KittenHouse ទៅ ClickHouse វានឹងមិនអាចដោះស្រាយបានទេ។ ទោះបីជាគ្មានសំណើក៏ដោយ វាបន្ថែមពីការតភ្ជាប់ HTTP នៃម៉ាស៊ីនមួយចំនួនធំ។ សម្រាប់គ្រោងការណ៍ដំណើរការនៅលើម៉ាស៊ីនមេដែលមាន ClickHouse ប្រូកស៊ីបញ្ច្រាសក្នុងតំបន់ត្រូវបានលើកឡើងដែលត្រូវបានសរសេរតាមរបៀបដែលវាអាចទប់ទល់នឹងបរិមាណដែលត្រូវការនៃការតភ្ជាប់។ វាក៏អាចផ្ទុកទិន្នន័យនៅក្នុងខ្លួនវាដោយភាពជឿជាក់ផងដែរ។

ពេលខ្លះយើងមិនចង់អនុវត្តគ្រោងការណ៍ RPC នៅក្នុងដំណោះស្រាយមិនស្តង់ដារ ឧទាហរណ៍នៅក្នុង nginx ។ ដូច្នេះ KittenHouse មានលទ្ធភាពទទួលកំណត់ហេតុតាមរយៈ UDP ។

ប្រសិនបើអ្នកផ្ញើ និងអ្នកទទួលកំណត់ហេតុធ្វើការនៅលើម៉ាស៊ីនតែមួយ នោះប្រូបាប៊ីលីតេនៃការបាត់បង់កញ្ចប់ព័ត៌មាន UDP នៅក្នុងម៉ាស៊ីនមូលដ្ឋានគឺទាបណាស់។ ជាការសម្របសម្រួលរវាងតម្រូវការក្នុងការអនុវត្ត RPC នៅក្នុងដំណោះស្រាយភាគីទីបី និងភាពជឿជាក់ យើងគ្រាន់តែប្រើការផ្ញើ UDP ប៉ុណ្ណោះ។ យើងនឹងត្រលប់ទៅគ្រោងការណ៍នេះនៅពេលក្រោយ។

ការត្រួតពិនិត្យ

យើង​មាន​កំណត់​ហេតុ​ពីរ​ប្រភេទ៖ ដែល​ប្រមូល​ដោយ​អ្នក​គ្រប់គ្រង​នៅ​លើ​ម៉ាស៊ីន​បម្រើ​របស់​ពួកគេ និង​ដែល​សរសេរ​ដោយ​អ្នក​អភិវឌ្ឍន៍​ពី​កូដ។ ពួកវាត្រូវគ្នាទៅនឹងរង្វាស់ពីរប្រភេទ៖ ប្រព័ន្ធនិងផលិតផល.

រង្វាស់ប្រព័ន្ធ

វាដំណើរការលើម៉ាស៊ីនមេរបស់យើងទាំងអស់។ ណេតដាតាដែលប្រមូលស្ថិតិ និងបញ្ជូនពួកគេទៅ កាបូនក្រាហ្វិច. ដូច្នេះ ClickHouse ត្រូវបានប្រើជាប្រព័ន្ធផ្ទុក ហើយមិនមែនជាឧទាហរណ៍ Whisper ទេ។ បើចាំបាច់ អ្នកអាចអានដោយផ្ទាល់ពី ClickHouse ឬប្រើ ហ្គ្រេណាណា សម្រាប់ម៉ែត្រ ក្រាហ្វ និងរបាយការណ៍។ ក្នុងនាមជាអ្នកអភិវឌ្ឍន៍ យើងមានសិទ្ធិចូលប្រើប្រាស់ Netdata និង Grafana គ្រប់គ្រាន់។

រង្វាស់ផលិតផល

ដើម្បីភាពងាយស្រួល យើងបានសរសេររឿងជាច្រើន។ ឧទាហរណ៍ មានសំណុំនៃមុខងារធម្មតាដែលអនុញ្ញាតឱ្យអ្នកសរសេរ Counts តម្លៃ UniqueCounts ទៅក្នុងស្ថិតិ ដែលត្រូវបានផ្ញើទៅកន្លែងណាមួយបន្ថែមទៀត។

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

ក្រោយមកទៀត យើងអាចប្រើតម្រងតម្រៀប និងដាក់ជាក្រុម ហើយធ្វើអ្វីគ្រប់យ៉ាងដែលយើងចង់បានពីស្ថិតិ - បង្កើតក្រាហ្វ កំណត់រចនាសម្ព័ន្ធ Watchdogs ។

យើងសរសេរណាស់។ ម៉ែត្រជាច្រើន។ ចំនួនព្រឹត្តិការណ៍គឺពី 600 ពាន់លានទៅ 1 ពាន់ពាន់លានក្នុងមួយថ្ងៃ។ ទោះយ៉ាងណាក៏ដោយយើងចង់រក្សាពួកគេ។ យ៉ាងហោចណាស់ពីរបីឆ្នាំដើម្បីយល់ពីនិន្នាការនៅក្នុងម៉ែត្រ។ ការ​ដាក់​វា​ទាំង​អស់​គ្នា​ជា​បញ្ហា​ធំ​មួយ​ដែល​យើង​មិន​ទាន់​បាន​ដោះស្រាយ​នៅ​ឡើយ​ទេ។ ខ្ញុំនឹងប្រាប់អ្នកពីរបៀបដែលវាដំណើរការក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ។

យើងមានមុខងារដែលសរសេរម៉ែត្រទាំងនេះ ទៅកាន់ memcache ក្នុងស្រុកដើម្បីកាត់បន្ថយចំនួនធាតុចូល។ ម្តងក្នុងរយៈពេលខ្លីនៃពេលវេលាដែលដាក់ឱ្យដំណើរការក្នុងស្រុក ស្ថិតិ - ដេមិន ប្រមូលកំណត់ត្រាទាំងអស់។ បន្ទាប់​មក បិសាច​បញ្ចូល​ម៉ែត្រ​ទៅ​ជា​ស្រទាប់​ពីរ​នៃ​ម៉ាស៊ីន​បម្រើ អ្នកប្រមូលកំណត់ហេតុដែលប្រមូលផ្តុំស្ថិតិពីម៉ាស៊ីនរបស់យើងជាច្រើន ដើម្បីកុំឱ្យស្រទាប់នៅពីក្រោយពួកវាស្លាប់។

បើចាំបាច់ យើងអាចសរសេរដោយផ្ទាល់ទៅអ្នកប្រមូលកំណត់ហេតុ។

ប៉ុន្តែការសរសេរពីកូដដោយផ្ទាល់ទៅកាន់អ្នកប្រមូល ដោយឆ្លងកាត់ stas-daemom គឺជាដំណោះស្រាយដែលអាចធ្វើមាត្រដ្ឋានបានតិចតួច ព្រោះវាបង្កើនបន្ទុកលើអ្នកប្រមូល។ ដំណោះស្រាយគឺសមរម្យលុះត្រាតែយើងមិនអាចដំឡើង memcache stats-daemon នៅលើម៉ាស៊ីន ឬវាគាំង ហើយយើងបានទៅដោយផ្ទាល់។

បន្ទាប់មក អ្នកប្រមូលទិន្នន័យ បញ្ចូលស្ថិតិទៅក្នុង meowDB - នេះគឺជាមូលដ្ឋានទិន្នន័យរបស់យើង ដែលអាចផ្ទុកម៉ែត្រផងដែរ។

បន្ទាប់មក យើងអាចធ្វើការជ្រើសរើស binary “near-SQL” ពីកូដ។

ពិសោធន៍

នៅរដូវក្តៅឆ្នាំ 2018 យើងមានកម្មវិធី hackathon ខាងក្នុង ហើយគំនិតនេះបានកើតឡើងដើម្បីព្យាយាមជំនួសផ្នែកក្រហមនៃដ្យាក្រាមជាមួយនឹងអ្វីមួយដែលអាចរក្សាទុកម៉ែត្រនៅក្នុង ClickHouse ។ យើងមានកំណត់ហេតុនៅលើ ClickHouse - ហេតុអ្វីមិនសាកល្បងវា?

យើងមានគ្រោងការណ៍ដែលសរសេរកំណត់ហេតុតាមរយៈ KittenHouse ។

យើង​បាន​សំរេចចិត្ត បន្ថែម "* ផ្ទះ" ផ្សេងទៀតទៅក្នុងដ្យាក្រាមដែល​នឹង​ទទួល​បាន​ម៉ែត្រ​ក្នុង​ទ្រង់ទ្រាយ​ដូច​ដែល​កូដ​របស់​យើង​សរសេរ​វា​តាម UDP។ បន្ទាប់មក * ផ្ទះនេះបង្វែរពួកវាទៅជាធាតុបញ្ចូល ដូចជាកំណត់ហេតុ ដែល KittenHouse យល់។ គាត់អាចបញ្ជូនកំណត់ហេតុទាំងនេះយ៉ាងល្អឥតខ្ចោះទៅ ClickHouse ដែលគួរតែអាចអានវាបាន។

គ្រោងការណ៍ដែលមាន memcache, stats-daemon និង logs-collectors database ត្រូវបានជំនួសដោយមួយនេះ។

គ្រោងការណ៍ដែលមាន memcache, stats-daemon និង logs-collectors database ត្រូវបានជំនួសដោយមួយនេះ។

• មានការបញ្ជូនពីកូដនៅទីនេះ ដែលត្រូវបានសរសេរក្នុងមូលដ្ឋាននៅក្នុង StatsHouse ។
• StatsHouse សរសេរ UDP metrics ដែលបានបំប្លែងរួចជាស្រេចទៅក្នុង SQL inserts ទៅ KittenHouse ជាបាច់។
• KittenHouse បញ្ជូនពួកគេទៅ ClickHouse ។
• ប្រសិនបើយើងចង់អានពួកវា នោះយើងអានវាដោយឆ្លងកាត់ StatsHouse - ដោយផ្ទាល់ពី ClickHouse ដោយប្រើ SQL ធម្មតា។

តើនៅតែមាន ការពិសោធន៍ប៉ុន្តែយើងចូលចិត្តរបៀបដែលវាប្រែចេញ។ ប្រសិនបើយើងដោះស្រាយបញ្ហាជាមួយគ្រោងការណ៍នោះប្រហែលជាយើងនឹងប្តូរទៅវាទាំងស្រុង។ ដោយផ្ទាល់ខ្ញុំសង្ឃឹមថាដូច្នេះ។

គម្រោងនេះ មិនសន្សំជាតិដែក. ត្រូវការម៉ាស៊ីនមេតិចជាងមុន ទិន្នន័យស្ថិតិក្នុងស្រុក និងអ្នកប្រមូលកំណត់ហេតុមិនត្រូវការទេ ប៉ុន្តែ ClickHouse ទាមទារម៉ាស៊ីនមេធំជាងម៉ាស៊ីនមេនៅក្នុងគ្រោងការណ៍បច្ចុប្បន្ន។ ត្រូវការម៉ាស៊ីនមេតិចជាងមុន ប៉ុន្តែពួកវាត្រូវតែមានតម្លៃថ្លៃជាង និងខ្លាំងជាង.

ដាក់ពង្រាយ

ជាដំបូង សូមក្រឡេកមើលការដាក់ពង្រាយ PHP ។ យើងកំពុងអភិវឌ្ឍនៅក្នុង Git: ប្រើ GitLab и ក្រុមធីស៊ីធី។ សម្រាប់ការដាក់ពង្រាយ។ សាខាអភិវឌ្ឍន៍ត្រូវបានបញ្ចូលទៅក្នុងសាខាមេ ពីមេសម្រាប់ការសាកល្បង ពួកគេត្រូវបានបញ្ចូលទៅក្នុងដំណាក់កាល និងពីដំណាក់កាលទៅជាផលិតកម្ម។

មុនពេលដាក់ពង្រាយ សាខាផលិតកម្មបច្ចុប្បន្ន និងមុនត្រូវបានយក ហើយឯកសារខុសគ្នាត្រូវបានពិចារណានៅក្នុងពួកវា - ការផ្លាស់ប្តូរ៖ បង្កើត លុប ផ្លាស់ប្តូរ។ ការផ្លាស់ប្តូរនេះត្រូវបានកត់ត្រានៅក្នុង binlog នៃម៉ាស៊ីន copyfast ពិសេស ដែលអាចចម្លងការផ្លាស់ប្តូរយ៉ាងឆាប់រហ័សទៅកាន់ក្រុម server ទាំងមូលរបស់យើង។ អ្វី​ដែល​ត្រូវ​បាន​ប្រើ​នៅ​ទីនេះ​គឺ​មិន​មែន​ជា​ការ​ចម្លង​ដោយ​ផ្ទាល់, ប៉ុន្តែ ការចម្លងការនិយាយដើមនៅពេលដែលម៉ាស៊ីនមេមួយផ្ញើការផ្លាស់ប្តូរទៅកាន់អ្នកជិតខាងដែលនៅជិតបំផុតរបស់វា នោះទៅកាន់អ្នកជិតខាងរបស់ពួកគេ និងដូច្នេះនៅលើ។ នេះអនុញ្ញាតឱ្យអ្នកធ្វើបច្ចុប្បន្នភាពកូដក្នុងរយៈពេលរាប់សិប និងឯកតានៃវិនាទីនៅទូទាំងកងនាវាទាំងមូល។ នៅពេលដែលការផ្លាស់ប្តូរឈានដល់ការចម្លងក្នុងស្រុក វាអនុវត្តបំណះទាំងនេះទៅរបស់វា។ ប្រព័ន្ធឯកសារក្នុងស្រុក. Rollback ក៏ត្រូវបានអនុវត្តទៅតាមគ្រោងការណ៍ដូចគ្នាដែរ។

យើងក៏ដាក់ពង្រាយ kPHP យ៉ាងច្រើន ហើយវាក៏មានការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនផងដែរ។ Git នេះបើយោងតាមដ្យាក្រាមខាងលើ។ ចាប់តាំងពីនេះ។ ម៉ាស៊ីនមេ HTTP គោលពីរបន្ទាប់មកយើងមិនអាចបង្កើតភាពខុសគ្នាបានទេ - ការចេញផ្សាយប្រព័ន្ធគោលពីរមានទម្ងន់រាប់រយ MB ។ ដូច្នេះមានជម្រើសមួយផ្សេងទៀតនៅទីនេះ - កំណែត្រូវបានសរសេរទៅ binlog copyfast. ជាមួយនឹងការស្ថាបនានីមួយៗវាកើនឡើង ហើយក្នុងអំឡុងពេល rollback វាក៏កើនឡើងផងដែរ។ កំណែ បានចម្លងទៅម៉ាស៊ីនមេ. copyfasts ក្នុងស្រុកមើលឃើញថាកំណែថ្មីបានចូលទៅក្នុង binlog ហើយដោយការចម្លងការនិយាយដើមដូចគ្នា ពួកគេយកកំណែចុងក្រោយបំផុតនៃ binary សម្រាប់ខ្លួនគេដោយមិននឿយហត់ម៉ាស៊ីនមេរបស់យើង ប៉ុន្តែការចែកចាយបន្ទុកយ៉ាងប្រុងប្រយ័ត្នឆ្លងកាត់បណ្តាញ។ អ្វី​ដែល​បន្ទាប់​មក ការ​ចាប់​ផ្តើម​ឡើង​វិញ​ដ៏​គួរ​ឱ្យ​គោរព សម្រាប់កំណែថ្មី។

សម្រាប់ម៉ាស៊ីនរបស់យើង ដែលជាប្រព័ន្ធគោលពីរសំខាន់ផងដែរ គ្រោងការណ៍គឺស្រដៀងគ្នាខ្លាំងណាស់៖

• git សាខាមេ;
• គោលពីរនៅក្នុង .deb;
• កំណែត្រូវបានសរសេរទៅ binlog copyfast;
• ចម្លងទៅម៉ាស៊ីនមេ;
• ម៉ាស៊ីនមេទាញចេញ .dep ស្រស់;
• dpkg -i;
• ការ​ចាប់​ផ្ដើម​ឡើង​វិញ​យ៉ាង​ល្អ​ចំពោះ​កំណែ​ថ្មី។

ភាពខុសគ្នាគឺថាប្រព័ន្ធគោលពីររបស់យើងត្រូវបានខ្ចប់ក្នុងបណ្ណសារ .debហើយនៅពេលបូមចេញ dpkg -i ត្រូវបានដាក់នៅលើប្រព័ន្ធ។ ហេតុអ្វីបានជា kPHP ត្រូវបានដាក់ពង្រាយជាប្រព័ន្ធគោលពីរ ហើយម៉ាស៊ីនត្រូវបានដាក់ពង្រាយជា dpkg? វាបានកើតឡើងតាមរបៀបនោះ។ វាដំណើរការ - កុំប៉ះវា។

បណ្តាញភ្ជាប់មានប្រយោជន៍:

• រាយការណ៍ដោយ Anton Kiryushkin "អ្នកគ្រប់គ្រងប្រព័ន្ធ Vkontakte ។ យ៉ាងម៉េច?” ជាមួយនឹងព័ត៌មានលម្អិតអំពី copyfast និងការនិយាយដើម។
• រាយការណ៍ដោយ Yuri Nasretdinov "របៀបដែល VK បញ្ចូលទិន្នន័យទៅក្នុង CLickHouse ពីម៉ាស៊ីនមេរាប់ម៉ឺននាក់".
• របាយការណ៍របស់ខ្ញុំ "ស្ថាបត្យកម្មនៃគម្រោងដែលកំពុងរីកចម្រើនដោយប្រើឧទាហរណ៍នៃ VKontakte"ប៉ុន្តែតាមទស្សនៈនៃការអភិវឌ្ឍន៍ មិនមែនផ្នែករឹងទេ។

Alexey Akulovich គឺជាមនុស្សម្នាក់ក្នុងចំណោមអ្នកដែលជាផ្នែកមួយនៃគណៈកម្មាធិការកម្មវិធីជួយ PHP រុស្ស៊ី នៅថ្ងៃទី 17 ខែឧសភានឹងក្លាយជាព្រឹត្តិការណ៍ដ៏ធំបំផុតសម្រាប់អ្នកអភិវឌ្ឍន៍ PHP នាពេលថ្មីៗនេះ។ រកមើលអ្វីដែលជាកុំព្យូទ័រត្រជាក់ដែលយើងមាន វាគ្មិន (ពីរនាក់ក្នុងចំណោមពួកគេកំពុងអភិវឌ្ឍស្នូល PHP!) - ហាក់ដូចជាអ្វីមួយដែលអ្នកមិនអាចខកខានប្រសិនបើអ្នកសរសេរ PHP ។

ប្រភព: www.habr.com