Yandex.Market ਖੋਜ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਜੇਕਰ ਕੋਈ ਸਰਵਰ ਫੇਲ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ

ਹੈਲੋ, ਮੇਰਾ ਨਾਮ Evgeniy ਹੈ. ਮੈਂ Yandex.Market ਖੋਜ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹਾਂ। ਮੈਂ ਹਾਬਰ ਭਾਈਚਾਰੇ ਨੂੰ ਮਾਰਕੀਟ ਦੀ ਅੰਦਰੂਨੀ ਰਸੋਈ ਬਾਰੇ ਦੱਸਣਾ ਚਾਹੁੰਦਾ ਹਾਂ - ਅਤੇ ਮੇਰੇ ਕੋਲ ਦੱਸਣ ਲਈ ਬਹੁਤ ਕੁਝ ਹੈ। ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਮਾਰਕੀਟ ਖੋਜ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਆਰਕੀਟੈਕਚਰ। ਅਸੀਂ ਸੰਕਟਕਾਲੀਨ ਸਥਿਤੀਆਂ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਦੇ ਹਾਂ: ਜੇਕਰ ਇੱਕ ਸਰਵਰ ਡਾਊਨ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ? ਜੇ 100 ਅਜਿਹੇ ਸਰਵਰ ਹਨ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?

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

ਸਾਡੇ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ: ਅਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦੇ ਹਾਂ

ਜਦੋਂ ਤੁਸੀਂ ਟੈਕਸਟ ਦਰਜ ਕਰਦੇ ਹੋ, ਪੈਰਾਮੀਟਰਾਂ ਦੁਆਰਾ ਕਿਸੇ ਉਤਪਾਦ ਦੀ ਖੋਜ ਕਰਦੇ ਹੋ, ਜਾਂ ਵੱਖ-ਵੱਖ ਸਟੋਰਾਂ ਵਿੱਚ ਕੀਮਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਖੋਜ ਸੇਵਾ ਨੂੰ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਖੋਜ ਮਾਰਕੀਟ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੀ ਸੇਵਾ ਹੈ।

ਅਸੀਂ ਸਾਰੀਆਂ ਖੋਜ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਾਂ: ਸਾਈਟਾਂ market.yandex.ru, beru.ru, ਸੁਪਰਚੈਕ ਸੇਵਾ, Yandex.Advisor, ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨਾਂ ਤੋਂ। ਅਸੀਂ yandex.ru 'ਤੇ ਖੋਜ ਨਤੀਜਿਆਂ ਵਿੱਚ ਉਤਪਾਦ ਪੇਸ਼ਕਸ਼ਾਂ ਨੂੰ ਵੀ ਸ਼ਾਮਲ ਕਰਦੇ ਹਾਂ।

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

ਕੀ ਹੈ: ਮਾਰਕੀਟ ਆਰਕੀਟੈਕਚਰ

ਮੈਂ ਮਾਰਕੀਟ ਦੇ ਮੌਜੂਦਾ ਆਰਕੀਟੈਕਚਰ ਦਾ ਸੰਖੇਪ ਵਰਣਨ ਕਰਾਂਗਾ। ਇਸ ਦਾ ਮੋਟੇ ਤੌਰ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਦੁਆਰਾ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਡੇਟਾਬੇਸ ਵਿੱਚ ਇੱਕ ਗੁੱਸੇ ਵਾਲੀ ਬਿੱਲੀ ਇੱਕ ਸਕਿਊਕਰ ਨਾਲ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਬਿੱਲੀ ਦਾ ਸੂਚਕਾਂਕ ਸਰਵਰ 'ਤੇ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ।

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

ਮਾਰਕੀਟ ਖੋਜ ਆਰਕੀਟੈਕਚਰ

ਅਸੀਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਰਹਿੰਦੇ ਹਾਂ: ਹਰ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ market.yandex.ru ਬਹੁਤ ਸਾਰੀਆਂ ਸਬਕਵੇਰੀਆਂ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ, ਅਤੇ ਦਰਜਨਾਂ ਸੇਵਾਵਾਂ ਉਹਨਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ। ਚਿੱਤਰ ਸਿਰਫ ਕੁਝ ਹੀ ਦਿਖਾਉਂਦਾ ਹੈ:

ਸਰਲੀਕ੍ਰਿਤ ਬੇਨਤੀ ਪ੍ਰੋਸੈਸਿੰਗ ਸਕੀਮ

ਹਰੇਕ ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਸ਼ਾਨਦਾਰ ਚੀਜ਼ ਹੁੰਦੀ ਹੈ - ਇੱਕ ਵਿਲੱਖਣ ਨਾਮ ਦੇ ਨਾਲ ਇਸਦਾ ਆਪਣਾ ਬੈਲੇਂਸਰ:

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

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

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

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

ਅਚਾਨਕ ਨਾਲ ਨਜਿੱਠਣਾ: ਖੋਜ ਸੇਵਾ ਸੰਤੁਲਨ ਅਤੇ ਲਚਕੀਲਾਪਨ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਢਹਿ ਹੈ: ਤੁਹਾਨੂੰ ਇੱਕ ਸਕੂਕਰ ਨਾਲ ਇੱਕ ਬਿੱਲੀ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਸਰਵਰ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ. ਜਾਂ 100 ਸਰਵਰ। ਬਾਹਰ ਕਿਵੇਂ ਨਿਕਲਣਾ ਹੈ? ਕੀ ਅਸੀਂ ਸੱਚਮੁੱਚ ਉਪਭੋਗਤਾ ਨੂੰ ਬਿੱਲੀ ਤੋਂ ਬਿਨਾਂ ਛੱਡਣ ਜਾ ਰਹੇ ਹਾਂ?

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

ਖੋਜ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਕਈ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਸਥਿਤ ਹੈ:

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

ਆਉ ਇੱਕ ਸਿੰਗਲ ਡੇਟਾ ਸੈਂਟਰ ਤੇ ਵਿਚਾਰ ਕਰੀਏ. ਹਰੇਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਸਮਾਨ ਬੈਲੇਂਸਰ ਓਪਰੇਸ਼ਨ ਸਕੀਮ ਹੈ:

ਇੱਕ ਬੈਲੇਂਸਰ ਘੱਟੋ-ਘੱਟ ਤਿੰਨ ਭੌਤਿਕ ਸਰਵਰ ਹਨ। ਇਹ ਰਿਡੰਡੈਂਸੀ ਭਰੋਸੇਯੋਗਤਾ ਲਈ ਬਣਾਈ ਗਈ ਹੈ। ਬੈਲੈਂਸਰ HAProx 'ਤੇ ਚੱਲਦੇ ਹਨ।

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

ਇੱਕ ਸਰਵਰ ਦੇ ਫੇਲ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੈ। ਪਰ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਸਰਵਰ ਹਨ, ਤਾਂ ਘੱਟੋ ਘੱਟ ਇੱਕ ਦੇ ਹੇਠਾਂ ਜਾਣ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਜਾਂਦੀ ਹੈ।

ਇਹ ਅਸਲੀਅਤ ਵਿੱਚ ਹੁੰਦਾ ਹੈ: ਸਰਵਰ ਕਰੈਸ਼. ਇਸ ਲਈ, ਸਾਰੇ ਸਰਵਰਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਨਿਰੰਤਰ ਨਿਗਰਾਨੀ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ. ਜੇਕਰ ਸਰਵਰ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ ਟ੍ਰੈਫਿਕ ਤੋਂ ਡਿਸਕਨੈਕਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਇਸ ਉਦੇਸ਼ ਲਈ, HAProxy ਵਿੱਚ ਇੱਕ ਬਿਲਟ-ਇਨ ਸਿਹਤ ਜਾਂਚ ਹੈ। ਇਹ HTTP ਬੇਨਤੀ “/ping” ਦੇ ਨਾਲ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਇੱਕ ਵਾਰ ਸਾਰੇ ਸਰਵਰਾਂ ਤੇ ਜਾਂਦਾ ਹੈ।

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

ਹੁਣ ਬਿੱਲੀ ਨੂੰ ਲੱਭਣ ਬਾਰੇ. ਬੇਨਤੀਆਂ ਵਿੱਚ ਖੋਜ ਨਤੀਜੇ ਜਿਵੇਂ ਕਿ: /search?text=angry+cat. ਖੋਜ ਤੇਜ਼ ਹੋਣ ਲਈ, ਪੂਰੀ ਕੈਟ ਇੰਡੈਕਸ ਰੈਮ ਵਿੱਚ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੋਂ ਤੱਕ ਕਿ SSD ਤੋਂ ਪੜ੍ਹਨਾ ਵੀ ਤੇਜ਼ ਨਹੀਂ ਹੈ.

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

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

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

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

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

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

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

ਸਰਵਰਾਂ ਨੂੰ ਕਲੱਸਟਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਹੈ। ਹਰੇਕ ਕਲੱਸਟਰ ਵਿੱਚ ਅੱਠ ਖੋਜ ਇੰਜਣ ਅਤੇ ਇੱਕ ਸਨਿੱਪਟ ਸਰਵਰ ਹੁੰਦਾ ਹੈ।

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

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

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

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

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

ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਖੋਜ ਸਵਾਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ: /shard1?text=angry+cat. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਫਾਰਮ ਦੀਆਂ ਸਬਕਵੇਰੀਆਂ ਨੂੰ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰਲੇ ਸਾਰੇ ਸਰਵਰਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਲਗਾਤਾਰ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: / ਸਥਿਤੀ.

ਬੇਨਤੀ / ਸਥਿਤੀ ਅਜਿਹੀ ਸਥਿਤੀ ਦਾ ਪਤਾ ਲਗਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਸਰਵਰ ਉਪਲਬਧ ਨਹੀਂ ਹੈ।

ਇਹ ਇਹ ਵੀ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਖੋਜ ਇੰਜਣ ਸੰਸਕਰਣ ਅਤੇ ਸੂਚਕਾਂਕ ਸੰਸਕਰਣ ਸਾਰੇ ਸਰਵਰਾਂ 'ਤੇ ਇੱਕੋ ਜਿਹੇ ਹਨ, ਨਹੀਂ ਤਾਂ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਅਸੰਗਤ ਡੇਟਾ ਹੋਵੇਗਾ।

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

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

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

ਅਤੇ ਹੁਣ ਖੁਸ਼ਹਾਲ ਅੰਤ ਵਾਲੀਆਂ ਡਰਾਉਣੀਆਂ ਕਹਾਣੀਆਂ ਲਈ। ਆਉ ਸਰਵਰ ਦੀ ਅਣਉਪਲਬਧਤਾ ਦੇ ਕਈ ਮਾਮਲਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ।

ਕੁਝ ਭਿਆਨਕ ਵਾਪਰਿਆ: ਇੱਕ ਸਰਵਰ ਉਪਲਬਧ ਨਹੀਂ ਹੈ

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

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

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

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

ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ: ਬਹੁਤ ਸਾਰੇ ਸਰਵਰ ਉਪਲਬਧ ਨਹੀਂ ਹਨ

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

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

ਫਿਰ ਵਾਧੂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਦੂਜੇ ਡੇਟਾ ਸੈਂਟਰਾਂ ਨੂੰ ਵੰਡਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ. ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ, ਹਰ ਕੋਈ ਖੁਸ਼ ਹੈ.

ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਕਰਦੇ ਹਾਂ: ਪ੍ਰਕਾਸ਼ਨ ਰੀਲੀਜ਼

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

ਫਿਰ ਸੇਵਾ ਨੂੰ ਟੈਸਟਿੰਗ ਲਈ ਰੋਲਆਊਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿੱਥੇ ਓਪਰੇਸ਼ਨ ਦੀ ਸਥਿਰਤਾ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

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

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

ਸਭ ਤੋਂ ਵਧੀਆ ਉਪਭੋਗਤਾ ਨੂੰ ਜਾਂਦਾ ਹੈ: A/B ਟੈਸਟਿੰਗ

ਇਹ ਹਮੇਸ਼ਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਸੇਵਾ ਵਿੱਚ ਬਦਲਾਅ ਅਸਲ ਲਾਭ ਲਿਆਏਗਾ ਜਾਂ ਨਹੀਂ। ਤਬਦੀਲੀਆਂ ਦੀ ਉਪਯੋਗਤਾ ਨੂੰ ਮਾਪਣ ਲਈ, ਲੋਕ A/B ਟੈਸਟਿੰਗ ਲੈ ਕੇ ਆਏ ਹਨ। ਮੈਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ ਦੱਸਾਂਗਾ ਕਿ ਇਹ Yandex.Market ਖੋਜ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ.

ਇਹ ਸਭ ਇੱਕ ਨਵਾਂ CGI ਪੈਰਾਮੀਟਰ ਜੋੜਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜੋ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਸਾਡੇ ਪੈਰਾਮੀਟਰ ਹੋਣ ਦਿਓ: ਮਾਰਕੀਟ_ਨਵੀਂ_ਕਾਰਜਸ਼ੀਲਤਾ = 1. ਫਿਰ ਕੋਡ ਵਿੱਚ ਅਸੀਂ ਇਸ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦੇ ਹਾਂ ਜੇਕਰ ਫਲੈਗ ਮੌਜੂਦ ਹੈ:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਉਤਪਾਦਨ ਲਈ ਰੋਲਆਊਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।

A/B ਟੈਸਟਿੰਗ ਨੂੰ ਸਵੈਚਾਲਤ ਕਰਨ ਲਈ, ਇੱਥੇ ਇੱਕ ਸਮਰਪਿਤ ਸੇਵਾ ਹੈ ਜੋ ਵਿਸਤ੍ਰਿਤ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ ਇੱਥੇ ਦੱਸਿਆ ਗਿਆ ਹੈ. ਸੇਵਾ ਵਿੱਚ ਇੱਕ ਪ੍ਰਯੋਗ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਟ੍ਰੈਫਿਕ ਸ਼ੇਅਰ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 15%. ਪ੍ਰਤੀਸ਼ਤ ਸਵਾਲਾਂ ਲਈ ਨਹੀਂ, ਪਰ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ। ਪ੍ਰਯੋਗ ਦੀ ਮਿਆਦ ਵੀ ਦਰਸਾਈ ਗਈ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਹਫ਼ਤੇ.

ਕਈ ਪ੍ਰਯੋਗ ਇੱਕੋ ਸਮੇਂ ਚਲਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਸੈਟਿੰਗਾਂ ਵਿੱਚ ਤੁਸੀਂ ਨਿਰਧਾਰਿਤ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਹੋਰ ਪ੍ਰਯੋਗਾਂ ਦੇ ਨਾਲ ਇੰਟਰਸੈਕਸ਼ਨ ਸੰਭਵ ਹੈ।

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

ਮਾਰਕੀਟ ਦਾ ਨਿਪੁੰਨ ਹੱਥ: ਉਤਪਾਦਨ ਵਿੱਚ ਟੈਸਟਿੰਗ

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

ਇੱਕ ਹੱਲ ਹੈ: CGI ਪੈਰਾਮੀਟਰਾਂ ਵਿੱਚ ਫਲੈਗ ਨਾ ਸਿਰਫ਼ A/B ਟੈਸਟਿੰਗ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਸਗੋਂ ਨਵੀਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਵੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਸੇਵਾ ਪ੍ਰਵਾਹ ਚਿੱਤਰ ਹੇਠਾਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ:

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

ਸਟਾਪ ਟੈਪ ਵਿੱਚ ਤੁਸੀਂ ਦੋ ਕਿਸਮ ਦੇ ਮੁੱਲ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ:

1) ਸ਼ਰਤੀਆ ਸਮੀਕਰਨ। ਲਾਗੂ ਕਰੋ ਜਦੋਂ ਮੁੱਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਹੀ ਹੋਵੇ। ਉਦਾਹਰਣ ਲਈ:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

ਜਦੋਂ DC3 ਸਥਾਨ 'ਤੇ ਬੇਨਤੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਮੁੱਲ "1" ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ। ਅਤੇ ਮੁੱਲ "4" ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਬੇਨਤੀ ਨੂੰ beru.ru ਸਾਈਟ ਲਈ ਦੂਜੇ ਕਲੱਸਟਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

2) ਬਿਨਾਂ ਸ਼ਰਤ ਮੁੱਲ। ਜੇਕਰ ਕੋਈ ਵੀ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ ਤਾਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਲਾਗੂ ਕਰੋ। ਉਦਾਹਰਣ ਲਈ:

ਮੁੱਲ, ਮੁੱਲ!

ਜੇਕਰ ਕੋਈ ਮੁੱਲ ਵਿਸਮਿਕ ਚਿੰਨ੍ਹ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਉੱਚ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।

CGI ਪੈਰਾਮੀਟਰ ਪਾਰਸਰ URL ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ। ਫਿਰ ਸਟਾਪ ਟੈਪ ਤੋਂ ਮੁੱਲਾਂ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਹੇਠ ਲਿਖੀਆਂ ਤਰਜੀਹਾਂ ਵਾਲੇ ਮੁੱਲ ਲਾਗੂ ਕੀਤੇ ਜਾਂਦੇ ਹਨ:

1. ਸਟਾਪ ਟੈਪ (ਵਿਸਮਿਕ ਚਿੰਨ੍ਹ) ਤੋਂ ਵਧੀ ਹੋਈ ਤਰਜੀਹ ਦੇ ਨਾਲ।
2. ਬੇਨਤੀ ਤੋਂ ਮੁੱਲ।
3. ਸਟਾਪ ਟੈਪ ਤੋਂ ਡਿਫੌਲਟ ਮੁੱਲ।
4. ਕੋਡ ਵਿੱਚ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲ।

ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਝੰਡੇ ਹਨ ਜੋ ਸ਼ਰਤੀਆ ਮੁੱਲਾਂ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ - ਉਹ ਸਾਡੇ ਲਈ ਜਾਣੇ ਜਾਂਦੇ ਸਾਰੇ ਦ੍ਰਿਸ਼ਾਂ ਲਈ ਕਾਫ਼ੀ ਹਨ:

• ਡਾਟਾ ਸੈਂਟਰ।
• ਵਾਤਾਵਰਣ: ਉਤਪਾਦਨ, ਟੈਸਟਿੰਗ, ਸ਼ੈਡੋ।
• ਸਥਾਨ: ਬਾਜ਼ਾਰ, ਬੇਰੂ।
• ਕਲੱਸਟਰ ਨੰਬਰ।

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

ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਸਮੱਸਿਆ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਝੰਡੇ ਨੂੰ ਇਸਦੇ ਪਿਛਲੇ ਮੁੱਲ 'ਤੇ ਵਾਪਸ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਤਬਦੀਲੀਆਂ ਨੂੰ ਵਾਪਸ ਰੋਲ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ।

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

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

ਹਾਲਾਂਕਿ, ਸਟਾਪ ਟੈਪ ਵਿਕਾਸ ਦੌਰਾਨ ਟੈਸਟਿੰਗ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ। ਡਿਵੈਲਪਰਾਂ ਲਈ ਇੱਕ ਵੱਖਰਾ ਕਲੱਸਟਰ ਹੈ ਜਿਸਨੂੰ "ਸ਼ੈਡੋ ਕਲੱਸਟਰ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਗੁਪਤ ਟੈਸਟਿੰਗ: ਸ਼ੈਡੋ ਕਲੱਸਟਰ

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

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

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

ਸਿੱਟਾ

ਤਾਂ, ਅਸੀਂ ਮਾਰਕੀਟ ਖੋਜ ਕਿਵੇਂ ਬਣਾਈ?

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

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

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

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

ਸਰੋਤ: www.habr.com