ਕਾਫਕਾ ਹਕੀਕਤ ਕਿਵੇਂ ਬਣਿਆ

ਹੇ ਹਬਰ!

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

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

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

ਗਾਰੰਟੀਸ਼ੁਦਾ ਡਿਲੀਵਰੀ ਅਤੇ ਹੋਰ

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

ਇਹ ਮਦਦ ਕਰੇਗਾ client.id ਉਤਪਾਦਕ ਅਤੇ ਖਪਤਕਾਰ ਲਈ. ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਨਾਮ ਨੂੰ ਮੁੱਲ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤ ਸਕਦੇ ਹੋ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਕੰਮ ਕਰੇਗਾ। ਹਾਲਾਂਕਿ ਸਥਿਤੀ ਜਦੋਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਕਈ ਖਪਤਕਾਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਉਹੀ client.id ਦਿੰਦੇ ਹੋ, ਨਤੀਜੇ ਵਜੋਂ ਹੇਠਾਂ ਦਿੱਤੀ ਚੇਤਾਵਨੀ ਹੁੰਦੀ ਹੈ:

org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0

ਜੇਕਰ ਤੁਸੀਂ ਕਾਫਕਾ ਦੇ ਨਾਲ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ JMX ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਹ ਇੱਕ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ। ਇਸ ਕੇਸ ਲਈ, ਐਪਲੀਕੇਸ਼ਨ ਨਾਮ ਦੇ ਸੁਮੇਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਅਤੇ, ਉਦਾਹਰਨ ਲਈ, client.id ਮੁੱਲ ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਸ਼ੇ ਦਾ ਨਾਮ। ਸਾਡੀ ਸੰਰਚਨਾ ਦਾ ਨਤੀਜਾ ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਾਫਕਾ-ਖਪਤਕਾਰ-ਸਮੂਹ Confluent ਤੋਂ ਉਪਯੋਗਤਾਵਾਂ ਤੋਂ:

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

• 0 - ਮਾਨਤਾ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।
• 1 ਡਿਫੌਲਟ ਪੈਰਾਮੀਟਰ ਹੈ, ਸਿਰਫ 1 ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• −1 — ਸਾਰੀਆਂ ਸਮਕਾਲੀ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਤੋਂ ਸਵੀਕਾਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ (ਕਲੱਸਟਰ ਸੈੱਟਅੱਪ min.insync.replicas).

ਸੂਚੀਬੱਧ ਮੁੱਲਾਂ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ −1 ਦੇ ਬਰਾਬਰ acks ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ​​ਗਾਰੰਟੀ ਦਿੰਦਾ ਹੈ ਕਿ ਸੁਨੇਹਾ ਗੁੰਮ ਨਹੀਂ ਹੋਵੇਗਾ।

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

ਅਸੀਂ ਬਿਲਕੁਲ ਇੱਕ ਵਾਰ ਡਿਲੀਵਰੀ ਵੱਲ ਵਧ ਰਹੇ ਹਾਂ

ਸੂਚੀਬੱਧ ਸੈਟਿੰਗਾਂ ਸਾਡੇ ਨਿਰਮਾਤਾ ਨੂੰ ਉੱਚ ਗਾਰੰਟੀ ਦੇ ਨਾਲ ਸੁਨੇਹੇ ਡਿਲੀਵਰ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਆਓ ਹੁਣ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾਵੇ ਕਿ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਕੇਵਲ ਇੱਕ ਕਾਪੀ ਕਾਫਕਾ ਵਿਸ਼ੇ 'ਤੇ ਲਿਖੀ ਗਈ ਹੈ? ਸਧਾਰਨ ਮਾਮਲੇ ਵਿੱਚ, ਅਜਿਹਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਪ੍ਰੋਡਿਊਸਰ 'ਤੇ ਪੈਰਾਮੀਟਰ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ enable.idempotence ਸੱਚ ਨੂੰ. ਇਡਮਪੋਟੈਂਸੀ ਗਾਰੰਟੀ ਦਿੰਦੀ ਹੈ ਕਿ ਇੱਕ ਵਿਸ਼ੇ ਦੇ ਇੱਕ ਖਾਸ ਭਾਗ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਸੁਨੇਹਾ ਲਿਖਿਆ ਗਿਆ ਹੈ। ਆਦਰਸ਼ਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਲਈ ਪੂਰਵ ਸ਼ਰਤ ਮੁੱਲ ਹਨ acks = ਸਭ, ਮੁੜ ਕੋਸ਼ਿਸ਼ > 0, max.in.flight.requests.per.connection ≤ 5. ਜੇਕਰ ਇਹ ਪੈਰਾਮੀਟਰ ਡਿਵੈਲਪਰ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ, ਤਾਂ ਉਪਰੋਕਤ ਮੁੱਲ ਆਪਣੇ ਆਪ ਸੈੱਟ ਹੋ ਜਾਣਗੇ।

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

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

ਨਾਲ ਹੀ, ਇੱਕ ਪੈਰਾਮੀਟਰ ਦੇ ਨਾਲ ਇੱਕ ਕੁੰਜੀ ਅਤੇ idempotent ਭੇਜਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ max.in.flight.requests.per.connection = 1 ਤੁਹਾਨੂੰ ਉਪਭੋਗਤਾ 'ਤੇ ਸੁਚਾਰੂ ਸੁਨੇਹੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਯਾਦ ਰੱਖਣ ਯੋਗ ਵੀ ਹੈ ਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕਲੱਸਟਰ 'ਤੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਨੂੰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵਿਸ਼ੇ 'ਤੇ ਵਿਚਾਰਸ਼ੀਲਤਾ ਨਾਲ ਲਿਖਣ ਲਈ ਅਧਿਕਾਰਾਂ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ।

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

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

org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.

ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਅਸੀਂ ਹੋਸਟਨਾਮ ਦੇ ਰੂਪ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਨਾਮ ਵਿੱਚ ਇੱਕ ਪਿਛੇਤਰ ਜੋੜਦੇ ਹਾਂ, ਜੋ ਅਸੀਂ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

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

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

ਪਰ ਇੱਕ ਹੋਰ ਸੂਖਮਤਾ ਹੈ. Transactional.id, ਜਿਸਨੂੰ ਅਸੀਂ ਉੱਪਰ ਕੌਂਫਿਗਰ ਕੀਤਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪ੍ਰੀਫਿਕਸ ਹੈ। ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਮੈਨੇਜਰ 'ਤੇ, ਇਸ ਵਿੱਚ ਇੱਕ ਕ੍ਰਮ ਨੰਬਰ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ। ਪ੍ਰਾਪਤ ਪਛਾਣਕਰਤਾ ਨੂੰ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ transactional.id.expiration.ms, ਜੋ ਕਾਫਕਾ ਕਲੱਸਟਰ 'ਤੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ "7 ਦਿਨ" ਦਾ ਡਿਫੌਲਟ ਮੁੱਲ ਹੈ। ਜੇਕਰ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੋਈ ਸੰਦੇਸ਼ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਇਆ ਹੈ, ਤਾਂ ਜਦੋਂ ਤੁਸੀਂ ਅਗਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਭੇਜਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਤਾਂ ਤੁਹਾਨੂੰ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ InvalidPidMappingException. ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਕੋਆਰਡੀਨੇਟਰ ਫਿਰ ਅਗਲੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਲਈ ਇੱਕ ਨਵਾਂ ਕ੍ਰਮ ਨੰਬਰ ਜਾਰੀ ਕਰੇਗਾ। ਹਾਲਾਂਕਿ, ਜੇਕਰ InvalidPidMappingException ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਨਹੀਂ ਸੰਭਾਲਿਆ ਗਿਆ ਤਾਂ ਸੁਨੇਹਾ ਗੁੰਮ ਹੋ ਸਕਦਾ ਹੈ।

ਕੁਲ ਦੀ ਬਜਾਏ

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

ਨਿਰਮਾਤਾ:

1. acks = ਸਾਰੇ
2. ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ > 0
3. enable.idempotence = ਸੱਚ
4. max.in.flight.requests.per.connection ≤ 5 (ਕ੍ਰਮਬੱਧ ਭੇਜਣ ਲਈ 1)
5. transactional.id = ${application-name}-${hostname}

ਖਪਤਕਾਰ:

1. isolation.level = read_committed

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

ਇੱਥੇ ਸਵੈ-ਅਧਿਐਨ ਲਈ ਕੁਝ ਸਮੱਗਰੀਆਂ ਹਨ:

• KIP-98 - ਇੱਕ ਵਾਰ ਡਿਲਿਵਰੀ ਅਤੇ ਟ੍ਰਾਂਜੈਕਸ਼ਨਲ ਮੈਸੇਜਿੰਗ
• ਸੈਟਿੰਗਾਂ ਦਾ ਵੇਰਵਾ

ਸਰੋਤ: www.habr.com