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

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

Redis PUB/SUB

Redis Pub/Sub ਇੱਕ ਸਧਾਰਨ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਡੇ ਮੁੱਖ-ਮੁੱਲ ਸਟੋਰ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਹਾਲਾਂਕਿ, ਸਾਦਗੀ ਇੱਕ ਕੀਮਤ 'ਤੇ ਆਉਂਦੀ ਹੈ:

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

Redis ਸੂਚੀ

ਰੈਡਿਸ ਲਿਸਟ ਇੱਕ ਡੇਟਾ ਢਾਂਚਾ ਹੈ ਜੋ ਰੀਡ ਕਮਾਂਡਾਂ ਨੂੰ ਬਲੌਕ ਕਰਨ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਸੂਚੀ ਦੇ ਸ਼ੁਰੂ ਜਾਂ ਅੰਤ ਤੋਂ ਸੁਨੇਹੇ ਜੋੜ ਅਤੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ। ਇਸ ਢਾਂਚੇ ਦੇ ਅਧਾਰ ਤੇ, ਤੁਸੀਂ ਆਪਣੇ ਵੰਡੇ ਹੋਏ ਸਿਸਟਮ ਲਈ ਇੱਕ ਵਧੀਆ ਸਟੈਕ ਜਾਂ ਕਤਾਰ ਬਣਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਕਾਫ਼ੀ ਹੋਵੇਗਾ. Redis Pub/Sub ਤੋਂ ਮੁੱਖ ਅੰਤਰ:

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

ਸਟ੍ਰੀਮ ਨਾਲ ਜਾਣ-ਪਛਾਣ

ਇੱਕ ਸਟ੍ਰੀਮ ਵਿੱਚ ਇੱਕ ਇੰਦਰਾਜ਼ ਜੋੜਨਾ

ਦੀ ਟੀਮ XADD ਸਟ੍ਰੀਮ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਐਂਟਰੀ ਜੋੜਦਾ ਹੈ। ਇੱਕ ਰਿਕਾਰਡ ਸਿਰਫ਼ ਇੱਕ ਸਤਰ ਨਹੀਂ ਹੁੰਦਾ, ਇਸ ਵਿੱਚ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਮੁੱਖ-ਮੁੱਲ ਦੇ ਜੋੜੇ ਹੁੰਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, ਹਰੇਕ ਐਂਟਰੀ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਢਾਂਚਾਗਤ ਹੈ ਅਤੇ ਇੱਕ CSV ਫਾਈਲ ਦੀ ਬਣਤਰ ਵਰਗੀ ਹੈ।

> XADD mystream * sensor-id 1234 temperature 19.8
1518951480106-0

ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਨਾਮ (ਕੁੰਜੀ) "ਮਾਈਸਟ੍ਰੀਮ" ਦੇ ਨਾਲ ਸਟ੍ਰੀਮ ਵਿੱਚ ਦੋ ਖੇਤਰ ਜੋੜਦੇ ਹਾਂ: ਕ੍ਰਮਵਾਰ "1234" ਅਤੇ "19.8" ਮੁੱਲਾਂ ਦੇ ਨਾਲ "ਸੈਂਸਰ-ਆਈਡੀ" ਅਤੇ "ਤਾਪਮਾਨ"। ਦੂਜੀ ਦਲੀਲ ਦੇ ਤੌਰ 'ਤੇ, ਕਮਾਂਡ ਇੱਕ ਪਛਾਣਕਰਤਾ ਲੈਂਦੀ ਹੈ ਜੋ ਇੰਦਰਾਜ਼ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਵੇਗਾ - ਇਹ ਪਛਾਣਕਰਤਾ ਸਟ੍ਰੀਮ ਵਿੱਚ ਹਰੇਕ ਐਂਟਰੀ ਦੀ ਵਿਲੱਖਣ ਪਛਾਣ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਕੇਸ ਵਿੱਚ ਅਸੀਂ * ਪਾਸ ਕੀਤਾ ਕਿਉਂਕਿ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ ਕਿ Redis ਸਾਡੇ ਲਈ ਇੱਕ ਨਵੀਂ ID ਤਿਆਰ ਕਰੇ। ਹਰ ਨਵੀਂ ਆਈਡੀ ਵਧੇਗੀ। ਇਸ ਲਈ, ਹਰੇਕ ਨਵੀਂ ਐਂਟਰੀ ਵਿੱਚ ਪਿਛਲੀਆਂ ਐਂਟਰੀਆਂ ਦੇ ਸਬੰਧ ਵਿੱਚ ਇੱਕ ਉੱਚ ਪਛਾਣਕਰਤਾ ਹੋਵੇਗਾ।

ਪਛਾਣਕਰਤਾ ਫਾਰਮੈਟ

ਕਮਾਂਡ ਦੁਆਰਾ ਵਾਪਸ ਕੀਤੀ ਐਂਟਰੀ ID XADD, ਦੋ ਭਾਗਾਂ ਦੇ ਸ਼ਾਮਲ ਹਨ:

{millisecondsTime}-{sequenceNumber}

ਮਿਲੀਸਕਿੰਟ ਦਾ ਸਮਾਂ - ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਯੂਨਿਕਸ ਸਮਾਂ (ਰੇਡਿਸ ਸਰਵਰ ਸਮਾਂ)। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਮੌਜੂਦਾ ਸਮਾਂ ਪਿਛਲੀ ਰਿਕਾਰਡਿੰਗ ਦੇ ਸਮੇਂ ਦੇ ਬਰਾਬਰ ਜਾਂ ਘੱਟ ਹੈ, ਤਾਂ ਪਿਛਲੀ ਰਿਕਾਰਡਿੰਗ ਦੀ ਟਾਈਮਸਟੈਂਪ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਲਈ, ਜੇਕਰ ਸਰਵਰ ਦਾ ਸਮਾਂ ਸਮੇਂ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨਵਾਂ ਪਛਾਣਕਰਤਾ ਅਜੇ ਵੀ ਵਾਧੇ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖੇਗਾ।

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

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

ਜੇ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਉਪਭੋਗਤਾ ਨੂੰ ਆਪਣਾ ਪਛਾਣਕਰਤਾ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਕਿਸੇ ਬਾਹਰੀ ਸਿਸਟਮ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਸਨੂੰ ਕਮਾਂਡ ਨੂੰ ਭੇਜ ਸਕਦੇ ਹਾਂ XADD * ਦੀ ਬਜਾਏ ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:

> XADD somestream 0-1 field value
0-1
> XADD somestream 0-2 foo bar
0-2

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਤੁਹਾਨੂੰ ID ਵਾਧੇ ਦੀ ਖੁਦ ਨਿਗਰਾਨੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਨਿਊਨਤਮ ਪਛਾਣਕਰਤਾ "0-1" ਹੈ, ਇਸਲਈ ਕਮਾਂਡ ਕਿਸੇ ਹੋਰ ਪਛਾਣਕਰਤਾ ਨੂੰ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗੀ ਜੋ "0-1" ਦੇ ਬਰਾਬਰ ਜਾਂ ਘੱਟ ਹੋਵੇ।

> XADD somestream 0-1 foo bar
(error) ERR The ID specified in XADD is equal or smaller than the target stream top item

ਪ੍ਰਤੀ ਸਟ੍ਰੀਮ ਰਿਕਾਰਡਾਂ ਦੀ ਸੰਖਿਆ

ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਟ੍ਰੀਮ ਵਿੱਚ ਰਿਕਾਰਡਾਂ ਦੀ ਗਿਣਤੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੰਭਵ ਹੈ XLEN. ਸਾਡੀ ਉਦਾਹਰਨ ਲਈ, ਇਹ ਕਮਾਂਡ ਹੇਠ ਦਿੱਤੇ ਮੁੱਲ ਨੂੰ ਵਾਪਸ ਕਰੇਗੀ:

> XLEN somestream
(integer) 2

ਰੇਂਜ ਸਵਾਲ - XRANGE ਅਤੇ XREVRANGE

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

> XRANGE mystream - +
1) 1) 1518951480106-0
   2) 1) "sensor-id"
      2) "1234"
      3) "temperature"
      4) "19.8"
2) 1) 1518951482479-0
   2) 1) "sensor-id"
      2) "9999"
      3) "temperature"
      4) "18.2"

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

> XRANGE mystream 1518951480106 1518951480107
1) 1) 1518951480106-0
   2) 1) "sensor-id"
      2) "1234"
      3) "temperature"
      4) "19.8"

ਇਸ ਰੇਂਜ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਐਂਟਰੀ ਹੈ, ਹਾਲਾਂਕਿ ਅਸਲ ਡਾਟਾ ਸੈੱਟਾਂ ਵਿੱਚ ਵਾਪਸ ਕੀਤੇ ਗਏ ਨਤੀਜੇ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਕਰਕੇ ਐਕਸਰੇਂਜ COUNT ਵਿਕਲਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਮਾਤਰਾ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਕੇ, ਅਸੀਂ ਸਿਰਫ਼ ਪਹਿਲੇ N ਰਿਕਾਰਡਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਜੇ ਸਾਨੂੰ ਅਗਲੇ N ਰਿਕਾਰਡ (ਪੰਨਾਬੰਦੀ) ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸੀਂ ਆਖਰੀ ਪ੍ਰਾਪਤ ਆਈਡੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਇਸ ਨੂੰ ਵਧਾ ਸਕਦੇ ਹਾਂ ਕ੍ਰਮ ਸੰਖਿਆ ਇੱਕ ਦੁਆਰਾ ਅਤੇ ਦੁਬਾਰਾ ਪੁੱਛੋ. ਆਓ ਇਸ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਣ ਵਿੱਚ ਵੇਖੀਏ. ਅਸੀਂ 10 ਤੱਤਾਂ ਨੂੰ ਜੋੜਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ XADD (ਇਹ ਮੰਨ ਕੇ ਕਿ ਮਾਈਸਟ੍ਰੀਮ ਪਹਿਲਾਂ ਹੀ 10 ਤੱਤਾਂ ਨਾਲ ਭਰੀ ਹੋਈ ਸੀ)। ਪ੍ਰਤੀ ਕਮਾਂਡ 2 ਤੱਤ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਦੁਹਰਾਓ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਪੂਰੀ ਰੇਂਜ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ ਪਰ 2 ਦੇ ਬਰਾਬਰ COUNT ਨਾਲ।

> XRANGE mystream - + COUNT 2
1) 1) 1519073278252-0
   2) 1) "foo"
      2) "value_1"
2) 1) 1519073279157-0
   2) 1) "foo"
      2) "value_2"

ਅਗਲੇ ਦੋ ਤੱਤਾਂ ਦੇ ਨਾਲ ਦੁਹਰਾਉਣਾ ਜਾਰੀ ਰੱਖਣ ਲਈ, ਸਾਨੂੰ ਪ੍ਰਾਪਤ ਹੋਈ ਆਖਰੀ ID, ਭਾਵ 1519073279157-0 ਨੂੰ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਇਸ ਵਿੱਚ 1 ਜੋੜੋ ਕ੍ਰਮ ਸੰਖਿਆ.
ਨਤੀਜੇ ਵਜੋਂ ਆਈਡੀ, ਇਸ ਕੇਸ ਵਿੱਚ 1519073279157-1, ਨੂੰ ਹੁਣ ਅਗਲੀ ਕਾਲ ਲਈ ਰੇਂਜ ਆਰਗੂਮੈਂਟ ਦੀ ਨਵੀਂ ਸ਼ੁਰੂਆਤ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ ਐਕਸਰੇਂਜ:

> XRANGE mystream 1519073279157-1 + COUNT 2
1) 1) 1519073280281-0
   2) 1) "foo"
      2) "value_3"
2) 1) 1519073281432-0
   2) 1) "foo"
      2) "value_4"

ਇਤਆਦਿ. ਕਿਉਂਕਿ ਗੁੰਝਲਤਾ ਐਕਸਰੇਂਜ ਖੋਜ ਕਰਨ ਲਈ O(log(N)) ਹੈ ਅਤੇ ਫਿਰ M ਐਲੀਮੈਂਟਸ ਨੂੰ ਵਾਪਸ ਕਰਨ ਲਈ O(M) ਹੈ, ਫਿਰ ਹਰੇਕ ਦੁਹਰਾਓ ਕਦਮ ਤੇਜ਼ ਹੁੰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਐਕਸਰੇਂਜ ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਦੁਹਰਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਦੀ ਟੀਮ XREVRANGE ਦੇ ਬਰਾਬਰ ਹੈ ਐਕਸਰੇਂਜ, ਪਰ ਉਲਟ ਕ੍ਰਮ ਵਿੱਚ ਤੱਤ ਵਾਪਸ ਕਰਦਾ ਹੈ:

> XREVRANGE mystream + - COUNT 1
1) 1) 1519073287312-0
   2) 1) "foo"
      2) "value_10"

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਕਮਾਂਡ XREVRANGE ਰੇਂਜ ਆਰਗੂਮੈਂਟਾਂ ਨੂੰ ਉਲਟ ਕ੍ਰਮ ਵਿੱਚ ਸ਼ੁਰੂ ਅਤੇ ਬੰਦ ਕਰਦਾ ਹੈ।

XREAD ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਵੀਆਂ ਐਂਟਰੀਆਂ ਪੜ੍ਹੀਆਂ ਜਾ ਰਹੀਆਂ ਹਨ

ਅਕਸਰ ਕੰਮ ਇੱਕ ਸਟ੍ਰੀਮ ਦੀ ਗਾਹਕੀ ਲੈਣ ਅਤੇ ਸਿਰਫ ਨਵੇਂ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਸੰਕਲਪ Redis Pub/Sub ਜਾਂ Redis ਸੂਚੀ ਨੂੰ ਬਲਾਕ ਕਰਨ ਦੇ ਸਮਾਨ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ Redis ਸਟ੍ਰੀਮ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਬੁਨਿਆਦੀ ਅੰਤਰ ਹਨ:

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

ਤੁਸੀਂ ਇੱਕ ਥ੍ਰੈਡ ਦੀ ਗਾਹਕੀ ਲੈ ਸਕਦੇ ਹੋ ਅਤੇ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਵੇਂ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ XREAD. ਇਸ ਤੋਂ ਥੋੜ੍ਹਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ ਐਕਸਰੇਂਜ, ਇਸ ਲਈ ਅਸੀਂ ਪਹਿਲਾਂ ਸਰਲ ਉਦਾਹਰਣਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਾਂਗੇ।

> XREAD COUNT 2 STREAMS mystream 0
1) 1) "mystream"
   2) 1) 1) 1519073278252-0
         2) 1) "foo"
            2) "value_1"
      2) 1) 1519073279157-0
         2) 1) "foo"
            2) "value_2"

ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਇੱਕ ਗੈਰ-ਬਲੌਕਿੰਗ ਫਾਰਮ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ XREAD. ਨੋਟ ਕਰੋ ਕਿ COUNT ਵਿਕਲਪ ਵਿਕਲਪਿਕ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਸਿਰਫ ਲੋੜੀਂਦਾ ਕਮਾਂਡ ਵਿਕਲਪ ਸਟ੍ਰੀਮਜ਼ ਵਿਕਲਪ ਹੈ, ਜੋ ਅਨੁਸਾਰੀ ਅਧਿਕਤਮ ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਸਟ੍ਰੀਮਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਸੀਂ "ਸਟ੍ਰੀਮਜ਼ ਮਾਈਸਟ੍ਰੀਮ 0" ਲਿਖਿਆ - ਅਸੀਂ "0-0" ਤੋਂ ਵੱਧ ਪਛਾਣਕਰਤਾ ਦੇ ਨਾਲ ਮਾਈਸਟ੍ਰੀਮ ਸਟ੍ਰੀਮ ਦੇ ਸਾਰੇ ਰਿਕਾਰਡ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਉਦਾਹਰਨ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਕਮਾਂਡ ਥ੍ਰੈਡ ਦਾ ਨਾਮ ਵਾਪਸ ਕਰਦੀ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਥ੍ਰੈਡਾਂ ਦੀ ਗਾਹਕੀ ਲੈ ਸਕਦੇ ਹਾਂ। ਅਸੀਂ ਲਿਖ ਸਕਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, "ਸਟ੍ਰੀਮਜ਼ ਮਾਈਸਟ੍ਰੀਮ ਅਦਰਸਟ੍ਰੀਮ 0 0"। ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਸਟ੍ਰੀਮ ਵਿਕਲਪ ਦੇ ਬਾਅਦ ਸਾਨੂੰ ਪਹਿਲਾਂ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਸਟ੍ਰੀਮਾਂ ਦੇ ਨਾਮ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਇੱਕ ਸੂਚੀ।

ਇਸ ਸਧਾਰਨ ਰੂਪ ਵਿੱਚ ਕਮਾਂਡ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਕੁਝ ਖਾਸ ਨਹੀਂ ਕਰਦਾ ਹੈ ਐਕਸਰੇਂਜ. ਹਾਲਾਂਕਿ, ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਆਸਾਨੀ ਨਾਲ ਮੋੜ ਸਕਦੇ ਹਾਂ XREAD ਬਲੌਕ ਆਰਗੂਮੈਂਟ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦੇ ਹੋਏ, ਇੱਕ ਬਲਾਕਿੰਗ ਕਮਾਂਡ ਲਈ:

> XREAD BLOCK 0 STREAMS mystream $

ਉਪਰੋਕਤ ਉਦਾਹਰਨ ਵਿੱਚ, ਇੱਕ ਨਵਾਂ ਬਲੌਕ ਵਿਕਲਪ 0 ਮਿਲੀਸਕਿੰਟ (ਇਸਦਾ ਮਤਲਬ ਹੈ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਉਡੀਕ ਕਰਨਾ) ਦੇ ਸਮਾਂ ਸਮਾਪਤੀ ਨਾਲ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮਾਈਸਟ੍ਰੀਮ ਸਟ੍ਰੀਮ ਲਈ ਆਮ ਪਛਾਣਕਰਤਾ ਪਾਸ ਕਰਨ ਦੀ ਬਜਾਏ, ਇੱਕ ਵਿਸ਼ੇਸ਼ ਪਛਾਣਕਰਤਾ $ ਪਾਸ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਸ ਵਿਸ਼ੇਸ਼ ਪਛਾਣਕਰਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ XREAD mystream ਵਿੱਚ ਵੱਧ ਤੋਂ ਵੱਧ ਪਛਾਣਕਰਤਾ ਨੂੰ ਪਛਾਣਕਰਤਾ ਵਜੋਂ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਲਈ ਅਸੀਂ ਸਿਰਫ਼ ਉਸ ਸਮੇਂ ਤੋਂ ਹੀ ਨਵੇਂ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ ਜਦੋਂ ਅਸੀਂ ਸੁਣਨਾ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ। ਕੁਝ ਤਰੀਕਿਆਂ ਨਾਲ ਇਹ ਯੂਨਿਕਸ "tail -f" ਕਮਾਂਡ ਦੇ ਸਮਾਨ ਹੈ।

ਨੋਟ ਕਰੋ ਕਿ ਬਲੌਕ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਸਾਨੂੰ ਵਿਸ਼ੇਸ਼ ਪਛਾਣਕਰਤਾ $ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਅਸੀਂ ਸਟ੍ਰੀਮ ਵਿੱਚ ਮੌਜੂਦ ਕਿਸੇ ਵੀ ਪਛਾਣਕਰਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਾਂ। ਜੇਕਰ ਟੀਮ ਬਲੌਕ ਕੀਤੇ ਬਿਨਾਂ ਸਾਡੀ ਬੇਨਤੀ ਦੀ ਤੁਰੰਤ ਸੇਵਾ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਇਹ ਅਜਿਹਾ ਕਰੇਗੀ, ਨਹੀਂ ਤਾਂ ਇਹ ਬਲੌਕ ਕਰ ਦੇਵੇਗੀ।

ਬਲਾਕਿੰਗ XREAD ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਥ੍ਰੈੱਡਾਂ ਨੂੰ ਵੀ ਸੁਣ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਦੇ ਨਾਮ ਦੱਸਣ ਦੀ ਲੋੜ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕਮਾਂਡ ਪਹਿਲੀ ਸਟ੍ਰੀਮ ਦਾ ਰਿਕਾਰਡ ਵਾਪਸ ਕਰੇਗੀ ਜਿਸਨੇ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਸੀ। ਦਿੱਤੇ ਗਏ ਥ੍ਰੈਡ ਲਈ ਬਲੌਕ ਕੀਤੇ ਗਏ ਪਹਿਲੇ ਗਾਹਕ ਨੂੰ ਪਹਿਲਾਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ।

ਖਪਤਕਾਰ ਸਮੂਹ

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

ਜੇਕਰ ਅਸੀਂ ਕਲਪਨਾ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ ਤਿੰਨ ਗਾਹਕ C1, C2, C3 ਅਤੇ ਇੱਕ ਥਰਿੱਡ ਹੈ ਜਿਸ ਵਿੱਚ ਸੁਨੇਹੇ 1, 2, 3, 4, 5, 6, 7 ਹਨ, ਤਾਂ ਸੁਨੇਹੇ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਵਾਂਗ ਦਿੱਤੇ ਜਾਣਗੇ:

1 -> C1
2 -> C2
3 -> C3
4 -> C1
5 -> C2
6 -> C3
7 -> C1

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

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

ਇੱਕ ਅਰਥ ਵਿੱਚ, ਸਮੂਹ ਦੀ ਸਥਿਤੀ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

+----------------------------------------+
| consumer_group_name: mygroup          
| consumer_group_stream: somekey        
| last_delivered_id: 1292309234234-92    
|                                                           
| consumers:                                          
|    "consumer-1" with pending messages  
|       1292309234234-4                          
|       1292309234232-8                          
|    "consumer-42" with pending messages 
|       ... (and so forth)                             
+----------------------------------------+

ਹੁਣ ਖਪਤਕਾਰ ਸਮੂਹ ਲਈ ਮੁੱਖ ਕਮਾਂਡਾਂ ਨਾਲ ਜਾਣੂ ਹੋਣ ਦਾ ਸਮਾਂ ਆ ਗਿਆ ਹੈ, ਅਰਥਾਤ:

• XGROUP ਗਰੁੱਪ ਬਣਾਉਣ, ਨਸ਼ਟ ਕਰਨ ਅਤੇ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ
• XREADGROUP ਗਰੁੱਪ ਦੁਆਰਾ ਸਟ੍ਰੀਮ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ
• XACK - ਇਹ ਕਮਾਂਡ ਸਬਸਕ੍ਰਾਈਬਰ ਨੂੰ ਸੁਨੇਹੇ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਸੰਸਾਧਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ

ਖਪਤਕਾਰ ਸਮੂਹ ਦੀ ਸਿਰਜਣਾ

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

> XGROUP CREATE mystream mygroup $
OK

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

ਹੁਣ ਜਦੋਂ ਗਰੁੱਪ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਅਸੀਂ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਰੰਤ ਸੁਨੇਹਿਆਂ ਨੂੰ ਪੜ੍ਹਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ XREADGROUP. ਇਹ ਹੁਕਮ ਬਹੁਤ ਸਮਾਨ ਹੈ XREAD ਅਤੇ ਵਿਕਲਪਿਕ ਬਲਾਕ ਵਿਕਲਪ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਕ ਲੋੜੀਂਦਾ GROUP ਵਿਕਲਪ ਹੈ ਜੋ ਹਮੇਸ਼ਾ ਦੋ ਆਰਗੂਮੈਂਟਾਂ ਨਾਲ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ: ਸਮੂਹ ਦਾ ਨਾਮ ਅਤੇ ਗਾਹਕ ਦਾ ਨਾਮ। COUNT ਵਿਕਲਪ ਵੀ ਸਮਰਥਿਤ ਹੈ।

ਥ੍ਰੈੱਡ ਨੂੰ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਇੱਥੇ ਕੁਝ ਸੰਦੇਸ਼ ਰੱਖ ਦੇਈਏ:

> XADD mystream * message apple
1526569495631-0
> XADD mystream * message orange
1526569498055-0
> XADD mystream * message strawberry
1526569506935-0
> XADD mystream * message apricot
1526569535168-0
> XADD mystream * message banana
1526569544280-0

ਆਉ ਹੁਣ ਸਮੂਹ ਦੁਆਰਾ ਇਸ ਸਟ੍ਰੀਮ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ:

> XREADGROUP GROUP mygroup Alice COUNT 1 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526569495631-0
         2) 1) "message"
            2) "apple"

ਉਪਰੋਕਤ ਹੁਕਮ ਸ਼ਬਦਾਵਲੀ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹਦਾ ਹੈ:

"ਮੈਂ, ਸਬਸਕ੍ਰਾਈਬਰ ਐਲਿਸ, ਮਾਈਗਰੁੱਪ ਦਾ ਮੈਂਬਰ, ਮਾਈਸਟ੍ਰੀਮ ਤੋਂ ਇੱਕ ਸੁਨੇਹਾ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦਾ ਹਾਂ ਜੋ ਪਹਿਲਾਂ ਕਦੇ ਕਿਸੇ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ ਗਿਆ ਸੀ।"

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

ਨਾਲ ਹੀ, ਖਾਸ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਅਸਲੀ ਪਛਾਣਕਰਤਾ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਕਿ 0 ਜਾਂ ਕੋਈ ਹੋਰ ਵੈਧ ਪਛਾਣਕਰਤਾ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕਮਾਂਡ XREADGROUP ਤੁਹਾਨੂੰ "ਬਕਾਇਆ" ਦੀ ਸਥਿਤੀ ਵਾਲੇ ਸੁਨੇਹਿਆਂ ਦਾ ਇਤਿਹਾਸ ਵਾਪਸ ਕਰੇਗਾ ਜੋ ਨਿਸ਼ਚਿਤ ਗਾਹਕ (ਐਲਿਸ) ਨੂੰ ਦਿੱਤੇ ਗਏ ਸਨ ਪਰ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਜੇ ਤੱਕ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ XACK.

ਅਸੀਂ ਬਿਨਾਂ ਵਿਕਲਪ ਦੇ ID 0 ਨੂੰ ਤੁਰੰਤ ਨਿਰਧਾਰਿਤ ਕਰਕੇ ਇਸ ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ COUNT. ਅਸੀਂ ਸਿਰਫ਼ ਇੱਕ ਲੰਬਿਤ ਸੁਨੇਹਾ ਵੇਖਾਂਗੇ, ਯਾਨੀ ਐਪਲ ਸੁਨੇਹਾ:

> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) 1) 1) 1526569495631-0
         2) 1) "message"
            2) "apple"

ਹਾਲਾਂਕਿ, ਜੇਕਰ ਅਸੀਂ ਸੁਨੇਹੇ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਪ੍ਰਕਿਰਿਆ ਕੀਤੇ ਜਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇਹ ਹੁਣ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਹੋਵੇਗਾ:

> XACK mystream mygroup 1526569495631-0
(integer) 1
> XREADGROUP GROUP mygroup Alice STREAMS mystream 0
1) 1) "mystream"
   2) (empty list or set)

ਹੁਣ ਕੁਝ ਪੜ੍ਹਨ ਲਈ ਬੌਬ ਦੀ ਵਾਰੀ ਹੈ:

> XREADGROUP GROUP mygroup Bob COUNT 2 STREAMS mystream >
1) 1) "mystream"
   2) 1) 1) 1526569498055-0
         2) 1) "message"
            2) "orange"
      2) 1) 1526569506935-0
         2) 1) "message"
            2) "strawberry"

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

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

ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਕੁਝ ਗੱਲਾਂ ਹਨ:

• ਜਿਵੇਂ ਹੀ ਗਾਹਕ ਸੰਦੇਸ਼ ਨੂੰ ਹੁਕਮ ਸਮਝਦਾ ਹੈ XREADGROUP, ਇਹ ਸੁਨੇਹਾ "ਬਕਾਇਆ" ਸਥਿਤੀ ਵਿੱਚ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਖਾਸ ਗਾਹਕ ਨੂੰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਹੋਰ ਸਮੂਹ ਗਾਹਕ ਇਸ ਸੰਦੇਸ਼ ਨੂੰ ਪੜ੍ਹ ਨਹੀਂ ਸਕਣਗੇ।
• ਗਾਹਕਾਂ ਨੂੰ ਪਹਿਲੇ ਜ਼ਿਕਰ 'ਤੇ ਆਪਣੇ ਆਪ ਹੀ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬਣਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।
• ਦੀ ਸਹਾਇਤਾ ਨਾਲ XREADGROUP ਤੁਸੀਂ ਇੱਕੋ ਸਮੇਂ ਕਈ ਵੱਖ-ਵੱਖ ਥ੍ਰੈੱਡਾਂ ਤੋਂ ਸੁਨੇਹੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਹਾਲਾਂਕਿ ਇਹ ਕੰਮ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹਰੇਕ ਥ੍ਰੈਡ ਲਈ ਇੱਕੋ ਨਾਮ ਨਾਲ ਗਰੁੱਪ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ XGROUP

ਇੱਕ ਅਸਫਲਤਾ ਦੇ ਬਾਅਦ ਰਿਕਵਰੀ

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ XPENDING, ਜੋ "ਪੈਂਡਿੰਗ" ਸਥਿਤੀ ਦੇ ਨਾਲ ਸਮੂਹ ਵਿੱਚ ਸਾਰੇ ਸੁਨੇਹੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਸਦੇ ਸਰਲ ਰੂਪ ਵਿੱਚ, ਕਮਾਂਡ ਨੂੰ ਸਿਰਫ ਦੋ ਆਰਗੂਮੈਂਟਾਂ ਨਾਲ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ: ਥਰਿੱਡ ਨਾਮ ਅਤੇ ਸਮੂਹ ਦਾ ਨਾਮ:

> XPENDING mystream mygroup
1) (integer) 2
2) 1526569498055-0
3) 1526569506935-0
4) 1) 1) "Bob"
      2) "2"

ਟੀਮ ਨੇ ਪੂਰੇ ਸਮੂਹ ਅਤੇ ਹਰੇਕ ਗਾਹਕ ਲਈ ਅਣਪ੍ਰੋਸੈਸ ਕੀਤੇ ਸੰਦੇਸ਼ਾਂ ਦੀ ਗਿਣਤੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕੀਤੀ। ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਦੋ ਬਕਾਇਆ ਸੁਨੇਹਿਆਂ ਵਾਲਾ ਬੌਬ ਹੈ ਕਿਉਂਕਿ ਐਲਿਸ ਵੱਲੋਂ ਬੇਨਤੀ ਕੀਤੇ ਗਏ ਸਿਰਫ਼ ਸੁਨੇਹੇ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਸੀ XACK.

ਅਸੀਂ ਹੋਰ ਦਲੀਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਹੋਰ ਜਾਣਕਾਰੀ ਲਈ ਬੇਨਤੀ ਕਰ ਸਕਦੇ ਹਾਂ:

XPENDING {key} {groupname} [{start-id} {end-id} {count} [{consumer-name}]]
{start-id} {end-id} - ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਰੇਂਜ (ਤੁਸੀਂ “-” ਅਤੇ “+” ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ)
{count} — ਡਿਲੀਵਰੀ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ
{consumer-name} - ਸਮੂਹ ਦਾ ਨਾਮ

> XPENDING mystream mygroup - + 10
1) 1) 1526569498055-0
   2) "Bob"
   3) (integer) 74170458
   4) (integer) 1
2) 1) 1526569506935-0
   2) "Bob"
   3) (integer) 74170458
   4) (integer) 1

ਹੁਣ ਸਾਡੇ ਕੋਲ ਹਰੇਕ ਸੁਨੇਹੇ ਲਈ ਵੇਰਵੇ ਹਨ: ਆਈਡੀ, ਗਾਹਕ ਦਾ ਨਾਮ, ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਵਿਹਲਾ ਸਮਾਂ ਅਤੇ ਅੰਤ ਵਿੱਚ ਡਿਲੀਵਰੀ ਕੋਸ਼ਿਸ਼ਾਂ ਦੀ ਗਿਣਤੀ। ਸਾਡੇ ਕੋਲ ਬੌਬ ਦੇ ਦੋ ਸੁਨੇਹੇ ਹਨ ਅਤੇ ਉਹ 74170458 ਮਿਲੀਸਕਿੰਟ, ਲਗਭਗ 20 ਘੰਟਿਆਂ ਲਈ ਵਿਹਲੇ ਰਹੇ ਹਨ।

ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਕੋਈ ਵੀ ਸਾਨੂੰ ਇਹ ਜਾਂਚਣ ਤੋਂ ਨਹੀਂ ਰੋਕ ਰਿਹਾ ਕਿ ਸੰਦੇਸ਼ ਦੀ ਸਮੱਗਰੀ ਸਿਰਫ਼ ਵਰਤ ਕੇ ਕੀ ਸੀ ਐਕਸਰੇਂਜ.

> XRANGE mystream 1526569498055-0 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "message"
      2) "orange"

ਸਾਨੂੰ ਆਰਗੂਮੈਂਟਾਂ ਵਿੱਚ ਇੱਕੋ ਪਛਾਣਕਰਤਾ ਨੂੰ ਦੋ ਵਾਰ ਦੁਹਰਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਹੁਣ ਜਦੋਂ ਸਾਡੇ ਕੋਲ ਕੁਝ ਵਿਚਾਰ ਹੈ, ਐਲਿਸ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦੀ ਹੈ ਕਿ 20 ਘੰਟੇ ਦੇ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਾਅਦ, ਬੌਬ ਸ਼ਾਇਦ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਉਹਨਾਂ ਸੁਨੇਹਿਆਂ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਨ ਅਤੇ ਬੌਬ ਲਈ ਉਹਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਮੁੜ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ। ਇਸਦੇ ਲਈ ਅਸੀਂ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ XCLAIM:

XCLAIM {key} {group} {consumer} {min-idle-time} {ID-1} {ID-2} ... {ID-N}

ਇਸ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਇੱਕ "ਵਿਦੇਸ਼ੀ" ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜਿਸ 'ਤੇ ਅਜੇ ਤੱਕ ਮਾਲਕ ਨੂੰ {उपभोक्ता} ਵਿੱਚ ਬਦਲ ਕੇ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕੀਤੀ ਗਈ ਹੈ। ਹਾਲਾਂਕਿ, ਅਸੀਂ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਨਿਸ਼ਕਿਰਿਆ ਸਮਾਂ {min-idle-time} ਵੀ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ। ਇਹ ਅਜਿਹੀ ਸਥਿਤੀ ਤੋਂ ਬਚਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਦੋ ਕਲਾਇੰਟ ਇੱਕੋ ਸੁਨੇਹਿਆਂ ਦੇ ਮਾਲਕ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ:

Client 1: XCLAIM mystream mygroup Alice 3600000 1526569498055-0
Clinet 2: XCLAIM mystream mygroup Lora 3600000 1526569498055-0

ਪਹਿਲਾ ਗਾਹਕ ਡਾਊਨਟਾਈਮ ਨੂੰ ਰੀਸੈਟ ਕਰੇਗਾ ਅਤੇ ਡਿਲੀਵਰੀ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾਏਗਾ। ਇਸ ਲਈ ਦੂਜਾ ਕਲਾਇੰਟ ਇਸਦੀ ਬੇਨਤੀ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ।

> XCLAIM mystream mygroup Alice 3600000 1526569498055-0
1) 1) 1526569498055-0
   2) 1) "message"
      2) "orange"

ਸੁਨੇਹੇ 'ਤੇ ਐਲਿਸ ਦੁਆਰਾ ਸਫਲਤਾਪੂਰਵਕ ਦਾਅਵਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਜੋ ਹੁਣ ਸੁਨੇਹੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦੀ ਹੈ।

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

ਡਿਲਿਵਰੀ ਕਾਊਂਟਰ

ਕਾਊਂਟਰ ਜੋ ਤੁਸੀਂ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦੇਖਦੇ ਹੋ XPENDING ਹਰੇਕ ਸੁਨੇਹੇ ਦੀ ਡਿਲੀਵਰੀ ਦੀ ਸੰਖਿਆ ਹੈ। ਅਜਿਹੇ ਕਾਊਂਟਰ ਨੂੰ ਦੋ ਤਰੀਕਿਆਂ ਨਾਲ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ: ਜਦੋਂ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਸਫਲਤਾਪੂਰਵਕ ਬੇਨਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ XCLAIM ਜਾਂ ਜਦੋਂ ਇੱਕ ਕਾਲ ਵਰਤੀ ਜਾਂਦੀ ਹੈ XREADGROUP.

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

ਥਰਿੱਡ ਸਟੇਟ

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

> XINFO STREAM mystream
 1) length
 2) (integer) 13
 3) radix-tree-keys
 4) (integer) 1
 5) radix-tree-nodes
 6) (integer) 2
 7) groups
 8) (integer) 2
 9) first-entry
10) 1) 1524494395530-0
    2) 1) "a"
       2) "1"
       3) "b"
       4) "2"
11) last-entry
12) 1) 1526569544280-0
    2) 1) "message"
       2) "banana"

ਉਪਰੋਕਤ ਕਮਾਂਡ ਨਿਰਧਾਰਤ ਸਟ੍ਰੀਮ ਬਾਰੇ ਆਮ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ। ਹੁਣ ਇੱਕ ਥੋੜ੍ਹਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਉਦਾਹਰਨ:

> XINFO GROUPS mystream
1) 1) name
   2) "mygroup"
   3) consumers
   4) (integer) 2
   5) pending
   6) (integer) 2
2) 1) name
   2) "some-other-group"
   3) consumers
   4) (integer) 1
   5) pending
   6) (integer) 0

ਉਪਰੋਕਤ ਕਮਾਂਡ ਨਿਰਧਾਰਤ ਥ੍ਰੈਡ ਦੇ ਸਾਰੇ ਸਮੂਹਾਂ ਲਈ ਆਮ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ

> XINFO CONSUMERS mystream mygroup
1) 1) name
   2) "Alice"
   3) pending
   4) (integer) 1
   5) idle
   6) (integer) 9104628
2) 1) name
   2) "Bob"
   3) pending
   4) (integer) 1
   5) idle
   6) (integer) 83841983

ਉਪਰੋਕਤ ਕਮਾਂਡ ਨਿਰਧਾਰਤ ਸਟ੍ਰੀਮ ਅਤੇ ਸਮੂਹ ਦੇ ਸਾਰੇ ਗਾਹਕਾਂ ਲਈ ਜਾਣਕਾਰੀ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੀ ਹੈ।
ਜੇਕਰ ਤੁਸੀਂ ਕਮਾਂਡ ਸਿੰਟੈਕਸ ਭੁੱਲ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਮਦਦ ਲਈ ਆਪਣੇ ਆਪ ਕਮਾਂਡ ਨੂੰ ਪੁੱਛੋ:

> XINFO HELP
1) XINFO {subcommand} arg arg ... arg. Subcommands are:
2) CONSUMERS {key} {groupname}  -- Show consumer groups of group {groupname}.
3) GROUPS {key}                 -- Show the stream consumer groups.
4) STREAM {key}                 -- Show information about the stream.
5) HELP                         -- Print this help.

ਸਟ੍ਰੀਮ ਆਕਾਰ ਸੀਮਾ

ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਹਮੇਸ਼ਾ ਲਈ ਇੱਕ ਸਟ੍ਰੀਮ ਵਿੱਚ ਡੇਟਾ ਇਕੱਠਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੀਆਂ ਹਨ। ਪ੍ਰਤੀ ਥ੍ਰੈੱਡ ਵਿੱਚ ਅਧਿਕਤਮ ਸੁਨੇਹਿਆਂ ਦੀ ਆਗਿਆ ਦੇਣਾ ਅਕਸਰ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ। ਦੂਜੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਸਾਰੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਇੱਕ ਥਰਿੱਡ ਤੋਂ ਕਿਸੇ ਹੋਰ ਸਥਿਰ ਸਟੋਰ ਵਿੱਚ ਲਿਜਾਣਾ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਨਿਰਧਾਰਤ ਥ੍ਰੈਡ ਆਕਾਰ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਕਮਾਂਡ ਵਿੱਚ MAXLEN ਪੈਰਾਮੀਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਟ੍ਰੀਮ ਦੇ ਆਕਾਰ ਨੂੰ ਸੀਮਿਤ ਕਰ ਸਕਦੇ ਹੋ XADD:

> XADD mystream MAXLEN 2 * value 1
1526654998691-0
> XADD mystream MAXLEN 2 * value 2
1526654999635-0
> XADD mystream MAXLEN 2 * value 3
1526655000369-0
> XLEN mystream
(integer) 2
> XRANGE mystream - +
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

MAXLEN ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਪੁਰਾਣੇ ਰਿਕਾਰਡ ਆਪਣੇ ਆਪ ਮਿਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਉਹ ਇੱਕ ਨਿਸ਼ਚਿਤ ਲੰਬਾਈ ਤੱਕ ਪਹੁੰਚ ਜਾਂਦੇ ਹਨ, ਇਸਲਈ ਸਟ੍ਰੀਮ ਦਾ ਆਕਾਰ ਸਥਿਰ ਹੁੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇਸ ਕੇਸ ਵਿੱਚ ਛਾਂਟਣਾ Redis ਮੈਮੋਰੀ ਵਿੱਚ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵੀ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਹੇਠ ਲਿਖੇ ਤਰੀਕੇ ਨਾਲ ਸਥਿਤੀ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹੋ:

XADD mystream MAXLEN ~ 1000 * ... entry fields here ...

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

ਇੱਕ ਵੱਖਰੀ ਟੀਮ ਵੀ ਹੈ XTRIM, ਜੋ ਉਹੀ ਕੰਮ ਕਰਦਾ ਹੈ:

> XTRIM mystream MAXLEN 10

> XTRIM mystream MAXLEN ~ 10


ਸਥਾਈ ਸਟੋਰੇਜ ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

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

ਇੱਕ ਸਟ੍ਰੀਮ ਤੋਂ ਵਿਅਕਤੀਗਤ ਤੱਤਾਂ ਨੂੰ ਹਟਾਉਣਾ

ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਮਿਟਾਉਣ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਕਮਾਂਡ ਹੈ XDEL. ਕਮਾਂਡ ਨੂੰ ਮਿਟਾਏ ਜਾਣ ਵਾਲੇ ਸੰਦੇਸ਼ IDs ਦੇ ਬਾਅਦ ਥ੍ਰੈਡ ਦਾ ਨਾਮ ਮਿਲਦਾ ਹੈ:

> XRANGE mystream - + COUNT 2
1) 1) 1526654999635-0
   2) 1) "value"
      2) "2"
2) 1) 1526655000369-0
   2) 1) "value"
      2) "3"
> XDEL mystream 1526654999635-0
(integer) 1
> XRANGE mystream - + COUNT 2
1) 1) 1526655000369-0
   2) 1) "value"
      2) "3"

ਇਸ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਅਸਲ ਮੈਮੋਰੀ ਤੁਰੰਤ ਜਾਰੀ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ।

ਜ਼ੀਰੋ ਲੰਬਾਈ ਦੀਆਂ ਧਾਰਾਵਾਂ

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

ਸਿੱਟਾ

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

ਜਿਵੇਂ ਕਿ ਮੈਂ ਇੱਕ ਵਾਰ ਕਿਹਾ ਸੀ ਨਿਕਲੌਸ ਵਿਰਥ, ਪ੍ਰੋਗਰਾਮ ਐਲਗੋਰਿਦਮ ਅਤੇ ਡਾਟਾ ਸਟ੍ਰਕਚਰ ਹੁੰਦੇ ਹਨ, ਅਤੇ Redis ਪਹਿਲਾਂ ਹੀ ਤੁਹਾਨੂੰ ਦੋਵੇਂ ਦਿੰਦਾ ਹੈ।

ਸਰੋਤ: www.habr.com