ਕਾਫਕਾ 'ਤੇ ਅਸਿੰਕਰੋਨਸ API ਦੇ ਨਾਲ ਰਿਫੰਡ ਟੂਲ ਸੇਵਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦਾ ਅਨੁਭਵ

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

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

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

ਪ੍ਰਕਿਰਿਆ ਬਾਰੇ

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

ਇਵੈਂਟ-ਸੰਚਾਲਿਤ API ਦੇ ਨਾਲ ਰਿਫੰਡ ਟੂਲ

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

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

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

ਸਾਡੀ ਪ੍ਰੇਰਣਾ:

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

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

BOB ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਐਕਸਚੇਂਜ ਵੀ ਹਨ: ਭੁਗਤਾਨ ਪ੍ਰਣਾਲੀਆਂ, ਡਿਲੀਵਰੀ ਸਿਸਟਮ, ਸੂਚਨਾ ਪ੍ਰਣਾਲੀਆਂ, ਆਦਿ।

ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ BOB ਹੈ:

• ਕੋਡ ਦੀਆਂ ~150k ਲਾਈਨਾਂ + ਟੈਸਟਾਂ ਦੀਆਂ ~100k ਲਾਈਨਾਂ;
• php7.2 + ਜ਼ੈਂਡ 1 ਅਤੇ ਸਿਮਫਨੀ ਕੰਪੋਨੈਂਟਸ 3;
• >100 API ਅਤੇ ~50 ਆਊਟਬਾਉਂਡ ਏਕੀਕਰਣ;
• 4 ਦੇਸ਼ ਆਪਣੇ ਕਾਰੋਬਾਰੀ ਤਰਕ ਨਾਲ।

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

ਵਾਪਸੀ ਦੀ ਪ੍ਰਕਿਰਿਆ

ਸ਼ੁਰੂ ਵਿੱਚ, ਦੋ ਪ੍ਰਣਾਲੀਆਂ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ: BOB ਅਤੇ ਭੁਗਤਾਨ। ਹੁਣ ਦੋ ਹੋਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

• ਵਿੱਤੀਕਰਨ ਸੇਵਾ, ਜੋ ਵਿੱਤੀਕਰਨ ਅਤੇ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਨਾਲ ਸੰਚਾਰ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਧਿਆਨ ਰੱਖੇਗੀ।
• ਰਿਫੰਡ ਟੂਲ, ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਨਵੇਂ ਐਕਸਚੇਂਜ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ ਤਾਂ ਜੋ BOB ਨੂੰ ਵਧਾਇਆ ਨਾ ਜਾਵੇ।

ਹੁਣ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

1. BOB ਨੂੰ ਰਿਫੰਡ ਲਈ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ।
2. BOB ਇਸ ਰਿਫੰਡ ਟੂਲ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ।
3. ਰਿਫੰਡ ਟੂਲ ਭੁਗਤਾਨ ਨੂੰ ਦੱਸਦਾ ਹੈ: "ਪੈਸੇ ਵਾਪਸ ਕਰੋ।"
4. ਭੁਗਤਾਨ ਪੈਸੇ ਵਾਪਸ ਕਰਦਾ ਹੈ।
5. ਰਿਫੰਡ ਟੂਲ ਅਤੇ BOB ਸਥਿਤੀਆਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਦੇ ਹਨ, ਕਿਉਂਕਿ ਫਿਲਹਾਲ ਦੋਵਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਅਜੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰਿਫੰਡ ਟੂਲ 'ਤੇ ਜਾਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹਾਂ, ਕਿਉਂਕਿ BOB ਕੋਲ ਇੱਕ UI ਹੈ, ਲੇਖਾ ਲਈ ਰਿਪੋਰਟਾਂ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਹੈ ਜੋ ਇੰਨੀ ਆਸਾਨੀ ਨਾਲ ਟ੍ਰਾਂਸਫਰ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਦੋ ਕੁਰਸੀਆਂ 'ਤੇ ਬੈਠਣਾ ਪਵੇਗਾ।
6. ਵਿੱਤੀਕਰਨ ਦੀ ਬੇਨਤੀ ਦੂਰ ਹੋ ਜਾਂਦੀ ਹੈ।

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

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

ਇੱਕ ਇਵੈਂਟ-ਸੰਚਾਲਿਤ API ਕੀ ਹੈ

ਇਸ ਸਵਾਲ ਦਾ ਵਧੀਆ ਜਵਾਬ ਮਾਰਟਿਨ ਫੋਲਰ (ਗੋਟੋ 2017) ਦੀ ਰਿਪੋਰਟ ਵਿੱਚ ਹੈ। "ਘਟਨਾ-ਸੰਚਾਲਿਤ ਆਰਕੀਟੈਕਚਰ ਦੇ ਬਹੁਤ ਸਾਰੇ ਅਰਥ".

ਸੰਖੇਪ ਵਿੱਚ ਅਸੀਂ ਕੀ ਕੀਤਾ:

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

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

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

Async ਐਕਸਚੇਂਜ AS IS

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

ਕੁਝ ਥਾਵਾਂ 'ਤੇ ESB ਬੱਸਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਕੁਝ ਐਕਟਿਵ ਐਮਕਿਊ 'ਤੇ ਰਹਿੰਦੀਆਂ ਹਨ, ਪਰ, ਆਮ ਤੌਰ 'ਤੇ, RabbitMQ - ਮਿਆਰੀ.

Async ਐਕਸਚੇਂਜ TO BE

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

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

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

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

ਸਮਾਗਮ-ਬੱਸ

ਜਾਂ ਇੱਕ ਇਵੈਂਟ ਬੱਸ। ਇਹ ਸਿਰਫ਼ ਇੱਕ ਸਟੇਟਲੈੱਸ http ਗੇਟਵੇ ਹੈ, ਜੋ ਕਈ ਮਹੱਤਵਪੂਰਨ ਭੂਮਿਕਾਵਾਂ ਨਿਭਾਉਂਦਾ ਹੈ:

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

ਇਸੇ

ਅਸੀਂ ਇੱਕ ਸੁਚਾਰੂ ਪ੍ਰਕਿਰਿਆ ਦੇ ਨਾਲ ਇੱਕ ਵੱਡੀ ਕੰਪਨੀ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਾਂ। ਕੁਝ ਵੀ ਕਿਉਂ ਬਦਲੋ? ਇਹ ਇੱਕ ਪ੍ਰਯੋਗ ਹੈ, ਅਤੇ ਅਸੀਂ ਕਈ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ।

1:n+1 ਐਕਸਚੇਂਜ (ਇੱਕ ਤੋਂ ਕਈ)

ਕਾਫਕਾ ਨਵੇਂ ਖਪਤਕਾਰਾਂ ਨੂੰ API ਨਾਲ ਜੋੜਨਾ ਬਹੁਤ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।

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

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

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

ਡਾਟਾ-ਸੰਚਾਲਿਤ

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

ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲੌਗ

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

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

ਅੱਗੇ, ਉਹਨਾਂ ਲਈ ਜੋ ਕਾਫਕਾ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ, ਉਹਨਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਥੋੜੀ ਜਿਹੀ ਰੀਟੈਲਿੰਗ (ਤਸਵੀਰ ਵੀ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਹੈ)

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

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

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

ਇਵੈਂਟ ਲੋੜਾਂ:

• ਡਾਟਾ ਸੰਪੂਰਨਤਾ. ਮੈਂ ਚਾਹਾਂਗਾ ਕਿ ਇਵੈਂਟ ਕੋਲ ਲੋੜੀਂਦਾ ਡਾਟਾ ਹੋਵੇ ਤਾਂ ਜੋ ਇਸ 'ਤੇ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾ ਸਕੇ।

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

ਲਮੋਡਾ ਵਿੱਚ ਕਾਫਕਾ

ਸਾਡੇ ਕੋਲ ਤਿੰਨ ਕਾਫਕਾ ਸਥਾਪਨਾਵਾਂ ਹਨ:

1. ਲਾਗ;
2. R&D;
3. ਸਮਾਗਮ-ਬੱਸ।

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

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

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

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

ਲਾਮੋਡਾ ਇਵੈਂਟਸ ਕੇਸਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ

ਅਸੀਂ ਨਿਮਨਲਿਖਤ ਕਾਰਜਾਂ ਲਈ ਨਿਰਮਿਤ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ:

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

ਹੁਣ ਪਿਛਲੇ ਛੇ ਮਹੀਨਿਆਂ ਦੌਰਾਨ ਹੋਈਆਂ ਵੱਡੀਆਂ ਝਟਕਿਆਂ ਅਤੇ ਦਿਲਚਸਪ ਖੋਜਾਂ ਬਾਰੇ ਵਧੇਰੇ ਦਿਲਚਸਪ ਹਿੱਸਾ.

ਡਿਜ਼ਾਈਨ ਸਮੱਸਿਆਵਾਂ

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

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

ਡਾਟਾ ਸਟ੍ਰੀਮ

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

ਇੱਕ ਵਿਸ਼ੇ ਵਿੱਚ ਜਾਂ ਵੱਖਰੇ ਵਿੱਚ?

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

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

ਨਵਾਂ ਖੇਤਰ ਜਾਂ ਨਵੀਂ ਘਟਨਾ?

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

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

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

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

ਇਵੈਂਟ ਸੰਸਕਰਣ

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

ਭਾਗਾਂ ਦਾ ਗਾਰੰਟੀਸ਼ੁਦਾ ਰੀਡਿੰਗ ਆਰਡਰ

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

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

ਕਾਫਕਾ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਵੰਡਦਾ ਹੈ? ਹਰੇਕ ਸੁਨੇਹੇ ਦਾ ਇੱਕ ਮੁੱਖ ਭਾਗ (ਜਿਸ ਵਿੱਚ ਅਸੀਂ JSON ਸਟੋਰ ਕਰਦੇ ਹਾਂ) ਅਤੇ ਇੱਕ ਕੁੰਜੀ ਹੁੰਦੀ ਹੈ। ਤੁਸੀਂ ਇਸ ਕੁੰਜੀ ਨਾਲ ਇੱਕ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਜੋੜ ਸਕਦੇ ਹੋ, ਜੋ ਇਹ ਨਿਰਧਾਰਤ ਕਰੇਗਾ ਕਿ ਸੁਨੇਹਾ ਕਿਸ ਭਾਗ ਵਿੱਚ ਜਾਵੇਗਾ।

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

ਇਵੈਂਟਸ ਬਨਾਮ ਕਮਾਂਡਾਂ

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

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

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

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

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

Nuances

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

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

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

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

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

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

ਨਿਗਰਾਨੀ

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

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

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

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

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

ਏਪੀਆਈ ਜਵਾਬ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਇਹ ਹੈ ਗਰੁੱਪ bob-live-fifa, partition refund.update.v1, ਸਟੇਟਸ OK, lag 0 - ਆਖਰੀ ਫਾਈਨਲ ਆਫਸੈੱਟ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਅਤੇ ਅਜਿਹੇ।

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

ਸੰਖੇਪ ਕਰਨ ਲਈ, ਘਟਨਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਹੈ ਜਦੋਂ:

• ਕਈ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ;
• ਪ੍ਰੋਸੈਸਿੰਗ ਦਾ ਨਤੀਜਾ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ;
• ਕੁਝ ਘਟਨਾਵਾਂ ਜਾਂ ਛੋਟੀਆਂ ਘਟਨਾਵਾਂ ਹਨ।

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਲੇਖ ਵਿੱਚ ਇੱਕ ਬਹੁਤ ਹੀ ਖਾਸ ਵਿਸ਼ਾ ਹੈ - ਕਾਫਕਾ 'ਤੇ ਅਸਿੰਕਰੋਨਸ API, ਪਰ ਇਸਦੇ ਸਬੰਧ ਵਿੱਚ ਮੈਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਨਾ ਚਾਹਾਂਗਾ.
ਪਹਿਲਾਂ, ਅਗਲਾ ਹਾਈਲੋਡ++ ਸਾਨੂੰ ਨਵੰਬਰ ਤੱਕ ਇੰਤਜ਼ਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ; ਅਪ੍ਰੈਲ ਵਿੱਚ ਇੱਕ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਸੰਸਕਰਣ ਹੋਵੇਗਾ, ਅਤੇ ਜੂਨ ਵਿੱਚ ਅਸੀਂ ਨੋਵੋਸਿਬਿਰਸਕ ਵਿੱਚ ਉੱਚ ਲੋਡ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ।
ਦੂਜਾ, ਰਿਪੋਰਟ ਦੇ ਲੇਖਕ, ਸਰਗੇਈ ਜ਼ਾਇਕਾ, ਗਿਆਨ ਪ੍ਰਬੰਧਨ 'ਤੇ ਸਾਡੀ ਨਵੀਂ ਕਾਨਫਰੰਸ ਦੀ ਪ੍ਰੋਗਰਾਮ ਕਮੇਟੀ ਦੇ ਮੈਂਬਰ ਹਨ। KnowledgeConf. ਇਹ ਕਾਨਫਰੰਸ ਇੱਕ ਰੋਜ਼ਾ ਹੈ, 26 ਅਪ੍ਰੈਲ ਨੂੰ ਹੋਵੇਗੀ, ਪਰ ਇਸ ਦਾ ਪ੍ਰੋਗਰਾਮ ਬਹੁਤ ਤਿੱਖਾ ਹੈ।
ਅਤੇ ਇਹ ਮਈ ਵਿੱਚ ਹੋਵੇਗਾ PHP ਰੂਸ и RIT++ (devOpsConf ਦੇ ਨਾਲ) - ਤੁਸੀਂ ਉੱਥੇ ਆਪਣੇ ਵਿਸ਼ੇ ਦਾ ਸੁਝਾਅ ਵੀ ਦੇ ਸਕਦੇ ਹੋ, ਆਪਣੇ ਅਨੁਭਵ ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੇ ਭਰੇ ਹੋਏ ਕੋਨ ਬਾਰੇ ਸ਼ਿਕਾਇਤ ਕਰ ਸਕਦੇ ਹੋ।

ਸਰੋਤ: www.habr.com