เมื่อเวิร์กเกอร์หลายตัวแชร์พูลผ่าน 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 ของคุณ พูลว่างให้ผลลัพธ์ null ซึ่งแอปพลิเคชันต้องจัดการโดยไม่ส่งคำขอ

ทำไมต้องรวมสองคำสั่งเข้าด้วยกัน?

การอ่านและการเพิ่มแยกกันทำให้เวิร์กเกอร์สองตัวเห็นค่าต่ำสุดเดียวกันก่อนที่ใครจะอัปเดต Redis รันสคริปต์ Lua อย่างอะตอมมิก เวิร์กเกอร์อื่นจึงแทรกการเลือกระหว่างการอ่านและการเพิ่มของสคริปต์นี้ไม่ได้ เก็บสคริปต์ให้สั้นเพราะการรันจะบล็อกงานอื่นของ Redis

ZRANGE คืนคะแนนต่ำสุดก่อน คะแนนที่เท่ากันตัดสินด้วยลำดับสมาชิก ไม่ใช่แบบสุ่ม ZINCRBY เพิ่มคะแนนของสมาชิกที่เลือกขึ้นหนึ่งสำหรับการจัดสรรครั้งถัดไป

กำหนดความหมายของคะแนน

ค่านี้บันทึกจำนวนการจัดสรร รวมถึงการจัดสรรที่คำขอเครือข่ายล้มเหลวในภายหลัง ไม่ได้วัดความหน่วง คำขอที่สำเร็จ หรืองานที่กำลังดำเนินอยู่ การเลือกสมาชิกที่เข้าเกณฑ์เพียงตัวเดียวซ้ำ ๆ ยังเป็นไปได้ สคริปต์ไม่ได้จองไว้แต่เพียงผู้เดียว

รักษาคุณสมบัติด้วยกฎสุขภาพและนโยบายของพูล หากคุณนำสมาชิกออกแล้วคืนกลับภายหลัง ให้ตัดสินว่าจะเก็บจำนวนในอดีตไว้หรือไม่ การเริ่มพร็อกซีที่คืนกลับจากศูนย์อาจทำให้การจัดสรรกระจุกตัวที่มันระหว่างที่ตามทัน

นโยบายการทำงานพร้อมกันต่ำสุดต้องมีวงจรชีวิตที่ต่างออกไป รวมถึงการทำให้เสร็จและการจัดการงานที่ถูกทิ้ง อย่าตีความตัวนับสะสมนี้ว่าเป็นวงจรชีวิตนั้น

บทความที่เกี่ยวข้อง