ការផ្ញើសារដែលអាចទុកចិត្តបាននៅក្នុងប្រព័ន្ធចែកចាយ

បញ្ហាសរសេរពីរដង ការកសាងប្រព័ន្ធចែកចាយដែលអាចទុកចិត្តបាន អាចប្រើបានខ្ពស់ ទាមទារការប្រកាន់ខ្ជាប់នូវបច្ចេកទេស គោលការណ៍ និងគំរូជាក់លាក់។ ការរចនានៃប្រព័ន្ធបែបនេះពាក់ព័ន្ធនឹងការដោះស្រាយបញ្ហាប្រឈមជាច្រើន។ ក្នុងចំណោមបញ្ហាទូទៅបំផុត និងជាមូលដ្ឋានគឺ ។ បញ្ហាសរសេរពីរដង គឺជាបញ្ហាប្រឈមដែលកើតឡើងនៅក្នុងប្រព័ន្ធចែកចាយ ជាចម្បងនៅពេលដោះស្រាយជាមួយប្រភពទិន្នន័យច្រើន ឬមូលដ្ឋានទិន្នន័យដែលត្រូវការរក្សាសមកាលកម្ម។ វាសំដៅទៅលើការលំបាកក្នុងការធានាថាការផ្លាស់ប្តូរទិន្នន័យត្រូវបានសរសេរជាប់លាប់ទៅកាន់កន្លែងផ្ទុកទិន្នន័យផ្សេងៗ ដូចជាមូលដ្ឋានទិន្នន័យ ឬឃ្លាំងសម្ងាត់ ដោយមិនបង្ហាញពីបញ្ហាដូចជា ភាពមិនស៊ីសង្វាក់គ្នានៃទិន្នន័យ ការប៉ះទង្គិច ឬបញ្ហាជាប់គាំងនៃដំណើរការ។ "បញ្ហាសរសេរពីរដង" ស្ថាបត្យកម្ម microservices និងមូលដ្ឋានទិន្នន័យលំនាំក្នុងមួយសេវាកម្មនាំមកជូនអ្នកនូវអត្ថប្រយោជន៍ជាច្រើនដូចជា ការដាក់ពង្រាយ និងការធ្វើមាត្រដ្ឋានឯករាជ្យ ការបរាជ័យដាច់ដោយឡែក និងការជំរុញសក្តានុពលនៃល្បឿននៃការអភិវឌ្ឍន៍។ ទោះជាយ៉ាងណាក៏ដោយ ប្រតិបត្តិការទាមទារការផ្លាស់ប្តូរក្នុងចំណោមសេវាមីក្រូជាច្រើន ដោយបង្ខំឱ្យអ្នកគិតអំពីដំណោះស្រាយដែលអាចទុកចិត្តបានដើម្បីដោះស្រាយបញ្ហានេះ។ ស្ទើរតែជាឧទាហរណ៍ជាក់ស្តែង ចូរយើងពិចារណាអំពីសេណារីយ៉ូដែលដែនរបស់យើងពាក់ព័ន្ធនឹងការទទួលយកពាក្យសុំកម្ចី វាយតម្លៃពួកវា ហើយបន្ទាប់មកផ្ញើការជូនដំណឹងជូនដំណឹងដល់អតិថិជន។ នៅក្នុងស្មារតីនៃគោលការណ៍ទំនួលខុសត្រូវតែមួយ ច្បាប់របស់ Conway និងវិធីសាស្រ្តរចនាដែលជំរុញដោយដែន បន្ទាប់ពីវគ្គនៃព្រឹត្តិការណ៍ជាច្រើន ដែនទាំងមូលត្រូវបានបំបែកទៅជាដែនរងចំនួនបីជាមួយនឹងបរិបទដែលបានកំណត់ដែលមានព្រំដែនច្បាស់លាស់ គំរូដែន និងភាសាដែលនៅគ្រប់ទីកន្លែង។ ត្រូវបានផ្តល់ភារកិច្ចក្នុងការបង្កើតឡើង និងចងក្រងពាក្យស្នើសុំកម្ចីថ្មី។ ប្រព័ន្ធ វាយតម្លៃកម្មវិធីទាំងនេះ និងធ្វើការសម្រេចចិត្តដោយផ្អែកលើទិន្នន័យដែលបានផ្តល់។ ដំណើរការវាយតម្លៃនេះ រាប់បញ្ចូលទាំង KYC/KYB ការប្រឆាំងការក្លែងបន្លំ និងការត្រួតពិនិត្យហានិភ័យឥណទាន អាចចំណាយពេលច្រើន ដែលត្រូវការសមត្ថភាពក្នុងការគ្រប់គ្រងកម្មវិធីរាប់ពាន់ក្នុងពេលដំណាលគ្នា។ អាស្រ័យហេតុនេះ មុខងារនេះត្រូវបានផ្ទេរទៅឱ្យសេវាមីក្រូពិសេសដែលមានមូលដ្ឋានទិន្នន័យផ្ទាល់ខ្លួន ដែលអនុញ្ញាតឱ្យធ្វើមាត្រដ្ឋានដោយឯករាជ្យ។ ទីមួយ ទីពីរ លើសពីនេះ ប្រព័ន្ធរងទាំងនេះត្រូវបានគ្រប់គ្រងដោយក្រុមពីរផ្សេងគ្នា ដែលនីមួយៗមានវដ្តនៃការចេញផ្សាយផ្ទាល់ខ្លួន កិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម (SLA) និងតម្រូវការធ្វើមាត្រដ្ឋាន។ សេវាកម្មជូនដំណឹងពិសេសគឺស្ថិតនៅក្នុងកន្លែងដើម្បីផ្ញើការជូនដំណឹងដល់អតិថិជន។ ជាចុងក្រោយ នេះជាការពិពណ៌នាលម្អិតនៃករណីប្រើប្រាស់ចម្បងរបស់ប្រព័ន្ធ៖ អតិថិជនដាក់ពាក្យស្នើសុំកម្ចី។ សេវាស្នើសុំប្រាក់កម្ចីកត់ត្រាកម្មវិធីថ្មីជាមួយនឹងស្ថានភាព "មិនទាន់សម្រេច" ហើយចាប់ផ្តើមដំណើរការវាយតម្លៃដោយបញ្ជូនបន្តកម្មវិធីទៅសេវាកម្មវាយតម្លៃ។ សេវាវាយតម្លៃវាយតម្លៃពាក្យស្នើសុំប្រាក់កម្ចីចូល ហើយជូនដំណឹងជាបន្តបន្ទាប់ទៅសេវាស្នើសុំប្រាក់កម្ចីអំពីការសម្រេចចិត្ត។ នៅពេលទទួលបានការសម្រេចចិត្ត សេវាកម្មស្នើសុំប្រាក់កម្ចីធ្វើបច្ចុប្បន្នភាពស្ថានភាពពាក្យសុំកម្ចីស្របតាម ហើយចាប់ផ្តើមសេវាកម្មជូនដំណឹងដើម្បីជូនដំណឹងដល់អតិថិជនអំពីលទ្ធផល។ សេវាកម្មជូនដំណឹងដំណើរការសំណើនេះ ហើយបញ្ជូនការជូនដំណឹងទៅអតិថិជនតាមរយៈអ៊ីមែល សារ SMS ឬវិធីទំនាក់ទំនងដែលពេញចិត្តផ្សេងទៀត យោងទៅតាមការកំណត់របស់អតិថិជន។ វាគឺជាប្រព័ន្ធដ៏សាមញ្ញ និងដំបូងបំផុតនៅ glance ដំបូង ប៉ុន្តែសូមពិនិត្យមើលពីរបៀបដែលសេវាកម្មវិធីប្រាក់កម្ចីដំណើរការពាក្យបញ្ជាដាក់ស្នើកម្មវិធីប្រាក់កម្ចី។ យើងអាចពិចារណាវិធីសាស្រ្តពីរសម្រាប់អន្តរកម្មសេវាកម្ម៖ នៅក្នុងវិធីសាស្រ្តនេះ សេវាកម្មធ្វើបច្ចុប្បន្នភាពមូលដ្ឋានទិន្នន័យរបស់ខ្លួន (ប្តេជ្ញា) ហើយបន្ទាប់មកបោះផ្សាយព្រឹត្តិការណ៍ ឬសារទៅកាន់សេវាកម្មផ្សេងទៀត។ First-Local-Commit-Then-Publish: ផ្ទុយទៅវិញ វិធីសាស្រ្តនេះពាក់ព័ន្ធនឹងការបោះផ្សាយព្រឹត្តិការណ៍ ឬសារ មុនពេលធ្វើការផ្លាស់ប្តូរទៅកាន់មូលដ្ឋានទិន្នន័យ។ First-Publish-Then-Local-Commit: វិធីសាស្រ្តទាំងពីរមានគុណវិបត្តិរបស់ពួកគេ ហើយមានតែផ្នែកខ្លះដែលបរាជ័យ-សុវត្ថិភាពសម្រាប់ការទំនាក់ទំនងនៅក្នុងប្រព័ន្ធចែកចាយ។ នេះគឺជាដ្យាក្រាមលំដាប់នៃការអនុវត្តវិធីសាស្រ្តដំបូង។ នៅក្នុងសេណារីយ៉ូនេះ សេវាស្នើសុំប្រាក់កម្ចីប្រើវិធីសាស្រ្ត ដែលជាកន្លែងដែលវាធ្វើប្រតិបត្តិការដំបូងហើយបន្ទាប់មកព្យាយាមផ្ញើការជូនដំណឹងទៅប្រព័ន្ធផ្សេងទៀត។ ទោះជាយ៉ាងណាក៏ដោយ ដំណើរការនេះងាយនឹងបរាជ័យ ប្រសិនបើឧទាហរណ៍ មានបញ្ហាបណ្តាញ សេវាវាយតម្លៃមិនអាចប្រើបាន ឬសេវាស្នើសុំប្រាក់កម្ចីជួបប្រទះបញ្ហា Out of Memory (OOM) និងគាំង។ ក្នុងករណីបែបនេះ សារនឹងត្រូវបាត់បង់ ដោយទុកឱ្យការវាយតម្លៃដោយគ្មានការជូនដំណឹងអំពីពាក្យសុំកម្ចីថ្មី លុះត្រាតែមានវិធានការបន្ថែម។ First-Local-Commit-Thin-Publish និងទីពីរ។ នៅក្នុងសេណារីយ៉ូ , សេវាស្នើសុំប្រាក់កម្ចីប្រឈមមុខនឹងហានិភ័យកាន់តែច្រើន។ វាអាចជូនដំណឹងដល់សេវាកម្មវាយតម្លៃអំពីកម្មវិធីថ្មី ប៉ុន្តែបរាជ័យក្នុងការរក្សាទុកការធ្វើបច្ចុប្បន្នភាពនេះក្នុងមូលដ្ឋាន ដោយសារបញ្ហាដូចជាបញ្ហាមូលដ្ឋានទិន្នន័យ កំហុសអង្គចងចាំ ឬកំហុសកូដ។ វិធីសាស្រ្តនេះអាចនាំឱ្យមានភាពមិនស៊ីសង្វាក់គ្នាយ៉ាងខ្លាំងនៅក្នុងទិន្នន័យ ដែលអាចបណ្តាលឱ្យមានបញ្ហាធ្ងន់ធ្ងរ អាស្រ័យលើរបៀបដែលសេវាពិនិត្យប្រាក់កម្ចីដោះស្រាយកម្មវិធីដែលចូលមក។ First-Publish-Then-Local-Commit ដូច្នេះហើយ យើងត្រូវតែកំណត់អត្តសញ្ញាណដំណោះស្រាយដែលផ្តល់នូវយន្តការដ៏រឹងមាំសម្រាប់ការបោះពុម្ពផ្សាយព្រឹត្តិការណ៍ដល់អ្នកប្រើប្រាស់ខាងក្រៅ។ ប៉ុន្តែមុននឹងស្វែងយល់អំពីដំណោះស្រាយដែលមានសក្តានុពល យើងគួរតែបញ្ជាក់ជាមុនអំពីប្រភេទនៃការធានាការបញ្ជូនសារដែលអាចសម្រេចបាននៅក្នុងប្រព័ន្ធចែកចាយ។ ការធានាការបញ្ជូនសារ មានការធានាបួនប្រភេទដែលយើងអាចសម្រេចបាន។ គ្មានការធានាទេ។ មិនមានការធានាថាសារនឹងត្រូវបានបញ្ជូនទៅកាន់គោលដៅនោះទេ។ វិធីសាស្រ្ត គឺច្បាស់ណាស់អំពីរឿងនេះ។ អ្នកប្រើប្រាស់អាចទទួលបានសារម្តង ច្រើនដង ឬមិនដែលទាល់តែសោះ។ First-Local-Commit-Then-Publish ការដឹកជញ្ជូនច្រើនដង ភាគច្រើននៅពេលដែលការដឹកជញ្ជូនមានន័យថាសារនឹងត្រូវបានបញ្ជូនទៅកាន់គោលដៅយ៉ាងហោចណាស់ 1 ដង។ វិធីសាស្រ្ត អាចត្រូវបានអនុវត្តតាមវិធីនេះផងដែរ ជាមួយនឹងគោលការណ៍ព្យាយាមម្តងទៀតនៃការប៉ុនប៉ងជាមួយនឹងតម្លៃមួយ។ First-Local-Commit-Then-Publish យ៉ាងហោចណាស់ការចែកចាយម្តង\អ្នកប្រើប្រាស់នឹងទទួលបាន និងដំណើរការរាល់សារ ប៉ុន្តែអាចទទួលបានសារដូចគ្នាច្រើនជាងម្តង។ Exactly once delivery\Exactly once delivery មានន័យថាអ្នកប្រើប្រាស់នឹងទទួលបានសារយ៉ាងមានប្រសិទ្ធភាពតែម្តង។ តាមបច្ចេកទេស វាអាចសម្រេចបានជាមួយនឹងប្រតិបត្តិការ Kafka និងការអនុវត្តជាក់ស្តែងជាក់លាក់របស់អ្នកផលិត និងអ្នកប្រើប្រាស់។ ក្នុងករណីភាគច្រើន ការផ្តល់ ធានាដោះស្រាយបញ្ហាជាច្រើនដោយធានាថា សារត្រូវបានបញ្ជូនយ៉ាងហោចណាស់ម្តង ប៉ុន្តែអ្នកប្រើប្រាស់ត្រូវតែគ្មានកម្លាំង។ ទោះជាយ៉ាងណាក៏ដោយ ដោយសារការបរាជ័យបណ្តាញដែលមិនអាចជៀសបាន តក្កវិជ្ជាអ្នកប្រើប្រាស់ទាំងអស់ត្រូវតែមានកម្លាំងដើម្បីជៀសវាងការដំណើរការសារស្ទួន ដោយមិនគិតពីការធានារបស់អ្នកផលិតឡើយ។ ដូច្នេះហើយ តម្រូវការនេះមិនមែនជាគុណវិបត្តិច្រើននោះទេ ព្រោះវាឆ្លុះបញ្ចាំងពីការពិត។ 'យ៉ាងហោចណាស់ម្តង' ដំណោះស្រាយ មានដំណោះស្រាយជាច្រើនចំពោះបញ្ហានេះ ដែលមានគុណសម្បត្តិ និងគុណវិបត្តិរបស់វា។ ការប្តេជ្ញាចិត្តពីរដំណាក់កាល យោងតាមវិគីភីឌា ការប្តេជ្ញាចិត្តពីរដំណាក់កាល (2PC) គឺជាពិធីការប្រតិបត្តិការចែកចាយដែលប្រើក្នុងវិទ្យាសាស្ត្រកុំព្យូទ័រ និងប្រព័ន្ធគ្រប់គ្រងមូលដ្ឋានទិន្នន័យ ដើម្បីធានាបាននូវភាពស៊ីសង្វាក់គ្នា និងភាពជឿជាក់នៃប្រតិបត្តិការចែកចាយ។ វាត្រូវបានរចនាឡើងសម្រាប់ស្ថានភាពដែលធនធានច្រើន (ឧ. មូលដ្ឋានទិន្នន័យ) ត្រូវការចូលរួមក្នុងប្រតិបត្តិការតែមួយ ហើយវាធានាថាពួកគេទាំងអស់ប្រព្រឹត្តប្រតិបត្តិការ ឬពួកគេទាំងអស់បោះបង់វា ដោយហេតុនេះរក្សាបាននូវស្ថិរភាពទិន្នន័យ។ វាស្តាប់ទៅពិតជាអ្វីដែលយើងត្រូវការ ប៉ុន្តែការប្តេជ្ញាចិត្តពីរដំណាក់កាលមានគុណវិបត្តិជាច្រើន៖ ប្រសិនបើធនធានដែលចូលរួមមិនឆ្លើយតប ឬជួបប្រទះនឹងបរាជ័យ ដំណើរការទាំងមូលអាចត្រូវបានរារាំងរហូតដល់បញ្ហាត្រូវបានដោះស្រាយ។ នេះអាចនាំឱ្យមានបញ្ហានៃការអនុវត្ត និងលទ្ធភាពដែលអាចរកបាន។ Two-Phase Commit មិនផ្តល់យន្តការអត់ឱនកំហុសដែលភ្ជាប់មកជាមួយទេ។ វាពឹងផ្អែកលើយន្តការខាងក្រៅ ឬការអន្តរាគមន៍ដោយដៃ ដើម្បីដោះស្រាយការបរាជ័យ។ មិនមែនមូលដ្ឋានទិន្នន័យទំនើបទាំងអស់គាំទ្រ Two-Phase Commit ទេ។ មូលដ្ឋានទិន្នន័យដែលបានចែករំលែក ដំណោះស្រាយជាក់ស្តែងបំផុតសម្រាប់ស្ថាបត្យកម្ម microservices គឺត្រូវអនុវត្តលំនាំ (ឬសូម្បីតែពេលខ្លះប្រឆាំងនឹងលំនាំ) — មូលដ្ឋានទិន្នន័យដែលបានចែករំលែក។ វិធីសាស្រ្តនេះគឺវិចារណញាណណាស់ ប្រសិនបើអ្នកត្រូវការភាពស៊ីសង្វាក់គ្នានៃប្រតិបត្តិការនៅទូទាំងតារាងជាច្រើននៅក្នុងមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នា គ្រាន់តែប្រើមូលដ្ឋានទិន្នន័យដែលបានចែករំលែកមួយសម្រាប់សេវាមីក្រូទាំងនេះ។ គុណវិបត្តិនៃវិធីសាស្រ្តនេះរួមមាន ការណែនាំចំណុចតែមួយនៃការបរាជ័យ ការរារាំងការធ្វើមាត្រដ្ឋានមូលដ្ឋានទិន្នន័យឯករាជ្យ និងការកំណត់លទ្ធភាពប្រើប្រាស់ដំណោះស្រាយមូលដ្ឋានទិន្នន័យផ្សេងៗគ្នា ដែលសមស្របបំផុតសម្រាប់តម្រូវការជាក់លាក់ និងករណីប្រើប្រាស់។ បន្ថែមពីលើនេះ ការកែប្រែមូលដ្ឋានកូដមីក្រូសេវានឹងចាំបាច់ ដើម្បីគាំទ្រទម្រង់នៃប្រតិបត្តិការចែកចាយបែបនេះ។ ប្រអប់ចេញប្រតិបត្តិការ ' ' គឺជាគំរូរចនាដែលប្រើក្នុងប្រព័ន្ធចែកចាយ ដើម្បីធានាការផ្សព្វផ្សាយសារដែលអាចទុកចិត្តបាន សូម្បីតែនៅចំពោះមុខប្រព័ន្ធផ្ញើសារដែលមិនគួរឱ្យទុកចិត្តក៏ដោយ។ វាពាក់ព័ន្ធនឹងការរក្សាទុកព្រឹត្តិការណ៍នៅក្នុងតារាង 'OutboxEvents' ដែលបានកំណត់នៅក្នុងប្រតិបត្តិការដូចគ្នានឹងប្រតិបត្តិការខ្លួនឯង។ វិធីសាស្រ្តនេះតម្រឹមយ៉ាងល្អជាមួយនឹងលក្ខណៈសម្បត្តិ ACID នៃមូលដ្ឋានទិន្នន័យទំនាក់ទំនង។ ផ្ទុយទៅវិញ មូលដ្ឋានទិន្នន័យ No-SQL ជាច្រើនមិនគាំទ្រយ៉ាងពេញលេញនូវលក្ខណៈសម្បត្តិ ACID ដោយជ្រើសរើសជំនួសវិញនូវគោលការណ៍នៃទ្រឹស្តីបទ CAP និងទស្សនវិជ្ជា BASE ដែលផ្តល់អាទិភាពដល់ភាពអាចរកបាន និងភាពស៊ីសង្វាក់គ្នាជាយថាហេតុលើភាពស៊ីសង្វាក់គ្នាយ៉ាងតឹងរឹង។ ប្រអប់ចេញប្រតិបត្តិការ ប្រអប់ចេញប្រតិបត្តិការផ្តល់ ហើយអាចត្រូវបានអនុវត្តជាមួយនឹងវិធីសាស្រ្តជាច្រើន៖ ការធានាយ៉ាងហោចណាស់ម្តង ការកាត់កំណត់ហេតុប្រតិបត្តិការ អ្នកបោះពុម្ពផ្សាយការបោះឆ្នោត វិធីសាស្រ្ត បង្កប់ន័យដោយប្រើដំណោះស្រាយជាក់លាក់នៃមូលដ្ឋានទិន្នន័យដូចជា CDC (ផ្លាស់ប្តូរការចាប់យកទិន្នន័យ)។ គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តនេះគឺ: កំណត់កំណត់ហេតុប្រតិបត្តិការ ដំណោះស្រាយជាក់លាក់នៃមូលដ្ឋានទិន្នន័យ ភាពយឺតយ៉ាវកើនឡើងដោយសារតែជាក់លាក់នៃការអនុវត្ត CDC វិធីសាស្រ្តមួយទៀតគឺ ដែលជួយសម្រួលដល់ការបញ្ចោញប្រអប់ចេញដោយការស្ទង់មតិលើតារាងប្រអប់ចេញ។ គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តនេះគឺសក្ដានុពលសម្រាប់ការបង្កើនការផ្ទុកមូលដ្ឋានទិន្នន័យដែលអាចនាំឱ្យមានការចំណាយខ្ពស់។ លើសពីនេះ មិនមែនមូលដ្ឋានទិន្នន័យ No-SQL ទាំងអស់គាំទ្រការសាកសួរប្រកបដោយប្រសិទ្ធភាពសម្រាប់ផ្នែកឯកសារជាក់លាក់នោះទេ។ ដូច្នេះ ការទាញយកឯកសារទាំងមូលអាចនាំឱ្យខូចមុខងារ។ កម្មវិធីបោះពុម្ភបោះឆ្នោត នេះគឺជាដ្យាក្រាមលំដាប់តូចមួយដែលពន្យល់ពីរបៀបដែលវាដំណើរការ។ ស្តាប់ខ្លួនឯង បញ្ហាប្រឈមចម្បងជាមួយគំរូប្រអប់ចេញប្រតិបត្តិការគឺស្ថិតនៅក្នុងភាពអាស្រ័យរបស់វាលើលក្ខណៈសម្បត្តិ ACID មូលដ្ឋានទិន្នន័យ។ វាអាចមានភាពត្រង់នៅក្នុងមូលដ្ឋានទិន្នន័យ OLTP ធម្មតា ប៉ុន្តែបង្កបញ្ហានៅក្នុងអាណាចក្រ NoSQL ។ ដើម្បីដោះស្រាយបញ្ហានេះ ដំណោះស្រាយដ៏មានសក្តានុពលមួយគឺត្រូវប្រើកំណត់ហេតុបន្ថែម (ឧទាហរណ៍ Kafka) ពីការចាប់ផ្តើមដំណើរការសំណើ។ ជំនួសឱ្យការដំណើរការដោយផ្ទាល់នូវពាក្យបញ្ជា 'ដាក់ស្នើកម្មវិធីប្រាក់កម្ចី' យើងផ្ញើវាភ្លាមៗទៅកាន់ប្រធានបទ Kafka ខាងក្នុង ហើយបន្ទាប់មកបញ្ជូនលទ្ធផល 'បានទទួលយក' ទៅអតិថិជន។ ទោះយ៉ាងណាក៏ដោយ ដោយសារវាទំនងជាថាពាក្យបញ្ជានៅតែត្រូវដំណើរការ យើងមិនអាចជូនដំណឹងដល់អតិថិជនភ្លាមៗអំពីលទ្ធផលនោះទេ។ ដើម្បីគ្រប់គ្រងភាពស៊ីសង្វាក់គ្នាជាយថាហេតុនេះ យើងអាចប្រើប្រាស់បច្ចេកទេសដូចជាការស្ទង់មតិរយៈពេលយូរ ការស្ទង់មតិដែលចាប់ផ្តើមដោយអតិថិជន ការអាប់ដេត UI ប្រកបដោយសុទិដ្ឋិនិយម ឬការប្រើប្រាស់ WebSockets ឬព្រឹត្តិការណ៍ដែលបានផ្ញើដោយម៉ាស៊ីនមេសម្រាប់ការជូនដំណឹង។ ទោះជាយ៉ាងណាក៏ដោយ នេះគឺជាប្រធានបទដាច់ដោយឡែកទាំងស្រុង ដូច្នេះយើងត្រឡប់ទៅប្រធានបទដំបូងរបស់យើង។ យើងបានផ្ញើសារលើប្រធានបទ Kafka ផ្ទៃក្នុង។ បន្ទាប់មក សេវាស្នើសុំប្រាក់កម្ចីប្រើប្រាស់សារនេះ — ពាក្យបញ្ជាដូចគ្នាដែលវាបានទទួលពីអតិថិជន — ហើយចាប់ផ្តើមដំណើរការ។ ទីមួយ វាប្រតិបត្តិតក្កវិជ្ជាអាជីវកម្មមួយចំនួន។ លុះត្រាតែតក្កវិជ្ជានេះត្រូវបានប្រតិបត្តិដោយជោគជ័យ ហើយលទ្ធផលត្រូវបានបន្ត វាផ្សាយសារថ្មីលើប្រធានបទ Kafka ជាសាធារណៈ។ ចូរយើងពិនិត្យមើលបន្តិចនៃ pseudo-code ។ public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } មិនបាច់បារម្ភទេ ដោយសារការប៉ះប៉ូវមិនទាន់បានប្តេជ្ញាចិត្ត សារនឹងត្រូវបានព្យាយាមម្តងទៀត។ ចុះបើដំណើរការនៃតក្កវិជ្ជាអាជីវកម្មបរាជ័យ? គ្មានការព្រួយបារម្ភទេ ដោយសារតក្កវិជ្ជាអាជីវកម្មមិនសូវមានប្រសិទ្ធភាព វានឹងមិនបង្កើតកម្មវិធីកម្ចីស្ទួនទេ។ ផ្ទុយទៅវិញ វានឹងព្យាយាមផ្ញើសារឡើងវិញទៅកាន់ប្រធានបទ Kafka ជាសាធារណៈ។ ចុះប្រសិនបើការផ្ញើព្រឹត្តិការណ៍ថ្មីទៅ Kafka បរាជ័យ? គ្មានការបារម្ភទេ ដោយសារតក្កវិជ្ជាអាជីវកម្មមានភាពរឹងមាំ វានឹងមិនបង្កើតកម្មវិធីកម្ចីស្ទួននោះទេ។ ជំនួសមកវិញ វានឹងផ្ញើសារឡើងវិញទៅកាន់ប្រធានបទ Kafka ជាសាធារណៈ ហើយសង្ឃឹមថាការប្តេជ្ញាចិត្តអុហ្វសិតនឹងទទួលបានជោគជ័យនៅពេលនេះ។ ចុះប្រសិនបើសារត្រូវបានផ្ញើទៅ Kafka ប៉ុន្តែការប្រព្រឹត្តអុហ្វសិតបរាជ័យ? គុណវិបត្តិចម្បងនៃវិធីសាស្រ្តនេះរួមមានភាពស្មុគស្មាញបន្ថែមដែលត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងរចនាប័ទ្មកម្មវិធីថ្មី ភាពជាប់លាប់ជាយថាហេតុ (ចាប់តាំងពីអតិថិជននឹងមិនដឹងលទ្ធផលភ្លាមៗ) និងតម្រូវការសម្រាប់តក្កវិជ្ជាអាជីវកម្មទាំងអស់ដើម្បីឱ្យមានភាពរឹងមាំ។ ប្រភពព្រឹត្តិការណ៍ តើអ្វីទៅជាប្រភពព្រឹត្តិការណ៍ ហើយតើវាត្រូវបានគេអនុវត្តនៅទីនេះដោយរបៀបណា? ប្រភពព្រឹត្តិការណ៍គឺជាគំរូស្ថាបត្យកម្មកម្មវិធីដែលប្រើដើម្បីយកគំរូតាមស្ថានភាពនៃប្រព័ន្ធដោយចាប់យកការផ្លាស់ប្តូរទាំងអស់ចំពោះទិន្នន័យរបស់វាជាស៊េរីនៃព្រឹត្តិការណ៍ដែលមិនអាចកែប្រែបាន។ ព្រឹត្តិការណ៍ទាំងនេះតំណាងឱ្យការពិត ឬការផ្លាស់ប្តូររដ្ឋ ហើយបម្រើជាប្រភពនៃការពិតតែមួយសម្រាប់ស្ថានភាពបច្ចុប្បន្នរបស់ប្រព័ន្ធ។ ដូច្នេះ តាមបច្ចេកទេស តាមរយៈការអនុវត្តប្រព័ន្ធប្រភពព្រឹត្តិការណ៍ យើងមានព្រឹត្តិការណ៍ទាំងអស់នៅក្នុង EventStore រួចហើយ ហើយ EventStore នេះអាចត្រូវបានប្រើប្រាស់ដោយអ្នកប្រើប្រាស់ជាប្រភពតែមួយនៃការពិតអំពីអ្វីដែលបានកើតឡើង។ មិនចាំបាច់មានដំណោះស្រាយមូលដ្ឋានទិន្នន័យជាក់លាក់សម្រាប់ការតាមដានរាល់ការផ្លាស់ប្តូរ ឬកង្វល់អំពីការបញ្ជាទិញនោះទេ បញ្ហាតែមួយគត់គឺអង្គុយលើផ្នែកអាន ព្រោះដើម្បីអាចទទួលបានស្ថានភាពជាក់ស្តែងគឺតម្រូវឱ្យចាក់ព្រឹត្តិការណ៍ទាំងអស់ឡើងវិញ។ សេចក្តីសន្និដ្ឋាន នៅក្នុងអត្ថបទនេះ យើងបានពិនិត្យឡើងវិញនូវវិធីសាស្រ្តជាច្រើនសម្រាប់ការកសាងសារដែលអាចទុកចិត្តបាននៅក្នុងប្រព័ន្ធចែកចាយ។ មានអនុសាសន៍មួយចំនួនដែលយើងអាចពិចារណាខណៈពេលដែលប្រព័ន្ធសាងសង់ដែលមានលក្ខណៈទាំងនេះ អភិវឌ្ឍអ្នកប្រើប្រាស់ដែលមិនមានអំណាចជានិច្ច ចាប់តាំងពីការបរាជ័យបណ្តាញគឺមិនអាចជៀសវាងបាន។ ប្រើប្រាស់ ដោយប្រុងប្រយ័ត្ន ជាមួយនឹងការយល់ដឹងច្បាស់លាស់អំពីតម្រូវការធានា។ First-Local-Commit-Then-Publish កុំប្រើវិធីសាស្រ្ត ព្រោះវាអាចនាំឱ្យមានភាពមិនស៊ីសង្វាក់គ្នានៃទិន្នន័យធ្ងន់ធ្ងរនៅក្នុងប្រព័ន្ធរបស់អ្នក។ First-Publish-Then-Local-Commit ប្រសិនបើការសម្រេចចិត្តជ្រើសរើសមូលដ្ឋានទិន្នន័យដែលមានស្រាប់ទំនងជាអាចផ្លាស់ប្តូរ ឬយុទ្ធសាស្ត្របច្ចេកទេសបង្កប់ន័យដើម្បីជ្រើសរើសដំណោះស្រាយការផ្ទុកល្អបំផុតសម្រាប់បញ្ហា — កុំបង្កើតបណ្ណាល័យចែករំលែកដោយចងភ្ជាប់ទៅនឹងដំណោះស្រាយមូលដ្ឋានទិន្នន័យដូចជា ជាដើម។ CDC ប្រើវិធីសាស្រ្ត ជាដំណោះស្រាយស្តង់ដារសម្រាប់ការសម្រេចបាននូវការធានាយ៉ាងហោចណាស់ម្តង។ Transactional Outbox ពិចារណាប្រើវិធីសាស្រ្ត នៅពេលដែលមូលដ្ឋានទិន្នន័យ No-SQL ត្រូវបានប្រើប្រាស់។ ស្តាប់ខ្លួនឯង លើកក្រោយ យើងនឹងពិនិត្យមើលឧទាហរណ៍ជាក់ស្តែងបន្ថែមទៀតនៃការអនុវត្ត Transactional Outbox។ សូមមើល អ្នក!