ਚਿੰਤਾ ਕਰਨਾ ਕਿਵੇਂ ਬੰਦ ਕਰਨਾ ਹੈ ਅਤੇ ਮੋਨੋਲੀਥ ਤੋਂ ਬਿਨਾਂ ਜੀਣਾ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ

ਅਸੀਂ ਸਾਰੇ ਕਹਾਣੀਆਂ ਨੂੰ ਪਿਆਰ ਕਰਦੇ ਹਾਂ. ਅਸੀਂ ਅੱਗ ਦੇ ਦੁਆਲੇ ਬੈਠਣਾ ਅਤੇ ਆਪਣੀਆਂ ਪਿਛਲੀਆਂ ਜਿੱਤਾਂ, ਲੜਾਈਆਂ, ਜਾਂ ਸਿਰਫ਼ ਸਾਡੇ ਕੰਮ ਦੇ ਤਜ਼ਰਬੇ ਬਾਰੇ ਗੱਲ ਕਰਨਾ ਪਸੰਦ ਕਰਦੇ ਹਾਂ।

ਅੱਜ ਅਜਿਹਾ ਹੀ ਦਿਨ ਹੈ। ਅਤੇ ਭਾਵੇਂ ਤੁਸੀਂ ਇਸ ਸਮੇਂ ਅੱਗ 'ਤੇ ਨਹੀਂ ਹੋ, ਸਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਲਈ ਇੱਕ ਕਹਾਣੀ ਹੈ। ਇਸ ਦੀ ਕਹਾਣੀ ਕਿ ਅਸੀਂ ਟਾਰਨਟੂਲ 'ਤੇ ਸਟੋਰੇਜ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ।

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

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

ਅੱਜ, CI/CD, K8S, ਆਦਿ ਦੇ ਰੂਪ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸਾਧਨ ਅਤੇ ਸੰਦ ਹਨ। "ਏਕਾਧਿਕਾਰੀ" ਸਮੇਂ ਵਿੱਚ, ਸਾਨੂੰ ਇੰਨੇ ਵਿਦੇਸ਼ੀ ਸ਼ਬਦਾਂ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਡੇਟਾਬੇਸ ਵਿੱਚ "ਸਟੋਰੇਜ" ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਇਹ ਕਾਫ਼ੀ ਸੀ.

ਪਰ ਸਮਾਂ ਅੱਗੇ ਵਧਿਆ, ਅਤੇ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਇਸ ਦੇ ਨਾਲ ਅੱਗੇ ਵਧਦੀ ਗਈ, ਕਈ ਵਾਰ ਆਰਪੀਐਸ ਨੂੰ ਸਾਡੀ ਸਮਰੱਥਾ ਤੋਂ ਪਰੇ ਸ਼ੂਟ ਕੀਤਾ. CIS ਦੇਸ਼ਾਂ ਦੇ ਮਾਰਕੀਟ ਵਿੱਚ ਦਾਖਲ ਹੋਣ ਦੇ ਨਾਲ, ਪਹਿਲੇ ਮੋਨੋਲੀਥ ਦੇ ਡੇਟਾਬੇਸ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਲੋਡ 90% ਤੋਂ ਹੇਠਾਂ ਨਹੀਂ ਆਇਆ, ਅਤੇ RPS 2400 ਦੇ ਪੱਧਰ 'ਤੇ ਰਿਹਾ। ਅਤੇ ਇਹ ਸਿਰਫ ਛੋਟੇ ਚੋਣਕਾਰ ਨਹੀਂ ਸਨ, ਪਰ ਇੱਕ ਨਾਲ ਭਾਰੀ ਸਵਾਲ ਸਨ। ਚੈਕਾਂ ਅਤੇ JOINs ਦਾ ਸਮੂਹ ਜੋ ਕਿ ਵੱਡੇ IO ਦੀ ਬੈਕਗ੍ਰਾਉਂਡ ਦੇ ਵਿਰੁੱਧ ਲਗਭਗ ਅੱਧੇ ਡੇਟਾ ਲਈ ਚੱਲ ਸਕਦਾ ਹੈ।

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

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

ਵੱਖ-ਵੱਖ ਸਮਾਗਮਾਂ ਵਿੱਚ ਮੈਂ ਕਹਿੰਦਾ ਹਾਂ: "ਜੇ ਤੁਸੀਂ ਇੱਕ ਮੋਨੋਲੀਥ ਨਹੀਂ ਦੇਖਿਆ, ਤਾਂ ਤੁਸੀਂ ਵਧੇ ਨਹੀਂ!" ਮੈਂ ਇਸ ਮਾਮਲੇ 'ਤੇ ਤੁਹਾਡੀ ਰਾਏ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ, ਕਿਰਪਾ ਕਰਕੇ ਇਸਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ.

ਥੰਡਰ ਦੀ ਇੱਕ ਆਵਾਜ਼

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

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

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

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ ਇੱਕ ਸਕੀਮ ਲੈ ਕੇ ਆਏ ਹਾਂ ਜੋ ਤਰਨਟੂਲ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੈ।

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

ਆਰਕੀਟੈਕਚਰ। ਵਿਕਲਪ 1. ਉਪਭੋਗਤਾ ਸੇਵਾ

ਵਰਤਮਾਨ ਸਮੇਂ, ਇੱਥੇ 24 ਸ਼ਾਰਡ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ 2 ਉਦਾਹਰਨਾਂ ਹਨ (ਹਰੇਕ DC ਲਈ ਇੱਕ), ਸਾਰੇ ਮਾਸਟਰ-ਮਾਸਟਰ ਮੋਡ ਵਿੱਚ ਹਨ।

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸ਼ਾਰਡਾਂ ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਚੋਣ ਨੀਤੀ ਨੂੰ ਸੰਰਚਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ। ਉਦਾਹਰਨ ਲਈ, roundrobin.

ਆਰਕੀਟੈਕਚਰ। ਵਿਕਲਪ 2. ਮਾਲ ਦੀ ਅੰਤਮ ਲਾਗਤ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ ਸੇਵਾ

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

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

ਜਾਂ ਤਾਂ ਪਹਿਲੀ ਜਾਂ ਦੂਜੀ ਸਕੀਮ ਵਿੱਚ, ਜੇਕਰ ਇੱਕ ਡੀਸੀ ਉਪਲਬਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਦੂਜੀ ਸਕੀਮ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ।

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

ਭਾਲੋ ਅਤੇ ਤੁਸੀਂ ਲੱਭੋਗੇ!

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

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

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

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

ਆਖਰਕਾਰ ਅਸੀਂ ਤਰਨਟੂਲ 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ।

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

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

ਲਾਗੂ ਕਰਨਾ ਇੱਕ ਮੋਟਾ ਸ਼ੁਰੂਆਤ ਕਰਨ ਲਈ ਬੰਦ ਹੋਇਆ

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

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

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

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

ਵੰਡੋ ਅਤੇ ਰਾਜ ਕਰੋ। ਲੂਆ ਨਾਲ ਕੀ ਸੌਦਾ ਹੈ?

ਇੱਕ ਗੰਭੀਰ ਦੁਬਿਧਾ ਸੀ: ਕੁਝ ਟੀਮਾਂ ਲੁਆ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਤਰਕ ਦੇ ਨਾਲ ਇੱਕ ਸੇਵਾ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਭਰੋਸੇਮੰਦ ਰੂਪ ਵਿੱਚ ਰੋਲ ਆਊਟ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸਨ। ਇਹ ਅਕਸਰ ਸੇਵਾ ਦੇ ਕੰਮ ਨਾ ਕਰਨ ਦੇ ਨਾਲ ਹੁੰਦਾ ਸੀ।

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

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

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

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

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਸੇਵਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਉਪਭੋਗਤਾ ਪ੍ਰੋਫਾਈਲ ਹੈ। ਯਾਨੀ, ਸਾਰੇ ਵਾਈਲਡਬੇਰੀ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਟਾਰਨਟੂਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਲਗਭਗ 50 ਮਿਲੀਅਨ ਹਨ। ਉਪਭੋਗਤਾ ID ਦੁਆਰਾ ਸਾਂਝਾ ਕੀਤਾ ਗਿਆ ਇੱਕ ਸਿਸਟਮ, Go ਸੇਵਾਵਾਂ ਨਾਲ ਜੁੜੇ ਕਈ DC ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।
ਆਰਪੀਐਸ ਦੇ ਅਨੁਸਾਰ, ਪ੍ਰਮੋਟਰ ਇੱਕ ਵਾਰ ਲੀਡਰ ਸੀ, 6 ਹਜ਼ਾਰ ਬੇਨਤੀਆਂ ਤੱਕ ਪਹੁੰਚ ਰਿਹਾ ਸੀ। ਇਕ ਸਮੇਂ ਸਾਡੇ ਕੋਲ 50-60 ਕਾਪੀਆਂ ਸਨ। ਹੁਣ RPS ਵਿੱਚ ਲੀਡਰ ਯੂਜ਼ਰ ਪ੍ਰੋਫਾਈਲ ਹਨ, ਲਗਭਗ 12 ਹਜ਼ਾਰ। ਇਹ ਸੇਵਾ ਉਪਭੋਗਤਾ IDs ਦੀਆਂ ਰੇਂਜਾਂ ਦੁਆਰਾ ਵੰਡ ਕੇ, ਕਸਟਮ ਸ਼ਾਰਡਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ। ਸੇਵਾ 20 ਤੋਂ ਵੱਧ ਮਸ਼ੀਨਾਂ ਦੀ ਸੇਵਾ ਕਰਦੀ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ; ਅਸੀਂ ਨਿਰਧਾਰਤ ਸਰੋਤਾਂ ਨੂੰ ਘਟਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਕਿਉਂਕਿ 4-5 ਮਸ਼ੀਨਾਂ ਦੀ ਸਮਰੱਥਾ ਇਸਦੇ ਲਈ ਕਾਫੀ ਹੈ।

ਸੈਸ਼ਨ ਸੇਵਾ vshard ਅਤੇ ਕਾਰਟ੍ਰੀਜ 'ਤੇ ਸਾਡੀ ਪਹਿਲੀ ਸੇਵਾ ਹੈ। vshard ਸੈਟ ਅਪ ਕਰਨ ਅਤੇ ਕਾਰਟ੍ਰੀਜ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਲਈ ਸਾਡੇ ਤੋਂ ਕੁਝ ਜਤਨ ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਪਰ ਅੰਤ ਵਿੱਚ ਸਭ ਕੁਝ ਠੀਕ ਹੋ ਗਿਆ।

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

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

ਵੇਟਿੰਗ ਲਿਸਟ, ਕਲਾਇੰਟ ਸਬਸਕ੍ਰਿਪਸ਼ਨ, ਵਰਤਮਾਨ ਵਿੱਚ ਫੈਸ਼ਨੇਬਲ ਕਹਾਣੀਆਂ ਅਤੇ ਮੁਲਤਵੀ ਸਾਮਾਨ ਦੀਆਂ ਸੇਵਾਵਾਂ ਵੀ Tarantool ਨਾਲ ਕੰਮ ਕਰਦੀਆਂ ਹਨ। ਮੈਮੋਰੀ ਵਿੱਚ ਆਖਰੀ ਸੇਵਾ ਲਗਭਗ 120 GB ਤੱਕ ਲੈਂਦੀ ਹੈ। ਇਹ ਉਪਰੋਕਤ ਦੀ ਸਭ ਤੋਂ ਵਿਆਪਕ ਸੇਵਾ ਹੈ।

ਸਿੱਟਾ

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

ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਕੀ ਪੜ੍ਹਨਾ ਹੈ

• Tarantool ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਕ੍ਰੈਚ ਤੋਂ ਇੱਕ ਉੱਚ-ਲੋਡ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣਾ habr.com/ru/company/mailru/blog/510440
• ਤਰਨਟੂਲ ਕਾਰਟ੍ਰੀਜ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਨੇਤਾ ਦੀ ਚੋਣ habr.com/ru/company/mailru/blog/513912
• ਉਤਪਾਦ ਬਾਰੇ ਖ਼ਬਰਾਂ ਦੇ ਨਾਲ ਟੈਲੀਗ੍ਰਾਮ ਚੈਨਲ Tarantool t.me/tarantool_news
• ਕਮਿਊਨਿਟੀ ਚੈਟ ਵਿੱਚ ਤਰਨਟੂਲ ਬਾਰੇ ਚਰਚਾ ਕਰੋ t.me/tarantoolru

ਸਰੋਤ: www.habr.com