ເມື່ອຜູ້ປະມວນຜົນຫຼາຍຄົນແບ່ງປັນພູລຜ່ານ Redis ຊຸດທີ່ຈັດລຳດັບສາມາດປະຕິບັດນະໂຍບາຍງ່າຍໆ: ເລືອກພຣອກຊີທີ່ມີສິດ ແລະ ມີຈຳນວນການຈັດສັນບັນທຶກໜ້ອຍທີ່ສຸດ. ເກັບຕົວລະບຸພຣອກຊີເປັນສະມາຊິກ ແລະ ຈຳນວນການຈັດສັນຂອງມັນເປັນຄະແນນ.

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

local chosen = redis.call('ZRANGE', KEYS[1], 0, 0)[1]
if not chosen then
    return nil
end

redis.call('ZINCRBY', KEYS[1], 1, chosen)
return chosen

ສົ່ງກະແຈຂອງຊຸດທີ່ຈັດລຳດັບເປັນອາກູເມັນກະແຈດຽວຂອງສະຄຣິບ ຜ່ານອິນເຕີເຟສ EVAL ຂອງ Redis client ຂອງທ່ານ. ພູລຫວ່າງໃຫ້ຜົນ null ທີ່ແອັບຯຕ້ອງຈັດການໂດຍບໍ່ສົ່ງຄຳຮ້ອງ.

ເປັນຫຍັງຈຶ່ງລວມສອງຄຳສັ່ງ?

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

ZRANGE ສົ່ງຄະແນນຕ່ຳທີ່ສຸດກ່ອນ; ຄະແນນເທົ່າກັນແກ້ໄຂດ້ວຍລຳດັບສະມາຊິກ ບໍ່ແມ່ນແບບສຸ່ມ. ZINCRBY ເພີ່ມຄະແນນຂອງສະມາຊິກທີ່ເລືອກຂຶ້ນໜຶ່ງ ສຳລັບການຈັດສັນຕໍ່ໄປ.

ກຳນົດຄວາມໝາຍຂອງຄະແນນ

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

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

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

ບົດຄວາມທີ່ກ່ຽວຂ້ອງ