VKontakte ਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਕੰਮ ਬਾਰੇ ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲ

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

ਅਲੈਕਸੀ ਅਕੁਲੋਵਿਚ (AterCattus) VKontakte ਟੀਮ ਵਿੱਚ ਬੈਕਐਂਡ ਡਿਵੈਲਪਰ। ਇਸ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਪਲੇਟਫਾਰਮ ਦੇ ਸੰਚਾਲਨ, ਬੁਨਿਆਦੀ ਢਾਂਚੇ, ਸਰਵਰਾਂ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਬਾਰੇ ਅਕਸਰ ਪੁੱਛੇ ਜਾਂਦੇ ਸਵਾਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹਿਕ ਜਵਾਬ ਹੈ, ਪਰ ਵਿਕਾਸ ਬਾਰੇ ਨਹੀਂ, ਅਰਥਾਤ। ਲੋਹੇ ਬਾਰੇ. ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਡੇਟਾਬੇਸ ਬਾਰੇ ਅਤੇ ਇਸ ਦੀ ਬਜਾਏ VK ਕੋਲ ਕੀ ਹੈ, ਲੌਗ ਇਕੱਠੇ ਕਰਨ ਅਤੇ ਸਮੁੱਚੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਬਾਰੇ। ਕੱਟ ਦੇ ਅਧੀਨ ਵੇਰਵੇ.

ਚਾਰ ਸਾਲਾਂ ਤੋਂ ਵੱਧ ਸਮੇਂ ਤੋਂ ਮੈਂ ਬੈਕਐਂਡ ਨਾਲ ਸਬੰਧਤ ਹਰ ਕਿਸਮ ਦੇ ਕੰਮਾਂ ਨਾਲ ਨਜਿੱਠ ਰਿਹਾ ਹਾਂ.

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

ਇਸ ਸਮੇਂ ਦੌਰਾਨ, ਸਾਈਟ ਦੇ ਬਹੁਤ ਸਾਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਮੇਰਾ ਹੱਥ ਸੀ. ਮੈਂ ਇਹ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ।

ਆਮ ਆਰਕੀਟੈਕਚਰ

ਹਰ ਚੀਜ਼, ਆਮ ਵਾਂਗ, ਇੱਕ ਸਰਵਰ ਜਾਂ ਸਰਵਰਾਂ ਦੇ ਸਮੂਹ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜੋ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ।

ਫਰੰਟ ਸਰਵਰ

ਫਰੰਟ ਸਰਵਰ HTTPS, RTMP ਅਤੇ WSS ਰਾਹੀਂ ਬੇਨਤੀਆਂ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

HTTPS - ਇਹ ਸਾਈਟ ਦੇ ਮੁੱਖ ਅਤੇ ਮੋਬਾਈਲ ਵੈੱਬ ਸੰਸਕਰਣਾਂ ਲਈ ਬੇਨਤੀਆਂ ਹਨ: vk.com ਅਤੇ m.vk.com, ਅਤੇ ਸਾਡੇ API ਦੇ ਹੋਰ ਅਧਿਕਾਰਤ ਅਤੇ ਅਣਅਧਿਕਾਰਤ ਕਲਾਇੰਟਸ: ਮੋਬਾਈਲ ਕਲਾਇੰਟਸ, ਮੈਸੇਂਜਰ। ਸਾਡੇ ਕੋਲ ਰਿਸੈਪਸ਼ਨ ਹੈ RTMP- ਵੱਖਰੇ ਫਰੰਟ ਸਰਵਰਾਂ ਦੇ ਨਾਲ ਲਾਈਵ ਪ੍ਰਸਾਰਣ ਲਈ ਟ੍ਰੈਫਿਕ ਅਤੇ WSS- ਸਟ੍ਰੀਮਿੰਗ API ਲਈ ਕਨੈਕਸ਼ਨ।

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

ਅਸੀਂ WSS ਅਤੇ RTMP ਬਾਰੇ ਹੋਰ ਗੱਲ ਨਹੀਂ ਕਰਾਂਗੇ, ਪਰ ਸਿਰਫ ਮਿਆਰੀ HTTPS ਬੇਨਤੀਆਂ ਬਾਰੇ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਵੈਬ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਜੁੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ।

ਪਿੱਠਵਰਤੀ

ਸਾਹਮਣੇ ਦੇ ਪਿੱਛੇ ਆਮ ਤੌਰ 'ਤੇ ਬੈਕਐਂਡ ਸਰਵਰ ਹੁੰਦੇ ਹਨ। ਉਹ ਉਹਨਾਂ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦੇ ਹਨ ਜੋ ਫਰੰਟ ਸਰਵਰ ਗਾਹਕਾਂ ਤੋਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ.

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

ਲੋਡ ਵੰਡ

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

ਮੀਟ੍ਰਿਕ ਸੰਗ੍ਰਹਿ ਅਤੇ ਮੁੜ ਸੰਤੁਲਨ

ਇਹ ਸਮਝਣ ਲਈ ਕਿ ਸਾਨੂੰ ਹਰੇਕ ਸਮੂਹ ਵਿੱਚ ਕਿੰਨੀਆਂ ਕਾਰਾਂ ਦੀ ਲੋੜ ਹੈ, ਅਸੀਂ QPS 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ. ਬੈਕਐਂਡ ਵੱਖਰੇ ਹਨ, ਉਹਨਾਂ ਦੀਆਂ ਵੱਖੋ-ਵੱਖਰੀਆਂ ਬੇਨਤੀਆਂ ਹਨ, ਹਰੇਕ ਬੇਨਤੀ ਦੀ QPS ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਵੱਖਰੀ ਗੁੰਝਲਤਾ ਹੈ। ਇਸ ਲਈ ਅਸੀਂ ਅਸੀਂ ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਰਵਰ 'ਤੇ ਲੋਡ ਦੀ ਧਾਰਨਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ - CPU ਅਤੇ perf 'ਤੇ.

ਸਾਡੇ ਕੋਲ ਅਜਿਹੇ ਹਜ਼ਾਰਾਂ ਸਰਵਰ ਹਨ। ਹਰੇਕ ਭੌਤਿਕ ਸਰਵਰ ਸਾਰੇ ਕੋਰਾਂ ਨੂੰ ਰੀਸਾਈਕਲ ਕਰਨ ਲਈ ਇੱਕ kPHP ਸਮੂਹ ਚਲਾਉਂਦਾ ਹੈ (ਕਿਉਂਕਿ kPHP ਸਿੰਗਲ ਥਰਿੱਡਡ ਹੈ)।

ਸਮੱਗਰੀ ਸਰਵਰ

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

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

pu/pp

ਜੇਕਰ ਤੁਸੀਂ VK ਵਿੱਚ ਨੈੱਟਵਰਕ ਟੈਬ ਖੋਲ੍ਹਿਆ ਹੈ, ਤਾਂ ਤੁਸੀਂ pu/pp ਦੇਖਿਆ ਹੈ।

pu/pp ਕੀ ਹੈ? ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਤੋਂ ਬਾਅਦ ਇੱਕ ਸਰਵਰ ਨੂੰ ਬੰਦ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਬੰਦ ਕੀਤੇ ਸਰਵਰ 'ਤੇ ਇੱਕ ਫਾਈਲ ਨੂੰ ਅੱਪਲੋਡ ਕਰਨ ਅਤੇ ਡਾਊਨਲੋਡ ਕਰਨ ਲਈ ਦੋ ਵਿਕਲਪ ਹਨ: ਸਿੱਧਾ ਦੁਆਰਾ http://cs100500.userapi.com/path ਜ ਵਿਚਕਾਰਲੇ ਸਰਵਰ ਦੁਆਰਾ - http://pu.vk.com/c100500/path.

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

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

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

ਸ਼ੇਅਰ ਕੀਤੇ IPs ਉੱਤੇ ਲਚਕਤਾ. ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦੇ ਸੰਦਰਭ ਵਿੱਚ, ਸਕੀਮ ਉਹੀ ਕੰਮ ਕਰਦੀ ਹੈ - ਕਈ ਭੌਤਿਕ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਸਾਂਝਾ ਭੌਤਿਕ IP ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਾਹਮਣੇ ਹਾਰਡਵੇਅਰ ਇਹ ਚੁਣਦਾ ਹੈ ਕਿ ਬੇਨਤੀ ਕਿੱਥੇ ਭੇਜਣੀ ਹੈ। ਮੈਂ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਵਿਕਲਪਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ।

ਵਿਵਾਦਪੂਰਨ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਗਾਹਕ ਘੱਟ ਕੁਨੈਕਸ਼ਨ ਰੱਖਦਾ ਹੈ. ਜੇਕਰ ਕਈ ਮਸ਼ੀਨਾਂ ਲਈ ਇੱਕੋ IP ਹੈ - ਇੱਕੋ ਹੋਸਟ ਦੇ ਨਾਲ: pu.vk.com ਜਾਂ pp.vk.com, ਕਲਾਇੰਟ ਬ੍ਰਾਊਜ਼ਰ ਕੋਲ ਇੱਕ ਹੋਸਟ ਲਈ ਇੱਕੋ ਸਮੇਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਦੀ ਸੀਮਾ ਹੁੰਦੀ ਹੈ। ਪਰ ਸਰਵ ਵਿਆਪਕ HTTP/2 ਦੇ ਸਮੇਂ ਵਿੱਚ, ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਇਹ ਹੁਣ ਇੰਨਾ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ.

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

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

ਸੂਰਜ

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

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

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

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

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

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

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

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

ਅੰਦਰੋਂ ਸੂਰਜ

nginx 'ਤੇ ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ, ਕੈਸ਼ ਜਾਂ ਤਾਂ RAM ਵਿੱਚ ਜਾਂ ਤੇਜ਼ Optane/NVMe ਡਿਸਕਾਂ 'ਤੇ। ਉਦਾਹਰਨ: http://sun4-2.userapi.com/c100500/path — “ਸੂਰਜ” ਲਈ ਇੱਕ ਲਿੰਕ, ਜੋ ਕਿ ਚੌਥੇ ਖੇਤਰ ਵਿੱਚ ਸਥਿਤ ਹੈ, ਦੂਜਾ ਸਰਵਰ ਸਮੂਹ। ਇਹ ਪਾਥ ਫਾਈਲ ਨੂੰ ਬੰਦ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਸਰਵਰ 100500 'ਤੇ ਭੌਤਿਕ ਤੌਰ 'ਤੇ ਪਿਆ ਹੈ।

ਕਵਰ

ਅਸੀਂ ਆਪਣੀ ਆਰਕੀਟੈਕਚਰਲ ਸਕੀਮ ਵਿੱਚ ਇੱਕ ਹੋਰ ਨੋਡ ਜੋੜਦੇ ਹਾਂ - ਕੈਚਿੰਗ ਵਾਤਾਵਰਣ।

ਹੇਠਾਂ ਖਾਕਾ ਚਿੱਤਰ ਹੈ ਖੇਤਰੀ ਕੈਸ਼, ਉਹਨਾਂ ਵਿੱਚੋਂ ਲਗਭਗ 20 ਹਨ। ਇਹ ਉਹ ਥਾਂਵਾਂ ਹਨ ਜਿੱਥੇ ਕੈਚ ਅਤੇ "ਸੂਰਜ" ਸਥਿਤ ਹਨ, ਜੋ ਆਪਣੇ ਆਪ ਦੁਆਰਾ ਆਵਾਜਾਈ ਨੂੰ ਕੈਚ ਕਰ ਸਕਦੇ ਹਨ।

ਇਹ ਮਲਟੀਮੀਡੀਆ ਸਮੱਗਰੀ ਦੀ ਕੈਚਿੰਗ ਹੈ; ਇੱਥੇ ਕੋਈ ਉਪਭੋਗਤਾ ਡੇਟਾ ਸਟੋਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ - ਸਿਰਫ਼ ਸੰਗੀਤ, ਵੀਡੀਓ, ਫੋਟੋਆਂ।

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

ਇਸ ਨੂੰ ਕੰਮ ਕਰਦਾ ਹੈ?

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

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

ਇਸ ਕੇਸ ਵਿੱਚ ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ ਸਮੱਗਰੀ ਉਪਭੋਗਤਾਵਾਂ ਦੇ ਨੇੜੇ ਅਤੇ ਨੈੱਟਵਰਕ ਲੋਡ ਨੂੰ ਫੈਲਾਉਣਾ। ਉਦਾਹਰਨ ਲਈ, ਸਿਰਫ਼ ਮਾਸਕੋ ਕੈਸ਼ ਤੋਂ ਅਸੀਂ ਪੀਕ ਘੰਟਿਆਂ ਦੌਰਾਨ 1 Tbit/s ਤੋਂ ਵੱਧ ਵੰਡਦੇ ਹਾਂ।

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

ਅਸੀਂ ਆਮ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੇਖਿਆ.

• ਫਰੰਟ ਸਰਵਰ ਜੋ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ।
• ਬੈਕਐਂਡ ਕਰਦਾ ਹੈ ਜੋ ਬੇਨਤੀਆਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ।
• ਸਟੋਰੇਜ ਜੋ ਦੋ ਕਿਸਮਾਂ ਦੇ ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਬੰਦ ਕੀਤੇ ਗਏ ਹਨ।
• ਖੇਤਰੀ ਕੈਸ਼।

ਇਸ ਚਿੱਤਰ ਵਿੱਚ ਕੀ ਗੁੰਮ ਹੈ? ਬੇਸ਼ੱਕ, ਡੇਟਾਬੇਸ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਡੇਟਾ ਸਟੋਰ ਕਰਦੇ ਹਾਂ.

ਡਾਟਾਬੇਸ ਜਾਂ ਇੰਜਣ

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

ਇਹ ਇੱਕ ਜ਼ਰੂਰੀ ਉਪਾਅ ਹੈ. ਇਹ ਇਸ ਲਈ ਹੋਇਆ ਕਿਉਂਕਿ 2008-2009 ਵਿੱਚ, ਜਦੋਂ VK ਦੀ ਪ੍ਰਸਿੱਧੀ ਵਿੱਚ ਵਿਸਫੋਟਕ ਵਾਧਾ ਹੋਇਆ ਸੀ, ਪ੍ਰੋਜੈਕਟ ਪੂਰੀ ਤਰ੍ਹਾਂ MySQL ਅਤੇ Memcache 'ਤੇ ਕੰਮ ਕਰਦਾ ਸੀ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਸਨ। MySQL ਕ੍ਰੈਸ਼ ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਖਰਾਬ ਕਰਨਾ ਪਸੰਦ ਕਰਦਾ ਸੀ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਇਹ ਠੀਕ ਨਹੀਂ ਹੋਏਗਾ, ਅਤੇ ਮੈਮਕੈਸ਼ ਹੌਲੀ-ਹੌਲੀ ਕਾਰਗੁਜ਼ਾਰੀ ਵਿੱਚ ਘਟਿਆ ਅਤੇ ਮੁੜ ਚਾਲੂ ਕਰਨਾ ਪਿਆ।

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

ਹੱਲ ਸਫਲ ਰਿਹਾ. ਅਜਿਹਾ ਕਰਨ ਦਾ ਇੱਕ ਮੌਕਾ ਸੀ, ਅਤੇ ਨਾਲ ਹੀ ਇੱਕ ਅਤਿ ਲੋੜ ਵੀ, ਕਿਉਂਕਿ ਉਸ ਸਮੇਂ ਸਕੇਲਿੰਗ ਦੇ ਹੋਰ ਤਰੀਕੇ ਮੌਜੂਦ ਨਹੀਂ ਸਨ। ਇੱਥੇ ਡੇਟਾਬੇਸ ਦਾ ਇੱਕ ਸਮੂਹ ਨਹੀਂ ਸੀ, NoSQL ਅਜੇ ਮੌਜੂਦ ਨਹੀਂ ਸੀ, ਇੱਥੇ ਸਿਰਫ MySQL, Memcache, PostrgreSQL ਸਨ - ਅਤੇ ਇਹ ਹੀ ਹੈ।

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

ਇੰਜਣਾਂ ਦੀਆਂ ਕਿਸਮਾਂ

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

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

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

ਕਲੱਸਟਰ

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

ਕੋਡ ਨੂੰ ਭੌਤਿਕ ਸਥਿਤੀ, ਆਕਾਰ, ਜਾਂ ਸਰਵਰਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਉਹ ਇੱਕ ਖਾਸ ਪਛਾਣਕਰਤਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਲੱਸਟਰ ਵਿੱਚ ਜਾਂਦਾ ਹੈ।

ਇਸ ਦੇ ਕੰਮ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ ਹੋਰ ਇਕਾਈ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ ਜੋ ਕੋਡ ਅਤੇ ਇੰਜਣਾਂ ਦੇ ਵਿਚਕਾਰ ਸਥਿਤ ਹੈ - ਪ੍ਰੌਕਸੀ.

RPC ਪ੍ਰੌਕਸੀ

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

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

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

ਖਾਸ ਲਾਗੂਕਰਨ

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

MySQL ਲਈ, ਜੋ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਇੱਥੇ ਅਤੇ ਉੱਥੇ ਹੈ, ਅਸੀਂ db-proxy ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ClickHouse ਲਈ - Kittenhouse.

ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇੱਕ ਖਾਸ ਸਰਵਰ ਹੈ, ਇਹ kPHP, Go, Python ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ - ਆਮ ਤੌਰ 'ਤੇ, ਕੋਈ ਵੀ ਕੋਡ ਜੋ ਸਾਡੇ RPC ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਕੋਡ ਇੱਕ RPC ਪ੍ਰੌਕਸੀ 'ਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਚੱਲਦਾ ਹੈ - ਹਰੇਕ ਸਰਵਰ ਜਿੱਥੇ ਕੋਡ ਸਥਿਤ ਹੈ, ਆਪਣੀ ਸਥਾਨਕ ਪ੍ਰੌਕਸੀ ਚਲਾਉਂਦਾ ਹੈ। ਬੇਨਤੀ ਕਰਨ 'ਤੇ, ਪ੍ਰੌਕਸੀ ਸਮਝਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਜਾਣਾ ਹੈ।

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

ਇੱਕ TL-ਸਕੀਮ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜਿਸ ਦੇ ਅਨੁਸਾਰ ਸਾਰੇ ਇੰਜਣ ਕੰਮ ਕਰਦੇ ਹਨ.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

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

TCP/UDP ਉੱਤੇ TL ਉੱਤੇ RPC… UDP?

ਸਾਡੇ ਕੋਲ ਇੰਜਨ ਬੇਨਤੀਆਂ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ RPC ਪ੍ਰੋਟੋਕੋਲ ਹੈ ਜੋ TL ਸਕੀਮ ਦੇ ਸਿਖਰ 'ਤੇ ਚੱਲਦਾ ਹੈ। ਇਹ ਸਭ ਇੱਕ TCP/UDP ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। TCP ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਸਾਨੂੰ ਅਕਸਰ UDP ਦੀ ਕਿਉਂ ਲੋੜ ਹੁੰਦੀ ਹੈ?

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

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

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

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

ਸਥਾਈ ਡਾਟਾ ਸਟੋਰੇਜ਼

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

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

ਮੈਂ ਤੇਜ਼ੀ ਨਾਲ ਕਾਰਵਾਈ ਦੇ ਸਿਧਾਂਤ ਦਾ ਵਰਣਨ ਕਰਾਂਗਾ. ਇੱਕ ਸਰਵਰ ਹੈ ਜਿਸ ਉੱਤੇ ਇੰਜਣ ਚੱਲਦਾ ਹੈ। ਉਹ ਲਿਖਣ ਲਈ ਇੱਕ ਨਵਾਂ ਖਾਲੀ ਬਿਨਲੌਗ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਤਬਦੀਲੀ ਲਈ ਇੱਕ ਇਵੈਂਟ ਲਿਖਦਾ ਹੈ।

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

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

ਉਸ ਸਥਿਤੀ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਜੋ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਣ ਸਮੇਂ ਸੀ ਅਤੇ ਬਿਨਲੌਗ ਦਾ ਆਕਾਰ।

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

ਡਾਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ

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

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

ਜੇ ਤੁਹਾਨੂੰ ਚਾਹੀਦਾ ਹੈ ਰੀਡਿੰਗ ਪ੍ਰਤੀਕ੍ਰਿਤੀCPU ਰੀਡਿੰਗ ਲੋਡ ਨੂੰ ਘਟਾਉਣ ਲਈ, ਰੀਡਿੰਗ ਇੰਜਣ ਨੂੰ ਬਸ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਬਿਨਲੌਗ ਦੇ ਅੰਤ ਨੂੰ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਕਮਾਂਡਾਂ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਚਲਾਉਂਦਾ ਹੈ।

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

RPC ਪਰਾਕਸੀ ਵਿੱਚ ਡਾਟਾ ਵੰਡਣਾ

ਸ਼ਾਰਡਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ? ਪ੍ਰੌਕਸੀ ਕਿਵੇਂ ਸਮਝਦੀ ਹੈ ਕਿ ਕਿਸ ਕਲੱਸਟਰ ਸ਼ਾਰਡ ਨੂੰ ਭੇਜਣਾ ਹੈ? ਕੋਡ ਇਹ ਨਹੀਂ ਕਹਿੰਦਾ: "15 ਸ਼ਾਰਡਾਂ ਲਈ ਭੇਜੋ!" - ਨਹੀਂ, ਇਹ ਪ੍ਰੌਕਸੀ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸਭ ਤੋਂ ਸਰਲ ਸਕੀਮ ਪਹਿਲੀ ਹੈ - ਬੇਨਤੀ ਵਿੱਚ ਪਹਿਲਾ ਨੰਬਰ।

get(photo100_500) => 100 % N.

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

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

ਜੇ ਅਸੀਂ ਇਸ ਗੱਲ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ ਕਿ ਬੇਨਤੀਆਂ ਨੂੰ ਸਮੂਹ ਵਿੱਚ ਕਿਵੇਂ ਫੈਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇੱਕ ਹੋਰ ਵਿਕਲਪ ਹੈ - ਪੂਰੇ ਸ਼ਾਰਡ ਨੂੰ ਹੈਸ਼ ਕਰਨਾ.

hash(photo100_500) => 3539886280 % N

ਸਾਨੂੰ ਹੈਸ਼, ਭਾਗ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਅਤੇ ਸ਼ਾਰਡ ਨੰਬਰ ਵੀ ਮਿਲਦਾ ਹੈ।

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

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

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

ਲਾਗ

ਅਸੀਂ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਲੌਗ ਲਿਖਦੇ ਹਾਂ। ਸਭ ਤੋਂ ਸਪੱਸ਼ਟ ਅਤੇ ਸਧਾਰਨ ਹੈ memcache ਵਿੱਚ ਲਾਗ ਲਿਖੋ.

ring-buffer: prefix.idx = line

ਇੱਥੇ ਇੱਕ ਮੁੱਖ ਅਗੇਤਰ ਹੈ - ਲੌਗ ਦਾ ਨਾਮ, ਇੱਕ ਲਾਈਨ, ਅਤੇ ਇਸ ਲੌਗ ਦਾ ਆਕਾਰ ਹੈ - ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ। ਅਸੀਂ 0 ਤੋਂ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ ਘਟਾਓ 1 ਤੱਕ ਇੱਕ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਲੈਂਦੇ ਹਾਂ। ਮੇਮਕੈਸ਼ ਵਿੱਚ ਕੁੰਜੀ ਇੱਕ ਅਗੇਤਰ ਹੈ ਜੋ ਇਸ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ। ਅਸੀਂ ਲੌਗ ਲਾਈਨ ਅਤੇ ਮੌਜੂਦਾ ਸਮੇਂ ਨੂੰ ਮੁੱਲ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕਰਦੇ ਹਾਂ।

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

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

ਇੰਜਣ ਬਹੁਤ ਪੁਰਾਣਾ ਹੈ, ਇੱਥੇ ਕਲੱਸਟਰ ਹਨ ਜੋ ਪਹਿਲਾਂ ਹੀ 6-7 ਸਾਲ ਪੁਰਾਣੇ ਹਨ. ਇਸਦੇ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹਨ ਜੋ ਅਸੀਂ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਲਾਗਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕਲਿਕਹਾਊਸ ਨੂੰ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਹੈ.

ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਲੌਗ ਇਕੱਠੇ ਕਰਨਾ

ਇਹ ਚਿੱਤਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਇੰਜਣਾਂ ਵਿੱਚ ਕਿਵੇਂ ਚੱਲਦੇ ਹਾਂ।

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

• ਕਲਿਕਹਾਊਸ ਨਾਲ ਕੁਝ ਇੰਜਣ ਨੂੰ ਬਦਲੋ;
• RPC ਪ੍ਰੌਕਸੀ ਨੂੰ ਬਦਲੋ, ਜੋ ਕਿ ਕਲਿਕਹਾਊਸ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਕੁਝ ਹੱਲ ਦੇ ਨਾਲ, ਅਤੇ RPC ਰਾਹੀਂ।

ਇੰਜਣ ਸਧਾਰਨ ਹੈ - ਅਸੀਂ ਇਸਨੂੰ ਸਰਵਰ ਜਾਂ ਕਲਿਕਹਾਊਸ ਦੇ ਨਾਲ ਸਰਵਰਾਂ ਦੇ ਸਮੂਹ ਨਾਲ ਬਦਲਦੇ ਹਾਂ।

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

ਕਈ ਵਾਰ ਅਸੀਂ RPC ਸਕੀਮ ਨੂੰ ਗੈਰ-ਮਿਆਰੀ ਹੱਲਾਂ ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ, ਉਦਾਹਰਨ ਲਈ, nginx ਵਿੱਚ। ਇਸ ਲਈ, KittenHouse ਕੋਲ UDP ਰਾਹੀਂ ਲੌਗ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ।

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

ਨਿਗਰਾਨੀ

ਸਾਡੇ ਕੋਲ ਦੋ ਕਿਸਮਾਂ ਦੇ ਲੌਗ ਹਨ: ਉਹ ਜੋ ਪ੍ਰਸ਼ਾਸਕਾਂ ਦੁਆਰਾ ਉਹਨਾਂ ਦੇ ਸਰਵਰਾਂ 'ਤੇ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਜੋ ਕੋਡ ਤੋਂ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਹਨ। ਉਹ ਦੋ ਕਿਸਮਾਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ: ਸਿਸਟਮ ਅਤੇ ਉਤਪਾਦ.

ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ

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

ਉਤਪਾਦ ਮਾਪਕ

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

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

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

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

ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਅਸੀਂ ਲੌਗ-ਕਲੈਕਟਰਾਂ ਨੂੰ ਸਿੱਧਾ ਲਿਖ ਸਕਦੇ ਹਾਂ।

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

ਅੱਗੇ, ਲੌਗ-ਕਲੈਕਟਰ ਅੰਕੜਿਆਂ ਨੂੰ ਇਸ ਵਿੱਚ ਮਿਲਾਉਂਦੇ ਹਨ meowDB - ਇਹ ਸਾਡਾ ਡੇਟਾਬੇਸ ਹੈ, ਜੋ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਵੀ ਸਟੋਰ ਕਰ ਸਕਦਾ ਹੈ।

ਫਿਰ ਅਸੀਂ ਕੋਡ ਤੋਂ ਬਾਈਨਰੀ "ਨੀਅਰ-SQL" ਚੋਣ ਕਰ ਸਕਦੇ ਹਾਂ।

ਪ੍ਰਯੋਗ

2018 ਦੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਅੰਦਰੂਨੀ ਹੈਕਾਥਨ ਸੀ, ਅਤੇ ਇਹ ਵਿਚਾਰ ਆਇਆ ਕਿ ਚਿੱਤਰ ਦੇ ਲਾਲ ਹਿੱਸੇ ਨੂੰ ਕਿਸੇ ਅਜਿਹੀ ਚੀਜ਼ ਨਾਲ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਵੇ ਜੋ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਮੈਟ੍ਰਿਕਸ ਸਟੋਰ ਕਰ ਸਕੇ। ਸਾਡੇ ਕੋਲ ਕਲਿਕਹਾਊਸ 'ਤੇ ਲੌਗਸ ਹਨ - ਕਿਉਂ ਨਾ ਇਸਨੂੰ ਅਜ਼ਮਾਓ?

ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਕੀਮ ਸੀ ਜਿਸ ਵਿੱਚ KittenHouse ਦੁਆਰਾ ਲੌਗ ਲਿਖੇ ਗਏ ਸਨ।

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

memcache, stats-deemon ਅਤੇ logs-colectors ਡੇਟਾਬੇਸ ਵਾਲੀ ਸਕੀਮ ਨੂੰ ਇਸ ਨਾਲ ਬਦਲਿਆ ਗਿਆ ਹੈ।

memcache, stats-deemon ਅਤੇ logs-colectors ਡੇਟਾਬੇਸ ਵਾਲੀ ਸਕੀਮ ਨੂੰ ਇਸ ਨਾਲ ਬਦਲਿਆ ਗਿਆ ਹੈ।

• ਇੱਥੇ ਕੋਡ ਤੋਂ ਇੱਕ ਡਿਸਪੈਚ ਹੈ, ਜੋ ਸਟੈਟਸਹਾਊਸ ਵਿੱਚ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਲਿਖਿਆ ਗਿਆ ਹੈ।
• StatsHouse UDP ਮੈਟ੍ਰਿਕਸ ਲਿਖਦਾ ਹੈ, ਜੋ ਪਹਿਲਾਂ ਹੀ SQL ਇਨਸਰਟਸ ਵਿੱਚ ਬਦਲਿਆ ਹੋਇਆ ਹੈ, ਬੈਚਾਂ ਵਿੱਚ KittenHouse ਵਿੱਚ।
• KittenHouse ਉਹਨਾਂ ਨੂੰ ClickHouse ਵਿੱਚ ਭੇਜਦਾ ਹੈ।
• ਜੇਕਰ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ StatsHouse ਨੂੰ ਬਾਈਪਾਸ ਕਰਦੇ ਹੋਏ ਪੜ੍ਹਦੇ ਹਾਂ - ਨਿਯਮਤ SQL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਿੱਧਾ ClickHouse ਤੋਂ।

ਕੀ ਇਹ ਅਜੇ ਵੀ ਹੈ ਪ੍ਰਯੋਗ, ਪਰ ਸਾਨੂੰ ਇਹ ਪਸੰਦ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਨਿਕਲਦਾ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਸਕੀਮ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸ਼ਾਇਦ ਅਸੀਂ ਇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਦਲਾਂਗੇ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਮੈਂ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਉਮੀਦ ਕਰਦਾ ਹਾਂ.

ਸਕੀਮ ਲੋਹਾ ਨਹੀਂ ਬਚਾਉਂਦਾ. ਘੱਟ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੈ, ਸਥਾਨਕ ਸਟੈਟਸ-ਡੈਮਨ ਅਤੇ ਲੌਗਸ-ਕਲੈਕਟਰਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਕਲਿਕਹਾਊਸ ਨੂੰ ਮੌਜੂਦਾ ਸਕੀਮ ਨਾਲੋਂ ਵੱਡੇ ਸਰਵਰ ਦੀ ਲੋੜ ਹੈ। ਘੱਟ ਸਰਵਰਾਂ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਉਹ ਵਧੇਰੇ ਮਹਿੰਗੇ ਅਤੇ ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ.

ਤੈਨਾਤ

ਪਹਿਲਾਂ, ਆਓ PHP ਤੈਨਾਤੀ ਨੂੰ ਵੇਖੀਏ. ਅਸੀਂ ਵਿੱਚ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹਾਂ Git: ਵਰਤੋਂ GitLab и ਟੀਮਸਿਟੀ ਤਾਇਨਾਤੀ ਲਈ. ਵਿਕਾਸ ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਟੈਸਟਿੰਗ ਲਈ ਮਾਸਟਰ ਤੋਂ ਉਹਨਾਂ ਨੂੰ ਸਟੇਜਿੰਗ ਵਿੱਚ, ਅਤੇ ਸਟੇਜਿੰਗ ਤੋਂ ਉਤਪਾਦਨ ਵਿੱਚ ਮਿਲਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

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

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

ਸਾਡੇ ਇੰਜਣਾਂ ਲਈ, ਜੋ ਕਿ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਬਾਈਨਰੀ ਵੀ ਹਨ, ਸਕੀਮ ਬਹੁਤ ਸਮਾਨ ਹੈ:

• git ਮਾਸਟਰ ਸ਼ਾਖਾ;
• ਵਿੱਚ ਬਾਈਨਰੀ .deb;
• ਸੰਸਕਰਣ ਬਿਨਲੌਗ ਕਾਪੀਫਾਸਟ ਲਈ ਲਿਖਿਆ ਗਿਆ ਹੈ;
• ਸਰਵਰਾਂ ਤੇ ਨਕਲ;
• ਸਰਵਰ ਇੱਕ ਤਾਜ਼ਾ .dep ਕੱਢਦਾ ਹੈ;
• dpkg -i;
• ਨਵੇਂ ਸੰਸਕਰਣ ਲਈ ਸ਼ਾਨਦਾਰ ਰੀਲਾਂਚ.

ਫਰਕ ਇਹ ਹੈ ਕਿ ਸਾਡੀ ਬਾਈਨਰੀ ਪੁਰਾਲੇਖਾਂ ਵਿੱਚ ਪੈਕ ਕੀਤੀ ਗਈ ਹੈ .deb, ਅਤੇ ਜਦੋਂ ਉਹ ਬਾਹਰ ਕੱਢਦੇ ਹਨ dpkg -i ਸਿਸਟਮ 'ਤੇ ਰੱਖੇ ਗਏ ਹਨ। ਕੇਪੀਐਚਪੀ ਨੂੰ ਬਾਈਨਰੀ ਵਜੋਂ ਕਿਉਂ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੰਜਣਾਂ ਨੂੰ dpkg ਵਜੋਂ ਤੈਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਹੋਇਆ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ - ਇਸਨੂੰ ਨਾ ਛੂਹੋ।

ਉਪਯੋਗੀ ਲਿੰਕ:

• ਐਂਟਨ ਕਿਰੀਯੁਸ਼ਕਿਨ ਦੁਆਰਾ ਰਿਪੋਰਟ "Vkontakte ਸਿਸਟਮ ਪ੍ਰਬੰਧਕ। ਕਿਵੇਂ?" ਕਾਪੀਫਾਸਟ ਅਤੇ ਗੱਪਾਂ ਬਾਰੇ ਵੇਰਵਿਆਂ ਦੇ ਨਾਲ।
• ਯੂਰੀ ਨਸਰੇਟਡੀਨੋਵ ਦੁਆਰਾ ਰਿਪੋਰਟ "ਕਿਵੇਂ VK ਹਜ਼ਾਰਾਂ ਸਰਵਰਾਂ ਤੋਂ ਕਲਿਕਹਾਊਸ ਵਿੱਚ ਡੇਟਾ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ".
• ਮੇਰੀ ਰਿਪੋਰਟ "VKontakte ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਵਧ ਰਹੇ ਪ੍ਰੋਜੈਕਟ ਦਾ ਆਰਕੀਟੈਕਚਰ", ਪਰ ਵਿਕਾਸ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਹਾਰਡਵੇਅਰ ਨਹੀਂ।

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

ਸਰੋਤ: www.habr.com