ਮਾਸਕੋ ਐਕਸਚੇਂਜ ਦੇ ਵਪਾਰ ਅਤੇ ਕਲੀਅਰਿੰਗ ਪ੍ਰਣਾਲੀ ਦੇ ਆਰਕੀਟੈਕਚਰ ਦਾ ਵਿਕਾਸ. ਭਾਗ 2

ਇਹ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ, ਉੱਚ-ਲੋਡ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਸਾਡੇ ਕੰਡੇਦਾਰ ਮਾਰਗ ਬਾਰੇ ਇੱਕ ਲੰਬੀ ਕਹਾਣੀ ਦੀ ਨਿਰੰਤਰਤਾ ਹੈ ਜੋ ਐਕਸਚੇਂਜ ਦੇ ਸੰਚਾਲਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਪਹਿਲਾ ਭਾਗ ਇੱਥੇ ਹੈ: habr.com/en/post/444300

ਰਹੱਸਮਈ ਗਲਤੀ

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

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

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

ਗਲਤੀ ਦਾ ਕਾਰਨ ਨਹੀਂ ਲੱਭਿਆ ਜਾ ਸਕਿਆ।

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

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

ਕਿਉਂਕਿ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਸੰਭਵ ਨਹੀਂ ਸੀ, ਇਸਲਈ "ਅਪਰਾਧਕ" ਸਰਵਰ ਨੂੰ ਓਪਰੇਸ਼ਨ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ.

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

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

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

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

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

ਸਿਸਟਮ ਦੇ ਹੋਰ ਵਿਕਾਸ

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

ਨਿਮਨਲਿਖਤ ਸਿਧਾਂਤਾਂ ਨੇ ਰਿਜ਼ਰਵੇਸ਼ਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਅਗਲੇ ਸੁਧਾਰਾਂ ਦਾ ਆਧਾਰ ਬਣਾਇਆ:

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

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

ਨੈੱਟਵਰਕਿੰਗ

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

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

ਲੈਣ-ਦੇਣ ਦੀ ਪ੍ਰਕਿਰਿਆ

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

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

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

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

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

ਕੋਡ ਦੇ ਇੱਕ ਛੋਟੇ ਅਨੁਕੂਲਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸਮਾਨਾਂਤਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਇੱਕ ਪਾਈਪਲਾਈਨ ਬਣਾਈ, ਜਿਸ ਵਿੱਚ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਨੂੰ ਪਾਈਪਲਾਈਨ ਦੇ 4 ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ: ਨੈਟਵਰਕ ਇੰਟਰੈਕਸ਼ਨ, ਪ੍ਰਮਾਣਿਕਤਾ, ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਅਤੇ ਨਤੀਜੇ ਦਾ ਪ੍ਰਕਾਸ਼ਨ

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

ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ASTS+ ਸਿਸਟਮ ਲੈ ਕੇ ਆਏ ਹਾਂ।

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

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

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

ਪੂਰੀ ਕਤਾਰ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਸੈਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਲਗਭਗ 8 ਮਿਲੀਅਨ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਅਤੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਦੋ ਮਹੀਨਿਆਂ ਬਾਅਦ ਲੇਖ LMAX ਡਿਸਪਲੇਟਰ ਬਾਰੇ ਅਸੀਂ ਉਸੇ ਕਾਰਜਸ਼ੀਲਤਾ ਵਾਲੇ ਸਰਕਟ ਦਾ ਵਰਣਨ ਦੇਖਿਆ ਹੈ।

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

ਐਕਸਚੇਂਜ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ

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

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

ਇੱਕ ਨਵੀਂ ਪ੍ਰਣਾਲੀ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਸਾਨੂੰ ਤੁਰੰਤ ਆਪਸੀ ਤਾਲਮੇਲ ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨਾ ਪਿਆ. ਇੱਕ ਡਾਟਾ ਬੱਸ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ, ਸਥਿਰ ਝਟਕੇ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਲੇਟੈਂਸੀ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਜ਼ਰੂਰੀ ਸੀ। InfiniBand RDMA ਨੈੱਟਵਰਕ ਇਸ ਲਈ ਸਭ ਤੋਂ ਅਨੁਕੂਲ ਸੀ: ਔਸਤ ਪ੍ਰੋਸੈਸਿੰਗ ਸਮਾਂ 4 G ਈਥਰਨੈੱਟ ਨੈੱਟਵਰਕਾਂ ਨਾਲੋਂ 10 ਗੁਣਾ ਘੱਟ ਹੈ। ਪਰ ਜਿਸ ਚੀਜ਼ ਨੇ ਅਸਲ ਵਿੱਚ ਸਾਨੂੰ ਆਕਰਸ਼ਿਤ ਕੀਤਾ ਉਹ ਸੀ ਪ੍ਰਤੀਸ਼ਤ - 99 ਅਤੇ 99,9 ਵਿੱਚ ਅੰਤਰ।

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

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

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

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

ਨਕਲ

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

ਬੈਕਅੱਪ ਡਾਟਾ ਸੈਂਟਰ ਨਾਲ ਕੰਮ ਕਰਨਾ

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

ਨਤੀਜੇ

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

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

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

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

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

ਅਸੀਂ ਆਖਰਕਾਰ ਕੀ ਪ੍ਰਾਪਤ ਕੀਤਾ:

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

ਪੀਕ ਪ੍ਰਦਰਸ਼ਨ ਪ੍ਰਤੀ ਸਕਿੰਟ 50 ਹਜ਼ਾਰ ਤੋਂ 180 ਹਜ਼ਾਰ ਟ੍ਰਾਂਜੈਕਸ਼ਨਾਂ ਤੱਕ ਵਧਿਆ। ਇੱਕ ਹੋਰ ਵਾਧਾ ਆਰਡਰ ਮੈਚਿੰਗ ਦੀ ਇੱਕੋ ਇੱਕ ਧਾਰਾ ਦੁਆਰਾ ਰੁਕਾਵਟ ਹੈ।

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

ਅੰਤ ਵਿੱਚ, ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਕੁਝ ਸਲਾਹ ਦੇ ਸਕਦਾ ਹਾਂ ਜੋ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਅੰਤਿਮ ਰੂਪ ਦੇ ਰਹੇ ਹਨ:

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

ਸਰੋਤ: www.habr.com