Redis ਵਰਤ ਕੇ ਵੰਡਿਆ ਲਾਕਿੰਗ

ਹੇ ਹਬਰ!

ਅੱਜ ਅਸੀਂ ਤੁਹਾਡੇ ਧਿਆਨ ਵਿੱਚ Redis ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਿਤਰਿਤ ਲਾਕਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਇੱਕ ਗੁੰਝਲਦਾਰ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਲਿਆਉਂਦੇ ਹਾਂ ਅਤੇ ਤੁਹਾਨੂੰ ਇੱਕ ਵਿਸ਼ੇ ਵਜੋਂ Redis ਦੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਨ ਲਈ ਸੱਦਾ ਦਿੰਦੇ ਹਾਂ। ਕਿਤਾਬ ਦੇ ਲੇਖਕ ਮਾਰਟਿਨ ਕਲੈਪਮੈਨ ਤੋਂ ਸਵਾਲ ਵਿੱਚ ਰੈੱਡਲਾਕ ਐਲਗੋਰਿਦਮ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ "ਉੱਚ ਲੋਡ ਐਪਲੀਕੇਸ਼ਨ", ਦਿੱਤਾ ਇੱਥੇ.

ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਲਾਕਿੰਗ ਬਹੁਤ ਸਾਰੇ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਇੱਕ ਬਹੁਤ ਹੀ ਉਪਯੋਗੀ ਮੁੱਢਲੀ ਚੀਜ਼ ਹੈ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਸਾਂਝੇ ਸਰੋਤਾਂ 'ਤੇ ਆਪਸੀ ਵਿਸ਼ੇਸ਼ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਪੋਸਟਾਂ ਹਨ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ Redis ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ DLM (ਡਿਸਟ੍ਰੀਬਿਊਟਡ ਲੌਕ ਮੈਨੇਜਰ) ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਪਰ ਹਰੇਕ ਲਾਇਬ੍ਰੇਰੀ ਇੱਕ ਵੱਖਰੀ ਪਹੁੰਚ ਅਪਣਾਉਂਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਗਾਰੰਟੀਆਂ ਥੋੜ੍ਹੇ ਜਿਹੇ ਵਧੇਰੇ ਸੂਝਵਾਨ ਡਿਜ਼ਾਈਨ ਨਾਲ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫ਼ੀ ਕਮਜ਼ੋਰ ਹਨ।

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

ਲਾਗੂ ਕਰਨ

ਐਲਗੋਰਿਦਮ ਦੇ ਵਰਣਨ 'ਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਤਿਆਰ ਕੀਤੇ ਲਾਗੂਕਰਨਾਂ ਲਈ ਕਈ ਲਿੰਕ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ। ਉਹ ਹਵਾਲੇ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ.

• ਰੈੱਡਲਾਕ-ਆਰ.ਬੀ (ਰੂਬੀ ਲਈ ਲਾਗੂ ਕਰਨਾ)। ਵੀ ਹੈ ਕਾਂਟਾ Redlock-rb, ਜੋ ਕਿ ਵੰਡ ਦੀ ਸੌਖ ਲਈ ਇੱਕ ਪੈਕੇਜ (ਰਤਨ) ਜੋੜਦਾ ਹੈ, ਨਾ ਕਿ ਸਿਰਫ਼ ਇਸਦੇ ਲਈ।
• redlock-py (ਪਾਈਥਨ ਲਾਗੂ ਕਰਨਾ)।
• Aioredlock (Asyncio Python ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• ਰੈੱਡਲਾਕ-php (PHP ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• PHPRedisMutex (PHP ਲਈ ਇੱਕ ਹੋਰ ਲਾਗੂਕਰਨ)
• cheprasov/php-redis-lock (ਲਾਕ ਲਈ PHP ਲਾਇਬ੍ਰੇਰੀ)
• ਰੈਡਸਿੰਕ (ਗੋ ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• ਰੀਡੀਸਨ (ਜਾਵਾ ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• Redis::DistLock (ਪਰਲ ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• ਰੈੱਡਲਾਕ-ਸੀ.ਪੀ.ਪੀ (C++ ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• ਰੈੱਡਲਾਕ-ਸੀ.ਐਸ (C#/.NET ਲਈ ਲਾਗੂ ਕਰਨਾ)।
• RedLock.net (C#/.NET ਲਈ ਲਾਗੂ ਕਰਨਾ)। ਅਸਿੰਕ ਅਤੇ ਲੌਕ ਐਕਸਟੈਂਸ਼ਨਾਂ ਲਈ ਸਮਰਥਨ ਦੇ ਨਾਲ।
• ਸਕਾਰਲੇਟ ਲੌਕ (ਸੰਰਚਨਾਯੋਗ ਡੇਟਾ ਸਟੋਰ ਦੇ ਨਾਲ C# .NET ਲਈ ਲਾਗੂ)
• Redlock4Net (C# .NET ਲਈ ਲਾਗੂ)
• ਨੋਡ-ਰੈਡਲਾਕ (ਨੋਡਜੇਐਸ ਲਈ ਲਾਗੂ ਕਰਨਾ)। ਤਾਲੇ ਨੂੰ ਵਧਾਉਣ ਲਈ ਸਮਰਥਨ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ।

ਸੁਰੱਖਿਆ ਅਤੇ ਉਪਲਬਧਤਾ ਦੀ ਗਾਰੰਟੀ

ਅਸੀਂ ਆਪਣੇ ਡਿਜ਼ਾਇਨ ਨੂੰ ਸਿਰਫ਼ ਤਿੰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਮਾਡਲ ਬਣਾਉਣ ਜਾ ਰਹੇ ਹਾਂ ਜੋ ਸਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਡਿਸਟਰੀਬਿਊਟਡ ਲਾਕਿੰਗ ਦੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਵਰਤੋਂ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀਆਂ ਘੱਟੋ-ਘੱਟ ਗਾਰੰਟੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ।

1. ਸੁਰੱਖਿਆ ਸੰਪਤੀ: ਆਪਸੀ ਬੇਦਖਲੀ। ਕਿਸੇ ਵੀ ਸਮੇਂ, ਸਿਰਫ਼ ਇੱਕ ਕਲਾਇੰਟ ਲਾਕ ਨੂੰ ਫੜ ਸਕਦਾ ਹੈ।
2. ਉਪਲਬਧਤਾ ਸੰਪੱਤੀ A: ਕੋਈ ਡੈੱਡਲਾਕ ਨਹੀਂ। ਅੰਤ ਵਿੱਚ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹਮੇਸ਼ਾ ਸੰਭਵ ਹੁੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਕਲਾਇੰਟ ਜਿਸ ਨੇ ਸਰੋਤ ਨੂੰ ਲਾਕ ਕੀਤਾ ਹੋਵੇ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਇੱਕ ਵੱਖਰੇ ਡਿਸਕ ਹਿੱਸੇ 'ਤੇ ਉਤਰਦਾ ਹੈ।
3. ਉਪਲਬਧਤਾ ਸੰਪੱਤੀ B: ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ। ਜਿੰਨਾ ਚਿਰ ਰੈਡਿਸ ਨੋਡਜ਼ ਦੀ ਬਹੁਗਿਣਤੀ ਚੱਲ ਰਹੀ ਹੈ, ਗਾਹਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਜਾਰੀ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ।

ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਅਸਫਲਤਾ ਰਿਕਵਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਲਾਗੂ ਕਰਨਾ ਕਾਫ਼ੀ ਕਿਉਂ ਨਹੀਂ ਹੈ
ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਅਸੀਂ ਕੀ ਸੁਧਾਰ ਕਰਨ ਜਾ ਰਹੇ ਹਾਂ, ਆਓ Redis 'ਤੇ ਆਧਾਰਿਤ ਜ਼ਿਆਦਾਤਰ ਵੰਡੀਆਂ ਲੌਕਿੰਗ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਨਾਲ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ।

Redis ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਸਰੋਤ ਨੂੰ ਲਾਕ ਕਰਨ ਦਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਉਦਾਹਰਣ ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਬਣਾਉਣਾ। ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਕੁੰਜੀ ਇੱਕ ਸੀਮਤ ਜੀਵਨ ਕਾਲ ਨਾਲ ਬਣਾਈ ਜਾਂਦੀ ਹੈ, ਇਹ Redis ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੀ ਮਿਆਦ ਪੁੱਗਣ ਵਾਲੀ ਵਿਸ਼ੇਸ਼ਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਇਹ ਕੁੰਜੀ ਜਾਰੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਸਾਡੀ ਸੂਚੀ ਵਿੱਚ ਸੰਪੱਤੀ 2)। ਜਦੋਂ ਕਲਾਇੰਟ ਨੂੰ ਸਰੋਤ ਜਾਰੀ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਕੁੰਜੀ ਨੂੰ ਮਿਟਾ ਦਿੰਦਾ ਹੈ।

ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਇਹ ਹੱਲ ਬਹੁਤ ਵਧੀਆ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਇੱਕ ਸਮੱਸਿਆ ਹੈ: ਸਾਡਾ ਆਰਕੀਟੈਕਚਰ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਬਿੰਦੂ ਬਣਾਉਂਦਾ ਹੈ. ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਮੇਜ਼ਬਾਨ Redis ਉਦਾਹਰਣ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ? ਚਲੋ ਫਿਰ ਇੱਕ ਗੁਲਾਮ ਜੋੜਦੇ ਹਾਂ! ਅਤੇ ਅਸੀਂ ਇਸਨੂੰ ਵਰਤਾਂਗੇ ਜੇਕਰ ਪੇਸ਼ਕਾਰ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਵਿਕਲਪ ਵਿਹਾਰਕ ਨਹੀਂ ਹੈ. ਅਜਿਹਾ ਕਰਨ ਨਾਲ, ਅਸੀਂ ਆਪਸੀ ਬੇਦਖਲੀ ਸੰਪੱਤੀ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵਾਂਗੇ ਜਿਸਦੀ ਸਾਨੂੰ ਸੁਰੱਖਿਆ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਕਿਉਂਕਿ Redis ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਸਿੰਕ੍ਰੋਨਸ ਹੈ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਅਜਿਹੇ ਮਾਡਲ ਵਿੱਚ ਇੱਕ ਦੌੜ ਦੀ ਸਥਿਤੀ ਹੁੰਦੀ ਹੈ:

1. ਕਲਾਇੰਟ ਏ ਮਾਸਟਰ 'ਤੇ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
2. ਕੁੰਜੀ ਐਂਟਰੀ ਨੂੰ ਸਲੇਵ ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਮਾਸਟਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ।
3. ਪੈਰੋਕਾਰ ਨੂੰ ਲੀਡਰ ਬਣਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
4. ਕਲਾਇੰਟ B ਉਸੇ ਸਰੋਤ 'ਤੇ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ A ਨੇ ਪਹਿਲਾਂ ਹੀ ਲਾਕ ਕੀਤਾ ਹੋਇਆ ਹੈ। ਸੁਰੱਖਿਆ ਦੀ ਉਲੰਘਣਾ!

ਕਈ ਵਾਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਮ ਹੁੰਦਾ ਹੈ ਕਿ ਵਿਸ਼ੇਸ਼ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਜਿਵੇਂ ਕਿ ਅਸਫਲਤਾ, ਬਹੁਤ ਸਾਰੇ ਗਾਹਕ ਇੱਕੋ ਸਮੇਂ ਲਾਕ ਨੂੰ ਫੜ ਸਕਦੇ ਹਨ। ਅਜਿਹੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਪ੍ਰਤੀਕ੍ਰਿਤੀ-ਅਧਾਰਤ ਹੱਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, ਅਸੀਂ ਇਸ ਲੇਖ ਵਿਚ ਦੱਸੇ ਗਏ ਹੱਲ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ.

ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਨਾਲ ਸਹੀ ਲਾਗੂ ਕਰਨਾ

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

ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਇਹ ਕਰੋ:

SET resource_name my_random_value NX PX 30000

ਇਹ ਕਮਾਂਡ ਕੇਵਲ ਤਾਂ ਹੀ ਇੱਕ ਕੁੰਜੀ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੀ ਹੈ ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਹੀਂ ਹੈ (NX ਵਿਕਲਪ), 30000 ਮਿਲੀਸਕਿੰਟ (PX ਵਿਕਲਪ) ਦੀ ਵੈਧਤਾ ਮਿਆਦ ਦੇ ਨਾਲ। ਕੁੰਜੀ "ਤੇ ਸੈੱਟ ਕੀਤੀ ਗਈ ਹੈmyrandomvalue" ਇਹ ਮੁੱਲ ਸਾਰੇ ਗਾਹਕਾਂ ਅਤੇ ਸਾਰੀਆਂ ਲੌਕ ਬੇਨਤੀਆਂ ਵਿੱਚ ਵਿਲੱਖਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਮੂਲ ਰੂਪ ਵਿੱਚ, ਇੱਕ ਬੇਤਰਤੀਬ ਮੁੱਲ ਦੀ ਵਰਤੋਂ ਲਾਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਜਾਰੀ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਇੱਕ ਸਕ੍ਰਿਪਟ Redis ਨੂੰ ਦੱਸਦੀ ਹੈ: ਕੇਵਲ ਤਾਂ ਹੀ ਕੁੰਜੀ ਨੂੰ ਹਟਾਓ ਜੇਕਰ ਇਹ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਮੁੱਲ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸਦੀ ਉਮੀਦ ਕੀਤੀ ਗਈ ਸੀ। ਇਹ ਹੇਠ ਲਿਖੀ ਲੂਆ ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

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

ਇਹ ਬੇਤਰਤੀਬ ਸਤਰ ਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ? ਮੈਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਰਿਹਾ ਹਾਂ ਕਿ ਇਹ /dev/urandom ਤੋਂ 20 ਬਾਈਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਆਪਣੇ ਉਦੇਸ਼ਾਂ ਲਈ ਸਤਰ ਨੂੰ ਵਿਲੱਖਣ ਬਣਾਉਣ ਦੇ ਘੱਟ ਮਹਿੰਗੇ ਤਰੀਕੇ ਲੱਭ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, RC4 ਨੂੰ /dev/urandom ਨਾਲ ਬੀਜਣਾ ਅਤੇ ਫਿਰ ਇਸ ਤੋਂ ਇੱਕ ਸੂਡੋ-ਰੈਂਡਮ ਸਟ੍ਰੀਮ ਬਣਾਉਣਾ ਠੀਕ ਰਹੇਗਾ। ਇੱਕ ਸਧਾਰਨ ਹੱਲ ਵਿੱਚ ਮਾਈਕ੍ਰੋਸਕਿੰਡ ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਅਤੇ ਕਲਾਇੰਟ ਆਈਡੀ ਵਿੱਚ ਯੂਨਿਕਸ ਸਮੇਂ ਦਾ ਸੁਮੇਲ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ; ਇਹ ਇੰਨਾ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਜ਼ਿਆਦਾਤਰ ਸੰਦਰਭਾਂ ਵਿੱਚ ਕੰਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

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

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

ਰੈੱਡਲਾਕ ਐਲਗੋਰਿਦਮ

ਐਲਗੋਰਿਦਮ ਦਾ ਵਿਤਰਿਤ ਸੰਸਕਰਣ ਇਹ ਮੰਨਦਾ ਹੈ ਕਿ ਸਾਡੇ ਕੋਲ N Redis ਮਾਸਟਰ ਹਨ। ਇਹ ਨੋਡ ਇੱਕ ਦੂਜੇ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਤੰਤਰ ਹਨ, ਇਸਲਈ ਅਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਜਾਂ ਕਿਸੇ ਹੋਰ ਅਪ੍ਰਤੱਖ ਤਾਲਮੇਲ ਪ੍ਰਣਾਲੀ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਵਰ ਕਰ ਚੁੱਕੇ ਹਾਂ ਕਿ ਕਿਵੇਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਮੌਕੇ 'ਤੇ ਲਾਕ ਕਿਵੇਂ ਜਾਰੀ ਕਰਨਾ ਹੈ। ਅਸੀਂ ਇਸ ਗੱਲ ਨੂੰ ਮੰਨਦੇ ਹਾਂ ਕਿ ਐਲਗੋਰਿਦਮ, ਜਦੋਂ ਇੱਕ ਸਿੰਗਲ ਉਦਾਹਰਨ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਬਿਲਕੁਲ ਇਸ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰੇਗਾ। ਸਾਡੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਅਸੀਂ N ਨੂੰ 5 ਤੇ ਸੈਟ ਕਰਦੇ ਹਾਂ, ਜੋ ਇੱਕ ਵਾਜਬ ਮੁੱਲ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ ਵੱਖ-ਵੱਖ ਕੰਪਿਊਟਰਾਂ ਜਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ 'ਤੇ 5 ਰੈਡਿਸ ਮਾਸਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕਿ ਉਹ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ।

ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਕਲਾਇੰਟ ਹੇਠਾਂ ਦਿੱਤੇ ਓਪਰੇਸ਼ਨ ਕਰਦਾ ਹੈ:

1. ਮੌਜੂਦਾ ਸਮਾਂ ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।
2. ਕ੍ਰਮਵਾਰ ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇੱਕੋ ਕੁੰਜੀ ਨਾਮ ਅਤੇ ਬੇਤਰਤੀਬ ਮੁੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਾਰੀਆਂ N ਮੌਕਿਆਂ 'ਤੇ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਪੜਾਅ 2 ਵਿੱਚ, ਜਦੋਂ ਕਲਾਇੰਟ ਪ੍ਰਤੀ-ਮਿਸਾਲ ਦੇ ਅਧਾਰ 'ਤੇ ਇੱਕ ਲਾਕ ਸੈਟ ਅਪ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਦੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜੋ ਉਸ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕਾਫ਼ੀ ਛੋਟਾ ਹੁੰਦਾ ਹੈ ਜਿਸ ਤੋਂ ਬਾਅਦ ਲਾਕ ਆਪਣੇ ਆਪ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਬਲਾਕਿੰਗ ਦੀ ਮਿਆਦ 10 ਸਕਿੰਟ ਹੈ, ਤਾਂ ਦੇਰੀ ~5-50 ਮਿਲੀਸਕਿੰਟ ਦੀ ਰੇਂਜ ਵਿੱਚ ਹੋ ਸਕਦੀ ਹੈ। ਇਹ ਉਸ ਸਥਿਤੀ ਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਕਲਾਇੰਟ ਇੱਕ ਅਸਫਲ ਰੈਡਿਸ ਨੋਡ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਲਈ ਬਲੌਕ ਰਹਿ ਸਕਦਾ ਹੈ: ਜੇਕਰ ਉਦਾਹਰਣ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ ਕਿਸੇ ਹੋਰ ਸਥਿਤੀ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ।
3. ਲਾਕ ਲੈਣ ਲਈ, ਗਾਹਕ ਗਣਨਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿੰਨਾ ਸਮਾਂ ਬੀਤ ਗਿਆ ਹੈ; ਅਜਿਹਾ ਕਰਨ ਲਈ, ਇਹ ਅਸਲ ਸਮਾਂ ਮੁੱਲ ਤੋਂ ਉਸ ਟਾਈਮਸਟੈਂਪ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਜੋ ਪੜਾਅ 1 ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਜੇਕਰ ਅਤੇ ਕੇਵਲ ਤਾਂ ਹੀ ਜੇਕਰ ਕਲਾਇੰਟ ਜ਼ਿਆਦਾਤਰ ਉਦਾਹਰਨਾਂ (ਘੱਟੋ-ਘੱਟ 3) 'ਤੇ ਲੌਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ, ਅਤੇ ਇਸ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਕੁੱਲ ਸਮਾਂ ਤਾਲਾ ਪ੍ਰਾਪਤ ਕਰੋ, ਤਾਲਾ ਦੀ ਮਿਆਦ ਤੋਂ ਘੱਟ, ਤਾਲਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
4. ਜੇਕਰ ਇੱਕ ਲਾਕ ਐਕਵਾਇਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਲਾਕ ਦੀ ਮਿਆਦ ਨੂੰ ਮੂਲ ਲਾਕ ਅਵਧੀ ਤੋਂ ਘਟਾ ਕੇ ਪੜਾਅ 3 ਵਿੱਚ ਗਿਣਿਆ ਗਿਆ ਸਮਾਂ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।
5. ਜੇਕਰ ਕਲਾਇੰਟ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ (ਜਾਂ ਤਾਂ ਇਹ N/2+1 ਮੌਕਿਆਂ ਨੂੰ ਲਾਕ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ, ਜਾਂ ਲਾਕ ਦੀ ਮਿਆਦ ਨਕਾਰਾਤਮਕ ਸੀ), ਤਾਂ ਇਹ ਸਾਰੀਆਂ ਮੌਕਿਆਂ ਨੂੰ ਅਨਲੌਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ (ਉਹਨਾਂ ਨੂੰ ਵੀ ਜੋ ਇਹ ਸੋਚਦਾ ਸੀ ਕਿ ਇਹ ਬਲਾਕ ਨਹੀਂ ਕਰ ਸਕਦਾ ਸੀ। ).

ਕੀ ਐਲਗੋਰਿਦਮ ਅਸਿੰਕ੍ਰੋਨਸ ਹੈ?

ਇਹ ਐਲਗੋਰਿਦਮ ਇਸ ਧਾਰਨਾ 'ਤੇ ਅਧਾਰਤ ਹੈ ਕਿ, ਹਾਲਾਂਕਿ ਇੱਥੇ ਕੋਈ ਸਮਕਾਲੀ ਘੜੀ ਨਹੀਂ ਹੈ ਜਿਸ 'ਤੇ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਕੰਮ ਕਰਨਗੀਆਂ, ਹਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਥਾਨਕ ਸਮਾਂ ਅਜੇ ਵੀ ਲਗਭਗ ਉਸੇ ਰਫਤਾਰ ਨਾਲ ਵਹਿੰਦਾ ਹੈ, ਅਤੇ ਤਾਲਾ ਲੱਗਣ ਦੇ ਕੁੱਲ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਗਲਤੀ ਛੋਟੀ ਹੈ। ਆਪਣੇ ਆਪ ਜਾਰੀ ਇਹ ਧਾਰਨਾ ਆਮ ਕੰਪਿਊਟਰਾਂ ਲਈ ਆਮ ਸਥਿਤੀ ਨਾਲ ਬਹੁਤ ਮਿਲਦੀ ਜੁਲਦੀ ਹੈ: ਹਰੇਕ ਕੰਪਿਊਟਰ ਦੀ ਇੱਕ ਸਥਾਨਕ ਘੜੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤੱਥ 'ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਵੱਖ-ਵੱਖ ਕੰਪਿਊਟਰਾਂ ਵਿਚਕਾਰ ਸਮੇਂ ਦਾ ਅੰਤਰ ਛੋਟਾ ਹੁੰਦਾ ਹੈ।

ਇਸ ਬਿੰਦੂ 'ਤੇ, ਸਾਨੂੰ ਆਪਣੇ ਆਪਸੀ ਬੇਦਖਲੀ ਦੇ ਨਿਯਮ ਨੂੰ ਹੋਰ ਧਿਆਨ ਨਾਲ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ: ਆਪਸੀ ਬੇਦਖਲੀ ਦੀ ਗਾਰੰਟੀ ਸਿਰਫ ਤਾਂ ਹੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਜੇਕਰ ਲਾਕ ਰੱਖਣ ਵਾਲੇ ਕਲਾਇੰਟ ਲਾਕ ਦੇ ਵੈਧ ਹੋਣ ਦੇ ਦੌਰਾਨ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ (ਇਹ ਮੁੱਲ ਕਦਮ 3 ਵਿੱਚ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ), ਕੁਝ ਹੋਰ ਸਮਾਂ ਘਟਾਓ (ਕੁੱਲ ਕੁਝ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚਕਾਰ ਸਮੇਂ ਦੇ ਅੰਤਰ ਦੀ ਪੂਰਤੀ ਲਈ ਮਿਲੀਸਕਿੰਟ)।

ਹੇਠਾਂ ਦਿੱਤਾ ਦਿਲਚਸਪ ਲੇਖ ਅਜਿਹੀਆਂ ਪ੍ਰਣਾਲੀਆਂ ਬਾਰੇ ਹੋਰ ਦੱਸਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਲਈ ਸਮੇਂ ਦੇ ਅੰਤਰਾਲਾਂ ਦੇ ਤਾਲਮੇਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਲੀਜ਼: ਵਿਤਰਿਤ ਫਾਈਲ ਕੈਸ਼ ਇਕਸਾਰਤਾ ਲਈ ਇੱਕ ਕੁਸ਼ਲ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਵਿਧੀ.

ਅਸਫਲ ਹੋਣ 'ਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ

ਜਦੋਂ ਇੱਕ ਕਲਾਇੰਟ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਬੇਤਰਤੀਬ ਦੇਰੀ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ; ਇਹ ਇੱਕੋ ਸਮੇਂ ਇੱਕੋ ਸਰੋਤ 'ਤੇ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਮਲਟੀਪਲ ਕਲਾਇੰਟਸ ਨੂੰ ਡੀ-ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਨ ਲਈ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਿਸ ਨਾਲ "ਸਪਲਿਟ-ਬ੍ਰੇਨ" ਸਥਿਤੀ ਪੈਦਾ ਹੋ ਸਕਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ ਵਿਜੇਤਾ ਨਹੀਂ ਹੈ)। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਕਲਾਇੰਟ ਰੈਡਿਸ ਮੌਕਿਆਂ ਦੀ ਬਹੁਗਿਣਤੀ 'ਤੇ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਵਿੰਡੋ ਓਨੀ ਹੀ ਤੰਗ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਸਥਿਤੀ ਹੋ ਸਕਦੀ ਹੈ (ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਲੋੜ ਘੱਟ ਹੁੰਦੀ ਹੈ)। ਇਸ ਲਈ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਕਲਾਇੰਟ ਨੂੰ ਮਲਟੀਪਲੈਕਸਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕੋ ਸਮੇਂ N ਮੌਕਿਆਂ 'ਤੇ SET ਕਮਾਂਡਾਂ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

ਇੱਥੇ ਇਸ ਗੱਲ 'ਤੇ ਜ਼ੋਰ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਇਹ ਉਹਨਾਂ ਗਾਹਕਾਂ ਲਈ ਕਿੰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਤਾਲੇ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ (ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ) ਐਕਵਾਇਰ ਕੀਤੇ ਲਾਕ ਨੂੰ ਜਾਰੀ ਕਰਨ ਲਈ, ਤਾਂ ਜੋ ਉਹਨਾਂ ਨੂੰ ਸਰੋਤ 'ਤੇ ਲਾਕ ਦੁਬਾਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਕੁੰਜੀ ਦੇ ਖਤਮ ਹੋਣ ਦੀ ਉਡੀਕ ਨਾ ਕਰਨੀ ਪਵੇ। (ਹਾਲਾਂਕਿ ਜੇਕਰ ਨੈੱਟਵਰਕ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਵਾਪਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ Redis ਉਦਾਹਰਨਾਂ ਨਾਲ ਸੰਪਰਕ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੁੰਜੀ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਇੱਕ ਉਪਲਬਧਤਾ ਜੁਰਮਾਨਾ ਅਦਾ ਕਰਨਾ ਪਵੇਗਾ)।

ਤਾਲਾ ਛੱਡ ਦਿਓ

ਇੱਕ ਲਾਕ ਜਾਰੀ ਕਰਨਾ ਇੱਕ ਸਧਾਰਨ ਕਾਰਵਾਈ ਹੈ ਜਿਸ ਲਈ ਸਿਰਫ਼ ਸਾਰੀਆਂ ਉਦਾਹਰਨਾਂ ਨੂੰ ਅਨਲੌਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਭਾਵੇਂ ਕਿ ਕਲਾਇੰਟ ਨੇ ਕਿਸੇ ਖਾਸ ਮੌਕੇ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਲਾਕ ਕੀਤਾ ਜਾਪਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਸੁਰੱਖਿਆ ਦੇ ਵਿਚਾਰ

ਕੀ ਐਲਗੋਰਿਦਮ ਸੁਰੱਖਿਅਤ ਹੈ? ਆਉ ਕਲਪਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਕਿ ਵੱਖ-ਵੱਖ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ।

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਆਓ ਇਹ ਮੰਨ ਲਈਏ ਕਿ ਕਲਾਇੰਟ ਜ਼ਿਆਦਾਤਰ ਮੌਕਿਆਂ 'ਤੇ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। ਹਰੇਕ ਉਦਾਹਰਨ ਵਿੱਚ ਸਾਰਿਆਂ ਲਈ ਇੱਕੋ ਜੀਵਨ ਕਾਲ ਵਾਲੀ ਇੱਕ ਕੁੰਜੀ ਹੋਵੇਗੀ। ਹਾਲਾਂਕਿ, ਇਹਨਾਂ ਕੁੰਜੀਆਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰੇ ਸਮੇਂ 'ਤੇ ਸਥਾਪਤ ਕੀਤੀ ਗਈ ਸੀ, ਇਸਲਈ ਉਹ ਵੱਖ-ਵੱਖ ਸਮੇਂ 'ਤੇ ਸਮਾਪਤ ਹੋ ਜਾਣਗੀਆਂ। ਪਰ, ਜੇਕਰ ਪਹਿਲੀ ਕੁੰਜੀ T1 (ਉਹ ਸਮਾਂ ਜੋ ਅਸੀਂ ਪਹਿਲੇ ਸਰਵਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੁਣਦੇ ਹਾਂ) ਤੋਂ ਮਾੜੇ ਸਮੇਂ 'ਤੇ ਸਥਾਪਤ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਆਖਰੀ ਕੁੰਜੀ T2 (ਜਿਸ ਸਮੇਂ ਜਵਾਬ ਪ੍ਰਾਪਤ ਹੋਇਆ ਸੀ) ਤੋਂ ਮਾੜੇ ਸਮੇਂ 'ਤੇ ਸਥਾਪਤ ਕੀਤੀ ਗਈ ਸੀ। ਆਖਰੀ ਸਰਵਰ ਤੋਂ), ਫਿਰ ਸਾਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਸੈੱਟ ਦੀ ਪਹਿਲੀ ਕੁੰਜੀ ਜਿਸਦੀ ਮਿਆਦ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਘੱਟੋ ਘੱਟ ਬਚੇਗੀ MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. ਬਾਕੀ ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ ਦੀ ਮਿਆਦ ਬਾਅਦ ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਵੇਗੀ, ਇਸਲਈ ਅਸੀਂ ਨਿਸ਼ਚਤ ਹੋ ਸਕਦੇ ਹਾਂ ਕਿ ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ ਘੱਟੋ-ਘੱਟ ਇਸ ਸਮੇਂ ਲਈ ਇੱਕੋ ਸਮੇਂ ਵੈਧ ਹੋਣਗੀਆਂ।

ਉਸ ਸਮੇਂ ਦੌਰਾਨ ਜਦੋਂ ਜ਼ਿਆਦਾਤਰ ਕੁੰਜੀਆਂ ਵੈਧ ਰਹਿੰਦੀਆਂ ਹਨ, ਕੋਈ ਹੋਰ ਕਲਾਇੰਟ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ, ਕਿਉਂਕਿ N/2+1 SET NX ਓਪਰੇਸ਼ਨ ਸਫਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਜੇਕਰ N/2+1 ਕੁੰਜੀਆਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ। ਇਸਲਈ, ਇੱਕ ਵਾਰ ਲਾਕ ਐਕਵਾਇਰ ਹੋ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਉਸੇ ਸਮੇਂ ਇਸਨੂੰ ਦੁਬਾਰਾ ਹਾਸਲ ਕਰਨਾ ਅਸੰਭਵ ਹੈ (ਇਹ ਆਪਸੀ ਬੇਦਖਲੀ ਸੰਪਤੀ ਦੀ ਉਲੰਘਣਾ ਕਰੇਗਾ)।
ਹਾਲਾਂਕਿ, ਅਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਇੱਕ ਤੋਂ ਵੱਧ ਗਾਹਕ ਇੱਕੋ ਸਮੇਂ ਸਫਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ।

ਜੇਕਰ ਕਲਾਇੰਟ ਨੇ ਅਧਿਕਤਮ ਲਾਕ ਅਵਧੀ ਤੋਂ ਲਗਭਗ ਜਾਂ ਵੱਧ ਸਮੇਂ ਲਈ ਜ਼ਿਆਦਾਤਰ ਉਦਾਹਰਨਾਂ ਨੂੰ ਲਾਕ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ ਲਾਕ ਨੂੰ ਅਵੈਧ ਮੰਨੇਗਾ ਅਤੇ ਉਦਾਹਰਨਾਂ ਨੂੰ ਅਨਲੌਕ ਕਰੇਗਾ। ਇਸ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ਼ ਉਸ ਕੇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਹੋਵੇਗਾ ਜਿਸ ਵਿੱਚ ਕਲਾਇੰਟ ਨੇ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਮਿਤੀ ਤੋਂ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਉਦਾਹਰਨਾਂ ਨੂੰ ਬਲਾਕ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਕੀਤਾ ਹੈ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਉਪਰੋਕਤ ਦਲੀਲ ਦੇ ਸਬੰਧ ਵਿੱਚ ਸਮੇਂ ਦੌਰਾਨ ਸ MIN_VALIDITY ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਲਾਕ ਦੁਬਾਰਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ, ਬਹੁਤ ਸਾਰੇ ਕਲਾਇੰਟ N/2+1 ਮੌਕਿਆਂ ਨੂੰ ਉਸੇ ਸਮੇਂ (ਜੋ ਕਿ ਪੜਾਅ 2 ਦੇ ਅੰਤ 'ਤੇ ਖਤਮ ਹੁੰਦਾ ਹੈ) ਨੂੰ ਲਾਕ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਗੇ, ਤਾਂ ਹੀ ਜਦੋਂ ਬਹੁਮਤ ਨੂੰ ਲਾਕ ਕਰਨ ਦਾ ਸਮਾਂ TTL ਸਮੇਂ ਤੋਂ ਵੱਧ ਸੀ, ਜੋ ਲਾਕ ਨੂੰ ਅਵੈਧ ਬਣਾਉਂਦਾ ਹੈ।

ਕੀ ਤੁਸੀਂ ਸੁਰੱਖਿਆ ਦਾ ਰਸਮੀ ਸਬੂਤ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹੋ, ਮੌਜੂਦਾ ਸਮਾਨ ਐਲਗੋਰਿਦਮ ਨੂੰ ਦਰਸਾ ਸਕਦੇ ਹੋ, ਜਾਂ ਉਪਰੋਕਤ ਵਿੱਚ ਕੋਈ ਬੱਗ ਲੱਭ ਸਕਦੇ ਹੋ?

ਪਹੁੰਚਯੋਗਤਾ ਦੇ ਵਿਚਾਰ

ਸਿਸਟਮ ਦੀ ਉਪਲਬਧਤਾ ਤਿੰਨ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:

1. ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਤਾਲੇ ਜਾਰੀ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਕੁੰਜੀਆਂ ਦੀ ਮਿਆਦ ਪੁੱਗ ਜਾਂਦੀ ਹੈ): ਕੁੰਜੀਆਂ ਅੰਤ ਵਿੱਚ ਤਾਲੇ ਲਈ ਵਰਤਣ ਲਈ ਦੁਬਾਰਾ ਉਪਲਬਧ ਹੋਣਗੀਆਂ।
2. ਇਹ ਤੱਥ ਕਿ ਗਾਹਕ ਆਮ ਤੌਰ 'ਤੇ ਤਾਲੇ ਨੂੰ ਹਟਾ ਕੇ ਇੱਕ ਦੂਜੇ ਦੀ ਮਦਦ ਕਰਦੇ ਹਨ ਜਦੋਂ ਲੋੜੀਂਦਾ ਲਾਕ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਾਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕੰਮ ਪੂਰਾ ਹੋ ਗਿਆ ਹੈ; ਇਸ ਲਈ ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਸਾਨੂੰ ਤਾਲਾ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਚਾਬੀਆਂ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਪਵੇਗੀ।
3. ਤੱਥ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਜ਼ਿਆਦਾਤਰ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਮਿਆਦ ਨਾਲੋਂ ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ। ਇਹ ਸਰੋਤਾਂ ਲਈ ਮੁਕਾਬਲਾ ਕਰਨ ਵੇਲੇ ਪੈਦਾ ਹੋਣ ਵਾਲੀ ਵੰਡ-ਦਿਮਾਗ ਦੀ ਸਥਿਤੀ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

ਹਾਲਾਂਕਿ, ਨੈੱਟਵਰਕ ਖੰਡਾਂ ਦੇ TTL ਦੇ ਬਰਾਬਰ ਇੱਕ ਉਪਲਬਧਤਾ ਜੁਰਮਾਨਾ ਹੈ, ਇਸਲਈ ਜੇਕਰ ਉੱਥੇ ਨਾਲ ਜੁੜੇ ਹਿੱਸੇ ਹਨ, ਤਾਂ ਜੁਰਮਾਨਾ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਕਲਾਇੰਟ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਜਾਰੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਨੂੰ ਰਿਪ ਕਰਦਾ ਹੈ।

ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਅਨੰਤ ਇਕਸਾਰ ਨੈੱਟਵਰਕ ਹਿੱਸੇ ਦਿੱਤੇ ਗਏ ਹਨ, ਇੱਕ ਸਿਸਟਮ ਅਨੰਤ ਸਮੇਂ ਲਈ ਅਣਉਪਲਬਧ ਰਹਿ ਸਕਦਾ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ, ਫੇਲਓਵਰ ਅਤੇ fsync

ਬਹੁਤ ਸਾਰੇ ਲੋਕ Redis ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਲਾਕ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਜਾਰੀ ਕਰਨ ਲਈ ਲੋੜੀਂਦੀ ਲੇਟੈਂਸੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਉੱਚ ਲਾਕ ਸਰਵਰ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਪ੍ਰਾਪਤੀਆਂ/ਰੀਲੀਜ਼ਾਂ ਦੀ ਗਿਣਤੀ ਜੋ ਪ੍ਰਤੀ ਸਕਿੰਟ ਪੂਰੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਲੋੜ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਲੇਟੈਂਸੀ ਨੂੰ ਘਟਾਉਣ ਲਈ N Redis ਸਰਵਰਾਂ ਨਾਲ ਸੰਚਾਰ ਕਰਨ ਦੀ ਰਣਨੀਤੀ ਹੈ। ਇਹ ਇੱਕ ਮਲਟੀਪਲੈਕਸਿੰਗ ਰਣਨੀਤੀ ਹੈ (ਜਾਂ "ਗਰੀਬ ਆਦਮੀ ਦੀ ਮਲਟੀਪਲੈਕਸਿੰਗ", ਜਿੱਥੇ ਸਾਕਟ ਨੂੰ ਨਾਨ-ਬਲਾਕਿੰਗ ਮੋਡ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ, ਸਾਰੀਆਂ ਕਮਾਂਡਾਂ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਕਮਾਂਡਾਂ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹਦਾ ਹੈ, ਇਹ ਮੰਨਦੇ ਹੋਏ ਕਿ ਕਲਾਇੰਟ ਅਤੇ ਹਰੇਕ ਉਦਾਹਰਨ ਦੇ ਵਿਚਕਾਰ ਰਾਉਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਸਮਾਨ ਹੈ) .

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

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

ਜੇਕਰ ਤੁਸੀਂ ਡੇਟਾ ਅੱਗੇ (AOF) ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਸਥਿਤੀ ਵਿੱਚ ਥੋੜ੍ਹਾ ਸੁਧਾਰ ਹੋਵੇਗਾ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ SHUTDOWN ਕਮਾਂਡ ਭੇਜ ਕੇ ਅਤੇ ਇਸਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਕੇ ਸਰਵਰ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਉਂਕਿ Redis ਵਿੱਚ ਮਿਆਦ ਪੁੱਗਣ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਸਰਵਰ ਦੇ ਬੰਦ ਹੋਣ 'ਤੇ ਵੀ ਸਮਾਂ ਜਾਰੀ ਰਹਿੰਦਾ ਹੈ, ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਲੋੜਾਂ ਠੀਕ ਹਨ। ਇਹ ਉਦੋਂ ਤੱਕ ਆਮ ਹੈ ਜਦੋਂ ਤੱਕ ਇੱਕ ਆਮ ਬੰਦ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਬਿਜਲੀ ਬੰਦ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ? ਜੇਕਰ Redis ਨੂੰ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, fsync ਨਾਲ ਹਰ ਸਕਿੰਟ ਡਿਸਕ ਉੱਤੇ ਸਮਕਾਲੀ, ਤਾਂ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਮੁੜ-ਚਾਲੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਸਾਡੇ ਕੋਲ ਸਾਡੀ ਕੁੰਜੀ ਨਹੀਂ ਹੋਵੇਗੀ। ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਅਸੀਂ ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਦੇ ਮੁੜ ਚਾਲੂ ਹੋਣ ਦੇ ਦੌਰਾਨ ਲਾਕ ਸੁਰੱਖਿਆ ਦੀ ਗਰੰਟੀ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਯੋਗ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ fsync=always ਲੰਬੇ ਸਮੇਂ ਦੇ ਡੇਟਾ ਸਟੋਰੇਜ ਲਈ ਸੈਟਿੰਗਾਂ ਵਿੱਚ। ਇਹ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰ ਦੇਵੇਗਾ, CP ਸਿਸਟਮਾਂ ਦੇ ਪੱਧਰ ਤੱਕ, ਜੋ ਕਿ ਰਵਾਇਤੀ ਤੌਰ 'ਤੇ ਵੰਡੇ ਗਏ ਲਾਕ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।

ਪਰ ਸਥਿਤੀ ਇਸ ਤੋਂ ਬਿਹਤਰ ਹੈ ਜਿੰਨੀ ਇਹ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਜਾਪਦੀ ਹੈ. ਸਿਧਾਂਤ ਵਿੱਚ, ਐਲਗੋਰਿਦਮ ਦੀ ਸੁਰੱਖਿਆ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਜਦੋਂ ਇੱਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਉਦਾਹਰਣ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਹੁਣ ਕਿਸੇ ਵੀ ਲਾਕ ਵਿੱਚ ਹਿੱਸਾ ਨਹੀਂ ਲੈ ਰਿਹਾ ਹੈ ਜੋ ਵਰਤਮਾਨ ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ ਹੈ।

ਇਸ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ਼ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਇੱਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਉਦਾਹਰਣ ਸਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਗਏ ਅਧਿਕਤਮ TTL ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਧ ਸਮੇਂ ਲਈ ਅਣਉਪਲਬਧ ਰਹਿੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਮਿਆਦ ਪੁੱਗਣ ਦੀ ਮਿਤੀ ਅਤੇ ਅਸਫਲਤਾ ਦੇ ਸਮੇਂ ਸਰਗਰਮ ਹੋਣ ਵਾਲੀਆਂ ਸਾਰੀਆਂ ਕੁੰਜੀਆਂ ਦੇ ਆਟੋਮੈਟਿਕ ਰੀਲੀਜ਼ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰਾਂਗੇ।

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

ਅਸੀਂ ਐਲਗੋਰਿਦਮ ਦੀ ਉਪਲਬਧਤਾ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ: ਅਸੀਂ ਬਲਾਕਿੰਗ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ

ਜੇਕਰ ਕਲਾਇੰਟਸ ਦੁਆਰਾ ਕੀਤੇ ਗਏ ਕੰਮ ਵਿੱਚ ਛੋਟੇ ਕਦਮ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਡਿਫਾਲਟ ਲਾਕ ਦੀ ਮਿਆਦ ਨੂੰ ਘਟਾਉਣਾ ਅਤੇ ਤਾਲੇ ਨੂੰ ਵਧਾਉਣ ਲਈ ਇੱਕ ਵਿਧੀ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸੰਭਵ ਹੈ। ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਜੇਕਰ ਕਲਾਇੰਟ ਕੰਪਿਊਟਿੰਗ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਹੈ ਅਤੇ ਲੌਕ ਮਿਆਦ ਪੁੱਗਣ ਦਾ ਮੁੱਲ ਖਤਰਨਾਕ ਤੌਰ 'ਤੇ ਘੱਟ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਲੂਆ ਸਕ੍ਰਿਪਟ ਉਹਨਾਂ ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਲਈ ਭੇਜ ਸਕਦੇ ਹੋ ਜੋ ਕੁੰਜੀ ਦੇ TTL ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ ਜੇਕਰ ਕੁੰਜੀ ਅਜੇ ਵੀ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਸਦਾ ਮੁੱਲ ਅਜੇ ਵੀ ਇੱਕ ਬੇਤਰਤੀਬ ਮੁੱਲ ਹੈ ਜਦੋਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਤਾਲਾ ਹਾਸਲ ਕੀਤਾ ਸੀ।

ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਕੇਵਲ ਇੱਕ ਲਾਕ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੇਕਰ ਉਹ ਵੈਧਤਾ ਅਵਧੀ ਦੇ ਅੰਦਰ ਜ਼ਿਆਦਾਤਰ ਉਦਾਹਰਨਾਂ ਨੂੰ ਲਾਕ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੁੰਦਾ ਹੈ।

ਇਹ ਸੱਚ ਹੈ, ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਐਲਗੋਰਿਦਮ ਨਹੀਂ ਬਦਲਦਾ, ਇਸਲਈ ਤਾਲੇ ਹਾਸਲ ਕਰਨ ਲਈ ਵੱਧ ਤੋਂ ਵੱਧ ਵਾਰ-ਵਾਰ ਕੋਸ਼ਿਸ਼ਾਂ ਨੂੰ ਸੀਮਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਪਹੁੰਚਯੋਗਤਾ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਜਾਵੇਗੀ।

ਸਰੋਤ: www.habr.com