ਮਿਖਾਇਲ ਸਲੋਸਿਨ. ਗੋਲੰਗ ਮੀਟਿੰਗ. ਲੁੱਕ+ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬੈਕਐਂਡ ਵਿੱਚ ਗੋ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਮਿਖਾਇਲ ਸਲੋਸਿਨ (ਇਸ ਤੋਂ ਬਾਅਦ - MS): - ਸਾਰਿਆਂ ਨੂੰ ਸਤਿ ਸ਼੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਮਾਈਕਲ ਹੈ। ਮੈਂ MC2 ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਇੱਕ ਬੈਕਐਂਡ ਡਿਵੈਲਪਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹਾਂ, ਅਤੇ ਮੈਂ Look+ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਬੈਕਐਂਡ ਵਿੱਚ ਗੋ ਦੀ ਵਰਤੋਂ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਕੀ ਇੱਥੇ ਕੋਈ ਹਾਕੀ ਪਸੰਦ ਕਰਦਾ ਹੈ?

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

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

ਤੁਸੀਂ ਵਿਕਾਸ ਵਿੱਚ ਕੀ ਵਰਤਿਆ?

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

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

ਸਿਸਟਮ API ਟੈਸਟਾਂ ਲਈ, ਅਸੀਂ ਪਾਈਥਨ ਯੂਨਿਟਸਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ। Memcached ਦੀ ਵਰਤੋਂ API ਭੁਗਤਾਨ ਕਾਲਾਂ ਨੂੰ ਥ੍ਰੋਟਲ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, "ਸ਼ੈੱਫ" ਦੀ ਵਰਤੋਂ ਸੰਰਚਨਾ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜ਼ੈਬਿਕਸ ਦੀ ਵਰਤੋਂ ਅੰਦਰੂਨੀ ਸਿਸਟਮ ਅੰਕੜਿਆਂ ਨੂੰ ਇਕੱਤਰ ਕਰਨ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਗ੍ਰੇਲੌਗ 2 ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਲਈ ਹੈ, ਸਲੇਟ ਗਾਹਕਾਂ ਲਈ API ਦਸਤਾਵੇਜ਼ ਹੈ।

ਪ੍ਰੋਟੋਕੋਲ ਚੋਣ

ਪਹਿਲੀ ਸਮੱਸਿਆ ਜਿਸ ਦਾ ਸਾਨੂੰ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ: ਸਾਨੂੰ ਬੈਕਐਂਡ ਅਤੇ ਮੋਬਾਈਲ ਕਲਾਇੰਟਸ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਲਈ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਚੁਣਨ ਦੀ ਲੋੜ ਸੀ, ਹੇਠਾਂ ਦਿੱਤੇ ਬਿੰਦੂਆਂ ਦੇ ਅਧਾਰ 'ਤੇ...

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

ਇਸਦੇ ਅਧਾਰ ਤੇ, ਸਾਡੇ ਕੋਲ ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਵਿਕਲਪ ਸਨ:

1. ਵੈਬਸਾਕੇਟ। ਪਰ ਸਾਨੂੰ ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਤੱਕ ਚੈਨਲਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਸਾਨੂੰ ਸਿਰਫ਼ ਸਰਵਰ ਤੋਂ ਕਲਾਇੰਟ ਨੂੰ ਅੱਪਡੇਟ ਭੇਜਣ ਦੀ ਲੋੜ ਸੀ, ਇਸਲਈ ਇੱਕ ਵੈਬਸਾਕੇਟ ਇੱਕ ਬੇਲੋੜਾ ਵਿਕਲਪ ਹੈ।
2. ਸਰਵਰ-ਭੇਜੇ ਈਵੈਂਟਸ (SSE) ਬਿਲਕੁਲ ਸਹੀ ਆਏ! ਇਹ ਕਾਫ਼ੀ ਸਧਾਰਨ ਹੈ ਅਤੇ ਅਸਲ ਵਿੱਚ ਸਾਨੂੰ ਲੋੜੀਂਦੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਸੰਤੁਸ਼ਟ ਕਰਦਾ ਹੈ।

ਸਰਵਰ ਦੁਆਰਾ ਭੇਜੇ ਗਏ ਇਵੈਂਟ

ਇਹ ਚੀਜ਼ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ...

ਇਹ ਇੱਕ http ਕੁਨੈਕਸ਼ਨ ਦੇ ਸਿਖਰ 'ਤੇ ਚੱਲਦਾ ਹੈ. ਕਲਾਇੰਟ ਇੱਕ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਸਰਵਰ ਸਮੱਗਰੀ-ਕਿਸਮ ਦੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: ਟੈਕਸਟ/ਈਵੈਂਟ-ਸਟ੍ਰੀਮ ਅਤੇ ਕਲਾਇੰਟ ਨਾਲ ਕਨੈਕਸ਼ਨ ਬੰਦ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਕਨੈਕਸ਼ਨ ਲਈ ਡੇਟਾ ਲਿਖਣਾ ਜਾਰੀ ਰੱਖਦਾ ਹੈ:

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

ਹੁਣ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਪਰਸਪਰ ਕ੍ਰਿਆ ਆਪਣੇ ਆਪ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ।

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

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

ਲਾਈਵ ਕਨੈਕਸ਼ਨ ਦੀ ਸੇਵਾ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ?

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਹੁਣ ਸਾਡਾ ਪਿੰਗ ਉਸੇ ਚੈਨਲ ਤੋਂ ਆਉਂਦਾ ਹੈ ਜਿਸ ਤੋਂ ਅੱਪਡੇਟ ਆਉਂਦਾ ਹੈ।

ਇਸ ਅਨੁਸਾਰ, ਇੱਥੇ ਸਿਰਫ ਇੱਕ ਟਾਈਮਰ ਹੈ ਜੋ ਹਰ 15 ਸਕਿੰਟਾਂ ਵਿੱਚ ਇੱਕ ਵਾਰ ਟਿੱਕ ਕਰਦਾ ਹੈ।

ਇੱਥੇ ਕਈ ਸਹਾਇਕ ਫੰਕਸ਼ਨ ਹਨ - ਸਿਰਲੇਖ, ਪਿੰਗ ਅਤੇ ਢਾਂਚੇ ਨੂੰ ਭੇਜਣਾ। ਭਾਵ, ਸਾਰਣੀ ਦਾ ਨਾਮ (ਵਿਅਕਤੀ, ਮੈਚ, ਸੀਜ਼ਨ) ਅਤੇ ਇਸ ਐਂਟਰੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਇੱਥੇ ਪ੍ਰਸਾਰਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

ਅੱਪਡੇਟ ਭੇਜਣ ਲਈ ਵਿਧੀ

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

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

PostgreSQL: ਸੁਣੋ/ਸੂਚਨਾ ਕਰੋ

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

ਕਿਸੇ ਰਿਕਾਰਡ ਨੂੰ ਸੰਮਿਲਿਤ ਜਾਂ ਬਦਲਦੇ ਸਮੇਂ, ਅਸੀਂ data_updates ਚੈਨਲ 'ਤੇ ਸੂਚਨਾ ਫੰਕਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਉੱਥੇ ਸਾਰਣੀ ਦਾ ਨਾਮ ਅਤੇ ਉਸ ਰਿਕਾਰਡ ਦਾ ਪਛਾਣਕਰਤਾ ਪਾਸ ਕਰਦੇ ਹਾਂ ਜੋ ਬਦਲਿਆ ਜਾਂ ਸੰਮਿਲਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

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

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

ਇੱਥੇ ਸਟੈਂਡਰਡ pq ਲਾਇਬ੍ਰੇਰੀ, ਜੋ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਦੀ ਹੈ ਅਤੇ ਕਹਿੰਦੀ ਹੈ ਕਿ ਇਹ ਚੈਨਲ (data_updates) ਨੂੰ ਸੁਣਨਾ ਚਾਹੁੰਦਾ ਹੈ, ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਕੁਨੈਕਸ਼ਨ ਖੁੱਲ੍ਹਾ ਹੈ ਅਤੇ ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਮੈਂ ਜਗ੍ਹਾ ਬਚਾਉਣ ਲਈ ਗਲਤੀ ਜਾਂਚ ਨੂੰ ਛੱਡ ਰਿਹਾ/ਰਹੀ ਹਾਂ (ਜਾਂਚ ਨਾ ਕਰਨਾ ਖਤਰਨਾਕ ਹੈ)।

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

ਫੈਨ-ਆਊਟ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

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

ਇਸਨੂੰ Go ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

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

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

ਇੱਥੇ ਇੱਕ ਸਬਸਕ੍ਰਾਈਬ ਵਿਧੀ ਵੀ ਹੈ ਜੋ ਚੈਨਲ ਨੂੰ "ਸੁਣਨ ਵਾਲਿਆਂ" ਵਿੱਚ ਜੋੜਦੀ ਹੈ:

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

ਸਵਾਲ: - ਇਸ ਚੈਨਲ ਰਾਹੀਂ ਕੀ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ?

MS: - ਮਾਡਲ ਜੋ ਬਦਲ ਗਿਆ ਹੈ ਜਾਂ ਪਿੰਗ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਗਿਆ ਹੈ (ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਇੱਕ ਸੰਖਿਆ, ਪੂਰਨ ਅੰਕ)।

MS: - ਤੁਸੀਂ ਕੁਝ ਵੀ ਭੇਜ ਸਕਦੇ ਹੋ, ਕੋਈ ਵੀ ਢਾਂਚਾ ਭੇਜ ਸਕਦੇ ਹੋ, ਇਸਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦੇ ਹੋ - ਇਹ ਸਿਰਫ਼ JSON ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਬੱਸ ਹੋ ਗਿਆ।

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

ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੀ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ? ਸਾਡੇ ਕੋਲ 7 ਹਾਰਡਵੇਅਰ ਸਰਵਰ ਹਨ: ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਡਾਟਾਬੇਸ ਨੂੰ ਸਮਰਪਿਤ ਹੈ, ਬਾਕੀ ਛੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। API ਦੀਆਂ 6 ਕਾਪੀਆਂ ਹਨ: API ਵਾਲੀ ਹਰੇਕ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਇੱਕ ਵੱਖਰੇ ਹਾਰਡਵੇਅਰ ਸਰਵਰ 'ਤੇ ਚੱਲਦੀ ਹੈ - ਇਹ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਹੈ।

ਸਾਡੇ ਕੋਲ ਪਹੁੰਚਯੋਗਤਾ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ Keepalived ਦੇ ਨਾਲ ਦੋ ਫਰੰਟਐਂਡ ਸਥਾਪਤ ਹਨ, ਤਾਂ ਜੋ ਜੇਕਰ ਕੁਝ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਫਰੰਟਐਂਡ ਦੂਜੇ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ। ਨਾਲ ਹੀ, CMS ਦੀਆਂ ਦੋ ਕਾਪੀਆਂ.

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

ਅਸਲ ਵਿੱਚ, ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬੇਲੋੜਾ ਹੈ, ਕਿਉਂਕਿ 100 ਹਜ਼ਾਰ ਘੱਟ ਸਰਵਰਾਂ ਨਾਲ ਸੇਵਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ. ਪਰ ਲੋਹਾ ਸੀ - ਅਸੀਂ ਇਸਨੂੰ ਵਰਤਿਆ (ਸਾਨੂੰ ਦੱਸਿਆ ਗਿਆ ਕਿ ਇਹ ਸੰਭਵ ਸੀ - ਕਿਉਂ ਨਹੀਂ).

ਗੋ ਦੇ ਫਾਇਦੇ

ਇਸ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਨ ਤੋਂ ਬਾਅਦ, Go ਦੇ ਅਜਿਹੇ ਸਪੱਸ਼ਟ ਫਾਇਦੇ ਸਾਹਮਣੇ ਆਏ।

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

ਅਸੀਂ ਡਿਵੈਲਪਰਾਂ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹਾਂ! ਜੇ ਕੋਈ ਚਾਹੁੰਦਾ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ.

ਤੁਹਾਡੇ ਸਵਾਲ

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

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

ਏ ਟੀ: - ਕੀ ਇਹ ਤੁਰੰਤ ਸੁਣਨ/ਸੂਚਿਤ ਕਰਨ ਲਈ ਇੱਕ ਰਿਕਾਰਡ ਭੇਜਣਾ ਸੰਭਵ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਪਛਾਣਕਰਤਾ ਸਾਰਣੀ ਨੂੰ ਨਹੀਂ?

MS: - ਸੁਣੋ/ਸੂਚਨਾ ਕਰੋ ਇਸ ਦੁਆਰਾ ਭੇਜੇ ਗਏ ਪ੍ਰੀਲੋਡ 'ਤੇ 8 ਹਜ਼ਾਰ ਬਾਈਟਸ ਦੀ ਸੀਮਾ ਹੈ। ਸਿਧਾਂਤ ਵਿੱਚ, ਇਹ ਭੇਜਣਾ ਸੰਭਵ ਹੋਵੇਗਾ ਜੇਕਰ ਅਸੀਂ ਥੋੜ੍ਹੇ ਜਿਹੇ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਸੀ, ਪਰ ਇਹ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਸ ਤਰੀਕੇ ਨਾਲ [ਜਿਸ ਤਰੀਕੇ ਨਾਲ ਅਸੀਂ ਇਸਨੂੰ ਕਰਦੇ ਹਾਂ] ਬਸ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੈ. ਸੀਮਾਵਾਂ ਪੋਸਟਗ੍ਰੇਸ ਵਿੱਚ ਹੀ ਹਨ.

ਏ ਟੀ: - ਕੀ ਗਾਹਕਾਂ ਨੂੰ ਉਹਨਾਂ ਮੈਚਾਂ ਬਾਰੇ ਅੱਪਡੇਟ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ ਜਿਹਨਾਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਦਿਲਚਸਪੀ ਨਹੀਂ ਹੈ?

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

ਏ ਟੀ: - ਤੁਸੀਂ ਆਪਣਾ ORM ਕਿਉਂ ਬਣਾਇਆ?

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

ਸਾਡਾ ORM ਡਾਟਾ ਮਾਡਲ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਤਰ ਤਿਆਰ ਕਰਦਾ ਹੈ। ਆਪਣੇ ਆਪ ਨੂੰ. ਅਤੇ ਇਸਲਈ ਸਾਰੇ ਤਰੀਕੇ ਠੋਸ ਹਨ, ਪ੍ਰਤੀਬਿੰਬ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ, ਆਦਿ। ਉਹ ਢਾਂਚਿਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਢਾਂਚਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ ਜੋ ਆਉਂਦੇ ਹਨ।

ਏ ਟੀ: - ਕਿੰਨੇ ਲੋਕਾਂ ਨੇ ਹਿੱਸਾ ਲਿਆ?

MS: - ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ 'ਤੇ, ਦੋ ਲੋਕਾਂ ਨੇ ਹਿੱਸਾ ਲਿਆ। ਅਸੀਂ ਜੂਨ ਵਿੱਚ ਕਿਤੇ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਅਗਸਤ ਵਿੱਚ ਮੁੱਖ ਭਾਗ ਤਿਆਰ ਹੋ ਗਿਆ (ਪਹਿਲਾ ਸੰਸਕਰਣ)। ਸਤੰਬਰ ਵਿੱਚ ਰਿਲੀਜ਼ ਹੋਈ ਸੀ।

ਏ ਟੀ: - ਜਿੱਥੇ ਤੁਸੀਂ SSE ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਸਮਾਂ ਸਮਾਪਤੀ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹੋ। ਅਜਿਹਾ ਕਿਉਂ ਹੈ?

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

ਏ ਟੀ: - ਤੁਸੀਂ ਕਿਹੜੀਆਂ ਵਾਧੂ ਸਹੂਲਤਾਂ ਵਰਤੀਆਂ ਹਨ?

MS: - ਅਸੀਂ ਸ਼ੈਲੀ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਬਣਾਉਣ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਸਰਗਰਮੀ ਨਾਲ ਗੋਵੇਟ ਅਤੇ ਗੋਲਿੰਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਨਾਲ ਹੀ gofmt. ਹੋਰ ਕੁਝ ਨਹੀਂ ਵਰਤਿਆ ਗਿਆ।

ਏ ਟੀ: - ਤੁਸੀਂ ਡੀਬੱਗ ਕਰਨ ਲਈ ਕੀ ਵਰਤਿਆ?

MS: - ਡੀਬੱਗਿੰਗ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਟੈਸਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੀ ਗਈ ਸੀ। ਅਸੀਂ ਕਿਸੇ ਡੀਬਗਰ ਜਾਂ GOP ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ।

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

MS: - ਨਹੀਂ। ਉਹਨਾਂ ਕੋਲ ਦਿੱਖ ਦਾ ਕਾਫ਼ੀ "ਤੰਗ" ਦਾਇਰਾ ਹੈ। ਉਹ ਇੱਥੇ (ਇਸ ਕਲਾਸ ਦੇ ਅੰਦਰੂਨੀ ਨੂੰ ਛੱਡ ਕੇ) ਨੂੰ ਛੱਡ ਕੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਹ ਬਹੁਤ ਸੰਖੇਪ ਹੈ - ਇਹ ਸਿਰਫ 7 ਲਾਈਨਾਂ ਲੈਂਦਾ ਹੈ।

ਏ ਟੀ: - ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹ ਅਜੇ ਵੀ ਅਨੁਭਵੀ ਨਹੀਂ ਹੈ ...

MS: - ਨਹੀਂ, ਨਹੀਂ, ਇਹ ਇੱਕ ਅਸਲੀ ਕੋਡ ਹੈ! ਇਹ ਸ਼ੈਲੀ ਬਾਰੇ ਨਹੀਂ ਹੈ. ਇਹ ਸਿਰਫ ਅਜਿਹੀ ਉਪਯੋਗੀ, ਬਹੁਤ ਛੋਟੀ ਕਲਾਸ ਹੈ - ਕਲਾਸ ਦੇ ਅੰਦਰ ਸਿਰਫ 3 ਖੇਤਰ...

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

ਏ ਟੀ: - ਕੀ ਕੋਈ ਤੀਜੀ-ਧਿਰ ਨਿਰਭਰਤਾ ਪ੍ਰਬੰਧਨ ਪੈਕੇਜ ਹਨ?

MS: - ਅਸੀਂ ਗੋ ਡਿਪ ਦੀ ਵਰਤੋਂ ਕੀਤੀ।

ਏ ਟੀ: - ਰਿਪੋਰਟ ਦੇ ਵਿਸ਼ੇ ਵਿੱਚ ਵੀਡੀਓ ਬਾਰੇ ਕੁਝ ਸੀ, ਪਰ ਵੀਡੀਓ ਬਾਰੇ ਰਿਪੋਰਟ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਸੀ।

MS: - ਨਹੀਂ, ਮੇਰੇ ਕੋਲ ਵੀਡੀਓ ਬਾਰੇ ਵਿਸ਼ੇ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਹੈ। ਇਸਨੂੰ "ਲੁੱਕ+" ਕਿਹਾ ਜਾਂਦਾ ਹੈ - ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਨਾਮ ਹੈ।

ਏ ਟੀ: - ਤੁਸੀਂ ਕਿਹਾ ਕਿ ਇਹ ਗਾਹਕਾਂ ਨੂੰ ਸਟ੍ਰੀਮ ਕੀਤਾ ਗਿਆ ਹੈ? ..

MS: - ਅਸੀਂ ਸਟ੍ਰੀਮਿੰਗ ਵੀਡੀਓ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਸੀ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੇਗਾਫੋਨ ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਹਾਂ, ਮੈਂ ਇਹ ਨਹੀਂ ਕਿਹਾ ਕਿ ਐਪਲੀਕੇਸ਼ਨ MegaFon ਸੀ।

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

ਕੁਝ ਵਿਗਿਆਪਨ 🙂

ਸਾਡੇ ਨਾਲ ਰਹਿਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। ਕੀ ਤੁਹਾਨੂੰ ਸਾਡੇ ਲੇਖ ਪਸੰਦ ਹਨ? ਹੋਰ ਦਿਲਚਸਪ ਸਮੱਗਰੀ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ? ਆਰਡਰ ਦੇ ਕੇ ਜਾਂ ਦੋਸਤਾਂ ਨੂੰ ਸਿਫਾਰਸ਼ ਕਰਕੇ ਸਾਡਾ ਸਮਰਥਨ ਕਰੋ, $4.99 ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਕਲਾਉਡ VPS, ਪ੍ਰਵੇਸ਼-ਪੱਧਰ ਦੇ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਵਿਲੱਖਣ ਐਨਾਲਾਗ, ਜਿਸਦੀ ਖੋਜ ਸਾਡੇ ਦੁਆਰਾ ਤੁਹਾਡੇ ਲਈ ਕੀਤੀ ਗਈ ਸੀ: VPS (KVM) E5-2697 v3 (6 ਕੋਰ) 10GB DDR4 480GB SSD 1Gbps ਤੋਂ $19 ਜਾਂ ਸਰਵਰ ਨੂੰ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਨਾ ਹੈ ਬਾਰੇ ਪੂਰੀ ਸੱਚਾਈ? (RAID1 ਅਤੇ RAID10 ਦੇ ਨਾਲ ਉਪਲਬਧ, 24 ਕੋਰ ਤੱਕ ਅਤੇ 40GB DDR4 ਤੱਕ)।

ਡੈਲ R730xd ਐਮਸਟਰਡਮ ਵਿੱਚ ਈਕੁਇਨਿਕਸ ਟੀਅਰ IV ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ 2 ਗੁਣਾ ਸਸਤਾ? ਇੱਥੇ ਹੀ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ਟੀਵੀ $199 ਤੋਂ ਨੀਦਰਲੈਂਡ ਵਿੱਚ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ਤੋਂ! ਬਾਰੇ ਪੜ੍ਹੋ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਾਰਪੋਰੇਸ਼ਨ ਕਿਵੇਂ ਬਣਾਇਆ ਜਾਵੇ ਡੇਲ R730xd E5-2650 v4 ਸਰਵਰਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਕਲਾਸ 9000 ਯੂਰੋ ਦੀ ਕੀਮਤ ਦੇ ਇੱਕ ਪੈਸੇ ਲਈ?

ਸਰੋਤ: www.habr.com