Redis માં સૌથી ઓછા વપરાયેલા પ્રોક્સીને અણુરૂપે ફાળવો

જ્યારે ઘણા વર્કર્સ 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 આગલી ફાળવણી માટે પસંદ કરેલા સભ્યનો સ્કોર એક વધારે છે.

સ્કોરનો અર્થ નક્કી કરો

આ ફાળવણીઓની ગણતરી કરે છે, જેમાં એવી ફાળવણી પણ છે જેની નેટવર્ક વિનંતી પછીથી નિષ્ફળ જાય. તે વિલંબ, સફળ વિનંતીઓ કે ચાલુ કામ માપતું નથી. એકમાત્ર પાત્ર સભ્યને વારંવાર પસંદ કરવું હજી શક્ય છે; સ્ક્રિપ્ટ તેને વિશિષ્ટ રીતે અનામત રાખતી નથી.

પૂલના આરોગ્ય અને નીતિ નિયમોથી પાત્રતા જાળવો. જો તમે સભ્ય દૂર કરો અને પછીથી પુનઃસ્થાપિત કરો, તો નક્કી કરો કે તેની ઐતિહાસિક ગણતરી રાખવી જોઈએ કે નહીં. પુનઃસ્થાપિત પ્રોક્સીને શૂન્યથી શરૂ કરવાથી તે સાથે આવતી વખતે ફાળવણીઓ તેના પર કેન્દ્રિત થઈ શકે છે.

સૌથી ઓછી સમવર્તી નીતિને અલગ જીવનચક્રની જરૂર છે, જેમાં પૂર્ણતા અને ત્યાગેલા કામોની સંભાળનો સમાવેશ થાય છે. આ સંચિત ગણતરીને તે જીવનચક્ર તરીકે અર્થઘટન કરશો નહીં.