Badoo ਵਿੱਚ ਫੋਟੋਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਸਾਂਝਾ ਕਰਨ ਲਈ ਆਰਕੀਟੈਕਚਰ

ਆਰਟੇਮ ਡੇਨੀਸੋਵ ( bo0rsh201, Badoo)

Badoo ਦੁਨੀਆ ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਡੇਟਿੰਗ ਸਾਈਟ ਹੈ। ਸਾਡੇ ਕੋਲ ਵਰਤਮਾਨ ਵਿੱਚ ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਲਗਭਗ 330 ਮਿਲੀਅਨ ਰਜਿਸਟਰਡ ਉਪਭੋਗਤਾ ਹਨ। ਪਰ ਅੱਜ ਸਾਡੀ ਗੱਲਬਾਤ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਜੋ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਅਸੀਂ ਉਪਭੋਗਤਾ ਦੀਆਂ ਫੋਟੋਆਂ ਦੇ ਲਗਭਗ 3 ਪੇਟਾਬਾਈਟ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਹਰ ਰੋਜ਼ ਸਾਡੇ ਉਪਭੋਗਤਾ ਲਗਭਗ 3,5 ਮਿਲੀਅਨ ਨਵੀਆਂ ਫੋਟੋਆਂ ਅਪਲੋਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੜ੍ਹਨ ਦਾ ਭਾਰ ਲਗਭਗ ਹੈ ਪ੍ਰਤੀ ਸਕਿੰਟ 80 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ. ਇਹ ਸਾਡੇ ਬੈਕਐਂਡ ਲਈ ਕਾਫ਼ੀ ਹੈ, ਅਤੇ ਕਈ ਵਾਰ ਇਸ ਨਾਲ ਮੁਸ਼ਕਲਾਂ ਆਉਂਦੀਆਂ ਹਨ।

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

ਹੁਣ ਸ਼ੁਰੂ ਕਰੀਏ.

ਜਿਵੇਂ ਕਿ ਮੈਂ ਕਿਹਾ, ਇਹ ਇੱਕ ਪਿਛਾਖੜੀ ਹੋਵੇਗਾ, ਅਤੇ ਇਸਨੂੰ ਕਿਤੇ ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਆਓ ਸਭ ਤੋਂ ਆਮ ਉਦਾਹਰਣ ਲਈਏ।

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

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

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

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

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

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

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

ਕੁਝ ਸਮਾਂ ਸਾਡੇ ਲਈ ਅਜਿਹਾ ਹੀ ਰਿਹਾ।

ਇਹ 2009 ਦੇ ਆਸ-ਪਾਸ ਦੀ ਗੱਲ ਹੈ। ਉਨ੍ਹਾਂ ਨੇ ਕਾਰਾਂ ਡਿਲੀਵਰ ਕੀਤੀਆਂ, ਡਿਲੀਵਰ ਕੀਤੀਆਂ...

ਅਤੇ ਕਿਸੇ ਸਮੇਂ ਅਸੀਂ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਇਸ ਸਕੀਮ ਦੇ ਕੁਝ ਨੁਕਸਾਨ ਹਨ. ਕੀ ਨੁਕਸਾਨ ਹਨ?

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

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

ਇਹ ਸਭ 2009 ਲਈ ਸੀ, ਪਰ, ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਹ ਲੋੜਾਂ ਅੱਜ ਵੀ ਢੁਕਵੇਂ ਹਨ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਪਿਛਾਖੜੀ ਹੈ, ਇਸ ਲਈ 2009 ਵਿੱਚ ਇਸ ਨਾਲ ਸਭ ਕੁਝ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਰਾਬ ਸੀ।

ਅਤੇ ਆਖਰੀ ਬਿੰਦੂ ਕੀਮਤ ਹੈ.

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

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਅਸੀਂ ਅਖੌਤੀ ਸਟੋਰੇਜ ਏਰੀਆ ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ।

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

ਇਸ ਫੈਸਲੇ ਦੇ ਸਪੱਸ਼ਟ ਫਾਇਦੇ ਸਨ. ਇਹ SHD ਹੈ। ਇਸਦਾ ਉਦੇਸ਼ ਫੋਟੋਆਂ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਹੈ। ਇਹ ਮਸ਼ੀਨਾਂ ਨੂੰ ਹਾਰਡ ਡਰਾਈਵਾਂ ਨਾਲ ਲੈਸ ਕਰਨ ਨਾਲੋਂ ਸਸਤਾ ਕੰਮ ਕਰਦਾ ਹੈ।

ਦੂਜਾ ਪਲੱਸ.

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

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

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

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

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

ਅਤੇ ਇੱਥੇ ਸਭ ਕੁਝ ਸਾਡੇ ਹੱਥਾਂ ਵਿੱਚ ਖੇਡਦਾ ਹੈ.

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

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

ਉਹ. ਸਾਡੇ ਕੋਲ ਬਹੁਤ ਛੋਟਾ ਗਰਮ ਡੇਟਾਸੈਟ ਹੈ। ਪਰ ਉਸੇ ਸਮੇਂ ਉਸ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਹਨ. ਅਤੇ ਇੱਥੇ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੱਸ਼ਟ ਹੱਲ ਹੈ ਇੱਕ ਕੈਸ਼ ਜੋੜਨਾ.

LRU ਨਾਲ ਇੱਕ ਕੈਸ਼ ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਹੱਲ ਕਰੇਗਾ। ਅਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹਾਂ?

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

ਇਹ ਅੰਦਰੋਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ? ਇੱਥੇ ਸਾਡਾ ਉਪਭੋਗਤਾ ਹੈ, ਇੱਥੇ ਸਟੋਰੇਜ ਹੈ. ਸਭ ਕੁਝ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਹੈ। ਅਸੀਂ ਵਿਚਕਾਰ ਕੀ ਜੋੜਦੇ ਹਾਂ?

ਇਹ ਕੇਵਲ ਇੱਕ ਭੌਤਿਕ ਲੋਕਲ ਡਿਸਕ ਵਾਲੀ ਮਸ਼ੀਨ ਹੈ, ਜੋ ਤੇਜ਼ ਹੈ। ਇਹ ਇੱਕ SSD ਨਾਲ ਹੈ, ਉਦਾਹਰਨ ਲਈ। ਅਤੇ ਇਸ ਡਿਸਕ 'ਤੇ ਕੁਝ ਕਿਸਮ ਦਾ ਸਥਾਨਕ ਕੈਸ਼ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਕਿਦੇ ਵਰਗਾ ਦਿਸਦਾ ਹੈ? ਉਪਭੋਗਤਾ ਇੱਕ ਫੋਟੋ ਲਈ ਇੱਕ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ. NGINX ਇਸਨੂੰ ਸਥਾਨਕ ਕੈਸ਼ ਵਿੱਚ ਪਹਿਲਾਂ ਲੱਭਦਾ ਹੈ। ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਸਿਰਫ਼ ਸਾਡੀ ਸਟੋਰੇਜ 'ਤੇ proxy_pass ਕਰੋ, ਉਥੋਂ ਫ਼ੋਟੋ ਡਾਊਨਲੋਡ ਕਰੋ ਅਤੇ ਯੂਜ਼ਰ ਨੂੰ ਦਿਓ।

ਪਰ ਇਹ ਬਹੁਤ ਮਾਮੂਲੀ ਹੈ ਅਤੇ ਇਹ ਅਸਪਸ਼ਟ ਹੈ ਕਿ ਅੰਦਰ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ।

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

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

ਇਸ ਦੇ ਕੰਮ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਕੈਸ਼ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਇਸ ਵਿੱਚ ਫੋਟੋਆਂ ਨੂੰ ਮੁੜ ਵਿਵਸਥਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਆਦਿ। ਇਹ ਵੀ ਇੱਕ ਬਹੁਤ ਹੀ ਮੁੱਢਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।

Nginx ਹਰ ਬੇਨਤੀ ਲਈ RAMDisk access.log ਨੂੰ ਸਿਰਫ਼ ਲਿਖਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਉਸ ਫੋਟੋ ਦੇ ਮਾਰਗ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਇਸ ਨੇ ਵਰਤਮਾਨ ਵਿੱਚ ਸੇਵਾ ਕੀਤੀ ਹੈ (ਰਿਸ਼ਤੇਦਾਰ ਮਾਰਗ, ਬੇਸ਼ਕ), ਅਤੇ ਇਹ ਕਿਹੜਾ ਭਾਗ ਦਿੱਤਾ ਗਿਆ ਸੀ। ਉਹ. ਇਹ "ਫੋਟੋ 1" ਅਤੇ ਫਿਰ ਜਾਂ ਤਾਂ ਇੱਕ ਬਫਰ, ਜਾਂ ਇੱਕ ਗਰਮ ਕੈਸ਼, ਜਾਂ ਇੱਕ ਠੰਡਾ ਕੈਸ਼, ਜਾਂ ਇੱਕ ਪ੍ਰੌਕਸੀ ਕਹਿ ਸਕਦਾ ਹੈ।

ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਫੋਟੋ ਨਾਲ ਕੀ ਕਰਨਾ ਹੈ.

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

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

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

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

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

ਬਾਕੀ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਸਰਵਰਾਂ ਵਿੱਚ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਵੰਡਣਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਇੱਥੇ ਵੀਹ ਸਟੋਰੇਜ ਮਸ਼ੀਨਾਂ ਅਤੇ ਤਿੰਨ ਕੈਚਿੰਗ ਸਰਵਰਾਂ ਦਾ ਇੱਕ ਕਲੱਸਟਰ ਹੈ (ਇਸ ਤਰ੍ਹਾਂ ਹੋਇਆ).

ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਬੇਨਤੀਆਂ ਕਿਹੜੀਆਂ ਫੋਟੋਆਂ ਲਈ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿੱਥੇ ਉਤਾਰਨਾ ਹੈ।

ਸਭ ਤੋਂ ਆਮ ਵਿਕਲਪ ਰਾਊਂਡ ਰੌਬਿਨ ਹੈ। ਜਾਂ ਇਹ ਦੁਰਘਟਨਾ ਦੁਆਰਾ ਕਰਦੇ ਹਨ?

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

ਸਾਨੂੰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਕਿਹੜਾ ਸਰਵਰ ਕਿਸ ਬੇਨਤੀ ਨੂੰ ਲੈਂਡ ਕਰਨਾ ਹੈ।

ਇੱਕ ਆਮ ਤਰੀਕਾ ਹੈ. ਅਸੀਂ URL ਤੋਂ ਹੈਸ਼ ਜਾਂ ਸਾਡੀ ਸ਼ਾਰਡਿੰਗ ਕੁੰਜੀ ਤੋਂ ਹੈਸ਼ ਲੈਂਦੇ ਹਾਂ, ਜੋ ਕਿ URL ਵਿੱਚ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨਾਲ ਵੰਡਦੇ ਹਾਂ। ਕੰਮ ਕਰੇਗਾ? ਕਰੇਗਾ।

ਉਹ. ਸਾਡੇ ਕੋਲ ਇੱਕ 2% ਬੇਨਤੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਕੁਝ "example_url" ਲਈ ਇਹ ਹਮੇਸ਼ਾ ਸੂਚਕਾਂਕ "XNUMX" ਦੇ ਨਾਲ ਸਰਵਰ 'ਤੇ ਲੈਂਡ ਕਰੇਗਾ, ਅਤੇ ਕੈਸ਼ ਨੂੰ ਲਗਾਤਾਰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨਿਪਟਾਇਆ ਜਾਵੇਗਾ।

ਪਰ ਅਜਿਹੀ ਸਕੀਮ ਵਿੱਚ ਰੀ-ਸ਼ਾਰਡਿੰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਮੁੜ-ਸ਼ਾਰਡਿੰਗ - ਮੇਰਾ ਮਤਲਬ ਹੈ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਦਲਣਾ.

ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਸਾਡਾ ਕੈਚਿੰਗ ਕਲੱਸਟਰ ਹੁਣ ਇਸਦਾ ਮੁਕਾਬਲਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਇੱਕ ਹੋਰ ਮਸ਼ੀਨ ਜੋੜਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹਾਂ।

ਆਓ ਜੋੜੀਏ।

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

ਇਹ ਵਿਕਲਪ ਸਾਡੇ ਲਈ ਵੀ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ।

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

ਇਹ ਕਿਦੇ ਵਰਗਾ ਦਿਸਦਾ ਹੈ?

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

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

ਰੀ-ਸ਼ਾਰਡਿੰਗ ਦੌਰਾਨ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ?

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

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

ਸਿਰਫ ਸਵਾਲ ਇਨਕਾਰ ਦੇ ਨਾਲ ਰਹਿੰਦਾ ਹੈ. ਚਲੋ ਮੰਨ ਲਓ ਕਿ ਕਿਸੇ ਕਿਸਮ ਦੀ ਕਾਰ ਆਰਡਰ ਤੋਂ ਬਾਹਰ ਹੈ.

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

ਇਹ ਕੈਚਿੰਗ ਸਿਸਟਮ ਬਾਰੇ ਹੈ। ਆਓ ਨਤੀਜਿਆਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ।

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

ਅਸੀਂ ਇਹਨਾਂ ਸਰਵਰਾਂ ਨੂੰ ਸਾਡੇ ਤਿੰਨ DC ਵਿੱਚ ਰੱਖਿਆ, ਅਤੇ ਮੌਜੂਦਗੀ ਦੇ ਤਿੰਨ ਪੁਆਇੰਟ ਪ੍ਰਾਪਤ ਕੀਤੇ - ਪ੍ਰਾਗ, ਮਿਆਮੀ ਅਤੇ ਹਾਂਗਕਾਂਗ।

ਕਿ. ਉਹ ਸਾਡੇ ਹਰੇਕ ਨਿਸ਼ਾਨਾ ਬਾਜ਼ਾਰ ਵਿੱਚ ਘੱਟ ਜਾਂ ਘੱਟ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਥਿਤ ਹਨ।

ਅਤੇ ਇੱਕ ਵਧੀਆ ਬੋਨਸ ਦੇ ਰੂਪ ਵਿੱਚ, ਸਾਨੂੰ ਇਹ ਕੈਚਿੰਗ ਪ੍ਰੌਕਸੀ ਮਿਲੀ ਹੈ, ਜਿਸ 'ਤੇ CPU ਅਸਲ ਵਿੱਚ ਨਿਸ਼ਕਿਰਿਆ ਹੈ, ਕਿਉਂਕਿ ਸਮੱਗਰੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਅਤੇ ਉੱਥੇ, NGINX+ Lua ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਉਪਯੋਗੀ ਤਰਕ ਲਾਗੂ ਕੀਤੇ।

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

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

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

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

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

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

ਅਤੇ, ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਇੱਕ ਸੂਝਵਾਨ ਸੁਣਨ ਵਾਲੇ ਕੋਲ ਇੱਕ ਸਵਾਲ ਹੋ ਸਕਦਾ ਹੈ: ਕਿਉਂ ਨਾ ਸਿਰਫ਼ ਹਰ ਚੀਜ਼ ਨੂੰ CDN ਵਿੱਚ ਬਦਲੋ? ਇਹ ਇਕੋ ਜਿਹਾ ਹੋਵੇਗਾ; ਸਾਰੇ ਆਧੁਨਿਕ CDN ਇਹ ਕਰ ਸਕਦੇ ਹਨ. ਅਤੇ ਕਈ ਕਾਰਨ ਹਨ।

ਪਹਿਲੀ ਫੋਟੋ ਹੈ.

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

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

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

ਅਤੇ ਬਿੰਦੂ ਜੋ ਪਿਛਲੇ ਇੱਕ ਤੋਂ ਬਾਅਦ ਆਉਂਦਾ ਹੈ

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

ਇਹ ਕਿਸ ਸਿੱਟੇ ਦਾ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ? ਸਾਡੇ ਕੇਸ ਵਿੱਚ, CDN ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਵਿਕਲਪ ਨਹੀਂ ਹੈ.

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

ਪਰ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੁਝ ਕਿਸਮ ਦਾ ਆਮ ਹੱਲ ਹੈ, ਅਤੇ ਕੰਮ ਬਹੁਤ ਖਾਸ ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ CDN ਲੈ ਸਕਦੇ ਹੋ। ਜਾਂ ਜੇ ਸਮਾਂ ਅਤੇ ਸਰੋਤ ਤੁਹਾਡੇ ਲਈ ਨਿਯੰਤਰਣ ਨਾਲੋਂ ਵਧੇਰੇ ਮਹੱਤਵਪੂਰਨ ਹਨ.

ਅਤੇ ਆਧੁਨਿਕ CDN ਕੋਲ ਲਗਭਗ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜਿਸ ਬਾਰੇ ਮੈਂ ਤੁਹਾਨੂੰ ਹੁਣ ਦੱਸਿਆ ਹੈ। ਪਲੱਸ ਜਾਂ ਘਟਾਓ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦੇ ਅਪਵਾਦ ਦੇ ਨਾਲ।

ਇਹ ਫੋਟੋਆਂ ਦੇਣ ਬਾਰੇ ਹੈ।

ਆਓ ਹੁਣ ਆਪਣੇ ਪਿਛੋਕੜ ਵਿੱਚ ਥੋੜਾ ਅੱਗੇ ਵਧੀਏ ਅਤੇ ਸਟੋਰੇਜ ਬਾਰੇ ਗੱਲ ਕਰੀਏ।

2013 ਲੰਘ ਰਿਹਾ ਸੀ।

ਕੈਸ਼ਿੰਗ ਸਰਵਰ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ, ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਦੂਰ ਹੋ ਗਈਆਂ। ਸਭ ਕੁਝ ਠੀਕ ਹੈ. ਡਾਟਾਸੈਟ ਵਧ ਰਿਹਾ ਹੈ। 2013 ਤੱਕ, ਸਾਡੇ ਕੋਲ ਸਟੋਰੇਜ ਨਾਲ ਜੁੜੇ ਲਗਭਗ 80 ਸਰਵਰ ਸਨ, ਅਤੇ ਹਰੇਕ DC ਵਿੱਚ ਲਗਭਗ 40 ਕੈਚਿੰਗ ਵਾਲੇ ਸਨ। ਇਹ ਹਰੇਕ ਡੀਸੀ 'ਤੇ 560 ਟੈਰਾਬਾਈਟ ਡੇਟਾ ਹੈ, ਯਾਨੀ. ਕੁੱਲ ਮਿਲਾ ਕੇ ਇੱਕ ਪੇਟਾਬਾਈਟ ਬਾਰੇ।

ਅਤੇ ਡੇਟਾਸੇਟ ਦੇ ਵਾਧੇ ਦੇ ਨਾਲ, ਓਪਰੇਟਿੰਗ ਲਾਗਤਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਵਾਧਾ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਗਿਆ। ਇਸ ਦਾ ਕੀ ਮਤਲਬ ਸੀ?

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਸਟੋਰੇਜ਼ ਏਰੀਆ ਨੈੱਟਵਰਕ (SAN) ਖੁਦ, ਜੋ ਕਿ ਫੇਲ ਹੋ ਸਕਦਾ ਹੈ।

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

ਬੇਸ਼ੱਕ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਸਾਰੇ ਨਹੀਂ ਹਨ ਜਿੰਨੇ SAN ਦੇ ਨਾਲ ਹਨ, ਪਰ, ਫਿਰ ਵੀ, ਇਹ ਅਸਫਲਤਾ ਦੇ ਬਿੰਦੂ ਵੀ ਹਨ.

ਅੱਗੇ ਮਸ਼ੀਨ ਖੁਦ ਹੈ, ਜੋ ਸਟੋਰੇਜ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ। ਇਹ ਫੇਲ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।

ਕੁੱਲ ਮਿਲਾ ਕੇ, ਸਾਡੇ ਕੋਲ ਅਸਫਲਤਾ ਦੇ ਤਿੰਨ ਅੰਕ ਹਨ.

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸਫਲਤਾ ਦੇ ਬਿੰਦੂਆਂ ਤੋਂ ਇਲਾਵਾ, ਸਟੋਰੇਜ਼ ਦੀ ਭਾਰੀ ਸਾਂਭ-ਸੰਭਾਲ ਹੈ.

ਇਹ ਇੱਕ ਗੁੰਝਲਦਾਰ ਮਲਟੀ-ਕੰਪੋਨੈਂਟ ਸਿਸਟਮ ਹੈ, ਅਤੇ ਸਿਸਟਮ ਇੰਜਨੀਅਰਾਂ ਨੂੰ ਇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ ਔਖਾ ਹੋ ਸਕਦਾ ਹੈ।

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

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

ਇਸ ਬਾਰੇ ਕੁਝ ਕਰਨਾ ਚਾਹੀਦਾ ਸੀ। ਅਤੇ ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਕਿ ਸਾਨੂੰ ਸਿਰਫ਼ ਡਾਟਾ ਬੈਕਅੱਪ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇਹ ਅਸਲ ਵਿੱਚ ਇੱਕ ਸਪੱਸ਼ਟ ਹੱਲ ਹੈ ਅਤੇ ਇੱਕ ਚੰਗਾ ਹੈ. ਅਸੀਂ ਕੀ ਕੀਤਾ ਹੈ?

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

ਅਸੀਂ ਹੁਣੇ ਇੱਕ ਦੂਜਾ ਭਾਗ ਜੋੜਿਆ ਹੈ।

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

ਇੱਥੇ ਅਸੀਂ ਨੇੜੇ ਹੀ ਇੱਕ ਅਸਿੰਕਰੋਨਸ ਕਤਾਰ ਬਣਾਉਂਦੇ ਹਾਂ।

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

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

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

ਅਤੇ ਅਸੀਂ ਇੱਕ ਤੀਜੀ ਡਿਸਕ ਜੋੜੀ, ਜੋ ਕਿ ਇੱਕ ਛੋਟੀ SSD ਹੈ, ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਬਫਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਇਹ ਹੁਣ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

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

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

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

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

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

ਦੂਸਰਾ, ਅਜੇ ਵੀ SANs ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਉਹਨਾਂ ਦੀ ਭਾਰੀ ਸਾਂਭ-ਸੰਭਾਲ ਆਦਿ ਬਾਕੀ ਹਨ. ਇਹ ਨਹੀਂ ਸੀ ਕਿ ਇਹ ਇੱਕ ਨਾਜ਼ੁਕ ਕਾਰਕ ਸੀ, ਪਰ ਮੈਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕਿਸੇ ਤਰ੍ਹਾਂ ਜੀਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਚਾਹੁੰਦਾ ਸੀ.

ਅਤੇ ਅਸੀਂ ਤੀਜਾ ਸੰਸਕਰਣ ਬਣਾਇਆ (ਅਸਲ ਵਿੱਚ, ਅਸਲ ਵਿੱਚ ਦੂਜਾ) - ਰਿਜ਼ਰਵੇਸ਼ਨ ਸੰਸਕਰਣ. ਇਹ ਕਿਹੋ ਜਿਹਾ ਲੱਗਿਆ?

ਇਹ ਉਹ ਹੈ ਜੋ ਇਹ ਸੀ -

ਸਾਡੀਆਂ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਇਸ ਤੱਥ ਨਾਲ ਹਨ ਕਿ ਇਹ ਇੱਕ ਭੌਤਿਕ ਮੇਜ਼ਬਾਨ ਹੈ.

ਪਹਿਲਾਂ, ਅਸੀਂ SAN ਨੂੰ ਹਟਾ ਰਹੇ ਹਾਂ ਕਿਉਂਕਿ ਅਸੀਂ ਪ੍ਰਯੋਗ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਅਸੀਂ ਸਿਰਫ਼ ਸਥਾਨਕ ਹਾਰਡ ਡਰਾਈਵਾਂ ਨੂੰ ਅਜ਼ਮਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ।

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਸਾਨੂੰ ਇਹ ਚਿੱਤਰ ਮਿਲਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਦੋ ਕਾਰਾਂ ਹਨ ਜੋ ਇੱਕੋ ਜਿਹੇ ਡੇਟਾਸੈਟਾਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਇੱਕ ਦੂਜੇ ਦਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੈਕਅੱਪ ਲੈਂਦੇ ਹਨ ਅਤੇ ਉਸੇ MySQL ਵਿੱਚ ਇੱਕ ਅਸਿੰਕਰੋਨਸ ਕਤਾਰ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਉੱਤੇ ਡੇਟਾ ਨੂੰ ਸਮਕਾਲੀ ਕਰਦੇ ਹਨ।

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

ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੇ ਤੁਸੀਂ ਥੋੜਾ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਵੇਖਦੇ ਹੋ.

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

ਕੰਮ ਥੋੜਾ ਹੋਰ ਔਖਾ ਹੈ।

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

ਜੇਕਰ ਇਹ ਉੱਥੇ ਨਹੀਂ ਹੈ, ਤਾਂ ਅਸੀਂ ਸਿਰਫ਼ ਆਪਣੇ ਗੁਆਂਢੀ ਨੂੰ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸ ਨੂੰ ਉੱਥੋਂ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਗਾਰੰਟੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

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

ਸਾਡੀ ਸਥਿਤੀ ਵਿੱਚ, ਇਹ ਹੌਲੀ ਹੌਲੀ ਕੰਮ ਨਹੀਂ ਕਰਦਾ.

ਅਸੀਂ ਇਸ ਸਿਸਟਮ 'ਤੇ ਮੈਟ੍ਰਿਕਸ ਦਾ ਇੱਕ ਸਮੂਹ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਅਜਿਹੀ ਵਿਧੀ ਦੀ ਕੰਡੀਸ਼ਨਲ ਸਮਾਰਟ ਰੇਟ ਲਗਭਗ 95% ਹੈ। ਉਹ. ਇਸ ਬੈਕਅਪ ਦਾ ਲੇਗ ਛੋਟਾ ਹੈ, ਅਤੇ ਇਸ ਕਾਰਨ ਅਸੀਂ ਲਗਭਗ ਗਾਰੰਟੀ ਦੇ ਰਹੇ ਹਾਂ, ਫੋਟੋ ਅਪਲੋਡ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਇਸਨੂੰ ਪਹਿਲੀ ਵਾਰ ਲਵਾਂਗੇ ਅਤੇ ਦੋ ਵਾਰ ਕਿਤੇ ਵੀ ਨਹੀਂ ਜਾਣਾ ਪਵੇਗਾ।

ਤਾਂ ਸਾਡੇ ਕੋਲ ਹੋਰ ਕੀ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਵਧੀਆ ਹੈ?

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

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

ਜਿਵੇਂ ਕਿ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਲਈ. ਅਸਲ ਵਿੱਚ, ਇਹ ਉਹ ਹੈ ਜਿਸ ਲਈ ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੜਦੇ ਹਾਂ। ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਦੇ ਨਾਲ, ਇੱਥੇ ਸਭ ਕੁਝ ਵਧੀਆ ਨਿਕਲਿਆ.

ਇੱਕ ਕਾਰ ਟੁੱਟ ਜਾਂਦੀ ਹੈ।

ਕੋਈ ਸਮੱਸਿਆ ਨਹੀ! ਇੱਕ ਸਿਸਟਮ ਇੰਜੀਨੀਅਰ ਰਾਤ ਨੂੰ ਵੀ ਨਹੀਂ ਜਾਗ ਸਕਦਾ, ਉਹ ਸਵੇਰ ਤੱਕ ਉਡੀਕ ਕਰੇਗਾ, ਕੁਝ ਵੀ ਬੁਰਾ ਨਹੀਂ ਹੋਵੇਗਾ.

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

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

ਇਸ ਰਿਡੰਡੈਂਸੀ ਸਕੀਮ ਤੋਂ ਕਿਹੜੇ ਸਿੱਟੇ ਕੱਢੇ ਜਾ ਸਕਦੇ ਹਨ?

ਸਾਨੂੰ ਗਲਤੀ ਸਹਿਣਸ਼ੀਲਤਾ ਮਿਲੀ ਹੈ।

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

ਸਾਨੂੰ ਡਬਲ ਰੀਡਿੰਗ ਭੱਤਾ ਮਿਲਿਆ।

ਇਹ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਤੋਂ ਇਲਾਵਾ ਇੱਕ ਬਹੁਤ ਵਧੀਆ ਬੋਨਸ ਹੈ।

ਪਰ ਸਮੱਸਿਆਵਾਂ ਵੀ ਹਨ। ਹੁਣ ਸਾਡੇ ਕੋਲ ਇਸ ਨਾਲ ਸਬੰਧਤ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਵਿਕਾਸ ਹੈ, ਕਿਉਂਕਿ ਸਿਸਟਮ 100% ਆਖ਼ਰਕਾਰ ਇਕਸਾਰ ਹੋ ਗਿਆ ਹੈ।

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

ਅਤੇ ਇੱਥੇ ਦੁਬਾਰਾ ਕੁਝ ਵਿਵਾਦ ਪੈਦਾ ਹੁੰਦਾ ਹੈ.

ਮੈਂ ਸ਼ੁਰੂ ਵਿਚ ਕਿਹਾ ਸੀ ਕਿ ਸਥਾਨਕ ਹਾਰਡ ਡਰਾਈਵਾਂ 'ਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਸਟੋਰ ਕਰਨਾ ਬੁਰਾ ਹੈ. ਅਤੇ ਹੁਣ ਮੈਂ ਕਹਿੰਦਾ ਹਾਂ ਕਿ ਸਾਨੂੰ ਇਹ ਪਸੰਦ ਆਇਆ.

ਹਾਂ, ਸੱਚਮੁੱਚ, ਸਮੇਂ ਦੇ ਨਾਲ ਸਥਿਤੀ ਬਹੁਤ ਬਦਲ ਗਈ ਹੈ, ਅਤੇ ਹੁਣ ਇਸ ਪਹੁੰਚ ਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ. ਪਹਿਲਾਂ, ਸਾਨੂੰ ਬਹੁਤ ਸਰਲ ਓਪਰੇਸ਼ਨ ਮਿਲਦਾ ਹੈ।

ਦੂਜਾ, ਇਹ ਵਧੇਰੇ ਲਾਭਕਾਰੀ ਹੈ, ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇਹ ਆਟੋਮੈਟਿਕ ਕੰਟਰੋਲਰ ਜਾਂ ਡਿਸਕ ਸ਼ੈਲਫਾਂ ਨਾਲ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹਨ।

ਉੱਥੇ ਮਸ਼ੀਨਰੀ ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਹੈ, ਅਤੇ ਇਹ ਸਿਰਫ ਕੁਝ ਡਿਸਕ ਹਨ ਜੋ ਇੱਥੇ ਇੱਕ ਛਾਪੇ ਵਿੱਚ ਮਸ਼ੀਨ 'ਤੇ ਇਕੱਠੇ ਕੀਤੇ ਗਏ ਹਨ.

ਪਰ ਨੁਕਸਾਨ ਵੀ ਹਨ.

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

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

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

ਆਉ ਅਸੀਂ ਕੀ ਪੂਰਾ ਕੀਤਾ, ਅਸੀਂ ਕਿਸ ਲਈ ਲੜੇ, ਅਤੇ ਕੀ ਅਸੀਂ ਸਫਲ ਹੋਏ, ਇਸ ਬਾਰੇ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਲਈਏ।

ਨਤੀਜੇ

ਸਾਡੇ ਕੋਲ ਉਪਭੋਗਤਾ ਹਨ - ਲਗਭਗ 33 ਮਿਲੀਅਨ।

ਸਾਡੇ ਕੋਲ ਮੌਜੂਦਗੀ ਦੇ ਤਿੰਨ ਪੁਆਇੰਟ ਹਨ - ਪ੍ਰਾਗ, ਮਿਆਮੀ, ਹਾਂਗਕਾਂਗ।

ਉਹਨਾਂ ਵਿੱਚ ਇੱਕ ਕੈਚਿੰਗ ਲੇਅਰ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਫਾਸਟ ਲੋਕਲ ਡਿਸਕਾਂ (SSDs) ਵਾਲੀਆਂ ਕਾਰਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਜਿਸ ਉੱਤੇ NGINX ਤੋਂ ਸਧਾਰਨ ਮਸ਼ੀਨਰੀ, ਇਸਦੇ access.log ਅਤੇ Python ਡੈਮਨ ਚੱਲਦੇ ਹਨ, ਜੋ ਇਸ ਸਭ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਨ ਅਤੇ ਕੈਸ਼ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹਨ।

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਮਸ਼ੀਨਾਂ ਸਥਾਨਕ ਹਾਰਡ ਡਰਾਈਵਾਂ ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ।

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਮਸ਼ੀਨਾਂ SAN ਨਾਲ ਜੁੜੀਆਂ ਹੋਈਆਂ ਹਨ।

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

ਇਹ ਆਰਕੀਟੈਕਚਰ ਦੀ ਅਜਿਹੀ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਹੈ ਕਿ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ ਅਤੇ ਇਹ ਸਭ ਕਿਵੇਂ ਵਿਕਸਿਤ ਹੋਇਆ।

ਕਪਤਾਨ ਤੋਂ ਕੁਝ ਹੋਰ ਸੁਝਾਅ, ਬਹੁਤ ਹੀ ਸਧਾਰਨ।

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

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

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

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

ਪਹਿਲਾਂ ਅਸੀਂ ਇਸਨੂੰ ਮਾਪਿਆ, ਫਿਰ ਅਸੀਂ ਇਸਨੂੰ ਸੁਧਾਰਿਆ।

ਅੱਗੇ. ਅਸੀਂ ਕੈਸ਼ ਨਾਲ ਰੀਡਿੰਗ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਂਦੇ ਹਾਂ, ਸ਼ਾਰਡਿੰਗ ਨਾਲ ਲਿਖਣਾ, ਪਰ ਇਹ ਇੱਕ ਸਪੱਸ਼ਟ ਬਿੰਦੂ ਹੈ।

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

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

ਅਗਲਾ ਬਿੰਦੂ. ਫਲਾਈ 'ਤੇ ਆਕਾਰ ਬਦਲਣ ਬਾਰੇ।

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

ਅਸੀਂ ਸਿਰਫ਼ ਤਿੰਨ ਮੁੱਖ ਆਕਾਰ ਛੱਡੇ: ਛੋਟੇ, ਦਰਮਿਆਨੇ ਅਤੇ ਵੱਡੇ। ਅਸੀਂ ਸਿਰਫ਼ ਉਸ ਆਕਾਰ ਤੋਂ ਬਾਕੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਡਾਊਨਸਕੇਲ ਕਰਦੇ ਹਾਂ ਜੋ Uport 'ਤੇ ਸਾਨੂੰ ਕਿਹਾ ਗਿਆ ਸੀ, ਅਸੀਂ ਸਿਰਫ਼ ਡਾਊਨਸਕੇਲ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਉਪਭੋਗਤਾ ਨੂੰ ਦਿੰਦੇ ਹਾਂ।

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

ਅਤੇ ਵਾਧੇ ਵਾਲਾ ਅਸਿੰਕਰੋਨਸ ਬੈਕਅੱਪ ਚੰਗਾ ਹੈ।

ਜਿਵੇਂ ਕਿ ਸਾਡੇ ਅਭਿਆਸ ਨੇ ਦਿਖਾਇਆ ਹੈ, ਇਹ ਸਕੀਮ ਬਦਲੀਆਂ ਗਈਆਂ ਫਾਈਲਾਂ ਦੀ ਦੇਰੀ ਨਾਲ ਕਾਪੀ ਕਰਨ ਦੇ ਨਾਲ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ।

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

ਸੰਪਰਕ

» bo0rsh201
» Badoo ਬਲੌਗ

ਇਹ ਰਿਪੋਰਟ ਉੱਚ-ਲੋਡ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਡਿਵੈਲਪਰਾਂ ਦੀ ਕਾਨਫਰੰਸ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਭਾਸ਼ਣਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਹੈ ਹਾਈਲੋਡ++. HighLoad++ 2017 ਕਾਨਫਰੰਸ ਵਿੱਚ ਇੱਕ ਮਹੀਨੇ ਤੋਂ ਵੀ ਘੱਟ ਸਮਾਂ ਬਾਕੀ ਹੈ।

ਸਾਡੇ ਕੋਲ ਇਹ ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਹੈ ਕਾਨਫਰੰਸ ਪ੍ਰੋਗਰਾਮ, ਅਨੁਸੂਚੀ ਹੁਣ ਸਰਗਰਮੀ ਨਾਲ ਬਣਾਈ ਜਾ ਰਹੀ ਹੈ।

ਇਸ ਸਾਲ ਅਸੀਂ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸਕੇਲਿੰਗ ਦੇ ਵਿਸ਼ੇ ਦੀ ਪੜਚੋਲ ਕਰਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ:

• ਇੱਕ ਅਰਬ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਸੇਵਾ ਕਿਵੇਂ ਕਰੀਏ ਅਤੇ ਟ੍ਰੈਫਿਕ ਦਾ ਇੱਕ ਟੈਰਾਬਿਟ ਕਿਵੇਂ ਪ੍ਰਦਾਨ ਕਰੀਏ / ਇਗੋਰ ਵਸੀਲੀਏਵ
• VKontakte ਨਿੱਜੀ ਸੰਦੇਸ਼ਾਂ ਦੇ ਡੇਟਾਬੇਸ ਨੂੰ ਸਕ੍ਰੈਚ ਤੋਂ ਕਿਵੇਂ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹੈ ਅਤੇ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਇਸ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨਾ ਹੈ / ਦਮਿਤਰੀ ਐਗੋਰੋਵ
• ਵਿਕਰੀ ਦੁਆਰਾ ਮੌਤ: ਕਿਵੇਂ Yandex.Money ਨੇ ਬਲੈਕ ਫ੍ਰਾਈਡੇ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਅਤੇ ਬਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ / ਅਨਾਤੋਲੀ ਪਲਸਕੋਵਸਕੀ
• ਬੈਂਕ ਦੇ ਫਰੰਟ-ਐਂਡ ਸਿਸਟਮ ਦੀ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਆਰਕੀਟੈਕਚਰ / ਰੋਮਨ ਸ਼ੇਖੋਵਤਸੋਵ, ਅਲੈਕਸੀ ਗ੍ਰੋਮੈਟਚਿਕੋਵ
• ਭੁਗਤਾਨ ਸਿਸਟਮ ਆਰਕੀਟੈਕਚਰ: ਲਗਭਗ ਐਂਟਰਪ੍ਰਾਈਜ਼ / ਫਿਲਿਪ ਡੇਲਗਾਡੋ

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

ਸਰੋਤ: www.habr.com