ਲੇਖ ਦਾ ਅਨੁਵਾਦ: ਦੂਤ ਥ੍ਰੈਡਿੰਗ ਮਾਡਲ - https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310

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

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

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

ਥ੍ਰੈਡਿੰਗ ਸੰਖੇਪ ਜਾਣਕਾਰੀ

ਰਾਜਦੂਤ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਧਾਰਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ:

• ਮੁੱਖ: ਇਹ ਥ੍ਰੈਡ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਸਮਾਪਤੀ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦਾ ਹੈ, XDS (xDiscovery ਸਰਵਿਸ) API ਦੀ ਸਾਰੀ ਪ੍ਰੋਸੈਸਿੰਗ, ਜਿਸ ਵਿੱਚ DNS, ਸਿਹਤ ਜਾਂਚ, ਜਨਰਲ ਕਲੱਸਟਰ ਅਤੇ ਰਨਟਾਈਮ ਪ੍ਰਬੰਧਨ, ਅੰਕੜੇ ਰੀਸੈਟ, ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਆਮ ਪ੍ਰਕਿਰਿਆ ਪ੍ਰਬੰਧਨ - ਲੀਨਕਸ ਸਿਗਨਲ ਹਾਟ ਰੀਸਟਾਰਟ, ਆਦਿ ਸਭ ਕੁਝ ਹੈ ਜੋ ਇਸ ਥਰਿੱਡ ਵਿੱਚ ਵਾਪਰਦਾ ਹੈ ਅਸਿੰਕ੍ਰੋਨਸ ਅਤੇ "ਨਾਨ-ਬਲਾਕਿੰਗ" ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਮੁੱਖ ਥ੍ਰੈਡ ਸਾਰੀਆਂ ਨਾਜ਼ੁਕ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦਾ ਤਾਲਮੇਲ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ CPU ਦੀ ਵੱਡੀ ਮਾਤਰਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਇਹ ਜ਼ਿਆਦਾਤਰ ਨਿਯੰਤਰਣ ਕੋਡ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਸਿੰਗਲ ਥਰਿੱਡਡ ਸਨ।
• ਕਾਮਾ: ਮੂਲ ਰੂਪ ਵਿੱਚ, ਦੂਤ ਸਿਸਟਮ ਵਿੱਚ ਹਰੇਕ ਹਾਰਡਵੇਅਰ ਥਰਿੱਡ ਲਈ ਇੱਕ ਵਰਕਰ ਥਰਿੱਡ ਬਣਾਉਂਦਾ ਹੈ, ਇਸਨੂੰ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਿਯੰਤਰਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ --concurrency. ਹਰੇਕ ਵਰਕਰ ਥ੍ਰੈਡ ਇੱਕ "ਨਾਨ-ਬਲੌਕਿੰਗ" ਇਵੈਂਟ ਲੂਪ ਚਲਾਉਂਦਾ ਹੈ, ਜੋ ਹਰ ਇੱਕ ਸਰੋਤੇ ਨੂੰ ਸੁਣਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ; ਲਿਖਣ ਦੇ ਸਮੇਂ (29 ਜੁਲਾਈ, 2017) ਸੁਣਨ ਵਾਲੇ ਦੀ ਕੋਈ ਵੰਡ ਨਹੀਂ ਹੁੰਦੀ, ਨਵੇਂ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ, ਇੱਕ ਫਿਲਟਰ ਸਟੈਕ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਕੁਨੈਕਸ਼ਨ, ਅਤੇ ਕੁਨੈਕਸ਼ਨ ਦੇ ਜੀਵਨ ਕਾਲ ਦੌਰਾਨ ਸਾਰੇ ਇੰਪੁੱਟ/ਆਉਟਪੁੱਟ (IO) ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ। ਦੁਬਾਰਾ ਫਿਰ, ਇਹ ਜ਼ਿਆਦਾਤਰ ਕਨੈਕਸ਼ਨ ਹੈਂਡਲਿੰਗ ਕੋਡ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਲਿਖਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਸਿੰਗਲ ਥਰਿੱਡਡ ਹੋਵੇ।
• ਫਾਈਲ ਫਲੱਸ਼ਰ: ਹਰੇਕ ਫਾਈਲ ਜੋ ਦੂਤ ਲਿਖਦਾ ਹੈ, ਮੁੱਖ ਤੌਰ 'ਤੇ ਲੌਗਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਦਾ ਹੈ, ਇਸ ਸਮੇਂ ਇੱਕ ਸੁਤੰਤਰ ਬਲੌਕਿੰਗ ਥਰਿੱਡ ਹੈ। ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੈ ਕਿ ਫਾਈਲ ਸਿਸਟਮ ਦੁਆਰਾ ਕੈਸ਼ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਲਿਖਣਾ ਭਾਵੇਂ ਵਰਤਣ ਵੇਲੇ O_NONBLOCK ਕਈ ਵਾਰ ਬਲੌਕ ਹੋ ਸਕਦਾ ਹੈ (ਸਾਹ)। ਜਦੋਂ ਵਰਕਰ ਥਰਿੱਡਾਂ ਨੂੰ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਲਿਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਡੇਟਾ ਅਸਲ ਵਿੱਚ ਮੈਮੋਰੀ ਵਿੱਚ ਇੱਕ ਬਫਰ ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਇਹ ਅੰਤ ਵਿੱਚ ਥਰਿੱਡ ਦੁਆਰਾ ਫਲੱਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਫਾਇਲ ਫਲੱਸ਼. ਇਹ ਕੋਡ ਦਾ ਇੱਕ ਖੇਤਰ ਹੈ ਜਿੱਥੇ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸਾਰੇ ਵਰਕਰ ਥਰਿੱਡ ਇੱਕ ਮੈਮੋਰੀ ਬਫਰ ਨੂੰ ਭਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ ਇੱਕੋ ਲਾਕ ਨੂੰ ਬਲੌਕ ਕਰ ਸਕਦੇ ਹਨ।

ਕਨੈਕਸ਼ਨ ਹੈਂਡਲਿੰਗ

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

ਇਸ ਦੇ ਕਈ ਮਹੱਤਵਪੂਰਨ ਨਤੀਜੇ ਹਨ:

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

ਗੈਰ-ਬਲੌਕ ਕਰਨ ਦਾ ਕੀ ਮਤਲਬ ਹੈ?

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

ਦੂਤ ਕਈ ਲੰਬੇ ਪ੍ਰਕਿਰਿਆ ਲਾਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ:

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

ਥਰਿੱਡ ਸਥਾਨਕ ਸਟੋਰੇਜ਼

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


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

ਰਾਜਦੂਤ ਦਾ TLS (ਥ੍ਰੈਡ ਲੋਕਲ ਸਟੋਰੇਜ) ਸਿਸਟਮ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ:

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

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

ਰਾਜਦੂਤ ਇਸ ਨੂੰ ਦੋ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਵਰਤਦਾ ਹੈ:

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

ਕਲੱਸਟਰ ਅੱਪਡੇਟ ਥ੍ਰੈਡਿੰਗ

ਇਸ ਭਾਗ ਵਿੱਚ, ਮੈਂ ਵਰਣਨ ਕਰਾਂਗਾ ਕਿ ਇੱਕ ਕਲੱਸਟਰ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ TLS (ਥ੍ਰੈਡ ਲੋਕਲ ਸਟੋਰੇਜ) ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਕਲੱਸਟਰ ਪ੍ਰਬੰਧਨ ਵਿੱਚ xDS API ਅਤੇ/ਜਾਂ DNS ਪ੍ਰੋਸੈਸਿੰਗ, ਨਾਲ ਹੀ ਸਿਹਤ ਜਾਂਚ ਸ਼ਾਮਲ ਹੈ।


ਕਲੱਸਟਰ ਪ੍ਰਵਾਹ ਪ੍ਰਬੰਧਨ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗ ਅਤੇ ਕਦਮ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:

1. ਕਲੱਸਟਰ ਮੈਨੇਜਰ ਦੂਤ ਦੇ ਅੰਦਰ ਇੱਕ ਭਾਗ ਹੈ ਜੋ ਸਾਰੇ ਜਾਣੇ-ਪਛਾਣੇ ਕਲੱਸਟਰ ਅੱਪਸਟ੍ਰੀਮ, ਕਲੱਸਟਰ ਡਿਸਕਵਰੀ ਸਰਵਿਸ (CDS) API, ਸੀਕਰੇਟ ਡਿਸਕਵਰੀ ਸਰਵਿਸ (SDS) ਅਤੇ ਐਂਡਪੁਆਇੰਟ ਡਿਸਕਵਰੀ ਸਰਵਿਸ (EDS) API, DNS, ਅਤੇ ਸਰਗਰਮ ਬਾਹਰੀ ਜਾਂਚਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦਾ ਹੈ। ਇਹ ਹਰੇਕ ਅੱਪਸਟਰੀਮ ਕਲੱਸਟਰ ਦਾ "ਅੰਤ ਵਿੱਚ ਇਕਸਾਰ" ਦ੍ਰਿਸ਼ ਬਣਾਉਣ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਜਿਸ ਵਿੱਚ ਖੋਜੇ ਗਏ ਮੇਜ਼ਬਾਨਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਸਿਹਤ ਸਥਿਤੀ ਵੀ ਸ਼ਾਮਲ ਹੈ।
2. ਸਿਹਤ ਜਾਂਚਕਰਤਾ ਇੱਕ ਸਰਗਰਮ ਸਿਹਤ ਜਾਂਚ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰ ਮੈਨੇਜਰ ਨੂੰ ਸਿਹਤ ਸਥਿਤੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ।
3. CDS (ਕਲੱਸਟਰ ਡਿਸਕਵਰੀ ਸਰਵਿਸ) / SDS (ਗੁਪਤ ਖੋਜ ਸੇਵਾ) / EDS (ਐਂਡਪੁਆਇੰਟ ਡਿਸਕਵਰੀ ਸਰਵਿਸ) / DNS ਕਲੱਸਟਰ ਮੈਂਬਰਸ਼ਿਪ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਰਾਜ ਦੀ ਤਬਦੀਲੀ ਕਲੱਸਟਰ ਮੈਨੇਜਰ ਨੂੰ ਵਾਪਸ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
4. ਹਰੇਕ ਵਰਕਰ ਥ੍ਰੈਡ ਲਗਾਤਾਰ ਇੱਕ ਇਵੈਂਟ ਲੂਪ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।
5. ਜਦੋਂ ਕਲੱਸਟਰ ਮੈਨੇਜਰ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਬਦਲ ਗਈ ਹੈ, ਤਾਂ ਇਹ ਕਲੱਸਟਰ ਦੀ ਸਥਿਤੀ ਦਾ ਇੱਕ ਨਵਾਂ ਰੀਡ-ਓਨਲੀ ਸਨੈਪਸ਼ਾਟ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਹਰੇਕ ਵਰਕਰ ਥ੍ਰੈਡ ਨੂੰ ਭੇਜਦਾ ਹੈ।
6. ਅਗਲੀ ਸ਼ਾਂਤ ਮਿਆਦ ਦੇ ਦੌਰਾਨ, ਵਰਕਰ ਥ੍ਰੈਡ ਨਿਰਧਾਰਤ TLS ਸਲਾਟ ਵਿੱਚ ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਅੱਪਡੇਟ ਕਰੇਗਾ।
7. ਇੱਕ I/O ਇਵੈਂਟ ਦੇ ਦੌਰਾਨ ਜੋ ਹੋਸਟ ਨੂੰ ਬੈਲੇਂਸ ਲੋਡ ਕਰਨ ਲਈ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੈ, ਲੋਡ ਬੈਲੇਂਸਰ ਮੇਜ਼ਬਾਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ TLS (ਥ੍ਰੈਡ ਲੋਕਲ ਸਟੋਰੇਜ) ਸਲਾਟ ਦੀ ਬੇਨਤੀ ਕਰੇਗਾ। ਇਸ ਲਈ ਤਾਲੇ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ TLS ਅੱਪਡੇਟ ਇਵੈਂਟਾਂ ਨੂੰ ਵੀ ਟਰਿੱਗਰ ਕਰ ਸਕਦਾ ਹੈ ਤਾਂ ਕਿ ਲੋਡ ਬੈਲੰਸਰ ਅਤੇ ਹੋਰ ਕੰਪੋਨੈਂਟ ਕੈਚਾਂ, ਡਾਟਾ ਸਟ੍ਰਕਚਰ ਆਦਿ ਦੀ ਮੁੜ ਗਣਨਾ ਕਰ ਸਕਣ। ਇਹ ਇਸ ਪੋਸਟ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਹੈ, ਪਰ ਕੋਡ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

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

ਹੋਰ ਉਪ-ਸਿਸਟਮ ਜੋ TLS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ

TLS (ਥ੍ਰੈੱਡ ਲੋਕਲ ਸਟੋਰੇਜ਼) ਅਤੇ RCU (ਰੀਡ ਕਾਪੀ ਅੱਪਡੇਟ) ਨੂੰ ਦੂਤ ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਵਰਤੋਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ:

• ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੌਰਾਨ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਬਦਲਣ ਲਈ ਵਿਧੀ: ਸਮਰਥਿਤ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦੀ ਮੌਜੂਦਾ ਸੂਚੀ ਨੂੰ ਮੁੱਖ ਥ੍ਰੈਡ ਵਿੱਚ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ। ਹਰੇਕ ਵਰਕਰ ਥ੍ਰੈਡ ਨੂੰ ਫਿਰ RCU ਸਿਮੈਂਟਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਰੀਡ-ਓਨਲੀ ਸਨੈਪਸ਼ਾਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
• ਰੂਟ ਟੇਬਲ ਨੂੰ ਬਦਲਣਾ: RDS (ਰੂਟ ਡਿਸਕਵਰੀ ਸਰਵਿਸ) ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਰੂਟ ਟੇਬਲਾਂ ਲਈ, ਰੂਟ ਟੇਬਲ ਮੁੱਖ ਥਰਿੱਡ 'ਤੇ ਬਣਾਏ ਗਏ ਹਨ। RCU (Read Copy Update) ਸਿਮੈਂਟਿਕਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹਰੇਕ ਵਰਕਰ ਥ੍ਰੈਡ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਲਈ ਸਨੈਪਸ਼ਾਟ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਹ ਬਦਲਦੇ ਹੋਏ ਰੂਟ ਟੇਬਲ ਨੂੰ ਪ੍ਰਮਾਣੂ ਤੌਰ 'ਤੇ ਕੁਸ਼ਲ ਬਣਾਉਂਦਾ ਹੈ।
• HTTP ਹੈਡਰ ਕੈਚਿੰਗ: ਜਿਵੇਂ ਕਿ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਹਰੇਕ ਬੇਨਤੀ ਲਈ HTTP ਸਿਰਲੇਖ ਦੀ ਗਣਨਾ ਕਰਨਾ (~ 25K+ RPS ਪ੍ਰਤੀ ਕੋਰ ਚਲਾਉਂਦੇ ਹੋਏ) ਕਾਫ਼ੀ ਮਹਿੰਗਾ ਹੈ। ਰਾਜਦੂਤ ਕੇਂਦਰੀ ਤੌਰ 'ਤੇ ਹੈਡਰ ਦੀ ਲਗਭਗ ਹਰ ਅੱਧੇ ਸਕਿੰਟ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ TLS ਅਤੇ RCU ਰਾਹੀਂ ਹਰੇਕ ਕਰਮਚਾਰੀ ਨੂੰ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਹੋਰ ਵੀ ਕੇਸ ਹਨ, ਪਰ ਪਿਛਲੀਆਂ ਉਦਾਹਰਣਾਂ ਨੂੰ ਇਸ ਗੱਲ ਦੀ ਚੰਗੀ ਸਮਝ ਪ੍ਰਦਾਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਕਿ TLS ਦੀ ਵਰਤੋਂ ਕਿਸ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਜਾਣੇ-ਪਛਾਣੇ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਨੁਕਸਾਨ

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

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

ਸਿੱਟਾ

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

ਕੋਡ ਲਈ ਲਿੰਕ

ਇਸ ਪੋਸਟ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਇੰਟਰਫੇਸ ਅਤੇ ਸਿਰਲੇਖ ਲਾਗੂ ਕਰਨ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਦੇ ਲਿੰਕ:

• github.com/lyft/envoy/blob/master/include/envoy/thread_local/thread_local.h
• github.com/lyft/envoy/blob/master/source/common/thread_local/thread_local_impl.h
• github.com/lyft/envoy/blob/master/include/envoy/upstream/cluster_manager.h
• github.com/lyft/envoy/blob/master/source/common/upstream/cluster_manager_impl.h

ਸਰੋਤ: www.habr.com