ਵੰਡੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਬਿਲਡਿੰਗ ਬਲਾਕ। ਦੂਜਾ ਅਨੁਮਾਨ

ਘੋਸ਼ਣਾ

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

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

ਅੱਜ ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕੋਡ ਬੇਸ ਅਤੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਵਿਕਾਸ ਦੇ ਮੁੱਦੇ ਉਠਾਵਾਂਗੇ।

ਸੇਵਾਵਾਂ ਦਾ ਸੰਗਠਨ

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

ਸਥਿਤੀ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਸਾਨੂੰ ਇੱਕ ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਵੰਡੀ ਸੇਵਾ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਆਓ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਲੋੜਾਂ ਬਦਲ ਗਈਆਂ ਹਨ:

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

ਟਿੱਪਣੀ: ਅਸੀਂ ਇਕਸਾਰ ਸਟੋਰੇਜ ਅਤੇ ਡੇਟਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੇ ਮੁੱਦੇ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਇਹ ਮੁੱਦੇ ਪਹਿਲਾਂ ਹੀ ਹੱਲ ਕੀਤੇ ਗਏ ਹਨ ਅਤੇ ਸਿਸਟਮ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਭਰੋਸੇਯੋਗ ਅਤੇ ਸਕੇਲੇਬਲ ਸਟੋਰੇਜ ਲੇਅਰ ਹੈ, ਅਤੇ ਹੈਂਡਲਰਾਂ ਕੋਲ ਇਸ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਲਈ ਵਿਧੀ ਹੈ।

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

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

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

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

ਨੇਤਾ ਦੀ ਚੋਣ

ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ, ਲੀਡਰ ਚੋਣ ਕੁਝ ਲੋਡ ਦੀ ਵਿਤਰਿਤ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤਹਿ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਨਿਯੁਕਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਹੈ।

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

ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਨਾਲ ਜੁੜਨ ਤੋਂ ਬਾਅਦ, ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਇੱਕ ਸਿਸਟਮ ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ਜੇ LeaderPid ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ pid ਮੌਜੂਦਾ ਪ੍ਰਕਿਰਿਆ, ਇਸ ਨੂੰ ਨੇਤਾ ਵਜੋਂ ਨਿਯੁਕਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਸੂਚੀ Servers ਸਾਰੇ ਨੋਡ ਅਤੇ ਉਹਨਾਂ ਦੇ ਪੈਰਾਮੀਟਰ ਸ਼ਾਮਲ ਹਨ।
ਇਸ ਸਮੇਂ ਇੱਕ ਨਵਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੇ ਕਲੱਸਟਰ ਨੋਡ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਾਰੇ ਸੇਵਾ ਕੰਟਰੋਲਰ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} ਕ੍ਰਮਵਾਰ.

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

ਵਿਚੋਲੇ

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

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

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

ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਡੇ ਕੋਲ "ਨਿਊਜ਼" ਵਿਸ਼ੇ ਦੇ 50000 ਗਾਹਕ ਹਨ। ਗਾਹਕਾਂ ਨੂੰ 5 ਸਰਵਰਾਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ 'ਤੇ ਪਹੁੰਚਣ ਵਾਲੇ ਹਰੇਕ ਅਪਡੇਟ ਨੂੰ 50000 ਵਾਰ ਦੁਹਰਾਇਆ ਜਾਵੇਗਾ: ਹਰੇਕ ਸਰਵਰ 'ਤੇ 10000 ਵਾਰ, ਇਸ 'ਤੇ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ ਦੇ ਅਨੁਸਾਰ। ਇੱਕ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਸਕੀਮ ਨਹੀਂ, ਠੀਕ ਹੈ?
ਸਥਿਤੀ ਨੂੰ ਸੁਧਾਰਨ ਲਈ, ਆਓ ਇੱਕ ਪ੍ਰੌਕਸੀ ਪੇਸ਼ ਕਰੀਏ ਜਿਸਦਾ ਨਾਮ ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਦੇ ਸਮਾਨ ਹੈ। ਗਲੋਬਲ ਨਾਮ ਰਜਿਸਟਰਾਰ ਨੂੰ ਨਾਮ ਦੁਆਰਾ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਪ੍ਰਕਿਰਿਆ ਵਾਪਸ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

ਰੂਟਿੰਗ ਅਤੇ ਸੰਤੁਲਨ

ਬੇਨਤੀ-ਜਵਾਬ

ਮੌਜੂਦਾ ਮੈਸੇਜਿੰਗ ਲਾਗੂ ਕਰਨ ਵਿੱਚ, 7 ਬੇਨਤੀ ਵੰਡ ਰਣਨੀਤੀਆਂ ਹਨ:

• default. ਬੇਨਤੀ ਸਾਰੇ ਕੰਟਰੋਲਰਾਂ ਨੂੰ ਭੇਜੀ ਜਾਂਦੀ ਹੈ।
• round-robin. ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕੰਟਰੋਲਰਾਂ ਵਿਚਕਾਰ ਚੱਕਰੀ ਤੌਰ 'ਤੇ ਵੰਡੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• consensus. ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਨਿਯੰਤਰਣ ਨੇਤਾਵਾਂ ਅਤੇ ਨੌਕਰਾਂ ਵਿੱਚ ਵੰਡੇ ਹੋਏ ਹਨ। ਲੀਡਰਾਂ ਨੂੰ ਹੀ ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• consensus & round-robin. ਸਮੂਹ ਦਾ ਇੱਕ ਆਗੂ ਹੈ, ਪਰ ਬੇਨਤੀਆਂ ਸਾਰੇ ਮੈਂਬਰਾਂ ਵਿੱਚ ਵੰਡੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।
• sticky. ਹੈਸ਼ ਫੰਕਸ਼ਨ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇੱਕ ਖਾਸ ਹੈਂਡਲਰ ਨੂੰ ਸੌਂਪੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਦਸਤਖਤ ਨਾਲ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਉਸੇ ਹੈਂਡਲਰ ਨੂੰ ਜਾਂਦੀਆਂ ਹਨ।
• sticky-fun. ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਸ਼ੁਰੂ ਕਰਨ ਵੇਲੇ, ਲਈ ਹੈਸ਼ ਕੈਲਕੂਲੇਸ਼ਨ ਫੰਕਸ਼ਨ sticky ਸੰਤੁਲਨ
• fun. ਸਟਿੱਕੀ-ਫਨ ਦੇ ਸਮਾਨ, ਸਿਰਫ ਤੁਸੀਂ ਇਸ ਨੂੰ ਰੀਡਾਇਰੈਕਟ, ਅਸਵੀਕਾਰ ਜਾਂ ਪ੍ਰੀ-ਪ੍ਰੋਸੈਸ ਕਰ ਸਕਦੇ ਹੋ।

ਵੰਡ ਦੀ ਰਣਨੀਤੀ ਉਦੋਂ ਸੈੱਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਐਕਸਚੇਂਜ ਪੁਆਇੰਟ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ।

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

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

ਪਬ-ਉਪ

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

ਮਾਪਯੋਗਤਾ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ

ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ ਸਿਸਟਮ ਦੀ ਮਾਪਯੋਗਤਾ ਸਿਸਟਮ ਦੀਆਂ ਲੇਅਰਾਂ ਅਤੇ ਭਾਗਾਂ ਦੀ ਮਾਪਯੋਗਤਾ ਦੀ ਡਿਗਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ:

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

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

ਰਿਜ਼ਰਵੇਸ਼ਨ

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

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

ਉਤਪਾਦਕਤਾ

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

ਪੈਰਾ 6.14.1.2.1.2.2 ਵਿੱਚ. ਅਸਲ ਦਸਤਾਵੇਜ਼ RPC CAST ਦਾ ਨਤੀਜਾ ਦਿਖਾਉਂਦਾ ਹੈ:

ਅਸੀਂ OS ਕਰਨਲ ਜਾਂ erlang VM ਲਈ ਪਹਿਲਾਂ ਤੋਂ ਕੋਈ ਵਾਧੂ ਸੈਟਿੰਗ ਨਹੀਂ ਕਰਾਂਗੇ। ਟੈਸਟ ਲਈ ਸ਼ਰਤਾਂ:

• erl opts: +A1 +sbtu.
• ਸਿੰਗਲ ਏਰਲੈਂਗ ਨੋਡ ਦੇ ਅੰਦਰ ਟੈਸਟ ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਵਿੱਚ ਇੱਕ ਪੁਰਾਣੇ i7 ਵਾਲੇ ਲੈਪਟਾਪ 'ਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ।
• ਕਲੱਸਟਰ ਟੈਸਟ 10G ਨੈੱਟਵਰਕ ਵਾਲੇ ਸਰਵਰਾਂ 'ਤੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
• ਕੋਡ ਡੌਕਰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। NAT ਮੋਡ ਵਿੱਚ ਨੈੱਟਵਰਕ।

ਟੈਸਟ ਕੋਡ:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

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

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

ਦ੍ਰਿਸ਼ 2: ਡੌਕਰ (NAT) ਦੇ ਅਧੀਨ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚੱਲ ਰਹੇ 3 ਨੋਡਸ।

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

ਸਾਰੇ ਮਾਮਲਿਆਂ ਵਿੱਚ, CPU ਉਪਯੋਗਤਾ 250% ਤੋਂ ਵੱਧ ਨਹੀਂ ਸੀ

ਨਤੀਜੇ

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

ਫੋਟੋਗ੍ਰਾਫੀ @chuttersnap

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

VTrade ਪ੍ਰਯੋਗ ਲੜੀ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਮੈਨੂੰ ਕਿਹੜੇ ਵਿਸ਼ਿਆਂ ਨੂੰ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

• ਥਿਊਰੀ: ਮਾਰਕਿਟ, ਆਰਡਰ ਅਤੇ ਉਹਨਾਂ ਦਾ ਸਮਾਂ: ਦਿਨ, ਜੀਟੀਡੀ, ਜੀਟੀਸੀ, ਆਈਓਸੀ, ਐਫਓਕੇ, ਐਮਓਓ, ਐਮਓਸੀ, ਲੋਓ, ਐਲਓਸੀ

• ਆਰਡਰ ਦੀ ਕਿਤਾਬ. ਸਮੂਹਾਂ ਦੇ ਨਾਲ ਇੱਕ ਕਿਤਾਬ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦਾ ਸਿਧਾਂਤ ਅਤੇ ਅਭਿਆਸ

• ਵਪਾਰ ਦੀ ਕਲਪਨਾ: ਟਿੱਕ, ਬਾਰ, ਰੈਜ਼ੋਲਿਊਸ਼ਨ। ਕਿਵੇਂ ਸਟੋਰ ਕਰਨਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਗੂੰਦ ਕਰਨਾ ਹੈ

• ਪਿਛਲਾ ਦਫਤਰ. ਯੋਜਨਾਬੰਦੀ ਅਤੇ ਵਿਕਾਸ. ਕਰਮਚਾਰੀ ਦੀ ਨਿਗਰਾਨੀ ਅਤੇ ਘਟਨਾ ਦੀ ਜਾਂਚ

• API। ਆਓ ਇਹ ਪਤਾ ਕਰੀਏ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ

• ਜਾਣਕਾਰੀ ਸਟੋਰੇਜ: ਵਪਾਰ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ PostgreSQL, Timescale, Tarantool

• ਵਪਾਰ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਪ੍ਰਤੀਕਿਰਿਆਸ਼ੀਲਤਾ

• ਹੋਰ। ਮੈਂ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖਾਂਗਾ

6 ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਵੋਟ ਪਾਈ। 4 ਉਪਭੋਗਤਾ ਪਰਹੇਜ਼ ਰਹੇ।

ਸਰੋਤ: www.habr.com