ស្ថាបត្យកម្មសម្រាប់ការរក្សាទុក និងចែករំលែករូបថតនៅក្នុង Badoo

Artem Denisov ( bo0rsh201, Badoo)

Badoo គឺជាគេហទំព័រណាត់ជួបដ៏ធំបំផុតរបស់ពិភពលោក។ បច្ចុប្បន្នយើងមានអ្នកប្រើប្រាស់ចុះឈ្មោះប្រហែល 330 លាននាក់នៅទូទាំងពិភពលោក។ ប៉ុន្តែអ្វីដែលសំខាន់ជាងនេះទៅទៀតនៅក្នុងបរិបទនៃការសន្ទនារបស់យើងនាពេលបច្ចុប្បន្ននេះគឺថាយើងរក្សាទុករូបថតរបស់អ្នកប្រើប្រាស់ប្រហែល 3 petabytes។ ជារៀងរាល់ថ្ងៃអ្នកប្រើប្រាស់របស់យើងបានបង្ហោះរូបថតថ្មីប្រហែល 3,5 លាន ហើយការអានគឺប្រហែល 80 ពាន់សំណើក្នុងមួយវិនាទី. នេះគឺច្រើនណាស់សម្រាប់ផ្នែកខាងក្រោយរបស់យើង ហើយជួនកាលមានការលំបាកជាមួយបញ្ហានេះ។

ខ្ញុំនឹងនិយាយអំពីការរចនានៃប្រព័ន្ធនេះ ដែលរក្សាទុក និងផ្ញើរូបថតជាទូទៅ ហើយខ្ញុំនឹងមើលវាតាមទស្សនៈរបស់អ្នកអភិវឌ្ឍន៍។ វានឹងមានការសង្ខេបឡើងវិញអំពីរបៀបដែលវាអភិវឌ្ឍ ដែលខ្ញុំនឹងរៀបរាប់ពីចំណុចសំខាន់ៗ ប៉ុន្តែខ្ញុំនឹងនិយាយលម្អិតបន្ថែមទៀតអំពីដំណោះស្រាយដែលយើងកំពុងប្រើប្រាស់នាពេលបច្ចុប្បន្ននេះ។

ឥឡូវនេះសូមចាប់ផ្តើម។

ដូចដែលខ្ញុំបាននិយាយ នេះនឹងជាការរំលឹកឡើងវិញ ហើយដើម្បីចាប់ផ្តើមវានៅកន្លែងណាមួយ ចូរយើងយកឧទាហរណ៍ទូទៅបំផុត។

យើងមានកិច្ចការទូទៅមួយ យើងត្រូវទទួលយក រក្សាទុក និងផ្ញើរូបថតអ្នកប្រើប្រាស់។ ក្នុងទម្រង់នេះ ភារកិច្ចគឺទូទៅ យើងអាចប្រើអ្វីក៏បាន៖

• ការផ្ទុកពពកទំនើប,
• ដំណោះស្រាយប្រអប់មួយ ដែលក្នុងនោះក៏មានច្រើនដែរឥឡូវនេះ។
• យើងអាចដំឡើងម៉ាស៊ីនជាច្រើននៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យរបស់យើង ហើយដាក់ hard drive ធំៗនៅលើពួកវា ហើយរក្សាទុករូបថតនៅទីនោះ។

Badoo ជាប្រវត្តិសាស្ត្រ - ទាំងឥឡូវនេះ និងនៅពេលនោះ (នៅពេលវាទើបតែនៅក្មេង) - រស់នៅលើម៉ាស៊ីនមេរបស់វា នៅខាងក្នុង DCs របស់យើងផ្ទាល់។ ដូច្នេះ ជម្រើសនេះគឺល្អបំផុតសម្រាប់យើង។

យើងទើបតែបានយកម៉ាស៊ីនជាច្រើន ដោយហៅវាថា "រូបថត" ហើយយើងទទួលបានចង្កោមដែលរក្សាទុករូបថត។ ប៉ុន្តែវាហាក់ដូចជាបាត់អ្វីមួយ។ ដើម្បីឱ្យអ្វីៗដំណើរការបាន យើងត្រូវកំណត់ថាតើម៉ាស៊ីនណាដែលយើងនឹងរក្សាទុករូបថតមួយណា។ ហើយនៅទីនេះផងដែរ មិនចាំបាច់បើកអាមេរិកទេ។

យើងបន្ថែមវាលមួយចំនួនទៅក្នុងកន្លែងផ្ទុករបស់យើងជាមួយនឹងព័ត៌មានអំពីអ្នកប្រើប្រាស់។ នេះនឹងជាគន្លឹះបំបែក។ ក្នុងករណីរបស់យើង យើងបានហៅវាថា place_id ហើយលេខសម្គាល់កន្លែងនេះចង្អុលទៅកន្លែងដែលរូបថតរបស់អ្នកប្រើប្រាស់ត្រូវបានរក្សាទុក។ យើងធ្វើផែនទី។

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

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

នោះហើយជារបៀបដែលវាគឺសម្រាប់ពួកយើងសម្រាប់ពេលខ្លះ។

នេះគឺប្រហែលឆ្នាំ 2009 ។ ពួកគេបានដឹកជញ្ជូនរថយន្ត ...

ហើយនៅចំណុចខ្លះយើងចាប់ផ្តើមកត់សំគាល់ថាគ្រោងការណ៍នេះមានគុណវិបត្តិជាក់លាក់។ តើមានគុណវិបត្តិអ្វីខ្លះ?

ដំបូងបង្អស់សមត្ថភាពមានកំណត់។ យើង​មិន​អាច​ដាក់​ Hard Drive ច្រើន​ទៅ​លើ​ម៉ាស៊ីន​មេ​មួយ​តាម​ដែល​យើង​ចង់​បាន។ ហើយនេះបានក្លាយជាបញ្ហាជាក់លាក់មួយតាមពេលវេលា និងជាមួយនឹងការកើនឡើងនៃសំណុំទិន្នន័យ។

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

នេះគឺទាំងអស់សម្រាប់ឆ្នាំ 2009 ប៉ុន្តែជាគោលការណ៍ តម្រូវការទាំងនេះនៅតែពាក់ព័ន្ធសព្វថ្ងៃនេះ។ យើងមានការរំលឹកឡើងវិញ ដូច្នេះក្នុងឆ្នាំ 2009 អ្វីគ្រប់យ៉ាងគឺអាក្រក់ទាំងស្រុងជាមួយនឹងរឿងនេះ។

ហើយចំណុចចុងក្រោយគឺតម្លៃ។

តម្លៃគឺខ្ពស់ខ្លាំងណាស់នៅពេលនោះ ហើយយើងត្រូវរកមើលជម្រើសមួយចំនួនទៀត។ ទាំងនោះ។ យើងត្រូវប្រើប្រាស់កន្លែងទំនេរនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ និងម៉ាស៊ីនមេជាក់ស្តែង ដែលអ្វីៗទាំងអស់នេះស្ថិតនៅ។ ហើយវិស្វករប្រព័ន្ធរបស់យើងបានចាប់ផ្តើមការសិក្សាដ៏ធំមួយដែលក្នុងនោះពួកគេបានពិនិត្យមើលជម្រើសផ្សេងៗជាច្រើន។ ពួកគេក៏បានពិនិត្យមើលប្រព័ន្ធឯកសារជាក្រុមដូចជា PolyCeph និង Luster ផងដែរ។ មាន​បញ្ហា​ក្នុង​ការ​អនុវត្ត និង​ប្រតិបត្តិការ​ពិបាក​ខ្លាំង។ ពួកគេបានបដិសេធ។ យើងបានព្យាយាមភ្ជាប់សំណុំទិន្នន័យទាំងមូលតាមរយៈ NFS នៅលើរថយន្តនីមួយៗ ដើម្បីធ្វើមាត្រដ្ឋានវាឡើង។ ការអានក៏ដំណើរការមិនល្អ យើងបានសាកល្បងដំណោះស្រាយផ្សេងៗពីអ្នកលក់ផ្សេងៗគ្នា។

ហើយនៅទីបញ្ចប់ យើងបានដោះស្រាយលើការប្រើប្រាស់អ្វីដែលគេហៅថាបណ្តាញតំបន់ផ្ទុក។

ទាំងនេះគឺជា SHDs ធំដែលត្រូវបានរចនាឡើងជាពិសេសសម្រាប់ការរក្សាទុកទិន្នន័យដ៏ធំ។ ពួកវាជាធ្នើដែលមានថាសដែលត្រូវបានម៉ោននៅលើម៉ាស៊ីនទិន្នផលអុបទិកចុងក្រោយ។ នោះ។ យើងមានប្រភេទម៉ាស៊ីនមួយចំនួនតូច ហើយ SHDs ទាំងនេះដែលមានតម្លាភាពចំពោះតក្កវិជ្ជាបញ្ជូនរបស់យើង ឧ. សម្រាប់ nginx របស់យើង ឬនរណាម្នាក់ផ្សេងទៀតដើម្បីបម្រើសំណើសម្រាប់រូបថតទាំងនេះ។

ការសម្រេចចិត្តនេះមានគុណសម្បត្តិជាក់ស្តែង។ នេះគឺជា SHD ។ វាមានគោលបំណងរក្សាទុករូបថត។ វាមានប្រសិទ្ធភាពថោកជាងការបំពាក់ម៉ាស៊ីនជាមួយថាសរឹង។

បូកទីពីរ។

នេះគឺថាសមត្ថភាពបានក្លាយទៅជាធំជាងមុន, i.e. យើង​អាច​ផ្ទុក​ទំហំ​ផ្ទុក​ច្រើន​ទៀត​ក្នុង​ទំហំ​តូច​ជាង​នេះ។

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

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

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

ដើម្បីបង្កើនប្រសិទ្ធភាព យើងបានសម្រេចចិត្តនៅពេលនោះ ជាក់ស្តែងដើម្បីមើលទម្រង់ផ្ទុក - ជាទូទៅអ្វីដែលកំពុងកើតឡើង អ្វីដែលត្រូវការធ្វើឱ្យប្រសើរ។

ហើយនៅទីនេះអ្វីគ្រប់យ៉ាងលេងនៅក្នុងដៃរបស់យើង។

ខ្ញុំបាននិយាយរួចហើយនៅក្នុងស្លាយទី 80: យើងមានសំណើអាន 3,5 ពាន់ក្នុងមួយវិនាទីដែលមានតែ XNUMX លានបង្ហោះក្នុងមួយថ្ងៃ។ នោះគឺជា, នេះគឺជាភាពខុសគ្នានៃលំដាប់បីនៃរ៉ិចទ័រ។ វាច្បាស់ណាស់ថាការអានត្រូវតែធ្វើឱ្យប្រសើរឡើង ហើយវាច្បាស់ណាស់អំពីរបៀប។

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

ទាំងនោះ។ យើងមានសំណុំទិន្នន័យក្តៅតូចមួយ។ ប៉ុន្តែ​ទន្ទឹម​នឹង​នេះ​មាន​សំណើ​ជា​ច្រើន​សម្រាប់​គាត់។ ហើយដំណោះស្រាយជាក់ស្តែងនៅទីនេះគឺការបន្ថែមឃ្លាំងសម្ងាត់។

ឃ្លាំងសម្ងាត់ជាមួយ LRU នឹងដោះស្រាយបញ្ហាទាំងអស់របស់យើង។ ពួក​យើង​កំពុង​ធ្វើអ្វី​ហ្នឹង?

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

តើវាដំណើរការពីខាងក្នុងយ៉ាងដូចម្តេច? នេះគឺជាអ្នកប្រើប្រាស់របស់យើង នេះគឺជាកន្លែងផ្ទុក។ អ្វីគ្រប់យ៉ាងគឺដូចគ្នានឹងមុន។ តើយើងបន្ថែមអ្វីរវាង?

វាគ្រាន់តែជាម៉ាស៊ីនដែលមានឌីសក្នុងស្រុកដែលមានល្បឿនលឿន។ ឧទាហរណ៍នេះជាមួយ SSD ។ ហើយប្រភេទនៃឃ្លាំងសម្ងាត់មូលដ្ឋានមួយចំនួនត្រូវបានរក្សាទុកនៅលើថាសនេះ។

តើវាមើលទៅដូចអ្វី? អ្នកប្រើប្រាស់ផ្ញើសំណើសុំរូបថត។ NGINX ស្វែងរកវាជាលើកដំបូងនៅក្នុងឃ្លាំងសម្ងាត់មូលដ្ឋាន។ ប្រសិនបើមិនមែនទេ នោះគ្រាន់តែ proxy_pass ទៅកាន់កន្លែងផ្ទុករបស់យើង ទាញយករូបថតពីទីនោះ ហើយផ្តល់ឱ្យវាទៅអ្នកប្រើប្រាស់។

ប៉ុន្តែ​រឿង​មួយ​នេះ​គឺ​សាហាវ​ណាស់ ហើយ​វា​មិន​ច្បាស់​ថា​មាន​អ្វី​កើត​ឡើង​នៅ​ខាង​ក្នុង​នោះ​ទេ។ វាដំណើរការអ្វីមួយដូចនេះ។

ឃ្លាំងសម្ងាត់ត្រូវបានបែងចែកជាបីស្រទាប់។ នៅពេលខ្ញុំនិយាយថា "បីស្រទាប់" នេះមិនមានន័យថាមានប្រព័ន្ធស្មុគស្មាញមួយចំនួននោះទេ។ ទេ ទាំងនេះគឺគ្រាន់តែជាថតបីនៅក្នុងប្រព័ន្ធឯកសារប៉ុណ្ណោះ៖

1. នេះគឺជាបណ្តុំដែលរូបថតទើបតែទាញយកពីប្រូកស៊ីទៅ។
2. នេះគឺជាឃ្លាំងសម្ងាត់ក្តៅដែលរក្សាទុករូបថតដែលបានស្នើសុំយ៉ាងសកម្មនាពេលបច្ចុប្បន្ន។
3. និងឃ្លាំងសម្ងាត់ត្រជាក់ ដែលរូបថតត្រូវបានរុញចេញពីឃ្លាំងសម្ងាត់ជាបណ្តើរៗ នៅពេលដែលសំណើតិចជាងមុនមករកពួកគេ។

ដើម្បីឱ្យវាដំណើរការ យើងត្រូវគ្រប់គ្រងឃ្លាំងសម្ងាត់នេះ យើងត្រូវរៀបចំរូបថតនៅក្នុងវាឡើងវិញ។ល។ នេះក៏ជាដំណើរការដំបូងបំផុតផងដែរ។

Nginx គ្រាន់តែសរសេរទៅកាន់ RAMDisk access.log សម្រាប់សំណើនីមួយៗ ដែលវាបង្ហាញពីផ្លូវទៅកាន់រូបថតដែលវាបានបម្រើនាពេលនេះ (ជាការពិតណាស់ ផ្លូវទាក់ទង) និងភាគថាសណាដែលវាត្រូវបានបម្រើ។ ទាំងនោះ។ វាអាចនិយាយថា "រូបថតទី 1" ហើយបន្ទាប់មកទាំងសតិបណ្ដោះអាសន្ន ឬឃ្លាំងសម្ងាត់ក្តៅ ឬឃ្លាំងសម្ងាត់ត្រជាក់ ឬប្រូកស៊ី។

អាស្រ័យលើនេះ យើងត្រូវសម្រេចចិត្តថាត្រូវធ្វើអ្វីជាមួយរូបថត។

យើងមានដេមិនតូចមួយដែលកំពុងដំណើរការនៅលើម៉ាស៊ីននីមួយៗដែលអានកំណត់ហេតុនេះជានិច្ច ហើយរក្សាទុកស្ថិតិអំពីការប្រើប្រាស់រូបថតមួយចំនួននៅក្នុងអង្គចងចាំរបស់វា។

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

រូបថតដែលត្រូវបានស្នើសុំកម្រ និងត្រូវបានស្នើសុំតិចជាញឹកញាប់ត្រូវបានរុញចេញជាបណ្តើរៗចេញពីឃ្លាំងសម្ងាត់ក្តៅចូលទៅក្នុងកន្លែងត្រជាក់។

ហើយនៅពេលដែលយើងអស់ទំហំផ្ទុកនៅក្នុងឃ្លាំងសម្ងាត់ យើងគ្រាន់តែចាប់ផ្តើមលុបអ្វីៗទាំងអស់ចេញពីឃ្លាំងសម្ងាត់ត្រជាក់ដោយមិនរើសអើង។ ហើយដោយវិធីនេះដំណើរការល្អ។

ដើម្បីឱ្យរូបថតត្រូវបានរក្សាទុកភ្លាមៗនៅពេលប្រូកស៊ីវាទៅសតិបណ្ដោះអាសន្ន យើងប្រើការណែនាំ proxy_store ហើយសតិបណ្ដោះអាសន្នក៏ជា RAMDisk ដែរ i.e. សម្រាប់អ្នកប្រើប្រាស់ វាដំណើរការលឿនណាស់។ វាទាក់ទងនឹងផ្នែកខាងក្នុងនៃម៉ាស៊ីនមេឃ្លាំងសម្ងាត់ខ្លួនឯង។

សំណួរដែលនៅសល់គឺរបៀបចែកចាយសំណើនៅទូទាំងម៉ាស៊ីនមេទាំងនេះ។

ចូរនិយាយថាមានចង្កោមនៃម៉ាស៊ីនផ្ទុកចំនួនម្ភៃ និងម៉ាស៊ីនបម្រើឃ្លាំងសម្ងាត់ចំនួនបី (នេះជារបៀបដែលវាកើតឡើង)។

យើង​ត្រូវ​កំណត់​ថា​តើ​សំណើ​ណា​មួយ​សម្រាប់​រូបថត​មួយ​ណា និង​កន្លែង​ណា​ដែល​ត្រូវ​បញ្ជូន​វា​ទៅ​កាន់។

ជម្រើសទូទៅបំផុតគឺ Round Robin ។ ឬធ្វើវាដោយចៃដន្យ?

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

យើង​ត្រូវ​កំណត់​ដោយ​មិន​ច្បាស់​លាស់​ថា​តើ​ម៉ាស៊ីន​មេ​មួយ​ណា​ត្រូវ​ចុះចត​សំណើ​មួយ​ណា។

មានវិធីហាមឃាត់។ យើងយក hash ពី URL ឬ hash ពី sharding key របស់យើងដែលមាននៅក្នុង URL ហើយចែកវាតាមចំនួន servers ។ នឹង​ធ្វើការ? នឹង។

ទាំងនោះ។ យើងមានសំណើ 2% ជាឧទាហរណ៍ សម្រាប់ "example_url" មួយចំនួន វានឹងតែងតែចុះចតនៅលើម៉ាស៊ីនមេដែលមានលិបិក្រម "XNUMX" ហើយឃ្លាំងសម្ងាត់នឹងត្រូវបោះចោលជាបន្តបន្ទាប់តាមដែលអាចធ្វើទៅបាន។

ប៉ុន្តែ​មាន​បញ្ហា​ជាមួយ​នឹង​ការ​បន្ត​ក្នុង​គ្រោងការណ៍​បែប​នេះ។ Resharding - ខ្ញុំមានន័យថាផ្លាស់ប្តូរចំនួនម៉ាស៊ីនមេ។

ឧបមាថា ចង្កោមឃ្លាំងសម្ងាត់របស់យើងមិនអាចដោះស្រាយបានទៀតទេ ហើយយើងសម្រេចចិត្តបន្ថែមម៉ាស៊ីនមួយទៀត។

តោះបន្ថែម។

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

ជម្រើសនេះក៏មិនសមនឹងយើងដែរ។

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

តើវាមើលទៅដូចអ្វី?

យើងយកមុខងារមួយចំនួនពី sharding key ហើយរីករាលដាលតម្លៃរបស់វាទាំងអស់នៅលើរង្វង់។ ទាំងនោះ។ នៅចំណុច 0 តម្លៃអប្បបរមា និងអតិបរមារបស់វាបញ្ចូលគ្នា។ បន្ទាប់មក យើងដាក់ម៉ាស៊ីនមេរបស់យើងទាំងអស់នៅលើរង្វង់ដូចគ្នាតាមរបៀបនេះ៖

ម៉ាស៊ីនមេនីមួយៗត្រូវបានកំណត់ដោយចំណុចមួយ ហើយវិស័យដែលដំណើរការតាមទ្រនិចនាឡិកាទៅវា អាស្រ័យហេតុនេះ ត្រូវបានបម្រើដោយម៉ាស៊ីននេះ។ នៅពេលដែលសំណើមកដល់យើង យើងឃើញភ្លាមៗនោះ ឧទាហរណ៍ សំណើ A - វាមាន hash នៅទីនោះ - ហើយវាត្រូវបានបម្រើដោយ server 2. Request B - ដោយ server 3. ហើយដូច្នេះនៅលើ។

តើមានអ្វីកើតឡើងក្នុងស្ថានភាពនេះ កំឡុងពេលបញ្ជូនបន្ត?

យើងមិនធ្វើឱ្យឃ្លាំងសម្ងាត់ទាំងមូលមានសុពលភាពដូចពីមុនទេ ហើយមិនប្តូរសោទាំងអស់នោះទេ ប៉ុន្តែយើងប្តូរផ្នែកនីមួយៗនៅចម្ងាយខ្លី ដូច្នេះបើនិយាយឱ្យចំទៅម៉ាស៊ីនមេទីប្រាំមួយរបស់យើងដែលយើងចង់បន្ថែម សមនឹងទំហំទំនេរ និង យើងបន្ថែមវានៅទីនោះ។

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

សំណួរតែមួយគត់នៅតែមានជាមួយនឹងការបដិសេធ។ ឧបមាថា រថយន្តប្រភេទខ្លះអស់សណ្តាប់ធ្នាប់។

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

នេះនិយាយអំពីប្រព័ន្ធឃ្លាំងសម្ងាត់។ តោះមើលលទ្ធផល។

វាហាក់ដូចជាមិនមានអ្វីស្មុគស្មាញនៅទីនេះទេ។ ប៉ុន្តែវិធីសាស្រ្តនៃការគ្រប់គ្រងឃ្លាំងសម្ងាត់នេះបានផ្តល់ឱ្យយើងនូវអត្រាល្បិចប្រហែល 98% ។ ទាំងនោះ។ ក្នុងចំណោមសំណើ 80 ពាន់នេះក្នុងមួយវិនាទីមានតែ 1600 ឈានដល់ការផ្ទុកហើយនេះគឺជាបន្ទុកធម្មតាទាំងស្រុងពួកគេស៊ូទ្រាំវាដោយស្ងប់ស្ងាត់យើងតែងតែមានទុនបំរុង។

យើងបានដាក់ម៉ាស៊ីនមេទាំងនេះនៅក្នុង DCs របស់យើងចំនួនបី ហើយទទួលបានវត្តមានចំនួនបីគឺ Prague, Miami និង Hong Kong។

នោះ។ ពួកវាមានទីតាំងនៅក្នុងមូលដ្ឋានច្រើន ឬតិចទៅកាន់ទីផ្សារគោលដៅនីមួយៗរបស់យើង។

ហើយជាប្រាក់រង្វាន់ដ៏ល្អ យើងទទួលបានប្រូកស៊ីឃ្លាំងសម្ងាត់នេះ ដែលស៊ីភីយូពិតជាទំនេរ ព្រោះវាមិនចាំបាច់ក្នុងការបម្រើមាតិកានោះទេ។ ហើយនៅទីនោះ ដោយប្រើ NGINX+ Lua យើងបានអនុវត្តតក្កវិជ្ជា utilitarian ជាច្រើន។

ឧទាហរណ៍ យើងអាចសាកល្បងជាមួយ webp ឬ jpeg ដែលកំពុងរីកចម្រើន (ទាំងនេះគឺជាទម្រង់ទំនើបដ៏មានប្រសិទ្ធភាព) សូមមើលពីរបៀបដែលវាប៉ះពាល់ដល់ចរាចរណ៍ ធ្វើការសម្រេចចិត្តមួយចំនួន បើកវាសម្រាប់ប្រទេសមួយចំនួន។ល។ ធ្វើការផ្លាស់ប្តូរទំហំថាមវន្ត ឬកាត់រូបថតភ្លាមៗ។

នេះជាករណីប្រើប្រាស់ដ៏ល្អ នៅពេលដែលឧទាហរណ៍ អ្នកមានកម្មវិធីទូរស័ព្ទដែលបង្ហាញរូបថត ហើយកម្មវិធីទូរស័ព្ទមិនចង់ខ្ជះខ្ជាយ CPU របស់អតិថិជនក្នុងការស្នើសុំរូបថតធំមួយ ហើយបន្ទាប់មកប្តូរទំហំវាទៅទំហំជាក់លាក់មួយ ដើម្បីរុញវាចូលទៅក្នុង ទេសភាព។ យើងអាចបញ្ជាក់យ៉ាងសាមញ្ញនូវប៉ារ៉ាម៉ែត្រមួយចំនួននៅក្នុង URL លក្ខខណ្ឌ UPport ហើយឃ្លាំងសម្ងាត់រូបថតនឹងផ្លាស់ប្តូរទំហំរូបថតដោយខ្លួនឯង។ តាមក្បួន វានឹងជ្រើសរើសទំហំដែលយើងមាននៅលើឌីស ឱ្យជិតតាមដែលអាចធ្វើបានទៅនឹងការស្នើសុំ ហើយលក់វាក្នុងកូអរដោណេជាក់លាក់។

ដោយវិធីនេះ យើងបានបង្កើតការថតវីដេអូជាសាធារណៈនៃរយៈពេលប្រាំឆ្នាំចុងក្រោយនៃសន្និសិទរបស់អ្នកអភិវឌ្ឍន៍ប្រព័ន្ធផ្ទុកខ្ពស់ ការផ្ទុកខ្ពស់ ++. មើល រៀន ចែករំលែក និងជាវ ឆានែលយូធូប.

យើងក៏អាចបន្ថែមតក្កវិជ្ជាផលិតផលជាច្រើននៅទីនោះផងដែរ។ ជាឧទាហរណ៍ យើងអាចបន្ថែម watermarks ផ្សេងៗដោយប្រើប៉ារ៉ាម៉ែត្រ URL យើងអាចធ្វើព្រិល ព្រិល ឬ pixelate រូបថត។ នេះគឺជាពេលដែលយើងចង់បង្ហាញរូបថតរបស់មនុស្ស ប៉ុន្តែយើងមិនចង់បង្ហាញមុខរបស់គាត់ វាដំណើរការបានល្អ វាត្រូវបានអនុវត្តនៅទីនេះ។

តើយើងទទួលបានអ្វីខ្លះ? យើងទទួលបានបីពិន្ទុនៃវត្តមាន អត្រាល្បិចដ៏ល្អ ហើយក្នុងពេលជាមួយគ្នានេះ យើងមិនមានស៊ីភីយូទំនេរនៅលើម៉ាស៊ីនទាំងនេះទេ។ ឥឡូវនេះ គាត់បានក្លាយជាមនុស្សសំខាន់ជាងពីមុន។ យើងត្រូវផ្តល់ឱ្យខ្លួនយើងនូវរថយន្តដែលខ្លាំងជាងប៉ុន្តែវាមានតម្លៃវា។

នេះទាក់ទងនឹងការត្រឡប់មកវិញនៃរូបថត។ អ្វីគ្រប់យ៉ាងនៅទីនេះគឺច្បាស់និងច្បាស់។ ខ្ញុំគិតថាខ្ញុំមិនបានរកឃើញអាមេរិចទេ ស្ទើរតែគ្រប់ CDN ធ្វើការតាមរបៀបនេះ។

ហើយភាគច្រើនទំនងជាអ្នកស្តាប់ដែលស្មុគ្រស្មាញអាចមានសំណួរមួយ៖ ហេតុអ្វីមិនគ្រាន់តែផ្លាស់ប្តូរអ្វីៗទាំងអស់ទៅជា CDN? វានឹងដូចគ្នាដែរ CDNs ទំនើបទាំងអស់អាចធ្វើវាបាន។ ហើយមានហេតុផលមួយចំនួន។

ទីមួយគឺរូបថត។

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

ខ្ញុំសូមផ្តល់ឧទាហរណ៍មួយដល់អ្នក។ ឥឡូវនេះ ជាមួយនឹងហេដ្ឋារចនាសម្ព័ន្ធរបស់យើង យើងអាចឧទាហរណ៍ ក្នុងករណីមានបញ្ហាមួយចំនួន ឬការគោះនៅក្រោមដី សូមចូលទៅកាន់ម៉ាស៊ីន ហើយរញ៉េរញ៉ៃនៅទីនោះ ដោយនិយាយទាក់ទងគ្នា។ យើងអាចបន្ថែមការប្រមូលផ្តុំនៃម៉ែត្រមួយចំនួនដែលយើងត្រូវការតែប៉ុណ្ណោះ យើងអាចពិសោធន៍ដូចម្ដេចបាន សូមមើលពីរបៀបដែលវាប៉ះពាល់ដល់ក្រាហ្វ។ល។ ឥឡូវនេះស្ថិតិជាច្រើនកំពុងត្រូវបានប្រមូលនៅលើចង្កោមឃ្លាំងសម្ងាត់នេះ។ ហើយ​យើង​ពិនិត្យ​មើល​វា​ជា​ទៀងទាត់ ហើយ​ចំណាយ​ពេល​យ៉ាង​យូរ​ដើម្បី​ស្វែង​រក​ភាព​មិន​ប្រក្រតី​មួយ​ចំនួន។ ប្រសិនបើវាស្ថិតនៅខាង CDN វានឹងកាន់តែពិបាកគ្រប់គ្រង។ ឬឧទាហរណ៍ប្រសិនបើឧបទ្ទវហេតុណាមួយកើតឡើងយើងដឹងពីអ្វីដែលបានកើតឡើងយើងដឹងពីរបៀបរស់នៅជាមួយវានិងវិធីយកឈ្នះវា។ នេះគឺជាការសន្និដ្ឋានដំបូង។

ការសន្និដ្ឋានទីពីរក៏ជាប្រវត្តិសាស្ត្រដែរ ពីព្រោះប្រព័ន្ធបាននិងកំពុងអភិវឌ្ឍជាយូរណាស់មកហើយ ហើយមានតម្រូវការអាជីវកម្មផ្សេងៗគ្នាជាច្រើននៅដំណាក់កាលផ្សេងៗគ្នា ហើយវាមិនតែងតែសមនឹងគំនិត CDN នោះទេ។

ហើយ​ចំណុច​បន្ទាប់​ពី​ចំណុច​មុន​គឺ​

នេះដោយសារតែនៅលើឃ្លាំងសម្ងាត់រូបថត យើងមានតក្កវិជ្ជាជាក់លាក់ជាច្រើន ដែលមិនអាចបន្ថែមតាមការស្នើសុំបាន។ វាមិនទំនងថា CDN ណាមួយនឹងបន្ថែមវត្ថុផ្ទាល់ខ្លួនមួយចំនួនដល់អ្នកតាមសំណើរបស់អ្នក។ ឧទាហរណ៍ ការអ៊ិនគ្រីប URLs ប្រសិនបើអ្នកមិនចង់ឱ្យម៉ាស៊ីនភ្ញៀវអាចផ្លាស់ប្តូរអ្វីមួយបាន។ តើអ្នកចង់ផ្លាស់ប្តូរ URL នៅលើម៉ាស៊ីនមេ និងអ៊ិនគ្រីបវា ហើយបន្ទាប់មកផ្ញើប៉ារ៉ាម៉ែត្រថាមវន្តមួយចំនួននៅទីនេះ។

តើការសន្និដ្ឋាននេះបង្ហាញអ្វីខ្លះ? ក្នុងករណីរបស់យើង CDN មិនមែនជាជម្រើសដ៏ល្អទេ។

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

ប៉ុន្តែប្រសិនបើអ្នកមានដំណោះស្រាយទូទៅមួយចំនួន ហើយកិច្ចការមិនជាក់លាក់ទេ អ្នកអាចយក CDN ដោយសុវត្ថិភាព។ ឬប្រសិនបើពេលវេលា និងធនធានមានសារៈសំខាន់សម្រាប់អ្នកជាងការគ្រប់គ្រង។

ហើយ CDNs ទំនើបមានអ្វីៗស្ទើរតែទាំងអស់ដែលខ្ញុំបានប្រាប់អ្នកឥឡូវនេះ។ លើកលែងតែមុខងារបូក ឬដកមួយចំនួន។

នេះគឺអំពីការផ្តល់ឱ្យរូបថត។

ឥឡូវ​នេះ​យើង​បន្ត​ដំណើរ​ទៅ​មុខ​បន្តិច​ក្នុង​ការ​មើល​ក្រោយ​របស់​យើង ហើយ​និយាយ​អំពី​ទំហំ​ផ្ទុក។

ឆ្នាំ 2013 បានកន្លងផុតទៅ។

ម៉ាស៊ីនមេឃ្លាំងសម្ងាត់ត្រូវបានបន្ថែម បញ្ហាដំណើរការបានបាត់ទៅ។ អ្វីគ្រប់យ៉ាងគឺល្អ។ សំណុំទិន្នន័យកំពុងកើនឡើង។ គិតត្រឹមឆ្នាំ 2013 យើងមានម៉ាស៊ីនមេប្រហែល 80 តភ្ជាប់ទៅកន្លែងផ្ទុក ហើយប្រហែល 40 ឃ្លាំងសម្ងាត់នៅក្នុង DC នីមួយៗ។ នេះគឺជាទិន្នន័យ 560 terabytes នៅលើ DC នីមួយៗ ពោលគឺឧ។ សរុបប្រហែលមួយ petabyte ។

ហើយជាមួយនឹងការកើនឡើងនៃសំណុំទិន្នន័យ ការចំណាយប្រតិបត្តិការបានចាប់ផ្តើមកើនឡើងយ៉ាងខ្លាំង។ តើនេះមានន័យយ៉ាងណា?

នៅក្នុងដ្យាក្រាមនេះដែលត្រូវបានគូរ - ជាមួយ SAN ជាមួយនឹងម៉ាស៊ីននិងឃ្លាំងសម្ងាត់ភ្ជាប់ទៅវា - មានចំណុចជាច្រើននៃការបរាជ័យ។ ប្រសិនបើ​យើង​បាន​ដោះស្រាយ​ការ​បរាជ័យ​នៃ​ម៉ាស៊ីន​បម្រើ​ឃ្លាំង​សម្ងាត់​ពីមុន​រួច​ហើយ អ្វីៗ​គឺ​អាច​ព្យាករណ៍​បាន​ច្រើន ឬ​តិច និង​អាច​យល់​បាន ប៉ុន្តែ​នៅ​ផ្នែក​ផ្ទុក​អ្វីៗ​គឺ​កាន់តែ​អាក្រក់​ទៅៗ។

ទីមួយបណ្តាញតំបន់ផ្ទុក (SAN) ខ្លួនឯងដែលអាចបរាជ័យ។

ទីពីរវាត្រូវបានភ្ជាប់តាមរយៈអុបទិកទៅម៉ាស៊ីនបញ្ចប់។ ប្រហែលជាមានបញ្ហាជាមួយកាតអុបទិក និងប៊ូហ្ស៊ី។

ជាការពិតណាស់ មានពួកគេមិនច្រើនដូច SAN ផ្ទាល់នោះទេ ប៉ុន្តែទោះជាយ៉ាងណា ទាំងនេះក៏ជាចំណុចនៃការបរាជ័យផងដែរ។

បន្ទាប់គឺម៉ាស៊ីនខ្លួនឯងដែលត្រូវបានភ្ជាប់ទៅនឹងកន្លែងផ្ទុក។ វាក៏អាចបរាជ័យផងដែរ។

សរុបមក យើងមាន ៣ ពិន្ទុនៃការបរាជ័យ។

លើសពីនេះ បន្ថែមពីលើចំណុចនៃការបរាជ័យ វាមានការថែរក្សាយ៉ាងធ្ងន់ធ្ងរនៃកន្លែងផ្ទុកដោយខ្លួនឯង។

នេះគឺជាប្រព័ន្ធពហុសមាសភាគដ៏ស្មុគស្មាញ ហើយវិស្វករប្រព័ន្ធអាចមានការលំបាកក្នុងការធ្វើការជាមួយវា។

ហើយចុងក្រោយ ចំណុចសំខាន់បំផុត។ ប្រសិនបើការបរាជ័យកើតឡើងនៅចំណុចណាមួយក្នុងចំណោមចំណុចទាំងបីនេះ យើងមានឱកាសមិនសូន្យក្នុងការបាត់បង់ទិន្នន័យអ្នកប្រើប្រាស់ ព្រោះប្រព័ន្ធឯកសារអាចនឹងគាំង។

ឧបមាថាប្រព័ន្ធឯកសាររបស់យើងខូច។ ទីមួយ ការងើបឡើងវិញរបស់វាត្រូវចំណាយពេលយូរ - វាអាចចំណាយពេលមួយសប្តាហ៍ជាមួយនឹងចំនួនទិន្នន័យច្រើន។ ហើយទីពីរ នៅទីបញ្ចប់ យើងទំនងជានឹងបញ្ចប់ជាមួយនឹងបណ្តុំនៃឯកសារដែលមិនអាចយល់បាន ដែលនឹងត្រូវបញ្ចូលទៅក្នុងរូបថតអ្នកប្រើប្រាស់។ ហើយយើងប្រថុយនឹងការបាត់បង់ទិន្នន័យ។ ហានិភ័យគឺខ្ពស់ណាស់។ ហើយស្ថានភាពបែបនេះកាន់តែច្រើនកើតឡើង ហើយបញ្ហាកាន់តែច្រើនកើតឡើងនៅក្នុងខ្សែសង្វាក់ទាំងមូលនេះ ហានិភ័យនេះកាន់តែខ្ពស់។

មានអ្វីមួយត្រូវធ្វើអំពីរឿងនេះ។ ហើយយើងបានសម្រេចចិត្តថាយើងគ្រាន់តែត្រូវការបម្រុងទុកទិន្នន័យប៉ុណ្ណោះ។ នេះពិតជាដំណោះស្រាយជាក់ស្តែង និងជាដំណោះស្រាយដ៏ល្អមួយ។ តើយើងបានធ្វើអ្វី?

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

យើងទើបតែបានបន្ថែមផ្នែកទីពីរ។

យើងបានដាក់កន្លែងផ្ទុកទីពីរនៅជាប់វា (ជាសំណាងល្អ វាមិនថ្លៃទេបើនិយាយពីលុយ) ហើយបានហៅវាថាជាភាគថាសបម្រុងទុក។ វាក៏ត្រូវបានភ្ជាប់តាមរយៈអុបទិក និងមានទីតាំងនៅលើម៉ាស៊ីនដូចគ្នា។ ប៉ុន្តែយើងត្រូវធ្វើសមកាលកម្មទិន្នន័យរវាងពួកវាតាមរបៀបណាមួយ។

នៅទីនេះយើងគ្រាន់តែបង្កើតជួរអសមកាលនៅក្បែរនោះ។

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

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

ប៉ុន្តែ​ដោយ​សារ​តែ​កត្តា​នេះ​ហើយ​ទើប​ការ​អាន​កើន​ឡើង​យ៉ាង​ខ្លាំង​ព្រោះ... បន្ថែមលើអតិថិជនដែលបានអានពីផ្នែកសំខាន់ ព្រោះពួកគេមើលរូបថតនៅទីនោះជាមុនសិន (វាថ្មីៗនៅទីនោះ) ហើយបន្ទាប់មករកមើលវានៅលើការបម្រុងទុក ប្រសិនបើពួកគេមិនបានរកឃើញវា (ប៉ុន្តែ NGINX គ្រាន់តែធ្វើវា) ប្រព័ន្ធរបស់យើងក៏ជាការបម្រុងទុកបូកផងដែរឥឡូវនេះអានពីភាគថាសសំខាន់។ វា​មិនមែន​ថា​នេះ​ជា​ការ​ស្ទះ​ទេ ប៉ុន្តែ​ខ្ញុំ​មិន​ចង់​បង្កើន​បន្ទុក​ទេ ជា​សំខាន់​ដូច​នោះ។

ហើយ​យើង​បាន​បន្ថែម​ថាស​ទី​បី ដែល​ជា SSD តូច ហើយ​បាន​ហៅ​វា​ថា​ជា​សតិបណ្ដោះ​អាសន្ន។

របៀបដែលវាដំណើរការឥឡូវនេះ។

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

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

ជាការប្រសើរណាស់ ហើយសំខាន់បំផុត៖ យើងឈប់បាត់បង់ទិន្នន័យ។

ចូរនិយាយថាយើងឈប់ សក្តានុពល បាត់បង់ទិន្នន័យ ព្រោះយើងពិតជាមិនបាត់បង់វាទេ។ ប៉ុន្តែ​មាន​គ្រោះថ្នាក់។ យើងឃើញថាដំណោះស្រាយនេះគឺល្អ ប៉ុន្តែវាដូចជាការបំបាត់រោគសញ្ញានៃបញ្ហានេះបន្តិច ជំនួសឱ្យការដោះស្រាយទាំងស្រុង។ ហើយបញ្ហាមួយចំនួននៅតែមាននៅទីនេះ។

ទីមួយនេះគឺជាចំណុចនៃការបរាជ័យនៅក្នុងទម្រង់នៃម៉ាស៊ីនរាងកាយដែលគ្រឿងចក្រទាំងអស់ដំណើរការ វាមិនបាត់ទៅណាទេ។

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

ហើយយើងបានបង្កើតកំណែទីបី (ជាការពិតទីពីរនៅក្នុងការពិត) - កំណែកក់។ តើវាមើលទៅដូចអ្វី?

នេះគឺជាអ្វីដែលវាគឺជា -

បញ្ហាចម្បងរបស់យើងគឺជាមួយនឹងការពិតដែលថានេះគឺជាម៉ាស៊ីនរាងកាយ។

ទីមួយ យើងដក SAN ចេញព្រោះយើងចង់ពិសោធន៍ យើងចង់សាកល្បងគ្រាន់តែ hard drive ក្នុងស្រុកប៉ុណ្ណោះ។

នេះគឺរួចទៅហើយ 2014-2015 ហើយនៅពេលនោះស្ថានភាពជាមួយថាសនិងសមត្ថភាពរបស់ពួកគេនៅក្នុងម៉ាស៊ីនតែមួយបានប្រសើរឡើងច្រើន។ យើងបានសម្រេចចិត្តថាហេតុអ្វីមិនសាកល្បងវា។

ហើយបន្ទាប់មកយើងគ្រាន់តែយកភាគថាសបម្រុងទុករបស់យើង ហើយផ្ទេរវាទៅម៉ាស៊ីនដាច់ដោយឡែក។

ដូច្នេះយើងទទួលបានដ្យាក្រាមនេះ។ យើងមានរថយន្តពីរដែលរក្សាទុកសំណុំទិន្នន័យដូចគ្នា។ ពួកគេបម្រុងទុកគ្នាទៅវិញទៅមកទាំងស្រុង និងធ្វើសមកាលកម្មទិន្នន័យនៅលើបណ្តាញតាមរយៈជួរអសមកាលនៅក្នុង MySQL ដូចគ្នា។

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

តើ​វា​ដំណើរ​ការ​យ៉ាង​ណា បើ​មើល​ឲ្យ​បាន​លម្អិត​បន្តិច។

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

ភារកិច្ចគឺពិបាកជាងបន្តិច។

Lua បានជួយពួកយើងនៅទីនេះ ព្រោះវាអាចជាការលំបាកក្នុងការបង្កើតតក្កវិជ្ជាបែបនេះនៅលើ vanilla NGINX ។ យើងធ្វើការស្នើរសុំទៅកាន់ម៉ាស៊ីនមេដំបូង ពិនិត្យមើលថាតើរូបថតនៅទីនោះឬអត់ ពីព្រោះវាអាចផ្ទុកឡើងឧទាហរណ៍ទៅកាន់អ្នកជិតខាង ប៉ុន្តែមិនទាន់មកដល់ទីនេះទេ។ ប្រសិនបើរូបថតនៅទីនោះ នោះជាការល្អ។ យើងប្រគល់វាទៅអតិថិជនភ្លាមៗ ហើយប្រហែលជាទុកវាចោល។

ប្រសិនបើវាមិននៅទីនោះទេ យើងគ្រាន់តែស្នើសុំទៅអ្នកជិតខាងរបស់យើង ហើយត្រូវបានធានាថានឹងទទួលបានវាពីទីនោះ។

នោះ។ យើងអាចនិយាយម្តងទៀត៖ វាអាចមានបញ្ហាជាមួយនឹងការអនុវត្ត ពីព្រោះមានការធ្វើដំណើរជុំថេរ - រូបថតត្រូវបានបង្ហោះ វាមិនមែននៅទីនេះទេ យើងកំពុងធ្វើការស្នើសុំពីរជំនួសឱ្យមួយ វាគួរតែដំណើរការយឺត។

នៅក្នុងស្ថានភាពរបស់យើង នេះមិនដំណើរការយឺតទេ។

យើងប្រមូលរង្វាស់ជាច្រើននៅលើប្រព័ន្ធនេះ ហើយអត្រាឆ្លាតវៃតាមលក្ខខណ្ឌនៃយន្តការនេះគឺប្រហែល 95% ។ ទាំងនោះ។ ភាពយឺតយ៉ាវនៃការបម្រុងទុកនេះគឺតូច ហើយដោយសារតែវាស្ទើរតែត្រូវបានធានា បន្ទាប់ពីរូបថតត្រូវបានផ្ទុកឡើង យើងនឹងយកវាជាលើកដំបូង ហើយនឹងមិនចាំបាច់ទៅកន្លែងណាពីរដងទេ។

ដូច្នេះ តើ​យើង​មាន​អ្វី​ទៀត​ដែល​ពិត​ជា​ឡូយ?

ពីមុនយើងមានភាគថាសបម្រុងទុកសំខាន់ ហើយយើងអានពីពួកវាតាមលំដាប់លំដោយ។ ទាំងនោះ។ យើងតែងតែស្វែងរកនៅលើមេដំបូង ហើយបន្ទាប់មកនៅលើការបម្រុងទុក។ វាជាចលនាមួយ។

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

ចំពោះការអត់ឱនចំពោះកំហុស។ តាមពិតនេះគឺជាអ្វីដែលយើងប្រយុទ្ធជាចម្បង។ ដោយមានការអត់ឱនចំពោះកំហុស អ្វីៗបានប្រែក្លាយជាអស្ចារ្យនៅទីនេះ។

រថយន្ត​១​គ្រឿង​ក្រឡាប់ ។

គ្មាន​បញ្ហា! វិស្វករប្រព័ន្ធប្រហែលជាមិនក្រោកនៅពេលយប់ទេ គាត់នឹងរង់ចាំរហូតដល់ព្រឹក គ្មានអ្វីអាក្រក់នឹងកើតឡើងនោះទេ។

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

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

តើ​ការ​សន្និដ្ឋាន​អ្វី​ខ្លះ​ដែល​អាច​ទាញ​ចេញ​ពី​គម្រោង​ការ​ប្រើ​ប្រាស់​ដដែល​នេះ?

យើងមានការអត់ឱនចំពោះកំហុស។

ងាយស្រួល​ប្រើ។ ដោយសារម៉ាស៊ីនមាន hard drive ក្នុងស្រុក នេះកាន់តែងាយស្រួលតាមទស្សនៈប្រតិបត្តិការសម្រាប់វិស្វករដែលធ្វើការជាមួយវា។

យើងបានទទួលប្រាក់ឧបត្ថម្ភសម្រាប់ការអានពីរដង។

នេះគឺជាប្រាក់រង្វាន់ដ៏ល្អមួយ បន្ថែមពីលើការអត់ឱនចំពោះកំហុស។

ប៉ុន្តែ​ក៏​មាន​បញ្ហា​ដែរ។ ឥឡូវនេះ យើងមានការអភិវឌ្ឍន៍ស្មុគ្រស្មាញជាងមុននៃលក្ខណៈពិសេសមួយចំនួនដែលទាក់ទងនឹងបញ្ហានេះ ពីព្រោះប្រព័ន្ធបានក្លាយទៅជា 100% នៅទីបំផុតស្របគ្នា។

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

ហើយនៅទីនេះម្តងទៀតជម្លោះខ្លះកើតឡើង។

ខ្ញុំបាននិយាយនៅដើមដំបូងថាការរក្សាទុកអ្វីគ្រប់យ៉ាងនៅលើ hard drive ក្នុងស្រុកគឺមិនល្អទេ។ ហើយឥឡូវនេះខ្ញុំនិយាយថាយើងចូលចិត្តវា។

បាទ ពិតណាស់ យូរៗទៅស្ថានភាពបានផ្លាស់ប្តូរច្រើន ហើយឥឡូវនេះវិធីសាស្រ្តនេះមានអត្ថប្រយោជន៍ជាច្រើន។ ទីមួយ យើងទទួលបានប្រតិបត្តិការសាមញ្ញជាង។

ទីពីរ វាកាន់តែមានផលិតភាព ដោយសារយើងមិនមានឧបករណ៍បញ្ជាដោយស្វ័យប្រវត្តិ ឬការតភ្ជាប់ទៅធ្នើថាស។

មានគ្រឿងចក្រយ៉ាងច្រើននៅទីនោះ ហើយទាំងនេះគ្រាន់តែជាថាសមួយចំនួនប៉ុណ្ណោះដែលត្រូវបានប្រមូលផ្តុំនៅទីនេះនៅលើម៉ាស៊ីនចូលទៅក្នុងការវាយឆ្មក់។

ប៉ុន្តែក៏មានគុណវិបត្តិផងដែរ។

នេះគឺប្រហែល 1,5 ដងថ្លៃជាងការប្រើប្រាស់ SANs សូម្បីតែតម្លៃនាពេលបច្ចុប្បន្ននេះ។ ដូច្នេះហើយ យើងបានសម្រេចចិត្តមិនបំប្លែងចង្កោមធំទាំងមូលរបស់យើងទៅជារថយន្តដែលមានថាសរឹងក្នុងស្រុក ហើយសម្រេចចិត្តចាកចេញពីដំណោះស្រាយកូនកាត់។

ពាក់កណ្តាលនៃម៉ាស៊ីនរបស់យើងដំណើរការជាមួយដ្រាយវ៍រឹង (ល្អមិនមែនពាក់កណ្តាលទេ - ប្រហែលជា 30 ភាគរយ) ។ ហើយ​នៅសល់​ជា​រថយន្ត​ចាស់ៗ​ដែល​ធ្លាប់​មាន​គម្រោង​កក់ទុក​មុន​។ យើងគ្រាន់តែដំឡើងពួកវាឡើងវិញ ដោយហេតុថាយើងមិនត្រូវការទិន្នន័យថ្មី ឬអ្វីផ្សេងទៀតទេ យើងគ្រាន់តែផ្លាស់ទីម៉ោនពីម៉ាស៊ីនពិតមួយទៅពីរ។

ហើយឥឡូវនេះយើងមានភាគហ៊ុនធំនៃការអាន ហើយយើងបានពង្រីកវា។ ប្រសិនបើមុននេះ យើងបានដំឡើងកន្លែងផ្ទុកមួយនៅលើម៉ាស៊ីនមួយ ឥឡូវនេះយើងម៉ោនចំនួនបួន ឧទាហរណ៍នៅលើមួយគូ។ ហើយវាដំណើរការល្អ។

ចូរយើងសង្ខេបនូវអ្វីដែលយើងសម្រេចបាន អ្វីដែលយើងបានតស៊ូដើម្បីអ្វី និងថាតើយើងជោគជ័យដែរឬទេ។

លទ្ធផល

យើងមានអ្នកប្រើប្រាស់ - រហូតដល់ 33 លាននាក់។

យើងមានបីពិន្ទុនៃវត្តមាន - ទីក្រុង Prague, Miami, ហុងកុង។

ពួកវាផ្ទុកនូវស្រទាប់ឃ្លាំងសម្ងាត់ ដែលរួមមានរថយន្តដែលមានថាសមូលដ្ឋានលឿន (SSDs) ដែលម៉ាស៊ីនសាមញ្ញពី NGINX, access.log និង Python daemons ដំណើរការ ដែលដំណើរការទាំងអស់នេះ និងគ្រប់គ្រងឃ្លាំងសម្ងាត់។

ប្រសិនបើអ្នកប្រាថ្នា អ្នកស្ថិតនៅក្នុងគម្រោងរបស់អ្នក ប្រសិនបើរូបថតមិនសំខាន់សម្រាប់អ្នកដូចដែលពួកវាសម្រាប់យើង ឬប្រសិនបើការគ្រប់គ្រងការដោះដូរធៀបនឹងល្បឿននៃការអភិវឌ្ឍន៍ និងតម្លៃធនធានគឺស្ថិតនៅក្នុងទិសដៅផ្សេងទៀតសម្រាប់អ្នក នោះអ្នកអាចជំនួសវាដោយសុវត្ថិភាព។ ជាមួយនឹង CDN CDNs ទំនើបគឺពួកគេធ្វើបានល្អ។

បន្ទាប់​មក​ស្រទាប់​ផ្ទុក ដែល​យើង​មាន​ម៉ាស៊ីន​ជា​គូ​ដែល​បម្រុង​ទុក​គ្នា ឯកសារ​ត្រូវ​បាន​ចម្លង​ពី​មួយ​ទៅ​មួយ​ដោយ​អសមកាល​គ្រប់​ពេល​ដែល​វា​ផ្លាស់ប្ដូរ។

លើសពីនេះទៅទៀត ម៉ាស៊ីនទាំងនេះមួយចំនួនដំណើរការជាមួយ hard drive ក្នុងស្រុក។

ម៉ាស៊ីនទាំងនេះមួយចំនួនត្រូវបានភ្ជាប់ទៅ SANs ។

ហើយម្យ៉ាងវិញទៀតវាកាន់តែងាយស្រួលប្រើ និងមានផលិតភាពជាងបន្តិច ម្យ៉ាងវិញទៀតវាមានភាពងាយស្រួលក្នុងលក្ខខណ្ឌនៃដង់ស៊ីតេនៃការដាក់ និងតម្លៃក្នុងមួយជីហ្គាបៃ។

នេះគឺជាទិដ្ឋភាពសង្ខេបនៃស្ថាបត្យកម្មនៃអ្វីដែលយើងទទួលបាន និងរបៀបដែលវាអភិវឌ្ឍទាំងអស់។

គន្លឹះពីរបីទៀតពីប្រធានក្រុម ដែលសាមញ្ញណាស់។

ទីមួយ ប្រសិនបើអ្នកសម្រេចចិត្តភ្លាមៗថាអ្នកត្រូវការកែលម្អអ្វីៗគ្រប់យ៉ាងនៅក្នុងរចនាសម្ព័ន្ធរូបថតរបស់អ្នកជាបន្ទាន់ សូមវាស់វែងជាមុនសិន ព្រោះប្រហែលជាគ្មានអ្វីត្រូវកែលម្អនោះទេ។

ខ្ញុំសូមផ្តល់ឧទាហរណ៍មួយដល់អ្នក។ យើង​មាន​ម៉ាស៊ីន​មួយ​ក្រុម​ដែល​ផ្ញើ​រូបថត​ពី​ឯកសារ​ភ្ជាប់​ក្នុង​ការ​ជជែក ហើយ​គ្រោងការណ៍​នេះ​បាន​ដំណើរការ​នៅ​ទីនោះ​តាំងពី​ឆ្នាំ ២០០៩ ហើយ​គ្មាន​នរណា​ម្នាក់​រង​គ្រោះ​ទេ។ អ្នកទាំងអស់គ្នាសុខសប្បាយទេ គ្រប់គ្នាចូលចិត្តទាំងអស់។

ដើម្បីវាស់វែង ជាដំបូងត្រូវព្យួររង្វាស់ម៉ែត្រមួយៗ មើលពួកវា ហើយបន្ទាប់មកសម្រេចចិត្តថាអ្នកមិនសប្បាយចិត្តនឹងអ្វី និងអ្វីដែលត្រូវកែលម្អ។ ដើម្បីវាស់វែងនេះ យើងមានឧបករណ៍ដ៏ត្រជាក់មួយដែលមានឈ្មោះថា Pinba ។

វាអនុញ្ញាតឱ្យអ្នកប្រមូលស្ថិតិលម្អិតពី NGINX សម្រាប់សំណើនីមួយៗ និងលេខកូដឆ្លើយតប និងការចែកចាយពេលវេលា - អ្វីក៏ដោយដែលអ្នកចង់បាន។ វាមានភ្ជាប់ជាមួយប្រព័ន្ធវិភាគផ្សេងៗគ្រប់ប្រភេទ ហើយបន្ទាប់មកអ្នកអាចមើលវាយ៉ាងស្រស់ស្អាត។

ដំបូង​យើង​វាស់​វា បន្ទាប់​មក​យើង​កែ​លម្អ​វា។

បន្ថែមទៀត។ យើងបង្កើនប្រសិទ្ធភាពការអានដោយប្រើឃ្លាំងសម្ងាត់ សរសេរជាមួយ sharding ប៉ុន្តែនេះគឺជាចំណុចជាក់ស្តែង។

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

ឧបមាថាអ្នកបានផ្ទុកឡើងមួយរយ បន្ទាប់មកបង្វិលវា ធ្វើវាដើម្បីឱ្យវាជាឯកសារផ្សេងគ្នា។ ទាំងនោះ។ មិនចាំបាច់គិតទេ៖ ឥឡូវនេះ ខ្ញុំនឹងរក្សាទុកកន្លែងទំនេរបន្តិច សរសេរវាទៅឯកសារដដែល ប្តូរកំណែ។ វាតែងតែមិនដំណើរការល្អ ហើយបណ្តាលឱ្យឈឺក្បាលច្រើននៅពេលក្រោយ។

ចំណុចបន្ទាប់។ អំពីការផ្លាស់ប្តូរទំហំភ្លាមៗ។

កាលពីមុន នៅពេលដែលអ្នកប្រើប្រាស់បង្ហោះរូបថត យើងបានកាត់ទំហំទាំងមូលភ្លាមៗសម្រាប់គ្រប់ឱកាសទាំងអស់ សម្រាប់អតិថិជនផ្សេងៗគ្នា ហើយពួកវាទាំងអស់នៅលើថាស។ ឥឡូវ​នេះ​យើង​បាន​បោះ​បង់​ចោល។

យើងទុកតែទំហំធំបីប៉ុណ្ណោះ៖ តូច មធ្យម និងធំ។ យើងគ្រាន់តែបន្ទាបទំហំអ្វីៗផ្សេងទៀតពីទំហំដែលនៅពីក្រោយមួយដែលត្រូវបានសួរមកយើងនៅ Uport យើងគ្រាន់តែធ្វើមាត្រដ្ឋានចុះហើយផ្តល់ឱ្យវាដល់អ្នកប្រើប្រាស់។

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

ហើយការបម្រុងទុកអសមកាលបន្ថែមគឺល្អ។

ដូចដែលការអនុវត្តរបស់យើងបានបង្ហាញ គ្រោងការណ៍នេះដំណើរការល្អជាមួយនឹងការពន្យារពេលនៃការចម្លងឯកសារដែលបានផ្លាស់ប្តូរ។

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

ទំនាក់ទំនង

» bo0rsh201
» ប្លុក Badoo

របាយការណ៍នេះគឺជាប្រតិចារិកនៃសុន្ទរកថាដ៏ល្អបំផុតមួយនៅក្នុងសន្និសិទរបស់អ្នកអភិវឌ្ឍន៍នៃប្រព័ន្ធផ្ទុកខ្ពស់។ ការផ្ទុកខ្ពស់ ++. នៅសល់តិចជាងមួយខែទៀតរហូតដល់សន្និសីទ HighLoad++ 2017។

យើងមានវារួចរាល់ហើយ។ កម្មវិធីសន្និសីទឥឡូវនេះ កាលវិភាគកំពុងត្រូវបានបង្កើតឡើងយ៉ាងសកម្ម។

ឆ្នាំនេះ យើងបន្តស្វែងយល់ពីប្រធានបទនៃស្ថាបត្យកម្ម និងការធ្វើមាត្រដ្ឋាន៖

• របៀបបម្រើអ្នកប្រើប្រាស់រាប់ពាន់លាននាក់ និងផ្តល់ចរាចរណ៍ terabit / Igor Vasiliev
• របៀបសរសេរសារឡើងវិញនូវមូលដ្ឋានទិន្នន័យសារផ្ទាល់ខ្លួន VKontakte ពីដំបូង ហើយប្តូរទៅវាដោយគ្មានពេលទំនេរ / Dmitry Egorov
• ការស្លាប់ដោយការលក់៖ របៀបដែល Yandex.Money ព្យាយាមបង្កើនល្បឿនដល់ Black Friday និងរស់រានមានជីវិត / Anatoly Plaskovsky
• ស្ថាបត្យកម្មមិនអត់ឱនចំពោះកំហុសនៃប្រព័ន្ធខាងមុខរបស់ធនាគារ / Roman Shekhovtsov, Alexey Gromatchikov
• ស្ថាបត្យកម្មប្រព័ន្ធទូទាត់៖ ស្ទើរតែសហគ្រាស / Philip Delgado

យើងក៏ប្រើសម្ភារៈទាំងនេះមួយចំនួននៅក្នុងវគ្គបណ្តុះបណ្តាលតាមអ៊ីនធឺណិតរបស់យើងលើការបង្កើតប្រព័ន្ធផ្ទុកបន្ទុកខ្ពស់។ HighLoad. មគ្គុទ្ទេសក៍ គឺជាខ្សែសង្វាក់នៃអក្សរ អត្ថបទ សម្ភារៈ វីដេអូដែលបានជ្រើសរើសជាពិសេស។ សៀវភៅសិក្សារបស់យើងមានសម្ភារៈពិសេសជាង 30 រួចហើយ។ ភ្ជាប់!

ប្រភព: www.habr.com