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

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

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

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

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

ਸਿੰਗਲ ਨੋਡ ਲਚਕੀਲੇਪਨ ਆਦਿ

ਲਚਕਦਾਰ ਕਤਾਰਬੰਦੀ/ਰੂਟਿੰਗ

RabbitMQ ਵਿੱਚ ਦੋ ਕਿਸਮਾਂ ਦੀਆਂ ਕਤਾਰਾਂ ਹਨ: ਟਿਕਾਊ ਅਤੇ ਗੈਰ-ਟਿਕਾਊ। ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਮੇਨਸੀਆ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਟਿਕਾਊ ਕਤਾਰਾਂ ਨੂੰ ਨੋਡ ਸਟਾਰਟਅਪ 'ਤੇ ਦੁਬਾਰਾ ਇਸ਼ਤਿਹਾਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਰੀਸਟਾਰਟ, ਸਿਸਟਮ ਕਰੈਸ਼, ਜਾਂ ਸਰਵਰ ਕ੍ਰੈਸ਼ਾਂ (ਜਿੰਨਾ ਚਿਰ ਡਾਟਾ ਬਰਕਰਾਰ ਰਹਿੰਦਾ ਹੈ) ਬਚ ਜਾਂਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਿੰਨਾ ਚਿਰ ਤੁਸੀਂ ਰੂਟਿੰਗ (ਐਕਸਚੇਂਜ) ਅਤੇ ਕਤਾਰ ਨੂੰ ਲਚਕੀਲੇ ਹੋਣ ਦਾ ਐਲਾਨ ਕਰਦੇ ਹੋ, ਕਤਾਰ/ਰੂਟਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਔਨਲਾਈਨ ਵਾਪਸ ਆ ਜਾਵੇਗਾ।

ਜਦੋਂ ਨੋਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਅਸਥਿਰ ਕਤਾਰਾਂ ਅਤੇ ਰੂਟਿੰਗ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਲਗਾਤਾਰ ਸੁਨੇਹੇ

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

ਚੌਲ. 1. ਸਥਿਰਤਾ ਮੈਟ੍ਰਿਕਸ

ਕਤਾਰ ਮਿਰਰਿੰਗ ਨਾਲ ਕਲੱਸਟਰਿੰਗ

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

ਕਤਾਰ ਮਿਰਰਿੰਗ:

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

ਚੌਲ. 2. ਕਤਾਰ ਮਿਰਰਿੰਗ

ਮਿਰਰਿੰਗ ਉਚਿਤ ਨੀਤੀ ਦੁਆਰਾ ਸੈੱਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਤੁਸੀਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਗੁਣਾਂਕ ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਉਹ ਨੋਡ ਵੀ ਚੁਣ ਸਕਦੇ ਹੋ ਜਿਨ੍ਹਾਂ 'ਤੇ ਕਤਾਰ ਸਥਿਤ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਦਾਹਰਨਾਂ:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ਇੱਕ ਮਾਸਟਰ ਅਤੇ ਇੱਕ ਸ਼ੀਸ਼ਾ)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ਪ੍ਰਕਾਸ਼ਕ ਦੀ ਪੁਸ਼ਟੀ

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

ਫੇਲਓਵਰ ਕਤਾਰ

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

ਚੌਲ. 3. ਕਈ ਪ੍ਰਤੀਬਿੰਬ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਨੀਤੀਆਂ

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

ਚੌਲ. 4. ਬ੍ਰੋਕਰ 3 ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕਤਾਰ C ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ

ਅਗਲਾ ਬ੍ਰੋਕਰ 1 ਡਿੱਗਦਾ ਹੈ! ਸਾਡੇ ਕੋਲ ਸਿਰਫ਼ ਇੱਕ ਦਲਾਲ ਬਚਿਆ ਹੈ। ਕਤਾਰ ਬੀ ਮਿਰਰ ਨੂੰ ਮਾਸਟਰ ਵਜੋਂ ਤਰੱਕੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

ਅੰਜੀਰ. 5

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

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

ਚੌਲ. 6. ਬ੍ਰੋਕਰ 1 ਸੇਵਾ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ

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

ਚੌਲ. 7. ਬ੍ਰੋਕਰ 3 ਸੇਵਾ 'ਤੇ ਵਾਪਸ ਆਉਂਦਾ ਹੈ। ਇੱਕ ਨੋਡ 'ਤੇ ਸਾਰੀਆਂ ਮੁੱਖ ਕਤਾਰਾਂ!

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

ਸਮਕਾਲੀਕਰਨ

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

ਇਹ ਸਮਕਾਲੀਕਰਨ ਆਟੋਮੈਟਿਕ ਜਾਂ ਹੱਥੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕਤਾਰ ਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਆਓ ਇੱਕ ਉਦਾਹਰਨ ਦੇਖੀਏ।

ਸਾਡੇ ਕੋਲ ਦੋ ਪ੍ਰਤੀਬਿੰਬ ਵਾਲੀਆਂ ਕਤਾਰਾਂ ਹਨ। ਕਤਾਰ A ਆਟੋਮੈਟਿਕਲੀ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਤਾਰ B ਹੱਥੀਂ ਸਮਕਾਲੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਦੋਵਾਂ ਕਤਾਰਾਂ ਵਿੱਚ ਦਸ ਸੁਨੇਹੇ ਹਨ।

ਚੌਲ. 8. ਵੱਖ-ਵੱਖ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਮੋਡਾਂ ਨਾਲ ਦੋ ਕਤਾਰਾਂ

ਹੁਣ ਅਸੀਂ ਬ੍ਰੋਕਰ 3 ਨੂੰ ਗੁਆ ਰਹੇ ਹਾਂ।

ਚੌਲ. 9. ਦਲਾਲ 3 ਡਿੱਗਿਆ

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

ਚੌਲ. 10. ਕਤਾਰ A ਦਾ ਨਵਾਂ ਸ਼ੀਸ਼ਾ ਸਾਰੇ ਮੌਜੂਦਾ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਪਰ ਕਤਾਰ B ਦਾ ਨਵਾਂ ਸ਼ੀਸ਼ਾ ਨਹੀਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ।

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

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

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

ਜੇਕਰ ਅਸੀਂ ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਨੀਤੀ ha-promote-on-fallure ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਹਮੇਸ਼ਾ. ਇਹ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲ ਹੈ, ਇਸਲਈ ਤੁਸੀਂ ਨੀਤੀ ਨੂੰ ਬਿਲਕੁਲ ਵੀ ਨਿਰਧਾਰਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਗੈਰ-ਸਮਕਾਲੀ ਮਿਰਰਾਂ ਵਿੱਚ ਅਸਫਲਤਾਵਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਰਹੇ ਹਾਂ। ਇਸ ਨਾਲ ਸੁਨੇਹੇ ਖਤਮ ਹੋ ਜਾਣਗੇ, ਪਰ ਕਤਾਰ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਲਿਖਣਯੋਗ ਰਹੇਗੀ।

ਚੌਲ. 12. ਕਤਾਰ A ਨੂੰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਗੁਆਏ ਬਿਨਾਂ ਬ੍ਰੋਕਰ 3 'ਤੇ ਵਾਪਸ ਭੇਜ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕਤਾਰ B ਗੁੰਮ ਹੋਏ ਦਸ ਸੁਨੇਹਿਆਂ ਦੇ ਨਾਲ ਬ੍ਰੋਕਰ 3 'ਤੇ ਵਾਪਸ ਚਲੀ ਜਾਂਦੀ ਹੈ

ਅਸੀਂ ਵੀ ਇੰਸਟਾਲ ਕਰ ਸਕਦੇ ਹਾਂ ha-promote-on-failure ਅਰਥ ਵਿੱਚ when-synced. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸ਼ੀਸ਼ੇ ਵਿੱਚ ਵਾਪਸ ਜਾਣ ਦੀ ਬਜਾਏ, ਕਤਾਰ ਉਦੋਂ ਤੱਕ ਉਡੀਕ ਕਰੇਗੀ ਜਦੋਂ ਤੱਕ ਬ੍ਰੋਕਰ 1 ਆਪਣੇ ਡੇਟਾ ਦੇ ਨਾਲ ਔਨਲਾਈਨ ਮੋਡ ਵਿੱਚ ਵਾਪਸ ਨਹੀਂ ਆਉਂਦਾ। ਇਸ ਦੇ ਵਾਪਸ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਮੁੱਖ ਕਤਾਰ ਬਿਨਾਂ ਕਿਸੇ ਡੇਟਾ ਦੇ ਨੁਕਸਾਨ ਦੇ ਬ੍ਰੋਕਰ 1 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ। ਡਾਟਾ ਸੁਰੱਖਿਆ ਲਈ ਉਪਲਬਧਤਾ ਦੀ ਬਲੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਪਰ ਇਹ ਇੱਕ ਜੋਖਮ ਭਰਿਆ ਮੋਡ ਹੈ ਜੋ ਪੂਰੇ ਡੇਟਾ ਦਾ ਨੁਕਸਾਨ ਵੀ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਜਲਦੀ ਹੀ ਦੇਖਾਂਗੇ।

ਚੌਲ. 13. ਬ੍ਰੋਕਰ 1 ਨੂੰ ਗੁਆਉਣ ਤੋਂ ਬਾਅਦ ਕਤਾਰ B ਅਣਉਪਲਬਧ ਰਹਿੰਦੀ ਹੈ

ਤੁਸੀਂ ਪੁੱਛ ਸਕਦੇ ਹੋ, "ਕੀ ਕਦੇ ਵੀ ਆਟੋਮੈਟਿਕ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ?" ਜਵਾਬ ਇਹ ਹੈ ਕਿ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਇੱਕ ਬਲਾਕਿੰਗ ਓਪਰੇਸ਼ਨ ਹੈ. ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦੇ ਦੌਰਾਨ, ਮੁੱਖ ਕਤਾਰ ਕੋਈ ਪੜ੍ਹਨ ਜਾਂ ਲਿਖਣ ਦੀ ਕਾਰਵਾਈ ਨਹੀਂ ਕਰ ਸਕਦੀ!

ਆਓ ਇੱਕ ਉਦਾਹਰਨ ਦੇਖੀਏ। ਹੁਣ ਸਾਡੀਆਂ ਬਹੁਤ ਲੰਬੀਆਂ ਕਤਾਰਾਂ ਹਨ। ਉਹ ਅਜਿਹੇ ਆਕਾਰ ਵਿਚ ਕਿਵੇਂ ਵਧ ਸਕਦੇ ਹਨ? ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ:

• ਕਤਾਰਾਂ ਸਰਗਰਮੀ ਨਾਲ ਨਹੀਂ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ
• ਇਹ ਹਾਈ-ਸਪੀਡ ਕਤਾਰਾਂ ਹਨ, ਅਤੇ ਇਸ ਸਮੇਂ ਖਪਤਕਾਰ ਹੌਲੀ ਹਨ
• ਇਹ ਹਾਈ-ਸਪੀਡ ਕਤਾਰਾਂ ਹਨ, ਇੱਕ ਗੜਬੜ ਹੈ ਅਤੇ ਖਪਤਕਾਰ ਫੜ ਰਹੇ ਹਨ

ਚੌਲ. 14. ਵੱਖ-ਵੱਖ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਮੋਡਾਂ ਨਾਲ ਦੋ ਵੱਡੀਆਂ ਕਤਾਰਾਂ

ਹੁਣ ਬ੍ਰੋਕਰ 3 ਡਿੱਗਦਾ ਹੈ।

ਚੌਲ. 15. ਬ੍ਰੋਕਰ 3 ਡਿੱਗਦਾ ਹੈ, ਹਰੇਕ ਕਤਾਰ ਵਿੱਚ ਇੱਕ ਮਾਸਟਰ ਅਤੇ ਸ਼ੀਸ਼ਾ ਛੱਡਦਾ ਹੈ

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

ਹਾਲਾਂਕਿ, ਕਤਾਰ ਬੀ ਪੂਰੀ ਮਿਆਦ ਦੌਰਾਨ ਉਪਲਬਧ ਰਹਿੰਦੀ ਹੈ। ਉਸਨੇ ਪਹੁੰਚਯੋਗਤਾ ਲਈ ਕੁਝ ਫਾਲਤੂਤਾ ਦੀ ਬਲੀ ਦਿੱਤੀ।

ਚੌਲ. 16. ਸਮਕਾਲੀਕਰਨ ਦੌਰਾਨ ਕਤਾਰ ਅਣਉਪਲਬਧ ਰਹਿੰਦੀ ਹੈ

ਦੋ ਘੰਟਿਆਂ ਬਾਅਦ, ਕਤਾਰ A ਵੀ ਉਪਲਬਧ ਹੋ ਜਾਂਦੀ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਪੜ੍ਹਨਾ ਅਤੇ ਲਿਖਣਾ ਸਵੀਕਾਰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।

ਅੱਪਡੇਟ

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

• always= ਗੈਰ-ਸਿੰਕਰੋਨਾਈਜ਼ਡ ਮਿਰਰਾਂ ਵਿੱਚ ਤਬਦੀਲੀ ਯੋਗ ਹੈ
• when-synced= ਕੇਵਲ ਇੱਕ ਸਮਕਾਲੀ ਸ਼ੀਸ਼ੇ ਵਿੱਚ ਤਬਦੀਲੀ, ਨਹੀਂ ਤਾਂ ਕਤਾਰ ਪੜ੍ਹਨਯੋਗ ਅਤੇ ਲਿਖਣਯੋਗ ਨਹੀਂ ਹੋ ਜਾਂਦੀ ਹੈ। ਬ੍ਰੋਕਰ ਦੇ ਵਾਪਸ ਆਉਂਦੇ ਹੀ ਕਤਾਰ ਸੇਵਾ 'ਤੇ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ

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

ਜਦੋਂ ਉਪਲਬਧਤਾ ਡੇਟਾ ਸੁਰੱਖਿਆ ਵਿੱਚ ਸੁਧਾਰ ਕਰਦੀ ਹੈ

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

ਇੱਥੇ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ:

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਇੱਕ ਸੰਤੁਲਨ ਦੀ ਮੰਗ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ ਹੱਲ ਖਾਸ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ha-promote-on-failure=ਜਦੋਂ-ਸਮਕਾਲੀਕਰਨ ਨਾਲ ਸਮੱਸਿਆਵਾਂ

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

ਪਰ (ਅਤੇ ਇਹ ਇੱਕ ਵੱਡਾ ਹੈ ਪਰ) ਜੇਕਰ ਬ੍ਰੋਕਰ ਨੇ ਆਪਣਾ ਡੇਟਾ ਗੁਆ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਹੈ: ਕਤਾਰ ਖਤਮ ਹੋ ਗਈ ਹੈ! ਸਾਰਾ ਡਾਟਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ! ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਸ਼ੀਸ਼ੇ ਹਨ ਜੋ ਜ਼ਿਆਦਾਤਰ ਮੁੱਖ ਕਤਾਰ ਦੇ ਨਾਲ ਫੜਦੇ ਹਨ, ਉਹ ਸ਼ੀਸ਼ੇ ਵੀ ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।

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

ਇਸ ਲਈ, ਦਸਤੀ ਸਮਕਾਲੀਕਰਨ (ਅਤੇ ਸਮਕਾਲੀ ਕਰਨ ਵਿੱਚ ਅਸਫਲਤਾ) ਦੇ ਨਾਲ ਸੁਮੇਲ ਵਿੱਚ ha-promote-on-failure=when-synced, ਮੇਰੇ ਵਿਚਾਰ ਵਿੱਚ, ਕਾਫ਼ੀ ਖ਼ਤਰਨਾਕ. ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ ਇਹ ਵਿਕਲਪ ਡੇਟਾ ਸੁਰੱਖਿਆ ਲਈ ਮੌਜੂਦ ਹੈ, ਪਰ ਇਹ ਦੋ-ਧਾਰੀ ਚਾਕੂ ਹੈ।

ਮਾਸਟਰ ਮੁੜ ਸੰਤੁਲਨ

ਜਿਵੇਂ ਵਾਅਦਾ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਸੀਂ ਇੱਕ ਜਾਂ ਕਈ ਨੋਡਾਂ 'ਤੇ ਸਾਰੇ ਮਾਸਟਰਾਂ ਦੇ ਇਕੱਠੇ ਹੋਣ ਦੀ ਸਮੱਸਿਆ ਵੱਲ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ। ਇਹ ਰੋਲਿੰਗ ਕਲੱਸਟਰ ਅਪਡੇਟ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਵੀ ਹੋ ਸਕਦਾ ਹੈ। ਤਿੰਨ-ਨੋਡ ਕਲੱਸਟਰ ਵਿੱਚ, ਸਾਰੀਆਂ ਮਾਸਟਰ ਕਤਾਰਾਂ ਇੱਕ ਜਾਂ ਦੋ ਨੋਡਾਂ 'ਤੇ ਇਕੱਠੀਆਂ ਹੋਣਗੀਆਂ।

ਮਾਸਟਰਾਂ ਨੂੰ ਮੁੜ ਸੰਤੁਲਿਤ ਕਰਨਾ ਦੋ ਕਾਰਨਾਂ ਕਰਕੇ ਸਮੱਸਿਆ ਹੋ ਸਕਦਾ ਹੈ:

• ਪੁਨਰ-ਸੰਤੁਲਨ ਕਰਨ ਲਈ ਕੋਈ ਵਧੀਆ ਸਾਧਨ ਨਹੀਂ ਹਨ
• ਕਤਾਰ ਸਮਕਾਲੀਕਰਨ

ਮੁੜ ਸੰਤੁਲਨ ਲਈ ਇੱਕ ਤੀਜੀ ਧਿਰ ਹੈ ਪਲੱਗਇਨ, ਜੋ ਅਧਿਕਾਰਤ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। RabbitMQ ਮੈਨੂਅਲ ਵਿੱਚ ਤੀਜੀ ਧਿਰ ਪਲੱਗਇਨਾਂ ਬਾਰੇ ਨੇ ਕਿਹਾ: “ਪਲੱਗਇਨ ਕੁਝ ਵਾਧੂ ਸੰਰਚਨਾ ਅਤੇ ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਪਰ RabbitMQ ਟੀਮ ਦੁਆਰਾ ਸਮਰਥਿਤ ਜਾਂ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਹੈ। ਆਪਣੇ ਜੋਖਮ 'ਤੇ ਵਰਤੋਂ।"

HA ਨੀਤੀਆਂ ਰਾਹੀਂ ਮੁੱਖ ਕਤਾਰ ਨੂੰ ਮੂਵ ਕਰਨ ਦੀ ਇੱਕ ਹੋਰ ਚਾਲ ਹੈ। ਮੈਨੁਅਲ ਦਾ ਜ਼ਿਕਰ ਹੈ ਸਕ੍ਰਿਪਟ ਇਸ ਲਈ. ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

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

ਨਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਇਹ ਪਹੁੰਚ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਵੱਡੀਆਂ ਕਤਾਰਾਂ ਹਨ ਜਾਂ ਸਖ਼ਤ ਰਿਡੰਡੈਂਸੀ ਲੋੜਾਂ ਹਨ।

ਹੁਣ ਆਓ ਦੇਖੀਏ ਕਿ RabbitMQ ਕਲੱਸਟਰ ਨੈੱਟਵਰਕ ਭਾਗਾਂ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ।

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

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

RabbitMQ ਨਾਲ ਸਾਡੇ ਕੋਲ ਦੋ ਮੁੱਖ ਵਿਕਲਪ ਹਨ:

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

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

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

ਜੇਕਰ ਪ੍ਰਕਾਸ਼ਕ ਦੋਵਾਂ ਮਾਸਟਰਾਂ ਨੂੰ ਡੇਟਾ ਭੇਜਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਕਤਾਰ ਦੀਆਂ ਦੋ ਵੱਖੋ-ਵੱਖਰੀਆਂ ਕਾਪੀਆਂ ਦੇ ਨਾਲ ਸਮਾਪਤ ਕਰਦੇ ਹਾਂ।

RabbitMQ ਦੇ ਵੱਖ-ਵੱਖ ਮੋਡ ਜਾਂ ਤਾਂ ਉਪਲਬਧਤਾ ਜਾਂ ਇਕਸਾਰਤਾ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ।

ਅਣਡਿੱਠ ਮੋਡ (ਡਿਫੌਲਟ)

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

ਚੌਲ. 18. ਤਿੰਨ ਪ੍ਰਕਾਸ਼ਕ ਤਿੰਨ ਦਲਾਲਾਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਕਲੱਸਟਰ ਬ੍ਰੋਕਰ 2 'ਤੇ ਮੁੱਖ ਕਤਾਰ ਲਈ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ।

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

ਚੌਲ. 19. ਲਾਜ਼ੀਕਲ ਡਿਵੀਜ਼ਨ (ਸਪਲਿਟ-ਬ੍ਰੇਨ)। ਰਿਕਾਰਡ ਦੋ ਮੁੱਖ ਕਤਾਰਾਂ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਦੋ ਕਾਪੀਆਂ ਵੱਖ ਹੋ ਜਾਂਦੀਆਂ ਹਨ।

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

ਚੌਲ. 20. ਪ੍ਰਸ਼ਾਸਕ ਬ੍ਰੋਕਰ 3 ਨੂੰ ਅਯੋਗ ਕਰਦਾ ਹੈ।

ਚੌਲ. 21. ਪ੍ਰਸ਼ਾਸਕ ਬ੍ਰੋਕਰ 3 ਨੂੰ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਕਲੱਸਟਰ ਨਾਲ ਜੁੜ ਜਾਂਦਾ ਹੈ, ਉੱਥੇ ਰਹਿ ਗਏ ਸਾਰੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਗੁਆ ਦਿੰਦਾ ਹੈ।

ਕੁਨੈਕਟੀਵਿਟੀ ਦੇ ਨੁਕਸਾਨ ਦੇ ਦੌਰਾਨ ਅਤੇ ਇਸਦੀ ਬਹਾਲੀ ਤੋਂ ਬਾਅਦ, ਕਲੱਸਟਰ ਅਤੇ ਇਹ ਕਤਾਰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਲਈ ਉਪਲਬਧ ਸਨ।

ਆਟੋਹੀਲ ਮੋਡ

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

ਘੱਟ ਗਿਣਤੀ ਮੋਡ ਨੂੰ ਰੋਕੋ

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

ਚੌਲ. 22. ਤਿੰਨ ਪ੍ਰਕਾਸ਼ਕ ਤਿੰਨ ਦਲਾਲਾਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, ਕਲੱਸਟਰ ਬ੍ਰੋਕਰ 2 'ਤੇ ਮੁੱਖ ਕਤਾਰ ਲਈ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ।

ਬ੍ਰੋਕਰ 1 ਅਤੇ 2 ਫਿਰ ਬ੍ਰੋਕਰ 3 ਤੋਂ ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ। ਆਪਣੇ ਸ਼ੀਸ਼ੇ ਨੂੰ ਮਾਸਟਰ ਬਣਾਉਣ ਦੀ ਬਜਾਏ, ਬ੍ਰੋਕਰ 3 ਨੂੰ ਮੁਅੱਤਲ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਣਉਪਲਬਧ ਹੋ ਜਾਂਦਾ ਹੈ।

ਚੌਲ. 23. ਬ੍ਰੋਕਰ 3 ਵਿਰਾਮ ਕਰਦਾ ਹੈ, ਸਾਰੇ ਗਾਹਕਾਂ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਬੇਨਤੀਆਂ ਨੂੰ ਰੱਦ ਕਰਦਾ ਹੈ।

ਇੱਕ ਵਾਰ ਕਨੈਕਟੀਵਿਟੀ ਰੀਸਟੋਰ ਹੋ ਜਾਂਦੀ ਹੈ, ਇਹ ਕਲੱਸਟਰ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਂਦੀ ਹੈ।

ਆਉ ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ ਵੇਖੀਏ ਜਿੱਥੇ ਮੁੱਖ ਕਤਾਰ ਬ੍ਰੋਕਰ 3 'ਤੇ ਹੈ.

ਚੌਲ. 24. ਬ੍ਰੋਕਰ 3 'ਤੇ ਮੁੱਖ ਕਤਾਰ।

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

ਚੌਲ. 25. ਬ੍ਰੋਕਰ 2 ਵਿੱਚ ਤਬਦੀਲੀ ਜੇਕਰ ਬ੍ਰੋਕਰ 3 ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਜਦੋਂ ਕਨੈਕਟੀਵਿਟੀ ਬਹਾਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਬ੍ਰੋਕਰ 3 ਕਲੱਸਟਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋ ਜਾਵੇਗਾ।

ਚੌਲ. 26. ਕਲੱਸਟਰ ਆਮ ਕਾਰਵਾਈ 'ਤੇ ਵਾਪਸ ਆ ਗਿਆ ਹੈ।

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

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

ਗਾਹਕ ਕਨੈਕਟੀਵਿਟੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ

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

ਸਾਡੇ ਵਿਕਲਪ:

• ਕਲੱਸਟਰ ਨੂੰ ਇੱਕ ਲੋਡ ਬੈਲੇਂਸਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਕਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਨੋਡਾਂ ਰਾਹੀਂ ਚੱਕਰ ਲਗਾਉਂਦਾ ਹੈ ਅਤੇ ਗਾਹਕ ਸਫ਼ਲ ਹੋਣ ਤੱਕ ਕਨੈਕਟ ਕਰਨ ਦੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। ਜੇਕਰ ਕੋਈ ਨੋਡ ਡਾਊਨ ਜਾਂ ਮੁਅੱਤਲ ਹੈ, ਤਾਂ ਉਸ ਨੋਡ ਨਾਲ ਜੁੜਨ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਅਸਫਲ ਹੋ ਜਾਣਗੀਆਂ, ਪਰ ਬਾਅਦ ਦੀਆਂ ਕੋਸ਼ਿਸ਼ਾਂ ਦੂਜੇ ਸਰਵਰਾਂ 'ਤੇ ਜਾਣਗੀਆਂ (ਇੱਕ ਰਾਊਂਡ-ਰੋਬਿਨ ਫੈਸ਼ਨ ਵਿੱਚ)। ਇਹ ਕੁਨੈਕਟੀਵਿਟੀ ਦੇ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਨੁਕਸਾਨ ਜਾਂ ਡਾਊਨ ਕੀਤੇ ਸਰਵਰ ਲਈ ਢੁਕਵਾਂ ਹੈ ਜੋ ਜਲਦੀ ਬੈਕਅੱਪ ਲਿਆ ਜਾਵੇਗਾ।
• ਇੱਕ ਲੋਡ ਬੈਲੇਂਸਰ ਦੁਆਰਾ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਕਰੋ ਅਤੇ ਜਿਵੇਂ ਹੀ ਉਹਨਾਂ ਦਾ ਪਤਾ ਚੱਲਦਾ ਹੈ ਸੂਚੀ ਵਿੱਚੋਂ ਮੁਅੱਤਲ/ਅਸਫ਼ਲ ਨੋਡਾਂ ਨੂੰ ਹਟਾਓ। ਜੇਕਰ ਅਸੀਂ ਇਹ ਜਲਦੀ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਜੇਕਰ ਗਾਹਕ ਕੁਨੈਕਸ਼ਨ ਦੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੇ ਯੋਗ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਅਸੀਂ ਨਿਰੰਤਰ ਉਪਲਬਧਤਾ ਪ੍ਰਾਪਤ ਕਰਾਂਗੇ।
• ਹਰੇਕ ਕਲਾਇੰਟ ਨੂੰ ਸਾਰੇ ਨੋਡਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਦਿਓ, ਅਤੇ ਕਲਾਇੰਟ ਕਨੈਕਟ ਕਰਨ ਵੇਲੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਬੇਤਰਤੀਬ ਢੰਗ ਨਾਲ ਚੁਣਦਾ ਹੈ। ਜੇਕਰ ਇਸ ਨੂੰ ਕਨੈਕਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਕੋਈ ਗਲਤੀ ਮਿਲਦੀ ਹੈ, ਤਾਂ ਇਹ ਸੂਚੀ ਵਿੱਚ ਅਗਲੇ ਨੋਡ 'ਤੇ ਚਲੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਇਹ ਕਨੈਕਟ ਨਹੀਂ ਹੋ ਜਾਂਦੀ।
• DNS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਅਸਫਲ/ਮੁਅੱਤਲ ਨੋਡ ਤੋਂ ਟ੍ਰੈਫਿਕ ਹਟਾਓ। ਇਹ ਇੱਕ ਛੋਟੇ ਟੀਟੀਐਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਿੱਟਾ

RabbitMQ ਕਲੱਸਟਰਿੰਗ ਦੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ। ਸਭ ਤੋਂ ਗੰਭੀਰ ਨੁਕਸਾਨ ਇਹ ਹਨ:

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

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

• ਭਰੋਸੇਯੋਗ ਨੈੱਟਵਰਕ.
• ਭਰੋਸੇਯੋਗ ਸਟੋਰੇਜ।
• ਬਹੁਤ ਲੰਬੀਆਂ ਕਤਾਰਾਂ।

ਜਦੋਂ ਇਹ ਉੱਚ ਉਪਲਬਧਤਾ ਸੈਟਿੰਗਾਂ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤੇ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ਜ autoheal)
• ਲਗਾਤਾਰ ਸੁਨੇਹੇ
• ਕੁਝ ਨੋਡ ਫੇਲ ਹੋਣ 'ਤੇ ਕਲਾਇੰਟਸ ਸਰਗਰਮ ਨੋਡ ਨਾਲ ਜੁੜਨਾ ਯਕੀਨੀ ਬਣਾਓ

ਇਕਸਾਰਤਾ (ਡੇਟਾ ਸੁਰੱਖਿਆ) ਲਈ, ਹੇਠ ਲਿਖੀਆਂ ਸੈਟਿੰਗਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰੋ:

• ਪ੍ਰਕਾਸ਼ਕ ਉਪਭੋਗਤਾ ਦੇ ਪੱਖ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਅਤੇ ਦਸਤੀ ਮਾਨਤਾਵਾਂ ਦਿੰਦਾ ਹੈ
• ha-promote-on-failure=when-synced, ਜੇਕਰ ਪ੍ਰਕਾਸ਼ਕ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦੇ ਹਨ ਅਤੇ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਭਰੋਸੇਯੋਗ ਸਟੋਰੇਜ ਹੈ! ਨਹੀਂ ਤਾਂ ਪਾਓ =always.
• ha-sync-mode=automatic (ਪਰ ਵੱਡੀਆਂ ਨਾ-ਸਰਗਰਮ ਕਤਾਰਾਂ ਲਈ ਮੈਨੂਅਲ ਮੋਡ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ; ਇਹ ਵੀ ਵਿਚਾਰ ਕਰੋ ਕਿ ਕੀ ਅਣਉਪਲਬਧਤਾ ਸੁਨੇਹਿਆਂ ਨੂੰ ਗੁਆਚ ਸਕਦੀ ਹੈ)
• ਘੱਟ ਗਿਣਤੀ ਮੋਡ ਨੂੰ ਰੋਕੋ
• ਲਗਾਤਾਰ ਸੁਨੇਹੇ

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

ਜੇਕਰ ਮੇਰੇ ਤੋਂ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਖੁੰਝ ਗਈ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਮੈਨੂੰ ਦੱਸੋ।

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

ਲੜੀ ਵਿੱਚ ਪਿਛਲੇ ਲੇਖ:
ਨੰਬਰ 1 - habr.com/ru/company/itsumma/blog/416629
ਨੰਬਰ 2 - habr.com/ru/company/itsumma/blog/418389
ਨੰਬਰ 3 - habr.com/ru/company/itsumma/blog/437446

ਸਰੋਤ: www.habr.com