ਇੱਕ ਹੋਰ ਨਿਗਰਾਨੀ ਸਿਸਟਮ

16 ਮਾਡਮ, 4 ਸੈਲੂਲਰ ਆਪਰੇਟਰ = ਆਊਟਗੋਇੰਗ ਸਪੀਡ 933.45 Mbit/s

ਜਾਣ ਪਛਾਣ

ਸਤ ਸ੍ਰੀ ਅਕਾਲ! ਇਹ ਲੇਖ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਲਈ ਇੱਕ ਨਵੀਂ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਕਿਵੇਂ ਲਿਖੀ ਹੈ। ਇਹ ਉੱਚ-ਵਾਰਵਾਰਤਾ ਸਮਕਾਲੀ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਬਹੁਤ ਘੱਟ ਸਰੋਤ ਖਪਤ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਵਿੱਚ ਮੌਜੂਦਾ ਲੋਕਾਂ ਤੋਂ ਵੱਖਰਾ ਹੈ। ਪੋਲਿੰਗ ਦਰ 0.1 ਨੈਨੋ ਸਕਿੰਟਾਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਵਿਚਕਾਰ ਸਮਕਾਲੀ ਸ਼ੁੱਧਤਾ ਦੇ ਨਾਲ 10 ਮਿਲੀਸਕਿੰਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ। ਸਾਰੀਆਂ ਬਾਈਨਰੀ ਫਾਈਲਾਂ 6 ਮੈਗਾਬਾਈਟ ਉੱਤੇ ਕਬਜ਼ਾ ਕਰਦੀਆਂ ਹਨ।

ਪ੍ਰੋਜੈਕਟ ਬਾਰੇ

ਸਾਡੇ ਕੋਲ ਇੱਕ ਖਾਸ ਉਤਪਾਦ ਹੈ। ਅਸੀਂ ਡੇਟਾ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਚੈਨਲਾਂ ਦੇ ਥ੍ਰੁਪੁੱਟ ਅਤੇ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ ਨੂੰ ਸੰਖੇਪ ਕਰਨ ਲਈ ਇੱਕ ਵਿਆਪਕ ਹੱਲ ਤਿਆਰ ਕਰਦੇ ਹਾਂ। ਇਹ ਉਦੋਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਈ ਚੈਨਲ ਹੁੰਦੇ ਹਨ, ਮੰਨ ਲਓ Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ ਕੁਝ ਹੋਰ (5 Mbit/s), ਨਤੀਜਾ ਇੱਕ ਸਥਿਰ ਅਤੇ ਤੇਜ਼ ਚੈਨਲ ਹੈ, ਜਿਸ ਦੀ ਸਪੀਡ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗੀ ਇਹ: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

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

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

ਸਮੱਸਿਆ ਦਾ ਗਠਨ

ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੋ ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਸ਼੍ਰੇਣੀਆਂ ਦੇ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ: ਰੀਅਲ-ਟਾਈਮ ਮੈਟ੍ਰਿਕਸ ਅਤੇ ਹੋਰ ਸਾਰੇ। ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੀਆਂ ਸਿਰਫ਼ ਹੇਠ ਲਿਖੀਆਂ ਲੋੜਾਂ ਸਨ:

1. ਰੀਅਲ-ਟਾਈਮ ਮੈਟ੍ਰਿਕਸ ਦੀ ਉੱਚ-ਵਾਰਵਾਰਤਾ ਸਮਕਾਲੀ ਪ੍ਰਾਪਤੀ ਅਤੇ ਬਿਨਾਂ ਦੇਰੀ ਦੇ ਸੰਚਾਰ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਤਬਾਦਲਾ।
   ਵੱਖ-ਵੱਖ ਮੈਟ੍ਰਿਕਸ ਦੀ ਉੱਚ ਬਾਰੰਬਾਰਤਾ ਅਤੇ ਸਮਕਾਲੀਕਰਨ ਸਿਰਫ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ, ਇਹ ਡੇਟਾ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਚੈਨਲਾਂ ਦੀ ਐਂਟਰੌਪੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇਕਰ ਇੱਕ ਡਾਟਾ ਟਰਾਂਸਮਿਸ਼ਨ ਚੈਨਲ ਵਿੱਚ ਔਸਤ ਦੇਰੀ 30 ਮਿਲੀਸਕਿੰਟ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਇੱਕ ਮਿਲੀਸਕਿੰਟ ਦੇ ਬਾਕੀ ਮੈਟ੍ਰਿਕਸ ਵਿਚਕਾਰ ਸਮਕਾਲੀਕਰਨ ਵਿੱਚ ਇੱਕ ਤਰੁੱਟੀ ਨਤੀਜੇ ਵਾਲੇ ਚੈਨਲ ਦੀ ਗਤੀ ਨੂੰ ਲਗਭਗ 5% ਤੱਕ ਘਟਾ ਦੇਵੇਗੀ। ਜੇਕਰ ਅਸੀਂ 1 ਚੈਨਲਾਂ ਵਿੱਚ ਸਮੇਂ ਨੂੰ 4 ਮਿਲੀਸਕਿੰਟ ਦੁਆਰਾ ਮਿਸਟਾਈਮ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਸਪੀਡ ਡਿਗਰੇਡੇਸ਼ਨ ਆਸਾਨੀ ਨਾਲ 30% ਤੱਕ ਘਟ ਸਕਦੀ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਚੈਨਲਾਂ ਵਿੱਚ ਐਨਟ੍ਰੋਪੀ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਇਸਲਈ ਜੇਕਰ ਅਸੀਂ ਇਸਨੂੰ ਹਰ 0.5 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਇੱਕ ਵਾਰ ਤੋਂ ਘੱਟ ਮਾਪਦੇ ਹਾਂ, ਤਾਂ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਦੇਰੀ ਨਾਲ ਤੇਜ਼ ਚੈਨਲਾਂ 'ਤੇ ਸਾਨੂੰ ਹਾਈ ਸਪੀਡ ਡਿਗਰੇਡੇਸ਼ਨ ਮਿਲੇਗਾ। ਬੇਸ਼ੱਕ, ਸਾਰੀਆਂ ਮੈਟ੍ਰਿਕਸ ਲਈ ਅਜਿਹੀ ਸ਼ੁੱਧਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ ਅਤੇ ਨਾ ਹੀ ਸਾਰੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ। ਜਦੋਂ ਚੈਨਲ ਵਿੱਚ ਦੇਰੀ 500 ਮਿਲੀਸਕਿੰਟ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਅਸੀਂ ਅਜਿਹੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਾਂ, ਤਾਂ 1 ਮਿਲੀਸਕਿੰਟ ਦੀ ਇੱਕ ਗਲਤੀ ਲਗਭਗ ਧਿਆਨ ਦੇਣ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗੀ। ਨਾਲ ਹੀ, ਲਾਈਫ ਸਪੋਰਟ ਸਿਸਟਮ ਮੈਟ੍ਰਿਕਸ ਲਈ, ਸਾਡੇ ਕੋਲ 2 ਸਕਿੰਟਾਂ ਦੀ ਕਾਫੀ ਪੋਲਿੰਗ ਅਤੇ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ ਦਰਾਂ ਹਨ, ਪਰ ਨਿਗਰਾਨੀ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਵਿੱਚ ਅਤਿ-ਉੱਚ ਪੋਲਿੰਗ ਦਰਾਂ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਅਤਿ-ਸਹੀ ਸਮਕਾਲੀਕਰਨ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
2. ਨਿਊਨਤਮ ਸਰੋਤ ਦੀ ਖਪਤ ਅਤੇ ਇੱਕ ਸਿੰਗਲ ਸਟੈਕ।
   ਅੰਤਮ ਯੰਤਰ ਜਾਂ ਤਾਂ ਇੱਕ ਸ਼ਕਤੀਸ਼ਾਲੀ ਆਨ-ਬੋਰਡ ਕੰਪਲੈਕਸ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਸੜਕ 'ਤੇ ਸਥਿਤੀ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਲੋਕਾਂ ਦੀ ਬਾਇਓਮੀਟ੍ਰਿਕ ਰਿਕਾਰਡਿੰਗ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਇੱਕ ਹਥੇਲੀ ਦੇ ਆਕਾਰ ਦਾ ਸਿੰਗਲ-ਬੋਰਡ ਕੰਪਿਊਟਰ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸ ਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬਲ ਦਾ ਸਿਪਾਹੀ ਵੀਡੀਓ ਪ੍ਰਸਾਰਿਤ ਕਰਨ ਲਈ ਆਪਣੇ ਸਰੀਰ ਦੇ ਬਸਤ੍ਰ ਦੇ ਹੇਠਾਂ ਪਹਿਨਦਾ ਹੈ। ਮਾੜੀ ਸੰਚਾਰ ਸਥਿਤੀਆਂ ਵਿੱਚ ਅਸਲ ਸਮਾਂ. ਅਜਿਹੇ ਕਈ ਤਰ੍ਹਾਂ ਦੇ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਦੇ ਬਾਵਜੂਦ, ਅਸੀਂ ਉਹੀ ਸਾਫਟਵੇਅਰ ਸਟੈਕ ਰੱਖਣਾ ਚਾਹੁੰਦੇ ਹਾਂ।
3. ਛਤਰੀ ਆਰਕੀਟੈਕਚਰ
   ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਅੰਤਮ ਡਿਵਾਈਸ 'ਤੇ ਇਕੱਠਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਅਤੇ ਪੂਰਵ-ਅਨੁਮਾਨ ਵਿੱਚ ਵਿਜ਼ੁਅਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਕੁਨੈਕਸ਼ਨ ਹੈ, ਤਾਂ ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ। ਜਦੋਂ ਕੋਈ ਕੁਨੈਕਸ਼ਨ ਨਹੀਂ ਹੁੰਦਾ, ਤਾਂ ਭੇਜਣ ਵਾਲੀ ਕਤਾਰ ਇਕੱਠੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ RAM ਦੀ ਖਪਤ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ।
4. ਗਾਹਕ ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਿੱਚ ਏਕੀਕਰਣ ਲਈ API, ਕਿਉਂਕਿ ਕਿਸੇ ਨੂੰ ਵੀ ਬਹੁਤ ਸਾਰੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਗਾਹਕ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਨਿਗਰਾਨੀ ਵਿੱਚ ਕਿਸੇ ਵੀ ਡਿਵਾਈਸ ਅਤੇ ਨੈਟਵਰਕ ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਕੀ ਹੋਇਆ

ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੰਬੇ ਸਮੇਂ 'ਤੇ ਬੋਝ ਨਾ ਪਾਉਣ ਲਈ, ਮੈਂ ਸਾਰੇ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਦੀਆਂ ਉਦਾਹਰਣਾਂ ਅਤੇ ਮਾਪ ਨਹੀਂ ਦੇਵਾਂਗਾ. ਇਹ ਇਕ ਹੋਰ ਲੇਖ ਵੱਲ ਲੈ ਜਾਵੇਗਾ. ਮੈਂ ਬੱਸ ਇਹ ਕਹਾਂਗਾ ਕਿ ਅਸੀਂ ਇੱਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਅਸਮਰੱਥ ਹਾਂ ਜੋ 1 ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਘੱਟ ਦੀ ਗਲਤੀ ਨਾਲ ਇੱਕੋ ਸਮੇਂ ਦੋ ਮੈਟ੍ਰਿਕਸ ਲੈਣ ਦੇ ਸਮਰੱਥ ਹੈ ਅਤੇ ਜੋ ਕਿ 64 MB RAM ਦੇ ਨਾਲ ARM ਆਰਕੀਟੈਕਚਰ ਅਤੇ 86 ਦੇ ਨਾਲ x64_32 ਆਰਕੀਟੈਕਚਰ ਦੋਵਾਂ 'ਤੇ ਬਰਾਬਰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। RAM ਦਾ GB। ਇਸ ਲਈ, ਅਸੀਂ ਆਪਣੇ ਆਪ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਜੋ ਇਹ ਸਭ ਕੁਝ ਕਰ ਸਕਦਾ ਹੈ. ਇੱਥੇ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ ਹੈ:

ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ ਟੌਪੋਲੋਜੀਜ਼ ਲਈ ਤਿੰਨ ਚੈਨਲਾਂ ਦੇ ਥ੍ਰੋਪੁੱਟ ਦਾ ਸਾਰ ਦੇਣਾ

ਕੁਝ ਮੁੱਖ ਮੈਟ੍ਰਿਕਸ ਦੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ

ਆਰਕੀਟੈਕਚਰ

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

ਸਿਸਟਮ ਨੂੰ ਕਲਾਸਿਕ ਮਾਡਯੂਲਰ ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਕਈ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਸ਼ਾਮਲ ਹਨ:

1. ਮੈਟ੍ਰਿਕਸ ਰਜਿਸਟ੍ਰੇਸ਼ਨ।
   ਹਰੇਕ ਮੈਟ੍ਰਿਕ ਨੂੰ ਇਸਦੇ ਆਪਣੇ ਥ੍ਰੈਡ ਦੁਆਰਾ ਪਰੋਸਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਾਰੇ ਚੈਨਲਾਂ ਵਿੱਚ ਸਮਕਾਲੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਅਸੀਂ 10 ਨੈਨੋ ਸਕਿੰਟਾਂ ਤੱਕ ਸਮਕਾਲੀਕਰਨ ਸ਼ੁੱਧਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ।
2. ਮੈਟ੍ਰਿਕਸ ਸਟੋਰੇਜ
   ਅਸੀਂ ਸਮਾਂ ਲੜੀ ਲਈ ਆਪਣੀ ਖੁਦ ਦੀ ਸਟੋਰੇਜ ਲਿਖਣ ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਉਪਲਬਧ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਵਿਚਕਾਰ ਚੋਣ ਕਰ ਰਹੇ ਸੀ। ਡਾਟਾਬੇਸ ਨੂੰ ਪਿਛਾਖੜੀ ਡੇਟਾ ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਜੋ ਬਾਅਦ ਦੇ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ ਦੇ ਅਧੀਨ ਹੈ। ਭਾਵ, ਇਸ ਵਿੱਚ ਚੈਨਲ ਵਿੱਚ ਹਰ 0.5 ਮਿਲੀਸਕਿੰਟ ਜਾਂ ਟ੍ਰਾਂਸਪੋਰਟ ਨੈਟਵਰਕ ਵਿੱਚ ਗਲਤੀ ਰੀਡਿੰਗ ਵਿੱਚ ਦੇਰੀ ਦਾ ਡੇਟਾ ਨਹੀਂ ਹੈ, ਪਰ ਹਰੇਕ ਇੰਟਰਫੇਸ ਵਿੱਚ ਹਰ 500 ਮਿਲੀਸਕਿੰਟ ਵਿੱਚ ਗਤੀ ਹੈ। ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਅਤੇ ਘੱਟ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਲਈ ਉੱਚ ਲੋੜਾਂ ਤੋਂ ਇਲਾਵਾ, ਸਾਡੇ ਲਈ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਡਾਟਾ ਉਹ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਸਾਰੇ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤ ਬਚਾਉਂਦਾ ਹੈ। ਅਸੀਂ 2016 ਤੋਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ Tarantool DBMS ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ ਅਤੇ ਹੁਣ ਤੱਕ ਸਾਨੂੰ ਦੂਰੀ 'ਤੇ ਇਸਦਾ ਬਦਲ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਲਚਕਦਾਰ, ਸਰਵੋਤਮ ਸਰੋਤ ਖਪਤ ਦੇ ਨਾਲ, ਲੋੜੀਂਦੀ ਤਕਨੀਕੀ ਸਹਾਇਤਾ ਤੋਂ ਵੱਧ। Tarantool ਇੱਕ GIS ਮੋਡੀਊਲ ਵੀ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਇਹ ਪੋਸਟਜੀਆਈਐਸ ਜਿੰਨਾ ਸ਼ਕਤੀਸ਼ਾਲੀ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਕੁਝ ਸਥਾਨ-ਸਬੰਧਤ ਮੈਟ੍ਰਿਕਸ (ਟ੍ਰਾਂਸਪੋਰਟ ਲਈ ਢੁਕਵੇਂ) ਨੂੰ ਸਟੋਰ ਕਰਨ ਦੇ ਸਾਡੇ ਕੰਮਾਂ ਲਈ ਕਾਫੀ ਹੈ।
3. ਮੈਟ੍ਰਿਕਸ ਦੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ
   ਇੱਥੇ ਹਰ ਚੀਜ਼ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਹੈ. ਅਸੀਂ ਵੇਅਰਹਾਊਸ ਤੋਂ ਡੇਟਾ ਲੈਂਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਅਸਲ ਸਮੇਂ ਵਿੱਚ ਜਾਂ ਪੂਰਵ-ਅਨੁਮਾਨ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।
4. ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨਾਲ ਡੇਟਾ ਦਾ ਸਮਕਾਲੀਕਰਨ।
   ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਸਾਰੇ ਡਿਵਾਈਸਾਂ ਤੋਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ, ਇਸਨੂੰ ਇੱਕ ਨਿਸ਼ਚਿਤ ਇਤਿਹਾਸ ਨਾਲ ਸਟੋਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇਸਨੂੰ API ਦੁਆਰਾ ਗਾਹਕ ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਨੂੰ ਭੇਜਦੀ ਹੈ। ਕਲਾਸਿਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਉਲਟ, ਜਿਸ ਵਿੱਚ "ਸਿਰ" ਘੁੰਮਦਾ ਹੈ ਅਤੇ ਡੇਟਾ ਇਕੱਠਾ ਕਰਦਾ ਹੈ, ਸਾਡੇ ਕੋਲ ਉਲਟ ਸਕੀਮ ਹੈ। ਜਦੋਂ ਕੋਈ ਕਨੈਕਸ਼ਨ ਹੁੰਦਾ ਹੈ ਤਾਂ ਡਿਵਾਈਸ ਆਪਣੇ ਆਪ ਡਾਟਾ ਭੇਜਦੇ ਹਨ। ਇਹ ਇੱਕ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਬਿੰਦੂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਡਿਵਾਈਸ ਤੋਂ ਉਹਨਾਂ ਸਮੇਂ ਲਈ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦੌਰਾਨ ਇਹ ਉਪਲਬਧ ਨਹੀਂ ਸੀ ਅਤੇ ਜਦੋਂ ਡਿਵਾਈਸ ਉਪਲਬਧ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਤਾਂ ਚੈਨਲਾਂ ਅਤੇ ਸਰੋਤਾਂ ਨੂੰ ਲੋਡ ਨਹੀਂ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਵਜੋਂ ਇਨਫਲਕਸ ਨਿਗਰਾਨੀ ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਇਸਦੇ ਐਨਾਲਾਗਸ ਦੇ ਉਲਟ, ਇਹ ਪੂਰਵ-ਅਨੁਸਾਰੀ ਡੇਟਾ ਨੂੰ ਆਯਾਤ ਕਰ ਸਕਦਾ ਹੈ (ਜੋ ਕਿ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਾਪਤ ਕੀਤੇ ਗਏ ਪਲ ਤੋਂ ਵੱਖਰੇ ਸਮੇਂ ਦੀ ਮੋਹਰ ਦੇ ਨਾਲ)। ਇਕੱਤਰ ਕੀਤੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਗ੍ਰਾਫਾਨਾ ਦੁਆਰਾ ਕਲਪਨਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਫਾਈਲ ਨਾਲ ਸੋਧਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਟੈਂਡਰਡ ਸਟੈਕ ਨੂੰ ਵੀ ਚੁਣਿਆ ਗਿਆ ਸੀ ਕਿਉਂਕਿ ਇਸ ਵਿੱਚ ਲਗਭਗ ਕਿਸੇ ਵੀ ਗਾਹਕ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੇ ਨਾਲ ਤਿਆਰ API ਏਕੀਕਰਣ ਹੈ।
5. ਇੱਕ ਕੇਂਦਰੀ ਡਿਵਾਈਸ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਦੇ ਨਾਲ ਡੇਟਾ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ੇਸ਼ਨ।
   ਡਿਵਾਈਸ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਜ਼ੀਰੋ ਟਚ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ (ਫਰਮਵੇਅਰ, ਸੰਰਚਨਾ, ਆਦਿ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ) ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ, ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਦੇ ਉਲਟ, ਪ੍ਰਤੀ ਡਿਵਾਈਸ ਸਿਰਫ਼ ਸਮੱਸਿਆਵਾਂ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਇਹ ਆਨ-ਬੋਰਡ ਹਾਰਡਵੇਅਰ ਵਾਚਡੌਗ ਸੇਵਾਵਾਂ ਅਤੇ ਜੀਵਨ ਸਹਾਇਤਾ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਸਾਰੇ ਮੈਟ੍ਰਿਕਸ ਦੇ ਸੰਚਾਲਨ ਲਈ ਟਰਿਗਰ ਹਨ: CPU ਅਤੇ SSD ਤਾਪਮਾਨ, CPU ਲੋਡ, ਖਾਲੀ ਥਾਂ ਅਤੇ ਡਿਸਕਾਂ 'ਤੇ ਸਮਾਰਟ ਹੈਲਥ। ਸਬ-ਸਿਸਟਮ ਸਟੋਰੇਜ਼ ਵੀ Tarantool 'ਤੇ ਬਣਾਇਆ ਗਿਆ ਹੈ. ਇਹ ਸਾਨੂੰ ਹਜ਼ਾਰਾਂ ਡਿਵਾਈਸਾਂ ਵਿੱਚ ਸਮਾਂ ਲੜੀ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਗਤੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਡਿਵਾਈਸਾਂ ਨਾਲ ਡੇਟਾ ਨੂੰ ਸਮਕਾਲੀ ਕਰਨ ਦੇ ਮੁੱਦੇ ਨੂੰ ਵੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦਾ ਹੈ। Tarantool ਵਿੱਚ ਇੱਕ ਸ਼ਾਨਦਾਰ ਕਤਾਰਬੰਦੀ ਅਤੇ ਗਾਰੰਟੀਸ਼ੁਦਾ ਡਿਲੀਵਰੀ ਸਿਸਟਮ ਹੈ। ਸਾਨੂੰ ਇਹ ਮਹੱਤਵਪੂਰਣ ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਮਿਲੀ, ਬਹੁਤ ਵਧੀਆ!

ਨੈੱਟਵਰਕ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ

ਅੱਗੇ ਕੀ ਹੈ

ਹੁਣ ਤੱਕ, ਸਾਡੀ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਕੜੀ ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਹੈ। ਇਹ ਇੱਕ ਮਿਆਰੀ ਸਟੈਕ 'ਤੇ 99.9% ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸਦੇ ਕਈ ਨੁਕਸਾਨ ਹਨ:

1. ਪਾਵਰ ਖਤਮ ਹੋਣ 'ਤੇ InfluxDB ਡਾਟਾ ਗੁਆ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਗਾਹਕ ਡਿਵਾਈਸਾਂ ਤੋਂ ਆਉਣ ਵਾਲੀ ਹਰ ਚੀਜ਼ ਨੂੰ ਤੁਰੰਤ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਅਤੇ ਡੇਟਾਬੇਸ ਵਿੱਚ 5 ਮਿੰਟ ਤੋਂ ਪੁਰਾਣਾ ਡੇਟਾ ਨਹੀਂ ਹੁੰਦਾ ਹੈ, ਪਰ ਭਵਿੱਖ ਵਿੱਚ ਇਹ ਇੱਕ ਦਰਦ ਬਣ ਸਕਦਾ ਹੈ।
2. ਗ੍ਰਾਫਾਨਾ ਨੂੰ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਇਸਦੇ ਡਿਸਪਲੇਅ ਦੇ ਸਮਕਾਲੀਕਰਨ ਨਾਲ ਕਈ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਸਭ ਤੋਂ ਆਮ ਸਮੱਸਿਆ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਡੇਟਾਬੇਸ ਵਿੱਚ 2:00:00 ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ 00 ਸਕਿੰਟਾਂ ਦੇ ਅੰਤਰਾਲ ਦੇ ਨਾਲ ਇੱਕ ਸਮਾਂ ਲੜੀ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਗ੍ਰਾਫਾਨਾ +1 ਸਕਿੰਟ ਤੋਂ ਇਕੱਤਰਤਾ ਵਿੱਚ ਡੇਟਾ ਦਿਖਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਉਪਭੋਗਤਾ ਇੱਕ ਡਾਂਸਿੰਗ ਗ੍ਰਾਫ ਦੇਖਦਾ ਹੈ।
3. ਤੀਜੀ-ਧਿਰ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀਆਂ ਦੇ ਨਾਲ API ਏਕੀਕਰਣ ਲਈ ਕੋਡ ਦੀ ਬਹੁਤ ਜ਼ਿਆਦਾ ਮਾਤਰਾ। ਇਸਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸੰਖੇਪ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਬੇਸ਼ਕ ਗੋ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ)

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

ਸਿੱਟਾ

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

ਜੇ ਕਿਸੇ ਕੋਲ ਇਸ ਲੇਖ ਦੇ ਦਾਇਰੇ ਤੋਂ ਬਾਹਰ ਕੋਈ ਸਵਾਲ ਹਨ, ਤਾਂ ਤੁਸੀਂ ਮੈਨੂੰ a.rodin @ qedr.com 'ਤੇ ਲਿਖ ਸਕਦੇ ਹੋ

ਸਰੋਤ: www.habr.com