ਹੇ ਹਬਰ!

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

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

ਹਰੀਜ਼ੱਟਲ ਸਕੇਲਿੰਗ

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

ਉਦਾਹਰਨ ਲਈ, ਮੈਂ ਐਬਸਟ੍ਰੈਕਟ ਕਲਾਉਡ ਫਾਈਲ ਸਟੋਰੇਜ ਲਵਾਂਗਾ, ਯਾਨੀ OwnCloud, OneDrive, ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਕੁਝ ਐਨਾਲਾਗ।

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

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

CQRS

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

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

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

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

ਕਲਾਇੰਟ ਨੇ ਅਪਡੇਟਾਂ ਲਈ ਗਾਹਕੀ ਲਿਆ ਹੈ।
ਕਲਾਇੰਟ ਨੇ ਸਰਵਰ ਨੂੰ ਇੱਕ ਬੇਨਤੀ ਭੇਜੀ ਹੈ।
ਸਰਵਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ "ਬੇਨਤੀ ਸਵੀਕਾਰ ਕੀਤੀ ਗਈ।"
ਸਰਵਰ ਨੇ ਪੁਆਇੰਟ "1" ਤੋਂ ਚੈਨਲ ਰਾਹੀਂ ਨਤੀਜੇ ਦੇ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ।

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

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

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

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

ਇਵੈਂਟ ਸੋਰਸਿੰਗ

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

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

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

ਹਾਲਾਂਕਿ, ਆਓ ਅਸਲ ਕੰਮ ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ. ਜੇਕਰ ਸਿਸਟਮ ਦੇ ਹਿੱਸੇ ਨਾਲ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅੰਤਮ ਇਕਸਾਰਤਾ, ਫਿਰ ਅਸੀਂ ਹੇਠ ਲਿਖਿਆ ਚਿੱਤਰ ਬਣਾ ਸਕਦੇ ਹਾਂ।

ਇਸ ਪਹੁੰਚ ਦੀਆਂ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

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

ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਅਸੀਂ ਔਨਲਾਈਨ ਫਾਈਲ ਸਟੋਰੇਜ ਦੇ ਮਾਮਲੇ 'ਤੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਾਂ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਚਿੱਤਰ ਵਿੱਚ ਸੇਵਾਵਾਂ ਦਾ ਮਤਲਬ ਇੱਕ ਵੱਖਰਾ ਸਰਵਰ ਨਹੀਂ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ ਪ੍ਰਕਿਰਿਆ ਵੀ ਇੱਕੋ ਜਿਹੀ ਹੋ ਸਕਦੀ ਹੈ. ਇਕ ਹੋਰ ਗੱਲ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਵਿਚਾਰਧਾਰਕ ਤੌਰ 'ਤੇ, ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ.

ਅਤੇ ਦੋ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਚਿੱਤਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ (ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਸੇਵਾਵਾਂ ਵੱਖ-ਵੱਖ ਰੰਗਾਂ ਵਿੱਚ ਦਰਸਾਈਆਂ ਗਈਆਂ ਹਨ):

ਅਜਿਹੇ ਸੁਮੇਲ ਤੋਂ ਬੋਨਸ:

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

ਹਾਲਾਂਕਿ, ਨੁਕਸਾਨ ਤੁਰੰਤ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ:

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

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

ਫਲਸਰੂਪ:

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

ਸ਼ੇਅਰਿੰਗ

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

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

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

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

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

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

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

ਸਥਿਰ ਸਮੱਗਰੀ ਹੋਸਟਿੰਗ

ਇਹ ਬਿੰਦੂ ਕਾਫ਼ੀ ਸਪੱਸ਼ਟ ਜਾਪਦਾ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਘੱਟ ਜਾਂ ਘੱਟ ਮਿਆਰੀ ਲੋਡ ਕੀਤੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਜ਼ਰੂਰੀ ਹੈ। ਇਸਦਾ ਸਾਰ ਸਧਾਰਨ ਹੈ: ਸਾਰੀ ਸਥਿਰ ਸਮੱਗਰੀ ਨੂੰ ਉਸੇ ਸਰਵਰ ਤੋਂ ਨਹੀਂ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਐਪਲੀਕੇਸ਼ਨ ਸਥਿਤ ਹੈ, ਪਰ ਇਸ ਕੰਮ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਸਮਰਪਿਤ ਵਿਸ਼ੇਸ਼ ਲੋਕਾਂ ਤੋਂ. ਨਤੀਜੇ ਵਜੋਂ, ਇਹ ਓਪਰੇਸ਼ਨ ਤੇਜ਼ੀ ਨਾਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (ਸ਼ਰਤ nginx ਇੱਕ Java ਸਰਵਰ ਨਾਲੋਂ ਵਧੇਰੇ ਤੇਜ਼ੀ ਨਾਲ ਅਤੇ ਘੱਟ ਮਹਿੰਗੇ ਢੰਗ ਨਾਲ ਫਾਈਲਾਂ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ)। ਪਲੱਸ CDN ਆਰਕੀਟੈਕਚਰ (ਸਮਗਰੀ ਡਿਲੀਵਰੀ ਨੈਟਵਰਕ) ਸਾਨੂੰ ਸਾਡੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਅੰਤਮ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਲੱਭਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜਿਸਦਾ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸਹੂਲਤ 'ਤੇ ਸਕਾਰਾਤਮਕ ਪ੍ਰਭਾਵ ਪੈਂਦਾ ਹੈ।

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

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

ਸਰਵਰ ਇੱਕ ਡਾਊਨਲੋਡ URL ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ ਫਾਰਮ ਫਾਈਲ_ਆਈਡੀ + ਕੁੰਜੀ ਦਾ ਹੋ ਸਕਦਾ ਹੈ, ਜਿੱਥੇ ਕੁੰਜੀ ਇੱਕ ਮਿੰਨੀ-ਡਿਜੀਟਲ ਹਸਤਾਖਰ ਹੁੰਦੀ ਹੈ ਜੋ ਅਗਲੇ 24 ਘੰਟਿਆਂ ਲਈ ਸਰੋਤ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦਾ ਅਧਿਕਾਰ ਦਿੰਦੀ ਹੈ।
ਫਾਈਲ ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪਾਂ ਨਾਲ ਸਧਾਰਨ nginx ਦੁਆਰਾ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ:
- ਸਮੱਗਰੀ ਕੈਸ਼ਿੰਗ। ਕਿਉਂਕਿ ਇਹ ਸੇਵਾ ਇੱਕ ਵੱਖਰੇ ਸਰਵਰ 'ਤੇ ਸਥਿਤ ਹੋ ਸਕਦੀ ਹੈ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਡਿਸਕ 'ਤੇ ਸਾਰੀਆਂ ਨਵੀਨਤਮ ਡਾਉਨਲੋਡ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ ਭਵਿੱਖ ਲਈ ਇੱਕ ਰਿਜ਼ਰਵ ਛੱਡ ਦਿੱਤਾ ਹੈ.
- ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਣ ਵੇਲੇ ਕੁੰਜੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ
ਵਿਕਲਪਿਕ: ਸਟ੍ਰੀਮਿੰਗ ਸਮੱਗਰੀ ਪ੍ਰੋਸੈਸਿੰਗ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਅਸੀਂ ਸੇਵਾ ਵਿੱਚ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸੰਕੁਚਿਤ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇਸ ਮੋਡੀਊਲ ਵਿੱਚ ਸਿੱਧੇ ਅਨਜ਼ਿਪ ਕਰ ਸਕਦੇ ਹਾਂ। ਨਤੀਜੇ ਵਜੋਂ: IO ਓਪਰੇਸ਼ਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿੱਥੇ ਉਹ ਸਬੰਧਤ ਹਨ। Java ਵਿੱਚ ਇੱਕ ਆਰਕਾਈਵਰ ਆਸਾਨੀ ਨਾਲ ਬਹੁਤ ਸਾਰੀ ਵਾਧੂ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰੇਗਾ, ਪਰ ਕਾਰੋਬਾਰੀ ਤਰਕ ਵਾਲੀ ਸੇਵਾ ਨੂੰ Rust/C++ ਕੰਡੀਸ਼ਨਲ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣਾ ਵੀ ਬੇਅਸਰ ਹੋ ਸਕਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਪ੍ਰਕਿਰਿਆਵਾਂ (ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ ਸੇਵਾਵਾਂ) ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਸਲਈ ਅਸੀਂ ਕਾਰੋਬਾਰੀ ਤਰਕ ਅਤੇ IO ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਕਾਫ਼ੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਵੱਖ ਕਰ ਸਕਦੇ ਹਾਂ।

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

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

ਹਾਲਾਂਕਿ, ਜੇਕਰ ਅਸੀਂ ਆਪਣੇ ਸਿਸਟਮ ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਇੱਕ ਸਮਾਨ ਚਿੱਤਰ ਮਿਲਦਾ ਹੈ:

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

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

ਸਿੱਟਾ

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

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

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

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

ਸਰੋਤ: www.habr.com

ਸੁਵਿਧਾਜਨਕ ਆਰਕੀਟੈਕਚਰਲ ਪੈਟਰਨ