ਸੁਨੇਹਾ ਦਲਾਲਾਂ ਨੂੰ ਸਮਝਣਾ। ActiveMQ ਅਤੇ Kafka ਨਾਲ ਮੈਸੇਜਿੰਗ ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਸਿੱਖਣਾ। ਅਧਿਆਇ 3. ਕਾਫਕਾ

ਇੱਕ ਛੋਟੀ ਕਿਤਾਬ ਦੇ ਅਨੁਵਾਦ ਦੀ ਨਿਰੰਤਰਤਾ:
ਸੁਨੇਹਾ ਦਲਾਲਾਂ ਨੂੰ ਸਮਝਣਾ
ਲੇਖਕ: ਜੈਕਬ ਕੋਰਬ, ਪ੍ਰਕਾਸ਼ਕ: ਓ'ਰੀਲੀ ਮੀਡੀਆ, ਇੰਕ., ਪ੍ਰਕਾਸ਼ਨ ਦੀ ਮਿਤੀ: ਜੂਨ 2017, ISBN: 9781492049296।

ਪਿਛਲਾ ਅਨੁਵਾਦ ਕੀਤਾ ਭਾਗ: ਸੁਨੇਹਾ ਦਲਾਲਾਂ ਨੂੰ ਸਮਝਣਾ। ActiveMQ ਅਤੇ Kafka ਨਾਲ ਮੈਸੇਜਿੰਗ ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਸਿੱਖਣਾ। ਅਧਿਆਇ 1 ਜਾਣ-ਪਛਾਣ

ਅਧਿਆਇ 3

ਕਾਫਕਾ

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

ਇਸ ਅੰਤਮ ਟੀਚੇ ਦੇ ਮੱਦੇਨਜ਼ਰ, ਹੋਰ ਲੋੜਾਂ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਪੈਦਾ ਹੋਈਆਂ। ਕਾਫਕਾ ਨੂੰ ਚਾਹੀਦਾ ਹੈ:

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

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

ਯੂਨੀਫਾਈਡ ਡੈਸਟੀਨੇਸ਼ਨ ਮਾਡਲ

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

ਇਸ ਅਧਿਆਇ ਦੇ ਬਾਕੀ ਬਚੇ ਹਿੱਸੇ ਲਈ, ਜਦੋਂ ਤੱਕ ਅਸੀਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਹੀਂ ਦੱਸਦੇ, "ਵਿਸ਼ਾ" ਸ਼ਬਦ ਕਾਫਕਾ ਵਿਸ਼ੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

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

ਸ਼ਬਦ "ਲੌਗ" ਅਤੇ "ਪੁਆਇੰਟਰ" ਵਿੱਚ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦੇ ਹਨ ਕਾਫਕਾ ਦਸਤਾਵੇਜ਼. ਇਹ ਜਾਣੇ-ਪਛਾਣੇ ਸ਼ਬਦ ਇੱਥੇ ਸਮਝਣ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਨ ਲਈ ਵਰਤੇ ਗਏ ਹਨ।

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

ਚਿੱਤਰ 3-1. ਕਾਫਕਾ ਭਾਗ

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

ਸੁਨੇਹੇ ਪੜ੍ਹ ਰਹੇ ਹਨ

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

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

ਪੜ੍ਹਨ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਰਸਾਇਆ ਜਾ ਸਕਦਾ ਹੈ:

• ਵਿਸ਼ੇ ਵਿੱਚ ਕਈ ਭਾਗ ਹਨ
• ਖਪਤਕਾਰਾਂ ਦੇ ਕਈ ਸਮੂਹ ਇੱਕੋ ਸਮੇਂ ਇੱਕ ਵਿਸ਼ੇ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ
• ਖਪਤਕਾਰਾਂ ਦੇ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਕਈ ਵੱਖਰੀਆਂ ਉਦਾਹਰਣਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ

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

ਖਪਤਕਾਰ ਅਤੇ ਖਪਤਕਾਰ ਸਮੂਹ

ਆਉ ਇੱਕ ਭਾਗ ਦੇ ਨਾਲ ਇੱਕ ਵਿਸ਼ੇ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਬਿੰਦੂ ਵਜੋਂ ਲੈਂਦੇ ਹਾਂ (ਚਿੱਤਰ 3-2).

ਚਿੱਤਰ 3-2. ਖਪਤਕਾਰ ਵੰਡ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ

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

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

ਚਿੱਤਰ 3-3. ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾ ਸਮੂਹਾਂ ਵਿੱਚ ਦੋ ਖਪਤਕਾਰ ਇੱਕੋ ਭਾਗ ਤੋਂ ਪੜ੍ਹਦੇ ਹਨ

ਇੱਕ ਖਪਤਕਾਰ ਸਮੂਹ ਵਿੱਚ ਖਪਤਕਾਰ

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

ਚਿੱਤਰ 3-4. ਇੱਕੋ ਖਪਤਕਾਰ ਸਮੂਹ ਵਿੱਚ ਦੋ ਖਪਤਕਾਰ ਇੱਕੋ ਭਾਗ ਤੋਂ ਪੜ੍ਹਦੇ ਹਨ

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

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

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

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

ਕਾਫਕਾ ਵਿੱਚ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦਾ ਪ੍ਰਮਾਣਿਕ ​​ਤਰੀਕਾ ਬੀОਹੋਰ ਭਾਗ.

ਵਿਭਾਗੀਕਰਨ

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

ਚਿੱਤਰ 3-5. ਇੱਕ ਖਪਤਕਾਰ ਕਈ ਭਾਗਾਂ ਤੋਂ ਪੜ੍ਹਦਾ ਹੈ

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

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

ਚਿੱਤਰ 3-6. ਇੱਕੋ ਖਪਤਕਾਰ ਸਮੂਹ ਵਿੱਚ ਦੋ ਖਪਤਕਾਰ ਵੱਖ-ਵੱਖ ਭਾਗਾਂ ਤੋਂ ਪੜ੍ਹਦੇ ਹਨ

ਇਹ ਸਕੀਮ JMS ਕਤਾਰ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਲੋੜੀਂਦੇ ਸੰਦੇਸ਼ ਵੰਡ ਦੇ ਮੁਕਾਬਲੇ ਕਾਫਕਾ ਬ੍ਰੋਕਰ ਦੀ ਗੁੰਝਲਤਾ ਨੂੰ ਬਹੁਤ ਘਟਾਉਂਦੀ ਹੈ। ਇੱਥੇ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੇ ਨੁਕਤਿਆਂ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ:

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

ਕਾਫਕਾ ਬ੍ਰੋਕਰ ਨੂੰ ਇਹ ਕਰਨਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਨੂੰ ਕ੍ਰਮਵਾਰ ਸੁਨੇਹੇ ਭੇਜੇ ਜਾਣ ਜਦੋਂ ਬਾਅਦ ਵਾਲੇ ਉਨ੍ਹਾਂ ਨੂੰ ਬੇਨਤੀ ਕਰਦੇ ਹਨ।

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

ਸੁਨੇਹੇ ਭੇਜ ਰਿਹਾ ਹੈ

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

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

ਅਧਿਆਇ 2 ਵਿੱਚ, ਅਸੀਂ ਔਨਲਾਈਨ ਸੱਟੇਬਾਜ਼ੀ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਚਰਚਾ ਕੀਤੀ ਹੈ ਜਿੱਥੇ ਸੰਬੰਧਿਤ ਘਟਨਾਵਾਂ ਨੂੰ ਇੱਕ ਇੱਕਲੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਕ੍ਰਮ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

1. ਉਪਭੋਗਤਾ ਖਾਤਾ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ।
2. ਖਾਤੇ ਵਿੱਚ ਪੈਸੇ ਜਮ੍ਹਾਂ ਹੋ ਜਾਂਦੇ ਹਨ।
3. ਇੱਕ ਬਾਜ਼ੀ ਲਗਾਈ ਜਾਂਦੀ ਹੈ ਜੋ ਖਾਤੇ ਵਿੱਚੋਂ ਪੈਸੇ ਕਢਵਾ ਲੈਂਦਾ ਹੈ।

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

ਇਹ ਇੰਟਰਫੇਸ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

ਆਪਣੀ ਖੁਦ ਦੀ ਵਿਭਾਗੀਕਰਨ ਰਣਨੀਤੀ ਲਿਖਣਾ

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

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

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

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

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

ਨਿਰਮਾਤਾ ਸਮਝੌਤੇ

ਸੁਨੇਹੇ ਭੇਜਣ ਵੇਲੇ ਸਿਰਫ਼ ਵਿਭਾਗੀਕਰਨ ਹੀ ਵਿਚਾਰਨ ਵਾਲੀ ਗੱਲ ਨਹੀਂ ਹੈ। ਆਉ Java API ਵਿੱਚ ਪ੍ਰੋਡਿਊਸਰ ਕਲਾਸ ਦੇ send() ਤਰੀਕਿਆਂ ਉੱਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

ਸੁਨੇਹੇ ਪੜ੍ਹਨ ਬਾਰੇ ਹੋਰ

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

ConsumerRecords < K, V > poll(long timeout);

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

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

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

ਪਹਿਲਾਂ ਵਿਚਾਰੇ ਗਏ ਰੀਡਿੰਗ ਮਾਡਲ 'ਤੇ ਵਾਪਸ ਆਉਣਾ, ਸੁਨੇਹਾ ਪ੍ਰੋਸੈਸਿੰਗ ਵਿੱਚ ਤਿੰਨ ਪੜਾਅ ਹੁੰਦੇ ਹਨ:

1. ਪੜ੍ਹਨ ਲਈ ਇੱਕ ਸੁਨੇਹਾ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰੋ।
2. ਸੰਦੇਸ਼ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰੋ।
3. ਸੁਨੇਹੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

ਕਾਫਕਾ ਉਪਭੋਗਤਾ ਇੱਕ ਸੰਰਚਨਾ ਵਿਕਲਪ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ enable.auto.commit. ਇਹ ਇੱਕ ਅਕਸਰ ਵਰਤੀ ਜਾਂਦੀ ਡਿਫੌਲਟ ਸੈਟਿੰਗ ਹੈ, ਜਿਵੇਂ ਕਿ "ਆਟੋ" ਸ਼ਬਦ ਵਾਲੀਆਂ ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਆਮ ਹੈ।

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

ਕਾਫਕਾ 0.10 ਵਿੱਚ, ਕਲਾਇੰਟ ਕੋਡ ਨੂੰ ਬਦਲਿਆ ਗਿਆ ਹੈ ਤਾਂ ਕਿ ਕਮਿਟ ਨੂੰ ਕਲਾਇੰਟ ਲਾਇਬ੍ਰੇਰੀ ਦੁਆਰਾ ਸਮੇਂ-ਸਮੇਂ ਤੇ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ auto.commit.interval.ms. ਇਹ ਵਿਵਹਾਰ JMS AUTO_ACKNOWLEDGE ਅਤੇ DUPS_OK_ACKNOWLEDGE ਮੋਡਾਂ ਦੇ ਵਿਚਕਾਰ ਕਿਤੇ ਹੈ। ਆਟੋਕਮਿਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਸੁਨੇਹਿਆਂ ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਕੀਤੇ ਬਿਨਾਂ ਵਚਨਬੱਧ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਉਹਨਾਂ ਦੀ ਅਸਲ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਗਈ ਸੀ - ਇਹ ਇੱਕ ਹੌਲੀ ਖਪਤਕਾਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਖਪਤਕਾਰ ਅਧੂਰਾ ਛੱਡਦਾ ਹੈ, ਤਾਂ ਅਗਲੇ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾਣਗੇ, ਪ੍ਰਤੀਬੱਧ ਸਥਿਤੀ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹੋਏ, ਜਿਸਦੇ ਨਤੀਜੇ ਵਜੋਂ ਇੱਕ ਖੁੰਝਿਆ ਸੁਨੇਹਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਕਾਫਕਾ ਨੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਨਹੀਂ ਗੁਆਇਆ, ਰੀਡਿੰਗ ਕੋਡ ਨੇ ਉਹਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਕੀਤੀ।

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

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

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

ਤੁਸੀਂ ਪੈਰਾਮੀਟਰ ਸੈਟ ਕਰਕੇ ਕਾਫਕਾ ਉਪਭੋਗਤਾ API ਵਿੱਚ ਮੈਨੂਅਲ ਆਫਸੈੱਟ ਕਮਿਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰ ਸਕਦੇ ਹੋ enable.auto.commit ਹੇਠਾਂ ਦਿੱਤੇ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਗਲਤ ਅਤੇ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਕਾਲ ਕਰਨ ਲਈ:

void commitSync();
void commitAsync();

ਜੇਕਰ ਤੁਸੀਂ "ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ" ਸੁਨੇਹੇ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਔਫਸੈੱਟ ਨੂੰ ਦਸਤੀ ਨਾਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਕਮਿਟ ਸਿੰਕ()ਸੁਨੇਹਿਆਂ ਦੀ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਤੁਰੰਤ ਬਾਅਦ ਇਸ ਕਮਾਂਡ ਨੂੰ ਲਾਗੂ ਕਰਕੇ।

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

• ਇੱਕ ਜਾਅਲੀ ਸੁਨੇਹੇ ਨੂੰ ਆਟੋਮੈਟਿਕਲੀ ਰੋਲ ਬੈਕ ਕਰੋ। ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਖੁਦ ਸਮੱਸਿਆ ਵਾਲੇ ਪੇਲੋਡਾਂ ਅਤੇ ਬੈਕਐਂਡ ਆਊਟੇਜ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਅਪਵਾਦਾਂ ਨੂੰ ਸੰਭਾਲਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਸੁਨੇਹਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਡਿਲੀਵਰ ਕਰਨ ਲਈ ਬ੍ਰੋਕਰ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ।
• ਇੱਕ ਪਰਮਾਣੂ ਕਾਰਵਾਈ ਵਿੱਚ ਕਈ ਵਿਸ਼ਿਆਂ ਨੂੰ ਸੁਨੇਹੇ ਭੇਜੋ। ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਜਲਦੀ ਹੀ ਦੇਖਾਂਗੇ, ਵੱਖ-ਵੱਖ ਵਿਸ਼ਿਆਂ 'ਤੇ ਨਿਯੰਤਰਣ ਅਤੇ ਭਾਗ ਕਾਫਕਾ ਕਲੱਸਟਰ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰਹਿ ਸਕਦੇ ਹਨ ਜੋ ਭੇਜੇ ਜਾਣ 'ਤੇ ਲੈਣ-ਦੇਣ ਦਾ ਤਾਲਮੇਲ ਨਹੀਂ ਕਰਦੀਆਂ। ਇਸ ਲਿਖਤ ਦੇ ਸਮੇਂ, KIP-98 ਨਾਲ ਇਸ ਨੂੰ ਸੰਭਵ ਬਣਾਉਣ ਲਈ ਕੁਝ ਕੰਮ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਇੱਕ ਵਿਸ਼ੇ ਤੋਂ ਇੱਕ ਸੁਨੇਹਾ ਪੜ੍ਹਨ ਨੂੰ ਦੂਜੇ ਵਿਸ਼ੇ 'ਤੇ ਦੂਜਾ ਸੁਨੇਹਾ ਭੇਜਣ ਨਾਲ ਜੋੜੋ। ਦੁਬਾਰਾ ਫਿਰ, ਕਾਫਕਾ ਦਾ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਬੱਸ ਦੇ ਰੂਪ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਸੁਤੰਤਰ ਮਸ਼ੀਨਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਛੁਪਾਉਣ ਦੀ ਕੋਈ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਕੋਈ API ਭਾਗ ਨਹੀਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਲਿੰਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ ਖਪਤਕਾਰ и ਨਿਰਮਾਤਾ ਇੱਕ ਲੈਣ-ਦੇਣ ਵਿੱਚ. JMS ਵਿੱਚ, ਇਹ ਵਸਤੂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਸੈਸ਼ਨਜਿਸ ਤੋਂ ਬਣਾਏ ਗਏ ਹਨ ਸੁਨੇਹਾ ਨਿਰਮਾਤਾ и Message Consumers.

ਜੇਕਰ ਅਸੀਂ ਲੈਣ-ਦੇਣ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਰਵਾਇਤੀ ਮੈਸੇਜਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਸ਼ਬਦਾਂ ਦੇ ਨੇੜੇ ਅਰਥ ਵਿਗਿਆਨ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਾਂ?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

.ੰਗ ਭਾਲ () ਵਿਧੀ ਨਾਲ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ
offsetsForTimes(ਮੈਪ ਟਾਈਮਸਟੈਂਪਸਖੋਜ) ਅਤੀਤ ਵਿੱਚ ਕਿਸੇ ਖਾਸ ਬਿੰਦੂ 'ਤੇ ਇੱਕ ਰਾਜ ਵੱਲ ਮੁੜਨ ਲਈ.

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

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

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

ਉੱਚ ਉਪਲਬਧਤਾ

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

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

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

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

ਬੇਸ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਵਿਸ਼ਾ ਇੱਕ ਕਾਫਕਾ ਕਲੱਸਟਰ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਹੈ:

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

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

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

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

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

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

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

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

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

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

ਨਤੀਜੇ

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

ਪਿਛਲਾ ਅਨੁਵਾਦ ਕੀਤਾ ਭਾਗ: ਸੁਨੇਹਾ ਦਲਾਲਾਂ ਨੂੰ ਸਮਝਣਾ। ActiveMQ ਅਤੇ Kafka ਨਾਲ ਮੈਸੇਜਿੰਗ ਦੇ ਮਕੈਨਿਕਸ ਨੂੰ ਸਿੱਖਣਾ। ਅਧਿਆਇ 1

ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ: tele.gg/middle_java

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ…

ਸਿਰਫ਼ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹੀ ਸਰਵੇਖਣ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਸਕਦੇ ਹਨ। ਸਾਈਨ - ਇਨ, ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ.

ਕੀ ਤੁਹਾਡੀ ਸੰਸਥਾ ਵਿੱਚ ਕਾਫਕਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ?

• ਜੀ

• ਕੋਈ

• ਪਹਿਲਾਂ ਵਰਤੀ ਜਾਂਦੀ ਸੀ, ਹੁਣ ਨਹੀਂ

• ਅਸੀਂ ਵਰਤਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ

38 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਕੀਤਾ। 8 ਉਪਭੋਗਤਾ ਬਚੇ ਹੋਏ ਹਨ।

ਸਰੋਤ: www.habr.com