"ਹੱਡੂਪ. ZooKeeper" Mail.Ru ਗਰੁੱਪ ਟੈਕਨੋਸਟ੍ਰੀਮ ਲੜੀ ਤੋਂ "ਹੈਡੂਪ ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਦੀ ਵੰਡ ਪ੍ਰਕਿਰਿਆ ਲਈ ਢੰਗ"

ਮੈਂ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ "ਹਡੂਪ ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਦੀ ਵੰਡ ਪ੍ਰਕਿਰਿਆ ਲਈ ਵਿਧੀਆਂ" ਲੜੀ ਤੋਂ ਲੈਕਚਰ "ਹਡੂਪ. ਜ਼ੂਕੀਪਰ" ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਨੂੰ ਪੜ੍ਹੋ।

ZooKeeper ਕੀ ਹੈ, Hadoop ਈਕੋਸਿਸਟਮ ਵਿੱਚ ਇਸਦਾ ਸਥਾਨ. ਡਿਸਟ੍ਰੀਬਿਊਟਿਡ ਕੰਪਿਊਟਿੰਗ ਬਾਰੇ ਅਸੱਚ. ਇੱਕ ਮਿਆਰੀ ਵੰਡ ਪ੍ਰਣਾਲੀ ਦਾ ਚਿੱਤਰ। ਵਿਤਰਿਤ ਪ੍ਰਣਾਲੀਆਂ ਦਾ ਤਾਲਮੇਲ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ. ਆਮ ਤਾਲਮੇਲ ਸਮੱਸਿਆਵਾਂ। ZooKeeper ਦੇ ਡਿਜ਼ਾਈਨ ਦੇ ਪਿੱਛੇ ਸਿਧਾਂਤ। ZooKeeper ਡਾਟਾ ਮਾਡਲ। znode ਝੰਡੇ. ਸੈਸ਼ਨ। ਕਲਾਇੰਟ API। ਪ੍ਰਾਇਮਰੀ (ਸੰਰਚਨਾ, ਸਮੂਹ ਸਦੱਸਤਾ, ਸਧਾਰਨ ਤਾਲੇ, ਨੇਤਾ ਚੋਣ, ਝੁੰਡ ਪ੍ਰਭਾਵ ਤੋਂ ਬਿਨਾਂ ਤਾਲਾਬੰਦੀ)। ਚਿੜੀਆਘਰ ਦਾ ਆਰਕੀਟੈਕਚਰ। ਚਿੜੀਆਘਰ ਡੀ.ਬੀ. ਜ਼ੈਬ. ਹੈਂਡਲਰ ਦੀ ਬੇਨਤੀ ਕਰੋ।

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

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

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

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

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

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

ਹੋਰ ਚੀਜ਼ਾਂ ਦੇ ਨਾਲ, ਨੈੱਟਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, ਹਮੇਸ਼ਾ ਇੱਕ ਖਾਸ ਲੇਟੈਂਸੀ ਹੁੰਦੀ ਹੈ। ਡਿਸਕ ਵਿੱਚ ਵੀ ਇਹ ਹੈ, ਪਰ ਨੈੱਟਵਰਕ ਵਿੱਚ ਇਸ ਤੋਂ ਵੱਧ ਹੈ। ਲੇਟੈਂਸੀ ਕੁਝ ਦੇਰੀ ਦਾ ਸਮਾਂ ਹੈ, ਜੋ ਕਿ ਛੋਟਾ ਜਾਂ ਕਾਫ਼ੀ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ।

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

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

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

ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਨਾਲ ਇੱਕ ਕੰਪਿਊਟਰ 'ਤੇ ਚੱਲਣ ਵਾਲਾ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣਾ ਆਸਾਨ ਹੈ।

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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਸ ਸਭ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਨਜ਼ਰ ਰੱਖੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਹ ਵੀ ਚੰਗਾ ਹੈ, ਪਰ ਨਿਗਰਾਨੀ ਇੱਕ ਸੀਮਤ ਚੀਜ਼ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਉੱਚ ਪੱਧਰ 'ਤੇ ਕੁਝ ਚੀਜ਼ਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ।

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

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

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

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

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

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

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

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

ਇਹ ਕਹਿਣਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਸਕੀਮ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ। ਹਰ ਇੱਕ ਦੇ ਆਪਣੇ ਫ਼ਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ.

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

ਅਤੇ ਇਹ ਸਕੀਮ (ਉੱਪਰ) ਸ਼ਾਇਦ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਹੈ, ਪਰ ਵਧੇਰੇ ਭਰੋਸੇਮੰਦ ਹੈ.

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

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

ZooKeeper ਅਜਿਹੇ ਇਨਕਾਰਾਂ ਨਾਲ ਨਜਿੱਠਣ ਦੇ ਤਰੀਕੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਾਡੀ ਜ਼ਿੰਦਗੀ ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦੀ ਹੈ।

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

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

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

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

ਇੱਕ ਗਤੀਸ਼ੀਲ ਸੰਰਚਨਾ ਵੀ ਹੈ. ਇਹ ਉਹ ਮਾਪਦੰਡ ਹਨ ਜੋ ਅਸੀਂ ਉੱਡਣ 'ਤੇ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਉਹ ਉੱਥੇ ਚੁੱਕੇ ਜਾਣ.

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

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

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

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

ZooKeeper ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਇੱਕ ਜਾਂ ਦੂਜੇ ਡਿਗਰੀ ਤੱਕ ਹੱਲ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਮੈਂ ਉਦਾਹਰਣਾਂ ਦੇ ਨਾਲ ਦਿਖਾਵਾਂਗਾ ਕਿ ਇਹ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਕਿਵੇਂ ਦਿੰਦਾ ਹੈ.

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

ਸਾਰੀਆਂ ਕਲਾਇੰਟ ਬੇਨਤੀਆਂ 'ਤੇ ਆਮ ਕਤਾਰ ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਕਾਰਵਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

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

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

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

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

ਕਲਾਇੰਟ ਉਹ ਉਪਭੋਗਤਾ ਹੈ ਜੋ ZooKeeper ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ।

ਸਰਵਰ ਆਪਣੇ ਆਪ ਵਿੱਚ ZooKeeper ਪ੍ਰਕਿਰਿਆ ਹੈ।

ਜ਼ਨੋਡ ਜ਼ੂਕੀਪਰ ਵਿੱਚ ਮੁੱਖ ਚੀਜ਼ ਹੈ। ਸਾਰੇ ਜ਼ਨੋਡਜ਼ ਜ਼ੂਕੀਪਰ ਦੁਆਰਾ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇੱਕ ਲੜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਲੜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਵਿਵਸਥਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

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

ਅਤੇ ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਕਲਾਇੰਟ ਇੱਕ ਬੇਨਤੀ ਨੂੰ ਪੂਰਾ ਨਹੀਂ ਕਰਦਾ ਹੈ ਅਤੇ ਡਿਸਕਨੈਕਟ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਇੱਕ ਸੈਸ਼ਨ ਸਥਾਪਤ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਇਹ ZooKeeper ਨਾਲ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ।

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

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

ਜ਼ਨੋਡ ਕਈ ਕਿਸਮਾਂ ਵਿੱਚ ਆਉਂਦੇ ਹਨ। ਉਹ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਅਤੇ ਜ਼ਨੋਡ ਬਣਾਉਣ ਵੇਲੇ, ਅਸੀਂ ਉਸ ਕਿਸਮ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਜਿਸ ਨਾਲ ਇਹ ਸਬੰਧਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਦੂਜੀ ਕਿਸਮ ਕ੍ਰਮਵਾਰ ਫਲੈਗ ਹੈ। ਇਹ ਜ਼ਨੋਡ ਦੇ ਰਸਤੇ 'ਤੇ ਕਾਊਂਟਰ ਨੂੰ ਵਧਾਉਂਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਸਾਡੇ ਕੋਲ ਐਪਲੀਕੇਸ਼ਨ 1_5 ਵਾਲੀ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਸੀ। ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਪਹਿਲਾ ਨੋਡ ਬਣਾਇਆ, ਤਾਂ ਇਸਨੂੰ p_1, ਦੂਜਾ - p_2 ਪ੍ਰਾਪਤ ਹੋਇਆ। ਅਤੇ ਜਦੋਂ ਅਸੀਂ ਹਰ ਵਾਰ ਇਸ ਵਿਧੀ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਪੂਰੇ ਮਾਰਗ ਨੂੰ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਮਾਰਗ ਦੇ ਸਿਰਫ ਹਿੱਸੇ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹੋਏ, ਅਤੇ ਇਹ ਸੰਖਿਆ ਆਪਣੇ ਆਪ ਵਧ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਅਸੀਂ ਨੋਡ ਕਿਸਮ - ਕ੍ਰਮਵਾਰ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਾਂ।

ਨਿਯਮਤ ਜ਼ਨੋਡ. ਉਹ ਹਮੇਸ਼ਾ ਜਿਉਂਦੀ ਰਹੇਗੀ ਅਤੇ ਉਸ ਦਾ ਨਾਮ ਹੋਵੇਗਾ ਜੋ ਅਸੀਂ ਉਸਨੂੰ ਦੱਸਦੇ ਹਾਂ।

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

ਅਤੇ ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਹਿਲਾਂ ਹੀ ਕਿਹਾ ਹੈ, ਡੇਟਾ ਦਾ ਕ੍ਰਮ ਕਿਲੋਬਾਈਟ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਉੱਥੇ ਵੱਡੇ ਟੈਕਸਟ ਡੇਟਾ ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਡੇਟਾਬੇਸ ਨਹੀਂ ਹੈ, ਇਹ ਇੱਕ ਐਕਸ਼ਨ ਕੋਆਰਡੀਨੇਸ਼ਨ ਸਰਵਰ ਹੈ.

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

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

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

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

ਜੇਕਰ ਅਸੀਂ ਇਸ ਸੰਸਕਰਣ ਦੀ ਜਾਂਚ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਸਿਰਫ਼ "-1" ਆਰਗੂਮੈਂਟ ਨੂੰ ਪਾਸ ਕਰਦੇ ਹਾਂ।

ਤੀਜਾ, ਇਹ ਜ਼ਨੋਡ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਨੋਡ ਮੌਜੂਦ ਹੈ ਤਾਂ ਸਹੀ ਦਿੰਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਗਲਤ।

ਅਤੇ ਫਿਰ ਫਲੈਗ ਵਾਚ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਇਸ ਨੋਡ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ.

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

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

ਵੀ ਹੈ ਡਾਟਾ ਸੈੱਟ ਕਰੋ. ਇੱਥੇ ਅਸੀਂ ਸੰਸਕਰਣ ਪਾਸ ਕਰਦੇ ਹਾਂ. ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਇਸਨੂੰ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਦੇ ਜ਼ਨੋਡ 'ਤੇ ਡੇਟਾ ਅਪਡੇਟ ਕੀਤਾ ਜਾਵੇਗਾ।

ਤੁਸੀਂ ਇਸ ਜਾਂਚ ਨੂੰ ਬਾਹਰ ਕੱਢਣ ਲਈ "-1" ਵੀ ਨਿਸ਼ਚਿਤ ਕਰ ਸਕਦੇ ਹੋ।

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

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

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

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

ਅਸੀਂ ਜਿਨ੍ਹਾਂ ਦੋ ਓਪਰੇਸ਼ਨਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਹੈ ਉਹ ਅੱਪਡੇਟ/ਰਾਈਟ ਹਨ, ਜੋ ਡਾਟਾ ਬਦਲਦੇ ਹਨ। ਇਹ ਬਣਾਓ, ਸੈੱਟ ਡੈਟਾ, ਸਿੰਕ, ਡਿਲੀਟ ਹਨ। ਅਤੇ ਰੀਡ ਮੌਜੂਦ ਹੈ, getData, getChildren.

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

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

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

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

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

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

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

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

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

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

ਜੇ ਨੇਤਾ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਮਰ ਗਿਆ, ਉਦਾਹਰਨ ਲਈ, ਡਿੱਗ ਗਿਆ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਨੇਤਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ. ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਕਾਮਯਾਬ ਹੋ ਜਾਂਦੇ ਹਾਂ ਤਾਂ ਸਾਡਾ ਵਰਕਰ ਆਗੂ ਬਣ ਜਾਂਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਇਸ ਸਮੇਂ ਕੋਈ ਵਿਅਕਤੀ ਇੱਕ ਨਵਾਂ ਨੇਤਾ ਬਣਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋ ਗਿਆ ਹੈ, ਤਾਂ ਅਸੀਂ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹ ਕੌਣ ਹੈ ਅਤੇ ਫਿਰ ਉਸਦਾ ਪਾਲਣ ਕਰੋ.

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

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

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

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

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

ਡਾਟਾਬੇਸ ਆਪਣੇ ਆਪ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੁਹਰਾਇਆ ਗਿਆ ਹੈ. ZooKeeper ਦੀਆਂ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਡੇਟਾ ਦੀ ਇੱਕ ਪੂਰੀ ਕਾਪੀ ਸਟੋਰ ਕਰਦੀਆਂ ਹਨ।

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

ZooKeeper ਪਰਮਾਣੂ ਪ੍ਰਸਾਰਣ ਇੱਕ ਅਜਿਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਪ੍ਰਤੀਕ੍ਰਿਤ ਡੇਟਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।

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

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

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

ਸਰੋਤ: www.habr.com