जेव्हा अनेक कामगार 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

क्रमवारीत सेटची किल्ली स्क्रिप्टचा एकमेव किल्ली युक्तिवाद म्हणून तुमच्या Redis क्लायंटच्या EVAL इंटरफेसवरून पाठवा. रिकामा पूल null निकाल देतो, जो अनुप्रयोगाने विनंती न करता हाताळला पाहिजे.

दोन्ही आदेश एकत्र का करावे?

वेगळे वाचन आणि वाढ दोन कामगारांना कोणीही अद्ययावत करण्यापूर्वी समान किमान पाहू देतात. Redis Lua स्क्रिप्ट अणुरित्या चालवते, त्यामुळे दुसरा कामगार या स्क्रिप्टच्या वाचन आणि वाढीमध्ये निवड घालू शकत नाही. स्क्रिप्ट छोटी ठेवा कारण तिची अंमलबजावणी इतर Redis काम अडवते.

ZRANGE सर्वात कमी गुण प्रथम परत करते; समान गुण सदस्य क्रमाने सोडवले जातात, यादृच्छिकपणे नाही. ZINCRBY पुढील वाटपासाठी निवडलेल्या सदस्याचा गुण एकने वाढवते.

गुणाचा अर्थ ठरवा

हे वाटप मोजते, ज्यात अशा वाटपाचा समावेश आहे ज्याची नेटवर्क विनंती नंतर अयशस्वी होते. हे विलंब, यशस्वी विनंत्या किंवा सध्या सुरू असलेले काम मोजत नाही. एकमेव पात्र सदस्य वारंवार निवडणे अजूनही शक्य आहे; स्क्रिप्ट त्याला विशेषाधिकाराने राखून ठेवत नाही.

पूलच्या आरोग्य आणि धोरण नियमांनी पात्रता टिकवा. सदस्य काढून नंतर पुनर्संचयित केल्यास, त्याची ऐतिहासिक संख्या ठेवावी का ते ठरवा. पुनर्संचयित प्रॉक्सी शून्यापासून सुरू केल्यास ती सावरण्याच्या काळात वाटप तिच्यावर केंद्रित होऊ शकते.

किमान-समवर्ती धोरणास वेगळे जीवनचक्र लागते, ज्यात पूर्णता आणि सोडून दिलेल्या कामांची हाताळणी समाविष्ट आहे. या संचित मोजकाची ते जीवनचक्र म्हणून व्याख्या करू नका.

संबंधित लेख