ਪੰਜ ਵਿਦਿਆਰਥੀ ਅਤੇ ਤਿੰਨ ਵੰਡੇ ਕੁੰਜੀ-ਮੁੱਲ ਸਟੋਰ

ਜਾਂ ਅਸੀਂ ZooKeeper, etcd ਅਤੇ Consul KV ਲਈ ਇੱਕ ਕਲਾਇੰਟ C++ ਲਾਇਬ੍ਰੇਰੀ ਕਿਵੇਂ ਲਿਖੀ

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

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

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

ਅਸੀਂ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਬਣਾਉਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਜੋ ZooKeeper, etcd ਅਤੇ Consul KV ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਸਾਂਝਾ ਇੰਟਰਫੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਲਾਇਬ੍ਰੇਰੀ C++ ਵਿੱਚ ਲਿਖੀ ਗਈ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਹੋਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪੋਰਟ ਕਰਨ ਦੀ ਯੋਜਨਾ ਹੈ।

ਡਾਟਾ ਮਾਡਲ

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

ਚਿੜੀਆਘਰ

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

ਆਦਿ

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

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

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

ਕੌਂਸਲਰ ਕੇ.ਵੀ.

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

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

ਇਹ ਸਭ ਇਕੱਠੇ ਪਾ ਕੇ

ZooKeeper ਕੋਲ ਸਭ ਤੋਂ ਸਖ਼ਤ ਡਾਟਾ ਮਾਡਲ ਹੈ। etcd ਵਿੱਚ ਉਪਲਬਧ ਐਕਸਪ੍ਰੈਸਿਵ ਰੇਂਜ ਸਵਾਲਾਂ ਨੂੰ ZooKeeper ਜਾਂ Consul ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਨਕਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਤੋਂ ਸਭ ਤੋਂ ਵਧੀਆ ਲੈਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਮਹੱਤਵਪੂਰਨ ਅਪਵਾਦਾਂ ਦੇ ਨਾਲ ਲਗਭਗ ZooKeeper ਇੰਟਰਫੇਸ ਦੇ ਬਰਾਬਰ ਇੰਟਰਫੇਸ ਦੇ ਨਾਲ ਸਮਾਪਤ ਕੀਤਾ:

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

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

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

ਲਾਗੂ ਕਰਨ ਦੀ ਸੂਖਮਤਾ

ਆਉ ਵੱਖ-ਵੱਖ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀ ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਕੁਝ ਪਹਿਲੂਆਂ 'ਤੇ ਡੂੰਘਾਈ ਨਾਲ ਵਿਚਾਰ ਕਰੀਏ।

ਆਦਿ ਵਿੱਚ ਦਰਜਾਬੰਦੀ

etcd ਵਿੱਚ ਇੱਕ ਲੜੀਵਾਰ ਦ੍ਰਿਸ਼ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਕਾਰਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਾਬਤ ਹੋਇਆ। ਰੇਂਜ ਦੇ ਸਵਾਲ ਇੱਕ ਖਾਸ ਅਗੇਤਰ ਨਾਲ ਕੁੰਜੀਆਂ ਦੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਦੀ ਲੋੜ ਹੈ ਜੋ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ "/foo", ਤੁਸੀਂ ਇੱਕ ਰੇਂਜ ਲਈ ਪੁੱਛ ਰਹੇ ਹੋ ["/foo", "/fop"). ਪਰ ਇਹ ਕੁੰਜੀ ਦਾ ਪੂਰਾ ਸਬਟ੍ਰੀ ਵਾਪਸ ਕਰ ਦੇਵੇਗਾ, ਜੋ ਕਿ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ ਜੇਕਰ ਸਬਟ੍ਰੀ ਵੱਡੀ ਹੈ। ਪਹਿਲਾਂ ਅਸੀਂ ਇੱਕ ਮੁੱਖ ਅਨੁਵਾਦ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ, zetcd ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ. ਇਸ ਵਿੱਚ ਕੁੰਜੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਬਾਈਟ ਜੋੜਨਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਰੁੱਖ ਵਿੱਚ ਨੋਡ ਦੀ ਡੂੰਘਾਈ ਦੇ ਬਰਾਬਰ। ਮੈਂ ਤੁਹਾਨੂੰ ਇੱਕ ਉਦਾਹਰਣ ਦਿੰਦਾ ਹਾਂ।

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

ਫਿਰ ਕੁੰਜੀ ਦੇ ਸਾਰੇ ਤੁਰੰਤ ਬੱਚੇ ਪ੍ਰਾਪਤ ਕਰੋ "/foo" ਇੱਕ ਰੇਂਜ ਦੀ ਬੇਨਤੀ ਕਰਕੇ ਸੰਭਵ ਹੈ ["u02/foo/", "u02/foo0"). ਹਾਂ, ASCII ਵਿੱਚ "0" ਠੀਕ ਬਾਅਦ ਖੜ੍ਹਾ ਹੈ "/".

ਪਰ ਇਸ ਕੇਸ ਵਿੱਚ ਇੱਕ ਸਿਰਲੇਖ ਨੂੰ ਹਟਾਉਣ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ? ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਿਸਮ ਦੀਆਂ ਸਾਰੀਆਂ ਰੇਂਜਾਂ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੈ ["uXX/foo/", "uXX/foo0") XX ਲਈ 01 ਤੋਂ FF ਤੱਕ। ਅਤੇ ਫਿਰ ਅਸੀਂ ਅੰਦਰ ਭੱਜ ਗਏ ਓਪਰੇਸ਼ਨ ਨੰਬਰ ਸੀਮਾ ਇੱਕ ਲੈਣ-ਦੇਣ ਦੇ ਅੰਦਰ।

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

ਫਿਰ ਕੁੰਜੀ ਨੂੰ ਮਿਟਾਉਣਾ "/very" ਮਿਟਾਉਣ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ "/u00very" ਅਤੇ ਰੇਂਜ ["/very/", "/very0"), ਅਤੇ ਸਾਰੇ ਬੱਚਿਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ - ਸੀਮਾ ਤੋਂ ਕੁੰਜੀਆਂ ਦੀ ਬੇਨਤੀ ਵਿੱਚ ["/very/u00", "/very/u01").

ZooKeeper ਵਿੱਚ ਇੱਕ ਕੁੰਜੀ ਨੂੰ ਹਟਾਉਣਾ

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

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

ZooKeeper ਵਿੱਚ ਸੈੱਟ ਕਰੋ

ZooKeeper ਵਿੱਚ ਵੱਖ-ਵੱਖ ਢੰਗ ਹਨ ਜੋ ਟ੍ਰੀ ਸਟ੍ਰਕਚਰ (ਬਣਾਓ, ਮਿਟਾਓ, getChildren) ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ ਅਤੇ ਜੋ ਕਿ ਨੋਡਾਂ (setData, getData) ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਰੀਆਂ ਵਿਧੀਆਂ ਵਿੱਚ ਸਖ਼ਤ ਪੂਰਵ-ਸ਼ਰਤਾਂ ਹਨ: ਜੇ ਨੋਡ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਕੋਈ ਗਲਤੀ ਹੈ ਤਾਂ ਬਣਾਓ ਡਾਟਾ ਬਣਾਇਆ, ਮਿਟਾਇਆ ਜਾਂ ਸੈੱਟ ਕੀਤਾ - ਜੇਕਰ ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਸਾਨੂੰ ਇੱਕ ਸੈੱਟ ਵਿਧੀ ਦੀ ਲੋੜ ਸੀ ਜਿਸਨੂੰ ਇੱਕ ਕੁੰਜੀ ਦੀ ਮੌਜੂਦਗੀ ਬਾਰੇ ਸੋਚੇ ਬਿਨਾਂ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਹੋਰ ਤਕਨੀਕੀ ਵੇਰਵੇ

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

ਸ਼ੁਰੂ ਤੋਂ ਹੀ, ਅਸੀਂ ਸੇਵਾਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਲਈ ਤਿਆਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। ZooKeeper ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਚੋਣ 'ਤੇ ਡਿੱਗ ਗਿਆ ਚਿੜੀਆਘਰ C++, ਜੋ ਆਖਰਕਾਰ ਵਿੰਡੋਜ਼ 'ਤੇ ਕੰਪਾਇਲ ਕਰਨ ਵਿੱਚ ਅਸਫਲ ਰਿਹਾ। ਹਾਲਾਂਕਿ, ਇਹ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ: ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ ਸਿਰਫ ਲੀਨਕਸ ਦੇ ਤੌਰ 'ਤੇ ਰੱਖਿਆ ਗਿਆ ਹੈ। ਕੌਂਸਲ ਲਈ ਇੱਕੋ ਇੱਕ ਵਿਕਲਪ ਸੀ ppconsul. ਇਸ ਵਿੱਚ ਸਹਿਯੋਗ ਜੋੜਨਾ ਪਿਆ ਸੈਸ਼ਨ и ਲੈਣ-ਦੇਣ. etcd ਲਈ, ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੀ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੀ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਮਿਲੀ, ਇਸ ਲਈ ਅਸੀਂ ਬਸ ਤਿਆਰ ਕੀਤਾ grpc ਕਲਾਇੰਟ.

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

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

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

ਨਤੀਜਾ

ਆਪਣੇ ਲਈ ਵੇਖੋ: liboffkv.

ਸਾਡੀ ਟੀਮ: ਰੇਡ ਰੋਮਾਨੋਵ, ਇਵਾਨ ਗਲੁਸ਼ੇਨਕੋਵ, ਦਿਮਿਤਰੀ ਕਮਲਦੀਨੋਵ, ਵਿਕਟਰ ਕ੍ਰਾਪਿਵੇਨਸਕੀ, ਵਿਟਾਲੀ ਇਵਾਨਿਨ.

ਸਰੋਤ: www.habr.com