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 ਅਗਲੇ ਨਿਰਧਾਰਨ ਲਈ ਚੁਣੇ ਮੈਂਬਰ ਦਾ ਸਕੋਰ ਇੱਕ ਵਧਾਉਂਦਾ ਹੈ।

ਸਕੋਰ ਦਾ ਅਰਥ ਨਿਰਧਾਰਤ ਕਰੋ

ਇਹ ਨਿਰਧਾਰਨ ਗਿਣਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਨਿਰਧਾਰਨ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਿਸਦੀ ਨੈੱਟਵਰਕ ਬੇਨਤੀ ਬਾਅਦ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦੀ ਹੈ। ਇਹ ਵਿਲੰਬ, ਸਫਲ ਬੇਨਤੀਆਂ ਜਾਂ ਚੱਲ ਰਹੇ ਕੰਮ ਨੂੰ ਨਹੀਂ ਮਾਪਦਾ। ਇੱਕੋ-ਇੱਕ ਯੋਗ ਮੈਂਬਰ ਨੂੰ ਵਾਰ-ਵਾਰ ਚੁਣਨਾ ਅਜੇ ਵੀ ਸੰਭਵ ਹੈ; ਸਕ੍ਰਿਪਟ ਇਸਨੂੰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਰਾਖਵਾਂ ਨਹੀਂ ਰੱਖਦੀ।

ਪੂਲ ਦੇ ਸਿਹਤ ਅਤੇ ਨੀਤੀ ਨਿਯਮਾਂ ਨਾਲ ਯੋਗਤਾ ਬਣਾਈ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਮੈਂਬਰ ਹਟਾ ਕੇ ਬਾਅਦ ਵਿੱਚ ਬਹਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੈਅ ਕਰੋ ਕਿ ਇਸਦੀ ਇਤਿਹਾਸਕ ਗਿਣਤੀ ਰੱਖਣੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਬਹਾਲ ਕੀਤੀ ਪਰਾਕਸੀ ਨੂੰ ਜ਼ੀਰੋ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਨਾਲ ਇਹ ਪੂਰਾ ਹੁੰਦੇ ਸਮੇਂ ਨਿਰਧਾਰਨ ਇਸ 'ਤੇ ਕੇਂਦ੍ਰਿਤ ਹੋ ਸਕਦੇ ਹਨ।

ਘੱਟੋ-ਘੱਟ-ਸਮਕਾਲੀ ਨੀਤੀ ਲਈ ਵੱਖਰਾ ਜੀਵਨ ਚੱਕਰ ਚਾਹੀਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਮੁਕੰਮਲਤਾ ਅਤੇ ਤਿਆਗੇ ਕੰਮਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਸ਼ਾਮਲ ਹੈ। ਇਸ ਸੰਚਿਤ ਗਿਣਕ ਨੂੰ ਉਹ ਜੀਵਨ ਚੱਕਰ ਨਾ ਸਮਝੋ।