В អត្ថបទចុងក្រោយ យើងបានពិនិត្យមើលក្រុម RabbitMQ សម្រាប់ការអត់ឱនចំពោះកំហុស និងភាពអាចរកបានខ្ពស់។ ឥឡូវនេះ ចូរយើងជីកជ្រៅទៅក្នុង Apache Kafka។

នៅទីនេះឯកតានៃការចម្លងគឺជាភាគថាស។ ប្រធានបទនីមួយៗមានផ្នែកមួយ ឬច្រើន។ ផ្នែកនីមួយៗមានអ្នកដឹកនាំដោយមាន ឬគ្មានអ្នកដើរតាម។ នៅពេលបង្កើតប្រធានបទ អ្នកបញ្ជាក់ចំនួនភាគថាស និងមេគុណនៃការចម្លង។ តម្លៃធម្មតាគឺ 3 ដែលមានន័យថាការចម្លងចំនួនបី៖ អ្នកដឹកនាំម្នាក់និងអ្នកដើរតាមពីរនាក់។

អង្ករ។ 1. ផ្នែកចំនួនបួនត្រូវបានចែកចាយក្នុងចំណោមឈ្មួញកណ្តាលបី

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

ការបរាជ័យផ្នែក

នៅពេលដែលឈ្មួញកណ្តាលបរាជ័យ អ្នកដឹកនាំផ្នែកជាច្រើនតែងតែបរាជ័យ។ នៅក្នុងពួកគេម្នាក់ៗ អ្នកដើរតាមពីថ្នាំងផ្សេងទៀតក្លាយជាអ្នកដឹកនាំ។ តាមពិត នេះមិនមែនតែងតែជាករណីនោះទេ ដោយសារកត្តាធ្វើសមកាលកម្មក៏មានឥទ្ធិពលផងដែរ៖ ថាតើមានអ្នកដើរតាមដែលបានធ្វើសមកាលកម្ម ឬអត់ នោះថាតើការប្តូរទៅការចម្លងដែលមិនសមកាលកម្មត្រូវបានអនុញ្ញាត។ ប៉ុន្តែសូមកុំឲ្យរឿងស្មុគស្មាញសម្រាប់ពេលនេះ។

ឈ្មួញកណ្តាលទី 3 ចាកចេញពីបណ្តាញ ហើយអ្នកដឹកនាំថ្មីត្រូវបានជ្រើសរើសសម្រាប់ផ្នែកទី 2 នៅឈ្មួញកណ្តាលទី 2 ។

អង្ករ។ 2. ឈ្មួញកណ្តាល 3 បានស្លាប់ហើយអ្នកដើរតាមឈ្មួញកណ្តាល 2 ត្រូវបានជ្រើសរើសជាអ្នកដឹកនាំថ្មីនៃភាគទី 2

បន្ទាប់មក មេខ្យល់ ១ ចាកចេញ ហើយផ្នែក ១ ក៏បាត់មេដឹកនាំដែរ ដែលតួនាទីរបស់វាឆ្លងទៅឈ្មួញកណ្តាល ២ ។

អង្ករ។ 3. នៅសល់ឈ្មួញកណ្តាលម្នាក់។ អ្នកដឹកនាំទាំងអស់គឺនៅលើឈ្មួញកណ្តាលតែមួយដោយមិនមានការលែងត្រូវការតទៅទៀត។

នៅពេលដែលឈ្មួញកណ្តាល 1 ត្រលប់មកអនឡាញវិញ វាបន្ថែមអ្នកដើរតាមបួននាក់ ដោយផ្តល់នូវភាពមិនដូចគ្នាខ្លះទៅភាគនីមួយៗ។ ប៉ុន្តែមេដឹកនាំទាំងអស់នៅតែនៅលើមេខ្យល់ ២.

អង្ករ។ ៤.មេដឹកនាំនៅលើឈ្មួញកណ្តាល ២

នៅពេលដែលឈ្មួញកណ្តាល 3 កើតឡើង យើងត្រលប់ទៅការចម្លងចំនួន 2 ក្នុងមួយភាគ។ ប៉ុន្តែមេដឹកនាំទាំងអស់នៅតែលើមេខ្យល់ ២.

អង្ករ។ 5. ការដាក់មេដឹកនាំគ្មានតុល្យភាពបន្ទាប់ពីការស្ដារឡើងវិញនៃឈ្មួញកណ្តាល 1 និង 3

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

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

ដើម្បីដោះស្រាយបញ្ហានេះ Kafka ផ្តល់ជម្រើសពីរ៖

ជម្រើស auto.leader.rebalance.enable=true អនុញ្ញាតឱ្យថ្នាំងឧបករណ៍បញ្ជាកំណត់ឡើងវិញដោយស្វ័យប្រវត្តិនូវអ្នកដឹកនាំត្រឡប់ទៅការចម្លងដែលពេញចិត្ត ហើយដោយហេតុនេះស្ដារការចែកចាយឯកសណ្ឋាន។
អ្នកគ្រប់គ្រងអាចដំណើរការស្គ្រីប kafka-preferred-replica-election.sh សម្រាប់ការចាត់តាំងឡើងវិញដោយដៃ។

អង្ករ។ 6. ការចម្លងបន្ទាប់ពីមានតុល្យភាពឡើងវិញ

នេះគឺជាកំណែសាមញ្ញនៃការបរាជ័យ ប៉ុន្តែការពិតគឺស្មុគ្រស្មាញជាង បើទោះបីជាមិនមានអ្វីស្មុគស្មាញខ្លាំងនៅទីនេះក៏ដោយ។ វាទាំងអស់ចុះមកជាមួយការចម្លងដែលបានធ្វើសមកាលកម្ម (In-Sync Replicas, ISR) ។

ការចម្លងដែលបានធ្វើសមកាលកម្ម (ISR)

ISR គឺជាសំណុំនៃការចម្លងនៃភាគថាសមួយដែលត្រូវបានគេចាត់ទុកថា "ធ្វើសមកាលកម្ម" (ក្នុងសមកាលកម្ម) ។ មានអ្នកដឹកនាំ ប៉ុន្តែប្រហែលជាមិនមានអ្នកដើរតាមទេ។ អ្នកដើរតាមត្រូវបានចាត់ទុកថាធ្វើសមកាលកម្ម ប្រសិនបើវាបានធ្វើច្បាប់ចម្លងពិតប្រាកដនៃសាររបស់អ្នកដឹកនាំទាំងអស់ មុនពេលចន្លោះពេលផុតកំណត់ ចម្លង.lag.time.max.ms.

អ្នកដើរតាមត្រូវដកចេញពីការកំណត់ ISR ប្រសិនបើវា៖

មិនបានធ្វើការស្នើសុំដើម្បីជ្រើសសម្រាប់ចន្លោះពេល ចម្លង.lag.time.max.ms (សន្មត់ថាស្លាប់)
មិនបានគ្រប់គ្រងដើម្បីធ្វើឱ្យទាន់សម័យក្នុងចន្លោះពេល ចម្លង.lag.time.max.ms (ចាត់ទុកថាយឺត)

អ្នកតាមដានធ្វើសំណើគំរូក្នុងចន្លោះពេល ចម្លង.fetch.wait.max.msដែលកំណត់លំនាំដើមដល់ 500ms ។

ដើម្បីពន្យល់យ៉ាងច្បាស់ពីគោលបំណងនៃ ISR យើងត្រូវមើលការបញ្ជាក់ពីអ្នកផលិត និងសេណារីយ៉ូបរាជ័យមួយចំនួន។ អ្នកផលិតអាចជ្រើសរើសពេលដែលឈ្មួញកណ្តាលផ្ញើការបញ្ជាក់៖

acks=0 ការបញ្ជាក់មិនត្រូវបានផ្ញើទេ។
acks=1, ការបញ្ជាក់ត្រូវបានផ្ញើបន្ទាប់ពីអ្នកដឹកនាំបានសរសេរសារទៅកាន់កំណត់ហេតុក្នុងតំបន់របស់គាត់។
acks=all ការបញ្ជាក់ត្រូវបានផ្ញើបន្ទាប់ពីអ្នកចម្លងទាំងអស់នៅក្នុង ISR បានសរសេរសារទៅកាន់កំណត់ហេតុក្នុងស្រុក

នៅក្នុងពាក្យ Kafka ប្រសិនបើ ISR បានរក្សាទុកសារមួយ វាត្រូវបាន "ប្តេជ្ញាចិត្ត" ។ Acks=all គឺជាជម្រើសដែលមានសុវត្ថិភាពបំផុត ប៉ុន្តែក៏បន្ថែមការពន្យារពេលបន្ថែមផងដែរ។ សូមក្រឡេកមើលឧទាហរណ៍ពីរនៃការបរាជ័យ និងរបៀបដែលជម្រើស 'acks' ផ្សេងគ្នាមានអន្តរកម្មជាមួយគំនិត ISR ។

Acks=1 និង ISR

ក្នុងឧទាហរណ៍នេះ យើងនឹងឃើញថា ប្រសិនបើអ្នកដឹកនាំមិនរង់ចាំរាល់សារពីអ្នកតាមដានទាំងអស់ត្រូវបានរក្សាទុកទេ នោះការបាត់បង់ទិន្នន័យគឺអាចធ្វើទៅបាន ប្រសិនបើអ្នកដឹកនាំបរាជ័យ។ ការរុករកទៅកាន់អ្នកដើរតាមដែលមិនសមកាលកម្មអាចត្រូវបានបើក ឬបិទដោយការកំណត់ មិនស្អាត.leader.election.enable.

ក្នុងឧទាហរណ៍នេះ ក្រុមហ៊ុនផលិតមានតម្លៃ acks=1។ ផ្នែកនេះត្រូវបានចែកចាយនៅទូទាំងឈ្មួញកណ្តាលទាំងបី។ ឈ្មួញកណ្តាលទី 3 នៅពីក្រោយ វាធ្វើសមកាលកម្មជាមួយអ្នកដឹកនាំកាលពី 7456 វិនាទីមុន ហើយឥឡូវនេះ 1 សារនៅពីក្រោយ។ ឈ្មួញកណ្តាលទី XNUMX គឺនៅពីក្រោយតែមួយវិនាទីប៉ុណ្ណោះ។ ផលិតកររបស់យើងផ្ញើសារមួយ ហើយទទួលបានមកវិញយ៉ាងឆាប់រហ័ស ដោយមិនមានការហួសពីអ្នកដើរតាមយឺត ឬស្លាប់ដែលអ្នកដឹកនាំមិនរង់ចាំនោះទេ។

អង្ករ។ 7. ISR ជាមួយនឹងការចម្លងចំនួនបី

ឈ្មួញកណ្តាល 2 បរាជ័យ ហើយអ្នកផលិតទទួលបានកំហុសក្នុងការតភ្ជាប់។ បន្ទាប់ពីការដឹកនាំឆ្លងកាត់ទៅឈ្មួញកណ្តាល 1 យើងបាត់បង់សារចំនួន 123 ។ អ្នកដើរតាមឈ្មួញកណ្តាល 1 គឺជាផ្នែកមួយនៃ ISR ប៉ុន្តែមិនត្រូវបានធ្វើសមកាលកម្មពេញលេញជាមួយអ្នកដឹកនាំនៅពេលវាធ្លាក់ចុះ។

អង្ករ។ 8. សារត្រូវបានបាត់បង់នៅពេលដែលវាគាំង

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ bootstrap.servers ក្រុមហ៊ុនផលិតមានឈ្មួញកណ្តាលជាច្រើនដែលបានរាយបញ្ជី ហើយអាចសួរឈ្មួញកណ្តាលផ្សេងទៀតដែលជាអ្នកដឹកនាំផ្នែកថ្មី។ បន្ទាប់មកវាបង្កើតការតភ្ជាប់ទៅឈ្មួញកណ្តាល 1 ហើយបន្តផ្ញើសារ។

អង្ករ។ 9. ការផ្ញើសារបន្តបន្ទាប់ពីសម្រាកខ្លី

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

អង្ករ។ 10. អ្នកដើរតាមឈ្មួញកណ្តាល 3 ត្រូវបានដកចេញពី ISR

ឈ្មួញកណ្តាល 1 ធ្លាក់ចុះហើយតួនាទីដឹកនាំទៅឈ្មួញកណ្តាល 3 ជាមួយនឹងការបាត់បង់ 15286 សារ! ក្រុមហ៊ុនផលិតទទួលបានសារកំហុសក្នុងការតភ្ជាប់។ ការផ្លាស់ប្តូរទៅជាអ្នកដឹកនាំនៅខាងក្រៅ ISR គឺអាចធ្វើទៅបានតែដោយសារការកំណត់ប៉ុណ្ណោះ។ unclean.leader.election.enable=true. ប្រសិនបើវាត្រូវបានដំឡើងនៅក្នុង មិនពិតបន្ទាប់មកការផ្លាស់ប្តូរនឹងមិនកើតឡើងទេ ហើយសំណើអាន និងសរសេរទាំងអស់នឹងត្រូវបានបដិសេធ។ ក្នុងករណីនេះ យើងរង់ចាំឱ្យឈ្មួញកណ្តាល 1 ត្រឡប់មកវិញជាមួយនឹងទិន្នន័យដដែលរបស់គាត់នៅក្នុងការចម្លង ដែលនឹងកាន់កាប់ភាពជាអ្នកដឹកនាំម្តងទៀត។

អង្ករ។ 11. ឈ្មួញកណ្តាល 1 ធ្លាក់។ នៅពេលដែលការបរាជ័យកើតឡើង សារមួយចំនួនធំត្រូវបានបាត់បង់

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

អង្ករ។ 12. បន្ទាប់ពីសម្រាករយៈពេលខ្លី សារត្រូវបានផ្ញើម្តងទៀតទៅកាន់ផ្នែកទី 0

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

Acks = ទាំងអស់ និង ISR

សូមធ្វើសេណារីយ៉ូនេះម្តងទៀត ប៉ុន្តែជាមួយ acks=ទាំងអស់។. ឈ្មួញកណ្តាល 3 មានភាពយឺតយ៉ាវជាមធ្យម XNUMX វិនាទី។ ក្រុមហ៊ុនផលិតផ្ញើសារជាមួយ acks=ទាំងអស់។ហើយឥឡូវនេះមិនទទួលបានការឆ្លើយតបរហ័សទេ។ អ្នកដឹកនាំរង់ចាំសារដែលត្រូវបានរក្សាទុកដោយអ្នកចម្លងទាំងអស់នៅក្នុង ISR ។

អង្ករ។ 13. ISR ជាមួយនឹងការចម្លងចំនួនបី។ មួយគឺយឺត ដែលបណ្តាលឱ្យមានការពន្យារពេលក្នុងការថត

បន្ទាប់ពីបួនវិនាទីនៃការពន្យាពេលបន្ថែម ឈ្មួញកណ្តាល 2 ផ្ញើ ack ។ ការចម្លងទាំងអស់ឥឡូវនេះត្រូវបានធ្វើបច្ចុប្បន្នភាពពេញលេញ។

អង្ករ។ 14. ការចម្លងទាំងអស់រក្សាទុកសារនិងផ្ញើ ack

ឈ្មួញកណ្តាល 3 ឥឡូវនេះធ្លាក់ចុះបន្ថែមទៀតហើយត្រូវបានដកចេញពី ISR ។ ភាពយឺតយ៉ាវត្រូវបានកាត់បន្ថយយ៉ាងខ្លាំង ដោយសារតែមិនមានការចម្លងយឺតៗដែលនៅសល់ក្នុង ISR ទេ។ ឈ្មួញកណ្តាលទី 2 ឥឡូវនេះរង់ចាំតែឈ្មួញកណ្តាលទី 1 ហើយគាត់មានការយឺតយ៉ាវជាមធ្យម 500 ms ។

អង្ករ។ 15. ការចម្លងនៅលើឈ្មួញកណ្តាល 3 ត្រូវបានយកចេញពី ISR

បន្ទាប់មកឈ្មួញកណ្តាល 2 ដួលហើយភាពជាអ្នកដឹកនាំឆ្លងកាត់ទៅឈ្មួញកណ្តាល 1 ដោយមិនបាត់បង់សារ។

អង្ករ។ 16. ឈ្មួញកណ្តាល 2 ធ្លាក់

ក្រុមហ៊ុនផលិតរកឃើញអ្នកដឹកនាំថ្មីហើយចាប់ផ្តើមផ្ញើសារទៅគាត់។ ភាពយឺតយ៉ាវត្រូវបានកាត់បន្ថយបន្ថែមទៀត ពីព្រោះ ISR ឥឡូវនេះមានការចម្លងមួយ! ដូច្នេះជម្រើស acks=ទាំងអស់។ មិនបន្ថែមភាពមិនដូចគ្នាទេ។

អង្ករ។ 17. ការចម្លងនៅលើឈ្មួញកណ្តាល 1 នាំមុខដោយមិនបាត់បង់សារ

បន្ទាប់មក ឈ្មួញកណ្តាល 1 គាំងហើយការនាំមុខទៅឈ្មួញកណ្តាល 3 ជាមួយនឹងការបាត់បង់ 14238 សារ!

អង្ករ។ 18. ឈ្មួញកណ្តាល 1 ស្លាប់ និងការផ្លាស់ប្តូរភាពជាអ្នកដឹកនាំជាមួយនឹងការកំណត់មិនស្អាតនាំឱ្យបាត់បង់ទិន្នន័យយ៉ាងទូលំទូលាយ

យើងមិនអាចដំឡើងជម្រើសបានទេ។ មិនស្អាត.leader.election.enable ចូលទៅក្នុងអត្ថន័យ ជាការពិត. តាមលំនាំដើមវាស្មើគ្នា មិនពិត. ការកំណត់ acks=ទាំងអស់។ с unclean.leader.election.enable=true ផ្តល់នូវភាពងាយស្រួលជាមួយនឹងសុវត្ថិភាពទិន្នន័យបន្ថែមមួយចំនួន។ ប៉ុន្តែដូចដែលអ្នកបានឃើញ យើងនៅតែអាចបាត់បង់សារ។

ប៉ុន្តែចុះយ៉ាងណាបើយើងចង់បង្កើនសុវត្ថិភាពទិន្នន័យ? អ្នកអាចដាក់ clean.leader.election.enable = មិនពិតប៉ុន្តែវានឹងមិនចាំបាច់ការពារយើងពីការបាត់បង់ទិន្នន័យនោះទេ។ ប្រសិនបើអ្នកដឹកនាំពិបាក ហើយយកទិន្នន័យទៅជាមួយនោះ សារនៅតែបាត់បង់ បូករួមទាំងភាពអាចរកបានក៏បាត់បង់រហូតដល់អ្នកគ្រប់គ្រងស្ដារស្ថានភាពឡើងវិញ។

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

Acks=all, min.insync.replicas និង ISR

ជាមួយនឹងការកំណត់ប្រធានបទ min.insync.replicas យើងកំពុងបង្កើនកម្រិតសុវត្ថិភាពទិន្នន័យ។ តោះឆ្លងកាត់ផ្នែកចុងក្រោយនៃសេណារីយ៉ូមុនម្តងទៀត ប៉ុន្តែលើកនេះជាមួយ min.insync.replicas=2.

ដូច្នេះ ឈ្មួញកណ្តាល 2 មានអ្នកដឹកនាំចម្លង ហើយអ្នកដើរតាមឈ្មួញកណ្តាល 3 ត្រូវបានដកចេញពី ISR ។

អង្ករ។ 19. ISR ពីការចម្លងពីរ

ឈ្មួញកណ្តាល 2 ធ្លាក់ហើយភាពជាអ្នកដឹកនាំឆ្លងកាត់ទៅឈ្មួញកណ្តាល 1 ដោយមិនបាត់បង់សារ។ ប៉ុន្តែឥឡូវនេះ ISR មានការចម្លងតែមួយប៉ុណ្ណោះ។ វាមិនត្រូវនឹងចំនួនអប្បបរមាក្នុងការទទួលកំណត់ត្រាទេ ដូច្នេះហើយឈ្មួញកណ្តាលឆ្លើយតបទៅនឹងការប៉ុនប៉ងសរសេរដោយមានកំហុស NotEnoughReplicas.

អង្ករ។ 20. ចំនួន ISRs គឺទាបជាងមួយដែលបានបញ្ជាក់នៅក្នុង min.insync.replicas

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

នៅពេលដែលភាពងាយស្រួលគឺចាំបាច់សម្រាប់សុវត្ថិភាពទិន្នន័យ

ដូចក្នុង។ ករណីជាមួយ RabbitMQពេលខ្លះលទ្ធភាពប្រើប្រាស់គឺចាំបាច់សម្រាប់សុវត្ថិភាពទិន្នន័យ។ នេះជាអ្វីដែលអ្នកត្រូវគិត៖

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

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

អត្ថន័យនៃ ISR

ឈុត ISR អនុញ្ញាតឱ្យអ្នកជ្រើសរើសសមតុល្យដ៏ល្អប្រសើររវាងសុវត្ថិភាពទិន្នន័យ និងភាពយឺតយ៉ាវ។ ជាឧទាហរណ៍ ធានាភាពអាចរកបាននៅក្នុងព្រឹត្តិការណ៍នៃការបរាជ័យនៃការចម្លងភាគច្រើន កាត់បន្ថយផលប៉ះពាល់នៃការចម្លងដែលងាប់ ឬយឺតក្នុងលក្ខខណ្ឌនៃភាពយឺតយ៉ាវ។

យើងជ្រើសរើសអត្ថន័យដោយខ្លួនឯង។ ចម្លង.lag.time.max.ms តាមតម្រូវការរបស់អ្នក។ សំខាន់ ប៉ារ៉ាម៉ែត្រនេះមានន័យថា តើការពន្យារពេលប៉ុន្មានដែលយើងសុខចិត្តទទួលយកនៅពេលណា acks=ទាំងអស់។. តម្លៃលំនាំដើមគឺដប់វិនាទី។ ប្រសិនបើវាវែងពេកសម្រាប់អ្នក អ្នកអាចកាត់បន្ថយវាបាន។ បន្ទាប់មកភាពញឹកញាប់នៃការផ្លាស់ប្តូរនៅក្នុង ISR នឹងកើនឡើង ដោយសារអ្នកដើរតាមនឹងត្រូវដកចេញ ហើយបន្ថែមកាន់តែច្រើនជាញឹកញាប់។

RabbitMQ គឺជាសំណុំនៃកញ្ចក់មួយដែលត្រូវចម្លង។ កញ្ចក់យឺតបង្ហាញភាពយឺតយ៉ាវបន្ថែម ហើយកញ្ចក់ដែលស្លាប់អាចរង់ចាំរហូតដល់កញ្ចប់ព័ត៌មានដែលពិនិត្យមើលភាពអាចរកបាននៃថ្នាំងនីមួយៗ (សញ្ញាធីកសុទ្ធ) ដើម្បីឆ្លើយតប។ ISR គឺជាវិធីគួរឱ្យចាប់អារម្មណ៍មួយដើម្បីជៀសវាងបញ្ហា latency ទាំងនេះ។ ប៉ុន្តែយើងប្រថុយនឹងការបាត់បង់ការប្រើប្រាស់ដដែលៗ ព្រោះ ISR អាចធ្លាក់ចុះដល់ថ្នាក់ដឹកនាំប៉ុណ្ណោះ។ ដើម្បីជៀសវាងហានិភ័យនេះ សូមប្រើការកំណត់ min.insync.replicas.

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

នៅក្នុងការកំណត់។ bootstrap.servers អ្នកផលិត និងអ្នកប្រើប្រាស់អាចបញ្ជាក់ឈ្មួញកណ្តាលច្រើនសម្រាប់ភ្ជាប់អតិថិជន។ គំនិតនេះគឺថានៅពេលដែលថ្នាំងមួយចុះក្រោម វាមានកន្លែងទំនេរជាច្រើនដែលអតិថិជនអាចបើកការតភ្ជាប់បាន។ ទាំងនេះមិនមែនជាអ្នកដឹកនាំផ្នែកចាំបាច់នោះទេ ប៉ុន្តែគ្រាន់តែជាក្តារបន្ទះសម្រាប់ផ្ទុកដំបូងប៉ុណ្ណោះ។ អតិថិជនអាចសួរពួកគេថាតើថ្នាំងណាដែលផ្ទុកអ្នកដឹកនាំផ្នែកអាន/សរសេរ។

នៅក្នុង RabbitMQ អតិថិជនអាចភ្ជាប់ទៅ node ណាមួយ ហើយការបញ្ជូនខាងក្នុងបញ្ជូនសំណើទៅកន្លែងដែលវាត្រូវទៅ។ នេះមានន័យថាអ្នកអាចដំឡើងតុល្យភាពបន្ទុកនៅពីមុខ RabbitMQ ។ Kafka តម្រូវឱ្យអតិថិជនភ្ជាប់ទៅថ្នាំងដែលផ្ទុកអ្នកដឹកនាំភាគដែលត្រូវគ្នា។ ក្នុងស្ថានភាពបែបនេះ អ្នកមិនអាចដំឡើងឧបករណ៍ផ្ទុកបន្ទុកបានទេ។ បញ្ជី bootstrap.servers វាមានសារៈសំខាន់ណាស់ដែលអតិថិជនអាចចូលប្រើ និងស្វែងរកថ្នាំងត្រឹមត្រូវបន្ទាប់ពីបរាជ័យ។

ស្ថាបត្យកម្ម Kafka Consensus

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

ចង្កោម Kafka នីមួយៗត្រូវបានដាក់ពង្រាយរួមជាមួយនឹងចង្កោម Zookeeper ដែលជាសេវាការយល់ស្របដែលបានចែកចាយដែលអនុញ្ញាតឱ្យប្រព័ន្ធឈានដល់ការយល់ស្របលើស្ថានភាពដែលបានផ្តល់ឱ្យមួយចំនួន ដោយផ្តល់អាទិភាពដល់ភាពស៊ីសង្វាក់គ្នាលើភាពអាចរកបាន។ ការយល់ព្រមពីថ្នាំង Zookeeper ភាគច្រើនគឺត្រូវបានទាមទារ ដើម្បីអនុម័តប្រតិបត្តិការអាន និងសរសេរ។

Zookeeper រក្សាទុកស្ថានភាពនៃចង្កោម៖

បញ្ជីប្រធានបទ ផ្នែក ការកំណត់រចនាសម្ព័ន្ធ ការចម្លងអ្នកដឹកនាំបច្ចុប្បន្ន ការចម្លងដែលពេញចិត្ត។
សមាជិកក្រុម។ ឈ្មួញកណ្តាលនីមួយៗ ping ចង្កោម Zookeeper ។ ប្រសិនបើវាមិនទទួលបាន ping ក្នុងរយៈពេលជាក់លាក់ណាមួយនោះ Zookeeper កត់ត្រាឈ្មួញកណ្តាលថាមិនអាចប្រើបាន។
ការជ្រើសរើសថ្នាំងសំខាន់ និងទំនេរសម្រាប់ឧបករណ៍បញ្ជា។

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

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

សម្រាប់ឧបករណ៍បញ្ជាផ្នែកនីមួយៗ៖

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

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

អ្នកដឹកនាំនីមួយៗទទួលខុសត្រូវក្នុងការជ្រើសរើស ISRs ។ ការកំណត់ ចម្លង.lag.time.max.ms កំណត់ថាអ្នកណានឹងចូលទីនោះ។ នៅពេលដែល ISR ផ្លាស់ប្តូរ អ្នកដឹកនាំបញ្ជូនព័ត៌មានថ្មីទៅ Zookeeper ។

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

អង្ករ។ 21. Kafka Consensus

ពិធីការចម្លង

ការយល់ដឹងលម្អិតនៃការចម្លងជួយអ្នកឱ្យយល់កាន់តែច្បាស់អំពីសេណារីយ៉ូការបាត់បង់ទិន្នន័យដែលអាចកើតមាន។

សំណួរគំរូ កំណត់ហេតុបញ្ចប់អុហ្វសិត (LEO) និង Highwater Mark (HW)

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

អ្នកដឹកនាំ និងអ្នកដើរតាមទាំងអស់រក្សាទុក Log End Offset (LEO) និងស្លាក Highwater (HW) ។ សញ្ញាសម្គាល់ LEO រក្សាទុកអុហ្វសិតនៃសារចុងក្រោយនៅក្នុងការចម្លងក្នុងស្រុក ហើយ HW រក្សាអុហ្វសិតនៃការប្តេជ្ញាចិត្តចុងក្រោយ។ សូមចងចាំថាសម្រាប់ស្ថានភាពការប្តេជ្ញា សារត្រូវតែបន្តនៅទូទាំងការចម្លង ISR ទាំងអស់។ នេះមានន័យថា LEO ជាធម្មតានាំមុខ HW បន្តិច។

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

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

អ្នកដឹកនាំបរាជ័យ

នៅពេលដែលអ្នកដឹកនាំដួល Zookeeper ជូនដំណឹងដល់ឧបករណ៍បញ្ជា ហើយវាជ្រើសរើសអ្នកដឹកនាំថ្មី។ អ្នកដឹកនាំថ្មីកំណត់សញ្ញាសម្គាល់ HW ថ្មីយោងទៅតាម LEO របស់គាត់។ បន្ទាប់មក អ្នកតាមដានទទួលបានព័ត៌មានអំពីអ្នកដឹកនាំថ្មី។ អាស្រ័យលើកំណែរបស់ Kafka អ្នកតាមដាននឹងជ្រើសរើសសេណារីយ៉ូមួយក្នុងចំណោមសេណារីយ៉ូពីរ៖

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

អ្នកដើរតាមប្រហែលជាត្រូវកាត់បន្ថយកំណត់ហេតុដោយហេតុផលដូចខាងក្រោម៖

នៅពេលដែលអ្នកដឹកនាំបរាជ័យ អ្នកដើរតាមទីមួយនៅក្នុងសំណុំ ISR ដែលបានចុះឈ្មោះជាមួយ Zookeeper ឈ្នះការបោះឆ្នោត ហើយក្លាយជាអ្នកដឹកនាំ។ អ្នកតាមដានទាំងអស់នៅលើ ISR ទោះបីជាត្រូវបានចាត់ទុកថាជា "សមកាលកម្ម" ប្រហែលជាមិនបានទទួលច្បាប់ចម្លងនៃសារទាំងអស់ពីអតីតមេដឹកនាំនោះទេ។ វាអាចទៅរួចទាំងស្រុងដែលអ្នកតាមដានលក្ខណៈពិសេសមិនមានច្បាប់ចម្លងទាន់សម័យបំផុត។ Kafka ធានាថាមិនមានភាពខុសគ្នារវាងការចម្លងទេ។ ដូច្នេះ ដើម្បីជៀសវាងភាពមិនស៊ីសង្វាក់គ្នា អ្នកដើរតាមម្នាក់ៗត្រូវតែកាត់កំណត់ហេតុរបស់វាទៅជាតម្លៃ HW របស់មេដឹកនាំថ្មីនៅពេលបោះឆ្នោតរបស់គាត់។ នេះជាហេតុផលមួយទៀតដែលកំណត់ acks=ទាំងអស់។ មានសារៈសំខាន់ណាស់សម្រាប់ស្ថិរភាព។
សារត្រូវបានសរសេរជាទៀងទាត់ទៅថាស។ ប្រសិនបើថ្នាំងចង្កោមទាំងអស់បរាជ័យក្នុងពេលតែមួយ នោះការចម្លងដែលមានអុហ្វសិតផ្សេងៗនឹងត្រូវបានរក្សាទុកនៅលើថាស។ វាអាចទៅរួចដែលថានៅពេលដែលឈ្មួញកណ្តាលត្រលប់មកអនឡាញវិញ អ្នកដឹកនាំថ្មីដែលត្រូវបានជ្រើសរើសនឹងនៅពីក្រោយអ្នកដើរតាមរបស់គាត់ ពីព្រោះគាត់ត្រូវបានរក្សាទុកក្នុងថាសមុនអ្នកដទៃ។

ការជួបជុំគ្នាជាមួយក្រុម

នៅពេលចូលរួមក្រុមឡើងវិញ អ្នកចម្លងធ្វើដូចគ្នានឹងពេលដែលអ្នកដឹកនាំបរាជ័យដែរ៖ ពួកគេពិនិត្យមើលការចម្លងរបស់អ្នកដឹកនាំ ហើយកាត់កំណត់ហេតុរបស់ពួកគេទៅជា HW របស់វា (នៅពេលបោះឆ្នោត)។ នៅក្នុងការប្រៀបធៀប RabbitMQ ស្មើភាពគ្នាព្យាបាលថ្នាំងដែលបានបង្រួបបង្រួមដូចថ្មីទាំងស្រុង។ ក្នុងករណីទាំងពីរ ឈ្មួញកណ្តាលបោះបង់រដ្ឋដែលមានស្រាប់។ ប្រសិនបើការធ្វើសមកាលកម្មដោយស្វ័យប្រវត្តិត្រូវបានប្រើ នោះមេត្រូវតែចម្លងខ្លឹមសារបច្ចុប្បន្នទាំងអស់ទៅកញ្ចក់ថ្មីក្នុងវិធីសាស្ត្រ "ទុកឱ្យពិភពលោកទាំងមូលរង់ចាំ" ។ មេមិនទទួលយកប្រតិបត្តិការអាន ឬសរសេរណាមួយក្នុងអំឡុងពេលប្រតិបត្តិការនេះទេ។ វិធីសាស្រ្តនេះបង្កើតបញ្ហានៅក្នុងជួរធំ។

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

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

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

Kafka មានសមាសធាតុច្រើនជាង RabbitMQ ដូច្នេះវាមានសំណុំអាកប្បកិរិយាស្មុគស្មាញជាងនៅពេលដែលចង្កោមត្រូវបានផ្តាច់។ ប៉ុន្តែ Kafka ដើមឡើយត្រូវបានរចនាឡើងសម្រាប់ចង្កោម ដូច្នេះដំណោះស្រាយត្រូវបានគិតយ៉ាងល្អ។

ខាងក្រោមនេះជាសេណារីយ៉ូបរាជ័យក្នុងការតភ្ជាប់មួយចំនួន៖

សេណារីយ៉ូទី១៖ អ្នកដើរតាមមិនឃើញអ្នកដឹកនាំទេ ប៉ុន្តែនៅតែឃើញអ្នកថែសួនសត្វ។
សេណារីយ៉ូទី 2៖ អ្នកដឹកនាំមិនឃើញអ្នកដើរតាមទេ ប៉ុន្តែនៅតែឃើញ Zookeeper ។
សេណារីយ៉ូទី ៣៖ អ្នកដើរតាមឃើញអ្នកដឹកនាំ តែមិនឃើញ Zookeeper ។
សេណារីយ៉ូទី ៤៖ អ្នកដឹកនាំឃើញអ្នកដើរតាម ប៉ុន្តែមិនឃើញ Zookeeper ។
សេណារីយ៉ូទី 5៖ អ្នកដើរតាមគឺដាច់ដោយឡែកទាំងស្រុងពីថ្នាំង Kafka ផ្សេងទៀត និង Zookeeper ។
សេណារីយ៉ូទី 6៖ អ្នកដឹកនាំគឺដាច់ដោយឡែកទាំងស្រុងពីថ្នាំង Kafka ផ្សេងទៀត និង Zookeeper ។
សេណារីយ៉ូទី 7៖ ថ្នាំងឧបករណ៍បញ្ជា Kafka មិនអាចមើលឃើញថ្នាំង Kafka ផ្សេងទៀតទេ។
សេណារីយ៉ូទី ៨៖ ឧបករណ៍បញ្ជា Kafka មិនឃើញ Zookeeper ទេ។

សេណារីយ៉ូនីមួយៗមានអាកប្បកិរិយាផ្ទាល់ខ្លួន។

សេណារីយ៉ូទី១៖ អ្នកដើរតាមមិនឃើញអ្នកដឹកនាំទេ ប៉ុន្តែនៅតែឃើញ Zookeeper

អង្ករ។ 22. សេណារីយ៉ូទី 1: ISR នៃការចម្លងចំនួនបី

ការបរាជ័យក្នុងការតភ្ជាប់បំបែកឈ្មួញកណ្តាល 3 ពីឈ្មួញកណ្តាល 1 និង 2 ប៉ុន្តែមិនមែនពី Zookeeper ទេ។ ឈ្មួញកណ្តាល 3 មិនអាចផ្ញើសំណើទៅយកបានទេ។ បន្ទាប់ពីពេលវេលាបានកន្លងផុតទៅ ចម្លង.lag.time.max.ms វាត្រូវបានដកចេញពី ISR និងមិនចូលរួមក្នុងការសន្យាសារ។ នៅពេលដែលការតភ្ជាប់ត្រូវបានស្ដារឡើងវិញ វានឹងបន្តការស្នើសុំយក និងចូលរួម ISR នៅពេលដែលវាចាប់បានជាមួយអ្នកដឹកនាំ។ Zookeeper នឹងបន្តទទួលបាន pings ហើយសន្មតថាឈ្មួញកណ្តាលនៅរស់រានមានជីវិត។

អង្ករ។ 23. សេណារីយ៉ូទី 1៖ ឈ្មួញកណ្តាលត្រូវបានដកចេញពី ISR ប្រសិនបើគ្មានការស្នើសុំទៅយកពីវាក្នុងចន្លោះពេល replica.lag.time.max.ms

មិនមានការផ្អាកខួរក្បាល ឬថ្នាំងដូចនៅក្នុង RabbitMQ ទេ។ ផ្ទុយទៅវិញ ភាពមិនប្រក្រតីត្រូវបានកាត់បន្ថយ។

សេណារីយ៉ូទី 2៖ អ្នកដឹកនាំមិនឃើញអ្នកដើរតាមទេ ប៉ុន្តែនៅតែឃើញ Zookeeper

អង្ករ។ 24. សេណារីយ៉ូ 2. អ្នកដឹកនាំនិងអ្នកដើរតាមពីរនាក់

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

អង្ករ។ 25. សេណារីយ៉ូ 2. ISR បានបង្រួញតែចំពោះអ្នកដឹកនាំប៉ុណ្ណោះ។

សេណារីយ៉ូ 3. អ្នកដើរតាមឃើញអ្នកដឹកនាំ តែមិនឃើញ Zookeeper

អ្នកដើរតាមត្រូវបានបំបែកចេញពី Zookeeper ប៉ុន្តែមិនមែនមកពីឈ្មួញកណ្តាលជាមួយអ្នកដឹកនាំនោះទេ។ ជាលទ្ធផល អ្នកតាមដានបន្តធ្វើការស្នើសុំយក និងជាសមាជិកនៃ ISR ។ Zookeeper លែងទទួលបាន pings និងចុះឈ្មោះ broker crash ទៀតហើយ ប៉ុន្តែដោយសារវាគ្រាន់តែជា follower ប៉ុណ្ណោះ វាមិនមានផលវិបាកបន្ទាប់ពីការជាសះស្បើយទេ។

អង្ករ។ 26. សេណារីយ៉ូទី 3: អ្នកដើរតាមបន្តផ្ញើសំណើរទៅអ្នកដឹកនាំ

សេណារីយ៉ូ 4. អ្នកដឹកនាំមើលឃើញអ្នកដើរតាម ប៉ុន្តែមិនឃើញ Zookeeper

អង្ករ។ 27. សេណារីយ៉ូ 4. អ្នកដឹកនាំនិងអ្នកដើរតាមពីរនាក់

អ្នកដឹកនាំត្រូវបានបំបែកចេញពី Zookeeper ប៉ុន្តែមិនមែនមកពីឈ្មួញកណ្តាលជាមួយអ្នកដើរតាមទេ។

អង្ករ។ 28. សេណារីយ៉ូទី 4: អ្នកដឹកនាំនៅដាច់ដោយឡែកពី Zookeeper

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

សារ acks=ទាំងអស់។ នឹងមិនទទួលបានការទទួលស្គាល់ទេព្រោះ ISR ដំបូងបើកការចម្លងទាំងអស់ ហើយសារមិនបានទៅដល់ពួកវាទេ។ នៅពេលដែលអ្នកដឹកនាំដើមព្យាយាមដកពួកគេចេញពី ISR វានឹងមិនអាចធ្វើដូច្នេះបានទេ ហើយនឹងឈប់ទទួលយកសារណាមួយទាល់តែសោះ។

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

អង្ករ។ 29. សេណារីយ៉ូ 4. អ្នកដឹកនាំនៅលើឈ្មួញកណ្តាល 1 ក្លាយជាអ្នកដើរតាមបន្ទាប់ពីបណ្តាញត្រូវបានស្ដារឡើងវិញ

សេណារីយ៉ូទី 5៖ អ្នកដើរតាមគឺដាច់ដោយឡែកទាំងស្រុងពីថ្នាំង Kafka ផ្សេងទៀត និង Zookeeper

អ្នកដើរតាមគឺដាច់ដោយឡែកទាំងស្រុងពីថ្នាំង Kafka ផ្សេងទៀត និង Zookeeper ។ គាត់គ្រាន់តែដកខ្លួនគាត់ចេញពី ISR រហូតដល់បណ្តាញត្រូវបានស្ដារឡើងវិញ ហើយបន្ទាប់មកតាមទាន់អ្នកដទៃ។

អង្ករ។ 30. សេណារីយ៉ូទី 5: អ្នកដើរតាមដាច់ឆ្ងាយពី ISR

សេណារីយ៉ូទី 6៖ អ្នកដឹកនាំគឺដាច់ដោយឡែកទាំងស្រុងពីថ្នាំង Kafka ផ្សេងទៀត និង Zookeeper

អង្ករ។ 31. សេណារីយ៉ូ 6. អ្នកដឹកនាំនិងអ្នកដើរតាមពីរនាក់

អ្នកដឹកនាំគឺនៅដាច់ដោយឡែកពីអ្នកដើរតាមរបស់គាត់ អ្នកត្រួតពិនិត្យ និង Zookeeper ។ ក្នុងរយៈពេលខ្លី វានឹងបន្តទទួលយកធាតុពី acks=1.

អង្ករ។ 32. សេណារីយ៉ូទី 6: ញែកអ្នកដឹកនាំចេញពីថ្នាំង Kafka និង Zookeeper ផ្សេងទៀត។

មិនបានទទួលសំណើបន្ទាប់ពីផុតកំណត់ ចម្លង.lag.time.max.msវានឹងព្យាយាមបង្រួម ISR ទៅខ្លួនវា ប៉ុន្តែនឹងមិនអាចធ្វើបានទេ ព្រោះមិនមានទំនាក់ទំនងជាមួយ Zookeeper នោះវានឹងឈប់ទទួលយកការសរសេរ។

ទន្ទឹមនឹងនេះ Zookeeper នឹងសម្គាល់ឈ្មួញកណ្តាលដាច់ស្រយាលថាបានស្លាប់ហើយអ្នកត្រួតពិនិត្យនឹងជ្រើសរើសអ្នកដឹកនាំថ្មី។

អង្ករ។ 33. សេណារីយ៉ូ 6. មេដឹកនាំពីរនាក់

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

អង្ករ។ 34. សេណារីយ៉ូទី 6: ក្រុមហ៊ុនផលិតប្តូរទៅអ្នកដឹកនាំថ្មី។

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

អង្ករ។ 35. សេណារីយ៉ូទី 6៖ អ្នកដឹកនាំដើមក្លាយជាអ្នកដើរតាម បន្ទាប់ពីការតភ្ជាប់បណ្តាញត្រូវបានស្ដារឡើងវិញ

ក្នុងស្ថានភាពនេះ ការបំបែកឡូជីខលអាចកើតឡើងក្នុងរយៈពេលខ្លីមួយ ប៉ុន្តែបានតែក្នុងករណី acks=1 и min.insync.replicas ផងដែរ 1. ការបំបែកឡូជីខលបញ្ចប់ដោយស្វ័យប្រវត្តិបន្ទាប់ពីបណ្តាញត្រូវបានស្ដារឡើងវិញ នៅពេលដែលអ្នកដឹកនាំដើមដឹងថាគាត់មិនមែនជាអ្នកដឹកនាំទៀតទេ ឬនៅពេលដែលអតិថិជនទាំងអស់ដឹងថាអ្នកដឹកនាំបានផ្លាស់ប្តូរ ហើយចាប់ផ្តើមសរសេរទៅកាន់អ្នកដឹកនាំថ្មី - អ្វីក៏ដោយកើតឡើងមុន។ ក្នុងករណីណាក៏ដោយ សារមួយចំនួននឹងត្រូវបាត់បង់ ប៉ុន្តែបានតែជាមួយ acks=1.

មានភាពខុសគ្នាមួយទៀតនៃសេណារីយ៉ូនេះ ដែលមុនពេលបណ្តាញបំបែក អ្នកដើរតាមបានធ្លាក់ចុះពីក្រោយ ហើយអ្នកដឹកនាំបានបង្ហាប់ ISR មកត្រឹមខ្លួនគាត់។ បន្ទាប់មកវាក្លាយជាដាច់ដោយឡែកដោយសារការបាត់បង់ការតភ្ជាប់។ មេដឹកនាំថ្មីត្រូវបានជ្រើសតាំង ប៉ុន្តែមេដឹកនាំដើមនៅតែបន្តទទួលយកការចូលរួមទាំងអស់ acks=ទាំងអស់។ពីព្រោះមិនមាននរណាម្នាក់ផ្សេងទៀតនៅក្នុង ISR លើកលែងតែគាត់។ កំណត់ត្រាទាំងនេះនឹងបាត់បង់នៅពេលដែលបណ្តាញត្រូវបានស្ដារឡើងវិញ។ មធ្យោបាយតែមួយគត់ដើម្បីជៀសវាងជម្រើសនេះគឺ min.insync.replicas = 2.

សេណារីយ៉ូទី 7៖ ថ្នាំងឧបករណ៍បញ្ជា Kafka មិនអាចមើលឃើញថ្នាំង Kafka ផ្សេងទៀតទេ។

ជាទូទៅ នៅពេលដែលការភ្ជាប់ជាមួយថ្នាំង Kafka ត្រូវបានបាត់បង់ ឧបករណ៍បញ្ជានឹងមិនអាចបញ្ជូនព័ត៌មានការផ្លាស់ប្តូរអ្នកដឹកនាំណាមួយទៅវាបានទេ។ ក្នុងករណីដ៏អាក្រក់បំផុត នេះនឹងនាំឱ្យមានការបំបែកឡូជីខលក្នុងរយៈពេលខ្លី ដូចនៅក្នុងសេណារីយ៉ូទី 6។ ជាញឹកញាប់ជាងនេះ ឈ្មួញកណ្តាលនឹងមិនក្លាយជាបេក្ខជនសម្រាប់ភាពជាអ្នកដឹកនាំទេ ប្រសិនបើការបរាជ័យចុងក្រោយនេះ។

សេណារីយ៉ូទី ៨៖ ឧបករណ៍បញ្ជា Kafka មិនឃើញ Zookeeper ទេ។

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

ការសន្និដ្ឋានពីសេណារីយ៉ូ

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

ប្រសិនបើអ្នកដឹកនាំត្រូវបានបំបែកចេញពី Zookeeper ដោយសារតែការបាត់បង់ការតភ្ជាប់ វាអាចបណ្តាលឱ្យបាត់បង់សារពី acks=1. កង្វះការប្រាស្រ័យទាក់ទងជាមួយ Zookeeper បណ្តាលឱ្យមានការបែកគ្នាយ៉ាងខ្លីជាមួយមេដឹកនាំទាំងពីរ។ បញ្ហានេះត្រូវបានដោះស្រាយដោយប៉ារ៉ាម៉ែត្រ acks=ទាំងអស់។.

ប៉ារ៉ាម៉ែត្រ min.insync.replicas ក្នុងការចម្លងពីរ ឬច្រើនផ្តល់នូវការធានាបន្ថែមថាសេណារីយ៉ូរយៈពេលខ្លីបែបនេះនឹងមិនបណ្តាលឱ្យបាត់បង់សារដូចនៅក្នុងសេណារីយ៉ូទី 6 នោះទេ។

សេចក្តីសង្ខេបនៃសារដែលបាត់

ចូររាយបញ្ជីវិធីទាំងអស់ដែលអ្នកអាចបាត់បង់ទិន្នន័យនៅក្នុង Kafka៖

មេដឹកនាំណាមួយបរាជ័យ ប្រសិនបើសារត្រូវបានបញ្ជាក់ដោយប្រើ acks=1
ការផ្លាស់ប្តូរភាពមិនស្អាតស្អំណាមួយនៃភាពជាអ្នកដឹកនាំ នោះគឺទៅកាន់អ្នកដើរតាមខាងក្រៅ ISR សូម្បីតែជាមួយ acks=ទាំងអស់។
ញែកអ្នកដឹកនាំចេញពី Zookeeper ប្រសិនបើសារត្រូវបានបញ្ជាក់ដោយប្រើ acks=1
ភាពឯកោពេញលេញនៃអ្នកដឹកនាំដែលបានបង្រួញក្រុម ISR ឱ្យធ្លាក់ចុះមកលើខ្លួនគាត់។ សារទាំងអស់នឹងត្រូវបាត់បង់ សូម្បីតែ acks=ទាំងអស់។. នេះជាការពិតប្រសិនបើ min.insync.replicas=1.
ការបរាជ័យក្នុងពេលដំណាលគ្នានៃថ្នាំងភាគថាសទាំងអស់។ ដោយសារសារត្រូវបានទទួលស្គាល់ពីអង្គចងចាំ ខ្លះប្រហែលជាមិនទាន់ត្រូវបានសរសេរទៅថាសទេ។ បន្ទាប់ពីចាប់ផ្តើមម៉ាស៊ីនមេឡើងវិញ សារមួយចំនួនអាចនឹងបាត់។

ការផ្លាស់ប្តូរភាពជាអ្នកដឹកនាំមិនបរិសុទ្ធអាចត្រូវបានជៀសវាងបានដោយការហាមឃាត់ពួកគេ ឬធានាឱ្យបានយ៉ាងហោចណាស់ចំនួនពីរ។ ការកំណត់រចនាសម្ព័ន្ធជាប់លាប់បំផុតគឺការរួមបញ្ចូលគ្នា acks=ទាំងអស់។ и min.insync.replicas ច្រើនជាង ០ ។

ការប្រៀបធៀបដោយផ្ទាល់នៃភាពអាចជឿជាក់បានរបស់ RabbitMQ និង Kafka

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

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

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

fsync រៀងរាល់ពីរបីរយមីលីវិនាទី
ការបរាជ័យនៃកញ្ចក់អាចត្រូវបានគេកត់សម្គាល់ឃើញតែបន្ទាប់ពីអាយុកាលនៃកញ្ចប់ព័ត៌មានដែលពិនិត្យមើលភាពអាចរកបាននៃថ្នាំងនីមួយៗ (ធីកសុទ្ធ) បានផុតកំណត់។ ប្រសិនបើកញ្ចក់បន្ថយល្បឿន ឬធ្លាក់ចុះ វាបន្ថែមការពន្យារពេល។

ការភ្នាល់របស់ Kafka គឺថាប្រសិនបើសារមួយត្រូវបានរក្សាទុកនៅលើថ្នាំងច្រើន វាអាចទទួលស្គាល់សារបានភ្លាមៗនៅពេលដែលពួកគេប៉ះអង្គចងចាំ។ ដោយសារតែនេះ, មានហានិភ័យនៃការបាត់បង់សារនៃប្រភេទណាមួយ (សូម្បីតែ acks=ទាំងអស់។, min.insync.replicas=2) ក្នុងករណីមានការបរាជ័យក្នុងពេលដំណាលគ្នា។

សរុបមក Kafka បង្ហាញដំណើរការកម្មវិធីប្រសើរជាងមុន ហើយត្រូវបានរចនាឡើងពីមូលដ្ឋានសម្រាប់ចង្កោម។ ចំនួនអ្នកតាមអាចត្រូវបានកើនឡើងដល់ 11 ប្រសិនបើចាំបាច់សម្រាប់ភាពជឿជាក់។ កត្តាចម្លង 5 និងចំនួនអប្បបរមានៃការចម្លងនៅក្នុងការធ្វើសមកាលកម្ម min.insync.replicas=3 នឹងធ្វើឱ្យការបាត់បង់សារជាព្រឹត្តិការណ៍ដ៏កម្រមួយ។ ប្រសិនបើហេដ្ឋារចនាសម្ព័ន្ធរបស់អ្នកអាចគាំទ្រសមាមាត្រនៃការចម្លងនេះ និងកម្រិតនៃការលែងត្រូវការតទៅទៀតនោះ អ្នកអាចជ្រើសរើសជម្រើសនេះ។

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

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

ជាចុងក្រោយ កុំភ្លេចអំពីកំហុសមួយចំនួននៅក្នុងយន្តការចង្កោម និងការចម្លងទាំង RabbitMQ និង Kafka។ យូរៗទៅ ប្រព័ន្ធកាន់តែមានភាពចាស់ទុំ និងមានស្ថេរភាព ប៉ុន្តែគ្មានសារណាដែលមានសុវត្ថិភាព 100% ពីការខាតបង់ឡើយ! លើសពីនេះ គ្រោះថ្នាក់ទ្រង់ទ្រាយធំកើតឡើងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ!

ប្រសិនបើខ្ញុំខកខានអ្វីមួយ បានធ្វើខុស ឬអ្នកមិនយល់ស្របនឹងចំណុចណាមួយ សូមមានអារម្មណ៍សេរីក្នុងការបញ្ចេញមតិ ឬទាក់ទងមកខ្ញុំ។

ខ្ញុំត្រូវបានគេសួរជាញឹកញាប់ថា "តើត្រូវជ្រើសរើសអ្វី Kafka ឬ RabbitMQ?", "វេទិកាមួយណាល្អជាង?" ការពិតគឺថា វាពិតជាអាស្រ័យលើស្ថានភាពរបស់អ្នក បទពិសោធន៍បច្ចុប្បន្នជាដើម។ ខ្ញុំមិនស្ទាក់ស្ទើរក្នុងការផ្តល់យោបល់របស់ខ្ញុំទេ ព្រោះវាអាចជាការធ្វើឱ្យសាមញ្ញពេកក្នុងការណែនាំវេទិកាមួយសម្រាប់ករណីប្រើប្រាស់ទាំងអស់ និងដែនកំណត់ដែលអាចកើតមាន។ ខ្ញុំបានសរសេរអត្ថបទស៊េរីនេះដើម្បីឱ្យអ្នកអាចបង្កើតជាគំនិតរបស់អ្នកផ្ទាល់។

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

ខ្ញុំឃើញបច្ចេកវិទ្យាផ្សេងទៀតដែលខ្វះភាពជឿជាក់ និងធានានូវការបញ្ជាទិញនេះ បន្ទាប់មកខ្ញុំមើលទៅ RabbitMQ និង Kafka ហើយដឹងពីតម្លៃមិនគួរឱ្យជឿនៃប្រព័ន្ធទាំងពីរនេះ។

ប្រភព: www.habr.com

RabbitMQ ទល់នឹង Kafka: ការអត់ឱនកំហុសនិងភាពអាចរកបានខ្ពស់។