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

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

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

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

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

Single Node Resilience Primitives

Resilient queing/routing

ມີສອງປະເພດຂອງຄິວໃນ RabbitMQ: ທົນທານແລະບໍ່ທົນທານ. ແຖວທັງໝົດຖືກບັນທຶກໄວ້ໃນຖານຂໍ້ມູນ Mnesia. ຄິວທີ່ທົນທານໄດ້ຖືກໂຄສະນາຄືນໃຫມ່ໃນຕອນເລີ່ມຕົ້ນຂອງ node ແລະດັ່ງນັ້ນຈຶ່ງຢູ່ລອດການ restarts, ລະບົບຂັດຂ້ອງ, ຫຼື server crash (ຕາບໃດທີ່ຂໍ້ມູນຍັງຄົງຢູ່). ນີ້ຫມາຍຄວາມວ່າຕາບໃດທີ່ທ່ານປະກາດ routing (ການແລກປ່ຽນ) ແລະຄິວທີ່ຈະທົນທານຕໍ່, ໂຄງສ້າງພື້ນຖານການຈັດແຖວ / routing ຈະກັບຄືນມາອອນໄລນ໌.

ຄິວທີ່ລະເຫີຍແລະເສັ້ນທາງຈະຖືກລຶບອອກເມື່ອໂຫນດຖືກເລີ່ມຕົ້ນໃຫມ່.

ຂໍ້ຄວາມທີ່ຍັງຄົງຄ້າງ

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

ເຂົ້າ. 1. ຕາຕະລາງຄວາມຍືນຍົງ

ການຈັດກຸ່ມດ້ວຍການສະທ້ອນແຖວ

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

ການສະທ້ອນແຖວ:

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

ເຂົ້າ. 2. ການສະທ້ອນແຖວ

ການສະທ້ອນແມ່ນຖືກກໍານົດໂດຍນະໂຍບາຍທີ່ເຫມາະສົມ. ໃນມັນທ່ານສາມາດເລືອກເອົາຄ່າສໍາປະສິດການຈໍາລອງແລະແມ້ກະທັ້ງ nodes ທີ່ແຖວຄວນຈະຕັ້ງຢູ່. ຕົວຢ່າງ:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ຫນຶ່ງຕົ້ນສະບັບແລະຫນຶ່ງກະຈົກ)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ການຢືນຢັນຜູ້ເຜີຍແຜ່

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

ຄິວທີ່ລົ້ມເຫລວ

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

ເຂົ້າ. 3. ຫຼາຍແຖວ mirrored ແລະນະໂຍບາຍຂອງເຂົາເຈົ້າ

ນາຍຫນ້າ 3 ລົງ. ໃຫ້ສັງເກດວ່າ Queue C mirror ໃນ Broker 2 ກໍາລັງຖືກສົ່ງເສີມເປັນແມ່ບົດ. ໃຫ້ສັງເກດວ່າກະຈົກໃຫມ່ໄດ້ຖືກສ້າງຂື້ນສໍາລັບ Queue C ໃນ Broker 1. RabbitMQ ສະເຫມີພະຍາຍາມຮັກສາປັດໄຈການຈໍາລອງທີ່ລະບຸໄວ້ໃນນະໂຍບາຍຂອງທ່ານ.

ເຂົ້າ. 4. ນາຍຫນ້າ 3 ລົ້ມເຫລວ, ເຮັດໃຫ້ຄິວ C ລົ້ມເຫລວ

ນາຍໜ້າ 1 ຄົນຕໍ່ໄປຕົກ! ພວກເຮົາມີນາຍຫນ້າຄົນດຽວເທົ່ານັ້ນ. ກະຈົກ Queue B ຖືກເລື່ອນເປັນແມ່ບົດ.

ຊາວ. ຫນຶ່ງ

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

ໃນກໍລະນີນີ້, ການສູນເສຍ Broker 1 ແມ່ນສົມບູນ, ເຊັ່ນດຽວກັນກັບຂໍ້ມູນ, ດັ່ງນັ້ນ Queue B ທີ່ບໍ່ມີການສະທ້ອນໄດ້ສູນເສຍຢ່າງສົມບູນ.

ເຂົ້າ. 6. ນາຍຫນ້າ 1 ກັບຄືນສູ່ການບໍລິການ

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

ເຂົ້າ. 7. ນາຍຫນ້າ 3 ກັບຄືນສູ່ການບໍລິການ. ຄິວຫຼັກທັງໝົດຢູ່ໃນໂຫນດດຽວ!

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

Syncing

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

ການຊິ້ງຂໍ້ມູນນີ້ຖືກປະຕິບັດໂດຍອັດຕະໂນມັດ ຫຼືດ້ວຍຕົນເອງ ແລະຖືກຈັດການໂດຍໃຊ້ນະໂຍບາຍຄິວ. ໃຫ້ເບິ່ງຕົວຢ່າງ.

ພວກເຮົາມີສອງແຖວ mirrored. ຄິວ A ແມ່ນ synchronized ອັດຕະໂນມັດ, ແລະ Queue B ແມ່ນ synchronized ດ້ວຍຕົນເອງ. ທັງສອງຄິວມີສິບຂໍ້ຄວາມ.

ເຂົ້າ. 8. ສອງແຖວທີ່ມີໂຫມດ synchronization ທີ່ແຕກຕ່າງກັນ

ໃນປັດຈຸບັນພວກເຮົາກໍາລັງສູນເສຍນາຍຫນ້າ 3.

ເຂົ້າ. 9. ນາຍໜ້າ 3 ຕົກ

ນາຍຫນ້າ 3 ກັບຄືນສູ່ການບໍລິການ. ກຸ່ມສ້າງກະຈົກສໍາລັບແຕ່ລະແຖວຢູ່ໃນ node ໃໝ່ ແລະ synchronize Queue A ໃໝ່ກັບແມ່ແບບໂດຍອັດຕະໂນມັດ. ຢ່າງໃດກໍຕາມ, ກະຈົກຂອງຄິວ B ໃຫມ່ຍັງຄົງຫວ່າງເປົ່າ. ດ້ວຍວິທີນີ້, ພວກເຮົາມີການຊໍ້າຊ້ອນຢູ່ໃນຄິວ A ແລະກະຈົກອັນດຽວສໍາລັບຂໍ້ຄວາມຄິວ B ທີ່ມີຢູ່ແລ້ວ.

ເຂົ້າ. 10. ກະຈົກໃຫມ່ຂອງຄິວ A ໄດ້ຮັບຂໍ້ຄວາມທີ່ມີຢູ່ທັງຫມົດ, ແຕ່ກະຈົກໃຫມ່ຂອງຄິວ B ບໍ່.

ອີກສິບຂໍ້ຄວາມມາຮອດທັງສອງຄິວ. ໂບຣກເກີ 2 ແລ້ວຂັດຂ້ອງ ແລະຄິວ A ມ້ວນກັບຄືນໄປຫາບ່ອນແລກປ່ຽນຄວາມເກົ່າແກ່ທີ່ສຸດ, ເຊິ່ງຢູ່ໃນ Broker 1. ບໍ່ມີຂໍ້ມູນສູນເສຍເມື່ອມັນລົ້ມເຫລວ. ໃນຄິວ B, ມີ XNUMX ຂໍ້ຄວາມໃນແມ່ບົດແລະມີພຽງແຕ່ສິບຂໍ້ຄວາມໃນກະຈົກເພາະວ່າຄິວນີ້ບໍ່ເຄີຍ replicated ສິບຂໍ້ຄວາມຕົ້ນສະບັບ.

ເຂົ້າ. 11. ຄິວ A ກັບຄືນໄປຫາ Broker 1 ໂດຍບໍ່ມີການສູນເສຍຂໍ້ຄວາມ

ອີກສິບຂໍ້ຄວາມມາຮອດທັງສອງຄິວ. ຕອນນີ້ Broker 1 crashes Queue A ປ່ຽນໄປບ່ອນກະຈົກໄດ້ຢ່າງງ່າຍດາຍໂດຍບໍ່ສູນເສຍຂໍ້ຄວາມ. ຢ່າງໃດກໍ່ຕາມ, ຄິວ B ມີບັນຫາ. ໃນຈຸດນີ້, ພວກເຮົາສາມາດປັບປຸງຄວາມພ້ອມຫຼືຄວາມສອດຄ່ອງ.

ຖ້າພວກເຮົາຕ້ອງການເພີ່ມປະສິດທິພາບການເຂົ້າເຖິງ, ຫຼັງຈາກນັ້ນນະໂຍບາຍ ha-promote-on-failure ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ​ຕິດ​ຕັ້ງ​ໃນ​ ສະເຫມີໄປ. ນີ້ແມ່ນຄ່າເລີ່ມຕົ້ນ, ສະນັ້ນທ່ານບໍ່ສາມາດລະບຸນະໂຍບາຍໄດ້. ໃນ​ກໍ​ລະ​ນີ​ນີ້, ພວກ​ເຮົາ​ເປັນ​ສິ່ງ​ຈໍາ​ເປັນ​ທີ່​ຈະ​ໃຫ້​ຄວາມ​ລົ້ມ​ເຫຼວ​ໃນ​ກະ​ຈົກ unsynchronized. ນີ້ຈະເຮັດໃຫ້ຂໍ້ຄວາມສູນເສຍ, ແຕ່ແຖວຈະຍັງຄົງອ່ານໄດ້ແລະຂຽນໄດ້.

ເຂົ້າ. 12. ຄິວ A ຖືກມ້ວນກັບຄືນໄປຫາ Broker 3 ໂດຍບໍ່ສູນເສຍຂໍ້ຄວາມ. ຄິວ B ກັບຄືນໄປຫາ Broker 3 ດ້ວຍສິບຂໍ້ຄວາມທີ່ສູນເສຍໄປ

ພວກເຮົາຍັງສາມາດຕິດຕັ້ງໄດ້ ha-promote-on-failure ເຂົ້າໄປໃນຄວາມຫມາຍ when-synced. ໃນກໍລະນີນີ້, ແທນທີ່ຈະມ້ວນກັບຄືນໄປບ່ອນກະຈົກ, ແຖວຈະລໍຖ້າຈົນກ່ວາ Broker 1 ກັບຂໍ້ມູນຂອງມັນກັບຄືນສູ່ໂຫມດອອນໄລນ໌. ຫຼັງຈາກທີ່ມັນກັບຄືນມາ, ຄິວຕົ້ນຕໍແມ່ນກັບມາຢູ່ໃນ Broker 1 ໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນໃດໆ. ຄວາມພ້ອມແມ່ນເສຍສະລະເພື່ອຄວາມປອດໄພຂອງຂໍ້ມູນ. ແຕ່ນີ້ແມ່ນຮູບແບບທີ່ມີຄວາມສ່ຽງທີ່ເຖິງແມ່ນວ່າສາມາດນໍາໄປສູ່ການສູນເສຍຂໍ້ມູນທີ່ສົມບູນ, ເຊິ່ງພວກເຮົາຈະເບິ່ງໃນໄວໆນີ້.

ເຂົ້າ. 13. ຄິວ B ຍັງບໍ່ສາມາດໃຊ້ໄດ້ຫຼັງຈາກສູນເສຍນາຍໜ້າ 1

ທ່ານອາດຈະຖາມວ່າ, "ມັນດີກວ່າທີ່ຈະບໍ່ເຄີຍໃຊ້ synchronization ອັດຕະໂນມັດບໍ?" ຄໍາຕອບແມ່ນວ່າ synchronization ແມ່ນການດໍາເນີນງານສະກັດ. ໃນລະຫວ່າງການ synchronization, ແຖວຕົ້ນຕໍບໍ່ສາມາດດໍາເນີນການອ່ານຫຼືຂຽນໃດໆ!

ໃຫ້ເບິ່ງຕົວຢ່າງ. ໃນປັດຈຸບັນພວກເຮົາມີຄິວຍາວຫຼາຍ. ພວກເຂົາສາມາດເຕີບໂຕໄດ້ຂະຫນາດດັ່ງກ່າວໄດ້ແນວໃດ? ດ້ວຍເຫດຜົນຫຼາຍຢ່າງ:

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

ເຂົ້າ. 14. ສອງແຖວຂະຫນາດໃຫຍ່ທີ່ມີໂຫມດ synchronization ທີ່ແຕກຕ່າງກັນ

ໃນປັດຈຸບັນ Broker 3 ຕົກ.

ເຂົ້າ. 15. ນາຍຫນ້າ 3 ຕົກ, ປ່ອຍໃຫ້ຫນຶ່ງຕົ້ນສະບັບແລະກະຈົກໃນແຕ່ລະແຖວ

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

ຢ່າງໃດກໍ່ຕາມ, ຄິວ B ຍັງມີຢູ່ຕະຫຼອດໄລຍະເວລາທັງໝົດ. ນາງໄດ້ເສຍສະລະການຊໍ້າຊ້ອນບາງຢ່າງສໍາລັບການເຂົ້າເຖິງ.

ເຂົ້າ. 16. ຄິວຍັງບໍ່ມີຢູ່ໃນລະຫວ່າງການ synchronization

ຫຼັງຈາກສອງຊົ່ວໂມງ, ຄິວ A ກໍ່ມີຢູ່ ແລະສາມາດເລີ່ມຮັບການອ່ານ ແລະ ຂຽນອີກຄັ້ງ.

ການປັບປຸງ

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

• always= ການຫັນປ່ຽນໄປສູ່ກະຈົກທີ່ບໍ່ synchronized ຖືກເປີດໃຊ້
• when-synced= ການຫັນປ່ຽນໄປຫາບ່ອນແລກປ່ຽນຄວາມກົງກັນເທົ່ານັ້ນ, ຖ້າບໍ່ດັ່ງນັ້ນຄິວຈະກາຍເປັນອ່ານບໍ່ໄດ້ ແລະຂຽນບໍ່ໄດ້. ຄິວກັບຄືນສູ່ການບໍລິການທັນທີທີ່ນາຍຫນ້າກັບຄືນມາ

ທາງໜຶ່ງຫຼືທາງອື່ນ, ດ້ວຍຄິວໃຫຍ່ເຈົ້າຕ້ອງເລືອກລະຫວ່າງການສູນເສຍຂໍ້ມູນ ແລະ ຄວາມບໍ່ພ້ອມ.

ເມື່ອມີໃຫ້ປັບປຸງຄວາມປອດໄພຂອງຂໍ້ມູນ

ມີ​ອີກ​ອັນ​ໜຶ່ງ​ທີ່​ຕ້ອງ​ພິຈາລະນາ​ກ່ອນ​ການ​ຕັດສິນ​ໃຈ. ໃນຂະນະທີ່ການ synchronization ອັດຕະໂນມັດແມ່ນດີກວ່າສໍາລັບການຊ້ໍາຊ້ອນ, ມັນມີຜົນກະທົບຕໍ່ຄວາມປອດໄພຂອງຂໍ້ມູນແນວໃດ? ແນ່ນອນ, ດ້ວຍການຊໍ້າຊ້ອນທີ່ດີກວ່າ, RabbitMQ ມີໂອກາດຫນ້ອຍທີ່ຈະສູນເສຍຂໍ້ຄວາມທີ່ມີຢູ່, ແຕ່ວ່າຂໍ້ຄວາມໃຫມ່ຈາກຜູ້ເຜີຍແຜ່ແມ່ນຫຍັງ?

ທີ່ນີ້ທ່ານຈໍາເປັນຕ້ອງພິຈາລະນາດັ່ງຕໍ່ໄປນີ້:

• ຜູ້ເຜີຍແພ່ສາມາດສົ່ງຄືນຄວາມຜິດພາດໄດ້ ແລະໃຫ້ການບໍລິການຂັ້ນຕົ້ນ ຫຼືຜູ້ໃຊ້ພະຍາຍາມອີກຄັ້ງໃນພາຍຫຼັງບໍ?
• ຜູ້ເຜີຍແຜ່ສາມາດບັນທຶກຂໍ້ຄວາມຢູ່ໃນທ້ອງຖິ່ນຫຼືໃນຖານຂໍ້ມູນເພື່ອລອງໃໝ່ໃນພາຍຫຼັງບໍ?

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

ດັ່ງນັ້ນ, ການດຸ່ນດ່ຽງຕ້ອງໄດ້ຮັບການຊອກຫາ, ແລະການແກ້ໄຂແມ່ນຂຶ້ນກັບສະຖານະການສະເພາະ.

ມີບັນຫາກັບ ha-promote-on-failure=when-synced

Idea ha-promote-on-failure= ເມື່ອຊິ້ງແລ້ວ ແມ່ນວ່າພວກເຮົາປ້ອງກັນບໍ່ໃຫ້ປ່ຽນໄປເປັນບ່ອນແລກປ່ຽນຄວາມທີ່ບໍ່ synchronized ແລະດັ່ງນັ້ນຈຶ່ງຫຼີກເວັ້ນການສູນເສຍຂໍ້ມູນ. ຄິວຍັງບໍ່ສາມາດອ່ານໄດ້ ຫຼືຂຽນບໍ່ໄດ້. ແທນທີ່ຈະ, ພວກເຮົາພະຍາຍາມຟື້ນຕົວນາຍຫນ້າທີ່ລົ້ມລົງດ້ວຍຂໍ້ມູນຂອງມັນ intact ເພື່ອໃຫ້ມັນສາມາດສືບຕໍ່ເຮັດວຽກເປັນແມ່ແບບໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນ.

ແຕ່ (ແລະນີ້ແມ່ນໃຫຍ່ແຕ່) ຖ້ານາຍຫນ້າໄດ້ສູນເສຍຂໍ້ມູນຂອງລາວ, ແລ້ວພວກເຮົາມີບັນຫາໃຫຍ່: ແຖວຈະສູນເສຍ! ຂໍ້ມູນທັງໝົດໝົດແລ້ວ! ເຖິງແມ່ນວ່າເຈົ້າມີກະຈົກທີ່ສ່ວນໃຫຍ່ຈັບໄດ້ກັບແຖວຫຼັກ, ກະຈົກເຫຼົ່ານັ້ນກໍ່ຖືກຍົກເລີກເຊັ່ນກັນ.

ເພື່ອເພີ່ມ node ທີ່ມີຊື່ດຽວກັນ, ພວກເຮົາບອກ cluster ໃຫ້ລືມ node ທີ່ສູນເສຍ (ດ້ວຍຄໍາສັ່ງ. rabbitmqctl forget_cluster_node) ແລະເລີ່ມຕົ້ນນາຍຫນ້າໃຫມ່ທີ່ມີຊື່ເຈົ້າພາບດຽວກັນ. ໃນຂະນະທີ່ cluster ຈື່ node ທີ່ສູນເສຍໄປ, ມັນຈື່ຄິວເກົ່າແລະກະຈົກ unsynchronized. ເມື່ອກຸ່ມຖືກບອກໃຫ້ລືມຂໍ້ທີ່ກຳພ້າ, ແຖວນັ້ນຖືກລືມເຊັ່ນກັນ. ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງປະກາດມັນໃຫມ່. ພວກເຮົາສູນເສຍຂໍ້ມູນທັງຫມົດ, ເຖິງແມ່ນວ່າພວກເຮົາມີບ່ອນແລກປ່ຽນຄວາມກັບຊຸດຂໍ້ມູນບາງສ່ວນ. ມັນຈະເປັນການດີກວ່າທີ່ຈະປ່ຽນເປັນກະຈົກທີ່ບໍ່ synchronized!

ດັ່ງນັ້ນ, synchronization ຄູ່ມື (ແລະຄວາມລົ້ມເຫຼວທີ່ຈະ synchronize) ໃນການປະສົມປະສານກັບ ha-promote-on-failure=when-synced, ໃນຄວາມຄິດເຫັນຂອງຂ້າພະເຈົ້າ, ຂ້ອນຂ້າງມີຄວາມສ່ຽງ. ເອກະສານບອກວ່າທາງເລືອກນີ້ມີຢູ່ສໍາລັບຄວາມປອດໄພຂອງຂໍ້ມູນ, ແຕ່ມັນເປັນມີດສອງດ້ານ.

ການດຸ່ນດ່ຽງຕົ້ນສະບັບ

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

Rebalancing masters ສາມາດມີບັນຫາສໍາລັບສອງເຫດຜົນ:

• ບໍ່ມີເຄື່ອງມືທີ່ດີເພື່ອປະຕິບັດການດຸ່ນດ່ຽງຄືນໃຫມ່
• ການຊິ້ງຂໍ້ມູນຄິວ

ມີພາກສ່ວນທີສາມສໍາລັບການດຸ່ນດ່ຽງ plugin, ເຊິ່ງບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຢ່າງເປັນທາງການ. ກ່ຽວກັບ plugins ຂອງພາກສ່ວນທີສາມໃນຄູ່ມື RabbitMQ ກ່າວ: “ປລັກອິນໃຫ້ບາງການຕັ້ງຄ່າເພີ່ມເຕີມ ແລະເຄື່ອງມືລາຍງານ, ແຕ່ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ ຫຼືກວດສອບໂດຍທີມງານ RabbitMQ. ໃຊ້ໃນຄວາມສ່ຽງຂອງທ່ານເອງ."

ມີເຄັດລັບອື່ນເພື່ອຍ້າຍແຖວຫຼັກຜ່ານນະໂຍບາຍ HA. ຄູ່ມືກ່າວເຖິງ ສະຄຣິບ ສໍາລັບການນີ້. ມັນເຮັດວຽກແບບນີ້:

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

ຂໍ້ເສຍແມ່ນວ່າວິທີການນີ້ອາດຈະບໍ່ເຮັດວຽກຖ້າທ່ານມີແຖວຂະຫນາດໃຫຍ່ຫຼືຄວາມຕ້ອງການຊ້ໍາຊ້ອນທີ່ເຄັ່ງຄັດ.

ຕອນນີ້ໃຫ້ເບິ່ງວິທີການກຸ່ມ RabbitMQ ເຮັດວຽກກັບການແບ່ງປັນເຄືອຂ່າຍ.

ການສູນເສຍການເຊື່ອມຕໍ່

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

ດ້ວຍ RabbitMQ ພວກເຮົາມີສອງທາງເລືອກຕົ້ນຕໍ:

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

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

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

ຖ້າຜູ້ເຜີຍແຜ່ສົ່ງຂໍ້ມູນໄປຫາແມ່ບົດທັງສອງ, ພວກເຮົາສິ້ນສຸດດ້ວຍສອງສໍາເນົາທີ່ແຕກຕ່າງກັນຂອງແຖວ.

ໂຫມດທີ່ແຕກຕ່າງກັນຂອງ RabbitMQ ສະຫນອງຄວາມພ້ອມຫຼືຄວາມສອດຄ່ອງ.

ໂໝດບໍ່ສົນໃຈ (ຄ່າເລີ່ມຕົ້ນ)

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

ເຂົ້າ. 18. ສາມຜູ້ເຜີຍແຜ່ກ່ຽວຂ້ອງກັບສາມນາຍຫນ້າ. ພາຍໃນ, ກຸ່ມດັ່ງກ່າວສົ່ງເສັ້ນທາງການຮ້ອງຂໍທັງຫມົດໄປຫາແຖວຕົ້ນຕໍໃນ Broker 2.

ໃນປັດຈຸບັນພວກເຮົາກໍາລັງສູນເສຍນາຍຫນ້າ 3. ລາວເຫັນວ່ານາຍຫນ້າອື່ນໆໄດ້ຫຼຸດລົງແລະສົ່ງເສີມກະຈົກຂອງລາວໃຫ້ກັບນາຍຫນ້າ. ນີ້ແມ່ນວິທີການແຍກເຫດຜົນເກີດຂຶ້ນ.

ເຂົ້າ. 19. ການແບ່ງຕາມເຫດຜົນ (split-brain). ບັນທຶກເຂົ້າໄປໃນສອງແຖວຕົ້ນຕໍ, ແລະສອງສໍາເນົາ diverge.

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

ເຂົ້າ. 20. ຜູ້ບໍລິຫານປິດການໃຊ້ງານ Broker 3.

ເຂົ້າ. 21. ຜູ້ບໍລິຫານເລີ່ມ Broker 3 ແລະມັນເຂົ້າຮ່ວມກຸ່ມ, ສູນເສຍຂໍ້ຄວາມທັງຫມົດທີ່ປະໄວ້.

ໃນລະຫວ່າງການສູນເສຍການເຊື່ອມຕໍ່ແລະຫຼັງຈາກການຟື້ນຟູຂອງມັນ, ກຸ່ມແລະແຖວນີ້ສາມາດໃຊ້ໄດ້ສໍາລັບການອ່ານແລະຂຽນ.

ໂໝດ Autoheal

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

ຢຸດໂໝດຊົນເຜົ່າສ່ວນໜ້ອຍຊົ່ວຄາວ

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

ເຂົ້າ. 22. ສາມຜູ້ເຜີຍແຜ່ກ່ຽວຂ້ອງກັບສາມນາຍຫນ້າ. ພາຍໃນ, ກຸ່ມດັ່ງກ່າວສົ່ງເສັ້ນທາງການຮ້ອງຂໍທັງຫມົດໄປຫາແຖວຕົ້ນຕໍໃນ Broker 2.

ໂບຣກເກີ 1 ແລະ 2 ຈາກນັ້ນແຍກອອກຈາກນາຍໜ້າ 3. ແທນທີ່ຈະສົ່ງເສີມບ່ອນແລກປ່ຽນຄວາມເປັນແມ່ແບບ, ໂບຣກເກີ 3 ຈະໂຈະ ແລະກາຍເປັນບໍ່ສາມາດໃຊ້ໄດ້.

ເຂົ້າ. 23. ນາຍຫນ້າ 3 ຢຸດຊົ່ວຄາວ, ຕັດການເຊື່ອມຕໍ່ລູກຄ້າທັງຫມົດ, ແລະປະຕິເສດການຮ້ອງຂໍການເຊື່ອມຕໍ່.

ເມື່ອການເຊື່ອມຕໍ່ຖືກຟື້ນຟູ, ມັນຈະກັບຄືນໄປຫາກຸ່ມ.

ໃຫ້ເບິ່ງຕົວຢ່າງອື່ນທີ່ແຖວຕົ້ນຕໍແມ່ນຢູ່ໃນ Broker 3.

ເຂົ້າ. 24. ແຖວຫຼັກ 3 ນາຍໜ້າ.

ຫຼັງຈາກນັ້ນ, ການສູນເສຍການເຊື່ອມຕໍ່ດຽວກັນເກີດຂຶ້ນ. ໂບຣກເກີ 3 ຢຸດຊົ່ວຄາວ ເພາະວ່າມັນຢູ່ໃນດ້ານນ້ອຍກວ່າ. ໃນອີກດ້ານຫນຶ່ງ, nodes ເຫັນວ່າ Broker 3 ໄດ້ຫຼຸດລົງ, ດັ່ງນັ້ນກະຈົກທີ່ເກົ່າແກ່ຈາກ Brokers 1 ແລະ 2 ຖືກສົ່ງເສີມເປັນແມ່ບົດ.

ເຂົ້າ. 25. ການຫັນປ່ຽນໄປສູ່ນາຍໜ້າ 2 ຖ້ານາຍໜ້າ 3 ບໍ່ສາມາດໃຊ້ໄດ້.

ເມື່ອການເຊື່ອມຕໍ່ຖືກຟື້ນຟູ, Broker 3 ຈະເຂົ້າຮ່ວມກຸ່ມ.

ເຂົ້າ. 26. ກຸ່ມໄດ້ກັບຄືນສູ່ການເຮັດວຽກປົກກະຕິ.

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

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

ຮັບປະກັນການເຊື່ອມຕໍ່ລູກຄ້າ

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

ທາງ​ເລືອກ​ຂອງ​ພວກ​ເຮົາ​:

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

ການຄົ້ນພົບ

RabbitMQ clustering ມີຂໍ້ດີແລະຂໍ້ເສຍຂອງມັນ. ຂໍ້ເສຍທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນວ່າ:

• ເມື່ອເຂົ້າຮ່ວມກຸ່ມ, nodes ຍົກເລີກຂໍ້ມູນຂອງເຂົາເຈົ້າ;
• ການຂັດຂວາງການ synchronization ເຮັດໃຫ້ແຖວບໍ່ສາມາດໃຊ້ໄດ້.

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

• ເຄືອຂ່າຍທີ່ບໍ່ຫນ້າເຊື່ອຖື.
• ການເກັບຮັກສາທີ່ບໍ່ຫນ້າເຊື່ອຖື.
• ຄິວຍາວຫຼາຍ.

ເມື່ອມັນມາກັບການຕັ້ງຄ່າທີ່ມີໃຫ້ສູງ, ໃຫ້ພິຈາລະນາຕໍ່ໄປນີ້:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ຫຼື autoheal)
• ຂໍ້​ຄວາມ​ທີ່​ຍັງ​ຄົງ​ຄ້າງ​
• ໃຫ້ແນ່ໃຈວ່າລູກຄ້າເຊື່ອມຕໍ່ກັບ node ທີ່ໃຊ້ວຽກໃນເວລາທີ່ບາງ node ລົ້ມເຫລວ

ເພື່ອຄວາມສອດຄ່ອງ (ຄວາມປອດໄພຂອງຂໍ້ມູນ), ພິຈາລະນາການຕັ້ງຄ່າຕໍ່ໄປນີ້:

• Publisher ຢືນຢັນແລະຄູ່ມືການຮັບຮູ້ໃນຝ່າຍຜູ້ບໍລິໂພກ
• ha-promote-on-failure=when-synced, ຖ້າຜູ້ເຜີຍແຜ່ສາມາດລອງໃໝ່ໃນພາຍຫຼັງ ແລະຖ້າທ່ານມີບ່ອນເກັບຂໍ້ມູນທີ່ເຊື່ອຖືໄດ້ຫຼາຍ! ຖ້າບໍ່ດັ່ງນັ້ນໃສ່ =always.
• ha-sync-mode=automatic (ແຕ່ສໍາລັບຮູບແບບຄູ່ມືຄິວທີ່ບໍ່ເຄື່ອນໄຫວຂະຫນາດໃຫຍ່ອາດຈະຕ້ອງການ; ຍັງພິຈາລະນາວ່າຄວາມບໍ່ມີຢູ່ຈະເຮັດໃຫ້ຂໍ້ຄວາມສູນເສຍ)
• ຢຸດໂໝດຊົນເຜົ່າສ່ວນໜ້ອຍຊົ່ວຄາວ
• ຂໍ້​ຄວາມ​ທີ່​ຍັງ​ຄົງ​ຄ້າງ​

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

ຖ້າຂ້ອຍພາດຫຍັງອີກ, ກະລຸນາແຈ້ງໃຫ້ຂ້ອຍຮູ້.

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

ບົດຄວາມທີ່ຜ່ານມາໃນຊຸດ:
ອັນດັບ 1 - habr.com/ru/company/itsumma/blog/416629
ອັນດັບ 2 - habr.com/ru/company/itsumma/blog/418389
ອັນດັບ 3 - habr.com/ru/company/itsumma/blog/437446

ແຫຼ່ງຂໍ້ມູນ: www.habr.com