ਹੇ ਹਬਰ!

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

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

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

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

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

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

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

CQRS

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

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

1. ਕਲਾਇੰਟ ਨੇ ਸਰਵਰ ਨੂੰ ਇੱਕ ਬੇਨਤੀ ਭੇਜੀ।
2. ਸਰਵਰ ਨੇ ਲੰਬੀ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤੀ।
3. ਸਰਵਰ ਨੇ ਨਤੀਜੇ ਦੇ ਨਾਲ ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਦਿੱਤਾ।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਇਹ ਧਿਆਨ ਦੇਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਚਿੱਤਰ ਵਿੱਚ ਸੇਵਾਵਾਂ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਵੱਖਰੇ ਸਰਵਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਨਹੀਂ ਹਨ। ਉਹ ਇੱਕੋ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਾਂਝਾ ਵੀ ਕਰ ਸਕਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਵਿਚਾਰਧਾਰਕ ਤੌਰ 'ਤੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਖਿਤਿਜੀ ਸਕੇਲਿੰਗ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

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

ਹਾਲਾਂਕਿ, ਨੁਕਸਾਨ ਤੁਰੰਤ ਸਪੱਸ਼ਟ ਹਨ:

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

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

ਫਲਸਰੂਪ:

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

ਸ਼ੇਅਰਿੰਗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ਸਿੱਟਾ

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

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

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

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

ਸਰੋਤ: www.habr.com