ਟਾਰਨਟੂਲ ਕਾਰਟ੍ਰੀਜ: ਤਿੰਨ ਲਾਈਨਾਂ ਵਿੱਚ ਲੂਆ ਬੈਕਐਂਡ ਸ਼ਾਰਡਿੰਗ

Mail.ru ਸਮੂਹ ਵਿੱਚ ਸਾਡੇ ਕੋਲ Tarantool ਹੈ - ਇਹ Lua ਵਿੱਚ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਡੇਟਾਬੇਸ (ਜਾਂ ਇਸਦੇ ਉਲਟ?) ਦੇ ਰੂਪ ਵਿੱਚ ਵੀ ਦੁੱਗਣਾ ਹੈ। ਇਹ ਤੇਜ਼ ਅਤੇ ਠੰਡਾ ਹੈ, ਪਰ ਇੱਕ ਸਰਵਰ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਅਜੇ ਵੀ ਅਸੀਮਤ ਨਹੀਂ ਹਨ। ਵਰਟੀਕਲ ਸਕੇਲਿੰਗ ਵੀ ਕੋਈ ਉਪਾਅ ਨਹੀਂ ਹੈ, ਇਸਲਈ ਤਰਨਟੂਲ ਕੋਲ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਲਈ ਟੂਲ ਹਨ - vshard ਮੋਡੀਊਲ [1]. ਇਹ ਤੁਹਾਨੂੰ ਕਈ ਸਰਵਰਾਂ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਸ਼ਾਰਡ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਪਰ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਸੈਟ ਅਪ ਕਰਨ ਅਤੇ ਵਪਾਰਕ ਤਰਕ ਨੂੰ ਜੋੜਨ ਲਈ ਇਸ ਨਾਲ ਟਿੰਕਰ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਚੰਗੀ ਖ਼ਬਰ: ਅਸੀਂ ਕੁਝ ਵੱਡੇ ਸ਼ਾਟ ਇਕੱਠੇ ਕੀਤੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ [2], [3]) ਅਤੇ ਇੱਕ ਹੋਰ ਫਰੇਮਵਰਕ ਬਣਾਇਆ ਹੈ ਜੋ ਇਸ ਸਮੱਸਿਆ ਦੇ ਹੱਲ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਸਰਲ ਕਰੇਗਾ।

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

ਅਸਲ ਵਿੱਚ ਸਮੱਸਿਆ ਕੀ ਹੈ?

ਸਾਡੇ ਕੋਲ ਟਾਰੈਂਟੁਲਾ ਹੈ, ਸਾਡੇ ਕੋਲ ਵੀਸ਼ਾਰਡ ਹੈ - ਤੁਸੀਂ ਹੋਰ ਕੀ ਚਾਹੁੰਦੇ ਹੋ?

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

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

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

ਅਸੀਂ ਇਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਹੱਲ ਕੀਤਾ, ਅਤੇ ਕੁਝ ਸਮੇਂ 'ਤੇ ਅਸੀਂ ਇੱਕ ਅਜਿਹੀ ਪਹੁੰਚ ਵਿਕਸਿਤ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਇਸ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਸਰਲ ਬਣਾ ਦਿੰਦਾ ਹੈ: ਰਚਨਾ, ਵਿਕਾਸ, ਟੈਸਟਿੰਗ, CI/CD, ਰੱਖ-ਰਖਾਅ।

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

ਟਾਰਨਟੂਲ ਕਾਰਟ੍ਰੀਜ ਦੀਆਂ ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ:

• ਸਵੈਚਲਿਤ ਕਲੱਸਟਰ ਆਰਕੈਸਟਰੇਸ਼ਨ;
• ਨਵੀਆਂ ਭੂਮਿਕਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਦਾ ਵਿਸਤਾਰ ਕਰਨਾ;
• ਵਿਕਾਸ ਅਤੇ ਤੈਨਾਤੀ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਟੈਂਪਲੇਟ;
• ਬਿਲਟ-ਇਨ ਆਟੋਮੈਟਿਕ ਸ਼ਾਰਡਿੰਗ;
• Luatest ਟੈਸਟਿੰਗ ਫਰੇਮਵਰਕ ਨਾਲ ਏਕੀਕਰਣ;
• WebUI ਅਤੇ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਲੱਸਟਰ ਪ੍ਰਬੰਧਨ;
• ਪੈਕੇਜਿੰਗ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਟੂਲ.

ਸਤਿ ਸ੍ਰੀ ਅਕਾਲ ਦੁਨਿਆ!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

ਇਹ ਦੋ ਕਮਾਂਡਾਂ ਕਮਾਂਡ ਲਾਈਨ ਉਪਯੋਗਤਾਵਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਗੀਆਂ ਅਤੇ ਤੁਹਾਨੂੰ ਟੈਂਪਲੇਟ ਤੋਂ ਆਪਣੀ ਪਹਿਲੀ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀਆਂ ਹਨ:

$ cartridge create --name myapp

ਅਤੇ ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

ਇਹ ਇੱਕ ਤਿਆਰ-ਕੀਤੀ "ਹੈਲੋ, ਵਰਲਡ!" ਦੇ ਨਾਲ ਇੱਕ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ ਹੈ! ਐਪਲੀਕੇਸ਼ਨ. ਚਲੋ ਇਸ ਨੂੰ ਤੁਰੰਤ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ, ਪਹਿਲਾਂ ਨਿਰਭਰਤਾਵਾਂ (ਫ੍ਰੇਮਵਰਕ ਸਮੇਤ):

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

ਐਪਲੀਕੇਸ਼ਨ ਵਿਕਾਸ

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

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

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

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

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

ਅਤੇ ਜਦੋਂ ਸਟੇਜਿੰਗ ਜਾਂ ਉਤਪਾਦਨ ਲਈ ਤੈਨਾਤ ਕਰਨ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਅਸੀਂ ਹਾਰਡਵੇਅਰ ਸਮਰੱਥਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਹਰੇਕ ਟਾਰਨਟੂਲ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਪਣੀਆਂ ਭੂਮਿਕਾਵਾਂ ਦਾ ਸੈੱਟ ਸੌਂਪਾਂਗੇ:

ਟੌਪੋਲੋਜੀ ਪ੍ਰਬੰਧਨ

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

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

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

ਰੋਲ ਦੀ ਜ਼ਿੰਦਗੀ

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

function init()
function validate_config()
function apply_config()
function stop()

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

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

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

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

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

ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਨੁਕਤਾ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੈ। ਕਾਰਟ੍ਰੀਜ ਸਿਹਤ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ SWIM ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ [4]. ਸੰਖੇਪ ਵਿੱਚ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਦੂਜੇ ਨਾਲ UDP ਉੱਤੇ "ਅਫਵਾਹਾਂ" ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੀਆਂ ਹਨ - ਹਰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਆਪਣੇ ਗੁਆਂਢੀਆਂ ਨੂੰ ਤਾਜ਼ਾ ਖਬਰਾਂ ਦੱਸਦੀ ਹੈ, ਅਤੇ ਉਹ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਅਚਾਨਕ ਜਵਾਬ ਨਾ ਮਿਲਣ 'ਤੇ ਤਰੰਤੂਲ ਨੂੰ ਸ਼ੱਕ ਹੋਣ ਲੱਗ ਪੈਂਦਾ ਹੈ ਕਿ ਕੁਝ ਗਲਤ ਹੈ, ਅਤੇ ਕੁਝ ਦੇਰ ਬਾਅਦ ਇਹ ਮੌਤ ਦਾ ਪਾਠ ਸੁਣਾਉਂਦਾ ਹੈ ਅਤੇ ਆਲੇ-ਦੁਆਲੇ ਦੇ ਸਾਰਿਆਂ ਨੂੰ ਇਹ ਖਬਰ ਦੱਸਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ।

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

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

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

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

ਤੈਨਾਤੀ ਸਾਧਨ

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

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

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

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

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

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

ਸੰਰਚਨਾ ਵਿੱਚ, ਅਸੀਂ HTTP ਪੋਰਟ ਨੂੰ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਹੈ ਜਿਸ 'ਤੇ ਕਾਰਟ੍ਰੀਜ ਵੈੱਬ ਇੰਟਰਫੇਸ - 8080 ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ। ਆਓ ਇਸ 'ਤੇ ਚੱਲੀਏ ਅਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ:

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

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

ਨਤੀਜੇ

ਨਤੀਜੇ ਕੀ ਹਨ? ਇਸਨੂੰ ਅਜ਼ਮਾਓ, ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ, ਫੀਡਬੈਕ ਛੱਡੋ, ਗਿਥਬ 'ਤੇ ਟਿਕਟਾਂ ਬਣਾਓ।

ਹਵਾਲੇ

[1] Tarantool » 2.2 » ਹਵਾਲਾ » ਰਾਕਸ ਹਵਾਲਾ » ਮੋਡੀਊਲ vshard

[2] ਅਸੀਂ Tarantool 'ਤੇ ਆਧਾਰਿਤ Alfa-Bank ਦੇ ਨਿਵੇਸ਼ ਕਾਰੋਬਾਰ ਦੇ ਮੂਲ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ

[3] ਨਵੀਂ ਪੀੜ੍ਹੀ ਦਾ ਬਿਲਿੰਗ ਆਰਕੀਟੈਕਚਰ: ਟਰਾਂਟੂਲ ਵਿੱਚ ਤਬਦੀਲੀ ਦੇ ਨਾਲ ਤਬਦੀਲੀ

[4] SWIM - ਕਲੱਸਟਰ ਨਿਰਮਾਣ ਪ੍ਰੋਟੋਕੋਲ

[5] GitHub - tarantool/cartridge-cli

[6] GitHub - tarantool/cartridge

ਸਰੋਤ: www.habr.com