ਸਪੋਰਟਮਾਸਟਰ ਵਿਖੇ ਅਸੀਂ ਇੱਕ ਕੈਚਿੰਗ ਸਿਸਟਮ ਨੂੰ ਕਿਵੇਂ ਚੁਣਿਆ। ਭਾਗ 1

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਮੇਰਾ ਨਾਮ ਅਲੈਕਸੀ ਪਿਯੰਕੋਵ ਹੈ, ਮੈਂ ਸਪੋਰਟਮਾਸਟਰ ਕੰਪਨੀ ਵਿੱਚ ਇੱਕ ਡਿਵੈਲਪਰ ਹਾਂ। ਉਸ ਵਿੱਚ ਪੋਸਟ ਮੈਂ ਦੱਸਿਆ ਕਿ ਸਪੋਰਟਮਾਸਟਰ ਵੈਬਸਾਈਟ 'ਤੇ 2012 ਵਿੱਚ ਕੰਮ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੋਇਆ, ਅਸੀਂ ਕਿਹੜੀਆਂ ਪਹਿਲਕਦਮੀਆਂ ਨੂੰ "ਪੁਸ਼ ਟੂ" ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਅਤੇ ਇਸ ਦੇ ਉਲਟ, ਅਸੀਂ ਕਿਹੜਾ ਰੇਕ ਇਕੱਠਾ ਕੀਤਾ।

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

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

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

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

ਪਰ ਇਸ ਪੋਸਟ ਵਿੱਚ ਮੈਂ ਦੂਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰਾਂਗਾ, ਮੈਂ ਕੁਝ ਵਿਚਾਰ ਪੇਸ਼ ਕਰਾਂਗਾ - ਕੈਚਿੰਗ ਬਾਰੇ ਵਿਚਾਰ, ਜੋ ਕਿ ਇੱਕ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟ ਤੋਂ ਪਹਿਲਾਂ ਸਕ੍ਰੌਲ ਕਰਨ ਲਈ ਇੱਕ ਚੰਗਾ ਕਦਮ ਹੋਵੇਗਾ.

ਜਦੋਂ ਇੱਕ ਕੈਸ਼ਿੰਗ ਕੰਮ ਹੁੰਦਾ ਹੈ

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

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

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

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

ਕੈਸ਼ਿੰਗ ਸਿਸਟਮ ਲਈ ਬੁਨਿਆਦੀ ਲੋੜਾਂ

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

ਚਲੋ ਇਸ ਕੇਸ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ।

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

ਅਤੇ ਜੇਕਰ ਹਾਰਡਵੇਅਰ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸਪਲਾਈ 2-5 ਗੁਣਾ ਹੋ ਸਕਦੀ ਹੈ, ਤਾਂ ਕੈਸ਼ ਦੀ ਮਦਦ ਨਾਲ ਅਸੀਂ 10 ਦੇ ਫੈਕਟਰ ਦੁਆਰਾ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਸੁਧਾਰ ਸਕਦੇ ਹਾਂ ਜਾਂ, ਇੱਕ ਚੰਗੇ ਮਾਮਲੇ ਵਿੱਚ, 100 ਦੇ ਇੱਕ ਫੈਕਟਰ ਦੁਆਰਾ, ਕੁਝ ਸਥਾਨਾਂ ਵਿੱਚ ਸ਼ਾਇਦ ਇੱਕ ਕਾਰਕ ਦੁਆਰਾ 1000 ਦਾ। ਭਾਵ, ਉਸੇ ਹਾਰਡਵੇਅਰ 'ਤੇ - ਅਸੀਂ 100 ਗੁਣਾ ਜ਼ਿਆਦਾ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੇ ਹਾਂ। ਬਹੁਤ ਵਧੀਆ, ਤੁਸੀਂ ਜਿੰਜਰਬ੍ਰੇਡ ਦੇ ਹੱਕਦਾਰ ਹੋ!

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

ਸ਼ੁਰੂਆਤੀ ਲੋਡ ਦੇ ਮੁਕਾਬਲੇ, ਸਾਡਾ ਲੋਹੇ ਦਾ ਰਿਜ਼ਰਵ 2-5 ਗੁਣਾ ਸੀ, ਅਤੇ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਲੋਡ 10-100 ਗੁਣਾ ਵਧ ਗਿਆ। ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਭਾਰੀ ਫੰਕਸ਼ਨਾਂ ਲਈ ਕਾਲਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਹੈ ਅਤੇ ਇਸਲਈ ਸਭ ਕੁਝ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਤੇ ਹੁਣ, ਕੈਸ਼ ਤੋਂ ਬਿਨਾਂ, ਸਾਡੀ ਪ੍ਰਣਾਲੀ ਕਿੰਨੀ ਵਾਰ ਹੌਲੀ ਹੋ ਜਾਵੇਗੀ? ਸਾਡਾ ਕੀ ਹੋਵੇਗਾ? ਸਿਸਟਮ ਡਿੱਗ ਜਾਵੇਗਾ।

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

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

ਪਸੰਦ ਦਾ ਆਟਾ

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

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

ਅਸੀਂ ਕੀ ਕੀਤਾ:

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

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

ਚਲੋ ਇਸ ਵਿਕਲਪ ਨੂੰ ਮਾਡਲ ਕਰੀਏ (ਇਹ ਕਲਪਨਾ ਕਰਨਾ ਔਖਾ ਹੈ ਕਿ ਇੱਕ ਮੱਧ+ ਡਿਵੈਲਪਰ ਇੱਕ ਵੈਕਿਊਮ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਚੋਣ ਦੇ ਸਮੇਂ ਅਜੇ ਤੱਕ ਆਪਣੀ ਤਰਜੀਹ ਨੂੰ ਰਸਮੀ ਨਹੀਂ ਬਣਾਇਆ ਹੈ ਕਿ ਕਿਸ ਉਤਪਾਦ ਨੂੰ ਪਹਿਲਾਂ ਅਜ਼ਮਾਉਣਾ ਹੈ - ਇਸ ਲਈ, ਹੋਰ ਤਰਕ ਇੱਕ ਸਿਧਾਂਤਕਾਰ/ਦਰਸ਼ਨ/ ਇੱਕ ਜੂਨੀਅਰ ਬਾਰੇ).

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

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

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

ਰੇਡਿਸ

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

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

EhCache

EhCache - "ਜਾਵਾ ਲਈ ਸਭ ਤੋਂ ਵੱਧ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਕੈਸ਼" (ਅਧਿਕਾਰਤ ਵੈੱਬਸਾਈਟ ਤੋਂ ਸਲੋਗਨ ਦਾ ਅਨੁਵਾਦ)। ਓਪਨਸੋਰਸ ਵੀ. ਅਤੇ ਫਿਰ ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਰੇਡਿਸ ਜਾਵਾ ਲਈ ਨਹੀਂ ਹੈ, ਪਰ ਆਮ ਹੈ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਲਈ ਤੁਹਾਨੂੰ ਇੱਕ ਰੈਪਰ ਦੀ ਲੋੜ ਹੈ. ਅਤੇ EhCache ਵਧੇਰੇ ਸੁਵਿਧਾਜਨਕ ਹੋਵੇਗਾ। ਸਿਸਟਮ ਹੋਰ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ? ਭਰੋਸੇਯੋਗਤਾ, ਸਾਬਤ, ਪੂਰੀ ਕਾਰਜਕੁਸ਼ਲਤਾ. ਖੈਰ, ਇਹ ਸਭ ਤੋਂ ਆਮ ਵੀ ਹੈ. ਅਤੇ ਟੈਰਾਬਾਈਟ ਡਾਟਾ ਕੈਸ਼ ਕਰਦਾ ਹੈ।

Redis ਭੁੱਲ ਗਿਆ ਹੈ, ਮੈਂ EhCache ਨੂੰ ਚੁਣਨ ਲਈ ਤਿਆਰ ਹਾਂ।

ਪਰ ਦੇਸ਼ ਭਗਤੀ ਦੀ ਭਾਵਨਾ ਮੈਨੂੰ ਇਹ ਦੇਖਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀ ਹੈ ਕਿ ਤਰਨਟੂਲ ਬਾਰੇ ਕੀ ਚੰਗਾ ਹੈ।

ਤਰੰਤੂਲ

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

ਆਓ ਲਾਗੂਕਰਨਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ: Mail.ru ਕਾਰਪੋਰੇਟ ਹਾਈਵੇਅ, ਅਵੀਟੋ, ਬੀਲਾਈਨ, ਮੇਗਾਫੋਨ, ਅਲਫਾ-ਬੈਂਕ, ਗਜ਼ਪ੍ਰੋਮ...

ਜੇਕਰ ਅਜੇ ਵੀ ਤਰਨਟੂਲ ਬਾਰੇ ਕੋਈ ਸ਼ੰਕੇ ਸਨ, ਤਾਂ ਮਾਸਟਰਕਾਰਡ 'ਤੇ ਲਾਗੂ ਕਰਨ ਦਾ ਮਾਮਲਾ ਮੈਨੂੰ ਖਤਮ ਕਰਦਾ ਹੈ। ਮੈਂ ਤਰਨਟੂਲ ਲੈਂਦਾ ਹਾਂ।

ਪਰ ਫਿਰ ਵੀ…

ਰੋਸ਼ਨ

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

ਲਾਗੂਕਰਨ: Sberbank, American Airlines, Yahoo! ਜਪਾਨ. ਅਤੇ ਫਿਰ ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ Ignite ਸਿਰਫ਼ Sberbank ਵਿੱਚ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ SberTech ਟੀਮ ਉਤਪਾਦ ਨੂੰ ਸ਼ੁੱਧ ਕਰਨ ਲਈ ਆਪਣੇ ਲੋਕਾਂ ਨੂੰ Ignite ਟੀਮ ਕੋਲ ਭੇਜਦੀ ਹੈ। ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਨਮੋਹਕ ਹੈ ਅਤੇ ਮੈਂ ਇਗਨਾਈਟ ਲੈਣ ਲਈ ਤਿਆਰ ਹਾਂ।

ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸਪਸ਼ਟ ਹੈ ਕਿ ਕਿਉਂ, ਮੈਂ ਪੰਜਵੇਂ ਬਿੰਦੂ ਨੂੰ ਦੇਖ ਰਿਹਾ ਹਾਂ.

ਹੇਜ਼ਲਕਾਸਟ

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

ਬੱਸ, ਮੈਂ ਹੇਜ਼ਲਕਾਸਟ ਲੈਣ ਲਈ ਤਿਆਰ ਹਾਂ।

ਤੁਲਨਾ

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

ਸਾਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਇੱਕ ਮਿਲਦਾ ਹੈ ਸਮੀਖਿਆ, ਸਾਡੇ 5 ਸਿਸਟਮ ਚੁਣੋ।

ਇੱਥੇ ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ: Redis ਸਿਖਰ 'ਤੇ ਹੈ, Hazelcast ਦੂਜੇ ਸਥਾਨ 'ਤੇ ਹੈ, Tarantool ਅਤੇ Ignite ਪ੍ਰਸਿੱਧੀ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹਨ, EhCache ਰਿਹਾ ਹੈ ਅਤੇ ਉਸੇ ਤਰ੍ਹਾਂ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਪਰ ਆਓ ਦੇਖੀਏ ਗਣਨਾ ਵਿਧੀ: ਵੈੱਬਸਾਈਟਾਂ ਦੇ ਲਿੰਕ, ਸਿਸਟਮ ਵਿੱਚ ਆਮ ਦਿਲਚਸਪੀ, ਨੌਕਰੀ ਦੀ ਪੇਸ਼ਕਸ਼ - ਬਹੁਤ ਵਧੀਆ! ਭਾਵ, ਜਦੋਂ ਮੇਰਾ ਸਿਸਟਮ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਮੈਂ ਕਹਾਂਗਾ: “ਨਹੀਂ, ਇਹ ਭਰੋਸੇਯੋਗ ਹੈ! ਨੌਕਰੀ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ ਹਨ..." ਅਜਿਹੀ ਸਧਾਰਨ ਤੁਲਨਾ ਨਹੀਂ ਕਰੇਗੀ।

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

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

Hz ਬਨਾਮ Redis

ਅਸੀਂ ਇਹ ਲੱਭਦੇ ਹਾਂ ਤੁਲਨਾ:


ਨੀਲਾ Redis ਹੈ, ਲਾਲ Hazelcast ਹੈ. ਹੇਜ਼ਲਕਾਸਟ ਹਰ ਜਗ੍ਹਾ ਜਿੱਤਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਲਈ ਇੱਕ ਤਰਕ ਹੈ: ਇਹ ਮਲਟੀ-ਥ੍ਰੈੱਡਡ ਹੈ, ਬਹੁਤ ਹੀ ਅਨੁਕੂਲਿਤ ਹੈ, ਹਰੇਕ ਥ੍ਰੈਡ ਆਪਣੇ ਖੁਦ ਦੇ ਭਾਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਸਲਈ ਕੋਈ ਬਲਾਕਿੰਗ ਨਹੀਂ ਹੈ। ਅਤੇ Redis ਸਿੰਗਲ-ਥਰਿੱਡਡ ਹੈ; ਇਹ ਆਧੁਨਿਕ ਮਲਟੀ-ਕੋਰ CPUs ਤੋਂ ਲਾਭ ਨਹੀਂ ਲੈਂਦਾ। Hazelcast ਕੋਲ ਅਸਿੰਕ੍ਰੋਨਸ I/O ਹੈ, Redis-Jedis ਕੋਲ ਬਲਾਕਿੰਗ ਸਾਕਟ ਹਨ। ਆਖਰਕਾਰ, ਹੇਜ਼ਲਕਾਸਟ ਇੱਕ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਰੈਡਿਸ ਟੈਕਸਟ-ਕੇਂਦ੍ਰਿਤ ਹੈ, ਭਾਵ ਇਹ ਅਕੁਸ਼ਲ ਹੈ।

ਬਸ ਮਾਮਲੇ ਵਿੱਚ, ਆਓ ਤੁਲਨਾ ਦੇ ਇੱਕ ਹੋਰ ਸਰੋਤ ਵੱਲ ਮੁੜੀਏ। ਉਹ ਸਾਨੂੰ ਕੀ ਦਿਖਾਏਗਾ?

Redis ਬਨਾਮ Hz

ਇੱਕ ਹੋਰ ਤੁਲਨਾ:


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

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

ਬੋਤਲ ਨੂੰ ਹਿਲਾ ਕੇ

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

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

ਇਸ ਵਿਧੀ ਨੂੰ ਇਸ ਉਦਾਹਰਣ ਨਾਲ ਬਹੁਤ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਾਇਆ ਗਿਆ ਹੈ।

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

ਅਜਿਹੀ ਵਿਧੀ ਹੈ, ਬਹੁਤ ਤੇਜ਼ ਅਤੇ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ.

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

ਅਸੀਂ ਕਿਸੇ ਨੂੰ ਇਹ ਕੁਝ ਦਿਖਾਉਂਦੇ ਹਾਂ: "ਸਰਯੋਗਾ, ਕੀ ਤੁਸੀਂ ਦੇਖਦੇ ਹੋ!" ਅਤੇ ਅਸਲ ਵਿੱਚ, ਦੂਰੋਂ ਇਹ ਇੱਕ ਜਹਾਜ਼ ਵਰਗਾ ਲੱਗਦਾ ਹੈ. ਪਰ ਇਸ ਨੂੰ ਜਾਰੀ ਰੱਖਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ।

ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ. ਉਹ ਵਧੇਰੇ ਉੱਨਤ ਮੁੰਡਿਆਂ ਦੁਆਰਾ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਹੈਕਰ।

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

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

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

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

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

ਕਿੱਥੇ ਬੋਤਲ-ਗਰਦਨ ਦੀ ਭਾਲ ਕਰਨੀ ਹੈ

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

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

ਸਾਨੂੰ ਕੋਡ ਤਰਕ (2) ਦੀ ਵੀ ਲੋੜ ਹੈ, ਜੋ ਅਸਲ ਵਿੱਚ ਕੈਚਿੰਗ ਬਾਰੇ ਹੈ। ਗਾਹਕ ਕੁਝ API ਰਾਹੀਂ ਇਸ ਕੋਡ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੇ ਹਨ। ਕਲਾਇੰਟ ਕੋਡ (1) ਜਾਂ ਤਾਂ ਉਸੇ JVM ਦੇ ਅੰਦਰ ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਇਸਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਐਕਸੈਸ ਕਰ ਸਕਦਾ ਹੈ। ਅੰਦਰ ਲਾਗੂ ਤਰਕ ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਛੱਡਣਾ ਹੈ ਅਤੇ ਕਿਹੜੀਆਂ ਨੂੰ ਬਾਹਰ ਸੁੱਟਣਾ ਹੈ। ਅਸੀਂ ਕੈਸ਼ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਮੈਮੋਰੀ (3) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਪਰ ਜੇਕਰ ਲੋੜ ਹੋਵੇ, ਤਾਂ ਅਸੀਂ ਡਿਸਕ (4) 'ਤੇ ਕੁਝ ਡਾਟਾ ਬਚਾ ਸਕਦੇ ਹਾਂ।

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

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

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

ਹੇਜ਼ਲਕਾਸਟ

ਆਓ ਦੇਖੀਏ ਕਿ ਸਾਡੀ ਸੂਚੀ ਵਿੱਚ ਇਸ ਸੜਨ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, Hazelcast.

ਹੇਜ਼ਲਕਾਸਟ ਤੋਂ ਡੇਟਾ ਪਾਉਣ/ਲੈਣ ਲਈ, ਕਲਾਇੰਟ ਕੋਡ (1) ਏਪੀਆਈ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ। Hz ਤੁਹਾਨੂੰ ਸਰਵਰ ਨੂੰ ਏਮਬੈੱਡ ਦੇ ਤੌਰ ਤੇ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਏਪੀਆਈ ਨੂੰ ਐਕਸੈਸ ਕਰਨਾ JVM ਦੇ ਅੰਦਰ ਇੱਕ ਵਿਧੀ ਕਾਲ ਹੈ, ਜਿਸ ਨੂੰ ਮੁਫਤ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਅਜਿਹੇ ਹਾਲਾਤ ਵਿੱਚ ਗਤੀ ਵਧਾਉਣ ਲਈ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

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

ਪੱਧਰ (6) 'ਤੇ ਮਰੋੜਨ ਲਈ, Hz ਦੋ ਕਿਸਮਾਂ ਦੀ ਸਟੋਰੇਜ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ: IMap ਅਤੇ ReplicatedMap।


ਇਹ ਵਰਣਨ ਯੋਗ ਹੈ ਕਿ ਹੇਜ਼ਲਕਾਸਟ ਸਪੋਰਟਮਾਸਟਰ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਵਿੱਚ ਕਿਵੇਂ ਆਇਆ।

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

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

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

ਇਹਨਾਂ ਸਾਰੀਆਂ ਲੋੜਾਂ ਲਈ, ਹੇਜ਼ਲਕਾਸਟ ਬਿਲ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ।

ਜਾਰੀ ਰੱਖਣ ਲਈ

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

ਇਸ ਦੌਰਾਨ... ਨਵਾਂ ਕੋਡ ਮੁਬਾਰਕ!

ਸਰੋਤ: www.habr.com