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

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

ਆਉ ਜਾਣਕਾਰੀ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ ਅਤੇ ਮੂਲ ਫਾਰਮੂਲਾ ਲਿਖੀਏ। ਅਸੀਂ ਆਪਣੀ ਨਵੀਂ ਫੋਟੋ ਸ਼ੇਅਰਿੰਗ ਸਾਈਟ ਗ੍ਰਾਮਿੰਸਟਾ ਨੂੰ 1 ਤੋਂ 100 ਉਪਭੋਗਤਾਵਾਂ ਤੱਕ ਕਦਮ ਦਰ ਕਦਮ ਵਧਾਉਣ ਜਾ ਰਹੇ ਹਾਂ।

ਆਓ ਇਹ ਲਿਖੀਏ ਕਿ ਜਦੋਂ ਦਰਸ਼ਕ 10, 100, 1000, 10 ਅਤੇ 000 ਲੋਕਾਂ ਤੱਕ ਵਧਦੇ ਹਨ ਤਾਂ ਕਿਹੜੀਆਂ ਖਾਸ ਕਾਰਵਾਈਆਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

1 ਉਪਭੋਗਤਾ: 1 ਮਸ਼ੀਨ

ਲਗਭਗ ਹਰ ਐਪਲੀਕੇਸ਼ਨ, ਭਾਵੇਂ ਇਹ ਇੱਕ ਵੈਬਸਾਈਟ ਜਾਂ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਹੋਵੇ, ਦੇ ਤਿੰਨ ਮੁੱਖ ਭਾਗ ਹੁੰਦੇ ਹਨ:

• API
• ਡਾਟਾਬੇਸ
• ਕਲਾਇੰਟ (ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਜਾਂ ਵੈਬਸਾਈਟ)

ਡੇਟਾਬੇਸ ਨਿਰੰਤਰ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਹੈ। API ਇਸ ਡੇਟਾ ਲਈ ਅਤੇ ਇਸਦੇ ਆਲੇ ਦੁਆਲੇ ਬੇਨਤੀਆਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਕਲਾਇੰਟ ਉਪਭੋਗਤਾ ਨੂੰ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕਰਦਾ ਹੈ.

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

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

ਸਿਧਾਂਤ ਵਿੱਚ, ਅਸੀਂ ਇਸਨੂੰ ਇੱਕ ਸਿੰਗਲ ਡਿਜੀਟਲ ਓਸ਼ਨ ਡ੍ਰੌਪਲੇਟ ਜਾਂ AWS EC2 ਉਦਾਹਰਨ 'ਤੇ ਕਲਾਉਡ ਵਿੱਚ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:

ਇਸ ਦੇ ਨਾਲ, ਜੇਕਰ ਇੱਕ ਸਾਈਟ 'ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਉਪਭੋਗਤਾ ਹੋਣਗੇ, ਤਾਂ ਇਹ ਇੱਕ ਡੇਟਾਬੇਸ ਲੇਅਰ ਨੂੰ ਸਮਰਪਿਤ ਕਰਨ ਲਈ ਲਗਭਗ ਹਮੇਸ਼ਾ ਸਮਝਦਾ ਹੈ.

10 ਉਪਭੋਗਤਾ: ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਪੱਧਰ 'ਤੇ ਲਿਜਾਣਾ

ਡਾਟਾਬੇਸ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਸੇਵਾਵਾਂ ਜਿਵੇਂ ਕਿ Amazon RDS ਜਾਂ Digital Ocean Managed Database ਵਿੱਚ ਵੰਡਣਾ ਸਾਡੇ ਲਈ ਲੰਬੇ ਸਮੇਂ ਲਈ ਵਧੀਆ ਸੇਵਾ ਕਰੇਗਾ। ਇਹ ਇੱਕ ਸਿੰਗਲ ਮਸ਼ੀਨ ਜਾਂ EC2 ਉਦਾਹਰਣ 'ਤੇ ਸਵੈ-ਹੋਸਟਿੰਗ ਨਾਲੋਂ ਥੋੜਾ ਜਿਹਾ ਮਹਿੰਗਾ ਹੈ, ਪਰ ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਦੇ ਨਾਲ ਤੁਹਾਨੂੰ ਬਾਕਸ ਦੇ ਬਾਹਰ ਬਹੁਤ ਸਾਰੇ ਉਪਯੋਗੀ ਐਕਸਟੈਂਸ਼ਨ ਮਿਲਦੇ ਹਨ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਕੰਮ ਆਉਣਗੇ: ਬਹੁ-ਖੇਤਰ ਬੈਕਅਪ, ਰੀਡ ਰਿਪਲੀਕਾ, ਆਟੋਮੈਟਿਕ ਬੈਕਅੱਪ, ਅਤੇ ਹੋਰ.

ਇਹ ਸਿਸਟਮ ਹੁਣ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

100 ਉਪਭੋਗਤਾ: ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਪੱਧਰ 'ਤੇ ਲਿਜਾਣਾ

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

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

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

ਅਜਿਹਾ ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

1000 ਉਪਭੋਗਤਾ: ਲੋਡ ਬੈਲੇਂਸਰ ਸ਼ਾਮਲ ਕਰੋ

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

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

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

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

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

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

ਨੋਟ ਕਰੋ। ਇਸ ਸਮੇਂ ਸਾਡਾ ਸਿਸਟਮ ਉਸ ਨਾਲ ਬਹੁਤ ਮਿਲਦਾ ਜੁਲਦਾ ਹੈ ਜੋ PaaS ਕੰਪਨੀਆਂ AWS 'ਤੇ Heroku ਜਾਂ Elastic Beanstalk ਦੁਆਰਾ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੀਆਂ ਹਨ (ਜਿਸ ਕਰਕੇ ਉਹ ਬਹੁਤ ਮਸ਼ਹੂਰ ਹਨ)। Heroku ਡੇਟਾਬੇਸ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਹੋਸਟ 'ਤੇ ਰੱਖਦਾ ਹੈ, ਇੱਕ ਆਟੋ-ਸਕੇਲਿੰਗ ਲੋਡ ਬੈਲੈਂਸਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ API ਤੋਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੈਬ ਕਲਾਇੰਟ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਜਾਂ ਸਟਾਰਟਅੱਪਸ ਲਈ Heroku ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਇਹ ਇੱਕ ਵਧੀਆ ਕਾਰਨ ਹੈ - ਤੁਹਾਨੂੰ ਸਾਰੀਆਂ ਬੁਨਿਆਦੀ ਸੇਵਾਵਾਂ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਮਿਲਦੀਆਂ ਹਨ।

10 ਉਪਭੋਗਤਾ: CDN

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

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

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

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

100 ਉਪਭੋਗਤਾ: ਡੇਟਾ ਪਰਤ ਨੂੰ ਸਕੇਲ ਕਰਨਾ

CDN ਨੇ ਬਹੁਤ ਮਦਦ ਕੀਤੀ ਹੈ: ਆਵਾਜਾਈ ਪੂਰੀ ਗਤੀ ਨਾਲ ਵਧ ਰਹੀ ਹੈ. ਮਸ਼ਹੂਰ ਵੀਡੀਓ ਬਲੌਗਰ ਮਾਵਿਡ ਮੋਬਰਿਕ ਨੇ ਹੁਣੇ ਹੀ ਸਾਡੇ ਨਾਲ ਰਜਿਸਟਰ ਕੀਤਾ ਹੈ ਅਤੇ ਆਪਣੀ "ਕਹਾਣੀ" ਪੋਸਟ ਕੀਤੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ. ਲੋਡ ਬੈਲੈਂਸਰ ਲਈ ਧੰਨਵਾਦ, API ਸਰਵਰਾਂ 'ਤੇ CPU ਅਤੇ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਘੱਟ ਰੱਖੀ ਗਈ ਹੈ (ਦਸ API ਉਦਾਹਰਨਾਂ ਚੱਲ ਰਹੀਆਂ ਹਨ), ਪਰ ਅਸੀਂ ਬੇਨਤੀਆਂ 'ਤੇ ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਾਂ... ਇਹ ਦੇਰੀ ਕਿੱਥੋਂ ਆ ਰਹੀਆਂ ਹਨ?

ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਖੋਦਣ ਨਾਲ, ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਡੇਟਾਬੇਸ ਸਰਵਰ 'ਤੇ CPU 80-90% ਲੋਡ ਹੈ। ਅਸੀਂ ਸੀਮਾ 'ਤੇ ਹਾਂ।

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

ਕੈਸ਼ਿੰਗ

ਸਾਡੇ ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਵਧਾਉਣ ਦੇ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨਵਾਂ ਭਾਗ ਪੇਸ਼ ਕਰਨਾ ਹੈ: ਕੈਸ਼ ਲੇਅਰ। ਸਭ ਤੋਂ ਆਮ ਕੈਚਿੰਗ ਵਿਧੀ ਇੱਕ ਇਨ-ਮੈਮੋਰੀ ਕੀ-ਵੈਲਯੂ ਰਿਕਾਰਡ ਸਟੋਰ ਹੈ, ਜਿਵੇਂ ਕਿ Redis ਜਾਂ Memcached। ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡਸ ਵਿੱਚ ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਦਾ ਇੱਕ ਪ੍ਰਬੰਧਿਤ ਸੰਸਕਰਣ ਹੁੰਦਾ ਹੈ: AWS 'ਤੇ Elasticache ਅਤੇ Google Cloud 'ਤੇ Memorystore.

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

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

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

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

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

ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਪੜ੍ਹੋ

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

ਇਹ ਹੁਣ ਸਾਡਾ ਸਿਸਟਮ ਹੈ:

ਅਗਲਾ ਕਦਮ

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

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

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

ਸਰੋਤ

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

ਫੁਟਨੋਟਸ

1. ਹਾਲਾਂਕਿ ਕਈ ਮੌਕਿਆਂ 'ਤੇ ਲੋਡ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਾਨ ਹੈ, ਇੱਕ Redis ਕਲੱਸਟਰ ਦਾ ਅੰਡਰਲਾਈੰਗ ਲਾਗੂ ਕਰਨਾ ਲੋਡ ਬੈਲੇਂਸਰ ਤੋਂ ਬਹੁਤ ਵੱਖਰਾ ਹੈ। [ਵਾਪਸੀ]

ਸਰੋਤ: www.habr.com