ແຈກຢາຍການລັອກໂດຍໃຊ້ Redis

Hey Habr!

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

locking ແຈກຢາຍແມ່ນເປັນ primitive ທີ່ເປັນປະໂຫຍດຫຼາຍທີ່ໃຊ້ໃນຫຼາຍສະພາບແວດລ້ອມທີ່ຂະບວນການທີ່ແຕກຕ່າງກັນຕ້ອງເຮັດວຽກກ່ຽວກັບຊັບພະຍາກອນຮ່ວມກັນໃນລັກສະນະສະເພາະເຊິ່ງກັນແລະກັນ.

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

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

ການຈັດຕັ້ງປະຕິບັດ

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

• Redlock-rb (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ Ruby). ຍັງມີ ສ້ອມ Redlock-rb, ເຊິ່ງເພີ່ມຊຸດ (ແກ້ວປະເສີດ) ສໍາລັບຄວາມງ່າຍຂອງການແຈກຢາຍ, ແລະບໍ່ພຽງແຕ່ສໍາລັບການນັ້ນ.
• Redlock-py (ການປະຕິບັດ Python).
• Aioredlock (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ Asyncio Python).
• Redlock-php (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ PHP).
• PHPRedisMutex (ການ​ປະ​ຕິ​ບັດ​ອື່ນ​ສໍາ​ລັບ PHP​)
• cheprasov/php-redis-lock (ຫໍສະຫມຸດ PHP ສໍາລັບລັອກ)
• Redsync (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ Go).
• ທົບທວນຄືນ (ການ​ປະ​ຕິ​ບັດ​ສໍາ​ລັບ Java​)​.
• Redis::DistLock (ການ​ປະ​ຕິ​ບັດ​ສໍາ​ລັບ Perl​)​.
• Redlock-cpp (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ C++).
• Redlock-cs (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ C#/.NET).
• RedLock.net (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ C#/.NET). ດ້ວຍການສະຫນັບສະຫນູນ async ແລະ lock extensions.
• ScarletLock (ການ​ປະ​ຕິ​ບັດ​ສໍາ​ລັບ C# .NET ກັບ​ການ​ເກັບ​ຮັກ​ສາ​ຂໍ້​ມູນ​ການ​ຕັ້ງ​ຄ່າ​)
• Redlock4Net (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ C# .NET)
• node-redlock (ການຈັດຕັ້ງປະຕິບັດສໍາລັບ NodeJS). ປະກອບມີການສະຫນັບສະຫນູນສໍາລັບການຂະຫຍາຍ locks.

ຮັບປະກັນຄວາມປອດໄພ ແລະຄວາມພ້ອມ

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

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

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

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

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

ແນ່ນອນ, ໃນຮູບແບບດັ່ງກ່າວ, ສະພາບການແຂ່ງຂັນເກີດຂື້ນ:

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

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

ການປະຕິບັດທີ່ຖືກຕ້ອງດ້ວຍຕົວຢ່າງດຽວ

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

ເພື່ອ​ໄດ້​ຮັບ lock ໄດ້​, ເຮັດ​ແນວ​ນີ້​:

SET resource_name my_random_value NX PX 30000

ຄໍາສັ່ງນີ້ຕິດຕັ້ງລະຫັດພຽງແຕ່ຖ້າມັນບໍ່ມີຢູ່ແລ້ວ (ທາງເລືອກ NX), ໄລຍະເວລາທີ່ຖືກຕ້ອງແມ່ນ 30000 milliseconds (ທາງເລືອກ PX). ລະຫັດຖືກຕັ້ງເປັນ “myrandomvalue" ຄ່ານີ້ຈະຕ້ອງບໍ່ຊໍ້າກັນໃນທຸກລູກຄ້າ ແລະທຸກຄໍາຮ້ອງຂໍລັອກ.
ໂດຍພື້ນຖານແລ້ວ, ຄ່າແບບສຸ່ມແມ່ນໃຊ້ເພື່ອປົດລ໋ອກຢ່າງປອດໄພ, ໂດຍມີສະຄຣິບບອກ Redis: ພຽງແຕ່ເອົາກະແຈອອກຖ້າມັນມີຢູ່ ແລະມູນຄ່າທີ່ເກັບໄວ້ໃນນັ້ນແມ່ນຕາມທີ່ຄາດໄວ້. ນີ້ແມ່ນບັນລຸໄດ້ໂດຍໃຊ້ຕົວອັກສອນ Lua ຕໍ່ໄປນີ້:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

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

ສະຕິງແບບສຸ່ມນີ້ຄວນຈະເປັນແນວໃດ? ຂ້ອຍຄາດເດົາວ່າມັນຄວນຈະເປັນ 20 bytes ຈາກ /dev/urandom, ແຕ່ເຈົ້າສາມາດຊອກຫາວິທີທີ່ມີລາຄາແພງຫນ້ອຍເພື່ອເຮັດໃຫ້ສະຕຣິງເປັນເອກະລັກພຽງພໍສໍາລັບຈຸດປະສົງຂອງເຈົ້າ. ຕົວຢ່າງ, ມັນຈະເປັນການດີທີ່ຈະແກ່ນ RC4 ກັບ /dev/urandom ແລະຫຼັງຈາກນັ້ນສ້າງກະແສ pseudo-random ຈາກມັນ. ການແກ້ໄຂທີ່ງ່າຍກວ່າປະກອບມີການລວມເວລາ unix ໃນຄວາມລະອຽດໄມໂຄຣວິນາທີບວກກັບ ID ລູກຄ້າ; ມັນບໍ່ປອດໄພເທົ່າທີ່ຄວນ, ແຕ່ມັນອາດຈະຂຶ້ນກັບວຽກງານໃນສະພາບການສ່ວນໃຫຍ່.

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

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

ສູດການຄິດໄລ່ Redlock

ສະບັບທີ່ແຈກຢາຍຂອງ algorithm ຖືວ່າພວກເຮົາມີ N Redis masters. nodes ເຫຼົ່ານີ້ແມ່ນເປັນເອກະລາດຢ່າງສົມບູນຂອງກັນແລະກັນ, ດັ່ງນັ້ນພວກເຮົາບໍ່ໄດ້ນໍາໃຊ້ replication ຫຼືລະບົບການປະສານງານ implicit ອື່ນໆ. ພວກ​ເຮົາ​ໄດ້​ກວມ​ເອົາ​ແລ້ວ​ວິ​ທີ​ການ​ທີ່​ຈະ​ໄດ້​ຮັບ​ຢ່າງ​ປອດ​ໄພ​ແລະ​ການ​ປົດ​ລັອກ​ໃນ​ຕົວ​ຢ່າງ​ດຽວ​. ພວກເຮົາຍອມຮັບວ່າ algorithm, ເມື່ອເຮັດວຽກກັບຕົວຢ່າງດຽວ, ຈະໃຊ້ວິທີນີ້ແທ້ໆ. ໃນຕົວຢ່າງຂອງພວກເຮົາພວກເຮົາກໍານົດ N ກັບ 5, ເຊິ່ງເປັນມູນຄ່າທີ່ສົມເຫດສົມຜົນ. ດັ່ງນັ້ນ, ພວກເຮົາຈະຕ້ອງໃຊ້ 5 Redis masters ໃນຄອມພິວເຕີຫຼືເຄື່ອງ virtual ທີ່ແຕກຕ່າງກັນເພື່ອຮັບປະກັນວ່າພວກເຂົາປະຕິບັດເປັນເອກະລາດຂອງກັນແລະກັນ.

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

1. ໄດ້ຮັບເວລາປະຈຸບັນເປັນ milliseconds.
2. ພະຍາຍາມຕາມລໍາດັບເພື່ອໃຫ້ໄດ້ລັອກຢູ່ໃນທຸກກໍລະນີ N, ໂດຍໃຊ້ຊື່ຄີດຽວກັນ ແລະຄ່າສຸ່ມໃນທຸກກໍລະນີ. ໃນຂັ້ນຕອນທີ 2, ເມື່ອລູກຄ້າຕັ້ງ lock ບົນພື້ນຖານຕໍ່ຕົວຢ່າງ, ລູກຄ້າໃຊ້ຄວາມລ່າຊ້າເພື່ອໃຫ້ໄດ້ມາມັນສັ້ນພຽງພໍເມື່ອທຽບໃສ່ກັບເວລາທີ່ລັອກຈະຖືກປ່ອຍອອກມາໂດຍອັດຕະໂນມັດ. ຕົວຢ່າງ, ຖ້າໄລຍະເວລາການຂັດຂວາງແມ່ນ 10 ວິນາທີ, ຫຼັງຈາກນັ້ນ, ຄວາມລ່າຊ້າອາດຈະຢູ່ໃນລະດັບຂອງ ~ 5-50 ມິນລິວິນາທີ. ນີ້ກໍາຈັດສະຖານະການທີ່ລູກຄ້າສາມາດຖືກບລັອກເປັນເວລາດົນນານເພື່ອພະຍາຍາມເຂົ້າຫາໂຫນດ Redis ທີ່ລົ້ມເຫລວ: ຖ້າຕົວຢ່າງບໍ່ສາມາດໃຊ້ໄດ້, ພວກເຮົາພະຍາຍາມເຊື່ອມຕໍ່ກັບຕົວຢ່າງອື່ນໄວເທົ່າທີ່ຈະໄວໄດ້.
3. ເພື່ອເອົາ lock, ລູກຄ້າຄິດໄລ່ວ່າເວລາຜ່ານໄປເທົ່າໃດ; ເພື່ອເຮັດສິ່ງນີ້, ມັນຫັກອອກຈາກມູນຄ່າເວລາທີ່ແທ້ຈິງຂອງເວລາທີ່ໄດ້ຮັບໃນຂັ້ນຕອນທີ 1. ຖ້າແລະພຽງແຕ່ຖ້າລູກຄ້າສາມາດໄດ້ຮັບ lock ໃນສ່ວນໃຫຍ່ຂອງຕົວຢ່າງ (ຢ່າງຫນ້ອຍ 3), ແລະເວລາທັງຫມົດທີ່ມັນໃຊ້ເວລາ. ໄດ້​ຮັບ lock ໄດ້​, ຫນ້ອຍ​ກ​່​ວາ​ໄລ​ຍະ​ເວ​ລາ lock ໄດ້​, lock ໄດ້​ຖືກ​ພິ​ຈາ​ລະ​ນາ​ໄດ້​ຮັບ​.
4. ຖ້າໄດ້ມາລັອກ, ໄລຍະເວລາລັອກຈະຖືກເອົາມາເປັນໄລຍະເວລາລັອກຕົ້ນສະບັບລົບກັບເວລາທີ່ຜ່ານໄປທີ່ຄິດໄລ່ໃນຂັ້ນຕອນທີ 3.
5. ຖ້າລູກຄ້າບໍ່ໄດ້ຮັບລັອກດ້ວຍເຫດຜົນບາງຢ່າງ (ມັນບໍ່ສາມາດລັອກ N/2+1 instances, ຫຼືໄລຍະເວລາລັອກເປັນລົບ), ຫຼັງຈາກນັ້ນມັນຈະພະຍາຍາມປົດລັອກທຸກຕົວຢ່າງ (ເຖິງແມ່ນວ່າມັນຄິດວ່າມັນບໍ່ສາມາດບລັອກໄດ້. ).

ສູດການຄິດໄລ່ບໍ່ກົງກັນບໍ?

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

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

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

ລອງໃຊ້ຄວາມລົ້ມເຫລວອີກຄັ້ງ

ເມື່ອລູກຄ້າບໍ່ໄດ້ຮັບ lock, ມັນຕ້ອງພະຍາຍາມອີກເທື່ອຫນຶ່ງຫຼັງຈາກການຊັກຊ້າແບບສຸ່ມ; ນີ້ແມ່ນເຮັດເພື່ອ de-synchronize ລູກຄ້າຫຼາຍຄົນທີ່ພະຍາຍາມທີ່ຈະໄດ້ຮັບ lock ໃນຊັບພະຍາກອນດຽວກັນໃນເວລາດຽວກັນ (ເຊິ່ງສາມາດນໍາໄປສູ່ສະຖານະການ "split-brain" ທີ່ບໍ່ມີຜູ້ຊະນະ). ນອກຈາກນັ້ນ, ເມື່ອລູກຄ້າພະຍາຍາມຫາຕົວລັອກໃນກໍລະນີ Redis ສ່ວນໃຫຍ່, ປ່ອງຢ້ຽມທີ່ແຄບກວ່າທີ່ສະຖານະການສະຫມອງສາມາດເກີດຂື້ນໄດ້ (ແລະຫນ້ອຍລົງ, ຕ້ອງການການພະຍາຍາມໃຫມ່). ດັ່ງນັ້ນ, ໂດຍວິທີທາງການ, ລູກຄ້າຄວນພະຍາຍາມສົ່ງຄໍາສັ່ງ SET ໄປຫາ N instances ພ້ອມກັນໂດຍໃຊ້ multiplexing.

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

ປ່ອຍ lock ໄດ້

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

ການພິຈາລະນາຄວາມປອດໄພ

ສູດການຄິດໄລ່ປອດໄພບໍ? ໃຫ້ພະຍາຍາມຈິນຕະນາການສິ່ງທີ່ເກີດຂື້ນໃນສະຖານະການທີ່ແຕກຕ່າງກັນ.

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ໃຫ້ສົມມຸດວ່າລູກຄ້າສາມາດໄດ້ຮັບ lock ໃນສ່ວນໃຫຍ່ຂອງຕົວຢ່າງ. ແຕ່ລະຕົວຢ່າງຈະມີລະຫັດທີ່ມີອາຍຸດຽວກັນສໍາລັບທຸກຄົນ. ຢ່າງໃດກໍຕາມ, ແຕ່ລະກະແຈເຫຼົ່ານີ້ໄດ້ຖືກຕິດຕັ້ງໃນເວລາທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນພວກມັນຈະຫມົດອາຍຸໃນເວລາທີ່ແຕກຕ່າງກັນ. ແຕ່, ຖ້າກະແຈທໍາອິດຖືກຕິດຕັ້ງໃນເວລາບໍ່ຮ້າຍແຮງກວ່າ T1 (ເວລາທີ່ພວກເຮົາເລືອກກ່ອນທີ່ຈະຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍທໍາອິດ), ແລະກະແຈສຸດທ້າຍຖືກຕິດຕັ້ງໃນເວລາບໍ່ຮ້າຍແຮງກວ່າ T2 (ເວລາທີ່ການຕອບສະຫນອງໄດ້ຮັບການຕອບຮັບ. ຈາກເຄື່ອງແມ່ຂ່າຍສຸດທ້າຍ), ຫຼັງຈາກນັ້ນພວກເຮົາຫມັ້ນໃຈວ່າລະຫັດທໍາອິດໃນຊຸດທີ່ຫມົດອາຍຸຈະຢູ່ລອດຢ່າງຫນ້ອຍ MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. ກະແຈອື່ນໆທັງໝົດຈະໝົດອາຍຸໃນພາຍຫຼັງ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງສາມາດໝັ້ນໃຈໄດ້ວ່າກະແຈທັງໝົດຈະໃຊ້ໄດ້ພ້ອມກັນເປັນເວລາຢ່າງໜ້ອຍນີ້.

ໃນລະຫວ່າງເວລາທີ່ກະແຈສ່ວນໃຫຍ່ຍັງຄົງໃຊ້ໄດ້, ລູກຄ້າອື່ນຈະບໍ່ສາມາດໄດ້ຮັບ lock ໄດ້, ເນື່ອງຈາກວ່າ N/2+1 SET NX operations ບໍ່ສາມາດສຳເລັດໄດ້ຖ້າ N/2+1 key ມີຢູ່ແລ້ວ. ດັ່ງນັ້ນ, ເມື່ອໄດ້ lock ໄດ້, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະໄດ້ມາອີກເທື່ອຫນຶ່ງໃນເວລາດຽວກັນ (ນີ້ຈະລະເມີດຊັບສິນການຍົກເວັ້ນເຊິ່ງກັນແລະກັນ).
ຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າລູກຄ້າຫຼາຍຄົນທີ່ພະຍາຍາມຊື້ lock ໃນເວລາດຽວກັນບໍ່ສາມາດປະສົບຜົນສໍາເລັດໃນເວລາດຽວກັນ.

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

ທ່ານສາມາດສະຫນອງຫຼັກຖານຢ່າງເປັນທາງການຂອງຄວາມປອດໄພ, ຊີ້ບອກວິທີການທີ່ຄ້າຍຄືກັນທີ່ມີຢູ່ແລ້ວ, ຫຼືຊອກຫາ bug ໃນຂ້າງເທິງນີ້?

ການພິຈາລະນາການເຂົ້າເຖິງ

ຄວາມພ້ອມຂອງລະບົບແມ່ນຂຶ້ນກັບສາມລັກສະນະຕົ້ນຕໍ:

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

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

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

ການປະຕິບັດ, ລົ້ມເຫລວແລະ fsync

ຫຼາຍຄົນໃຊ້ Redis ເພາະວ່າພວກເຂົາຕ້ອງການປະສິດທິພາບຂອງເຄື່ອງແມ່ຂ່າຍ lock ສູງໃນເງື່ອນໄຂຂອງ latency ທີ່ຕ້ອງການເພື່ອໃຫ້ໄດ້ມາແລະປ່ອຍ locks, ແລະຈໍານວນການຊື້ / ປ່ອຍທີ່ສາມາດສໍາເລັດຕໍ່ວິນາທີ. ເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການນີ້, ມີຍຸດທະສາດທີ່ຈະຕິດຕໍ່ສື່ສານກັບເຄື່ອງແມ່ຂ່າຍຂອງ N Redis ເພື່ອຫຼຸດຜ່ອນເວລາ latency. ນີ້ແມ່ນຍຸດທະສາດການ multiplexing (ຫຼື "ການ multiplexing ຜູ້ຊາຍທີ່ທຸກຍາກ", ບ່ອນທີ່ socket ໄດ້ຖືກໃສ່ໃນໂຫມດບໍ່ສະກັດ, ສົ່ງຄໍາສັ່ງທັງຫມົດ, ແລະອ່ານຄໍາສັ່ງຕໍ່ມາ, ສົມມຸດວ່າເວລາໄປກັບລະຫວ່າງລູກຄ້າແລະແຕ່ລະ instance ແມ່ນຄ້າຍຄືກັນ). .

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

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

ຖ້າທ່ານເປີດໃຊ້ຂໍ້ມູນລ່ວງຫນ້າ (AOF), ສະຖານະການຈະປັບປຸງເລັກນ້ອຍ. ຕົວຢ່າງ, ທ່ານສາມາດສົ່ງເສີມເຄື່ອງແມ່ຂ່າຍໂດຍການສົ່ງຄໍາສັ່ງ SHUTDOWN ແລະເລີ່ມຕົ້ນໃຫມ່. ນັບຕັ້ງແຕ່ການປະຕິບັດງານຫມົດອາຍຸໃນ Redis ໄດ້ຖືກປະຕິບັດໃນລັກສະນະທີ່ເວລາຍັງສືບຕໍ່ໄຫຼເຖິງແມ່ນວ່າໃນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍຖືກປິດ, ຂໍ້ກໍານົດຂອງພວກເຮົາທັງຫມົດແມ່ນດີ. ນີ້ແມ່ນເລື່ອງປົກກະຕິຕາບໃດທີ່ການປິດປົກກະຕິແມ່ນຮັບປະກັນ. ຈະ​ເຮັດ​ແນວ​ໃດ​ໃນ​ກໍ​ລະ​ນີ​ໄຟ​ຟ້າ​ຫມົດ​? ຖ້າ Redis ຖືກຕັ້ງຄ່າໂດຍຄ່າເລີ່ມຕົ້ນ, ດ້ວຍ fsync synchronizing ໃນແຜ່ນທຸກໆວິນາທີ, ມັນເປັນໄປໄດ້ວ່າຫຼັງຈາກ restart ພວກເຮົາຈະບໍ່ມີລະຫັດຂອງພວກເຮົາ. ໃນທາງທິດສະດີ, ຖ້າພວກເຮົາຕ້ອງການຮັບປະກັນຄວາມປອດໄພຂອງລັອກໃນລະຫວ່າງການປິດເປີດຕົວຢ່າງໃດກໍ່ຕາມ, ພວກເຮົາຄວນຈະເປີດໃຊ້ fsync=always ໃນການຕັ້ງຄ່າສໍາລັບການເກັບຮັກສາຂໍ້ມູນໃນໄລຍະຍາວ. ນີ້ຈະຂ້າປະສິດທິພາບຢ່າງສົມບູນ, ລົງເຖິງລະດັບຂອງລະບົບ CP ທີ່ຖືກນໍາໃຊ້ແບບດັ້ງເດີມເພື່ອປະຕິບັດການກະແຈກກະຈາຍຢ່າງປອດໄພ.

ແຕ່ສະຖານະການແມ່ນດີກ່ວາມັນເບິ່ງຄືວ່າຢູ່ glance ທໍາອິດ. ໃນຫຼັກການ, ຄວາມປອດໄພຂອງ algorithm ແມ່ນຖືກຮັກສາໄວ້ເພາະວ່າເມື່ອ instance ຖືກ restart ຫຼັງຈາກຄວາມລົ້ມເຫຼວ, ມັນຈະບໍ່ມີສ່ວນຮ່ວມໃນ lock ໃດໆທີ່ມີການເຄື່ອນໄຫວໃນປັດຈຸບັນ.

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

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

ພວກເຮົາເພີ່ມຄວາມພ້ອມຂອງ algorithm: ພວກເຮົາຂະຫຍາຍການຂັດຂວາງ

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

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

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

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