ការចាប់ផ្តើមអាជីវកម្មជាច្រើនបានឆ្លងកាត់បញ្ហានេះ៖ ហ្វូងអ្នកប្រើប្រាស់ថ្មីចុះឈ្មោះជារៀងរាល់ថ្ងៃ ហើយក្រុមអភិវឌ្ឍន៍ព្យាយាមបន្តដំណើរការសេវាកម្ម។

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

ចូរយើងព្យាយាមត្រងព័ត៌មាន និងសរសេររូបមន្តមូលដ្ឋាន។ យើងនឹងពង្រីកគេហទំព័រចែករំលែករូបថតថ្មីរបស់យើង Graminsta មួយជំហានម្តងៗ ពីអ្នកប្រើប្រាស់ 1 ដល់ 100។

ចូរយើងសរសេរនូវសកម្មភាពជាក់លាក់ណាមួយដែលត្រូវធ្វើនៅពេលដែលទស្សនិកជនកើនឡើងដល់ 10, 100, 1000, 10 និង 000 នាក់។

អ្នកប្រើប្រាស់ ១ ​​នាក់៖ ម៉ាស៊ីន ១

ស្ទើរតែគ្រប់កម្មវិធី មិនថាជាគេហទំព័រ ឬកម្មវិធីទូរស័ព្ទ មានធាតុផ្សំសំខាន់ៗចំនួនបី៖

• ការ API
• មូលដ្ឋានទិន្នន័យ
• អតិថិជន (កម្មវិធីទូរស័ព្ទខ្លួនឯង ឬគេហទំព័រ)

មូលដ្ឋានទិន្នន័យរក្សាទុកទិន្នន័យជាប់លាប់។ API បម្រើសំណើទៅកាន់ និងជុំវិញទិន្នន័យនេះ។ ម៉ាស៊ីនភ្ញៀវបញ្ជូនទិន្នន័យទៅអ្នកប្រើប្រាស់។

ខ្ញុំបានសន្និដ្ឋានថាវាងាយស្រួលជាងក្នុងការនិយាយអំពីការធ្វើមាត្រដ្ឋានកម្មវិធី ប្រសិនបើតាមទស្សនៈស្ថាបត្យកម្ម អតិថិជន និងអង្គភាព API ត្រូវបានបំបែកចេញពីគ្នាទាំងស្រុង។

នៅពេលយើងចាប់ផ្តើមបង្កើតកម្មវិធីដំបូង សមាសធាតុទាំងបីអាចដំណើរការលើម៉ាស៊ីនមេតែមួយ។ នៅក្នុងវិធីមួយចំនួន នេះគឺស្រដៀងគ្នាទៅនឹងបរិយាកាសអភិវឌ្ឍន៍របស់យើង៖ វិស្វករម្នាក់ដំណើរការមូលដ្ឋានទិន្នន័យ API និងម៉ាស៊ីនភ្ញៀវនៅលើម៉ាស៊ីនតែមួយ។

តាមទ្រឹស្ដី យើងអាចដាក់ពង្រាយវានៅក្នុងពពកលើវត្ថុ DigitalOcean Droplet ឬ AWS EC2 ដូចបានបង្ហាញខាងក្រោម៖

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

10 អ្នកប្រើប្រាស់៖ ផ្លាស់ទីមូលដ្ឋានទិន្នន័យទៅកម្រិតដាច់ដោយឡែក

ការបំបែកមូលដ្ឋានទិន្នន័យទៅជាសេវាកម្មគ្រប់គ្រងដូចជា Amazon RDS ឬ Digital Ocean Managed Database នឹងបម្រើយើងឱ្យបានយូរ។ វាមានតម្លៃថ្លៃជាងការបង្ហោះដោយខ្លួនឯងនៅលើម៉ាស៊ីនតែមួយ ឬឧទាហរណ៍ EC2 ប៉ុន្តែជាមួយនឹងសេវាកម្មទាំងនេះ អ្នកទទួលបានផ្នែកបន្ថែមមានប្រយោជន៍ជាច្រើនចេញពីប្រអប់ដែលនឹងមានប្រយោជន៍នៅពេលអនាគត៖ ការបម្រុងទុកពហុតំបន់ អានការចម្លងដោយស្វ័យប្រវត្តិ ការបម្រុងទុក និងច្រើនទៀត។

នេះជាអ្វីដែលប្រព័ន្ធមើលទៅឥឡូវនេះ៖

អ្នកប្រើប្រាស់ 100 នាក់៖ ផ្លាស់ប្តូរអតិថិជនទៅកម្រិតដាច់ដោយឡែកមួយ។

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

នេះជាមូលហេតុដែលខ្ញុំចូលចិត្តគិតដល់អតិថិជនថាដាច់ដោយឡែកពី API ។ នេះធ្វើឱ្យវាមានភាពងាយស្រួលក្នុងការគិតគូរអំពីការអភិវឌ្ឍន៍សម្រាប់វេទិកាជាច្រើន៖ គេហទំព័រ គេហទំព័រចល័ត ប្រព័ន្ធប្រតិបត្តិការ iOS ប្រព័ន្ធប្រតិបត្តិការ Android កម្មវិធីកុំព្យូទ័រ សេវាកម្មភាគីទីបី។ល។ ពួកគេទាំងអស់គ្រាន់តែជាអតិថិជនដែលប្រើ API តែមួយប៉ុណ្ណោះ។

ជាឧទាហរណ៍ ឥឡូវនេះអ្នកប្រើប្រាស់របស់យើងភាគច្រើនតែងតែស្នើសុំឱ្យបញ្ចេញកម្មវិធីទូរស័ព្ទ។ ប្រសិនបើអ្នកបែងចែកអតិថិជន និងអង្គភាព API នោះវាកាន់តែងាយស្រួល។

នេះជាអ្វីដែលប្រព័ន្ធបែបនេះមើលទៅ៖

1000 អ្នកប្រើប្រាស់៖ បន្ថែមការផ្ទុកតុល្យភាព

អ្វីៗកំពុងរកមើល។ អ្នកប្រើប្រាស់ Graminsta កំពុងបង្ហោះរូបថតកាន់តែច្រើនឡើង។ ចំនួននៃការចុះឈ្មោះក៏កំពុងកើនឡើងផងដែរ។ ម៉ាស៊ីនមេ API តែមួយគត់របស់យើងកំពុងមានការលំបាកក្នុងការរក្សាចរាចរណ៍ទាំងអស់។ ត្រូវការជាតិដែកទៀត!

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

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

នៅទីនេះយើងទទួលបានអត្ថប្រយោជន៍សំខាន់មួយទៀត - លែងត្រូវការតទៅទៀត។ នៅពេលដែលឧទាហរណ៍មួយបរាជ័យ (ប្រហែលជាផ្ទុកលើសទម្ងន់ ឬគាំង) យើងនៅសល់ជាមួយអ្នកផ្សេងទៀតដែលបន្តឆ្លើយតបទៅនឹងសំណើចូល។ ប្រសិន​បើ​មាន​ឧទាហរណ៍​តែ​មួយ​ដែល​ដំណើរ​ការ​នោះ​ប្រសិន​បើ​បរាជ័យ​ប្រព័ន្ធ​ទាំង​មូល​នឹង​គាំង។

ឧបករណ៍តុល្យភាពបន្ទុកក៏ផ្តល់នូវការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិផងដែរ។ យើង​អាច​កំណត់​រចនាសម្ព័ន្ធ​វា​ដើម្បី​បង្កើន​ចំនួន​ករណី​មុន​ពេល​ផ្ទុក​ឡើង​ខ្ពស់ ហើយ​បន្ថយ​វា​នៅ​ពេល​អ្នក​ប្រើ​ទាំងអស់​កំពុង​គេង។

ជាមួយនឹងឧបករណ៍ផ្ទុកតុល្យភាព កម្រិត API អាចត្រូវបានធ្វើមាត្រដ្ឋានស្ទើរតែគ្មានកំណត់ ដោយគ្រាន់តែបន្ថែមករណីថ្មីនៅពេលដែលចំនួនសំណើកើនឡើង។

ចំណាំ។ ឥឡូវនេះប្រព័ន្ធរបស់យើងគឺស្រដៀងគ្នាទៅនឹងអ្វីដែលក្រុមហ៊ុន PaaS ដូចជា Heroku ឬ Elastic Beanstalk នៅលើ AWS ផ្តល់ជូនចេញពីប្រអប់ (ដែលនេះជាមូលហេតុដែលពួកគេមានប្រជាប្រិយភាពខ្លាំង)។ Heroku ដាក់មូលដ្ឋានទិន្នន័យនៅលើម៉ាស៊ីនដាច់ដោយឡែក គ្រប់គ្រងតុល្យភាពការផ្ទុកដោយស្វ័យប្រវត្តិ និងអនុញ្ញាតឱ្យអ្នកធ្វើជាម្ចាស់ផ្ទះកម្មវិធីបណ្តាញដាច់ដោយឡែកពី API ។ នេះជាហេតុផលដ៏ល្អក្នុងការប្រើប្រាស់ Heroku សម្រាប់គម្រោងដំណាក់កាលដំបូង ឬការចាប់ផ្តើមអាជីវកម្ម - អ្នកទទួលបានសេវាកម្មជាមូលដ្ឋានទាំងអស់ចេញពីប្រអប់។

អ្នកប្រើប្រាស់ 10 នាក់៖ CDN

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

នៅដំណាក់កាលនេះ អ្នកត្រូវប្រើសេវាកម្មពពកសម្រាប់ការរក្សាទុកមាតិកាឋិតិវន្ត - រូបភាព វីដេអូ និងច្រើនទៀត (AWS S3 ឬ Digital Ocean Spaces) ។ ជាទូទៅ API របស់យើងគួរតែជៀសវាងការដោះស្រាយដូចជាការបម្រើរូបភាព និងការបង្ហោះរូបភាពទៅកាន់ម៉ាស៊ីនមេ។

អត្ថប្រយោជន៍មួយទៀតនៃការបង្ហោះលើពពកគឺ CDN (AWS ហៅកម្មវិធីបន្ថែមនេះថា Cloudfront ប៉ុន្តែអ្នកផ្តល់សេវាផ្ទុកពពកជាច្រើនផ្តល់ជូនវាចេញពីប្រអប់)។ CDN រក្សាទុករូបភាពរបស់យើងដោយស្វ័យប្រវត្តិនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗជុំវិញពិភពលោក។

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

អ្នកប្រើប្រាស់ 100៖ ធ្វើមាត្រដ្ឋានស្រទាប់ទិន្នន័យ

CDN បានជួយច្រើន៖ ចរាចរណ៍កំពុងកើនឡើងពេញល្បឿន។ អ្នកសរសេរប្លុកវីដេអូដ៏ល្បីល្បាញ Mavid Mobrick ទើបតែចុះឈ្មោះជាមួយយើង ហើយបង្ហោះ "រឿង" របស់គាត់ ដូចដែលពួកគេនិយាយ។ សូមអរគុណដល់ការផ្ទុកតុល្យភាព ការប្រើប្រាស់ស៊ីភីយូ និងអង្គចងចាំនៅលើម៉ាស៊ីនមេ API ត្រូវបានរក្សាទុកទាប (ឧទាហរណ៍ API ដប់កំពុងដំណើរការ) ប៉ុន្តែយើងកំពុងចាប់ផ្តើមទទួលបានពេលវេលាអស់ពេលជាច្រើនលើសំណើ... តើការពន្យារពេលទាំងនេះមកពីណា?

ជីកបន្តិចទៅក្នុងរង្វាស់ យើងឃើញថាស៊ីភីយូនៅលើម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យត្រូវបានផ្ទុក 80-90% ។ យើង​ដល់​កម្រិត​ហើយ។

ការធ្វើមាត្រដ្ឋានស្រទាប់ទិន្នន័យប្រហែលជាផ្នែកដ៏លំបាកបំផុតនៃសមីការ។ ម៉ាស៊ីនមេ API បម្រើសំណើគ្មានរដ្ឋ ដូច្នេះយើងគ្រាន់តែបន្ថែមឧទាហរណ៍ API បន្ថែមទៀត។ ច្រមុះ ភាគច្រើន មូលដ្ឋានទិន្នន័យមិនអាចធ្វើវាបានទេ។ យើងនឹងនិយាយអំពីប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យទំនាក់ទំនងដ៏ពេញនិយម (PostgreSQL, MySQL ។ល។)។

ឃ្លាំងសម្ងាត់

មធ្យោបាយងាយស្រួលបំផុតមួយដើម្បីបង្កើនដំណើរការនៃមូលដ្ឋានទិន្នន័យរបស់យើងគឺដើម្បីណែនាំសមាសភាគថ្មី: ស្រទាប់ឃ្លាំងសម្ងាត់។ វិធីសាស្ត្រ​ឃ្លាំង​សម្ងាត់​ទូទៅ​បំផុត​គឺ​ឃ្លាំង​ទិន្នន័យ​តម្លៃ​គ្រាប់ចុច​ក្នុង​អង្គចងចាំ​ដូចជា Redis ឬ Memcached ។ ពពកភាគច្រើនមានកំណែដែលបានគ្រប់គ្រងនៃសេវាកម្មទាំងនេះ៖ Elasticache នៅលើ AWS និង Memorystore នៅលើ Google Cloud ។

ឃ្លាំងសម្ងាត់មានប្រយោជន៍នៅពេលដែលសេវាកម្មហៅម្តងហើយម្តងទៀតជាច្រើនទៅកាន់មូលដ្ឋានទិន្នន័យដើម្បីទាញយកព័ត៌មានដូចគ្នា។ សំខាន់ យើងចូលប្រើមូលដ្ឋានទិន្នន័យតែម្តងគត់ រក្សាទុកព័ត៌មានក្នុងឃ្លាំងសម្ងាត់ ហើយកុំប៉ះវាម្តងទៀត។

ឧទាហរណ៍ នៅក្នុងសេវាកម្ម Graminsta របស់យើង រាល់ពេលដែលនរណាម្នាក់ចូលទៅកាន់ទំព័រកម្រងព័ត៌មានរបស់តារា Mobrik ម៉ាស៊ីនមេ API សាកសួរមូលដ្ឋានទិន្នន័យសម្រាប់ព័ត៌មានពីប្រវត្តិរូបរបស់គាត់។ រឿងនេះកើតឡើងម្តងហើយម្តងទៀត។ ដោយសារព័ត៌មានប្រវត្តិរូបរបស់ Mobrik មិនផ្លាស់ប្តូរជាមួយសំណើនីមួយៗ វាជាការប្រសើរណាស់សម្រាប់ឃ្លាំងសម្ងាត់។

យើងនឹងរក្សាទុកលទ្ធផលពីមូលដ្ឋានទិន្នន័យនៅក្នុង Redis ដោយគន្លឹះ user:id ជាមួយនឹងរយៈពេលសុពលភាព 30 វិនាទី។ ឥឡូវនេះ នៅពេលដែលនរណាម្នាក់ចូលទៅកាន់ Profile របស់ Mobrik យើងពិនិត្យមើល Redis ជាដំបូង ហើយប្រសិនបើទិន្នន័យនៅទីនោះ យើងគ្រាន់តែផ្ទេរវាដោយផ្ទាល់ពី Redis ប៉ុណ្ណោះ។ ឥឡូវនេះស្នើសុំទៅទម្រង់ពេញនិយមបំផុតនៅលើគេហទំព័រអនុវត្តមិនផ្ទុកមូលដ្ឋានទិន្នន័យរបស់យើង។

អត្ថប្រយោជន៍មួយទៀតនៃសេវាកម្មឃ្លាំងសម្ងាត់ភាគច្រើនគឺថាពួកវាងាយស្រួលក្នុងការធ្វើមាត្រដ្ឋានជាងម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ។ Redis មានមុខងារ Redis Cluster ដែលមានស្រាប់។ ស្រដៀងទៅនឹងឧបករណ៍ផ្ទុកតុល្យភាព1វាអនុញ្ញាតឱ្យអ្នកចែកចាយឃ្លាំងសម្ងាត់ Redis របស់អ្នកនៅលើម៉ាស៊ីនជាច្រើន (ឆ្លងកាត់ម៉ាស៊ីនមេរាប់ពាន់ប្រសិនបើចាំបាច់) ។

ស្ទើរតែគ្រប់កម្មវិធីខ្នាតធំទាំងអស់ប្រើឃ្លាំងសម្ងាត់ វាគឺជាផ្នែកសំខាន់នៃ API លឿន។ ដំណើរការសំណួរលឿនជាងមុន និងកូដដែលមានផលិតភាពកាន់តែច្រើន សុទ្ធតែមានសារៈសំខាន់ ប៉ុន្តែបើគ្មានឃ្លាំងសម្ងាត់ វាស្ទើរតែមិនអាចទៅរួចទេក្នុងការធ្វើមាត្រដ្ឋានសេវាកម្មដល់អ្នកប្រើប្រាស់រាប់លាននាក់។

អានការចម្លង

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

នេះគឺជាប្រព័ន្ធរបស់យើងឥឡូវនេះ៖

សកម្មភាពបន្ថែម

នៅពេលដែលកម្មវិធីបន្តធ្វើមាត្រដ្ឋាន យើងនឹងបន្តបំបែកសេវាកម្មដើម្បីធ្វើមាត្រដ្ឋានពួកវាដោយឯករាជ្យ។ ឧទាហរណ៍ ប្រសិនបើយើងចាប់ផ្តើមប្រើ Websockets នោះវាសមហេតុផលក្នុងការទាញកូដដំណើរការ Websockets ទៅជាសេវាកម្មដាច់ដោយឡែក។ យើងអាចដាក់វានៅលើករណីថ្មីនៅពីក្រោយ Load Balancer របស់យើងផ្ទាល់ ដែលអាចធ្វើមាត្រដ្ឋានឡើងលើ និងចុះក្រោមដោយផ្អែកលើការតភ្ជាប់ Websockets បើកចំហ និងមិនគិតពីចំនួនសំណើ HTTP នោះទេ។

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

យើងក៏ចង់ដំឡើងសេវាកម្មត្រួតពិនិត្យ និងវិភាគដូចជា New Relic ឬ Datadog ផងដែរ។ នេះនឹងជួយអ្នកកំណត់សំណួរយឺតៗ និងយល់ពីកន្លែងដែលត្រូវការការកែលម្អ។ នៅពេលដែលយើងធ្វើមាត្រដ្ឋាន យើងចង់ផ្តោតលើការស្វែងរកការស្ទះ និងលុបបំបាត់វា—ជាញឹកញាប់ប្រើគំនិតមួយចំនួនពីផ្នែកមុនៗ។

ប្រភព។

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

លេខយោង

1. ទោះបីជាស្រដៀងគ្នានៅក្នុងលក្ខខណ្ឌនៃការចែកចាយបន្ទុកលើករណីជាច្រើនក៏ដោយ ការអនុវត្តមូលដ្ឋាននៃក្រុម Redis គឺខុសគ្នាខ្លាំងណាស់ពីតុល្យភាពបន្ទុក។ [ត្រឡប់]

ប្រភព: www.habr.com