ការអត់ឱនចំពោះកំហុស និងភាពអាចរកបានខ្ពស់គឺជាប្រធានបទធំ ដូច្នេះយើងនឹងលះបង់អត្ថបទដាច់ដោយឡែកពី RabbitMQ និង Kafka ។ អត្ថបទនេះគឺអំពី RabbitMQ ហើយអត្ថបទបន្ទាប់គឺអំពី Kafka ក្នុងការប្រៀបធៀបជាមួយ RabbitMQ ។ នេះ​ជា​អត្ថបទ​វែង ដូច្នេះ​ធ្វើ​ឱ្យ​ខ្លួន​ឯង​ស្រួល​ខ្លួន។

សូមក្រឡេកមើលយុទ្ធសាស្រ្តអត់ធ្មត់ ភាពជាប់លាប់ និងភាពអាចរកបានខ្ពស់ (HA) និងការដោះដូរដែលយុទ្ធសាស្រ្តនីមួយៗបង្កើត។ RabbitMQ អាចដំណើរការលើចង្កោមថ្នាំង - ហើយបន្ទាប់មកត្រូវបានចាត់ថ្នាក់ជាប្រព័ន្ធចែកចាយ។ នៅពេលនិយាយអំពីប្រព័ន្ធចែកចាយ យើងច្រើនតែនិយាយអំពីភាពជាប់លាប់ និងភាពអាចរកបាន។

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

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

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

បុព្វបទភាពធន់នឹងថ្នាំងតែមួយ

ការតម្រង់ជួរ/ការនាំផ្លូវដែលធន់

មានជួរពីរប្រភេទនៅក្នុង RabbitMQ: ជាប់បានយូរ និងមិនធន់។ ជួរទាំងអស់ត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ Mnesia ។ ជួរជាប់លាប់ត្រូវបានផ្សាយឡើងវិញនៅពេលចាប់ផ្តើមថ្នាំង ហើយដូច្នេះរួចផុតពីការចាប់ផ្ដើមឡើងវិញ ការគាំងប្រព័ន្ធ ឬការគាំងម៉ាស៊ីនមេ (ដរាបណាទិន្នន័យនៅតែមាន)។ នេះមានន័យថា ដរាបណាអ្នកប្រកាសអំពីការកំណត់ផ្លូវ (ការផ្លាស់ប្តូរ) និងជួរដើម្បីឱ្យមានភាពធន់ ហេដ្ឋារចនាសម្ព័ន្ធតម្រង់ជួរ/ផ្លូវនឹងត្រលប់មកវិញតាមអ៊ីនធឺណិត។

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

សារជាប់លាប់

ដោយសារតែជួរមួយមានភាពជាប់លាប់ មិនមានន័យថាសារទាំងអស់របស់វានឹងរួចផុតពីការចាប់ផ្ដើមថ្នាំងឡើងវិញនោះទេ។ មានតែសារដែលកំណត់ដោយអ្នកបោះពុម្ពផ្សាយជា និរន្តរភាព (ជាប់លាប់) ។ សារជាប់លាប់បង្កើតបន្ទុកបន្ថែមលើឈ្មួញកណ្តាល ប៉ុន្តែប្រសិនបើការបាត់បង់សារមិនអាចទទួលយកបាន នោះគ្មានជម្រើសផ្សេងទៀតទេ។

អង្ករ។ 1. ម៉ាទ្រីសនិរន្តរភាព

ការដាក់ជាចង្កោមជាមួយនឹងការឆ្លុះបញ្ចាំងជួរ

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

ការឆ្លុះបញ្ចាំងជួរ៖

• ជួរមេមួយ (មេ) ដែលទទួលរាល់ការសរសេរ និងអានពាក្យបញ្ជា
• កញ្ចក់មួយ ឬច្រើនដែលទទួលសារ និងទិន្នន័យមេតាទាំងអស់ពីជួរមេ។ កញ្ចក់ទាំងនេះមិននៅទីនោះសម្រាប់ធ្វើមាត្រដ្ឋានទេ ប៉ុន្តែសម្រាប់ការប្រើប្រាស់ឡើងវិញសុទ្ធសាធ។

អង្ករ។ 2. ការឆ្លុះកញ្ចក់

ការឆ្លុះកញ្ចក់ត្រូវបានកំណត់ដោយគោលការណ៍សមស្រប។ នៅក្នុងវា អ្នកអាចជ្រើសរើសមេគុណចម្លង និងសូម្បីតែថ្នាំងដែលជួរគួរតែស្ថិតនៅ។ ឧទាហរណ៍:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (មេមួយ និងកញ្ចក់មួយ)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ការបញ្ជាក់របស់អ្នកបោះពុម្ពផ្សាយ

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

ជួរដែលបរាជ័យ

នៅពេលដែលឈ្មួញកណ្តាលឈប់ ឬគាំង អ្នកដឹកនាំជួរទាំងអស់ (មេ) នៅលើថ្នាំងនោះគាំងជាមួយវា។ បន្ទាប់មក ចង្កោមជ្រើសរើសកញ្ចក់ចាស់បំផុតរបស់មេនីមួយៗ ហើយផ្សព្វផ្សាយវាជាមេថ្មី។

អង្ករ។ 3. ជួរដែលឆ្លុះបញ្ចាំងច្រើន និងគោលការណ៍របស់ពួកគេ។

ឈ្មួញកណ្តាល 3 ធ្លាក់ចុះ។ ចំណាំថាកញ្ចក់ Queue C នៅលើ Broker 2 កំពុងត្រូវបានដំឡើងឋានៈជាមេ។ សូមចំណាំផងដែរថាកញ្ចក់ថ្មីមួយត្រូវបានបង្កើតឡើងសម្រាប់ Queue C នៅលើ Broker 1។ RabbitMQ តែងតែព្យាយាមរក្សាកត្តាចម្លងដែលបានបញ្ជាក់នៅក្នុងគោលការណ៍របស់អ្នក។

អង្ករ។ 4. ឈ្មួញកណ្តាល 3 បរាជ័យ ដែលបណ្តាលឱ្យជួរ C បរាជ័យ

ឈ្មួញកណ្តាលទី 1 ធ្លាក់! យើងនៅសល់តែឈ្មួញកណ្តាលម្នាក់ប៉ុណ្ណោះ។ កញ្ចក់ជួរ B ត្រូវបានដំឡើងឋានៈជាមេ។

រូបភព។ មួយ

យើងបានប្រគល់ Broker 1 មកវិញហើយ។ មិនថាទិន្នន័យអាចរួចផុតពីការបាត់បង់ និងការសង្គ្រោះរបស់ឈ្មួញកណ្តាលបានល្អប៉ុណ្ណានោះទេ សារជួរដែលឆ្លុះបញ្ចាំងទាំងអស់ត្រូវបានលុបចោលនៅពេលចាប់ផ្តើមឡើងវិញ។ នេះ​ជា​ការ​សំខាន់​ក្នុង​ការ​កត់​សម្គាល់ ព្រោះ​វា​នឹង​មាន​ផល​វិបាក។ យើងនឹងពិនិត្យមើលផលប៉ះពាល់ទាំងនេះក្នុងពេលឆាប់ៗនេះ។ ដូច្នេះ Broker 1 ឥឡូវនេះជាសមាជិកនៃ cluster ម្តងទៀត ហើយ cluster ព្យាយាមអនុវត្តតាមគោលការណ៍ ដូច្នេះហើយបង្កើតកញ្ចក់នៅលើ Broker 1។

ក្នុងករណីនេះ ការបាត់បង់ Broker 1 ត្រូវបានបញ្ចប់ដូចទិន្នន័យ ដូច្នេះហើយ Queue B ដែលមិនមានកញ្ចក់ត្រូវបានបាត់បង់ទាំងស្រុង។

អង្ករ។ 6. ឈ្មួញកណ្តាល 1 ត្រឡប់ទៅសេវាកម្មវិញ។

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

អង្ករ។ 7. ឈ្មួញកណ្តាល 3 ត្រឡប់ទៅសេវាកម្មវិញ។ ជួរសំខាន់ៗទាំងអស់នៅលើថ្នាំងមួយ!

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

ធ្វើសមកាលកម្ម

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

ការធ្វើសមកាលកម្មនេះត្រូវបានអនុវត្តដោយស្វ័យប្រវត្តិ ឬដោយដៃ ហើយត្រូវបានគ្រប់គ្រងដោយប្រើគោលការណ៍ជួរ។ សូមក្រឡេកមើលឧទាហរណ៍មួយ។

យើងមានជួរកញ្ចក់ពីរ។ ជួរ A ត្រូវបានធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិ ហើយជួរ B ត្រូវបានធ្វើសមកាលកម្មដោយដៃ។ ជួរទាំងពីរមានសារចំនួនដប់។

អង្ករ។ 8. ជួរពីរដែលមានរបៀបធ្វើសមកាលកម្មផ្សេងគ្នា

ឥឡូវនេះយើងកំពុងបាត់បង់ Broker 3 ។

អង្ករ។ 9. ឈ្មួញកណ្តាល 3 បានធ្លាក់ចុះ

ឈ្មួញកណ្តាល 3 ត្រឡប់ទៅសេវាកម្មវិញ។ ចង្កោមបង្កើតកញ្ចក់សម្រាប់ជួរនីមួយៗនៅលើថ្នាំងថ្មី ហើយធ្វើសមកាលកម្មជួរ A ថ្មីដោយស្វ័យប្រវត្តិជាមួយមេ។ ទោះជាយ៉ាងណាក៏ដោយកញ្ចក់នៃជួរ B ថ្មីនៅតែទទេ។ វិធីនេះ​យើង​មាន​ការ​ប្រើ​ឡើងវិញ​ពេញលេញ​នៅលើ​ជួរ​ A និង​កញ្ចក់​តែមួយគត់​សម្រាប់​សារ​ជួរ​ B ដែលមាន​ស្រាប់។​

អង្ករ។ 10. កញ្ចក់ថ្មីនៃជួរ A ទទួលបានសារដែលមានស្រាប់ទាំងអស់ ប៉ុន្តែកញ្ចក់ថ្មីនៃ Queue B មិនដំណើរការទេ។

សារ ១០ ទៀតមកដល់ក្នុងជួរទាំងពីរ។ បន្ទាប់មក Broker 2 គាំង ហើយ Queue A វិលត្រលប់ទៅកញ្ចក់ចាស់បំផុត ដែលស្ថិតនៅលើ Broker 1។ វាមិនមានការបាត់បង់ទិន្នន័យទេនៅពេលដែលវាបរាជ័យ។ នៅក្នុងជួរ B មានសារចំនួនម្ភៃនៅក្នុងមេ ហើយមានតែដប់សារប៉ុណ្ណោះនៅក្នុងកញ្ចក់ ពីព្រោះជួរនេះមិនដែលចម្លងសារដើមចំនួនដប់ទេ។

អង្ករ។ 11. ជួរ A វិលត្រលប់ទៅ Broker 1 ដោយមិនបាត់បង់សារ

សារ ១០ ទៀតមកដល់ក្នុងជួរទាំងពីរ។ ឥឡូវនេះ Broker 1 គាំង Queue A ងាយស្រួលប្តូរទៅកញ្ចក់ដោយមិនបាត់បង់សារ។ ទោះយ៉ាងណាក៏ដោយ ជួរ B កំពុងមានបញ្ហា។ នៅចំណុចនេះ យើងអាចបង្កើនប្រសិទ្ធភាពភាពអាចរកបាន ឬភាពស៊ីសង្វាក់គ្នា។

ប្រសិនបើយើងចង់បង្កើនប្រសិទ្ធភាពភាពងាយស្រួល នោះគោលការណ៍ ha-promote-on-failure គួរតែត្រូវបានដំឡើងនៅក្នុង តែងតែ. នេះគឺជាតម្លៃលំនាំដើម ដូច្នេះអ្នកគ្រាន់តែមិនអាចបញ្ជាក់គោលការណ៍បានទាំងស្រុងនោះទេ។ ក្នុងករណីនេះ យើងអនុញ្ញាតឱ្យមានការបរាជ័យនៅក្នុងកញ្ចក់ដែលមិនសមកាលកម្ម។ វានឹងធ្វើឱ្យសារបាត់បង់ ប៉ុន្តែជួរនឹងនៅតែអាចអានបាន និងអាចសរសេរបាន។

អង្ករ។ 12. ជួរ A ត្រូវបានបង្វិលត្រលប់ទៅ Broker 3 ដោយមិនបាត់បង់សារ។ ជួរ B វិលត្រលប់ទៅ Broker 3 ជាមួយនឹងសារចំនួនដប់ដែលបាត់

យើងក៏អាចដំឡើងបានដែរ។ ha-promote-on-failure ចូលទៅក្នុងអត្ថន័យ when-synced. ក្នុងករណីនេះ ជំនួសឱ្យការវិលត្រលប់ទៅកញ្ចក់វិញ ជួរនឹងរង់ចាំរហូតដល់ Broker 1 ជាមួយនឹងទិន្នន័យរបស់វាត្រឡប់ទៅរបៀបអនឡាញវិញ។ បន្ទាប់ពីវាត្រឡប់មកវិញ ជួរសំខាន់គឺត្រលប់មកវិញនៅលើ Broker 1 ដោយមិនបាត់បង់ទិន្នន័យណាមួយឡើយ។ ភាពអាចរកបានត្រូវបានលះបង់សម្រាប់សុវត្ថិភាពទិន្នន័យ។ ប៉ុន្តែនេះគឺជារបៀបប្រថុយប្រថានដែលអាចនាំទៅដល់ការបាត់បង់ទិន្នន័យពេញលេញ ដែលយើងនឹងពិនិត្យមើលក្នុងពេលឆាប់ៗនេះ។

អង្ករ។ 13. ជួរ B នៅតែមិនមានបន្ទាប់ពីបាត់បង់ Broker 1

អ្នកអាចសួរថា "តើវាប្រសើរជាងដែលមិនប្រើការធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិទេ?" ចម្លើយគឺថាការធ្វើសមកាលកម្មគឺជាប្រតិបត្តិការទប់ស្កាត់។ កំឡុងពេលធ្វើសមកាលកម្ម ជួរមេមិនអាចធ្វើប្រតិបត្តិការអាន ឬសរសេរបានទេ!

សូមក្រឡេកមើលឧទាហរណ៍មួយ។ ឥឡូវនេះយើងមានជួរវែងណាស់។ តើ​គេ​អាច​លូត​លាស់​បាន​យ៉ាង​ដូច​ម្តេច? សម្រាប់ហេតុផលជាច្រើន៖

• ជួរមិនត្រូវបានប្រើយ៉ាងសកម្មទេ។
• ទាំងនេះគឺជាជួរដែលមានល្បឿនលឿន ហើយឥឡូវនេះអ្នកប្រើប្រាស់យឺត
• វាជាជួរដែលមានល្បឿនលឿន មានកំហុស ហើយអ្នកប្រើប្រាស់កំពុងតាមទាន់

អង្ករ។ 14. ជួរធំពីរដែលមានរបៀបធ្វើសមកាលកម្មផ្សេងគ្នា

ឥឡូវនេះ Broker 3 ធ្លាក់។

អង្ករ។ 15. ឈ្មួញកណ្តាល 3 ធ្លាក់ដោយបន្សល់ទុកមេមួយនិងកញ្ចក់នៅក្នុងជួរនីមួយៗ

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

ទោះយ៉ាងណាក៏ដោយ ជួរ B នៅតែមានពេញមួយរយៈពេលទាំងមូល។ នាង​បាន​លះបង់​ភាព​មិន​ចាំបាច់​ខ្លះ​សម្រាប់​លទ្ធភាព​ប្រើប្រាស់។

អង្ករ។ 16. ជួរនៅតែមិនអាចប្រើបានក្នុងអំឡុងពេលធ្វើសមកាលកម្ម

បន្ទាប់ពីពីរម៉ោង ជួរ A ក៏អាចប្រើបាន ហើយអាចចាប់ផ្តើមទទួលយកការអាន និងសរសេរម្តងទៀត។

ការធ្វើបច្ចុប្បន្នភាព

ឥរិយាបថ​ទប់ស្កាត់​នេះ​កំឡុង​ពេល​ធ្វើ​សមកាលកម្ម​ធ្វើ​ឱ្យ​មាន​ការ​លំបាក​ក្នុង​ការ​ធ្វើ​បច្ចុប្បន្នភាព​ចង្កោម​ដែល​មាន​ជួរ​ធំ​ណាស់។ នៅចំណុចខ្លះ ថ្នាំងមេត្រូវចាប់ផ្តើមឡើងវិញ ដែលមានន័យថា ផ្លាស់ទីទៅកញ្ចក់ ឬបិទជួរ ខណៈពេលដែលម៉ាស៊ីនមេកំពុងត្រូវបានដំឡើងកំណែ។ ប្រសិនបើយើងជ្រើសរើសការផ្លាស់ប្តូរ យើងនឹងបាត់បង់សារ ប្រសិនបើកញ្ចក់មិនត្រូវបានធ្វើសមកាលកម្ម។ តាមលំនាំដើម កំឡុងពេលឈ្មួញកណ្តាលដាច់ ការបរាជ័យចំពោះកញ្ចក់ដែលមិនសមកាលកម្មមិនត្រូវបានអនុវត្តទេ។ នេះមានន័យថា នៅពេលដែលឈ្មួញកណ្តាលត្រឡប់មកវិញ យើងមិនបាត់បង់សារណាមួយទេ ការខូចខាតគឺគ្រាន់តែជាជួរធម្មតាប៉ុណ្ណោះ។ ច្បាប់នៃអាកប្បកិរិយានៅពេលឈ្មួញកណ្តាលត្រូវបានផ្តាច់ត្រូវបានកំណត់ដោយគោលការណ៍ ha-promote-on-shutdown. អ្នកអាចកំណត់តម្លៃមួយក្នុងចំណោមតម្លៃពីរ៖

• always=ការផ្លាស់ប្តូរទៅកញ្ចក់ដែលមិនសមកាលកម្មត្រូវបានបើក
• when-synced=ការផ្លាស់ប្តូរទៅកញ្ចក់ដែលធ្វើសមកាលកម្មតែប៉ុណ្ណោះ បើមិនដូច្នេះទេ ជួរនឹងមិនអាចអានបាន និងមិនអាចសរសេរបាន។ ជួរ​ត្រឡប់​មក​សេវា​វិញ​ភ្លាមៗ​ពេល​ឈ្មួញ​កណ្តាល​ត្រឡប់​មក​វិញ។

វិធីមួយ ឬមធ្យោបាយផ្សេងទៀត ជាមួយនឹងជួរធំ អ្នកត្រូវជ្រើសរើសរវាងការបាត់បង់ទិន្នន័យ និងភាពមិនអាចប្រើបាន។

នៅពេលដែលភាពអាចរកបានធ្វើអោយប្រសើរឡើងនូវសុវត្ថិភាពទិន្នន័យ

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

នៅទីនេះអ្នកត្រូវពិចារណាដូចខាងក្រោម:

• តើ​អ្នក​បោះផ្សាយ​អាច​នឹង​ត្រឡប់​កំហុស​មួយ​វិញ​ហើយ​មាន​សេវា​ចរន្ត ឬ​អ្នក​ប្រើ​ព្យាយាម​ម្ដង​ទៀត​នៅ​ពេល​ក្រោយ​បាន​ទេ?
• តើ​អ្នក​បោះពុម្ព​អាច​រក្សា​ទុក​សារ​ក្នុង​មូលដ្ឋាន ឬ​ក្នុង​មូលដ្ឋាន​ទិន្នន័យ​ដើម្បី​ព្យាយាម​ម្ដង​ទៀត​ពេល​ក្រោយ​បាន​ទេ?

ប្រសិនបើអ្នកបោះពុម្ពផ្សាយគ្រាន់តែអាចបោះបង់សារ នោះតាមពិត ការកែលម្អលទ្ធភាពប្រើប្រាស់ក៏ធ្វើអោយប្រសើរឡើងនូវសុវត្ថិភាពទិន្នន័យផងដែរ។

ដូច្នេះ តុល្យភាពត្រូវតែស្វែងរក ហើយដំណោះស្រាយអាស្រ័យលើស្ថានភាពជាក់លាក់។

បញ្ហាជាមួយ ha-promote-on-failure=when-synced

គំនិត ha-promote-on-failure= ពេលដែលធ្វើសមកាលកម្ម គឺថាយើងការពារការប្តូរទៅកញ្ចក់ដែលមិនសមកាលកម្ម ហើយដោយហេតុនេះជៀសវាងការបាត់បង់ទិន្នន័យ។ ជួរនៅតែមិនអាចអានបាន ឬមិនអាចសរសេរបាន។ ជំនួសមកវិញ យើងព្យាយាមសង្គ្រោះឈ្មួញកណ្តាលដែលគាំងដោយទិន្នន័យរបស់វានៅដដែល ដើម្បីឱ្យវាអាចបន្តដំណើរការជាមេដោយមិនបាត់បង់ទិន្នន័យ។

ប៉ុន្តែ (ហើយនេះគឺធំប៉ុន្តែ) ប្រសិនបើឈ្មួញកណ្តាលបានបាត់បង់ទិន្នន័យរបស់គាត់នោះយើងមានបញ្ហាធំ: ជួរត្រូវបានបាត់បង់! ទិន្នន័យ​ទាំងអស់​បាន​បាត់​! ទោះបីជាអ្នកមានកញ្ចក់ដែលភាគច្រើនតាមជួរសំខាន់ក៏ដោយ ក៏កញ្ចក់ទាំងនោះក៏ត្រូវបោះចោលដែរ។

ដើម្បីបន្ថែមថ្នាំងដែលមានឈ្មោះដូចគ្នាឡើងវិញ យើងប្រាប់ចង្កោមឱ្យភ្លេចថ្នាំងដែលបាត់ (ដោយប្រើពាក្យបញ្ជា rabbitmqctl ភ្លេច_cluster_node) ហើយចាប់ផ្តើមឈ្មួញកណ្តាលថ្មីដែលមានឈ្មោះម៉ាស៊ីនដូចគ្នា។ ខណៈពេលដែលចង្កោមចងចាំថ្នាំងដែលបាត់ វាចងចាំជួរចាស់ និងកញ្ចក់ដែលមិនសមកាលកម្ម។ នៅពេលដែលចង្កោមត្រូវបានប្រាប់ឱ្យភ្លេចថ្នាំងកំព្រា ជួរនោះក៏ត្រូវបានបំភ្លេចផងដែរ។ ឥឡូវនេះយើងត្រូវប្រកាសវាឡើងវិញ។ យើងបានបាត់បង់ទិន្នន័យទាំងអស់ ទោះបីជាយើងមានកញ្ចក់ជាមួយនឹងសំណុំទិន្នន័យមួយផ្នែកក៏ដោយ។ វាជាការប្រសើរក្នុងការប្តូរទៅកញ្ចក់ដែលមិនសមកាលកម្ម!

ដូច្នេះការធ្វើសមកាលកម្មដោយដៃ (និងការបរាជ័យក្នុងការធ្វើសមកាលកម្ម) នៅក្នុងការរួមបញ្ចូលគ្នាជាមួយ ha-promote-on-failure=when-syncedតាមគំនិតរបស់ខ្ញុំ ប្រថុយប្រថានណាស់។ ឯកសារនិយាយថាជម្រើសនេះមានសម្រាប់សុវត្ថិភាពទិន្នន័យ ប៉ុន្តែវាជាកាំបិតមុខពីរ។

តុល្យភាពមេ

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

ចៅហ្វាយនាយឡើងវិញអាចមានបញ្ហាដោយសារហេតុផលពីរយ៉ាង៖

• មិនមានឧបករណ៍ល្អដើម្បីអនុវត្តតុល្យភាពឡើងវិញទេ។
• ការធ្វើសមកាលកម្មជួរ

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

មានល្បិចមួយទៀតដើម្បីផ្លាស់ទីជួរសំខាន់តាមរយៈគោលការណ៍ HA ។ សៀវភៅណែនាំរៀបរាប់ ស្គ្រីប សម្រាប់​ការ​នេះ។ វាដំណើរការដូចនេះ៖

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

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

ឥឡូវនេះសូមមើលពីរបៀបដែលក្រុម RabbitMQ ដំណើរការជាមួយភាគថាសបណ្តាញ។

ការបាត់បង់ការតភ្ជាប់

ថ្នាំងនៃប្រព័ន្ធចែកចាយត្រូវបានតភ្ជាប់ដោយតំណភ្ជាប់បណ្តាញ ហើយតំណភ្ជាប់បណ្តាញអាច និងនឹងត្រូវបានផ្តាច់។ ភាពញឹកញាប់នៃការដាច់ភ្លើងអាស្រ័យលើហេដ្ឋារចនាសម្ព័ន្ធក្នុងតំបន់ ឬភាពជឿជាក់នៃពពកដែលបានជ្រើសរើស។ ក្នុងករណីណាក៏ដោយ ប្រព័ន្ធចែកចាយត្រូវតែអាចដោះស្រាយជាមួយពួកគេ។ ជាថ្មីម្តងទៀត យើងមានជម្រើសរវាងភាពអាចរកបាន និងភាពស៊ីសង្វាក់គ្នា ហើយម្តងទៀត ដំណឹងល្អគឺថា RabbitMQ ផ្តល់ជម្រើសទាំងពីរ (មិនមែនក្នុងពេលតែមួយទេ)។

ជាមួយ RabbitMQ យើងមានជម្រើសសំខាន់ពីរ៖

• អនុញ្ញាតឱ្យបែងចែកតក្កវិជ្ជា (បំបែកខួរក្បាល) ។ វាធានានូវភាពអាចរកបាន ប៉ុន្តែអាចបណ្តាលឱ្យបាត់បង់ទិន្នន័យ។
• បិទការបំបែកឡូជីខល។ អាចបណ្តាលឱ្យបាត់បង់ភាពអាចរកបានក្នុងរយៈពេលខ្លី អាស្រ័យលើរបៀបដែលអតិថិជនភ្ជាប់ទៅចង្កោម។ ក៏អាចនាំឱ្យមានភាពមិនអាចប្រើបានពេញលេញនៅក្នុងចង្កោមថ្នាំងពីរ។

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

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

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

របៀបផ្សេងគ្នារបស់ RabbitMQ ផ្តល់នូវភាពអាចរកបាន ឬភាពស៊ីសង្វាក់គ្នា។

របៀបមិនអើពើ (លំនាំដើម)

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

អង្ករ។ 18. អ្នកបោះពុម្ពបីនាក់ត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងឈ្មួញកណ្តាលបីនាក់។ នៅខាងក្នុង ចង្កោមបញ្ជូនសំណើទាំងអស់ទៅកាន់ជួរមេនៅលើឈ្មួញកណ្តាល 2 ។

ឥឡូវនេះយើងកំពុងបាត់បង់ Broker 3 ។ គាត់ឃើញថាឈ្មួញកណ្តាលផ្សេងទៀតបានធ្លាក់ចុះហើយផ្សព្វផ្សាយកញ្ចក់របស់គាត់ទៅមេ។ នេះជារបៀបដែលការបំបែកឡូជីខលកើតឡើង។

អង្ករ។ 19. ការបែងចែកឡូជីខល (បំបែកខួរក្បាល) ។ កំណត់ត្រាចូលទៅក្នុងជួរសំខាន់ពីរ ហើយច្បាប់ចម្លងទាំងពីរខុសគ្នា។

ការតភ្ជាប់ត្រូវបានស្ដារឡើងវិញ ប៉ុន្តែការបំបែកឡូជីខលនៅតែមាន។ អ្នកគ្រប់គ្រងត្រូវតែជ្រើសរើសផ្នែកដែលចាញ់ដោយដៃ។ ក្នុងករណីខាងក្រោម អ្នកគ្រប់គ្រងចាប់ផ្ដើម Broker 3 ឡើងវិញ។ សារទាំងអស់ដែលគាត់មិនបានគ្រប់គ្រងដើម្បីបញ្ជូនត្រូវបានបាត់បង់។

អង្ករ។ 20. អ្នកគ្រប់គ្រងបិទ Broker 3 ។

អង្ករ។ 21. អ្នកគ្រប់គ្រងចាប់ផ្តើម Broker 3 ហើយវាភ្ជាប់ជាមួយ cluster ដោយបាត់បង់សារទាំងអស់ដែលបានទុកនៅទីនោះ។

កំឡុងពេលបាត់បង់ការតភ្ជាប់ និងបន្ទាប់ពីការស្ដារឡើងវិញ ចង្កោម និងជួរនេះអាចរកបានសម្រាប់ការអាន និងសរសេរ។

របៀបព្យាបាលដោយស្វ័យប្រវត្តិ

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

ផ្អាករបៀបជនជាតិភាគតិច

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

អង្ករ។ 22. អ្នកបោះពុម្ពបីនាក់ត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងឈ្មួញកណ្តាលបីនាក់។ នៅខាងក្នុង ចង្កោមបញ្ជូនសំណើទាំងអស់ទៅកាន់ជួរមេនៅលើឈ្មួញកណ្តាល 2 ។

ឈ្មួញកណ្តាលទី 1 និងទី 2 បន្ទាប់មកបានបំបែកចេញពីឈ្មួញកណ្តាលទី 3 ។ ជំនួសឱ្យការផ្សព្វផ្សាយកញ្ចក់របស់ពួកគេទៅជាមេ ឈ្មួញកណ្តាលទី 3 ផ្អាក ហើយក្លាយជាមិនអាចប្រើបាន។

អង្ករ។ 23. ឈ្មួញកណ្តាល 3 ផ្អាក ផ្តាច់អតិថិជនទាំងអស់ និងបដិសេធសំណើការតភ្ជាប់។

នៅពេលដែលការតភ្ជាប់ត្រូវបានស្ដារឡើងវិញ វាត្រឡប់ទៅក្រុមវិញ។

សូមក្រឡេកមើលឧទាហរណ៍មួយទៀតដែលជួរសំខាន់គឺនៅលើ Broker 3 ។

អង្ករ។ 24. ជួរសំខាន់នៅលើឈ្មួញកណ្តាល 3 ។

បន្ទាប់មកការបាត់បង់ការតភ្ជាប់ដូចគ្នាកើតឡើង។ ឈ្មួញកណ្តាល 3 ផ្អាកព្រោះវានៅផ្នែកតូចជាង។ នៅផ្នែកម្ខាងទៀត ថ្នាំងមើលឃើញថា Broker 3 បានធ្លាក់ចុះ ដូច្នេះកញ្ចក់ចាស់ពី Brokers 1 និង 2 ត្រូវបានដំឡើងឋានៈជាមេ។

អង្ករ។ 25. ការផ្លាស់ប្តូរទៅជា Broker 2 ប្រសិនបើ Broker 3 មិនអាចប្រើបាន។

នៅពេលដែលការតភ្ជាប់ត្រូវបានស្ដារឡើងវិញ ឈ្មួញកណ្តាល 3 នឹងចូលរួមជាមួយចង្កោម។

អង្ករ។ 26. ចង្កោមបានត្រលប់ទៅប្រតិបត្តិការធម្មតាវិញ។

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

ដើម្បីធានាបាននូវភាពអាចរកបាន វាមានសារៈសំខាន់ណាស់ក្នុងការធានាថាអតិថិជនអាចភ្ជាប់ទៅម៉ាស៊ីនដោយជោគជ័យ។ សូមក្រឡេកមើលជម្រើសរបស់យើង។

ធានាការតភ្ជាប់អតិថិជន

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

ជម្រើសរបស់យើង៖

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

ការរកឃើញ

RabbitMQ clustering មានគុណសម្បត្តិ និងគុណវិបត្តិរបស់វា។ គុណវិបត្តិធ្ងន់ធ្ងរបំផុតគឺ៖

• នៅពេលភ្ជាប់ចង្កោម ថ្នាំងបោះបង់ទិន្នន័យរបស់ពួកគេ;
• ការទប់ស្កាត់ការធ្វើសមកាលកម្មធ្វើឱ្យជួរមិនអាចប្រើបាន។

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

• បណ្តាញមិនគួរឱ្យទុកចិត្ត។
• ការផ្ទុកមិនគួរឱ្យទុកចិត្ត។
• ជួរវែងណាស់។

នៅពេលនិយាយអំពីការកំណត់ភាពអាចរកបានខ្ពស់ សូមពិចារណាដូចខាងក្រោម៖

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ឬ autoheal)
• សារជាប់លាប់
• ត្រូវប្រាកដថាអតិថិជនភ្ជាប់ទៅថ្នាំងសកម្ម នៅពេលដែលថ្នាំងមួយចំនួនបរាជ័យ

សម្រាប់ភាពស៊ីសង្វាក់គ្នា (សុវត្ថិភាពទិន្នន័យ) សូមពិចារណាការកំណត់ខាងក្រោម៖

• អ្នកបោះពុម្ពផ្សាយបញ្ជាក់ និងការទទួលស្គាល់ដោយដៃនៅផ្នែកអតិថិជន
• ha-promote-on-failure=when-syncedប្រសិនបើអ្នកបោះពុម្ពផ្សាយអាចព្យាយាមម្តងទៀតនៅពេលក្រោយ ហើយប្រសិនបើអ្នកមានកន្លែងផ្ទុកដែលអាចទុកចិត្តបាន! បើមិនដូច្នោះទេដាក់ =always.
• ha-sync-mode=automatic (ប៉ុន្តែ​សម្រាប់​របៀប​សៀវភៅដៃ​ជួរ​ធំ​ដែល​អសកម្ម​អាច​ត្រូវ​បាន​ទាមទារ។ សូម​ពិចារណា​ផង​ដែរ​ថា​តើ​ភាព​មិន​អាច​ប្រើ​បាន​នឹង​ធ្វើ​ឱ្យ​សារ​ត្រូវ​បាន​បាត់បង់)
• ផ្អាកមុខងារជនជាតិភាគតិច
• សារជាប់លាប់

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

ប្រសិនបើខ្ញុំខកខានអ្វីផ្សេងទៀតសូមប្រាប់ខ្ញុំ។

សូមមើលរបស់ខ្ញុំផងដែរ។ ប្រកាសដែលជាកន្លែងដែលខ្ញុំធ្វើការបំផ្លិចបំផ្លាញលើក្រុម RabbitMQ ដោយប្រើ Docker និង Blockade ដើម្បីសាកល្បងសេណារីយ៉ូការបាត់បង់សារមួយចំនួនដែលបានពិពណ៌នានៅក្នុងអត្ថបទនេះ។

អត្ថបទមុនក្នុងស៊េរី៖
លេខ 1 - habr.com/ru/company/itsumma/blog/416629
លេខ 2 - habr.com/ru/company/itsumma/blog/418389
លេខ 3 - habr.com/ru/company/itsumma/blog/437446

ប្រភព: www.habr.com