ਪਤਾ ਕਰੋ ਕਿ Joe Armstrong ਨੇ Erlang ਦੀ concurrency, supervision ਅਤੇ “let it crash” ਸੋਚ ਨੂੰ ਕਿਵੇਂ ਰੂਪ ਦਿੱਤਾ—ਉਹ ਵਿਚਾਰ ਅਜੇ ਵੀ ਭਰੋਸੇਯੋਗ ਰੀਅਲ-ਟਾਈਮ ਸੇਵਾਵਾਂ ਬਣਾਉਣ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ।
Joe Armstrong ਨੇ ਸਿਰਫ Erlang ਬਣਾਇਆ ਹੀ ਨਹੀਂ — ਉਹ ਇਸਦਾ ਸਭ ਤੋਂ ਸਪਸ਼ਟ ਅਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵਿਆਖਿਆਕਾਰ ਬਣ ਕੇ ਰਹਿ ਗਏ। ਟਾਕਸ, ਪੇਪਰਾਂ ਅਤੇ ਇੱਕ ਪ੍ਰਜ਼ਗਮੈਟਿਕ ਨਜ਼ਰੀਏ ਦੁਆਰਾ ਉਹਨਾ ਨੇ ਇੱਕ ਸਧਾਰਣ خیال ਨੂੰ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ: ਜੇ ਤੁਸੀਂ ਉਹ ਸੋਫਟਵੇਅਰ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਚੱਲਦਾ ਰਹੇ, ਤਾਂ ਤਕਨਾਲੋਜੀ ਨੂੰ ਅਸਫਲਤਾ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ ਨਾ ਕਿ ਇਹ ਸੋਚੋ ਕਿ ਤੁਸੀਂ ਅਸਫਲਤਾ ਤੋਂ ਬਚ ਸਕੋਗੇ।
ਇਹ ਪੋਸਟ Erlang ਦੀ ਸੋਚ ਦਾ ਇੱਕ ਰਾਹ-ਦਰਸ਼ਨ ਹੈ ਅਤੇ ਦਿਖਾਉਂਦੀ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਭਰੋਸੇਯੋਗ ਰੀਅਲ-ਟਾਈਮ ਪਲੇਟਫਾਰਮ ਬਣਾਉਂਦੇ ਹੋ ਤਾਂ ਇਹ ਕਿਉਂ ਅਹਿਮ ਹੈ — ਜਿਵੇਂ ਕਿ ਚੈਟ ਸਿਸਟਮ, ਕਾਲ ਰੂਟਿੰਗ, ਲਾਈਵ ਨੋਟੀਫਿਕੇਸ਼ਨ, ਮਲਟੀਪਲੇਅਰ ਕੋਆਰਡੀਨੇਸ਼ਨ ਅਤੇ ਉਹ ਇੰਫ੍ਰਾਸਟਰੱਕਚਰ ਜੋ ਤੇਜ਼ੀ ਅਤੇ ਲਗਾਤਾਰ ਜਵਾਬ ਦੇ ਸਕਦੇ ਹਨ ਭਾਵੇਂ ਕੁਝ ਹਿੱਸੇ ਗਲਤ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋਣ।
ਰੀਅਲ-ਟਾਈਮ ਹਰ ਵੇਲੇ “ਮਾਇਕ੍ਰੋਸੈਕਿੰਡ” ਜਾਂ “ਹਾਰਡ ਡੈੱਡਲਾਈਨ” ਨਹੀਂ ਹੁੰਦਾ। ਕਈ ਪ੍ਰੋਡਕਟਾਂ ਵਿੱਚ ਇਸਦਾ ਮਤਲਬ ਹੁੰਦਾ ਹੈ:
Erlang ਟੈਲੀਕੋਮ ਸਿਸਟਮਾਂ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ ਜਿੱਥੇ ਇਹ ਉਮੀਦਾਂ ਬਿਨਾ ਗੱਲ-ਬਾਤ ਦੇ ਮੰਨੀਆਂ ਜਾਂਦੀਆਂ ਸਨ — ਅਤੇ ਇਹ ਦਬਾਅ ਇਸ ਦੇ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵਿਚਾਰਾਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ।
ਸਿੰਟੈਕਸ ਵਿੱਚ ਡਿੱਠੇ ਬਿਨਾਂ, ਅਸੀਂ ਉਹ ਧਾਰਨਾਵਾਂ 'ਤੇ ਧਿਆਨ ਦੇਵਾਂਗੇ ਜਿਨ੍ਹਾਂ ਨੇ Erlang ਨੂੰ ਮਸ਼ਹੂਰ ਕੀਤਾ ਅਤੇ ਜੋ ਅਧੁਨਿਕ ਸਿਸਟਮ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਵਾਪਸ-ਵਾਪਸ ਆ ਰਹੀਆਂ ਹਨ:
ਇਸ ਰਾਹ 'ਤੇ ਅਸੀਂ actor ਮਾਡਲ ਅਤੇ ਮੇਸੇਜ ਪਾਸਿੰਗ ਨਾਲ ਜੋੜਾਂਗੇ, ਸੁਪਰਵਾਈਜ਼ਨ ਟਰੀਆਂ ਅਤੇ OTP ਨੂੰ ਸਧਾਰਣ ਸ਼ਬਦਾਂ ਵਿੱਚ ਸਮਝਾਵਾਂਗੇ, ਅਤੇ ਦਿਖਾਵਾਂਗੇ ਕਿ BEAM VM ਸਾਰੇ ਤਰੀਕੇ ਨੂੰ ਪ੍ਰਾਇਕਟੀਕਲ ਕਿਵੇਂ ਬਣਾਉਂਦਾ ਹੈ।
ਭਾਵੇਂ ਤੁਸੀਂ Erlang ਨਹੀਂ ਵਰਤ ਰਹੇ (ਅਤੇ ਸ਼ਾਇਦ ਕਦੇ ਨਹੀਂ ਵਰਤੋਂਗੇ), Armstrong ਦੀ ਰੇਖਾ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਤਾਕਤਵਰ ਚੈਕਲਿਸਟ ਦਿੰਦੀ ਹੈ ਜੋ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਜੋ ਗੰਦੇ ਹਾਲਾਤਾਂ ਵਿੱਚ ਵੀ ਜਵਾਬਦੇਹ ਅਤੇ ਉਪਲਬਧ ਰਹਿੰਦੇ ਹਨ।
ਟੈਲੀਕੋਮ ਸੁਇਚਾਂ ਅਤੇ ਕਾਲ-ਰੂਟਿੰਗ ਪਲੇਟਫਾਰਮ ਉਹ ਨਹੀਂ ਜਿਹੜੇ "ਮੇਨਟੇਨੈਂਸ ਲਈ ਡਾਊਨ" ਹੋ ਸਕਦੇ। ਉਹਨਾਂ ਤੋਂ ਉਮੀਦ ਰਹਿੰਦੀ ਹੈ ਕਿ ਉਹ calls, billing events ਅਤੇ signaling ਟ੍ਰੈਫਿਕ ਨੂੰ ਰਾਤ-ਦਿਨ ਹੈਂਡਲ ਕਰਨ — ਅਕਸਰ availability ਅਤੇ ਪੇਸ਼ਗੋਈ ਯੋਗ ਜਵਾਬ ਸਮੇਂ ਲਈ ਕਠੋਰ ਮਾਪਦੰਡਾਂ ਦੇ ਨਾਲ।
Erlang 1980s ਦੇ ਆਖਰੀ ਦਹਾਕੇ ਵਿੱਚ Ericsson ਦੇ ਅੰਦਰ ਇੱਕ ਕੋਸ਼ਿਸ਼ ਵਜੋਂ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ ਜਿਸਦਾ ਮਕਸਦ ਇਹ ਅਸਲੀਅਤਾਂ ਸਾਫਟਵੇਅਰ ਨਾਲ ਮਿਲਕੇ ਪੂਰੀਆਂ ਕਰਨੀ ਸਨ, ਨਾ ਕਿ ਸਿਰਫ਼ ਵਿਸ਼ੇਸ਼ ਹਾਰਡਵੇਅਰ। Joe Armstrong ਤੇ ਉਸਦੇ ਸਹਯੋਗੀ ਸੁੰਦਰਤਾ ਲਈ ਨਹੀਂ, ਬਲਕਿ ਓਹ ਪਰਯਾਪਤ ਤੌਰ ਤੇ ਅਜਿਹੇ ਸਿਸਟਮ ਬਣਾਉਣ ਲਈ ਸੋਚ ਰਹੇ ਸਨ ਜਿਸ 'ਤੇ ਆਪਰੇਟर्स ਭਰੋਸਾ ਕਰ ਸਕਣ — ਲਗਾਤਾਰ ਲੋਡ, ਅੰਸ਼ਿਕ ਫੇਲ੍ਹਰ ਅਤੇ ਅਸਲੀ ਦੁਨੀਆ ਦੀ ਗੜਬੜ ਦੇ ਬਾਵਜੂਦ।
ਸੋਚ ਵਿੱਚ ਇੱਕ ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਸੀ ਕਿ ਯਕੀਨ ਨੂੰ "ਕਦੇ ਫੇਲ੍ਹ ਨਾ ਹੋਣਾ" ਦੇ ਨਾਲ ਸਮਾਨ ਨਾ ਕੀਤਾ ਜਾਵੇ। ਵੱਡੇ, ਲੰਬੇ ਚਲਣ ਵਾਲੇ ਸਿਸਟਮਾਂ ਵਿੱਚ ਕੁਝ ਨਾ ਕੁਝ ਫੇਲ੍ਹ ਹੋਵੇਗਾ: ਇੱਕ ਪ੍ਰੋਸੈਸ ਅਣਛਾਹੀ ਇਨਪੁਟ ਉੱਤੇ ਲੱਗ ਸਕਦਾ ਹੈ, ਇੱਕ ਨੋਡ ਰੀਬੂਟ ਹੋ ਸਕਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਲਿੰਕ ਝਟਕਾ ਖਾ ਸਕਦੀ ਹੈ, ਜਾਂ ਇੱਕ ਡੀਪੈਂਡੇੰਸੀ ਸਟਾਲ ਹੋ ਸਕਦੀ ਹੈ।
ਤਾਂ ਲਕਸ਼ਯ ਬਣਦਾ ਹੈ:
ਇਹੀ ਮਨੋਭਾਵ ਬਾਅਦ ਵਿੱਚ ਸੁਪਰਵਾਈਜ਼ਨ ਟਰੀਆਂ ਅਤੇ “let it crash” ਵਰਗੀਆਂ ਵਿਚਾਰਾਂ ਨੂੰ ਵਾਜਬ ਬਣਾਉਂਦਾ ਹੈ: ਤੁਸੀਂ ਅਸਫਲਤਾ ਨੂੰ ਇੱਕ ਆਮ ਘਟਨਾ ਮੰਨ ਕੇ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ ਇੱਕ ਭਾਰੀ ਬਿਪਤਾ।
ਇਹ ਕਹਾਣੀ ਇੱਕ ਇੱਕਦਰਸ਼ ਮਹਾਨ ਵਿਜ਼ਨਰੀ ਦੀ ਉਪਲਬਧੀ ਵਾਂਗ ਨਹੀਂ ਦਿਸ਼ ਰਹੀ — ਬਦلے ਵਿੱਚ ਸਭ ਤੋਂ ਵਰਤੋਂਯੋਗ ਨਜ਼ਰੀਆ ਸਧਾਰਨ ਹੈ: ਟੈਲੀਕੋਮ ਦੀਆਂ ਮੰਗਾਂ ਨੇ ਵੱਖਰੇ ਤਰ੍ਹਾਂ ਦੇ ਟਰੇਡ-ਆਫ਼ਾਂ ਨੂੰ ਜਨਮ ਦਿੱਤਾ। Erlang ਨੇ concurrency, isolation ਅਤੇ recovery ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਕਿਉਂਕਿ ਇਹ ਉਹ ਪ੍ਰਾਇਗਟਿਕ ਟੂਲ ਸਨ ਜੋ ਸੇਵਾਵਾਂ ਨੂੰ ਚੱਲਦੇ ਰੱਖਣ ਲਈ ਲੋਜ਼ਮੀ ਸਨ ਜਦੋਂ ਦੁਨੀਆ ਬਦਲ ਰਹੀ ਸੀ।
ਇਹ ਸਮੱਸਿਆ-ਪਹਿਲਾ ਫ੍ਰੇਮ Erlang ਦੇ ਸਬਕਾਂ ਨੂੰ ਅੱਜ ਵੀ ਬਹੁਤ ਜਗ੍ਹਾ ਵਰਤਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ—ਜਿੱਥੇ uptime ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰੀ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੇ ਹਨ।
Erlang ਦੀ ਇੱਕ ਮੁੱਖ ਧਾਰਣਾ ਇਹ ਹੈ ਕਿ "ਕਈ ਕੰਮ ਇੱਕਠੇ ਕਰਨਾ" ਕੋਈ ਖਾਸ ਫੀਚਰ ਨਹੀਂ ਜੋ ਤਦੋਂ ਜੋੜਿਆ ਜਾਵੇ — ਇਹ ਉਹ ਆਮ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਸਿਸਟਮ ਨੂੰ ਬਣਾਉਂਦੇ ਹੋ।
Erlang ਵਿੱਚ ਕੰਮ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ “ਪ੍ਰੋਸੈਸ” ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਛੋਟੇ ਵਰਕਰ ਸੋਚੋ, ਹਰ ਇੱਕ ਇਕ ਕੰਮ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲਈ: ਇੱਕ ਫੋਨ ਕਾਲ ਸੰਭਾਲਣਾ, ਇੱਕ ਚੈਟ ਸੈਸ਼ਨ ਟਰੈਕ ਕਰਨਾ, ਇੱਕ ਡਿਵਾਈਸ ਨਿਗਰਾਨੀ ਕਰਨਾ, ਪੇਮੈਂਟ ਨੂੰ ਰੀਟ੍ਰਾਈ ਕਰਨਾ, ਜਾਂ ਇੱਕ ਕਿਊ ਵੇਖਣਾ।
ਉਹ ਲਾਈਟਵੇਟ ਹੁੰਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਨਾਂ ਵੱਡੇ ਹਾਰਡਵੇਅਰ ਦੀ ਲੋੜ ਦੇ ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਸੈਸ ਚਲਾ ਸਕਦੇ ਹੋ। ਇੱਕ ਭਾਰੀ ਵਰਕਰ ਦੇ ਮੁਕਾਬਲੇ, ਤਤਕਾਲ ਸ਼ੁਰੂ ਹੋਣ, ਬੰਦ ਹੋਣ, ਅਤੇ ਬਦਲਣ ਦੀ ਯੋਗਤਾ ਨਾਲ ਤੁਹਾਨੂੰ ਘਣੇ ਧਿਆਨਕੇਂਦ੍ਰਿਤ ਵਰਕਰ ਮਿਲਦੇ ਹਨ।
ਕਈ ਸਿਸਟਮ ਇਕ ਵੱਡੇ ਪ੍ਰੋਗਰਾਮ ਦੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਕਈ ਹਿੱਸੇ ਨੇੜੇ ਜੁੜੇ ਹੁੰਦੇ ਹਨ। ਜਦੋਂ ਐਸੇ ਸਿਸਟਮ ਨੂੰ ਕੋਈ ਗੰਭੀਰ ਬੱਗ, ਮੈਮੋਰੀ ਮੁੱਦਾ, ਜਾਂ ਬਲਾਕਿੰਗ ਆਪਰੇਸ਼ਨ ਮਿਲਦਾ ਹੈ, ਤਾਂ ਫੇਲ੍ਹ ਸਕਾਰਾਤਮਕ ਤਰੀਕੇ ਨਾਲ ਫੈਲ ਸਕਦਾ ਹੈ—ਜਿਵੇਂ ਇੱਕ ਬ੍ਰੇਕਰ ਦੇ ਝਟਕੇ ਨਾਲ ਸਾਰਾ ਬਿਲਡਿੰਗ ਬਲੈਕ ਆਉਟ ਹੋ ਜਾਵੇ।
Erlang ਵਿਰੋਧੀ ਦਿਸ਼ਾ ਦਿਖਾਉਂਦਾ ਹੈ: ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਅਲੱਗ ਕਰੋ। ਜੇ ਇੱਕ ਛੋਟਾ ਵਰਕਰ ਗਲਤ ਆਚਰਨ ਕਰਦਾ ਹੈ, ਤੁਸੀਂ ਉਸ ਨੂੰ ਬਿਨਾਂ ਅਸਬੰਧਤ ਕੰਮ ਨੂੰ ਡਾਊਨ ਕੀਤੇ ਬਦਲ ਸਕਦੇ ਹੋ।
ਇਹ ਵਰਕਰ ਅਪਸ ਵਿੱਚ ਸਹੀ ਰੂਪ ਵਿੱਚ ਕਿਵੇਂ ਕੋਆਰਡੀਨੇਟ ਕਰਦੇ ਹਨ? ਉਹ ਇਕ ਦੂਜੇ ਦੀ ਅੰਦਰਲੀ ਸਥਿਤੀ ਵਿੱਚ ਦਖਲ ਨਹੀਂ ਦਿੰਦੇ। ਉਹ ਮੇਸੇਜ ਭੇਜਦੇ ਹਨ—ਇੱਕ ਗੱਲ-ਬਾਤ ਜਿਆਦਾ ਨੋਟ ਭੇਜਣ ਵਰਗੀ ਹੈ ਨਾ ਕਿ ਗਲਤ-ਭਰਿਆ ਵਾਈਟਬੋਰਡ ਚੇਤਾਵਨੀ।
ਇੱਕ ਵਰਕਰ ਕਹਿ ਸਕਦਾ ਹੈ, “ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਹੈ,” “ਇਹ ਯੂਜ਼ਰ ਡਿਸਕਨੈਕਟ ਹੋ ਗਿਆ,” ਜਾਂ “5 ਸੈਕਿੰਡ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ।” ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲਾ ਵਰਕਰ ਨੋਟ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਫੈਸਲਾ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਲਾਭ ਇਹ ਹੈ ਕਿ ਕਿਉਂਕਿ ਵਰਕਰ ਅਲੱਗ ਹਨ ਅਤੇ ਮੇਸੇਜ ਦੁਆਰਾ ਸੰਚਾਰ ਕਰਦੇ ਹਨ, ਫੇਲ੍ਹਰ ਸਾਰੇ ਸਿਸਟਮ ਵਿੱਚ ਵੱਧਣ ਦੀ ਸੰਭਾਵਨਾ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
Erlang ਦੇ “ਐਕਟਰ ਮਾਡਲ” ਨੂੰ ਸਮਝਣ ਦਾ ਇੱਕ ਸਧਾਰਣ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਸਿਸਟਮ ਨੂੰ ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ, ਸੁਤੰਤਰ ਵਰਕਰਾਂ ਦੀ ਤਸਵੀਰ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚੋ।
ਇਕ ਐਕਟਰ ਆਪਣੀ ਨਿੱਜੀ ਸਥਿਤੀ ਅਤੇ ਇੱਕ ਮੇਲਬਾਕਸ ਨਾਲ ਇੱਕ ਸੁਤੰਤਰ ਇਕਾਈ ਹੁੰਦਾ ਹੈ। ਇਹ ਤਿੰਨ ਮੁੱਖ ਕੰਮ ਕਰਦਾ ਹੈ:
ਬਸ ਇੰਨਾ ਹੀ। ਕੋਈ ਛੁਪਿਆ ਹੋਇਆ ਸਾਂਝਾ ਵੇਰੀਏਬਲ ਨਹੀਂ, ਕੋਈ “ਦੂਜੇ ਵਰਕਰ ਦੀ ਮੈਮੋਰੀ ਵਿੱਚ ਦਾਖ਼ਲ” ਨਹੀਂ। ਜੇ ਇੱਕ ਐਕਟਰ ਨੂੰ ਦੂਜੇ ਤੋਂ ਕੁੱਝ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਮੇਸੇਜ ਭੇਜ ਕੇ ਮੰਗਦਾ ਹੈ।
ਜਦੋਂ ਇਕੱਠੇ ਧਾਗੇ ਇੱਕੋ ਡੇਟਾ ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਤਦ ਸੀਮਾਂ 'ਤੇ race conditions ਆ ਸਕਦੀਆਂ ਹਨ: ਦੋ ਚੀਜ਼ਾਂ ਲਗਭਗ ਇਕੋ ਸਮੇਂ ਇੱਕੋ ਹੀ ਵੈਲਯੂ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ, ਅਤੇ ਨਤੀਜਾ ਸਮੇਂ ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਬੱਗਾਂ ਦਾ ਰੁਪ ਹੈ ਜੋ ਅਕਸਮਾਤ ਅਤੇ ਮੁਸ਼ਕਲ ਦੁਹਰਾਏ ਜਾਂਦੇ ਹਨ।
ਮੇਸੇਜ ਪਾਸਿੰਗ ਨਾਲ, ਹਰ ਐਕਟਰ ਆਪਣੇ ਡੇਟਾ ਦਾ ਮਾਲਿਕ ਹੁੰਦਾ ਹੈ। ਹੋਰ ਐਕਟਰ ਇਸ ਨੂੰ ਸਿੱਧਾ ਬਦਲ ਨਹੀਂ ਕਰ ਸਕਦੇ। ਇਹ ਹਰ ਬੱਗ ਨਹੀਂ ਖਤਮ ਕਰਦਾ, ਪਰ ਇੱਕੋ ਹੀ ਟੁਕੜੇ ਸਟੇਟ ਦੀ ਸਮਕਾਲੀ ਪਹੁੰਚ ਕਾਰਨ ਹੋਣ ਵਾਲੇ ਮੁੱਦਿਆਂ ਨੂੰ ਬਹੁਤ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਮੇਸੇਜ "ਮੁਫ਼ਤ" ਨਹੀਂ ਆਉਂਦੇ। ਜੇ ਕੋਈ ਐਕਟਰ ਵੇਖਦਾ ਹੈ ਕਿ ਉਸ ਨੂੰ ਉਸਦੀ ਸਮਰੱਥਾ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮੇਸੇਜ ਮਿਲ ਰਹੇ ਹਨ, ਤਾਂ ਉਸਦੀ ਮੇਲਬਾਕਸ (ਕਿਊ) ਵੱਧ ਜਾਂਦੀ ਹੈ। ਇਹੀ ਬੈਕ-ਪ੍ਰੈਸ਼ਰ ਹੈ: ਸਿਸਟਮ ਨਿਸ਼ਾਨਾ ਦਿੰਦਾ ਹੈ, “ਇਹ ਹਿੱਸਾ ਓਵਰਲੋਡ ਹੋ ਰਿਹਾ ਹੈ।”
ਅਮਲ ਵਿੱਚ, ਤੁਸੀਂ ਮੇਲਬਾਕਸ ਸਾਈਜ਼ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹੋ ਅਤੇ ਸੀਮਾਵਾਂ ਬਣਾਉਂਦੇ ਹੋ: ਲੋਡ ਛੱਡਣਾ, ਬੈਚਿੰਗ, ਸੈਂਪਲਿੰਗ, ਜਾਂ ਕੰਮ ਨੂੰ ਹੋਰ ਵਰਕਰਾਂ 'ਤੇ ਧੱਕਣਾ ਤਾਂ ਕਿ ਕਿਊਆਂ ਅਨੰਤ ਤੱਕ ਨਾ ਵਧਣ।
ਇੱਕ ਚੈਟ ਐਪ ਦੀ ਕਲਪਨਾ ਕਰੋ। ਹਰ ਯੂਜ਼ਰ ਲਈ ਇੱਕ ਐਕਟਰ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਦੀ ਡਿਲਿਵਰੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ ਯੂਜ਼ਰ ਆਫ਼ਲਾਈਨ ਹੋ ਜਾਂਦਾ ਹੈ, ਸੁਨੇਹੇ ਆਉਂਦੇ ਰਹਿਣਗੇ—ਤਾਂ ਮੇਲਬਾਕਸ ਵਧੇਗਾ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਸਿਸਟਮ ਕਿਊ ਦੀ ਸੀਮਾ ਲਗਾ ਸਕਦਾ ਹੈ, ਗੈਰ-ਜ਼ਰੂਰੀ ਨੋਟੀਫਿਕੇਸ਼ਨਾਂ ਨੂੰ ਡ੍ਰੌਪ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਡਾਈਜੇਸਟ ਮੋਡ 'ਤੇ ਚਲ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਢੀਲਾ ਯੂਜ਼ਰ ਪੂਰੇ ਸਰਵਿਸ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰੇ।
“Let it crash” ਢੀਠ ਕੋਡਿੰਗ ਲਈ ਨਾਰੀ ਨਹੀ ਹੈ। ਇਹ ਇੱਕ ਰਿਲਾਇਬਿਲਟੀ ਰਣਨੀਤੀ ਹੈ: ਜੇ ਕੋਈ ਹਿੱਸਾ ਬੁਰੇ ਜਾਂ ਅਣਉਮੀਦਿਤ ਸਟੇਟ 'ਚ ਪਹੁੰਚ ਜਾਵੇ, ਉਨ੍ਹੇ ਨੂੰ ਚੀੜ੍ਹ-ਚਿੜ੍ਹ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ ਮੁੜ ਪ੍ਰਾਪਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰੋਸੈਸ ਵਿੱਚ ਹਰ ਸੰਭਵ ਐਡਜ ਕੇਸ ਨੂੰ ਹੈਂਡਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, Erlang ਹਰ ਵਰਕਰ ਨੂੰ ਛੋਟਾ ਅਤੇ ਕੇਂਦਰਿਤ ਰੱਖਣ ਦੀ ਹਿਮਾਇਤ ਕਰਦਾ ਹੈ। ਜੇ ਉਹ ਵਰਕਰ ਕਿਸੇ ਚੀਜ਼ ਦਾ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ ਜੋ ਵਾਸਤਵ ਵਿੱਚ ਉਹ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦਾ (ਕੋਰੀਪਟ ਸਟੇਟ, ਟੁੱਟੀਆਂ ਧਾਰਨਾਵਾਂ, ਅਣਛਾਹੀ ਇਨਪੁਟ), ਤਾਂ ਉਹ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਿਸਟਮ ਦਾ ਕੋਈ ਹੋਰ ਹਿੱਸਾ ਇਸ ਨੂੰ ਵਾਪਸ ਲਿਆਉਣ ਲ਼ਏ ਜ਼ਿੰਮੇਵਾਰ ਹੁੰਦਾ ਹੈ।
ਇਸ ਨਾਲ ਮੁੱਖ ਸਵਾਲ "ਅਸੀਂ ਅਸਫਲਤਾ ਨੂੰ ਕਿਵੇਂ ਰੋਕੀਏ?" ਤੋਂ ਬਦਲ ਕੇ "ਅਸੀਂ ਅਸਫਲਤਾ ਹੋਣ 'ਤੇ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਰਿਕਵਰ ਕਰੀਏ?" ਹੋ ਜਾਂਦਾ ਹੈ।
ਹਰ ਜਗ੍ਹਾ defensive programming ਕਈ ਵਾਰ ਸਰਲ ਫਲੋਜ਼ ਨੂੰ ਕੰਡੇ ਦੀਆਂ ਸ਼ਰਤਾਂ, ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਅਧੂਰੇ ਸਟੇਟ ਵਿੱਚ ਬਦਲ ਦੇ ਦਿੰਦਾ ਹੈ। “Let it crash” ਕੁਝ ਅਦਾਲਤ-ਵਾਲੀ ਜਟਿਲਤਾ ਨੂੰ ਬਦਲ ਦਿੰਦਾ ਹੈ:
ਵੱਡਾ ਵਿਚਾਰ ਇਹ ਹੈ ਕਿ ਰਿਕਵਰੀ ਨੂੰ ਪੇਸ਼ਗੋਈਯੋਗ ਅਤੇ ਦੁਹਰਾਯੋਗ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਹਰ ਫੰਕਸ਼ਨ ਵਿੱਚ improvisation।
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਫਿੱਟ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਫੇਲ੍ਹਰ recoverable ਅਤੇ isolated ਹੁੰਦੇ ਹਨ: ਇੱਕ ਅਰੰਭਕ ਨੈੱਟਵਰਕ ਮੁੱਦਾ, ਖਰਾਬ ਰਿਕਵੇਸਟ, ਇੱਕ ਅਟੱਕਿਆ ਵਰਕਰ, ਜਾਂ ਤੀਸਰੇ-ਪਾਰਟੀ ਟਾਈਮਆਊਟ।
ਇਹ ਮਾੜੀਆਂ ਸਥਿਤੀਆਂ ਲਈ ਠੀਕ ਨਹੀਂ ਜਦੋਂ ਇੱਕ ਕਰੈਸ਼ ਅਮਾਨਯੋਗ ਨੁਕਸਾਨ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਵੇਂ:
ਕਰੈਸ਼ ਸਿਰਫ ਇਸ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਮੁੜ ਆਉਣਾ ਤੇਜ਼ ਅਤੇ ਸੁਰੱਖਿਅਤ ਹੋਵੇ। ਅਮਲ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਵਰਕਰਾਂ ਨੂੰ ਜਾਣਿਆ-ਪ੍ਰਮਾਣਿਤ ਸਥਿਤੀ ਵਿੱਚ ਰੀਸਟਾਰਟ ਕੀਤਾ ਜਾਵੇ—ਅਕਸਰ configuration reload ਕਰਕੇ, in-memory cache ਨੂੰ ਦਾਇਮੀ ਸਟੋਰੇਜ ਤੋਂ ਦੁਬਾਰਾ ਬਣਾਕੇ, ਅਤੇ ਕੰਮ ਨੂੰ ਬਿਨਾਂ ਖੋਏ ਜਾਰੀ ਰੱਖਣਾ।
Erlang ਦਾ “let it crash” ਵਿਚਾਰ तभी ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ ਕਾਰੈਸ਼ਾਂ ਨੂੰ ਮੌਕੇ 'ਤੇ ਛੱਡਿਆ ਨਹੀਂ ਜਾਂਦਾ। ਮੁੱਖ ਪੈਟਰਨ ਹੈ ਸੁਪਰਵਾਈਜ਼ਨ ਟਰੀ: ਇੱਕ ਹਾਇਰਾਰਕੀ ਜਿੱਥੇ ਸੁਪਰਵਾਈਜ਼ਰ ਮੈਨੇਜਰਾਂ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ वर्कਰ ਅਸਲ ਕੰਮ ਕਰਦੇ ਹਨ (ਕਾਲ ਸੰਭਾਲਣਾ, ਸੈਸ਼ਨ ਟਰੈਕ ਕਰਨਾ, ਕਿਊ ਖਪਤ ਕਰਨਾ ਆਦਿ)। ਜਦੋਂ ਕੋਈ ਵਰਕਰ ਗਲਤ ਆਚਰਣ ਕਰਦਾ ਹੈ, ਮੈਨੇਜਰ ਨੋਟਿਸ ਕਰਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈ।
ਇੱਕ ਸੁਪਰਵਾਈਜ਼ਰ ਟੁੱਟੇ ਹੋਏ ਵਰਕਰ ਨੂੰ ਜਗ੍ਹਾ 'ਤੇ “ਠੀਕ” ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਇਹ ਇੱਕ ਸਧਾਰਣ, ਸੂਚਿਤ ਨਿਯਮ ਲਗਾਉਂਦਾ ਹੈ: ਜੇ ਵਰਕਰ ਮਰ ਜਾਂਦਾ ਹੈ, ਨਵਾਂ ਵਰਕਰ ਸ਼ੁਰੂ ਕਰੋ। ਇਸ ਨਾਲ ਰਿਕਵਰੀ ਦਾ ਰਾਸ਼ਤਾ ਪੇਸ਼ਗੋਈਯੋਗ ਹੁੰਦਾ ਹੈ ਅਤੇ ਕੋਡ ਵਿੱਚ ਫੈਲ-ਹੈਂਡਲਿੰਗ ਨੂੰ ਘਟਾਇਆ ਜਾਂਦਾ ਹੈ।
ਉਹਨਾਂ ਲਈ ਵੀ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਸੁਪਰਵਾਈਜ਼ਰ ਇਹ ਵੀ ਫੈਸਲਾ ਕਰ ਸਕੇ ਕਿ ਕਦੋਂ ਰੀਸਟਾਰਟ ਨਾ ਕੀਤਾ ਜਾਵੇ—ਜੇ ਕੋਈ ਚੀਜ਼ ਬਹੁਤ ਵਾਰ ਕਰੈਸ਼ ਹੋ ਰਹੀ ਹੈ, ਤਾਂ ਇਹ ਕੋਈ ਡੂੰਘੀ ਸਮੱਸਿਆ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਲਗਾਤਾਰ ਰੀਸਟਾਰਟ ਕਰਨਾ ਹਾਲਤ ਨੂੰ ਹੋਰ ਖਰਾਬ ਕਰ ਸਕਦਾ ਹੈ।
ਸੁਪਰਵਾਈਜ਼ਨ ਇੱਕ-ਸਾਈਜ਼-ਫਿੱਟ-ਸਭ ਨੂੰ ਨਹੀਂ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ ਰਣਨੀਤੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਵਧੀਆ ਸੁਪਰਵਾਈਜ਼ਨ ਡਿਜ਼ਾਈਨ ਇੱਕ dependency map ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕਿਹੜੇ ਕੰਪੋਨੈਂਟ ਕਿਸ ਤੇ ਨਿਰਭਰ ਹਨ, ਅਤੇ "ਤਾਜ਼ਾ ਸ਼ੁਰੂ" ਉਨ੍ਹਾਂ ਲਈ ਕੀ ਅਰਥ ਰੱਖਦਾ ਹੈ।
ਜੇ ਇੱਕ ਸੈਸ਼ਨ ਹੈਂਡਲਰ ਇੱਕ cache ਪ੍ਰੋਸੈਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਿਰਫ ਹੈਂਡਲਰ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਨਾ ਉਸ ਨੂੰ ਖਰਾਬ ਸਟੇਟ ਨਾਲ ਜੁੜਿਆ ਰਹਿ ਸਕਦਾ ਹੈ। ਉਚਿਤ ਸੁਪਰਵਾਈਜ਼ਰ ਹੇਠਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਗਰੁੱਪ ਕਰਨਾ (ਜਾਂ ਇਕੱਠੇ ਰੀਸਟਾਰਟ ਕਰਨਾ) ਗੰਦੇ ਫੇਲ੍ਹ ਮੋਡ ਨੂੰ ਲਾਜ਼ਮੀ ਅਤੇ ਦੁਹਰਾਯੋਗ ਰਿਕਵਰੀ ਵਿਹਾਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਜੇ Erlang ਭਾਸ਼ਾ ਹੈ, ਤਾਂ OTP (Open Telecom Platform) ਉਹ ਪਾਰਟਸ ਦੀ ਕਿਟ ਹੈ ਜੋ “let it crash” ਨੂੰ ਇਕ ਐਸਾ ਚੀਜ਼ ਬਣਾਉਂਦੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਸਾਲਾਂ ਤੱਕ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਚਲਾ ਸਕਦੇ ਹੋ।
OTP ਕੋਈ ਇਕ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ; ਇਹ ਰਵਾਇਤਾਂ ਅਤੇ ਤਿਆਰ-ਕਿਤੇ ਕੰਪੋਨੈਂਟਾਂ (ਜਿਨ੍ਹਾਂ ਨੂੰ behaviours ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਦਾ ਇੱਕ ਸੈਟ ਹੈ ਜੋ ਸਰਵਿਸਾਂ ਬਣਾਉਣ ਦੇ ਬੋਰੀੰਗ-ਪਰ-ਅਹਮ ਹਿੱਸਿਆਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ:
gen_server ਇੱਕ ਲੰਬੇ-ਚਲਦੇ ਵਰਕਰ ਲਈ ਜੋ ਸਟੇਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਬੇਨਤੀਆਂ ਨੂੰ ਹੈਂਡਲ ਕਰਦਾ ਹੈsupervisor ਫੇਲ੍ਹ ਹੋਏ ਵਰਕਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਆਟੋਮੈਟਿਕ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈapplication ਪੂਰੇ ਸਰਵਿਸ ਦਾ ਸ਼ੁਰੂ/ਬੰਦ ਕਿਵੇਂ ਹੋਵੇ ਅਤੇ ਰਿਲੀਜ਼ ਵਿੱਚ ਕਿਵੇਂ ਫਿੱਟ ਕਰੇ, ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈਇਹ "ਜਾਦੂ" ਨਹੀਂ — ਇਹ ਟੈਮਪਲੇਟ ਹਨ ਜਿਨ੍ਹਾਂ ਦੇ ਸਪਸ਼ਟ callback ਹੋਂਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਕੋਡ ਇੱਕ ਜਾਣੀ-ਪਹਚਾਣੀ ਸ਼ਕਲ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਵੇ ਨਾ ਕਿ ਹਰ ਪ੍ਰਾਜੈਕਟ ਵਿੱਚ ਨਵਾਂ ਫਰੇਮ ਬਣਾਉਣਾ ਪਵੇ।
ਟੀਮਾਂ ਅਕਸਰ ਕਰਦੀ-ਕਰਦੀ ਬੈਕਗ੍ਰਾਊਂਡ ਵਰਕਰ, ਘਰੇਲੂ ਮੋਨੀਟਰਿੰਗ ਹੋਕ, ਅਤੇ ਇਕ-ਵੈਰੀ ਰੀਸਟਾਰਟ ਲੌਜਿਕ ਬਣਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ—ਜਦ ਤੱਕ ਇਹ ਨਹੀਂ ਕਰਦਾ। OTP ਇਸ ਖਤਰੇ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਕਿਸੇ ਨੂੰ ਇੱਕੋ ਹੀ ਸ਼ਬਦਾਵਲੀ ਅਤੇ ਲਾਈਫਸਾਇਕਲ ਵੱਲ ਧਕाबिक ਕਰਦਾ ਹੈ। ਜਦ ਯੂ-ਇਕ ਨਵਾਂ ਇੰਜੀਨੀਅਰ ਜੋਇਨ ਕਰਦਾ ਹੈ, ਉਹ ਤੁਹਾਡੇ ਕਸਟਮ ਫਰੇਮਵਰਕ ਨੂੰ ਪਹਿਲਾਂ ਸਿੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਰੱਖਦਾ; ਉਹ Erlang ਇਕੋਸਿਸਟਮ ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਮਝੇ ਜਾਂਦੇ ਪੈਟਰਨਾਂ ਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦਾ ਹੈ।
OTP ਤੁਹਾਨੂੰ ਪ੍ਰੋਸੈਸ ਰੋਲਸ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਦੇ ਤਰੀਕੇ ਨਾਲ ਸੋਚਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ: ਇੱਕ ਵਰਕਰ ਕੀ ਹੈ, ਇੱਕ ਕੋਆਰਡੀਨੇਟਰ ਕੀ ਹੈ, ਕਿਹੜਾ ਕਿਸਨੂੰ ਰੀਸਟਾਰਟ ਕਰੇਗਾ, ਅਤੇ ਕਿਹੜਾ ਕਦੇ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਰੀਸਟਾਰਟ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ।
ਇਹ ਸਾਫ਼ ਨਾਂਕਰਨ, ਸਪਸ਼ਟ ਸ਼ੁਰੂਆਤ ਆਰਡਰ, ਪੇਸ਼ਗੋਈ ਸ਼ਟਡਾਊਨ, ਅਤੇ ਬਿਲਟ-ਇਨ ਮੋਨੀਟਰੀੰਗ ਸਿਗਨਲਾਂ ਨੂੰ ਵੀ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ: ਐਸਾ ਸੌਫਟਵੇਅਰ ਜੋ ਲਗਾਤਾਰ ਚੱਲਣ ਲਈ ਬਣਿਆ ਹੁੰਦਾ ਹੈ—ਜੋ ਫੌਲਟ ਤੋਂ ਰਿਕਵਰ ਕਰ ਸਕਦਾ, ਸਮੇਂ ਦੇ ਨਾਲ ਵਿਕਸਤ ਹੋ ਸਕਦਾ, ਅਤੇ ਬਿਨਾਂ ਲਗਾਤਾਰ ਮਨੁੱਖੀ ਦੇਖਰੇਖ ਦੇ ਆਪਣਾ ਕੰਮ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ।
Erlang ਦੇ ਵੱਡੇ ਵਿਚਾਰ—ਨਿੱਕੇ ਪ੍ਰੋਸੈਸ, ਮੇਸੇਜ ਪਾਸਿੰਗ, ਅਤੇ “let it crash”—BEAM virtual machine ਬਿਨਾਂ ਪੂਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵਰਤਣ ਯੋਗ ਨਹੀਂ ਰਹਿੰਦੇ। BEAM ਉਹ ਰਨਟਾਈਮ ਹੈ ਜੋ ਇਹਨਾਂ ਪੈਟਰਨਾਂ ਨੂੰ ਨਾਜੁਕ ਨਹੀਂ, ਪਰ ਕੁਦਰਤੀ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ।
BEAM ਦਾ ਨਿਰਮਾਣ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਲਾਈਟਵੇਟ ਪ੍ਰੋਸੈਸ ਚਲਾਉਣ ਲਈ ਕੀਤਾ ਗਿਆ ਹੈ। OS ਥ੍ਰੈਡਾਂ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਥਾਂ, BEAM ਖੁਦ Erlang ਪ੍ਰੋਸੈਸਾਂ ਨੂੰ ਸ਼ੈਡਿਯੂਲ ਕਰਦਾ ਹੈ।
ਅਮਲਿਕ ਲਾਭ ਇਹ ਹੈ ਕਿ ਲੋਡ ਹੇਠਾਂ ਰਿਸਪਾਂਸਿਵਨੈੱਸ: ਕੰਮ ਨੂੰ ਛੋਟੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਕੱਟਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇਨਸਾਫ਼ ਨਾਲ ਰੋਟੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜੋ ਕੋਈ ਵੀ ਅਤੀ-ਬੀਜੀ ਵਰਕਰ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਸਿਸਟਮ 'ਤੇ ਹਕ਼ ਨਹੀਂ ਜਮਾਂਦਾ। ਇਹ ਉਸ ਸਰਵਿਸ ਨਾਲ ਬਹੁਤ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜੋ ਕਈ ਸੁਤੰਤਰ ਕਾਰਜਾਂ ਦਾ ਸਮੂਹ ਹੋਂਦਾ ਹੈ—ਹਰ ਇੱਕ ਥੋੜ੍ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਫਿਰ yield ਕਰਦਾ ਹੈ।
ਹਰ Erlang ਪ੍ਰੋਸੈਸ ਦੀ ਆਪਣੀ ਹੀ heap ਅਤੇ ਆਪਣੀ garbage collection ਹੁੰਦੀ ਹੈ। ਇਹ ਇੱਕ ਮੁੱਖ ਵੇਰਵਾ ਹੈ: ਇੱਕ ਪ੍ਰੋਸੈਸ ਵਿੱਚ ਮੈਮੋਰੀ ਸਾਫ਼ ਕਰਨ ਲਈ ਪੂਰੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਰੋਕਣਾ ਲੋੜੀਂਦਾ ਨਹੀਂ।
ਇਸੇ ਤਰ੍ਹਾਂ ਅਹੰਕਾਰਪੂਰਕ, ਪ੍ਰੋਸੈਸ ਆਈਸੋਲੇਟ ਰਹਿੰਦੇ ਹਨ। ਜੇ ਇਕ ਪ੍ਰੋਸੈਸ ਕਰੈਸ਼ ਕਰ ਜਾਂਦਾ ਹੈ, ਉਹ ਹੋਰਾਂ ਦੀ ਮੈਮੋਰੀ ਨੂੰ ਕਰੋਪਟ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ VM ਜੀਊਂਦਾ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਆਈਸੋਲੇਸ਼ਨ ਉਹ ਬੁਨਿਆਦ ਹੈ ਜੋ ਸੁਪਰਵਾਈਜ਼ਨ ਟਰੀਆਂ ਨੂੰ ਹਕੀਕਤ ਬਣਾਉਂਦਾ ਹੈ: ਫੇਲ੍ਹਰ ਨੁਕਸਾਨਤਮਕ ਢੰਗ ਨਾਲ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ, ਫਿਰ ਨੁਕਸਾਨ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਹੱਲ ਕਰਨ ਲਈ ਫੇਲ੍ਹ ਹਿੱਸੇ ਨੂੰ ਰੀਸਟਾਰਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
BEAM ਸਪਲਾਈ ਕਰਨ ਵਿੱਚ ਵੀ ਆਸਾਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ: ਤੁਸੀਂ ਕਈ Erlang ਨੋਡ (ਅਲੱਗ VM ਇੰਸਟੈਂਸ) ਚਲਾ ਸਕਦੇ ਹੋ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਮੇਸੇਜ ਭੇਜ ਕੇ ਗੱਲਬਾਤ ਕਰਨ ਦੇ ਸਕਦੇ ਹੋ। ਜੇ ਤੁਸੀਂ “ਪ੍ਰੋਸੈਸ ਐਕਟਰਾਂ ਦੁਆਰਾ ਮੇਸੇਜ ਭੇਜਦੇ ਹਨ” ਨੂੰ ਸਮਝ ਲਿਆ ਹੈ, ਤਾਂ ਡਿਸਟ੍ਰੀਬਿਊਸ਼ਨ ਉਹੀ ਵਿਚਾਰ ਦਾ ਇੱਕ ਵਿਸਥਾਰ ਹੈ—ਕੁਝ ਪ੍ਰੋਸੈਸ ਕਿਸੇ ਹੋਰ ਨੋਡ 'ਤੇ ਰਹਿੰਦੇ ਹਨ।
BEAM ਕੱਚੀ ਗਤੀ ਦੇ ਵਾਅਦਿਆਂ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਇਹ concurrency, ਫੌਲਟ ਕੰਟੇਨਮੈਂਟ, ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਡਿਫਾਲਟ ਬਣਾਉਂਦਾ ਹੈ, ਤਾਂ ਕਿ ਭਰੋਸੇਯੋਗਤਾ ਦੀ ਕਹਾਣੀ ਸਿਧੀ-ਸਾਦੀ ਨਾ ਰਹਿ ਕੇ ਅਮਲਯੋਗ ਬਣ ਜਾਵੇ।
Erlang ਦੀਆਂ ਸਭ ਤੋਂ ਚਰਚਿਤ ਤਰਕੀਬਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ hot code swapping: ਰਨਿੰਗ ਸਿਸਟਮ ਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਘੱਟ-ਡਾਊਨਟਾਈਮ ਨਾਲ ਅਪਡੇਟ ਕਰਨਾ (ਜਿੱਥੇ ਰਨਟਾਈਮ ਅਤੇ ਟੂਲਿੰਗ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ)। ਅਮਲਿਕ ਵਾਅਦਾ ਇਹ ਨਹੀਂ ਕਿ "ਕਦੇ ਵੀ ਰੀਸਟਾਰਟ ਨਾ ਕਰੋ", ਪਰ ਇਹ ਕਿ "ਇੱਕ ਛੋਟੇ ਬੱਗ ਨੂੰ ਲੰਬੇ ਆਊਟੇਜ ਵਿੱਚ ਨਹੀਂ ਬਦਲਣਾ"।
Erlang/OTP ਵਿੱਚ, ਰਨਟਾਈਮ ਇੱਕ ਹੀ ਸਮੇਂ ਦੋ ਵਰਜ਼ਨਾਂ ਇੱਕ ਮੌਡੀਊਲ ਦੀ ਲੋਡ ਰੱਖ ਸਕਦਾ ਹੈ। ਮੌਜੂਦਾ ਪ੍ਰੋਸੈਸ ਪੁਰਾਣੇ ਵਰਜ਼ਨ ਨਾਲ ਕੰਮ ਮੁਕੰਮਲ ਕਰ ਸਕਦੇ ਹਨ ਜਦਕਿ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਨਵੇਂ ਵਰਜ਼ਨ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਨਾਲ ਤੁਹਾਨੂੰ ਬੱਗ ਪੈਚ ਕਰਨ, ਫੀਚਰ ਰੋਲ ਆਊਟ ਕਰਨ, ਜਾਂ ਵਿਵਹਾਰ ਸਹੀ ਕਰਨ ਲਈ ਥੋੜ੍ਹਾ ਸਮਾਂ ਮਿਲਦਾ ਹੈ ਬਿਨਾਂ ਸਭ ਨੂੰ ਨਿਕਾਸ ਕਰਨ ਦੇ।
ਚੰਗੀ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਗਿਆ, ਇਹ ਸਿੱਧਾ ਰਿਲਾਇਬਿਲਟੀ ਲਕਸ਼ਯਾਂ ਦੀ ਸਹਾਇਤਾ ਕਰਦਾ ਹੈ: ਘੱਟ ਪੂਰੇ-ਸਿਸਟਮ ਰੀਸਟਾਰਟ, ਛੋਟੀ ਮੈਨਟੇਨੈਂਸ ਵਿੰਡੋਜ਼, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਕੁਝ ਗਲਤ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਰਿਕਵਰੀ।
ਹਰ ਬਦਲਾਅ ਨੂੰ ਲਾਈਵ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਸਵੈਪ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਕੁਝ ਉਦਾਹਰਣ ਜਿਨ੍ਹਾਂ ਲਈ ਵੱਖਰੀ ਸਾਵਧਾਨੀ ਜਾਂ ਰੀਸਟਾਰਟ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:
Erlang ਸੰਤੁਲਿਤ ਤਬਦੀਲੀਆਂ ਲਈ ਮਕੈਨਜ਼ਮ ਦਿੰਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਅਪਗਰੇਡ ਪਾਥ ਡਿਜ਼ਾਈਨ ਕਰਨੀ ਪੈਂਦੀ ਹੈ।
ਹਾਟ ਅਪਗਰੇਡਸ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਅਪਗਰੇਡਸ ਅਤੇ ਰੋਲਬੈਕ ਰੋਜ਼ਾਨਾ ਅਪਰੇਸ਼ਨ ਮੰਨੇ ਜਾਂਦੇ ਹਨ, ਨ ਕਿ ਖਾਸ ਐਮਰਜੈਂਸੀ। ਇਸਦਾ ਮਤਲਬ ਵਰਜ਼ਨਿੰਗ, ਅਨੁਕੂਲਤਾ, ਅਤੇ ਇੱਕ ਸਪਸ਼ਟ “ਅਣਕਰ” ਰਸਤਾ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਯੋਜਿਤ ਹੋਵੇ। ਅਮਲ ਵਿੱਚ, ਟੀਮਾਂ ਲਾਈਵ-ਅਪਗਰੇਡ ਤਕਨੀਕਾਂ ਨੂੰ stagਡ ਰੋਲਆਊਟ, ਹੈਲਥ ਚੈਕ, ਅਤੇ ਸੁਪਰਵਾਈਜ਼ਨ-ਅਧਾਰਤ ਰਿਕਵਰੀ ਨਾਲ ਜੋੜਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ Erlang ਵਰਤਦੇ ਵੀ ਨਹੀਂ, ਤਾਂ ਸਬਕ ਇਹ ਹੈ: ਸਿਸਟਮਾਂ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕਰੋ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਬਦਲਣਾ ਪਹਿਲਾ-ਪ੍ਰਖਿਆਤ ਲਕਸ਼ਯ ਹੋਵੇ, ਨਾ ਕਿ ਇੱਕ ਬਾਅਦ-ਵਿੱਚਾਰ।
ਰੀਅਲ-ਟਾਈਮ ਪਲੇਟਫਾਰਮਾਂ ਦਾ ਸਬੰਧ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਪੀਡ ਨਾਲ ਨਹੀਂ, ਬਲਕਿ ਇਸ ਨਾਲ ਹੈ ਕਿ ਜਦੋਂ ਹਮੇਸ਼ਾ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਰਹੇ ਤਾ ਵੀ ਸਿਸਟਮ ਜਵਾਬਦੇਹ ਰਹੇ: ਨੈੱਟਵਰਕ ਹੰਝਦਾ ਹੈ, ਡੀਪੈਂਡੇੰਸੀਆਂ ਢੀਮੀਆਂ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਯੂਜ਼ਰ ਟ੍ਰੈਫਿਕ spike ਕਰ ਜਾਂਦਾ ਹੈ। Erlang ਦਾ ਡਿਜ਼ਾਈਨ—Joe Armstrong ਦੁਆਰਾ ਪ੍ਰਚਾਰਤ—ਇਸ ਹਕੀਕਤ ਨੂੰ ਮੰਨਦਾ ਹੈ ਅਤੇ concurrency ਨੂੰ ਅਸਧਾਰਨ ਨਹੀਂ, ਪਰ ਆਮ ਮੰਨਦਾ ਹੈ।
ਤੁਸੀਂ Erlang-ਸ਼ੈਲੀ ਸੋਚ ਨੂੰ ਹਰ ਥਾਂ ਵੇਖਦੇ ਹੋ ਜਿੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਸੁਤੰਤਰ ਗਤਿਵਿਧੀਆਂ ਇੱਕੋ ਸਮੇਂ ਹੋ ਰਹੀਆਂ ਹੁੰ:
ਬਹੁਤ ਸਾਰੇ ਉਤਪਾਦਾਂ ਨੂੰ ਉਹ ਕਠੋਰ ਗਾਰੰਟੀ ਨਹੀਂ ਚਾਹੀਦੀ ਕਿ "ਹਰ ਐਕਸ਼ਨ 10ms ਵਿੱਚ ਪੂਰਾ ਹੋਵੇ"। ਉਹ ਚਾਹੁੰਦੇ ਹਨ ਸੌਫਟ ਰੀਅਲ-ਟਾਈਮ: ਆਮ ਬੇਨਤੀਆਂ ਲਈ ਲਗਾਤਾਰ ਘੱਟ latency, ਹਿੱਸੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਤੇਜ਼ ਰਿਕਵਰੀ, ਅਤੇ ਉੱਚ ਉਪਲਬਧਤਾ ਤਾਂ ਜੋ ਯੂਜ਼ਰ INCIDENTS ਨੂੰ ਬਹੁਤ ਘੱਟ ਮਹਿਸੂਸ ਕਰਨ।
ਅਸਲ ਸਿਸਟਮ ਇਹ ਮੁੱਦੇ ਸਹਿਮਾਣੇ ਆਂਦੇ ਹਨ:
Erlang ਦਾ ਮਾਡਲ ਹਰ ਗਤੀਵਿਧੀ ਨੂੰ ਅਲੱਗ ਕਰਨ ਦੀ ਹਿਮਾਇਤ ਕਰਦਾ ਹੈ (ਇੱਕ ਯੂਜ਼ਰ ਸੈਸ਼ਨ, ਇੱਕ ਡਿਵਾਈਸ, ਇੱਕ ਰੀਟ੍ਰਾਈ ਅਟੈਂਪ) ਤਾਂ ਕਿ ਇੱਕ ਫੇਲ੍ਹਰ ਫੈਲ੍ਹ ਨਾ ਹੋਵੇ। ਇੱਕ ਵੱਡੇ “ਸਭ ਕੁਝ ਸੰਭਾਲਣ ਦੀ” ਕੰਪੋਨੈਂਟ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਛੋਟੇ ਯੂਨਿਟਾਂ 'ਤੇ ਸੋਚ ਸਕਦੀਆਂ ਹਨ: ਹਰ ਵਰਕਰ ਇੱਕ ਕੰਮ ਕਰਦਾ, ਮੇਸੇਜ ਰਾਹੀਂ ਗੱਲ ਕਰਦਾ, ਅਤੇ ਜੇ ਟੁੱਟਦਾ ਹੈ ਤਾਂ ਸਾਫ਼ ਤਰੀਕੇ ਨਾਲ ਰੀਸਟਾਰਟ ਹੁੰਦਾ ਹੈ।
ਇਹ ਬਦਲਾਅ—"ਹਰ ਫੇਲ੍ਹ ਨੂੰ ਰੋਕਣ" ਤੋਂ "ਫੇਲ੍ਹ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸੀਮਿਤ ਅਤੇ ਰਿਕਵਰ ਕਰਨ"—ਅਕਸਰ ਉਹੀ ਗੱਲ ਹੈ ਜੋ ਰੀਅਲ-ਟਾਈਮ ਪਲੇਟਫਾਰਮਾਂ ਨੂੰ ਦਬਾਅ ਹੇਠਾਂ ਸਥਿਰ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੀ ਹੈ।
Erlang ਦੀ ਸ਼ੋਤਰੀ ਇਮেজ ਇੱਕ ਵਾਅਦੇ ਵਾਂਗ ਦਿਸਦੀ ਹੈ: ਸਿਸਟਮ ਜੋ ਕਦੇ ਡਾਊਨ ਨਹੀਂ ਹੁੰਦੇ ਕਿਉਂਕਿ ਉਹ ਸਿਰਫ ਰੀਸਟਾਰਟ ਕਰ ਲੈਂਦੇ ਹਨ। ਹਕੀਕਤ ਜ਼ਿਆਦਾ ਅਮਲਿਕ ਅਤੇ ਲਾਭਦਾਇਕ ਹੈ। “Let it crash” ਇਕ ਟੂਲ ਹੈ ਭਰੋਸੇਯੋਗ ਸੇਵਾਵਾਂ ਬਣਾਉਣ ਲਈ, ਨਾ ਕਿ ਮੁਸ਼ਕਲ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਦੀ ਆਗਿਆ।
ਇੱਕ ਆਮ ਗਲਤੀ ਸੁਪਰਵਾਈਜ਼ਨ ਨੂੰ ਡੂੰਘੀਆਂ ਬੱਗੇ ਛੁਪਾਉਣ ਦੇ ਤਰੀਕੇ ਵਜੋਂ ਵਰਤਣਾ ਹੈ। ਜੇ ਇੱਕ ਪ੍ਰੋਸੈਸ ਤੁਰੰਤ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕਰੈਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਸੁਪਰਵਾਈਜ਼ਰ ਉਸ ਨੂੰ ਲਗਾਤਾਰ ਰੀਸਟਾਰਟ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਕ੍ਰੈਸ਼ ਲੂਪ ਵਿੱਚ ਆ ਸਕਦੇ ਹੋ—CPU ਜ਼ਿਆਦਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਲੌਗ ਭਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਸ਼ਾਇਦ ਮੁਢਲੀ ਬੱਗ ਨਾਲੋਂ ਵੱਡਾ ਆਊਟੇਜ ਬਣ ਜਾਏ।
ਚੰਗੇ ਸਿਸਟਮ backoff, restart intensity ਸੀਮਾਵਾਂ, ਅਤੇ "ਦਰਜਾ-ਉਠਾਓ" ਵਿਵਹਾਰ ਜੋੜਦੇ ਹਨ। ਰੀਸਟਾਰਟ ਸਿਹਤਮੰਦ ਓਪਰੇਸ਼ਨ ਨੂੰ بحال ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨ ਕਿ ਇੱਕ ਟੁੱਟੇ ਹੋਏ ਇਨਵੈਰੀਅੰਟ ਨੂੰ ਛੁਪਾਉਣਾ।
ਕਿਸੇ ਪ੍ਰੋਸੈਸ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਆਸਾਨ ਹੁੰਦਾ ਹੈ; ਸਹੀ ਸਟੇਟ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਵੱਡੀ ਗੱਲ ਹੈ। ਜੇ ਸਟੇਟ صرف memory ਵਿੱਚ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਫੈਸਲਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਕਰੈਸ਼ ਤੋਂ ਬਾਅਦ "ਸਹੀ" ਕੀ ਹੈ:
ਫੌਲਟ ਟੋਲਰੈਂਸ ਡੇਟਾ ਡਿਜ਼ਾਈਨ ਨੂੰ ਬਦਲਦਾ ਨਹੀਂ; ਇਹ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਸਪਸ਼ਟ ਹੋਣ ਲਈ ਬਲਦਾ ਹੈ।
ਕਰੈਸ਼ ਤਦ ਹੀ ਮਦਦਗਾਰ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਜਲਦੀ ਦੇਖ ਸਕੋ ਅਤੇ ਸਮਝ ਸਕੋ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਲੌਗਿੰਗ, ਮੈਟ੍ਰਿਕਸ, ਅਤੇ ਟਰੇਸਿੰਗ ਵਿੱਚ ਨਿਵੇਸ਼—ਨਾ ਕਿ ਸਿਰਫ "ਇਹ ਰੀਸਟਾਰਟ ਹੋ ਗਿਆ, ਸਾਨੂੰ ਚਿੰਤਾ ਨਹੀਂ"। ਤੁਸੀਂ ਰੀਸਟਾਰਟ ਦਰਾਂ, ਵਧ ਰਹੀ ਕਿਊਆਂ, ਅਤੇ ਧੀਮੇ ਡੀਪੈਂਡੇੰਸੀਜ਼ ਨੂੰ ਵੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ ਯੂਜ਼ਰਾਂ ਨੂੰ ਮਹਿਸੂਸ ਹੋਵੇ।
BEAM ਦੀਆਂ ਤਾਕਤਾਂ ਦੇ ਬਾਵਜੂਦ, ਸਿਸਟਮ ਆਮ ਤੌਰ 'ਤੇ ਆਮ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੋ ਸਕਦੇ ਹਨ:
Erlang ਦਾ ਮਾਡਲ ਤੁਹਾਨੂੰ ਫੇਲ੍ਹਰ ਨੂੰ ਸੀਮਿਤ ਅਤੇ ਰਿਕਵਰ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ—ਪਰ ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਹਟਾ ਨਹੀਂ ਸਕਦਾ।
Erlang ਦੀ ਸਭ ਤੋਂ ਵੱਡੀ ਕਿਫ਼ਾਇਤ syntax ਨਹੀਂ ਹੈ—ਇਹ ਆਦਤਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਹੈ ਜੋ ਉਹ ਸੇਵਾਵਾਂ ਬਣਾਉਂਦੀਆਂ ਹਨ ਜੋ ਹਿੱਸਿਆਂ ਦੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਸਮੇਂ ਵੀ ਚੱਲਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਉਹ ਆਦਤਾਂ ਲਗਭਗ ਕਿਸੇ ਵੀ ਟੈਕ ਸਟੈਕ ਵਿੱਚ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ।
ਸ਼ੁਰੂਆਤ failure boundaries ਨੂੰ ਸਪੱਸ਼ਟ ਬਣਾਉਣ ਨਾਲ ਕਰੋ। ਆਪਣੇ ਸਿਸਟਮ ਨੂੰ ਐਸੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਤੋੜੋ ਜੋ ਅਜ਼ਾਦੀ ਨਾਲ ਫੇਲ ਹੋ ਸਕਣ, ਅਤੇ ਹਰ ਹਿੱਸੇ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਕਾਂਟਰੈਕਟ (ਇਨਪੁਟ, ਆਉਟਪੁਟ, ਅਤੇ "ਖਰਾਬ" ਕੀ ਦਿਖਦਾ) ਪੱਕਾ ਕਰੋ।
ਫਿਰ recovery ਨੂੰ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਹਰ ਗਲਤੀ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਥਾਂ ਆਟੋਮੇਟ ਕਰੋ:
ਇਹ ਆਦਤਾਂ tooling ਅਤੇ ਲਾਈਫਸਾਇਕਲ ਵਿੱਚ ਹੀ ਬੇਸ਼ਕ ਸ਼ਾਮਲ ਕਰੋ, ਨਾ ਕਿ ਸਿਰਫ਼ ਕੋਡ ਵਿੱਚ। ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ 팀 Koder.ai ਵਰਤਦੇ ਹਨ ਤਾਂ Planning Mode ਰੀਪੀਟੇਬਲ ਡਿਪਲੋਯਮੈਂਟ ਅਤੇ ਸਨੈਪਸ਼ੌਟ/ਰੋਲਬੈਕ ਦੀਆਂ ਪ੍ਰਕ੍ਰਿਯਾਵਾਂ ਨਾਲ ਉਹੀ ਓਪਰੇਸ਼ਨਲ ਸੋਚ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਆਉਂਦੀ ਹੈ: ਮੰਨੋ ਕਿ ਬਦਲਾਵ ਅਤੇ ਫੇਲ੍ਹ ਹੌਣਗੇ ਅਤੇ recovery ਨੂੰ ਰੋਜ਼ਮਰਾ ਦਾ ਹਿੱਸਾ ਬਣਾਓ।
ਤੁਸੀਂ "ਸੁਪਰਵਾਈਜ਼ਨ" ਪੈਟਰਨ ਨੂੰ ਉਹ ਸੰਦਾਂ ਨਾਲ ਨਜ਼ਦੀਕੀ ਰੂਪ ਵਿੱਚ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਵਰਤ ਰਹੇ ਹੋ:
ਇਹ ਪੈਟਰਨਾਂ ਨੂੰ ਨਕਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਫੈਸਲਾ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ ਕੀ ਚਾਹੀਦਾ ਹੈ:
ਜੇ ਤੁਸੀਂ ਪ੍ਰਯੋਗਾਤਮਕ ਅਗਲੇ ਕਦਮ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ /blog ਵਿੱਚ ਹੋਰ ਗਾਈਡ ਵੇਖੋ, /docs ਵਿੱਚ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਵੇਰਵਿਆਂ ਨੂੰ ਜाँचੋ (ਅਤੇ ਜੇ ਤੁਸੀਂ ਟੂਲਿੰਗ ਦਾ ਮੂਲਿਆੰਕਣ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਦੇ ਯੋਜਨਾਂ ਨੂੰ ਵੇਖੋ)।
Erlang ਨੇ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਰਿਲਾਇਬਿਲਟੀ ਸੋਚ ਮਸ਼ਹੂਰ ਕੀਤੀ: ਮੰਨੋ ਕਿ ਹਿੱਸੇ ਫੇਲ੍ਹ ਹੋਣਗੇ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣ 'ਤੇ ਅੱਗੇ ਕੀ ਹੋਏਗਾ ਇਹ ਡਿਜ਼ਾਈਨ ਕਰੋ।
ਹਰ ਇੱਕ ਕਰੈਸ਼ ਨੂੰ ਰੋਕਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਬਜਾਏ, ਇਹ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ ਫੌਲਟ ਆਈਸੋਲੇਸ਼ਨ, ਤੇਜ਼ ਪਤਾ ਲਗਾਉਣਾ, ਅਤੇ ਆਟੋਮੈਟਿਕ ਰਿਕਵਰੀ, ਜੋ ਚੈਟ, ਕਾਲ ਰੂਟਿੰਗ, ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਰਵਿਸਾਂ ਵਰਗੀਆਂ ਰੀਅਲ-ਟਾਈਮ ਪਲੇਟਫਾਰਮਾਂ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਮਿਲਦਾ ਹੈ।
ਇਸ ਸੰਦਰਭ ਵਿੱਚ, “ਰੀਅਲ-ਟਾਈਮ” ਆਮਤੌਰ 'ਤੇ ਸੌਫਟ ਰੀਅਲ-ਟਾਈਮ ਦਾ ਮਤਲਬ ਰੱਖਦਾ ਹੈ:
ਇਹ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ ਡੇਢਲਾਈਨਾਂ ਬਾਰੇ ਘੱਟ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾ ਉਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਸਟਾਲ, ਸਪਾਇਰਲ ਅਤੇ ਕੈਸਕੇਡਿੰਗ ਆਊਟੇਜ ਤੋਂ ਬਚਿਆ ਜਾਵੇ।
ਕਨਕਰਨਸੀ-ਬਾਈ-ਡਿਫੌਲਟ ਦਾ ਮਤਲਬ ਹੈ ਸਿਸਟਮ ਨੂੰ ਘਣੇ ਛੋਟੇ, ਅਲੱਗ ਵਰਕਰਾਂ ਵਜੋਂ ਬਣਾਉਣਾ ਨਾ ਕਿ ਕੁਝ ਵੱਡੇ, ਅਜਿਹਾ-ਭਰੇ ਕੰਪੋਨੈਂਟਾਂ ਵਜੋਂ।
ਹਰ ਵਰਕਰ ਇੱਕ ਨਿੱਕੀ ਜ਼ਿੰਮੇਵਾਰੀ (ਇੱਕ ਸੈਸ਼ਨ, ਡਿਵਾਈਸ, ਕਾਲ, ਰੀਟ੍ਰਾਈ ਲੂਪ) ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਕੇਲਿੰਗ ਅਤੇ ਫੇਲ੍ਹਰ ਕੰਟੇਨਮੈਂਟ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
ਲਾਈਟਵੇਟ ਪ੍ਰੋਸੈਸ ਉਹ ਨਿੱਕੇ ਸਵਤੰਤਰ ਵਰਕਰ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਵੱਡੇ ਗਿਣਤੀ ਵਿੱਚ ਬਣਾ ਸਕਦੇ ਹੋ।
ਅਮਲ ਵਿੱਚ, ਇਹ ਇਸ ਲਈ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ:
ਮੇਸੇਜ ਪਾਸਿੰਗ ਸਹਿਯੋਗ ਲਈ ਮੇਸੇਜ ਭੇਜਣ ਹੈ, ਨਾ ਕਿ ਸਾਂਝੀ ਮਿਊਟੇਬਲ ਸਟੇਟ।
ਇਸ ਨਾਲ concurrency ਬੱਗਜ਼ (ਜਿਵੇਂ race conditions) ਦੇ ਬਹੁਤ ਸਾਰੇ ਕੇਸ ਘਟ ਜਾਂਦੇ ਹਨ ਕਿਉਂਕਿ ਹਰ ਵਰਕਰ ਆਪਣਾ ਡੇਟਾ ਮਾਲਿਕ ਹੈ; ਹੋਰ ਕੋਈ ਇਹਨੂੰ ਸਿੱਧਾ ਬਦਲ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਬੈਕ-ਪ੍ਰੈਸ਼ਰ ਉਹਦੇ ਸਮੇਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਇਕ ਵਰਕਰ ਨੂੰ ਉਸ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਤੇਜ਼ੀ ਨਾਲ ਮੇਸੇਜ ਮਿਲ ਰਹੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਸ ਦੀ ਮੇਲਬਾਕਸ ਵਧਦੀ ਹੈ।
ਅਮਲ ਵਿੱਚ ਮੁਕਾਬਲਾ ਕਰਨ ਦੇ ਤਰੀਕੇ:
“Let it crash” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਢਿੱਡੀ ਇੰਜੀਨੀਅਰਿੰਗ ਚਲਾਈ ਜਾਵੇ। ਇਹ ਇੱਕ ਰਿਲਾਇਬਿਲਟੀ ਨੀਤੀ ਹੈ: ਜਦੋਂ ਕੋਈ ਕੰਪੋਨੈਂਟ ਬਹੁਤ ਖਰਾਬ ਹਾਲਤ ਵਿੱਚ ਹੋਵੇ, ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਰੁੱਕਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਕਿ ਢੀਠ ਸਾਹਮਣੇ ਨਾ ਪਏ।
ਰਿਕਵਰੀ ਫੈਸਲਾ ਸੁਪਰਵਾਈਜ਼ਨ ਰਚਨਾ ਦੁਆਰਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੋਡ ਸਾਫ਼ ਅਤੇ ਪਾਠਣਯੋਗ ਰਹਿੰਦਾ ਹੈ।
ਸੁਪਰਵਾਈਜ਼ਨ ਟਰੀ ਇੱਕ ਹਾਇਰਾਰਕੀ ਹੁੰਦੀ ਹੈ ਜਿੱਥੇ ਸੁਪਰਵਾਈਜ਼ਰ ਵਰਕਰਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਨ ਅਤੇ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਉਨ੍ਹਾਂ ਨੂੰ ਰੀਸਟਾਰਟ ਕਰਦੇ ਹਨ।
ਇਸ ਨਾਲ ਤੁਸੀਂ ਹਰ ਥਾਂ ਫੈਲ੍ਹਰ ਨੂੰ ਲਪੇਟਣ ਦੀ ਬਜਾਏ ਰਿਕਵਰੀ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੇ ਹੋ:
OTP ਉਹ ਸਟੈਂਡਰਡ ਪੈਟਰਨ (behaviours) ਅਤੇ ਰਵਾਇਤੀ ਤਰੀਕੇ ਹਨ ਜੋ “let it crash” ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਚਲਾਉਣ ਯੋਗ ਬਣਾਉਂਦੇ ਹਨ।
ਆਮ ਬਿਲਡਿੰਗ ਬਲਾਕ ਸ਼ਾਮਲ ਹਨ:
gen_server ਲੰਬੇ-ਚਲਦੇ ਵਰਕਰ ਲਈ ਜੋ ਸਟੇਟ ਰੱਖਦਾ ਹੈ ਅਤੇ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਬੇਨਤੀ ਹੈਂਡਲ ਕਰਦਾ ਹੈsupervisor ਫੇਲ੍ਹ ਹੋਏ ਵਰਕਰਾਂ ਨੂੰ ਸਪਸ਼ਟ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਰੀਸਟਾਰਟ ਕਰਦਾ ਹੈapplication ਪੂਰੇ ਸਰਵਿਸ ਦੇ ਸ਼ੁਰੂ, ਬੰਦ ਅਤੇ ਰਿਲੀਜ਼ ਨਾਲ ਮਿਲਦਾ ਹੈਇਹ ਪ੍ਰੋਜੈਕਟ-ਵਿਸ਼ੇਸ਼ ਫਰੇਮਵਰਕਾਂ ਨਾਲੋਂ ਸਾਂਝੇ ਪੈਟਰਨ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਉਹੀ ਨੀਤੀਆਂ ਹੋਰ ਸਟੈੱਕਾਂ ਵਿੱਚ ਵੀ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ: ਫੇਲ੍ਹਰ ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਪਹਿਲੀ-ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ।
ਕੁਝ ਅਮਲ ਦੇ ਤਰੀਕੇ:
ਇਕ ਉਦਾਹਰਣਤੌਰ 'ਤੇ, ਜਦੋਂ ਟੀਮਾਂ Koder.ai ਵਰਤਦੀਆਂ ਹਨ ਤਾਂ Planning Mode, ਰੀਪੀਟੇਬਲ ਡਿਪਲੋਯਮੈਂਟ ਅਤੇ ਸਨੈਪਸ਼ੌਟ/ਰੋਲਬੈਕ ਵਰਗੀਆਂ ਵਰਕਫਲੋਜ਼ ਉਹੀ ਆਪਰੇਸ਼ਨਲ ਸੋਚ ਨੈਚਰਲ ਤੌਰ 'ਤੇ ਉਤਪੰਨ ਕਰਦੀਆਂ ਹਨ: ਮੰਨੋ ਕਿ ਬਦਲਾਅ ਅਤੇ ਫੇਲ੍ਹ ਹੋਵੇਗਾ, ਅਤੇ ਰਿਕਵਰੀ ਨੂੰ ਬੋਰਿੰਗ ਬਣਾਓ।