ការយល់ដឹងអំពីឈ្មួញកណ្តាលសារ។ រៀនមេកានិចនៃការផ្ញើសារជាមួយ ActiveMQ និង Kafka ។ ជំពូក 3. Kafka

ការបន្តការបកប្រែសៀវភៅតូចមួយ៖
ការយល់ដឹងអំពីឈ្មួញកណ្តាលសារ
អ្នកនិពន្ធ៖ Jakub Korab អ្នកបោះពុម្ពផ្សាយ៖ O'Reilly Media, Inc. កាលបរិច្ឆេទនៃការបោះពុម្ពផ្សាយ៖ ខែមិថុនា ឆ្នាំ ២០១៧ ISBN៖ 2017។

ផ្នែកដែលបានបកប្រែពីមុន៖ ការយល់ដឹងអំពីឈ្មួញកណ្តាលសារ។ រៀនមេកានិចនៃការផ្ញើសារជាមួយ ActiveMQ និង Kafka ។ ជំពូកទី 1 សេចក្តីផ្តើម

ជំពូកទី 3

កាកាកា។

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

ដោយសារគោលដៅចុងក្រោយនេះ តម្រូវការផ្សេងទៀតបានកើតឡើងដោយធម្មជាតិ។ Kafka គួរ៖

• ត្រូវលឿនបំផុត។
• ផ្តល់កម្រិតបញ្ជូនកាន់តែច្រើននៅពេលធ្វើការជាមួយសារ
• គាំទ្រ Publisher-Subscriber និងម៉ូដែល Point-to-Point
• កុំបន្ថយល្បឿនជាមួយនឹងការបន្ថែមអ្នកប្រើប្រាស់។ ជាឧទាហរណ៍ ដំណើរការទាំងជួរ និងប្រធានបទនៅក្នុង ActiveMQ ធ្លាក់ចុះ ដោយសារចំនួនអ្នកប្រើប្រាស់នៅលើគោលដៅកើនឡើង។
• ធ្វើមាត្រដ្ឋានផ្ដេក; ប្រសិនបើឈ្មួញកណ្តាលដែលបន្តសារអាចធ្វើដូច្នេះបានតែក្នុងល្បឿនឌីសអតិបរមា នោះវាសមហេតុផលក្នុងការទៅហួសពីឧទាហរណ៍ឈ្មួញកណ្តាលតែមួយដើម្បីបង្កើនប្រសិទ្ធភាព។
• កំណត់ការចូលប្រើក្នុងការរក្សាទុក និងទាញយកសារឡើងវិញ

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

គំរូទិសដៅបង្រួបបង្រួម

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

សម្រាប់ផ្នែកដែលនៅសល់នៃជំពូកនេះ លុះត្រាតែយើងបញ្ជាក់យ៉ាងច្បាស់លាស់ បើមិនដូច្នេះទេ ពាក្យ "ប្រធានបទ" នឹងសំដៅទៅលើប្រធានបទ Kafka ។

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

ពាក្យ "កំណត់ហេតុ" និង "ទ្រនិច" មិនបង្ហាញនៅក្នុងទេ។ ឯកសារ Kafka. ពាក្យ​ល្បី​ទាំង​នេះ​ត្រូវ​បាន​ប្រើ​នៅ​ទីនេះ​ដើម្បី​ជួយ​ដល់​ការ​យល់​ដឹង។

គំរូនេះគឺខុសគ្នាទាំងស្រុងពី ActiveMQ ដែលសារពីគ្រប់ជួរទាំងអស់ត្រូវបានរក្សាទុកក្នុងកំណត់ហេតុតែមួយ ហើយឈ្មួញកណ្តាលសម្គាល់សារថាបានលុបបន្ទាប់ពីពួកគេអានរួច។
ឥឡូវនេះ ចូរយើងជីកជ្រៅបន្តិច ហើយមើលកំណត់ហេតុប្រធានបទឱ្យកាន់តែលម្អិត។
កំណត់ហេតុ Kafka មានភាគថាសជាច្រើន (រូបភាព ១.៣-៤) Kafka ធានានូវការបញ្ជាទិញយ៉ាងតឹងរឹងនៅក្នុងភាគថាសនីមួយៗ។ នេះមានន័យថាសារដែលសរសេរទៅភាគថាសក្នុងលំដាប់ជាក់លាក់មួយនឹងត្រូវបានអានក្នុងលំដាប់ដូចគ្នា។ ភាគថាសនីមួយៗត្រូវបានអនុវត្តជាឯកសារកំណត់ហេតុវិលដែលមាន សំណុំរងមួយ។ (សំណុំរង) នៃសារទាំងអស់ដែលបានផ្ញើទៅកាន់ប្រធានបទដោយអ្នកផលិតរបស់វា។ តាមលំនាំដើម ប្រធានបទដែលបានបង្កើតមានភាគថាសមួយ។ គំនិតនៃភាគថាសគឺជាគំនិតកណ្តាលនៃ Kafka សម្រាប់ការធ្វើមាត្រដ្ឋានផ្ដេក។

រូបភាព 3-1 ។ ភាគថាស Kafka

នៅពេលអ្នកផលិតផ្ញើសារទៅកាន់ប្រធានបទ Kafka វាសម្រេចថាតើភាគថាសមួយណាត្រូវផ្ញើសារទៅ។ យើងនឹងពិនិត្យមើលរឿងនេះឱ្យកាន់តែលម្អិតនៅពេលក្រោយ។

ការអានសារ

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

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

បញ្ហានៃការអានអាចត្រូវបានតំណាងដូចខាងក្រោម:

• ប្រធានបទមានភាគថាសច្រើន។
• ក្រុមអ្នកប្រើប្រាស់ជាច្រើនអាចប្រើប្រធានបទមួយក្នុងពេលតែមួយ
• ក្រុមអ្នកប្រើប្រាស់អាចមានឧទាហរណ៍ដាច់ដោយឡែកជាច្រើន។

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

ក្រុមអ្នកប្រើប្រាស់ និងអ្នកប្រើប្រាស់

សូម​យក​ជា​ចំណុច​ចាប់​ផ្ដើម​ប្រធានបទ​មួយ​ដែល​មាន​ភាគ​ថាស​មួយ (រូបភាព ១.៣-៤).

រូបភាពទី 3-2 ។ អ្នកប្រើប្រាស់អានពីភាគថាស

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

នៅពេលដែលអ្នកប្រើប្រាស់តក្កវិជ្ជាទីពីរភ្ជាប់ដោយប្រើ group_id ផ្សេងគ្នា វាគ្រប់គ្រងទ្រនិចទីពីរដែលឯករាជ្យពីទីមួយ (រូបភាព ១.៣-៤) ដូច្នេះ ប្រធានបទ Kafka ដើរតួដូចជាជួរដែលមានអ្នកប្រើប្រាស់ម្នាក់ និងដូចជាប្រធានបទបោះពុម្ពផ្សាយធម្មតា (pub-sub) ដែលអ្នកប្រើប្រាស់ច្រើនជាវ ដោយមានអត្ថប្រយោជន៍បន្ថែមដែលសារទាំងអស់ត្រូវបានរក្សាទុក និងអាចដំណើរការបានច្រើនដង។

រូបភាពទី 3-3 ។ អ្នកប្រើប្រាស់ពីរនាក់នៅក្នុងក្រុមអ្នកប្រើប្រាស់ផ្សេងគ្នាអានពីភាគថាសដូចគ្នា។

អ្នកប្រើប្រាស់នៅក្នុងក្រុមអ្នកប្រើប្រាស់

នៅពេលដែលអតិថិជនប្រើប្រាស់មួយអានទិន្នន័យពីភាគថាស វាមានការគ្រប់គ្រងពេញលេញនៃទ្រនិច និងដំណើរការសារដូចដែលបានពិពណ៌នានៅក្នុងផ្នែកមុន។
ប្រសិនបើករណីជាច្រើននៃអ្នកប្រើប្រាស់ត្រូវបានភ្ជាប់ជាមួយ group_id ដូចគ្នាទៅនឹងប្រធានបទដែលមានភាគថាសមួយ នោះឧទាហរណ៍ដែលភ្ជាប់ចុងក្រោយនឹងត្រូវបានផ្តល់ការគ្រប់គ្រងលើទ្រនិច ហើយចាប់ពីពេលនោះមកវានឹងទទួលសារទាំងអស់ (រូបភាព ១.៣-៤).

រូបភាពទី 3-4 ។ អ្នកប្រើប្រាស់ពីរនាក់នៅក្នុងក្រុមអ្នកប្រើប្រាស់ដូចគ្នាអានពីភាគថាសដូចគ្នា។

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

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

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

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

មធ្យោបាយ Canonical ដើម្បីដោះស្រាយបញ្ហានេះនៅ Kafka គឺត្រូវប្រើ ខОភាគថាសច្រើនទៀត។

ការបែងចែក

ភាគថាសគឺជាយន្តការចម្បងសម្រាប់ការអានស្របគ្នា និងធ្វើមាត្រដ្ឋានប្រធានបទលើសពីកម្រិតបញ្ជូននៃឧទាហរណ៍ឈ្មួញកណ្តាលតែមួយ។ ដើម្បីយល់កាន់តែច្បាស់ សូមយើងពិចារណាអំពីស្ថានភាពដែលមានប្រធានបទដែលមានភាគពីរ ហើយអ្នកប្រើប្រាស់ម្នាក់បានជាវប្រធានបទនេះ (រូបភាព ១.៣-៤).

រូបភាពទី 3-5 ។ អ្នកប្រើប្រាស់ម្នាក់អានពីភាគច្រើន។

នៅក្នុងសេណារីយ៉ូនេះ អ្នកប្រើប្រាស់ត្រូវបានផ្តល់ការគ្រប់គ្រងលើទ្រនិចដែលត្រូវគ្នានឹង group_id របស់វានៅក្នុងភាគថាសទាំងពីរ ហើយចាប់ផ្តើមអានសារពីភាគទាំងពីរ។
នៅពេលដែលអ្នកប្រើប្រាស់បន្ថែមសម្រាប់ group_id ដូចគ្នាត្រូវបានបន្ថែមទៅប្រធានបទនេះ Kafka កំណត់ទីតាំងមួយនៃភាគថាសពីអ្នកប្រើប្រាស់ទីមួយទៅអ្នកប្រើប្រាស់ទីពីរ។ បន្ទាប់ពីនោះ ករណីនីមួយៗនៃអ្នកប្រើប្រាស់នឹងអានពីផ្នែកមួយនៃប្រធានបទ (រូបភាព ១.៣-៤).

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

រូបភាពទី 3-6 ។ អ្នកប្រើប្រាស់ពីរនាក់នៅក្នុងក្រុមអ្នកប្រើប្រាស់ដូចគ្នាអានពីភាគផ្សេងគ្នា

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

• អ្នកប្រើប្រាស់ណាដែលគួរទទួលបានសារបន្ទាប់ ដោយផ្អែកលើការបែងចែកជុំវិលជុំ សមត្ថភាពបច្ចុប្បន្ននៃការទាញយកសារទុកមុន ឬសារពីមុន (សម្រាប់ក្រុមសារ JMS)។
• សារណាដែលត្រូវផ្ញើទៅកាន់អ្នកប្រើប្រាស់ និងថាតើពួកគេគួរតែត្រូវបានបញ្ជូនឡើងវិញក្នុងករណីបរាជ័យ។

ឈ្មួញកណ្តាល Kafka ទាំងអស់ត្រូវធ្វើគឺបញ្ជូនសារតាមលំដាប់លំដោយទៅកាន់អ្នកប្រើប្រាស់នៅពេលដែលអ្នកស្នើសុំក្រោយគេ។

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

ការផ្ញើសារ

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

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

នៅក្នុងជំពូកទី 2 យើងបានពិភាក្សាអំពីសេណារីយ៉ូភ្នាល់អនឡាញ ដែលព្រឹត្តិការណ៍ដែលពាក់ព័ន្ធត្រូវដំណើរការតាមលំដាប់លំដោយដោយអ្នកប្រើប្រាស់តែមួយ៖

1. គណនីអ្នកប្រើប្រាស់ត្រូវបានកំណត់រចនាសម្ព័ន្ធ។
2. លុយត្រូវបានបញ្ចូលទៅក្នុងគណនី។
3. ការភ្នាល់ត្រូវបានធ្វើឡើងដែលដកប្រាក់ចេញពីគណនី។

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

ចំណុចប្រទាក់នេះមើលទៅដូចនេះ៖

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

សរសេរយុទ្ធសាស្ត្របំបែកខ្លួនឯង

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

Kafka រួមបញ្ចូលការឆែកឆេរដើម្បីរកមើលអំពើពុករលួយនៃសារនៅក្នុងហាង ហើយមានសំណុំពេញលេញនៃមុខងារសុវត្ថិភាព។ ទោះបីជាយ៉ាងនេះក៏ដោយ តម្រូវការជាក់លាក់នៃឧស្សាហកម្មដូចជា លក្ខខណ្ឌខាងលើ ជួនកាលលេចឡើង។

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

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

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

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

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

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

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

ឈ្មួញកណ្តាល JMS ក៏ត្រូវដោះស្រាយជាមួយនឹងតម្រូវការបែបនេះដែរ។ គួរឱ្យចាប់អារម្មណ៍ យន្តការសម្រាប់ការផ្ញើសារដែលពាក់ព័ន្ធទៅកាន់អ្នកប្រើប្រាស់ដូចគ្នា ដែលត្រូវបានអនុវត្តតាមរយៈ JMS Message Groups (បំរែបំរួលលើយុទ្ធសាស្ត្ររក្សាតុល្យភាពផ្ទុកស្អិត (SLB)) ក៏តម្រូវឱ្យអ្នកផ្ញើសម្គាល់សារថាពាក់ព័ន្ធផងដែរ។ ក្នុងករណី JMS ឈ្មួញកណ្តាលទទួលខុសត្រូវក្នុងការផ្ញើសារដែលពាក់ព័ន្ធនេះទៅកាន់អ្នកប្រើប្រាស់ម្នាក់ក្នុងចំណោមមនុស្សជាច្រើន ហើយផ្ទេរកម្មសិទ្ធិរបស់ក្រុមប្រសិនបើអ្នកប្រើប្រាស់ធ្លាក់។

កិច្ចព្រមព្រៀងអ្នកផលិត

ការបែងចែកមិនមែនជារឿងតែមួយគត់ដែលត្រូវពិចារណានៅពេលផ្ញើសារ។ តោះមើលវិធីសាស្រ្ត send() នៃថ្នាក់ផលិតនៅក្នុង Java API៖

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

បន្ថែមទៀតអំពីការអានសារ

ការអានសារមានភាពស្មុគស្មាញបន្ថែមដែលចាំបាច់ត្រូវប៉ាន់ស្មាន។ មិនដូច JMS API ដែលអាចដំណើរការកម្មវិធីស្តាប់សារក្នុងការឆ្លើយតបទៅនឹងសារ អ្នកប្រើប្រាស់ Kafka មានតែការបោះឆ្នោតប៉ុណ្ណោះ។ ចូរយើងពិនិត្យមើលឱ្យកាន់តែច្បាស់អំពីវិធីសាស្រ្ត ការស្ទង់មតិ()ប្រើសម្រាប់គោលបំណងនេះ៖

ConsumerRecords < K, V > poll(long timeout);

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

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

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

ត្រឡប់ទៅគំរូអានដែលបានពិភាក្សាពីមុន ដំណើរការសារមានបីដំណាក់កាល៖

1. ទាញយកសារសម្រាប់ការអាន។
2. ដំណើរការសារ។
3. បញ្ជាក់សារ។

អ្នកប្រើប្រាស់ Kafka ភ្ជាប់មកជាមួយជម្រើសកំណត់រចនាសម្ព័ន្ធ enable.auto.commit. នេះ​ជា​ការ​កំណត់​លំនាំដើម​ដែល​ត្រូវ​បាន​ប្រើ​ជា​ញឹក​ញាប់​ដូច​ជា​ការ​កំណត់​ដែល​មាន​ពាក្យ "ស្វ័យប្រវត្តិ"។

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

នៅក្នុង Kafka 0.10 លេខកូដអតិថិជនត្រូវបានផ្លាស់ប្តូរ ដូច្នេះការប្តេជ្ញាចិត្តត្រូវបានបង្កឡើងជាទៀងទាត់ដោយបណ្ណាល័យអតិថិជន ដូចដែលបានកំណត់រចនាសម្ព័ន្ធ auto.commit.interval.ms. ឥរិយាបថនេះគឺនៅកន្លែងណាមួយរវាងរបៀប JMS AUTO_ACKNOWLEDGE និង DUPS_OK_ACKNOWLEDGE ។ នៅពេលប្រើ autocommit សារអាចត្រូវបានប្តេជ្ញាដោយមិនគិតពីថាតើពួកគេត្រូវបានដំណើរការពិតប្រាកដ - វាអាចកើតឡើងក្នុងករណីអ្នកប្រើប្រាស់យឺត។ ប្រសិនបើអ្នកប្រើប្រាស់ត្រូវបានលុបចោល សារនឹងត្រូវបានទាញយកដោយអ្នកប្រើប្រាស់បន្ទាប់ ដោយចាប់ផ្តើមពីទីតាំងដែលបានប្តេជ្ញាចិត្ត ដែលអាចបណ្តាលឱ្យខកខានសារ។ ក្នុងករណីនេះ Kafka មិនបាត់បង់សារទេ លេខកូដអានគ្រាន់តែមិនដំណើរការពួកវា។

របៀបនេះមានការសន្យាដូចគ្នានឹងកំណែ 0.9 ដែរ៖ សារអាចត្រូវបានដំណើរការ ប៉ុន្តែប្រសិនបើវាបរាជ័យ អុហ្វសិតអាចនឹងមិនត្រូវបានប្តេជ្ញាចិត្ត ដែលអាចធ្វើឱ្យការដឹកជញ្ជូនកើនឡើងទ្វេដង។ សារកាន់តែច្រើនដែលអ្នកទទួលបាននៅពេលប្រតិបត្តិ ការស្ទង់មតិ()បញ្ហានេះកាន់តែច្រើន។

ដូចដែលបានពិភាក្សានៅក្នុង “ការអានសារពីជួរ” នៅទំព័រទី 21 វាមិនមានអ្វីដូចជាការបញ្ជូនសារមួយដងក្នុងប្រព័ន្ធផ្ញើសារទេ នៅពេលដែលរបៀបបរាជ័យត្រូវបានយកមកពិចារណា។

នៅក្នុង Kafka មានវិធីពីរយ៉ាងដើម្បី commit (commit) a offset (offset): ដោយស្វ័យប្រវត្តិ និងដោយដៃ។ ក្នុង​ករណី​ទាំងពីរ សារ​អាច​ត្រូវ​បាន​ដំណើរការ​ច្រើន​ដង ប្រសិនបើ​សារ​ត្រូវ​បាន​ដំណើរការ ប៉ុន្តែ​បាន​បរាជ័យ​មុន​ពេល​ដែល​បាន​ប្រព្រឹត្ត។ អ្នកក៏អាចជ្រើសរើសមិនដំណើរការសារទាល់តែសោះ ប្រសិនបើការប្តេជ្ញាចិត្តបានកើតឡើងនៅក្នុងផ្ទៃខាងក្រោយ ហើយលេខកូដរបស់អ្នកត្រូវបានបញ្ចប់ មុនពេលវាអាចត្រូវបានដំណើរការ (ប្រហែលជានៅក្នុង Kafka 0.9 និងមុននេះ)។

អ្នកអាចគ្រប់គ្រងដំណើរការប្រព្រឹត្តអុហ្វសិតដោយដៃនៅក្នុង Kafka consumer API ដោយកំណត់ប៉ារ៉ាម៉ែត្រ enable.auto.commit ដើម្បីមិនពិត និងហៅយ៉ាងច្បាស់លាស់នូវវិធីមួយក្នុងចំណោមវិធីខាងក្រោម៖

void commitSync();
void commitAsync();

ប្រសិនបើអ្នកចង់ដំណើរការសារ "យ៉ាងហោចណាស់ម្តង" អ្នកត្រូវតែធ្វើអុហ្វសិតដោយដៃ commitSync()ដោយប្រតិបត្តិពាក្យបញ្ជានេះភ្លាមៗបន្ទាប់ពីដំណើរការសារ។

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

• ត្រឡប់សារក្លែងក្លាយដោយស្វ័យប្រវត្តិ។ អ្នកប្រើប្រាស់ខ្លួនឯងត្រូវតែដោះស្រាយការលើកលែងដែលកើតឡើងពីបន្ទុកដែលមានបញ្ហា និងការដាច់ចរន្តអគ្គិសនី ដោយសារពួកគេមិនអាចពឹងផ្អែកលើឈ្មួញកណ្តាលដើម្បីបញ្ជូនសារឡើងវិញបានទេ។
• ផ្ញើសារទៅកាន់ប្រធានបទជាច្រើននៅក្នុងប្រតិបត្តិការអាតូមិកមួយ។ ដូចដែលយើងនឹងឃើញក្នុងពេលឆាប់ៗនេះ ការគ្រប់គ្រងលើប្រធានបទផ្សេងគ្នា និងភាគថាសអាចរស់នៅលើម៉ាស៊ីនផ្សេងគ្នានៅក្នុងចង្កោម Kafka ដែលមិនសម្របសម្រួលប្រតិបត្តិការនៅពេលផ្ញើ។ នៅពេលនៃការសរសេរនេះ ការងារមួយចំនួនត្រូវបានធ្វើដើម្បីធ្វើឱ្យវាអាចទៅរួចជាមួយ KIP-98 ។
• ភ្ជាប់ការអានសារមួយពីប្រធានបទមួយជាមួយនឹងការផ្ញើសារមួយផ្សេងទៀតទៅកាន់ប្រធានបទផ្សេងទៀត។ ជាថ្មីម្តងទៀត ស្ថាបត្យកម្មរបស់ Kafka ពឹងផ្អែកលើម៉ាស៊ីនឯករាជ្យជាច្រើនដែលដំណើរការជាឡានក្រុងតែមួយ ហើយគ្មានការប៉ុនប៉ងលាក់បាំងរឿងនេះទេ។ ឧទាហរណ៍ មិនមានសមាសធាតុ API ដែលនឹងអនុញ្ញាតឱ្យអ្នកភ្ជាប់ អ្នកប្រើប្រាស់ и អ្នកផលិត នៅក្នុងប្រតិបត្តិការមួយ។ នៅក្នុង JMS នេះត្រូវបានផ្តល់ដោយវត្ថុ សម័យប្រជុំពីដែលត្រូវបានបង្កើតឡើង អ្នកផលិតសារ и សារអ្នកប្រើប្រាស់.

ប្រសិនបើយើងមិនអាចពឹងផ្អែកលើប្រតិបត្តិការបានទេ តើយើងអាចផ្តល់អត្ថន័យឱ្យកាន់តែជិតទៅនឹងអ្វីដែលផ្តល់ដោយប្រព័ន្ធផ្ញើសារបែបប្រពៃណីដោយរបៀបណា?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

វិធីសាស្រ្ត ស្វែងរក() អាចត្រូវបានប្រើជាមួយវិធីសាស្រ្ត
offsetsForTimes(ផែនទី ត្រាពេលវេលាដើម្បីស្វែងរក) ដើម្បីត្រលប់ទៅរដ្ឋមួយនៅចំណុចជាក់លាក់ណាមួយកាលពីអតីតកាល។

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

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

ការសង្កេតផ្ទាល់ខ្លួនបង្ហាញថា នៅពេលដែលអាំងតង់ស៊ីតេនៃសារកើនឡើង តម្លៃនៃសារនីមួយៗមានការថយចុះ។ សារធំមានទំនោរមានតម្លៃនៅពេលមើលក្នុងទម្រង់រួម។

ភាពអាចរកបានខ្ពស់។

វិធីសាស្រ្តរបស់ Kafka ចំពោះភាពអាចរកបានខ្ពស់គឺខុសគ្នាខ្លាំងពីវិធីសាស្រ្តរបស់ ActiveMQ ។ Kafka ត្រូវ​បាន​រចនា​ជុំវិញ​ចង្កោម​ខ្នាត​ដែល​ករណី​ឈ្មួញកណ្តាល​ទាំងអស់​ទទួល និង​ចែកចាយ​សារ​ក្នុង​ពេល​តែមួយ។

ចង្កោម Kafka មានឧទាហរណ៍ឈ្មួញកណ្តាលជាច្រើនដែលកំពុងដំណើរការលើម៉ាស៊ីនមេផ្សេងៗគ្នា។ Kafka ត្រូវ​បាន​រចនា​ឡើង​ដើម្បី​ដំណើរ​ការ​លើ​ផ្នែក​រឹង​តែ​ឯង​ធម្មតា ដែល​ថ្នាំង​នីមួយៗ​មាន​កន្លែង​ផ្ទុក​ផ្ទាល់ខ្លួន។ ការប្រើប្រាស់ឧបករណ៍ផ្ទុកដែលបានភ្ជាប់បណ្តាញ (SAN) មិនត្រូវបានណែនាំទេ ពីព្រោះថ្នាំងកុំព្យូទ័រច្រើនអាចប្រកួតប្រជែងនឹងពេលវេលា។Ыe ចន្លោះពេលផ្ទុក និងបង្កើតការប៉ះទង្គិច។

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

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

ក្នុងករណីមូលដ្ឋាន ប្រធានបទមួយត្រូវបានបង្កើតនៅក្នុងចង្កោម Kafka ដែលមានលក្ខណៈសម្បត្តិដូចខាងក្រោមៈ

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

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

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

អ្នកដើរតាមដែលមានសារទាំងអស់ដែលកាន់ដោយអ្នកដឹកនាំត្រូវបានហៅ ការចម្លងដែលបានធ្វើសមកាលកម្ម (ចម្លង​ដែល​ស្ថិត​ក្នុង​ស្ថានភាព​សមកាលកម្ម, ចម្លង​ក្នុង​សមកាលកម្ម)។ ប្រសិនបើឈ្មួញកណ្តាលដែលដើរតួជាអ្នកដឹកនាំសម្រាប់ភាគថាសធ្លាក់ចុះ ឈ្មួញកណ្តាលណាមួយដែលទាន់សម័យ ឬធ្វើសមកាលកម្មសម្រាប់ភាគថាសនោះអាចកាន់កាប់តួនាទីជាអ្នកដឹកនាំបាន។ វាជាការរចនាប្រកបដោយនិរន្តរភាពមិនគួរឱ្យជឿ។

ផ្នែកនៃការកំណត់រចនាសម្ព័ន្ធអ្នកផលិតគឺជាប៉ារ៉ាម៉ែត្រ អេកដែលកំណត់ថាតើចំនួនអ្នកចម្លងត្រូវតែទទួលស្គាល់ (ទទួលស្គាល់) ការទទួលសារ មុនពេលដែលកម្មវិធីបន្តផ្ញើ៖ 0, 1 ឬទាំងអស់។ ប្រសិនបើកំណត់ទៅ ទាំងអស់បន្ទាប់មកនៅពេលដែលសារត្រូវបានទទួល អ្នកដឹកនាំនឹងផ្ញើការបញ្ជាក់ត្រឡប់ទៅអ្នកផលិតវិញភ្លាមៗនៅពេលដែលវាទទួលបានការបញ្ជាក់ (ការទទួលស្គាល់) នៃកំណត់ត្រាពីសញ្ញាជាច្រើន (រួមទាំងខ្លួនវា) ដែលកំណត់ដោយការកំណត់ប្រធានបទ។ min.insync.replicas (លំនាំដើម 1) ។ ប្រសិនបើសារមិនអាចចម្លងបានដោយជោគជ័យ នោះអ្នកផលិតនឹងបោះបង់កម្មវិធីលើកលែងមួយ (NotEnoughReplicas ឬ NotEnoughReplicasAfterAppend).

ការកំណត់រចនាសម្ព័ន្ធធម្មតាបង្កើតប្រធានបទមួយដែលមានកត្តាចម្លងនៃ 3 (អ្នកដឹកនាំ 1 នាក់ អ្នកតាម 2 នាក់ក្នុងមួយភាគ) និងប៉ារ៉ាម៉ែត្រ min.insync.replicas ត្រូវបានកំណត់ទៅ 2. ក្នុងករណីនេះ ចង្កោមនឹងអនុញ្ញាតឱ្យឈ្មួញកណ្តាលម្នាក់ដែលគ្រប់គ្រងភាគថាសប្រធានបទធ្លាក់ចុះដោយមិនប៉ះពាល់ដល់កម្មវិធីអតិថិជន។

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

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

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

ការអនុវត្តកាន់តែប្រសើរឡើងច្រើនគឺអាចធ្វើទៅបាននៅក្នុងចង្កោម Kafka ជាជាងជាមួយឈ្មួញកណ្តាល Kafka តែមួយ ពីព្រោះភាគថាសប្រធានបទអាចពង្រីកនៅលើម៉ាស៊ីនដាច់ដោយឡែកជាច្រើន។

លទ្ធផល

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

ផ្នែកដែលបានបកប្រែពីមុន៖ ការយល់ដឹងអំពីឈ្មួញកណ្តាលសារ។ រៀនមេកានិចនៃការផ្ញើសារជាមួយ ActiveMQ និង Kafka ។ ជំពូកទី 1

ការបកប្រែរួចរាល់៖ tele.gg/middle_java

នៅ​មាន​ជា​បន្ត​ទៀត…

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើ Kafka ត្រូវបានប្រើប្រាស់នៅក្នុងស្ថាប័នរបស់អ្នកទេ?

• ថា

• គ្មាន

• ពីមុនធ្លាប់ប្រើ ឥឡូវអត់ទេ។

• យើងមានគម្រោងប្រើប្រាស់

អ្នកប្រើប្រាស់ 38 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ ១៤ នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com