В ਆਖਰੀ ਲੇਖ ਅਸੀਂ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਅਤੇ ਉੱਚ ਉਪਲਬਧਤਾ ਲਈ RabbitMQ ਕਲੱਸਟਰਿੰਗ ਨੂੰ ਦੇਖਿਆ। ਆਉ ਹੁਣ ਅਪਾਚੇ ਕਾਫਕਾ ਦੀ ਡੂੰਘਾਈ ਵਿੱਚ ਖੋਦਾਈ ਕਰੀਏ।

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

ਚੌਲ. 1. ਤਿੰਨ ਦਲਾਲਾਂ ਵਿੱਚ ਚਾਰ ਭਾਗ ਵੰਡੇ ਗਏ ਹਨ

ਸਾਰੇ ਪੜ੍ਹਨ-ਲਿਖਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਲੀਡਰ ਨੂੰ ਜਾਂਦੀਆਂ ਹਨ। ਅਨੁਯਾਈ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਨੇਤਾ ਨੂੰ ਨਵੀਨਤਮ ਸੰਦੇਸ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬੇਨਤੀਆਂ ਭੇਜਦੇ ਹਨ। ਖਪਤਕਾਰ ਕਦੇ ਵੀ ਪੈਰੋਕਾਰਾਂ ਵੱਲ ਨਹੀਂ ਮੁੜਦੇ ਹਨ; ਬਾਅਦ ਵਾਲੇ ਸਿਰਫ ਰਿਡੰਡੈਂਸੀ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ ਮੌਜੂਦ ਹਨ।

ਭਾਗ ਅਸਫਲਤਾ

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

ਬ੍ਰੋਕਰ 3 ਨੈੱਟਵਰਕ ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬ੍ਰੋਕਰ 2 'ਤੇ ਸੈਕਸ਼ਨ 2 ਲਈ ਇੱਕ ਨਵਾਂ ਨੇਤਾ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ।

ਚੌਲ. 2. ਦਲਾਲ 3 ਦੀ ਮੌਤ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦਲਾਲ 2 'ਤੇ ਉਸ ਦੇ ਚੇਲੇ ਨੂੰ ਵੰਡ 2 ਦੇ ਨਵੇਂ ਨੇਤਾ ਵਜੋਂ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ।

ਫਿਰ ਬ੍ਰੋਕਰ 1 ਛੱਡਦਾ ਹੈ ਅਤੇ ਸੈਕਸ਼ਨ 1 ਵੀ ਆਪਣਾ ਨੇਤਾ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਦੀ ਭੂਮਿਕਾ ਦਲਾਲ 2 ਨੂੰ ਜਾਂਦੀ ਹੈ।

ਚੌਲ. 3. ਇੱਕ ਦਲਾਲ ਬਚਿਆ ਹੈ। ਸਾਰੇ ਨੇਤਾ ਜ਼ੀਰੋ ਰਿਡੰਡੈਂਸੀ ਦੇ ਨਾਲ ਇੱਕ ਦਲਾਲ 'ਤੇ ਹਨ

ਜਦੋਂ ਬ੍ਰੋਕਰ 1 ਔਨਲਾਈਨ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਚਾਰ ਅਨੁਯਾਈਆਂ ਨੂੰ ਜੋੜਦਾ ਹੈ, ਹਰੇਕ ਭਾਗ ਨੂੰ ਕੁਝ ਰਿਡੰਡੈਂਸੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਪਰ ਫਿਰ ਵੀ ਸਾਰੇ ਆਗੂ ਦਲਾਲ 2 'ਤੇ ਡਟੇ ਰਹੇ।

ਚੌਲ. 4. ਨੇਤਾ ਦਲਾਲ 2 'ਤੇ ਰਹਿੰਦੇ ਹਨ

ਜਦੋਂ ਬ੍ਰੋਕਰ 3 ਆਉਂਦਾ ਹੈ, ਅਸੀਂ ਪ੍ਰਤੀ ਭਾਗ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦੇ ਹਾਂ। ਪਰ ਸਾਰੇ ਲੀਡਰ ਅਜੇ ਵੀ ਦਲਾਲ 2 'ਤੇ ਹਨ।

ਚੌਲ. 5. ਦਲਾਲ 1 ਅਤੇ 3 ਦੀ ਬਹਾਲੀ ਤੋਂ ਬਾਅਦ ਨੇਤਾਵਾਂ ਦੀ ਅਸੰਤੁਲਿਤ ਪਲੇਸਮੈਂਟ

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

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

ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਕਾਫਕਾ ਦੋ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦਾ ਹੈ:

• ਵਿਕਲਪ auto.leader.rebalance.enable=true ਕੰਟਰੋਲਰ ਨੋਡ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਲੀਡਰਾਂ ਨੂੰ ਤਰਜੀਹੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਈ ਦੁਬਾਰਾ ਸੌਂਪਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਇਕਸਾਰ ਵੰਡ ਨੂੰ ਬਹਾਲ ਕਰਦਾ ਹੈ।
• ਪ੍ਰਸ਼ਾਸਕ ਸਕ੍ਰਿਪਟ ਚਲਾ ਸਕਦਾ ਹੈ kafka-preferred-replica-election.sh ਦਸਤੀ ਮੁੜ-ਸਾਈਨਮੈਂਟ ਲਈ।

ਚੌਲ. 6. ਮੁੜ-ਸੰਤੁਲਨ ਤੋਂ ਬਾਅਦ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ

ਇਹ ਅਸਫਲਤਾ ਦਾ ਇੱਕ ਸਰਲ ਰੂਪ ਸੀ, ਪਰ ਅਸਲੀਅਤ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ, ਹਾਲਾਂਕਿ ਇੱਥੇ ਕੁਝ ਵੀ ਗੁੰਝਲਦਾਰ ਨਹੀਂ ਹੈ. ਇਹ ਸਭ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ (ਇਨ-ਸਿੰਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ, ISR) ਤੱਕ ਆਉਂਦਾ ਹੈ।

ਸਿੰਕ੍ਰੋਨਾਈਜ਼ਡ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ (ISR)

ਇੱਕ ISR ਇੱਕ ਭਾਗ ਦੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ ਜਿਸਨੂੰ "ਸਮਕਾਲੀ" (ਇਨ-ਸਿੰਕ) ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਨੇਤਾ ਹੈ, ਪਰ ਚੇਲੇ ਨਹੀਂ ਹੋ ਸਕਦੇ। ਇੱਕ ਅਨੁਯਾਈ ਨੂੰ ਸਮਕਾਲੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਉਸਨੇ ਅੰਤਰਾਲ ਦੀ ਮਿਆਦ ਖਤਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਨੇਤਾ ਦੇ ਸਾਰੇ ਸੰਦੇਸ਼ਾਂ ਦੀਆਂ ਸਹੀ ਕਾਪੀਆਂ ਬਣਾਈਆਂ ਹਨ replica.lag.time.max.ms.

ਇੱਕ ਅਨੁਯਾਈ ਨੂੰ ISR ਸੈੱਟ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੇਕਰ ਇਹ:

• ਅੰਤਰਾਲ ਲਈ ਚੁਣਨ ਦੀ ਬੇਨਤੀ ਨਹੀਂ ਕੀਤੀ replica.lag.time.max.ms (считается мертвым)
• ਅੰਤਰਾਲ ਦੌਰਾਨ ਅੱਪਡੇਟ ਕਰਨ ਦਾ ਪ੍ਰਬੰਧ ਨਹੀਂ ਕੀਤਾ replica.lag.time.max.ms (ਧੀਮਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ)

ਅਨੁਯਾਈ ਅੰਤਰਾਲ ਵਿੱਚ ਨਮੂਨੇ ਲਈ ਬੇਨਤੀਆਂ ਕਰਦੇ ਹਨ replica.fetch.wait.max.ms, ਜੋ ਕਿ 500ms ਤੱਕ ਡਿਫਾਲਟ ਹੈ।

ISR ਦੇ ਉਦੇਸ਼ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਸਮਝਾਉਣ ਲਈ, ਸਾਨੂੰ ਨਿਰਮਾਤਾ ਤੋਂ ਪੁਸ਼ਟੀਕਰਨ ਅਤੇ ਕੁਝ ਅਸਫਲਤਾ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਦੇਖਣ ਦੀ ਲੋੜ ਹੈ। ਨਿਰਮਾਤਾ ਇਹ ਚੁਣ ਸਕਦੇ ਹਨ ਕਿ ਬ੍ਰੋਕਰ ਪੁਸ਼ਟੀਕਰਨ ਕਦੋਂ ਭੇਜਦਾ ਹੈ:

• acks=0, ਪੁਸ਼ਟੀ ਨਹੀਂ ਭੇਜੀ ਗਈ
• acks=1, ਨੇਤਾ ਦੁਆਰਾ ਉਸਦੇ ਸਥਾਨਕ ਲੌਗ ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਪੁਸ਼ਟੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ
• acks=all, ISR ਵਿੱਚ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੁਆਰਾ ਸਥਾਨਕ ਲੌਗਸ ਨੂੰ ਸੰਦੇਸ਼ ਲਿਖਣ ਤੋਂ ਬਾਅਦ ਪੁਸ਼ਟੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ

ਕਾਫਕਾ ਦੀ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ, ਜੇਕਰ ISR ਨੇ ਇੱਕ ਸੁਨੇਹਾ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ "ਵਚਨਬੱਧ" ਹੈ। Acks=all ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਹੈ, ਪਰ ਵਾਧੂ ਦੇਰੀ ਵੀ ਜੋੜਦਾ ਹੈ। ਆਉ ਅਸੀਂ ਅਸਫਲਤਾ ਦੀਆਂ ਦੋ ਉਦਾਹਰਣਾਂ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਕਿਵੇਂ ਵੱਖ-ਵੱਖ 'ਐਕਸ' ਵਿਕਲਪ ISR ਸੰਕਲਪ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ।

Acks=1 ਅਤੇ ISR

ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਜੇਕਰ ਨੇਤਾ ਸਾਰੇ ਪੈਰੋਕਾਰਾਂ ਦੇ ਹਰ ਸੰਦੇਸ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਜਾਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੇਕਰ ਲੀਡਰ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਡੇਟਾ ਦਾ ਨੁਕਸਾਨ ਸੰਭਵ ਹੈ। ਇੱਕ ਗੈਰ-ਸਮਕਾਲੀ ਅਨੁਯਾਾਇਯ ਨੂੰ ਨੈਵੀਗੇਟ ਕਰਨਾ ਸੈਟਿੰਗ ਦੁਆਰਾ ਸਮਰੱਥ ਜਾਂ ਅਯੋਗ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ unclean.leader.election.enable.

ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਨਿਰਮਾਤਾ ਕੋਲ ਮੁੱਲ acks=1 ਹੈ। ਭਾਗ ਨੂੰ ਸਾਰੇ ਤਿੰਨ ਦਲਾਲਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਬ੍ਰੋਕਰ 3 ਪਿੱਛੇ ਹੈ, ਇਹ ਅੱਠ ਸਕਿੰਟ ਪਹਿਲਾਂ ਲੀਡਰ ਨਾਲ ਸਮਕਾਲੀ ਹੈ ਅਤੇ ਹੁਣ 7456 ਸੁਨੇਹੇ ਪਿੱਛੇ ਹੈ। ਬ੍ਰੋਕਰ 1 ਸਿਰਫ ਇੱਕ ਸਕਿੰਟ ਪਿੱਛੇ ਸੀ। ਸਾਡਾ ਨਿਰਮਾਤਾ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਐਕ ਵਾਪਸ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਬਿਨਾਂ ਹੌਲੀ ਜਾਂ ਮਰੇ ਹੋਏ ਪੈਰੋਕਾਰਾਂ ਦੇ ਓਵਰਹੈੱਡ ਦੇ ਜਿਸ ਦੀ ਲੀਡਰ ਉਡੀਕ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ।

ਚੌਲ. 7. ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਾਲਾ ISR

ਬ੍ਰੋਕਰ 2 ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਨਿਰਮਾਤਾ ਨੂੰ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਗਲਤੀ ਮਿਲਦੀ ਹੈ। ਲੀਡਰਸ਼ਿਪ ਬ੍ਰੋਕਰ 1 ਨੂੰ ਪਾਸ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ 123 ਸੁਨੇਹੇ ਗੁਆ ਦਿੰਦੇ ਹਾਂ। ਬ੍ਰੋਕਰ 1 'ਤੇ ਫਾਲੋਅਰ ISR ਦਾ ਹਿੱਸਾ ਸੀ, ਪਰ ਜਦੋਂ ਇਹ ਡਿੱਗਿਆ ਤਾਂ ਲੀਡਰ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਕਾਲੀ ਨਹੀਂ ਸੀ।

ਚੌਲ. 8. ਕ੍ਰੈਸ਼ ਹੋਣ 'ਤੇ ਸੁਨੇਹੇ ਗੁੰਮ ਹੋ ਜਾਂਦੇ ਹਨ

ਸੰਰਚਨਾ ਵਿੱਚ bootstrap.servers ਨਿਰਮਾਤਾ ਕੋਲ ਕਈ ਦਲਾਲ ਸੂਚੀਬੱਧ ਹਨ ਅਤੇ ਉਹ ਕਿਸੇ ਹੋਰ ਬ੍ਰੋਕਰ ਨੂੰ ਪੁੱਛ ਸਕਦੇ ਹਨ ਜੋ ਨਵਾਂ ਸੈਕਸ਼ਨ ਲੀਡਰ ਹੈ। ਇਹ ਫਿਰ ਬ੍ਰੋਕਰ 1 ਨਾਲ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਸੁਨੇਹੇ ਭੇਜਣਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ।

ਚੌਲ. 9. ਇੱਕ ਛੋਟੇ ਬ੍ਰੇਕ ਤੋਂ ਬਾਅਦ ਸੁਨੇਹੇ ਭੇਜਣਾ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ

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

ਚੌਲ. 10. ਬ੍ਰੋਕਰ 3 'ਤੇ ਫਾਲੋਅਰ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ

ਬ੍ਰੋਕਰ 1 ਹੇਠਾਂ ਚਲਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਦੀ ਭੂਮਿਕਾ 3 ਸੁਨੇਹਿਆਂ ਦੇ ਨੁਕਸਾਨ ਦੇ ਨਾਲ ਬ੍ਰੋਕਰ 15286 ਨੂੰ ਜਾਂਦੀ ਹੈ! ਨਿਰਮਾਤਾ ਨੂੰ ਇੱਕ ਕਨੈਕਸ਼ਨ ਗਲਤੀ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ। ISR ਦੇ ਬਾਹਰ ਇੱਕ ਨੇਤਾ ਨੂੰ ਤਬਦੀਲੀ ਸਿਰਫ ਸੈਟਿੰਗ ਦੇ ਕਾਰਨ ਸੰਭਵ ਸੀ unclean.leader.election.enable=true. ਜੇਕਰ ਇਹ ਵਿੱਚ ਇੰਸਟਾਲ ਹੈ ਝੂਠੇ, ਤਦ ਪਰਿਵਰਤਨ ਨਹੀਂ ਹੋਵੇਗਾ ਅਤੇ ਸਾਰੀਆਂ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਬ੍ਰੋਕਰ 1 ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਵਿੱਚ ਉਸਦੇ ਬਰਕਰਾਰ ਡੇਟਾ ਦੇ ਨਾਲ ਵਾਪਸ ਆਉਣ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹਾਂ, ਜੋ ਦੁਬਾਰਾ ਲੀਡਰਸ਼ਿਪ ਲੈ ਲਵੇਗਾ।

ਚੌਲ. 11. ਬ੍ਰੋਕਰ 1 ਡਿੱਗਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਅਸਫਲਤਾ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਸੁਨੇਹੇ ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ

ਨਿਰਮਾਤਾ ਆਖਰੀ ਦਲਾਲ ਨਾਲ ਸਬੰਧ ਸਥਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਦੇਖਦਾ ਹੈ ਕਿ ਉਹ ਹੁਣ ਸੈਕਸ਼ਨ ਦਾ ਨੇਤਾ ਹੈ। ਉਹ ਬ੍ਰੋਕਰ 3 ਨੂੰ ਸੰਦੇਸ਼ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ।

ਚੌਲ. 12. ਇੱਕ ਛੋਟੇ ਬ੍ਰੇਕ ਤੋਂ ਬਾਅਦ, ਸੁਨੇਹੇ ਸੈਕਸ਼ਨ 0 ਨੂੰ ਦੁਬਾਰਾ ਭੇਜੇ ਜਾਂਦੇ ਹਨ

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

Acks = ਸਭ ਅਤੇ ISR

ਚਲੋ ਇਸ ਦ੍ਰਿਸ਼ ਨੂੰ ਦੁਬਾਰਾ ਦੁਹਰਾਉਂਦੇ ਹਾਂ, ਪਰ ਨਾਲ acks = ਸਾਰੇ. ਬ੍ਰੋਕਰ 3 ਵਿੱਚ ਚਾਰ ਸਕਿੰਟਾਂ ਦੀ ਔਸਤ ਲੇਟੈਂਸੀ ਹੈ। ਨਿਰਮਾਤਾ ਦੇ ਨਾਲ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ acks = ਸਾਰੇ, ਅਤੇ ਹੁਣ ਇੱਕ ਤੇਜ਼ ਜਵਾਬ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦਾ। ਨੇਤਾ ISR ਵਿੱਚ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੁਆਰਾ ਸੰਦੇਸ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤੇ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।

ਚੌਲ. 13. ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਾਲਾ ISR। ਇੱਕ ਹੌਲੀ ਹੈ, ਨਤੀਜੇ ਵਜੋਂ ਰਿਕਾਰਡਿੰਗ ਵਿੱਚ ਦੇਰੀ ਹੁੰਦੀ ਹੈ

ਚਾਰ ਸਕਿੰਟਾਂ ਦੀ ਵਾਧੂ ਦੇਰੀ ਤੋਂ ਬਾਅਦ, ਬ੍ਰੋਕਰ 2 ਇੱਕ ack ਭੇਜਦਾ ਹੈ। ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹੁਣ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅੱਪਡੇਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ਚੌਲ. 14. ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ack ਭੇਜਦੀਆਂ ਹਨ

ਬ੍ਰੋਕਰ 3 ਹੁਣ ਹੋਰ ਪਿੱਛੇ ਆ ਗਿਆ ਹੈ ਅਤੇ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਲੇਟੈਂਸੀ ਕਾਫ਼ੀ ਘੱਟ ਗਈ ਹੈ ਕਿਉਂਕਿ ISR ਵਿੱਚ ਕੋਈ ਵੀ ਹੌਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨਹੀਂ ਬਚੀਆਂ ਹਨ। ਬ੍ਰੋਕਰ 2 ਹੁਣ ਸਿਰਫ਼ ਬ੍ਰੋਕਰ 1 ਦਾ ਇੰਤਜ਼ਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਉਸ ਕੋਲ ਔਸਤਨ 500 ਐਮ.ਐਸ.

ਚੌਲ. 15. ਬ੍ਰੋਕਰ 3 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ

ਫਿਰ ਬ੍ਰੋਕਰ 2 ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਸੰਦੇਸ਼ਾਂ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ ਬ੍ਰੋਕਰ 1 ਨੂੰ ਪਾਸ ਕਰਦੀ ਹੈ।

ਚੌਲ. 16. ਬ੍ਰੋਕਰ 2 ਡਿੱਗਦਾ ਹੈ

ਨਿਰਮਾਤਾ ਇੱਕ ਨਵਾਂ ਨੇਤਾ ਲੱਭਦਾ ਹੈ ਅਤੇ ਉਸਨੂੰ ਸੰਦੇਸ਼ ਭੇਜਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਲੇਟੈਂਸੀ ਨੂੰ ਹੋਰ ਘਟਾਇਆ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ISR ਵਿੱਚ ਹੁਣ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸ਼ਾਮਲ ਹੈ! ਇਸ ਲਈ ਵਿਕਲਪ acks = ਸਾਰੇ ਰਿਡੰਡੈਂਸੀ ਨਹੀਂ ਜੋੜਦਾ।

ਚੌਲ. 17. ਬ੍ਰੋਕਰ 1 'ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਸੁਨੇਹਿਆਂ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ ਅਗਵਾਈ ਕਰਦੀ ਹੈ

ਫਿਰ ਬ੍ਰੋਕਰ 1 ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਲੀਡ 3 ਸੁਨੇਹਿਆਂ ਦੇ ਨੁਕਸਾਨ ਦੇ ਨਾਲ ਬ੍ਰੋਕਰ 14238 ਨੂੰ ਜਾਂਦੀ ਹੈ!

ਚੌਲ. 18. ਬ੍ਰੋਕਰ 1 ਦੀ ਮੌਤ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਅਸ਼ੁੱਧ ਸੈਟਿੰਗ ਦੇ ਨਾਲ ਲੀਡਰਸ਼ਿਪ ਤਬਦੀਲੀ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਵਿਆਪਕ ਡਾਟਾ ਨੁਕਸਾਨ ਹੁੰਦਾ ਹੈ

ਅਸੀਂ ਵਿਕਲਪ ਨੂੰ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰ ਸਕੇ unclean.leader.election.enable ਅਰਥ ਵਿੱਚ ਇਹ ਸੱਚ ਹੈ,. ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ ਬਰਾਬਰ ਹੈ ਝੂਠੇ. ਸੈਟਿੰਗਾਂ acks = ਸਾਰੇ с unclean.leader.election.enable=true ਕੁਝ ਵਾਧੂ ਡਾਟਾ ਸੁਰੱਖਿਆ ਦੇ ਨਾਲ ਪਹੁੰਚਯੋਗਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ. ਪਰ ਜਿਵੇਂ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਸੀਂ ਅਜੇ ਵੀ ਸੁਨੇਹੇ ਗੁਆ ਸਕਦੇ ਹਾਂ।

ਪਰ ਜੇ ਅਸੀਂ ਡੇਟਾ ਸੁਰੱਖਿਆ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੋਵੇਗਾ? ਤੁਸੀਂ ਪਾ ਸਕਦੇ ਹੋ unclean.leader.election.enable = ਗਲਤ, ਪਰ ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਸਾਨੂੰ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਚਾਏਗਾ ਨਹੀਂ। ਜੇ ਨੇਤਾ ਸਖ਼ਤ ਹੋ ਗਿਆ ਅਤੇ ਇਸ ਨਾਲ ਡੇਟਾ ਲੈ ਗਿਆ, ਤਾਂ ਸੁਨੇਹੇ ਅਜੇ ਵੀ ਗੁੰਮ ਹੋ ਗਏ ਹਨ, ਨਾਲ ਹੀ ਉਪਲਬਧਤਾ ਉਦੋਂ ਤੱਕ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਪ੍ਰਬੰਧਕ ਸਥਿਤੀ ਨੂੰ ਬਹਾਲ ਨਹੀਂ ਕਰਦਾ.

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

Acks=all, min.insync.replicas ਅਤੇ ISR

ਵਿਸ਼ਾ ਸੰਰਚਨਾ ਦੇ ਨਾਲ min.insync.replicas ਅਸੀਂ ਡਾਟਾ ਸੁਰੱਖਿਆ ਦੇ ਪੱਧਰ ਨੂੰ ਵਧਾ ਰਹੇ ਹਾਂ। ਚਲੋ ਪਿਛਲੇ ਦ੍ਰਿਸ਼ ਦੇ ਆਖਰੀ ਹਿੱਸੇ ਨੂੰ ਦੁਬਾਰਾ ਵੇਖੀਏ, ਪਰ ਇਸ ਵਾਰ ਨਾਲ min.insync.replicas=2.

ਇਸ ਲਈ ਬ੍ਰੋਕਰ 2 ਕੋਲ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲੀਡਰ ਹੈ ਅਤੇ ਬ੍ਰੋਕਰ 3 ਦੇ ਅਨੁਯਾਈ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ।

ਚੌਲ. 19. ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੋਂ ਆਈ.ਐਸ.ਆਰ

ਬ੍ਰੋਕਰ 2 ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਲੀਡਰਸ਼ਿਪ ਸੰਦੇਸ਼ਾਂ ਦੇ ਨੁਕਸਾਨ ਤੋਂ ਬਿਨਾਂ ਬ੍ਰੋਕਰ 1 ਨੂੰ ਪਾਸ ਕਰਦੀ ਹੈ। ਪਰ ਹੁਣ ISR ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਹੈ। ਇਹ ਰਿਕਾਰਡ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਘੱਟੋ-ਘੱਟ ਸੰਖਿਆ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸਲਈ ਬ੍ਰੋਕਰ ਗਲਤੀ ਨਾਲ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ NotEnoughReplicas.

ਚੌਲ. 20. ISR ਦੀ ਸੰਖਿਆ min.insync.replicas ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਨਾਲੋਂ ਇੱਕ ਘੱਟ ਹੈ

ਇਹ ਸੰਰਚਨਾ ਇਕਸਾਰਤਾ ਲਈ ਉਪਲਬਧਤਾ ਨੂੰ ਕੁਰਬਾਨ ਕਰਦੀ ਹੈ। ਕਿਸੇ ਸੁਨੇਹੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਅਸੀਂ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਾਂ ਕਿ ਇਹ ਘੱਟੋ-ਘੱਟ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ 'ਤੇ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਇਹ ਨਿਰਮਾਤਾ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵਿਸ਼ਵਾਸ ਦਿੰਦਾ ਹੈ. ਇੱਥੇ, ਸੰਦੇਸ਼ ਦਾ ਨੁਕਸਾਨ ਤਾਂ ਹੀ ਸੰਭਵ ਹੈ ਜੇਕਰ ਦੋ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਇੱਕ ਛੋਟੇ ਅੰਤਰਾਲ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਅਸਫਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਤੱਕ ਸੁਨੇਹਾ ਇੱਕ ਵਾਧੂ ਅਨੁਯਾਈ ਨੂੰ ਨਕਲ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਜਿਸਦੀ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ। ਪਰ ਜੇ ਤੁਸੀਂ ਸੁਪਰ ਪਾਗਲ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਫੈਕਟਰ ਨੂੰ 5 ਤੇ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ min.insync.replicas ਦੁਆਰਾ 3. ਇੱਥੇ ਰਿਕਾਰਡ ਗੁਆਉਣ ਲਈ ਤਿੰਨ ਦਲਾਲਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਡਿੱਗਣਾ ਚਾਹੀਦਾ ਹੈ! ਬੇਸ਼ੱਕ, ਤੁਸੀਂ ਇਸ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਵਾਧੂ ਲੇਟੈਂਸੀ ਵਿੱਚ ਭੁਗਤਾਨ ਕਰਦੇ ਹੋ।

ਜਦੋਂ ਡੇਟਾ ਸੁਰੱਖਿਆ ਲਈ ਪਹੁੰਚਯੋਗਤਾ ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ

ਜਿਵੇਂ ਕਿ RabbitMQ ਨਾਲ ਕੇਸ, ਕਈ ਵਾਰ ਡਾਟਾ ਸੁਰੱਖਿਆ ਲਈ ਪਹੁੰਚਯੋਗਤਾ ਜ਼ਰੂਰੀ ਹੁੰਦੀ ਹੈ। ਇੱਥੇ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ:

• ਕੀ ਪ੍ਰਕਾਸ਼ਕ ਸਿਰਫ਼ ਇੱਕ ਗਲਤੀ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਅੱਪਸਟ੍ਰੀਮ ਸੇਵਾ ਜਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ?
• ਕੀ ਪ੍ਰਕਾਸ਼ਕ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਜਾਂ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੰਦੇਸ਼ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਸਕਦਾ ਹੈ?

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

ISR ਦਾ ਅਰਥ

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

ਅਸੀਂ ਅਰਥ ਆਪ ਚੁਣਦੇ ਹਾਂ replica.lag.time.max.ms ਤੁਹਾਡੀ ਲੋੜ ਅਨੁਸਾਰ. ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਇਸ ਪੈਰਾਮੀਟਰ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ ਕਿੰਨੀ ਦੇਰੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹਾਂ ਕਦੋਂ acks = ਸਾਰੇ. ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲ ਦਸ ਸਕਿੰਟ ਹੈ। ਜੇਕਰ ਇਹ ਤੁਹਾਡੇ ਲਈ ਬਹੁਤ ਲੰਮਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ। ਫਿਰ ISR ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਬਾਰੰਬਾਰਤਾ ਵਧੇਗੀ, ਕਿਉਂਕਿ ਅਨੁਯਾਈਆਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ ਅਤੇ ਅਕਸਰ ਜੋੜਿਆ ਜਾਵੇਗਾ।

RabbitMQ ਸਿਰਫ਼ ਸ਼ੀਸ਼ੇ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜਿਸਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਹੌਲੀ ਮਿਰਰ ਵਾਧੂ ਲੇਟੈਂਸੀ ਪੇਸ਼ ਕਰਦੇ ਹਨ, ਅਤੇ ਡੈੱਡ ਮਿਰਰ ਜਵਾਬ ਦੇਣ ਲਈ ਹਰੇਕ ਨੋਡ (ਨੈੱਟ ਟਿਕ) ਦੀ ਉਪਲਬਧਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੇ ਪੈਕੇਟਾਂ ਤੱਕ ਉਡੀਕ ਕਰ ਸਕਦੇ ਹਨ। ISR ਇਹਨਾਂ ਲੇਟੈਂਸੀ ਮੁੱਦਿਆਂ ਤੋਂ ਬਚਣ ਦਾ ਇੱਕ ਦਿਲਚਸਪ ਤਰੀਕਾ ਹੈ। ਪਰ ਸਾਨੂੰ ਰਿਡੰਡੈਂਸੀ ਗੁਆਉਣ ਦਾ ਜੋਖਮ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ISR ਸਿਰਫ ਨੇਤਾ ਤੱਕ ਸੁੰਗੜ ਸਕਦਾ ਹੈ। ਇਸ ਜੋਖਮ ਤੋਂ ਬਚਣ ਲਈ, ਸੈਟਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰੋ min.insync.replicas.

ਕਲਾਇੰਟ ਕੁਨੈਕਸ਼ਨ ਦੀ ਗਰੰਟੀ

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

RabbitMQ ਵਿੱਚ, ਕਲਾਇੰਟ ਕਿਸੇ ਵੀ ਨੋਡ ਨਾਲ ਜੁੜ ਸਕਦੇ ਹਨ, ਅਤੇ ਅੰਦਰੂਨੀ ਰੂਟਿੰਗ ਬੇਨਤੀ ਭੇਜਦੀ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਜਾਣ ਦੀ ਲੋੜ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ RabbitMQ ਦੇ ਸਾਹਮਣੇ ਇੱਕ ਲੋਡ ਬੈਲੇਂਸਰ ਸਥਾਪਤ ਕਰ ਸਕਦੇ ਹੋ। ਕਾਫਕਾ ਲਈ ਗਾਹਕਾਂ ਨੂੰ ਨੋਡ ਨਾਲ ਜੁੜਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜੋ ਸੰਬੰਧਿਤ ਪਾਰਟੀਸ਼ਨ ਲੀਡਰ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦਾ ਹੈ। ਅਜਿਹੀ ਸਥਿਤੀ ਵਿੱਚ, ਤੁਸੀਂ ਲੋਡ ਬੈਲੇਂਸਰ ਨਹੀਂ ਲਗਾ ਸਕਦੇ ਹੋ। ਸੂਚੀ bootstrap.servers ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਗਾਹਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਸਹੀ ਨੋਡਸ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਲੱਭ ਸਕਦੇ ਹਨ।

ਕਾਫਕਾ ਸਹਿਮਤੀ ਆਰਕੀਟੈਕਚਰ

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

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

ਜ਼ੂਕੀਪਰ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ:

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

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

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

ਹਰੇਕ ਸੈਕਸ਼ਨ ਕੰਟਰੋਲਰ ਲਈ:

• ISR ਅਤੇ ਨੇਤਾ ਬਾਰੇ Zookeeper ਵਿੱਚ ਜਾਣਕਾਰੀ ਨੂੰ ਅੱਪਡੇਟ ਕਰਦਾ ਹੈ;
• ਹਰੇਕ ਬ੍ਰੋਕਰ ਨੂੰ ਲੀਡਰ ਅਤੇ ਆਈਐਸਆਰਕਮਾਂਡ ਭੇਜਦਾ ਹੈ ਜੋ ਇਸ ਭਾਗ ਦੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦਾ ਹੈ, ਦਲਾਲਾਂ ਨੂੰ ISR ਅਤੇ ਨੇਤਾ ਬਾਰੇ ਸੂਚਿਤ ਕਰਦਾ ਹੈ।

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

ਹਰੇਕ ਆਗੂ ISR ਦੀ ਭਰਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਸੈਟਿੰਗਾਂ replica.lag.time.max.ms ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਉੱਥੇ ਕੌਣ ਦਾਖਲ ਹੋਵੇਗਾ। ਜਦੋਂ ISR ਬਦਲਦਾ ਹੈ, ਤਾਂ ਨੇਤਾ ਜ਼ੂਕੀਪਰ ਨੂੰ ਨਵੀਂ ਜਾਣਕਾਰੀ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ।

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

ਚੌਲ. 21. ਕਾਫਕਾ ਸਹਿਮਤੀ

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪ੍ਰੋਟੋਕੋਲ

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਵੇਰਵਿਆਂ ਨੂੰ ਸਮਝਣਾ ਤੁਹਾਨੂੰ ਸੰਭਾਵੀ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।

ਨਮੂਨਾ ਪੁੱਛਗਿੱਛ, ਲੌਗ ਐਂਡ ਆਫਸੈੱਟ (LEO) ਅਤੇ ਹਾਈਵਾਟਰ ਮਾਰਕ (HW)

ਅਸੀਂ ਵਿਚਾਰ ਕੀਤਾ ਕਿ ਪੈਰੋਕਾਰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਲੀਡਰ ਨੂੰ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਡਿਫੌਲਟ ਅੰਤਰਾਲ 500ms ਹੈ। ਇਹ RabbitMQ ਤੋਂ ਵੱਖਰਾ ਹੈ ਕਿ RabbitMQ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਿਊ ਮਿਰਰ ਦੁਆਰਾ ਨਹੀਂ ਬਲਕਿ ਮਾਸਟਰ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਮਾਸਟਰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸ਼ੀਸ਼ੇ ਵੱਲ ਧੱਕਦਾ ਹੈ।

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

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

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

ਨੇਤਾ ਦੀ ਅਸਫਲਤਾ

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

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

ਇੱਕ ਅਨੁਯਾਈ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਕਾਰਨਾਂ ਕਰਕੇ ਲੌਗ ਨੂੰ ਕੱਟਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ:

• ਜਦੋਂ ਕੋਈ ਨੇਤਾ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜ਼ੂਕੀਪਰ ਦੇ ਨਾਲ ਰਜਿਸਟਰਡ ISR ਸੈੱਟ ਵਿੱਚ ਪਹਿਲਾ ਅਨੁਯਾਈ ਚੋਣ ਜਿੱਤਦਾ ਹੈ ਅਤੇ ਨੇਤਾ ਬਣ ਜਾਂਦਾ ਹੈ। ISR 'ਤੇ ਸਾਰੇ ਅਨੁਯਾਈਆਂ, ਹਾਲਾਂਕਿ "ਸਮਕਾਲੀਨ ਵਿੱਚ" ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਾਬਕਾ ਨੇਤਾ ਦੇ ਸਾਰੇ ਸੰਦੇਸ਼ਾਂ ਦੀਆਂ ਕਾਪੀਆਂ ਪ੍ਰਾਪਤ ਨਾ ਕੀਤੀਆਂ ਹੋਣ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੰਭਵ ਹੈ ਕਿ ਫੀਚਰਡ ਫਾਲੋਅਰ ਕੋਲ ਸਭ ਤੋਂ ਅੱਪ-ਟੂ-ਡੇਟ ਕਾਪੀ ਨਾ ਹੋਵੇ। ਕਾਫਕਾ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਿਚਕਾਰ ਕੋਈ ਭਿੰਨਤਾ ਨਹੀਂ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਮਤਭੇਦਾਂ ਤੋਂ ਬਚਣ ਲਈ, ਹਰੇਕ ਅਨੁਯਾਈ ਨੂੰ ਆਪਣੀ ਚੋਣ ਦੇ ਸਮੇਂ ਨਵੇਂ ਨੇਤਾ ਦੇ HW ਮੁੱਲ ਲਈ ਆਪਣੇ ਲੌਗ ਨੂੰ ਕੱਟਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਇਕ ਹੋਰ ਕਾਰਨ ਹੈ ਕਿ ਸੈਟਿੰਗ acks = ਸਾਰੇ ਇਕਸਾਰਤਾ ਲਈ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ.
• ਸੁਨੇਹੇ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਡਿਸਕ ਤੇ ਲਿਖੇ ਜਾਂਦੇ ਹਨ। ਜੇਕਰ ਸਾਰੇ ਕਲੱਸਟਰ ਨੋਡ ਇੱਕੋ ਸਮੇਂ ਫੇਲ ਹੋ ਜਾਂਦੇ ਹਨ, ਤਾਂ ਵੱਖ-ਵੱਖ ਆਫਸੈਟਾਂ ਵਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਡਿਸਕਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਜਦੋਂ ਬ੍ਰੋਕਰ ਔਨਲਾਈਨ ਵਾਪਸ ਆਉਂਦੇ ਹਨ, ਤਾਂ ਚੁਣਿਆ ਗਿਆ ਨਵਾਂ ਨੇਤਾ ਆਪਣੇ ਪੈਰੋਕਾਰਾਂ ਦੇ ਪਿੱਛੇ ਹੋਵੇਗਾ ਕਿਉਂਕਿ ਉਹ ਦੂਜਿਆਂ ਤੋਂ ਪਹਿਲਾਂ ਡਿਸਕ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਕਲੱਸਟਰ ਦੇ ਨਾਲ ਰੀਯੂਨੀਅਨ

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

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

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

ਕਨੈਕਟੀਵਿਟੀ ਦਾ ਨੁਕਸਾਨ

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

ਹੇਠਾਂ ਕਈ ਕਨੈਕਟੀਵਿਟੀ ਅਸਫਲਤਾ ਦੇ ਦ੍ਰਿਸ਼ ਹਨ:

• ਦ੍ਰਿਸ਼ 1: ਪੈਰੋਕਾਰ ਨੇਤਾ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ, ਪਰ ਫਿਰ ਵੀ ਚਿੜੀਆਘਰ ਨੂੰ ਦੇਖਦਾ ਹੈ।
• ਦ੍ਰਿਸ਼ 2: ਨੇਤਾ ਕੋਈ ਅਨੁਯਾਈ ਨਹੀਂ ਦੇਖਦਾ, ਪਰ ਫਿਰ ਵੀ ਜ਼ੂਕੀਪਰ ਨੂੰ ਦੇਖਦਾ ਹੈ।
• ਦ੍ਰਿਸ਼ 3: ਚੇਲਾ ਆਗੂ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਪਰ ਚਿੜੀਆਘਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ।
• ਦ੍ਰਿਸ਼ 4: ਨੇਤਾ ਪੈਰੋਕਾਰਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਪਰ ਚਿੜੀਆਘਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ।
• ਦ੍ਰਿਸ਼ 5: ਅਨੁਯਾਈ ਕਾਫਕਾ ਨੋਡ ਅਤੇ ਜ਼ੂਕੀਪਰ ਦੋਵਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਹੈ।
• ਦ੍ਰਿਸ਼ 6: ਨੇਤਾ ਕਾਫਕਾ ਨੋਡ ਅਤੇ ਜ਼ੂਕੀਪਰ ਦੋਵਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਹੈ।
• ਦ੍ਰਿਸ਼ 7: ਕਾਫਕਾ ਕੰਟਰੋਲਰ ਨੋਡ ਕਿਸੇ ਹੋਰ ਕਾਫਕਾ ਨੋਡ ਨੂੰ ਨਹੀਂ ਦੇਖ ਸਕਦਾ।
• ਦ੍ਰਿਸ਼ 8: ਕਾਫਕਾ ਕੰਟਰੋਲਰ ਜ਼ੂਕੀਪਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ।

ਹਰ ਦ੍ਰਿਸ਼ ਦਾ ਆਪਣਾ ਵਿਹਾਰ ਹੁੰਦਾ ਹੈ।

ਦ੍ਰਿਸ਼ 1: ਅਨੁਯਾਈ ਨੇਤਾ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ, ਪਰ ਫਿਰ ਵੀ ਜ਼ੂਕੀਪਰ ਨੂੰ ਦੇਖਦਾ ਹੈ

ਚੌਲ. 22. ਦ੍ਰਿਸ਼ 1: ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦਾ ISR

ਕਨੈਕਟੀਵਿਟੀ ਅਸਫਲਤਾ ਬ੍ਰੋਕਰ 3 ਨੂੰ ਬ੍ਰੋਕਰ 1 ਅਤੇ 2 ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ, ਪਰ ਜ਼ੂਕੀਪਰ ਤੋਂ ਨਹੀਂ। ਬ੍ਰੋਕਰ 3 ਹੁਣ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬੇਨਤੀਆਂ ਨਹੀਂ ਭੇਜ ਸਕਦਾ ਹੈ। ਸਮਾਂ ਬੀਤ ਜਾਣ ਤੋਂ ਬਾਅਦ replica.lag.time.max.ms ਇਸ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸੰਦੇਸ਼ ਕਮਿਟਾਂ ਵਿੱਚ ਹਿੱਸਾ ਨਹੀਂ ਲੈਂਦਾ। ਇੱਕ ਵਾਰ ਕਨੈਕਟੀਵਿਟੀ ਬਹਾਲ ਹੋ ਜਾਣ 'ਤੇ, ਇਹ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਮੁੜ-ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਲੀਡਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨ 'ਤੇ ISR ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਜਾਵੇਗੀ। ਜ਼ੂਕੀਪਰ ਪਿੰਗ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ ਅਤੇ ਇਹ ਮੰਨ ਲਵੇਗਾ ਕਿ ਬ੍ਰੋਕਰ ਜ਼ਿੰਦਾ ਅਤੇ ਠੀਕ ਹੈ।

ਚੌਲ. 23. ਦ੍ਰਿਸ਼ 1: ਬ੍ਰੋਕਰ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜੇਕਰ replica.lag.time.max.ms ਅੰਤਰਾਲ ਦੇ ਅੰਦਰ ਇਸ ਤੋਂ ਕੋਈ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।

RabbitMQ ਵਾਂਗ ਕੋਈ ਸਪਲਿਟ-ਬ੍ਰੇਨ ਜਾਂ ਨੋਡ ਸਸਪੈਂਸ਼ਨ ਨਹੀਂ ਹੈ। ਇਸ ਦੀ ਬਜਾਏ, ਫਾਲਤੂਤਾ ਘਟਾਈ ਜਾਂਦੀ ਹੈ.

ਦ੍ਰਿਸ਼ 2: ਨੇਤਾ ਕੋਈ ਅਨੁਯਾਈ ਨਹੀਂ ਦੇਖਦਾ, ਪਰ ਫਿਰ ਵੀ ਚਿੜੀਆਘਰ ਨੂੰ ਦੇਖਦਾ ਹੈ

ਚੌਲ. 24. ਦ੍ਰਿਸ਼ 2. ਨੇਤਾ ਅਤੇ ਦੋ ਪੈਰੋਕਾਰ

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

ਚੌਲ. 25. ਦ੍ਰਿਸ਼ 2. ISR ਸਿਰਫ ਨੇਤਾ ਤੱਕ ਸੁੰਗੜ ਗਿਆ ਹੈ

ਦ੍ਰਿਸ਼ 3. ਅਨੁਯਾਈ ਨੇਤਾ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਪਰ ਚਿੜੀਆਘਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ

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

ਚੌਲ. 26. ਦ੍ਰਿਸ਼ 3: ਪੈਰੋਕਾਰ ਲੀਡਰ ਨੂੰ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ

ਦ੍ਰਿਸ਼ 4. ਲੀਡਰ ਪੈਰੋਕਾਰਾਂ ਨੂੰ ਦੇਖਦਾ ਹੈ, ਪਰ ਚਿੜੀਆਘਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ

ਚੌਲ. 27. ਦ੍ਰਿਸ਼ 4. ਨੇਤਾ ਅਤੇ ਦੋ ਪੈਰੋਕਾਰ

ਨੇਤਾ ਚਿੜੀਆਘਰ ਤੋਂ ਵੱਖ ਹੁੰਦਾ ਹੈ, ਪਰ ਪੈਰੋਕਾਰਾਂ ਵਾਲੇ ਦਲਾਲਾਂ ਤੋਂ ਨਹੀਂ।

ਚੌਲ. 28. ਦ੍ਰਿਸ਼ 4: ਨੇਤਾ ਚਿੜੀਆਘਰ ਤੋਂ ਅਲੱਗ

ਕੁਝ ਸਮੇਂ ਬਾਅਦ, ਜ਼ੂਕੀਪਰ ਇੱਕ ਬ੍ਰੋਕਰ ਅਸਫਲਤਾ ਨੂੰ ਦਰਜ ਕਰੇਗਾ ਅਤੇ ਇਸ ਬਾਰੇ ਕੰਟਰੋਲਰ ਨੂੰ ਸੂਚਿਤ ਕਰੇਗਾ। ਉਹ ਆਪਣੇ ਪੈਰੋਕਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਵਾਂ ਆਗੂ ਚੁਣੇਗਾ। ਹਾਲਾਂਕਿ, ਅਸਲੀ ਨੇਤਾ ਇਹ ਸੋਚਦਾ ਰਹੇਗਾ ਕਿ ਇਹ ਨੇਤਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਐਂਟਰੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਰਹੇਗਾ acks = 1. ਪੈਰੋਕਾਰ ਹੁਣ ਉਸਨੂੰ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨਹੀਂ ਭੇਜ ਰਹੇ ਹਨ, ਇਸਲਈ ਉਹ ਉਹਨਾਂ ਨੂੰ ਮਰੇ ਹੋਏ ਸਮਝੇਗਾ ਅਤੇ ISR ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁੰਗੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ। ਪਰ ਕਿਉਂਕਿ ਇਸਦਾ Zookeeper ਨਾਲ ਕੋਈ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ, ਇਹ ਅਜਿਹਾ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਉਸ ਸਮੇਂ ਕਿਸੇ ਹੋਰ ਐਂਟਰੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦੇਵੇਗਾ।

ਸੁਨੇਹੇ acks = ਸਾਰੇ ਇੱਕ ਰਸੀਦ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਵੇਗੀ ਕਿਉਂਕਿ ISR ਪਹਿਲਾਂ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੰਦੇਸ਼ ਉਹਨਾਂ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ ਹਨ। ਜਦੋਂ ਅਸਲੀ ਨੇਤਾ ਉਹਨਾਂ ਨੂੰ ISR ਤੋਂ ਹਟਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਜਿਹਾ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਹੋਵੇਗਾ ਅਤੇ ਕਿਸੇ ਵੀ ਸੰਦੇਸ਼ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ।

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

ਚੌਲ. 29. ਦ੍ਰਿਸ਼ 4. ਬ੍ਰੋਕਰ 1 'ਤੇ ਲੀਡਰ ਨੈੱਟਵਰਕ ਰੀਸਟੋਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਅਨੁਯਾਈ ਬਣ ਜਾਂਦਾ ਹੈ

ਦ੍ਰਿਸ਼ 5: ਅਨੁਯਾਈ ਕਾਫਕਾ ਨੋਡ ਅਤੇ ਜ਼ੂਕੀਪਰ ਦੋਵਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਹੈ

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

ਚੌਲ. 30. ਦ੍ਰਿਸ਼ 5: ਆਈਸੋਲੇਟਡ ਫਾਲੋਅਰ ਨੂੰ ISR ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ

ਦ੍ਰਿਸ਼ 6: ਨੇਤਾ ਕਾਫਕਾ ਨੋਡ ਅਤੇ ਜ਼ੂਕੀਪਰ ਦੋਵਾਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰਾ ਹੈ

ਚੌਲ. 31. ਦ੍ਰਿਸ਼ 6. ਨੇਤਾ ਅਤੇ ਦੋ ਪੈਰੋਕਾਰ

ਨੇਤਾ ਆਪਣੇ ਪੈਰੋਕਾਰਾਂ, ਕੰਟਰੋਲਰ ਅਤੇ ਚਿੜੀਆਘਰ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ-ਥਲੱਗ ਹੈ। ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਇਹ ਇੰਦਰਾਜਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ acks = 1.

ਚੌਲ. 32. ਦ੍ਰਿਸ਼ 6: ਲੀਡਰ ਨੂੰ ਹੋਰ ਕਾਫਕਾ ਅਤੇ ਜ਼ੂਕੀਪਰ ਨੋਡਾਂ ਤੋਂ ਅਲੱਗ ਕਰਨਾ

ਮਿਆਦ ਪੁੱਗਣ ਤੋਂ ਬਾਅਦ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਈਆਂ replica.lag.time.max.ms, ਇਹ ISR ਨੂੰ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁੰਗੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ, ਪਰ ਅਜਿਹਾ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ ਕਿਉਂਕਿ Zookeeper ਨਾਲ ਕੋਈ ਸੰਚਾਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਇਹ ਲਿਖਤਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ।

ਇਸ ਦੌਰਾਨ, ਜ਼ੂਕੀਪਰ ਅਲੱਗ-ਥਲੱਗ ਦਲਾਲ ਨੂੰ ਮਰੇ ਹੋਏ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰੇਗਾ ਅਤੇ ਕੰਟਰੋਲਰ ਇੱਕ ਨਵੇਂ ਨੇਤਾ ਦੀ ਚੋਣ ਕਰੇਗਾ।

ਚੌਲ. 33. ਦ੍ਰਿਸ਼ 6. ਦੋ ਨੇਤਾ

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

ਚੌਲ. 34. ਦ੍ਰਿਸ਼ 6: ਨਿਰਮਾਤਾ ਇੱਕ ਨਵੇਂ ਲੀਡਰ ਵੱਲ ਬਦਲਦੇ ਹਨ

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

ਚੌਲ. 35. ਦ੍ਰਿਸ਼ 6: ਨੈੱਟਵਰਕ ਕਨੈਕਟੀਵਿਟੀ ਬਹਾਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਅਸਲੀ ਨੇਤਾ ਇੱਕ ਅਨੁਯਾਈ ਬਣ ਜਾਂਦਾ ਹੈ

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਥੋੜ੍ਹੇ ਸਮੇਂ ਲਈ ਲਾਜ਼ੀਕਲ ਵਿਛੋੜਾ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਕੇਵਲ ਤਾਂ ਹੀ acks = 1 и min.insync.replicas ਇਹ ਵੀ 1. ਲਾਜ਼ੀਕਲ ਅਲਹਿਦਗੀ ਜਾਂ ਤਾਂ ਨੈੱਟਵਰਕ ਰੀਸਟੋਰ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਪਣੇ ਆਪ ਖਤਮ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਅਸਲੀ ਲੀਡਰ ਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਉਹ ਹੁਣ ਲੀਡਰ ਨਹੀਂ ਹੈ, ਜਾਂ ਜਦੋਂ ਸਾਰੇ ਗਾਹਕਾਂ ਨੂੰ ਅਹਿਸਾਸ ਹੁੰਦਾ ਹੈ ਕਿ ਲੀਡਰ ਬਦਲ ਗਿਆ ਹੈ ਅਤੇ ਨਵੇਂ ਲੀਡਰ ਨੂੰ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ - ਜੋ ਵੀ ਪਹਿਲਾਂ ਹੁੰਦਾ ਹੈ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਕੁਝ ਸੁਨੇਹੇ ਖਤਮ ਹੋ ਜਾਣਗੇ, ਪਰ ਸਿਰਫ ਨਾਲ acks = 1.

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

ਦ੍ਰਿਸ਼ 7: ਕਾਫਕਾ ਕੰਟਰੋਲਰ ਨੋਡ ਹੋਰ ਕਾਫਕਾ ਨੋਡ ਨਹੀਂ ਦੇਖ ਸਕਦਾ

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

ਦ੍ਰਿਸ਼ 8: ਕਾਫਕਾ ਕੰਟਰੋਲਰ ਜ਼ੂਕੀਪਰ ਨੂੰ ਨਹੀਂ ਦੇਖਦਾ

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

ਦ੍ਰਿਸ਼ਾਂ ਤੋਂ ਸਿੱਟੇ

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

ਜੇਕਰ ਨੇਤਾ ਕੁਨੈਕਟੀਵਿਟੀ ਦੇ ਨੁਕਸਾਨ ਦੇ ਕਾਰਨ ਜ਼ੂਕੀਪਰ ਤੋਂ ਵੱਖ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸੁਨੇਹੇ ਗੁੰਮ ਹੋ ਸਕਦੇ ਹਨ acks = 1. Zookeeper ਨਾਲ ਸੰਚਾਰ ਦੀ ਘਾਟ ਦੋਵਾਂ ਨੇਤਾਵਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸੰਖੇਪ ਤਰਕਪੂਰਨ ਵੰਡ ਦਾ ਕਾਰਨ ਬਣਦੀ ਹੈ। ਇਹ ਸਮੱਸਿਆ ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ ਹੱਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ acks = ਸਾਰੇ.

ਪੈਰਾਮੀਟਰ min.insync.replicas ਦੋ ਜਾਂ ਦੋ ਤੋਂ ਵੱਧ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਵਿੱਚ ਇਹ ਵਾਧੂ ਭਰੋਸਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਕਿ ਅਜਿਹੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਦ੍ਰਿਸ਼ 6 ਵਿੱਚ ਗੁੰਮ ਹੋਏ ਸੰਦੇਸ਼ ਨਹੀਂ ਹੋਣਗੇ।

ਗੁੰਮ ਹੋਏ ਸੁਨੇਹਿਆਂ ਦਾ ਸੰਖੇਪ

ਆਉ ਉਹਨਾਂ ਸਾਰੇ ਤਰੀਕਿਆਂ ਨੂੰ ਸੂਚੀਬੱਧ ਕਰੀਏ ਜਿਨ੍ਹਾਂ ਨਾਲ ਤੁਸੀਂ ਕਾਫਕਾ ਵਿੱਚ ਡੇਟਾ ਗੁਆ ਸਕਦੇ ਹੋ:

• ਜੇਕਰ ਸੁਨੇਹਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ ਸੀ ਤਾਂ ਕੋਈ ਲੀਡਰ ਅਸਫਲਤਾ acks = 1
• ਲੀਡਰਸ਼ਿਪ ਦਾ ਕੋਈ ਵੀ ਅਸ਼ੁੱਧ ਪਰਿਵਰਤਨ, ਜੋ ਕਿ, ISR ਤੋਂ ਬਾਹਰ ਇੱਕ ਅਨੁਯਾਈ ਤੱਕ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਨਾਲ ਵੀ acks = ਸਾਰੇ
• ਜੇਕਰ ਸੁਨੇਹਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ Zookeeper ਤੋਂ ਨੇਤਾ ਨੂੰ ਅਲੱਗ ਕਰਨਾ acks = 1
• ਨੇਤਾ ਦੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਲੱਗ-ਥਲੱਗਤਾ ਜਿਸ ਨੇ ਪਹਿਲਾਂ ਹੀ ISR ਸਮੂਹ ਨੂੰ ਆਪਣੇ ਤੱਕ ਸੁੰਗੜ ਲਿਆ ਹੈ। ਸਾਰੇ ਸੁਨੇਹੇ ਖਤਮ ਹੋ ਜਾਣਗੇ, ਇੱਥੋਂ ਤੱਕ ਕਿ acks = ਸਾਰੇ. ਇਹ ਤਾਂ ਹੀ ਸੱਚ ਹੈ ਜੇਕਰ min.insync.replicas=1.
• ਸਾਰੇ ਭਾਗ ਨੋਡਾਂ ਦੀਆਂ ਸਮਕਾਲੀ ਅਸਫਲਤਾਵਾਂ। ਕਿਉਂਕਿ ਸੁਨੇਹੇ ਮੈਮੋਰੀ ਤੋਂ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕੁਝ ਅਜੇ ਤੱਕ ਡਿਸਕ 'ਤੇ ਨਾ ਲਿਖੇ ਜਾ ਸਕਣ। ਸਰਵਰਾਂ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕੁਝ ਸੁਨੇਹੇ ਗੁੰਮ ਹੋ ਸਕਦੇ ਹਨ।

ਅਸ਼ੁੱਧ ਲੀਡਰਸ਼ਿਪ ਪਰਿਵਰਤਨ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਤਾਂ ਉਹਨਾਂ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾ ਕੇ ਜਾਂ ਘੱਟੋ-ਘੱਟ ਦੋ ਰਿਡੰਡੈਂਸੀਆਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾ ਕੇ। ਸਭ ਤੋਂ ਟਿਕਾਊ ਸੰਰਚਨਾ ਇੱਕ ਸੁਮੇਲ ਹੈ acks = ਸਾਰੇ и min.insync.replicas 1 ਤੋਂ ਵੱਧ।

RabbitMQ ਅਤੇ Kafka ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਸਿੱਧੀ ਤੁਲਨਾ

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

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

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

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

ਕਾਫਕਾ ਦੀ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਕੋਈ ਸੁਨੇਹਾ ਮਲਟੀਪਲ ਨੋਡਾਂ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਮੈਮੋਰੀ ਨੂੰ ਹਿੱਟ ਕਰਦੇ ਹੀ ਸੰਦੇਸ਼ਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਕਾਰਨ, ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਸੁਨੇਹਿਆਂ ਦੇ ਗੁਆਚਣ ਦਾ ਜੋਖਮ ਹੁੰਦਾ ਹੈ (ਭਾਵੇਂ acks = ਸਾਰੇ, min.insync.replicas=2) ਸਮਕਾਲੀ ਅਸਫਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ.

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਕਾਫਕਾ ਬਿਹਤਰ ਸੌਫਟਵੇਅਰ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰਾਂ ਲਈ ਜ਼ਮੀਨ ਤੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਲੋੜ ਪੈਣ 'ਤੇ ਪੈਰੋਕਾਰਾਂ ਦੀ ਗਿਣਤੀ 11 ਤੱਕ ਵਧਾਈ ਜਾ ਸਕਦੀ ਹੈ। ਸਮਕਾਲੀਕਰਨ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਕਾਰਕ 5 ਅਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਸੰਖਿਆ min.insync.replicas=3 ਸੁਨੇਹਾ ਗੁਆਉਣ ਨੂੰ ਇੱਕ ਬਹੁਤ ਹੀ ਦੁਰਲੱਭ ਘਟਨਾ ਬਣਾ ਦੇਵੇਗਾ। ਜੇਕਰ ਤੁਹਾਡਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਅਨੁਪਾਤ ਅਤੇ ਰਿਡੰਡੈਂਸੀ ਦੇ ਪੱਧਰ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਇਸ ਵਿਕਲਪ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ।

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

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

ਅੰਤ ਵਿੱਚ, RabbitMQ ਅਤੇ Kafka ਦੋਵਾਂ ਦੇ ਕਲੱਸਟਰਿੰਗ ਅਤੇ ਰੀਪਲੀਕੇਸ਼ਨ ਮਕੈਨਿਜ਼ਮ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਬੱਗਾਂ ਬਾਰੇ ਨਾ ਭੁੱਲੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਸਿਸਟਮ ਵਧੇਰੇ ਪਰਿਪੱਕ ਅਤੇ ਸਥਿਰ ਹੋ ਗਏ ਹਨ, ਪਰ ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਕਦੇ ਵੀ ਨੁਕਸਾਨ ਤੋਂ 100% ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੋਵੇਗਾ! ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿਚ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਹਾਦਸੇ ਵਾਪਰਦੇ ਹਨ!

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

ਮੈਨੂੰ ਅਕਸਰ ਪੁੱਛਿਆ ਜਾਂਦਾ ਹੈ: "ਕੀ ਚੁਣਨਾ ਹੈ, ਕਾਫਕਾ ਜਾਂ RabbitMQ?", "ਕੌਣ ਪਲੇਟਫਾਰਮ ਬਿਹਤਰ ਹੈ?"। ਸੱਚਾਈ ਇਹ ਹੈ ਕਿ ਇਹ ਅਸਲ ਵਿੱਚ ਤੁਹਾਡੀ ਸਥਿਤੀ, ਮੌਜੂਦਾ ਅਨੁਭਵ, ਆਦਿ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਮੈਂ ਆਪਣੀ ਰਾਏ ਦੇਣ ਤੋਂ ਝਿਜਕਦਾ ਹਾਂ ਕਿਉਂਕਿ ਸਾਰੇ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਅਤੇ ਸੰਭਾਵਿਤ ਸੀਮਾਵਾਂ ਲਈ ਇੱਕ ਪਲੇਟਫਾਰਮ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਰਲੀਕਰਨ ਹੋਵੇਗਾ। ਮੈਂ ਲੇਖਾਂ ਦੀ ਇਹ ਲੜੀ ਲਿਖੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਆਪਣੀ ਰਾਏ ਬਣਾ ਸਕੋ।

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

ਮੈਂ ਹੋਰ ਤਕਨੀਕਾਂ ਦੇਖਦਾ ਹਾਂ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇਸ ਭਰੋਸੇਯੋਗਤਾ ਅਤੇ ਗਾਰੰਟੀਸ਼ੁਦਾ ਆਰਡਰਿੰਗ ਦੀ ਘਾਟ ਹੈ, ਫਿਰ ਮੈਂ RabbitMQ ਅਤੇ Kafka ਨੂੰ ਦੇਖਦਾ ਹਾਂ ਅਤੇ ਇਹਨਾਂ ਦੋਵਾਂ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਸ਼ਾਨਦਾਰ ਮੁੱਲ ਨੂੰ ਮਹਿਸੂਸ ਕਰਦਾ ਹਾਂ।

ਸਰੋਤ: www.habr.com