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

ບັນຫາການຂຽນຄູ່ ການສ້າງລະບົບການແຈກຢາຍທີ່ເຊື່ອຖືໄດ້, ສາມາດໃຊ້ໄດ້ສູງ, ສາມາດຂະຫຍາຍໄດ້ຮຽກຮ້ອງໃຫ້ມີການຍຶດຫມັ້ນກັບເຕັກນິກ, ຫຼັກການ, ແລະຮູບແບບສະເພາະ. ການອອກແບບຂອງລະບົບດັ່ງກ່າວກ່ຽວຂ້ອງກັບການແກ້ໄຂຄວາມທ້າທາຍຫຼາຍຢ່າງ. ໃນບັນດາບັນຫາທີ່ແຜ່ຫຼາຍແລະພື້ນຖານທີ່ສຸດແມ່ນ . ບັນຫາການຂຽນຄູ່ ແມ່ນສິ່ງທ້າທາຍທີ່ເກີດຂື້ນໃນລະບົບການແຈກຢາຍ, ສ່ວນໃຫຍ່ແມ່ນໃນເວລາທີ່ຈັດການກັບແຫຼ່ງຂໍ້ມູນຫຼາຍຫຼືຖານຂໍ້ມູນທີ່ຕ້ອງໄດ້ຮັບການເກັບຮັກສາໄວ້ໃນ sync. ມັນຫມາຍເຖິງຄວາມຫຍຸ້ງຍາກໃນການຮັບປະກັນວ່າການປ່ຽນແປງຂໍ້ມູນຖືກຂຽນຢ່າງຕໍ່ເນື່ອງກັບບ່ອນເກັບຂໍ້ມູນຕ່າງໆ, ເຊັ່ນ: ຖານຂໍ້ມູນຫຼືຖານຄວາມຈໍາ, ໂດຍບໍ່ມີການແນະນໍາບັນຫາຕ່າງໆເຊັ່ນຄວາມບໍ່ສອດຄ່ອງຂອງຂໍ້ມູນ, ຄວາມຂັດແຍ້ງ, ຫຼືຂໍ້ບົກຜ່ອງດ້ານການປະຕິບັດ. "ບັນຫາການຂຽນຄູ່" ສະຖາປັດຕະຍະກໍາ microservices ແລະຖານຂໍ້ມູນຮູບແບບຕໍ່ການບໍລິການນໍາມາໃຫ້ທ່ານຜົນປະໂຫຍດຈໍານວນຫຼາຍ, ເຊັ່ນ: ການຈັດວາງເອກະລາດແລະຂະຫນາດ, ຄວາມລົ້ມເຫຼວທີ່ໂດດດ່ຽວ, ແລະການເພີ່ມຄວາມໄວຂອງການພັດທະນາ. ຢ່າງໃດກໍຕາມ, ການດໍາເນີນງານຮຽກຮ້ອງໃຫ້ມີການປ່ຽນແປງລະຫວ່າງ microservices ຫຼາຍ, ບັງຄັບໃຫ້ທ່ານຄິດກ່ຽວກັບການແກ້ໄຂທີ່ເຊື່ອຖືໄດ້ເພື່ອແກ້ໄຂບັນຫານີ້. ເກືອບເປັນຕົວຢ່າງທີ່ແທ້ຈິງ ຂໍໃຫ້ພິຈາລະນາສະຖານະການທີ່ໂດເມນຂອງພວກເຮົາກ່ຽວຂ້ອງກັບການຮັບເອົາຄໍາຮ້ອງຂໍເງິນກູ້, ການປະເມີນພວກມັນ, ແລະຫຼັງຈາກນັ້ນສົ່ງການແຈ້ງເຕືອນໃຫ້ລູກຄ້າ. ໃນຈິດໃຈຂອງຫຼັກການຄວາມຮັບຜິດຊອບດຽວ, ກົດຫມາຍຂອງ Conway, ແລະວິທີການອອກແບບໂດເມນ, ຫຼັງຈາກກອງປະຊຸມເຫດການຫຼາຍຄັ້ງ, ໂດເມນທັງຫມົດໄດ້ຖືກແບ່ງອອກເປັນສາມໂດເມນຍ່ອຍທີ່ມີຂອບເຂດກໍານົດທີ່ມີຂອບເຂດທີ່ຊັດເຈນ, ຮູບແບບໂດເມນ, ແລະພາສາທີ່ກວ້າງຂວາງ. ແມ່ນມອບຫມາຍໃຫ້ onboarding ແລະລວບລວມຄໍາຮ້ອງສະຫມັກເງິນກູ້ໃຫມ່. ລະບົບ ປະເມີນຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້ແລະເຮັດການຕັດສິນໃຈໂດຍອີງໃສ່ຂໍ້ມູນທີ່ສະຫນອງໃຫ້. ຂະບວນການປະເມີນນີ້, ລວມທັງ KYC/KYB, ການຕ້ານການສໍ້ໂກງ, ແລະການກວດສອບຄວາມສ່ຽງດ້ານສິນເຊື່ອ, ສາມາດໃຊ້ເວລາຫຼາຍ, ມີຄວາມຈໍາເປັນໃນການຈັດການຄໍາຮ້ອງສະຫມັກຫຼາຍພັນອັນພ້ອມກັນ. ດັ່ງນັ້ນ, ຫນ້າທີ່ນີ້ໄດ້ຖືກມອບຫມາຍໃຫ້ກັບບໍລິການຈຸລະພາກທີ່ອຸທິດຕົນທີ່ມີຖານຂໍ້ມູນຂອງຕົນເອງ, ອະນຸຍາດໃຫ້ມີຂະຫນາດເອກະລາດ. ທໍາອິດ ທີສອງ ຍິ່ງໄປກວ່ານັ້ນ, ລະບົບຍ່ອຍເຫຼົ່ານີ້ຖືກຈັດການໂດຍສອງທີມທີ່ແຕກຕ່າງກັນ, ແຕ່ລະຄົນມີວົງຈອນການປ່ອຍຕົວຂອງມັນເອງ, ຂໍ້ຕົກລົງລະດັບການບໍລິການ (SLA), ແລະຄວາມຕ້ອງການຂະຫນາດ. , ການບໍລິການແຈ້ງການພິເສດແມ່ນຢູ່ໃນສະຖານທີ່ເພື່ອສົ່ງການແຈ້ງເຕືອນໃຫ້ລູກຄ້າ. ສຸດທ້າຍ ນີ້ແມ່ນຄໍາອະທິບາຍທີ່ຫລອມໂລຫະຂອງກໍລະນີການນໍາໃຊ້ຕົ້ນຕໍຂອງລະບົບ: ລູກຄ້າສົ່ງໃບສະໝັກເງິນກູ້. ການບໍລິການການຮ້ອງຂໍເງິນກູ້ບັນທຶກຄໍາຮ້ອງສະຫມັກໃຫມ່ທີ່ມີສະຖານະ "ຍັງຄ້າງ" ແລະເລີ່ມຕົ້ນຂະບວນການປະເມີນຜົນໂດຍການສົ່ງຕໍ່ຄໍາຮ້ອງສະຫມັກໄປຍັງບໍລິການການປະເມີນຜົນ. ການບໍລິການການປະເມີນປະເມີນຄໍາຮ້ອງຂໍເງິນກູ້ທີ່ເຂົ້າມາແລະຕໍ່ມາແຈ້ງໃຫ້ບໍລິການຄໍາຮ້ອງຂໍເງິນກູ້ຂອງການຕັດສິນໃຈ. ເມື່ອໄດ້ຮັບການຕັດສິນໃຈ, ການບໍລິການການຮ້ອງຂໍເງິນກູ້ຈະປັບປຸງສະຖານະພາບການຮ້ອງຂໍເງິນກູ້ຕາມຄວາມເຫມາະສົມແລະກະຕຸ້ນການບໍລິການແຈ້ງການເພື່ອແຈ້ງໃຫ້ລູກຄ້າຂອງຜົນໄດ້ຮັບ. ການບໍລິການແຈ້ງການປະມວນຜົນການຮ້ອງຂໍນີ້ແລະສົ່ງແຈ້ງການໃຫ້ລູກຄ້າຜ່ານທາງອີເມລ໌, SMS, ຫຼືວິທີການສື່ສານອື່ນໆທີ່ຕ້ອງການ, ອີງຕາມການກໍານົດຂອງລູກຄ້າ. ມັນເປັນລະບົບທີ່ງ່າຍດາຍທີ່ສວຍງາມແລະເບື້ອງຕົ້ນຢູ່ glance ທໍາອິດ, ແຕ່ໃຫ້ dive ເຂົ້າໄປໃນວິທີການບໍລິການຄໍາຮ້ອງສະຫມັກເງິນກູ້ດໍາເນີນການຄໍາສັ່ງການຍື່ນຄໍາຮ້ອງຂໍເງິນກູ້. ພວກເຮົາສາມາດພິຈາລະນາສອງວິທີການສໍາລັບການໂຕ້ຕອບການບໍລິການ: ໃນວິທີການນີ້, ບໍລິການປັບປຸງຖານຂໍ້ມູນທ້ອງຖິ່ນຂອງຕົນ (ຄໍາຫມັ້ນສັນຍາ) ແລະຫຼັງຈາກນັ້ນເຜີຍແຜ່ເຫດການຫຼືຂໍ້ຄວາມໃຫ້ກັບບໍລິການອື່ນໆ. First-Local-Commit-Then-Publish: ໃນທາງກັບກັນ, ວິທີການນີ້ກ່ຽວຂ້ອງກັບການເຜີຍແຜ່ເຫດການ ຫຼືຂໍ້ຄວາມກ່ອນທີ່ຈະເຮັດການປ່ຽນແປງກັບຖານຂໍ້ມູນທ້ອງຖິ່ນ. First-Publish-Then-Local-Commit: ວິທີການທັງສອງມີຂໍ້ບົກຜ່ອງຂອງພວກເຂົາແລະພຽງແຕ່ບາງສ່ວນທີ່ລົ້ມເຫລວ - ປອດໄພສໍາລັບການສື່ສານໃນລະບົບແຈກຢາຍ. ນີ້ແມ່ນແຜນວາດລໍາດັບຂອງການນໍາໃຊ້ວິທີການທໍາອິດ. ໃນສະຖານະການນີ້, ການບໍລິການການຮ້ອງຂໍເງິນກູ້ຢືມໃຊ້ວິທີການ , ບ່ອນທີ່ມັນທໍາອິດເຮັດທຸລະກໍາແລະຫຼັງຈາກນັ້ນພະຍາຍາມສົ່ງແຈ້ງການໄປຫາລະບົບອື່ນ. ຢ່າງໃດກໍຕາມ, ຂະບວນການນີ້ແມ່ນມີຄວາມອ່ອນໄຫວຕໍ່ກັບຄວາມລົ້ມເຫຼວຖ້າຫາກວ່າ, ສໍາລັບການຍົກຕົວຢ່າງ, ມີບັນຫາເຄືອຂ່າຍ, ບໍລິການການປະເມີນບໍ່ສາມາດໃຊ້ໄດ້, ຫຼືການບໍລິການຄໍາຮ້ອງສະຫມັກເງິນກູ້ພົບຄວາມຜິດພາດ Out of Memory (OOM) ແລະ crash. ໃນກໍລະນີດັ່ງກ່າວ, ຂໍ້ຄວາມຈະສູນເສຍ, ເຮັດໃຫ້ການປະເມີນຜົນໂດຍບໍ່ມີການແຈ້ງການຂອງຄໍາຮ້ອງສະຫມັກເງິນກູ້ໃຫມ່, ເວັ້ນເສຍແຕ່ມາດຕະການເພີ່ມເຕີມໄດ້ຖືກປະຕິບັດ. ທໍາອິດທ້ອງຖິ່ນ - ສັນຍາ - ຫຼັງຈາກນັ້ນ - ເຜີຍແຜ່ ແລະອັນທີສອງ. ໃນສະຖານະການ , ການບໍລິການການຮ້ອງຂໍເງິນກູ້ປະເຊີນກັບຄວາມສ່ຽງຫຼາຍ. ມັນອາດຈະແຈ້ງການບໍລິການການປະເມີນກ່ຽວກັບແອັບພລິເຄຊັນໃໝ່ ແຕ່ບໍ່ສາມາດບັນທຶກການອັບເດດນີ້ຢູ່ໃນທ້ອງຖິ່ນ ເນື່ອງຈາກບັນຫາເຊັ່ນ: ບັນຫາຖານຂໍ້ມູນ, ຄວາມຜິດໃນໜ່ວຍຄວາມຈຳ ຫຼືຂໍ້ຜິດພາດຂອງລະຫັດ. ວິທີການນີ້ສາມາດນໍາໄປສູ່ຄວາມບໍ່ສອດຄ່ອງທີ່ສໍາຄັນໃນຂໍ້ມູນ, ເຊິ່ງອາດຈະເຮັດໃຫ້ເກີດບັນຫາຮ້າຍແຮງ, ຂຶ້ນກັບວິທີການບໍລິການທົບທວນເງິນກູ້ຈັດການກັບຄໍາຮ້ອງສະຫມັກທີ່ເຂົ້າມາ. ທໍາອິດທີ່ເຜີຍແຜ່ - ຫຼັງຈາກນັ້ນ - ທ້ອງຖິ່ນ ດັ່ງນັ້ນ, ພວກເຮົາຕ້ອງກໍານົດການແກ້ໄຂທີ່ສະຫນອງກົນໄກທີ່ເຂັ້ມແຂງສໍາລັບການເຜີຍແຜ່ເຫດການໃຫ້ກັບຜູ້ບໍລິໂພກພາຍນອກ. ແຕ່, ກ່ອນທີ່ຈະ delving ເຂົ້າໄປໃນການແກ້ໄຂທີ່ມີທ່າແຮງ, ພວກເຮົາທໍາອິດຄວນຈະໃຫ້ຄວາມກະຈ່າງແຈ້ງປະເພດຂອງການຮັບປະກັນການສົ່ງຂໍ້ຄວາມສາມາດບັນລຸໄດ້ໃນລະບົບແຈກຢາຍ. ຮັບປະກັນການຈັດສົ່ງຂໍ້ຄວາມ ມີສີ່ປະເພດຂອງການຮັບປະກັນທີ່ພວກເຮົາສາມາດບັນລຸໄດ້. ບໍ່ມີການຮັບປະກັນ ບໍ່ມີການຮັບປະກັນວ່າຂໍ້ຄວາມຈະຖືກສົ່ງເຖິງຈຸດຫມາຍປາຍທາງ. ວິທີການ ແມ່ນຊັດເຈນກ່ຽວກັບເລື່ອງນີ້. ຜູ້ບໍລິໂພກອາດຈະໄດ້ຮັບຂໍ້ຄວາມຫນຶ່ງຄັ້ງ, ຫຼາຍຄັ້ງ, ຫຼືບໍ່ເຄີຍທັງຫມົດ. First-Local-Commit- Then-Publish ການຈັດສົ່ງຄັ້ງຫຼາຍທີ່ສຸດ ການຈັດສົ່ງຄັ້ງທີ່ຫຼາຍທີ່ສຸດຫມາຍຄວາມວ່າຂໍ້ຄວາມຈະຖືກສົ່ງໄປຫາປາຍທາງຫຼາຍທີ່ສຸດ 1 ຄັ້ງ. ວິທີການ ສາມາດຖືກປະຕິບັດດ້ວຍວິທີນີ້ເຊັ່ນດຽວກັນກັບນະໂຍບາຍການພະຍາຍາມຄືນໃຫມ່ຂອງຄວາມພະຍາຍາມທີ່ມີຄ່າຫນຶ່ງ. ທໍາອິດ - ທ້ອງຖິ່ນ - ຄໍາຫມັ້ນສັນຍາຫຼັງຈາກນັ້ນ - ເຜີຍແຜ່ ຢ່າງໜ້ອຍໜຶ່ງຄັ້ງການຈັດສົ່ງ ຜູ້ບໍລິໂພກຈະໄດ້ຮັບ ແລະປະມວນຜົນທຸກຂໍ້ຄວາມ ແຕ່ອາດຈະໄດ້ຮັບຂໍ້ຄວາມດຽວກັນຫຼາຍກວ່າໜຶ່ງຄັ້ງ. ການຈັດສົ່ງຄັ້ງດຽວ\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, ເຊິ່ງຈັດລໍາດັບຄວາມສໍາຄັນຂອງຄວາມພ້ອມແລະຄວາມສອດຄ່ອງໃນທີ່ສຸດຫຼາຍກວ່າຄວາມສອດຄ່ອງທີ່ເຄັ່ງຄັດ. ກ່ອງອອກການເຮັດທຸລະກໍາ ກ່ອງອອກການເຮັດທຸລະກໍາສະຫນອງ ແລະສາມາດປະຕິບັດໄດ້ດ້ວຍຫຼາຍວິທີການ: ການຮັບປະກັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ ການຕັດບັນທຶກການເຮັດທຸລະກໍາ ຜູ້ຈັດພິມການລົງຄະແນນສຽງ ວິທີ ຫມາຍເຖິງການນໍາໃຊ້ວິທີແກ້ໄຂສະເພາະຂອງຖານຂໍ້ມູນເຊັ່ນ 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(); } ບໍ່ຕ້ອງເປັນຫ່ວງ, ເນື່ອງຈາກການຊົດເຊີຍຍັງບໍ່ທັນໄດ້ສັນຍາໄວ້, ຂໍ້ຄວາມຈະຖືກລອງອີກຄັ້ງ. ຈະເປັນແນວໃດຖ້າການປຸງແຕ່ງຕາມເຫດຜົນຂອງທຸລະກິດລົ້ມເຫລວ? ບໍ່ຕ້ອງກັງວົນ, ເນື່ອງຈາກວ່າເຫດຜົນທາງທຸລະກິດແມ່ນ ideempotent, ມັນຈະບໍ່ສ້າງຄໍາຮ້ອງສະຫມັກການກູ້ຢືມເງິນຊ້ໍາກັນ. ແທນທີ່ຈະ, ມັນຈະພະຍາຍາມສົ່ງຂໍ້ຄວາມໄປຫາຫົວຂໍ້ Kafka ສາທາລະນະ. ຈະເປັນແນວໃດຖ້າການສົ່ງເຫດການໃຫມ່ໄປຫາ Kafka ລົ້ມເຫລວ? ບໍ່ຕ້ອງກັງວົນ, ເນື່ອງຈາກວ່າເຫດຜົນທາງທຸລະກິດແມ່ນ ideempotent, ມັນຈະບໍ່ສ້າງຄໍາຮ້ອງສະຫມັກການກູ້ຢືມເງິນຊ້ໍາກັນ. ແທນທີ່ຈະ, ມັນຈະສົ່ງຂໍ້ຄວາມໄປຫາຫົວຂໍ້ Kafka ສາທາລະນະແລະຫວັງວ່າຄໍາຫມັ້ນສັນຍາຊົດເຊີຍຈະປະສົບຜົນສໍາເລັດໃນເວລານີ້. ຈະເປັນແນວໃດຖ້າຂໍ້ຄວາມຖືກສົ່ງໄປຫາ Kafka, ແຕ່ການຊົດເຊີຍຄວາມລົ້ມເຫລວ? ຂໍ້ບົກຜ່ອງຕົ້ນຕໍຂອງວິທີການນີ້ປະກອບມີຄວາມສັບສົນເພີ່ມເຕີມທີ່ກ່ຽວຂ້ອງກັບຮູບແບບການຂຽນໂປລແກລມໃຫມ່, ຄວາມສອດຄ່ອງໃນທີ່ສຸດ (ເນື່ອງຈາກວ່າລູກຄ້າຈະບໍ່ຮູ້ຜົນໄດ້ຮັບທັນທີ), ແລະຄວາມຕ້ອງການສໍາລັບເຫດຜົນທາງທຸລະກິດທັງຫມົດທີ່ຈະບໍ່ມີຄວາມເຂັ້ມແຂງ. ແຫຼ່ງເຫດການ ແຫລ່ງທີ່ມາຂອງເຫດການແມ່ນຫຍັງ, ແລະມັນຈະຖືກນໍາມາໃຊ້ທີ່ນີ້ໄດ້ແນວໃດ? ແຫລ່ງທີ່ມາຂອງເຫດການແມ່ນຮູບແບບສະຖາປັດຕະຍະກຳຊອບແວທີ່ໃຊ້ເພື່ອສ້າງແບບຈໍາລອງສະຖານະຂອງລະບົບໂດຍການຈັບເອົາການປ່ຽນແປງທັງໝົດຕໍ່ກັບຂໍ້ມູນຂອງມັນເປັນຊຸດຂອງເຫດການທີ່ບໍ່ປ່ຽນແປງໄດ້. ເຫດການເຫຼົ່ານີ້ສະແດງເຖິງຄວາມຈິງ ຫຼືການຫັນປ່ຽນຂອງລັດ ແລະເປັນແຫຼ່ງຄວາມຈິງອັນດຽວສຳລັບສະຖານະປັດຈຸບັນຂອງລະບົບ. ດັ່ງນັ້ນ, ທາງດ້ານເຕັກນິກ, ໂດຍການປະຕິບັດລະບົບແຫຼ່ງເຫດການ, ພວກເຮົາມີເຫດການທັງຫມົດໃນ EventStore, ແລະ EventStore ນີ້ສາມາດຖືກນໍາໃຊ້ໂດຍຜູ້ບໍລິໂພກເປັນແຫຼ່ງດຽວຂອງຄວາມຈິງກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ. ບໍ່ຈໍາເປັນຕ້ອງມີການແກ້ໄຂຖານຂໍ້ມູນສະເພາະສໍາລັບການຕິດຕາມການປ່ຽນແປງທັງຫມົດຫຼືຄວາມກັງວົນກ່ຽວກັບການສັ່ງຊື້, ບັນຫາດຽວແມ່ນນັ່ງຢູ່ດ້ານຂ້າງອ່ານນັບຕັ້ງແຕ່ເພື່ອໃຫ້ສາມາດໄດ້ຮັບສະຖານະຕົວຈິງຂອງຫນ່ວຍງານແມ່ນຈໍາເປັນເພື່ອຫຼິ້ນຄືນເຫດການທັງຫມົດ. ສະຫຼຸບ ໃນບົດຄວາມນີ້, ພວກເຮົາໄດ້ທົບທວນຄືນວິທີການຈໍານວນຫນຶ່ງສໍາລັບການສ້າງຂໍ້ຄວາມທີ່ເຊື່ອຖືໄດ້ໃນລະບົບແຈກຢາຍ. ມີຫຼາຍຄໍາແນະນໍາທີ່ພວກເຮົາສາມາດພິຈາລະນາໃນຂະນະທີ່ການກໍ່ສ້າງລະບົບທີ່ມີລັກສະນະເຫຼົ່ານີ້ ສະເຫມີພັດທະນາຜູ້ບໍລິໂພກທີ່ບໍ່ມີທ່າແຮງນັບຕັ້ງແຕ່ຄວາມລົ້ມເຫຼວຂອງເຄືອຂ່າຍແມ່ນບໍ່ສາມາດຫຼີກເວັ້ນໄດ້. ໃຊ້ ຢ່າງລະມັດລະວັງດ້ວຍຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບຂໍ້ກໍານົດການຄໍ້າປະກັນ. First-Local-Commit-Tan-Publish ຢ່າໃຊ້ວິທີ ເພາະວ່າມັນອາດຈະເຮັດໃຫ້ຂໍ້ມູນບໍ່ສອດຄ່ອງກັນຢ່າງຮ້າຍແຮງໃນລະບົບຂອງເຈົ້າ. First-Publish-Then-Local-Commit ຖ້າການຕັດສິນໃຈທາງເລືອກຖານຂໍ້ມູນທີ່ມີຢູ່ແລ້ວອາດຈະມີການປ່ຽນແປງຫຼືຍຸດທະສາດດ້ານວິຊາການຫມາຍເຖິງການເລືອກເອົາການແກ້ໄຂການເກັບຮັກສາທີ່ດີທີ່ສຸດສໍາລັບບັນຫາ - ຢ່າສ້າງຫ້ອງສະຫມຸດຮ່ວມກັນໂດຍການຜູກມັດກັບວິທີແກ້ໄຂຖານຂໍ້ມູນເຊັ່ນ . CDC ໃຊ້ວິທີການ ເປັນການແກ້ໄຂມາດຕະຖານສໍາລັບການບັນລຸການຮັບປະກັນຢ່າງຫນ້ອຍຫນຶ່ງຄັ້ງ. Transactional Outbox ພິຈາລະນາໃຊ້ວິທີ ໃນເວລາທີ່ຖານຂໍ້ມູນ No-SQL ຖືກນໍາໃຊ້. ການຟັງຕົວເອງ ໃນຄັ້ງຕໍ່ໄປ, ພວກເຮົາຈະເບິ່ງຕົວຢ່າງການປະຕິບັດເພີ່ມເຕີມຂອງການປະຕິບັດ Transactional Outbox. ເບິ່ງ ເຈົ້າ!