ການສົ່ງຂໍ້ຄວາມທີ່ເຊື່ອຖືໄດ້ໃນລະບົບການແຈກຢາຍ

ບັນຫາການຂຽນຄູ່

ການສ້າງລະບົບການແຈກຢາຍທີ່ເຊື່ອຖືໄດ້, ສາມາດໃຊ້ໄດ້ສູງ, ສາມາດຂະຫຍາຍໄດ້ຮຽກຮ້ອງໃຫ້ມີການຍຶດຫມັ້ນກັບເຕັກນິກ, ຫຼັກການ, ແລະຮູບແບບສະເພາະ. ການ​ອອກ​ແບບ​ຂອງ​ລະ​ບົບ​ດັ່ງ​ກ່າວ​ກ່ຽວ​ຂ້ອງ​ກັບ​ການ​ແກ້​ໄຂ​ຄວາມ​ທ້າ​ທາຍ​ຫຼາຍ​ຢ່າງ. ໃນບັນດາບັນຫາທີ່ແຜ່ຫຼາຍແລະພື້ນຖານທີ່ສຸດແມ່ນ ບັນຫາການຂຽນຄູ່ .

"ບັນຫາການຂຽນຄູ່" ແມ່ນສິ່ງທ້າທາຍທີ່ເກີດຂື້ນໃນລະບົບການແຈກຢາຍ, ສ່ວນໃຫຍ່ແມ່ນໃນເວລາທີ່ຈັດການກັບແຫຼ່ງຂໍ້ມູນຫຼາຍຫຼືຖານຂໍ້ມູນທີ່ຕ້ອງໄດ້ຮັບການເກັບຮັກສາໄວ້ໃນ sync. ມັນຫມາຍເຖິງຄວາມຫຍຸ້ງຍາກໃນການຮັບປະກັນວ່າການປ່ຽນແປງຂໍ້ມູນຖືກຂຽນຢ່າງຕໍ່ເນື່ອງກັບບ່ອນເກັບຂໍ້ມູນຕ່າງໆ, ເຊັ່ນ: ຖານຂໍ້ມູນຫຼືຖານຄວາມຈໍາ, ໂດຍບໍ່ມີການແນະນໍາບັນຫາຕ່າງໆເຊັ່ນຄວາມບໍ່ສອດຄ່ອງຂອງຂໍ້ມູນ, ຄວາມຂັດແຍ້ງ, ຫຼືຂໍ້ບົກຜ່ອງດ້ານການປະຕິບັດ.

ສະຖາປັດຕະຍະກໍາ microservices ແລະຖານຂໍ້ມູນຮູບແບບຕໍ່ການບໍລິການນໍາມາໃຫ້ທ່ານຜົນປະໂຫຍດຈໍານວນຫຼາຍ, ເຊັ່ນ: ການຈັດວາງເອກະລາດແລະຂະຫນາດ, ຄວາມລົ້ມເຫຼວທີ່ໂດດດ່ຽວ, ແລະການເພີ່ມຄວາມໄວຂອງການພັດທະນາ. ຢ່າງໃດກໍຕາມ, ການດໍາເນີນງານຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງລະຫວ່າງ microservices ຫຼາຍ, ບັງຄັບໃຫ້ທ່ານຄິດກ່ຽວກັບການແກ້ໄຂທີ່ເຊື່ອຖືໄດ້ເພື່ອແກ້ໄຂບັນຫານີ້.

ເກືອບເປັນຕົວຢ່າງທີ່ແທ້ຈິງ

ຂໍໃຫ້ພິຈາລະນາສະຖານະການທີ່ໂດເມນຂອງພວກເຮົາກ່ຽວຂ້ອງກັບການຮັບເອົາຄໍາຮ້ອງຂໍເງິນກູ້, ການປະເມີນພວກມັນ, ແລະຫຼັງຈາກນັ້ນສົ່ງການແຈ້ງເຕືອນໃຫ້ລູກຄ້າ.

ໃນຈິດໃຈຂອງຫຼັກການຄວາມຮັບຜິດຊອບດຽວ, ກົດຫມາຍຂອງ Conway, ແລະວິທີການອອກແບບໂດເມນ, ຫຼັງຈາກກອງປະຊຸມເຫດການຫຼາຍຄັ້ງ, ໂດເມນທັງຫມົດໄດ້ຖືກແບ່ງອອກເປັນສາມໂດເມນຍ່ອຍທີ່ມີຂອບເຂດກໍານົດທີ່ມີຂອບເຂດທີ່ຊັດເຈນ, ຮູບແບບໂດເມນ, ແລະພາສາທີ່ກວ້າງຂວາງ.

ທໍາອິດ ແມ່ນມອບຫມາຍໃຫ້ onboarding ແລະລວບລວມຄໍາຮ້ອງສະຫມັກເງິນກູ້ໃຫມ່. ລະບົບ ທີສອງ ປະເມີນຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ແລະເຮັດການຕັດສິນໃຈໂດຍອີງໃສ່ຂໍ້ມູນທີ່ສະຫນອງໃຫ້. ຂະບວນການປະເມີນນີ້, ລວມທັງ KYC/KYB, ການຕ້ານການສໍ້ໂກງ, ແລະການກວດສອບຄວາມສ່ຽງດ້ານສິນເຊື່ອ, ສາມາດໃຊ້ເວລາຫຼາຍ, ມີຄວາມຈໍາເປັນໃນການຈັດການຄໍາຮ້ອງສະຫມັກຫຼາຍພັນອັນພ້ອມກັນ. ດັ່ງນັ້ນ, ຫນ້າທີ່ນີ້ໄດ້ຖືກມອບຫມາຍໃຫ້ກັບບໍລິການຈຸລະພາກທີ່ອຸທິດຕົນທີ່ມີຖານຂໍ້ມູນຂອງຕົນເອງ, ອະນຸຍາດໃຫ້ມີຂະຫນາດເອກະລາດ.

ຍິ່ງໄປກວ່ານັ້ນ, ລະບົບຍ່ອຍເຫຼົ່ານີ້ຖືກຈັດການໂດຍສອງທີມທີ່ແຕກຕ່າງກັນ, ແຕ່ລະຄົນມີວົງຈອນການປ່ອຍຕົວຂອງມັນເອງ, ຂໍ້ຕົກລົງລະດັບການບໍລິການ (SLA), ແລະຄວາມຕ້ອງການຂະຫນາດ.

ສຸດທ້າຍ , ການບໍລິການແຈ້ງການພິເສດແມ່ນຢູ່ໃນສະຖານທີ່ເພື່ອສົ່ງການແຈ້ງເຕືອນໃຫ້ລູກຄ້າ.

ນີ້ແມ່ນຄໍາອະທິບາຍທີ່ຫລອມໂລຫະຂອງກໍລະນີການນໍາໃຊ້ຕົ້ນຕໍຂອງລະບົບ:

1. ລູກຄ້າສົ່ງໃບສະໝັກເງິນກູ້.
2. ການບໍລິການການຮ້ອງຂໍເງິນກູ້ບັນທຶກຄໍາຮ້ອງສະຫມັກໃຫມ່ທີ່ມີສະຖານະ "ຍັງຄ້າງ" ແລະເລີ່ມຕົ້ນຂະບວນການປະເມີນຜົນໂດຍການສົ່ງຕໍ່ຄໍາຮ້ອງສະຫມັກໄປຍັງບໍລິການການປະເມີນຜົນ.
3. ການບໍລິການການປະເມີນປະເມີນຄໍາຮ້ອງຂໍເງິນກູ້ທີ່ເຂົ້າມາແລະຕໍ່ມາແຈ້ງໃຫ້ບໍລິການຄໍາຮ້ອງຂໍເງິນກູ້ຂອງການຕັດສິນໃຈ.
4. ເມື່ອໄດ້ຮັບການຕັດສິນໃຈ, ການບໍລິການການຮ້ອງຂໍເງິນກູ້ຈະປັບປຸງສະຖານະພາບການຮ້ອງຂໍເງິນກູ້ຕາມຄວາມເຫມາະສົມແລະກະຕຸ້ນການບໍລິການແຈ້ງການເພື່ອແຈ້ງໃຫ້ລູກຄ້າຂອງຜົນໄດ້ຮັບ.
5. ການບໍລິການແຈ້ງການປະມວນຜົນການຮ້ອງຂໍນີ້ແລະສົ່ງແຈ້ງການໃຫ້ລູກຄ້າຜ່ານທາງອີເມລ໌, SMS, ຫຼືວິທີການສື່ສານອື່ນໆທີ່ຕ້ອງການ, ອີງຕາມການກໍານົດຂອງລູກຄ້າ.

ມັນເປັນລະບົບທີ່ງ່າຍດາຍທີ່ສວຍງາມແລະເບື້ອງຕົ້ນຢູ່ glance ທໍາອິດ, ແຕ່ໃຫ້ dive ເຂົ້າໄປໃນວິທີການບໍລິການຄໍາຮ້ອງສະຫມັກເງິນກູ້ດໍາເນີນການຄໍາສັ່ງການຍື່ນຄໍາຮ້ອງຂໍເງິນກູ້.

ພວກເຮົາສາມາດພິຈາລະນາສອງວິທີການສໍາລັບການໂຕ້ຕອບການບໍລິການ:

1. First-Local-Commit-Then-Publish: ໃນວິທີການນີ້, ບໍລິການປັບປຸງຖານຂໍ້ມູນທ້ອງຖິ່ນຂອງຕົນ (ຄໍາຫມັ້ນສັນຍາ) ແລະຫຼັງຈາກນັ້ນເຜີຍແຜ່ເຫດການຫຼືຂໍ້ຄວາມໃຫ້ກັບບໍລິການອື່ນໆ.

2. First-Publish-Then-Local-Commit: ໃນທາງກັບກັນ, ວິທີການນີ້ກ່ຽວຂ້ອງກັບການເຜີຍແຜ່ເຫດການ ຫຼືຂໍ້ຄວາມກ່ອນທີ່ຈະເຮັດການປ່ຽນແປງກັບຖານຂໍ້ມູນທ້ອງຖິ່ນ.

   
   

ວິທີການທັງສອງມີຂໍ້ບົກຜ່ອງຂອງພວກເຂົາແລະພຽງແຕ່ບາງສ່ວນທີ່ລົ້ມເຫລວ - ປອດໄພສໍາລັບການສື່ສານໃນລະບົບແຈກຢາຍ.

ນີ້ແມ່ນແຜນວາດລໍາດັບຂອງການນໍາໃຊ້ວິທີການທໍາອິດ.

ໃນສະຖານະການນີ້, ການບໍລິການການຮ້ອງຂໍເງິນກູ້ຢືມໃຊ້ວິທີການ ທໍາອິດທ້ອງຖິ່ນ - ສັນຍາ - ຫຼັງຈາກນັ້ນ - ເຜີຍແຜ່ , ບ່ອນທີ່ມັນທໍາອິດເຮັດທຸລະກໍາແລະຫຼັງຈາກນັ້ນພະຍາຍາມສົ່ງແຈ້ງການໄປຫາລະບົບອື່ນ. ຢ່າງໃດກໍຕາມ, ຂະບວນການນີ້ແມ່ນມີຄວາມອ່ອນໄຫວຕໍ່ກັບຄວາມລົ້ມເຫຼວຖ້າຫາກວ່າ, ສໍາລັບການຍົກຕົວຢ່າງ, ມີບັນຫາເຄືອຂ່າຍ, ບໍລິການການປະເມີນບໍ່ສາມາດໃຊ້ໄດ້, ຫຼືການບໍລິການຄໍາຮ້ອງສະຫມັກເງິນກູ້ພົບຄວາມຜິດພາດ Out of Memory (OOM) ແລະ crash. ໃນກໍລະນີດັ່ງກ່າວ, ຂໍ້ຄວາມຈະສູນເສຍ, ເຮັດໃຫ້ການປະເມີນຜົນໂດຍບໍ່ມີການແຈ້ງການຂອງຄໍາຮ້ອງສະຫມັກເງິນກູ້ໃຫມ່, ເວັ້ນເສຍແຕ່ມາດຕະການເພີ່ມເຕີມໄດ້ຖືກປະຕິບັດ.

ແລະອັນທີສອງ.

ໃນສະຖານະການ ທໍາອິດທີ່ເຜີຍແຜ່ - ຫຼັງຈາກນັ້ນ - ທ້ອງຖິ່ນ , ການບໍລິການການຮ້ອງຂໍເງິນກູ້ປະເຊີນກັບຄວາມສ່ຽງຫຼາຍ. ມັນອາດຈະແຈ້ງການບໍລິການການປະເມີນກ່ຽວກັບແອັບພລິເຄຊັນໃໝ່ ແຕ່ບໍ່ສາມາດບັນທຶກການອັບເດດນີ້ຢູ່ໃນທ້ອງຖິ່ນ ເນື່ອງຈາກບັນຫາເຊັ່ນ: ບັນຫາຖານຂໍ້ມູນ, ຄວາມຜິດໃນໜ່ວຍຄວາມຈຳ ຫຼືຂໍ້ຜິດພາດຂອງລະຫັດ. ວິທີການນີ້ສາມາດນໍາໄປສູ່ຄວາມບໍ່ສອດຄ່ອງທີ່ສໍາຄັນໃນຂໍ້ມູນ, ເຊິ່ງອາດຈະເຮັດໃຫ້ເກີດບັນຫາຮ້າຍແຮງ, ຂຶ້ນກັບວິທີການບໍລິການທົບທວນເງິນກູ້ຈັດການກັບຄໍາຮ້ອງສະຫມັກທີ່ເຂົ້າມາ.

ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງກໍານົດການແກ້ໄຂທີ່ສະຫນອງກົນໄກທີ່ເຂັ້ມແຂງສໍາລັບການເຜີຍແຜ່ເຫດການໃຫ້ກັບຜູ້ບໍລິໂພກພາຍນອກ. ແຕ່, ກ່ອນທີ່ຈະ delving ເຂົ້າໄປໃນການແກ້ໄຂທີ່ມີທ່າແຮງ, ພວກເຮົາທໍາອິດຄວນຈະໃຫ້ຄວາມກະຈ່າງແຈ້ງປະເພດຂອງການຮັບປະກັນການສົ່ງຂໍ້ຄວາມສາມາດບັນລຸໄດ້ໃນລະບົບແຈກຢາຍ.

ຮັບປະກັນການຈັດສົ່ງຂໍ້ຄວາມ

ມີສີ່ປະເພດຂອງການຮັບປະກັນທີ່ພວກເຮົາສາມາດບັນລຸໄດ້.

1. ບໍ່ມີການຮັບປະກັນ
   ບໍ່ມີການຮັບປະກັນວ່າຂໍ້ຄວາມຈະຖືກສົ່ງເຖິງຈຸດຫມາຍປາຍທາງ. ວິທີການ First-Local-Commit- Then-Publish ແມ່ນຊັດເຈນກ່ຽວກັບເລື່ອງນີ້. ຜູ້ບໍລິໂພກອາດຈະໄດ້ຮັບຂໍ້ຄວາມຫນຶ່ງຄັ້ງ, ຫຼາຍຄັ້ງ, ຫຼືບໍ່ເຄີຍທັງຫມົດ.

2. ການຈັດສົ່ງຄັ້ງຫຼາຍທີ່ສຸດ
   ການຈັດສົ່ງຄັ້ງທີ່ຫຼາຍທີ່ສຸດຫມາຍຄວາມວ່າຂໍ້ຄວາມຈະຖືກສົ່ງໄປຫາປາຍທາງຫຼາຍທີ່ສຸດ 1 ຄັ້ງ. ວິທີການ ທໍາອິດ - ທ້ອງຖິ່ນ - ຄໍາຫມັ້ນສັນຍາຫຼັງຈາກນັ້ນ - ເຜີຍແຜ່ ສາມາດຖືກປະຕິບັດດ້ວຍວິທີນີ້ເຊັ່ນດຽວກັນກັບນະໂຍບາຍການພະຍາຍາມຄືນໃຫມ່ຂອງຄວາມພະຍາຍາມທີ່ມີຄ່າຫນຶ່ງ.

3. ຢ່າງໜ້ອຍໜຶ່ງຄັ້ງການຈັດສົ່ງ ຜູ້ບໍລິໂພກຈະໄດ້ຮັບ ແລະປະມວນຜົນທຸກຂໍ້ຄວາມ ແຕ່ອາດຈະໄດ້ຮັບຂໍ້ຄວາມດຽວກັນຫຼາຍກວ່າໜຶ່ງຄັ້ງ.

4. ການຈັດສົ່ງຄັ້ງດຽວ\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e\u003e ການຈັດສົ່ງເທົ່ານັ້ນ}}}}}}}}}}}}}}}\
   ດ້ານວິຊາການ, ມັນເປັນໄປໄດ້ທີ່ຈະບັນລຸການເຮັດທຸລະກໍາ Kafka ແລະການປະຕິບັດ idempotent ສະເພາະຂອງຜູ້ຜະລິດແລະຜູ້ບໍລິໂພກ.

   
   

ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການຮັບປະກັນການຈັດສົ່ງ 'ຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ' ແກ້ໄຂບັນຫາຫຼາຍຢ່າງໂດຍການຮັບປະກັນຂໍ້ຄວາມຖືກຈັດສົ່ງຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ, ແຕ່ຜູ້ບໍລິໂພກຕ້ອງບໍ່ມີຄວາມເຂັ້ມແຂງ. ຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍທີ່ບໍ່ສາມາດຫຼີກລ້ຽງໄດ້, ເຫດຜົນຂອງຜູ້ບໍລິໂພກທັງຫມົດຈະຕ້ອງມີຄວາມເຂັ້ມແຂງເພື່ອຫຼີກເວັ້ນການປະມວນຜົນຂໍ້ຄວາມທີ່ຊ້ໍາກັນ, ໂດຍບໍ່ຄໍານຶງເຖິງການຮັບປະກັນຂອງຜູ້ຜະລິດ. ດັ່ງນັ້ນ, ຄວາມຕ້ອງການນີ້ບໍ່ແມ່ນຂໍ້ບົກຜ່ອງຫຼາຍຍ້ອນວ່າມັນສະທ້ອນເຖິງຄວາມເປັນຈິງ.

ວິທີແກ້ໄຂ

ມີຫຼາຍວິທີແກ້ໄຂບັນຫານີ້, ເຊິ່ງມີຂໍ້ດີແລະຂໍ້ເສຍຂອງມັນ.

ຄໍາຫມັ້ນສັນຍາສອງໄລຍະ

ອີງຕາມວິກິພີເດຍ, ສັນຍາສອງໄລຍະ (2PC) ແມ່ນໂປໂຕຄອນການເຮັດທຸລະກໍາທີ່ແຈກຢາຍທີ່ໃຊ້ໃນວິທະຍາສາດຄອມພິວເຕີແລະລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນເພື່ອຮັບປະກັນຄວາມສອດຄ່ອງແລະຄວາມຫນ້າເຊື່ອຖືຂອງທຸລະກໍາທີ່ແຈກຢາຍ. ມັນຖືກອອກແບບມາສໍາລັບສະຖານະການທີ່ຊັບພະຍາກອນຫຼາຍ (ຕົວຢ່າງ, ຖານຂໍ້ມູນ) ຕ້ອງການເຂົ້າຮ່ວມໃນທຸລະກໍາດຽວ, ແລະມັນຮັບປະກັນວ່າພວກເຂົາທັງຫມົດເຮັດທຸລະກໍາຫຼືພວກເຂົາທັງຫມົດຍົກເລີກມັນ, ດັ່ງນັ້ນການຮັກສາຄວາມສອດຄ່ອງຂອງຂໍ້ມູນ. ມັນຟັງຄືສິ່ງທີ່ພວກເຮົາຕ້ອງການ, ແຕ່ Commit ສອງໄລຍະມີຂໍ້ບົກຜ່ອງຫຼາຍຢ່າງ:

• ຖ້າຊັບພະຍາກອນທີ່ເຂົ້າຮ່ວມຫນຶ່ງກາຍເປັນບໍ່ຕອບສະຫນອງຫຼືປະສົບກັບຄວາມລົ້ມເຫລວ, ຂະບວນການທັງຫມົດສາມາດຖືກບລັອກຈົນກວ່າບັນຫາຈະຖືກແກ້ໄຂ. ນີ້ສາມາດນໍາໄປສູ່ບັນຫາປະສິດທິພາບແລະຄວາມພ້ອມ.
• ສັນຍາສອງໄລຍະບໍ່ໄດ້ໃຫ້ກົນໄກຄວາມທົນທານຕໍ່ຄວາມຜິດພາດທີ່ສ້າງຂຶ້ນມາ. ມັນອີງໃສ່ກົນໄກພາຍນອກຫຼືການແຊກແຊງຄູ່ມືເພື່ອຈັດການກັບຄວາມລົ້ມເຫລວ.
• ບໍ່ແມ່ນຖານຂໍ້ມູນທີ່ທັນສະໄຫມທັງຫມົດສະຫນັບສະຫນູນສອງເຟດ Commit.

ຖານຂໍ້ມູນທີ່ແບ່ງປັນ

ການແກ້ໄຂທີ່ເຫັນໄດ້ຊັດເຈນທີ່ສຸດສໍາລັບສະຖາປັດຕະຍະກໍາ microservices ແມ່ນການນໍາໃຊ້ຮູບແບບ (ຫຼືແມ້ກະທັ້ງບາງຄັ້ງການຕ້ານຮູບແບບ) — ຖານຂໍ້ມູນທີ່ແບ່ງປັນ. ວິທີການນີ້ແມ່ນ intuitive ຫຼາຍຖ້າຫາກວ່າທ່ານຕ້ອງການຄວາມສອດຄ່ອງການເຮັດທຸລະກໍາໃນທົ່ວຕາຕະລາງຫຼາຍໃນຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນ, ພຽງແຕ່ນໍາໃຊ້ຖານຂໍ້ມູນແບ່ງປັນຫນຶ່ງສໍາລັບ microservices ເຫຼົ່ານີ້.

ຂໍ້ບົກຜ່ອງຂອງວິທີການນີ້ປະກອບມີການແນະນໍາຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ, ຂັດຂວາງການຂະຫຍາຍຖານຂໍ້ມູນເອກະລາດ, ແລະການຈໍາກັດຄວາມສາມາດໃນການນໍາໃຊ້ວິທີແກ້ໄຂຖານຂໍ້ມູນທີ່ແຕກຕ່າງກັນທີ່ເຫມາະສົມທີ່ສຸດສໍາລັບຄວາມຕ້ອງການສະເພາະແລະກໍລະນີການນໍາໃຊ້. ນອກຈາກນັ້ນ, ການດັດແກ້ລະຫັດ microservices ຈະມີຄວາມຈໍາເປັນເພື່ອສະຫນັບສະຫນູນຮູບແບບການແຈກຢາຍດັ່ງກ່າວ.

ກ່ອງອອກທຸລະກໍາ

' ກ່ອງອອກການເຮັດທຸລະກໍາ ' ແມ່ນຮູບແບບການອອກແບບທີ່ໃຊ້ໃນລະບົບການແຈກຢາຍເພື່ອຮັບປະກັນການເຜີຍແຜ່ຂໍ້ຄວາມທີ່ເຊື່ອຖືໄດ້, ເຖິງແມ່ນວ່າຈະປະເຊີນກັບລະບົບຂໍ້ຄວາມທີ່ບໍ່ຫນ້າເຊື່ອຖື. ມັນກ່ຽວຂ້ອງກັບການເກັບຮັກສາເຫດການໃນຕາຕະລາງ 'OutboxEvents' ທີ່ກໍານົດໄວ້ພາຍໃນການເຮັດທຸລະກໍາດຽວກັນກັບການດໍາເນີນງານຂອງມັນເອງ. ວິທີການນີ້ສອດຄ່ອງກັບຄຸນສົມບັດ ACID ຂອງຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ. ໃນທາງກົງກັນຂ້າມ, ຖານຂໍ້ມູນ No-SQL ຈໍານວນຫຼາຍບໍ່ສະຫນັບສະຫນູນຄຸນສົມບັດ ACID ຢ່າງເຕັມສ່ວນ, ແທນທີ່ຈະເລືອກຫຼັກການຂອງທິດສະດີ CAP ແລະປັດຊະຍາ BASE, ເຊິ່ງຈັດລໍາດັບຄວາມສໍາຄັນຂອງຄວາມພ້ອມແລະຄວາມສອດຄ່ອງໃນທີ່ສຸດຫຼາຍກວ່າຄວາມສອດຄ່ອງທີ່ເຄັ່ງຄັດ.

ກ່ອງອອກການເຮັດທຸລະກໍາສະຫນອງ ການຮັບປະກັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ ແລະສາມາດປະຕິບັດໄດ້ດ້ວຍຫຼາຍວິທີການ:

1. ການຕັດບັນທຶກການເຮັດທຸລະກໍາ

2. ຜູ້​ຈັດ​ພິມ​ການ​ລົງ​ຄະ​ແນນ​ສຽງ​

   
   

ວິທີ ການຕັດບັນທຶກການເຮັດທຸລະກໍາ ຫມາຍເຖິງການນໍາໃຊ້ວິທີແກ້ໄຂສະເພາະຂອງຖານຂໍ້ມູນເຊັ່ນ CDC (ການປ່ຽນແປງການຈັບຂໍ້ມູນ). ຂໍ້ບົກຜ່ອງຕົ້ນຕໍຂອງວິທີການດັ່ງກ່າວແມ່ນ:

• ວິທີແກ້ໄຂສະເພາະຂອງຖານຂໍ້ມູນ

• ຄວາມລ່າຊ້າເພີ່ມຂຶ້ນເນື່ອງຈາກສະເພາະຂອງການປະຕິບັດ CDC

  
  

ອີກວິທີໜຶ່ງແມ່ນ ຜູ້ຈັດພິມແບບສຳຫຼວດ , ເຊິ່ງອຳນວຍຄວາມສະດວກໃຫ້ແກ່ການອອກກ່ອງອອກໂດຍການສຳຫຼວດຕາຕະລາງອອກ. ຂໍ້ບົກຜ່ອງຕົ້ນຕໍຂອງວິທີການນີ້ແມ່ນທ່າແຮງສໍາລັບການໂຫຼດຖານຂໍ້ມູນທີ່ເພີ່ມຂຶ້ນ, ເຊິ່ງສາມາດນໍາໄປສູ່ຄ່າໃຊ້ຈ່າຍທີ່ສູງຂຶ້ນ. ຍິ່ງໄປກວ່ານັ້ນ, ບໍ່ແມ່ນທຸກຖານຂໍ້ມູນ No-SQL ສະຫນັບສະຫນູນການສອບຖາມທີ່ມີປະສິດທິພາບສໍາລັບພາກສ່ວນເອກະສານສະເພາະ. ການສະກັດເອົາເອກະສານທັງຫມົດ, ດັ່ງນັ້ນ, ເຮັດໃຫ້ການປະຕິບັດການເສື່ອມໂຊມ.

ນີ້ແມ່ນແຜນວາດລໍາດັບຂະຫນາດນ້ອຍທີ່ອະທິບາຍວິທີການເຮັດວຽກ.

ຟັງຕົວທ່ານເອງ

ສິ່ງທ້າທາຍຕົ້ນຕໍກັບຮູບແບບ Transactional Outbox ແມ່ນຢູ່ໃນການຂຶ້ນກັບຄຸນສົມບັດ ACID ຖານຂໍ້ມູນ. ມັນອາດຈະກົງໄປກົງມາໃນຖານຂໍ້ມູນ OLTP ປົກກະຕິແຕ່ສ້າງຄວາມທ້າທາຍໃນຂອບເຂດ NoSQL. ເພື່ອແກ້ໄຂບັນຫານີ້, ການແກ້ໄຂທີ່ມີທ່າແຮງແມ່ນການໃຊ້ບັນທຶກການເພີ່ມເຕີມ (ຕົວຢ່າງ, Kafka) ຕັ້ງແຕ່ເລີ່ມຕົ້ນການດໍາເນີນການຮ້ອງຂໍ.

ແທນທີ່ຈະດໍາເນີນການໂດຍກົງຄໍາສັ່ງ 'ຍື່ນຄໍາຮ້ອງຂໍເງິນກູ້', ພວກເຮົາທັນທີສົ່ງມັນໄປຫາຫົວຂໍ້ Kafka ພາຍໃນແລະຫຼັງຈາກນັ້ນສົ່ງຜົນໄດ້ຮັບ 'ຍອມຮັບ' ກັບລູກຄ້າ. ຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກມັນເປັນໄປໄດ້ສູງທີ່ຄໍາສັ່ງຍັງຕ້ອງໄດ້ຮັບການປຸງແຕ່ງ, ພວກເຮົາບໍ່ສາມາດແຈ້ງໃຫ້ລູກຄ້າຮູ້ຜົນໄດ້ຮັບທັນທີ. ເພື່ອຈັດການຄວາມສອດຄ່ອງສຸດທ້າຍນີ້, ພວກເຮົາສາມາດນຳໃຊ້ເຕັກນິກຕ່າງໆ ເຊັ່ນ: ການລົງຄະແນນສຽງທີ່ຍາວນານ, ການສຳຫຼວດລູກຄ້າທີ່ລິເລີ່ມ, ການອັບເດດ UI ທີ່ເປັນໄປໃນແງ່ດີ, ຫຼືໃຊ້ WebSockets ຫຼື Server-Sent Events ສໍາລັບການແຈ້ງເຕືອນ. ຢ່າງໃດກໍ່ຕາມ, ນີ້ແມ່ນຫົວຂໍ້ທີ່ແຕກຕ່າງກັນທັງຫມົດ, ດັ່ງນັ້ນໃຫ້ພວກເຮົາກັບຄືນໄປຫາຫົວຂໍ້ເບື້ອງຕົ້ນຂອງພວກເຮົາ.

ພວກເຮົາໄດ້ສົ່ງຂໍ້ຄວາມໃນຫົວຂໍ້ 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 ລົ້ມເຫລວ? ບໍ່ຕ້ອງກັງວົນ, ເນື່ອງຈາກວ່າເຫດຜົນທາງທຸລະກິດແມ່ນ ideempotent, ມັນຈະບໍ່ສ້າງຄໍາຮ້ອງສະຫມັກການກູ້ຢືມເງິນຊ້ໍາກັນ. ແທນທີ່ຈະ, ມັນຈະພະຍາຍາມສົ່ງຂໍ້ຄວາມໄປຫາຫົວຂໍ້ Kafka ສາທາລະນະ.

ຈະເປັນແນວໃດຖ້າຂໍ້ຄວາມຖືກສົ່ງໄປຫາ Kafka, ແຕ່ການຊົດເຊີຍຄວາມລົ້ມເຫລວ? ບໍ່ຕ້ອງກັງວົນ, ເນື່ອງຈາກວ່າເຫດຜົນທາງທຸລະກິດແມ່ນ ideempotent, ມັນຈະບໍ່ສ້າງຄໍາຮ້ອງສະຫມັກການກູ້ຢືມເງິນຊ້ໍາກັນ. ແທນທີ່ຈະ, ມັນຈະສົ່ງຂໍ້ຄວາມໄປຫາຫົວຂໍ້ Kafka ສາທາລະນະແລະຫວັງວ່າຄໍາຫມັ້ນສັນຍາຊົດເຊີຍຈະປະສົບຜົນສໍາເລັດໃນເວລານີ້.

ຂໍ້ບົກຜ່ອງຕົ້ນຕໍຂອງວິທີການນີ້ປະກອບມີຄວາມສັບສົນເພີ່ມເຕີມທີ່ກ່ຽວຂ້ອງກັບຮູບແບບການຂຽນໂປລແກລມໃຫມ່, ຄວາມສອດຄ່ອງໃນທີ່ສຸດ (ເນື່ອງຈາກວ່າລູກຄ້າຈະບໍ່ຮູ້ຜົນໄດ້ຮັບທັນທີ), ແລະຄວາມຕ້ອງການສໍາລັບເຫດຜົນທາງທຸລະກິດທັງຫມົດທີ່ຈະບໍ່ມີຄວາມເຂັ້ມແຂງ.

ແຫຼ່ງເຫດການ

ແຫລ່ງທີ່ມາຂອງເຫດການແມ່ນຫຍັງ, ແລະມັນຈະຖືກນໍາມາໃຊ້ທີ່ນີ້ໄດ້ແນວໃດ? ແຫລ່ງທີ່ມາຂອງເຫດການແມ່ນຮູບແບບສະຖາປັດຕະຍະກຳຊອບແວທີ່ໃຊ້ເພື່ອສ້າງແບບຈໍາລອງສະຖານະຂອງລະບົບໂດຍການຈັບເອົາການປ່ຽນແປງທັງໝົດຕໍ່ກັບຂໍ້ມູນຂອງມັນເປັນຊຸດຂອງເຫດການທີ່ບໍ່ປ່ຽນແປງໄດ້. ເຫດການເຫຼົ່ານີ້ສະແດງເຖິງຄວາມຈິງ ຫຼືການຫັນປ່ຽນຂອງລັດ ແລະເປັນແຫຼ່ງຄວາມຈິງອັນດຽວສຳລັບສະຖານະປັດຈຸບັນຂອງລະບົບ. ດັ່ງນັ້ນ, ທາງດ້ານເຕັກນິກ, ໂດຍການປະຕິບັດລະບົບແຫຼ່ງເຫດການ, ພວກເຮົາມີເຫດການທັງຫມົດໃນ EventStore, ແລະ EventStore ນີ້ສາມາດຖືກນໍາໃຊ້ໂດຍຜູ້ບໍລິໂພກເປັນແຫຼ່ງດຽວຂອງຄວາມຈິງກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ. ບໍ່ຈໍາເປັນຕ້ອງມີການແກ້ໄຂຖານຂໍ້ມູນສະເພາະສໍາລັບການຕິດຕາມການປ່ຽນແປງທັງຫມົດຫຼືຄວາມກັງວົນກ່ຽວກັບການສັ່ງຊື້, ບັນຫາດຽວແມ່ນນັ່ງຢູ່ດ້ານຂ້າງອ່ານນັບຕັ້ງແຕ່ເພື່ອໃຫ້ສາມາດໄດ້ຮັບສະຖານະຕົວຈິງຂອງຫນ່ວຍງານແມ່ນຈໍາເປັນເພື່ອຫຼິ້ນຄືນເຫດການທັງຫມົດ.

ສະຫຼຸບ

ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ທົບທວນຄືນວິທີການຈໍານວນຫນຶ່ງສໍາລັບການສ້າງຂໍ້ຄວາມທີ່ເຊື່ອຖືໄດ້ໃນລະບົບແຈກຢາຍ. ມີຫຼາຍຄໍາແນະນໍາທີ່ພວກເຮົາສາມາດພິຈາລະນາໃນຂະນະທີ່ການກໍ່ສ້າງລະບົບທີ່ມີລັກສະນະເຫຼົ່ານີ້

1. ສະເຫມີພັດທະນາຜູ້ບໍລິໂພກທີ່ບໍ່ມີທ່າແຮງນັບຕັ້ງແຕ່ຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍແມ່ນບໍ່ສາມາດຫຼີກເວັ້ນໄດ້.
2. ໃຊ້ First-Local-Commit-Tan-Publish ຢ່າງລະມັດລະວັງດ້ວຍຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບຂໍ້ກໍານົດການຄໍ້າປະກັນ.
3. ຢ່າໃຊ້ວິທີ First-Publish-Then-Local-Commit ເພາະວ່າມັນອາດຈະເຮັດໃຫ້ຂໍ້ມູນບໍ່ສອດຄ່ອງກັນຢ່າງຮ້າຍແຮງໃນລະບົບຂອງເຈົ້າ.
4. ຖ້າການຕັດສິນໃຈທາງເລືອກຖານຂໍ້ມູນທີ່ມີຢູ່ແລ້ວອາດຈະມີການປ່ຽນແປງຫຼືຍຸດທະສາດດ້ານວິຊາການຫມາຍເຖິງການເລືອກເອົາການແກ້ໄຂການເກັບຮັກສາທີ່ດີທີ່ສຸດສໍາລັບບັນຫາ - ຢ່າສ້າງຫ້ອງສະຫມຸດຮ່ວມກັນໂດຍການຜູກມັດກັບວິທີແກ້ໄຂຖານຂໍ້ມູນເຊັ່ນ CDC .
5. ໃຊ້ວິທີການ Transactional Outbox ເປັນການແກ້ໄຂມາດຕະຖານສໍາລັບການບັນລຸການຮັບປະກັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ.
6. ພິຈາລະນາໃຊ້ວິທີ ການຟັງຕົວເອງ ໃນເວລາທີ່ຖານຂໍ້ມູນ No-SQL ຖືກນໍາໃຊ້.

ໃນຄັ້ງຕໍ່ໄປ, ພວກເຮົາຈະເບິ່ງຕົວຢ່າງການປະຕິບັດເພີ່ມເຕີມຂອງການປະຕິບັດ Transactional Outbox. ເບິ່ງ

ເຈົ້າ!