ਕਾਫਕਾ ਤੋਂ ਪ੍ਰਾਪਤ ਇਵੈਂਟਾਂ ਨੂੰ ਰੀਪ੍ਰੋਸੈਸ ਕਰਨਾ

ਹੇ ਹਬਰ.

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

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

ਕਾਫਕਾ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕਿਵੇਂ ਸੀ

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

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

ਇੱਕ ਹੱਲ ਲੱਭਣਾ

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

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

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

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

spring-kafka ਖੁਦ ContainerAwareErrorHandler ਦੇ ਕਈ ਸਥਾਪਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ SeekToCurrentErrorHandler, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਕਿਸੇ ਗਲਤੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਆਫਸੈੱਟ ਨੂੰ ਸ਼ਿਫਟ ਕੀਤੇ ਬਿਨਾਂ ਬਾਅਦ ਵਿੱਚ ਸੰਦੇਸ਼ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੇ ਹੋ। ਸਪਰਿੰਗ-ਕਾਫਕਾ 2.3 ਦੇ ਸੰਸਕਰਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋਏ, ਬੈਕਆਫ ਪਾਲਿਸੀ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਸੰਭਵ ਹੋ ਗਿਆ।

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

ਅੰਤਿਮ ਫੈਸਲਾ

SeekToCurrentErrorHandler 'ਤੇ ਆਧਾਰਿਤ ਲਾਗੂਕਰਨ ਨੇ ਸਾਨੂੰ ਸੁਨੇਹੇ ਮੁੜ ਭੇਜਣ ਲਈ ਆਪਣੀ ਖੁਦ ਦੀ ਵਿਧੀ ਵਿਕਸਿਤ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਆ।

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

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

ਇੱਕ ਰੇਖਿਕ ਤਰਕ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਖਪਤਕਾਰ ਨੂੰ ਰੋਕਣਾ

ਸਪਰਿੰਗ-ਕਾਫਕਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਉਪਭੋਗਤਾ ਨੂੰ ਰੋਕਣ ਲਈ ਕੋਡ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ:

public void pauseListenerContainer(MessageListenerContainer listenerContainer, 
                                   Instant retryAt) {
        if (nonNull(retryAt) && listenerContainer.isRunning()) {
            listenerContainer.stop();
            taskScheduler.schedule(() -> listenerContainer.start(), retryAt);
            return;
        }
        // to DLQ
    }

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

ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਤਰੀਕੇ ਨਾਲ ਰੀਟ੍ਰੈਟ ਵੈਲਯੂ ਲੱਭਦੇ ਹਾਂ:

1. ਰੀ-ਕਾਲ ਕਾਊਂਟਰ ਦਾ ਮੁੱਲ ਦੇਖਿਆ ਜਾਂਦਾ ਹੈ।
2. ਵਿਰੋਧੀ ਮੁੱਲ ਦੇ ਆਧਾਰ 'ਤੇ, ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਰਣਨੀਤੀ ਵਿੱਚ ਮੌਜੂਦਾ ਦੇਰੀ ਅੰਤਰਾਲ ਦੀ ਖੋਜ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਰਣਨੀਤੀ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਹੀ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ; ਅਸੀਂ ਇਸਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ JSON ਫਾਰਮੈਟ ਚੁਣਿਆ ਹੈ।
3. JSON ਐਰੇ ਵਿੱਚ ਮਿਲੇ ਅੰਤਰਾਲ ਵਿੱਚ ਸਕਿੰਟਾਂ ਦੀ ਗਿਣਤੀ ਹੁੰਦੀ ਹੈ ਜਿਸ ਤੋਂ ਬਾਅਦ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਸਕਿੰਟਾਂ ਦੀ ਇਹ ਸੰਖਿਆ ਮੌਜੂਦਾ ਸਮੇਂ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ ਮੁੱਲ ਬਣਾਉਣ ਲਈ ਜੋੜੀ ਜਾਂਦੀ ਹੈ।
4. ਜੇਕਰ ਅੰਤਰਾਲ ਨਹੀਂ ਮਿਲਦਾ ਹੈ, ਤਾਂ retryAt ਦਾ ਮੁੱਲ ਖਾਲੀ ਹੈ ਅਤੇ ਮੈਨੁਅਲ ਪਾਰਸਿੰਗ ਲਈ ਸੁਨੇਹਾ DLQ ਨੂੰ ਭੇਜਿਆ ਜਾਵੇਗਾ।

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

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

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

ਗੈਰ-ਨਿਰਧਾਰਤ ਤਰਕ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ ਸੁਨੇਹਿਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਐਪਲੀਕੇਸ਼ਨ

ਇੱਥੇ ਕੋਡ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਅਜਿਹੀ ਐਪਲੀਕੇਸ਼ਨ (ਰੀਟਾਇਅਰ) ਨੂੰ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਦਾ ਹੈ, ਜੋ RETRY_AT ਸਮਾਂ ਪੂਰਾ ਹੋਣ 'ਤੇ DESTINATION ਵਿਸ਼ੇ 'ਤੇ ਮੁੜ ਭੇਜਿਆ ਜਾਵੇਗਾ:

public <K, V> void retry(ConsumerRecord<K, V> record, String retryToTopic, 
                         Instant retryAt, String counter, String groupId, Exception e) {
        Headers headers = ofNullable(record.headers()).orElse(new RecordHeaders());
        List<Header> arrayOfHeaders = 
            new ArrayList<>(Arrays.asList(headers.toArray()));
        updateHeader(arrayOfHeaders, GROUP_ID, groupId::getBytes);
        updateHeader(arrayOfHeaders, DESTINATION, retryToTopic::getBytes);
        updateHeader(arrayOfHeaders, ORIGINAL_PARTITION, 
                     () -> Integer.toString(record.partition()).getBytes());
        if (nonNull(retryAt)) {
            updateHeader(arrayOfHeaders, COUNTER, counter::getBytes);
            updateHeader(arrayOfHeaders, SEND_TO, "retry"::getBytes);
            updateHeader(arrayOfHeaders, RETRY_AT, retryAt.toString()::getBytes);
        } else {
            updateHeader(arrayOfHeaders, REASON, 
                         ExceptionUtils.getStackTrace(e)::getBytes);
            updateHeader(arrayOfHeaders, SEND_TO, "backout"::getBytes);
        }
        ProducerRecord<K, V> messageToSend =
            new ProducerRecord<>(retryTopic, null, null, record.key(), record.value(), arrayOfHeaders);
        kafkaTemplate.send(messageToSend);
    }

ਉਦਾਹਰਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਿਰਲੇਖਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀ ਜਾਣਕਾਰੀ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. RETRY_AT ਦਾ ਮੁੱਲ ਉਸੇ ਤਰ੍ਹਾਂ ਪਾਇਆ ਜਾਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਉਪਭੋਗਤਾ ਸਟਾਪ ਦੁਆਰਾ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਵਿਧੀ ਲਈ। DESTINATION ਅਤੇ RETRY_AT ਤੋਂ ਇਲਾਵਾ ਅਸੀਂ ਪਾਸ ਕਰਦੇ ਹਾਂ:

• GROUP_ID, ਜਿਸ ਦੁਆਰਾ ਅਸੀਂ ਮੈਨੁਅਲ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਸਰਲ ਖੋਜ ਲਈ ਸੁਨੇਹਿਆਂ ਨੂੰ ਸਮੂਹ ਕਰਦੇ ਹਾਂ।
• ORIGINAL_PARTITION ਮੁੜ-ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਉਹੀ ਖਪਤਕਾਰ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ। ਇਹ ਪੈਰਾਮੀਟਰ ਨਲ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸ ਸਥਿਤੀ ਵਿੱਚ ਨਵਾਂ ਭਾਗ ਅਸਲੀ ਸੁਨੇਹੇ ਦੀ record.key() ਕੁੰਜੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾਵੇਗਾ।
• ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਰਣਨੀਤੀ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ COUNTER ਮੁੱਲ ਨੂੰ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ।
• SEND_TO ਇੱਕ ਨਿਰੰਤਰ ਸੰਕੇਤ ਹੈ ਕਿ ਕੀ ਸੁਨੇਹਾ RETRY_AT 'ਤੇ ਪਹੁੰਚਣ 'ਤੇ ਮੁੜ ਪ੍ਰਕਿਰਿਆ ਲਈ ਭੇਜਿਆ ਗਿਆ ਹੈ ਜਾਂ DLQ ਵਿੱਚ ਰੱਖਿਆ ਗਿਆ ਹੈ।
• ਕਾਰਨ - ਸੁਨੇਹੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਰੁਕਾਵਟ ਦਾ ਕਾਰਨ।

Retryer PostgreSQL ਵਿੱਚ ਮੁੜ ਭੇਜਣ ਅਤੇ ਮੈਨੂਅਲ ਪਾਰਸਿੰਗ ਲਈ ਸੁਨੇਹੇ ਸਟੋਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਟਾਈਮਰ ਇੱਕ ਕੰਮ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਜੋ RETRY_AT ਨਾਲ ਸੁਨੇਹੇ ਲੱਭਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੁੰਜੀ record.key() ਨਾਲ DESTINATION ਵਿਸ਼ੇ ਦੇ ORIGINAL_PARTITION ਭਾਗ ਵਿੱਚ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।

ਇੱਕ ਵਾਰ ਭੇਜੇ ਜਾਣ ਤੇ, ਸੁਨੇਹੇ PostgreSQL ਤੋਂ ਮਿਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਸੁਨੇਹਿਆਂ ਦਾ ਮੈਨੁਅਲ ਪਾਰਸਿੰਗ ਇੱਕ ਸਧਾਰਨ UI ਵਿੱਚ ਹੁੰਦਾ ਹੈ ਜੋ REST API ਦੁਆਰਾ ਰੀਟਾਇਅਰ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦਾ ਹੈ। ਇਸ ਦੀਆਂ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ DLQ ਤੋਂ ਸੁਨੇਹਿਆਂ ਨੂੰ ਮੁੜ ਭੇਜਣਾ ਜਾਂ ਮਿਟਾਉਣਾ, ਗਲਤੀ ਦੀ ਜਾਣਕਾਰੀ ਦੇਖਣਾ ਅਤੇ ਸੁਨੇਹਿਆਂ ਦੀ ਖੋਜ ਕਰਨਾ, ਉਦਾਹਰਨ ਲਈ ਗਲਤੀ ਨਾਮ ਦੁਆਰਾ।

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

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

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

ਸਿੱਟਾ

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

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

ਸਰੋਤ: www.habr.com