ਅਸੀਂ 1C ਲਈ ਇੱਕ ਉੱਚ-ਲੋਡ ਸਕੇਲੇਬਲ ਸੇਵਾ ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ ਲਿਖੀ: Enterprise: Java, PostgreSQL, Hazelcast

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

ਇੰਟਰਐਕਸ਼ਨ ਸਿਸਟਮ (ਇਸ ਤੋਂ ਬਾਅਦ SV ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਗਾਰੰਟੀਸ਼ੁਦਾ ਡਿਲੀਵਰੀ ਦੇ ਨਾਲ ਇੱਕ ਵੰਡਿਆ, ਨੁਕਸ-ਸਹਿਣਸ਼ੀਲ ਮੈਸੇਜਿੰਗ ਸਿਸਟਮ ਹੈ। SV ਨੂੰ ਉੱਚ ਮਾਪਯੋਗਤਾ ਦੇ ਨਾਲ ਇੱਕ ਉੱਚ-ਲੋਡ ਸੇਵਾ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਇੱਕ ਔਨਲਾਈਨ ਸੇਵਾ (1C ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀ ਗਈ) ਅਤੇ ਇੱਕ ਵੱਡੇ-ਵੱਡੇ ਉਤਪਾਦ ਦੇ ਰੂਪ ਵਿੱਚ ਉਪਲਬਧ ਹੈ ਜੋ ਤੁਹਾਡੀਆਂ ਸਰਵਰ ਸੁਵਿਧਾਵਾਂ 'ਤੇ ਤੈਨਾਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

SV ਵੰਡਿਆ ਸਟੋਰੇਜ ਵਰਤਦਾ ਹੈ ਹੇਜ਼ਲਕਾਸਟ ਅਤੇ ਖੋਜ ਇੰਜਣ ਲਲਸੀ ਖੋਜ. ਅਸੀਂ Java ਬਾਰੇ ਵੀ ਗੱਲ ਕਰਾਂਗੇ ਅਤੇ ਕਿਵੇਂ ਅਸੀਂ PostgreSQL ਨੂੰ ਖਿਤਿਜੀ ਤੌਰ 'ਤੇ ਸਕੇਲ ਕਰਦੇ ਹਾਂ।

ਸਮੱਸਿਆ ਦਾ ਗਠਨ

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

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

ਕਲਾਇੰਟ-ਸਰਵਰ ਵਿਕਾਸ ਪੈਰਾਡਾਈਮ

1C 'ਤੇ ਬਣਾਏ ਗਏ ਕਾਰੋਬਾਰੀ ਐਪਲੀਕੇਸ਼ਨ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਤਿੰਨ-ਪੱਧਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ ਕਲਾਇੰਟ-ਸਰਵਰ ਆਰਕੀਟੈਕਚਰ “DBMS – ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ – ਕਲਾਇੰਟ”। ਵਿੱਚ ਲਿਖਿਆ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਬਿਲਟ-ਇਨ 1C ਭਾਸ਼ਾ, ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਜਾਂ ਕਲਾਇੰਟ 'ਤੇ ਚਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਆਬਜੈਕਟ (ਡਾਇਰੈਕਟਰੀਆਂ, ਦਸਤਾਵੇਜ਼, ਆਦਿ) ਦੇ ਨਾਲ-ਨਾਲ ਡਾਟਾਬੇਸ ਨੂੰ ਪੜ੍ਹਨ ਅਤੇ ਲਿਖਣ ਦੇ ਨਾਲ ਸਾਰੇ ਕੰਮ ਸਿਰਫ਼ ਸਰਵਰ 'ਤੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਫਾਰਮ ਅਤੇ ਕਮਾਂਡ ਇੰਟਰਫੇਸ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਸਰਵਰ 'ਤੇ ਵੀ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਕਲਾਇੰਟ ਫਾਰਮਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ, ਖੋਲ੍ਹਣਾ ਅਤੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨਾ, ਉਪਭੋਗਤਾ ਨਾਲ "ਸੰਵਾਦ" (ਚੇਤਾਵਨੀਆਂ, ਸਵਾਲ...), ਫਾਰਮਾਂ ਵਿੱਚ ਛੋਟੀਆਂ ਗਣਨਾਵਾਂ ਕਰਦਾ ਹੈ ਜਿਸ ਲਈ ਤੁਰੰਤ ਜਵਾਬ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਕੀਮਤ ਨੂੰ ਮਾਤਰਾ ਨਾਲ ਗੁਣਾ ਕਰਨਾ), ਸਥਾਨਕ ਫਾਈਲਾਂ ਨਾਲ ਕੰਮ ਕਰਨਾ, ਸਾਜ਼ੋ-ਸਾਮਾਨ ਨਾਲ ਕੰਮ ਕਰਨਾ.

ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਵਿੱਚ, ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਦੇ ਸਿਰਲੇਖਾਂ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇਹ ਦਰਸਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਡ ਕਿੱਥੇ ਲਾਗੂ ਕੀਤਾ ਜਾਵੇਗਾ - &AtClient / &AtServer ਨਿਰਦੇਸ਼ਾਂ (&AtClient / &AtServer ਭਾਸ਼ਾ ਦੇ ਅੰਗਰੇਜ਼ੀ ਸੰਸਕਰਣ ਵਿੱਚ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ। 1C ਡਿਵੈਲਪਰ ਹੁਣ ਮੈਨੂੰ ਇਹ ਕਹਿ ਕੇ ਠੀਕ ਕਰਨਗੇ ਕਿ ਨਿਰਦੇਸ਼ ਅਸਲ ਵਿੱਚ ਹਨ ਵੱਧ ਹੋਰ, ਪਰ ਸਾਡੇ ਲਈ ਇਹ ਹੁਣ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ।

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

ਕੋਡ ਜੋ ਇੱਕ ਬਟਨ ਕਲਿੱਕ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ: ਕਲਾਇੰਟ ਤੋਂ ਇੱਕ ਸਰਵਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਾਲ ਕਰਨਾ ਕੰਮ ਕਰੇਗਾ, ਸਰਵਰ ਤੋਂ ਇੱਕ ਕਲਾਇੰਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਕਾਲ ਕਰਨਾ ਨਹੀਂ ਹੋਵੇਗਾ

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

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

ਉਤਪਾਦਨ ਆਪਣੇ ਆਪ

ਇੱਕ ਮੈਸੇਜਿੰਗ ਵਿਧੀ ਬਣਾਓ। ਤੇਜ਼, ਭਰੋਸੇਮੰਦ, ਗਾਰੰਟੀਸ਼ੁਦਾ ਡਿਲੀਵਰੀ ਦੇ ਨਾਲ, ਸੁਨੇਹਿਆਂ ਨੂੰ ਲਚਕਦਾਰ ਤਰੀਕੇ ਨਾਲ ਖੋਜਣ ਦੀ ਯੋਗਤਾ ਦੇ ਨਾਲ। ਵਿਧੀ ਦੇ ਅਧਾਰ 'ਤੇ, 1C ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਅੰਦਰ ਚੱਲ ਰਹੇ ਇੱਕ ਮੈਸੇਂਜਰ (ਸੁਨੇਹੇ, ਵੀਡੀਓ ਕਾਲਾਂ) ਨੂੰ ਲਾਗੂ ਕਰੋ।

ਸਿਸਟਮ ਨੂੰ ਖਿਤਿਜੀ ਤੌਰ 'ਤੇ ਸਕੇਲੇਬਲ ਬਣਾਉਣ ਲਈ ਡਿਜ਼ਾਈਨ ਕਰੋ। ਵਧ ਰਹੇ ਲੋਡ ਨੂੰ ਨੋਡਾਂ ਦੀ ਗਿਣਤੀ ਵਧਾ ਕੇ ਕਵਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

Реализация

ਅਸੀਂ SV ਦੇ ਸਰਵਰ ਹਿੱਸੇ ਨੂੰ ਸਿੱਧੇ 1C:Enterprise ਪਲੇਟਫਾਰਮ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਪਰ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਜੋਂ ਲਾਗੂ ਕਰਨ ਲਈ, ਜਿਸਦਾ API ਨੂੰ 1C ਐਪਲੀਕੇਸ਼ਨ ਹੱਲਾਂ ਦੇ ਕੋਡ ਤੋਂ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਮੁੱਖ ਇੱਕ ਇਹ ਸੀ ਕਿ ਮੈਂ ਵੱਖ-ਵੱਖ 1C ਐਪਲੀਕੇਸ਼ਨਾਂ (ਉਦਾਹਰਨ ਲਈ, ਵਪਾਰ ਪ੍ਰਬੰਧਨ ਅਤੇ ਲੇਖਾਕਾਰੀ ਵਿਚਕਾਰ) ਵਿੱਚ ਸੰਦੇਸ਼ਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਨਾ ਸੰਭਵ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ। ਵੱਖ-ਵੱਖ 1C ਐਪਲੀਕੇਸ਼ਨਾਂ 1C ਦੇ ਵੱਖ-ਵੱਖ ਸੰਸਕਰਣਾਂ 'ਤੇ ਚੱਲ ਸਕਦੀਆਂ ਹਨ: ਐਂਟਰਪ੍ਰਾਈਜ਼ ਪਲੇਟਫਾਰਮ, ਵੱਖ-ਵੱਖ ਸਰਵਰਾਂ 'ਤੇ ਸਥਿਤ ਹੋਣਾ, ਆਦਿ। ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, 1C ਸਥਾਪਨਾਵਾਂ ਦੇ "ਪਾਸੇ" ਸਥਿਤ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਜੋਂ SV ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸਰਵੋਤਮ ਹੱਲ ਹੈ।

ਇਸ ਲਈ, ਅਸੀਂ SV ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਜੋਂ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਛੋਟੀਆਂ ਕੰਪਨੀਆਂ CB ਸਰਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ ਜੋ ਅਸੀਂ ਆਪਣੇ ਕਲਾਉਡ (wss://1cdialog.com) ਵਿੱਚ ਸਥਾਪਤ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਸਰਵਰ ਦੀ ਸਥਾਨਕ ਸਥਾਪਨਾ ਅਤੇ ਸੰਰਚਨਾ ਨਾਲ ਸੰਬੰਧਿਤ ਓਵਰਹੈੱਡ ਖਰਚਿਆਂ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕੇ। ਵੱਡੇ ਗਾਹਕਾਂ ਨੂੰ ਆਪਣੀਆਂ ਸੁਵਿਧਾਵਾਂ 'ਤੇ ਆਪਣਾ ਸੀਬੀ ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਕਲਾਉਡ SaaS ਉਤਪਾਦ ਵਿੱਚ ਇੱਕ ਸਮਾਨ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕੀਤੀ 1c ਤਾਜ਼ਾ - ਇਹ ਗਾਹਕਾਂ ਦੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਸਥਾਪਨਾ ਲਈ ਵੱਡੇ ਪੱਧਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਉਤਪਾਦ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸਾਡੇ ਕਲਾਉਡ ਵਿੱਚ ਵੀ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। https://1cfresh.com/.

ਐਪਲੀਕੇਸ਼ਨ

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

ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਸੰਚਾਰ ਵੈਬਸਾਕੇਟ ਦੁਆਰਾ ਹੁੰਦਾ ਹੈ। ਇਹ ਰੀਅਲ-ਟਾਈਮ ਸਿਸਟਮ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ.

ਵੰਡਿਆ ਕੈਸ਼

ਅਸੀਂ Redis, Hazelcast ਅਤੇ Ehcache ਵਿਚਕਾਰ ਚੋਣ ਕੀਤੀ। ਇਹ 2015 ਦੀ ਗੱਲ ਹੈ। ਰੈਡਿਸ ਨੇ ਹੁਣੇ ਹੀ ਇੱਕ ਨਵਾਂ ਕਲੱਸਟਰ ਜਾਰੀ ਕੀਤਾ (ਬਹੁਤ ਨਵਾਂ, ਡਰਾਉਣਾ), ਬਹੁਤ ਸਾਰੀਆਂ ਪਾਬੰਦੀਆਂ ਵਾਲਾ ਸੈਂਟੀਨੇਲ ਹੈ. Ehcache ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਵੇਂ ਇਕੱਠੇ ਹੋਣਾ ਹੈ (ਇਹ ਕਾਰਜਕੁਸ਼ਲਤਾ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਈ)। ਅਸੀਂ ਇਸਨੂੰ ਹੇਜ਼ਲਕਾਸਟ 3.4 ਨਾਲ ਅਜ਼ਮਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।
ਹੇਜ਼ਲਕਾਸਟ ਨੂੰ ਬਾਕਸ ਦੇ ਬਾਹਰ ਇੱਕ ਸਮੂਹ ਵਿੱਚ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਿੰਗਲ ਨੋਡ ਮੋਡ ਵਿੱਚ, ਇਹ ਬਹੁਤ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੈ ਅਤੇ ਸਿਰਫ ਇੱਕ ਕੈਸ਼ ਵਜੋਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ - ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਡੇਟਾ ਨੂੰ ਡਿਸਕ ਵਿੱਚ ਕਿਵੇਂ ਡੰਪ ਕਰਨਾ ਹੈ, ਜੇਕਰ ਤੁਸੀਂ ਇੱਕੋ ਨੋਡ ਗੁਆ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਡੇਟਾ ਗੁਆ ਦਿੰਦੇ ਹੋ। ਅਸੀਂ ਕਈ ਹੇਜ਼ਲਕਾਸਟਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਦੇ ਹਾਂ, ਜਿਨ੍ਹਾਂ ਵਿਚਕਾਰ ਅਸੀਂ ਨਾਜ਼ੁਕ ਡੇਟਾ ਦਾ ਬੈਕਅੱਪ ਲੈਂਦੇ ਹਾਂ। ਅਸੀਂ ਕੈਸ਼ ਦਾ ਬੈਕਅੱਪ ਨਹੀਂ ਲੈਂਦੇ - ਸਾਨੂੰ ਇਸ 'ਤੇ ਕੋਈ ਇਤਰਾਜ਼ ਨਹੀਂ ਹੈ।

ਸਾਡੇ ਲਈ, ਹੇਜ਼ਲਕਾਸਟ ਹੈ:

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

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

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

ਇੱਕ DBMS ਚੁਣਨਾ

ਸਾਡੇ ਕੋਲ PostgreSQL ਨਾਲ ਕੰਮ ਕਰਨ ਅਤੇ ਇਸ DBMS ਦੇ ਡਿਵੈਲਪਰਾਂ ਨਾਲ ਸਹਿਯੋਗ ਕਰਨ ਦਾ ਵਿਆਪਕ ਅਤੇ ਸਫਲ ਤਜਰਬਾ ਹੈ।

PostgreSQL ਕਲੱਸਟਰ ਨਾਲ ਇਹ ਆਸਾਨ ਨਹੀਂ ਹੈ - ਉੱਥੇ ਹੈ XL, XC, ਸਿਟਸ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਇਹ NoSQLs ਨਹੀਂ ਹਨ ਜੋ ਬਾਕਸ ਤੋਂ ਬਾਹਰ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ NoSQL ਨੂੰ ਮੁੱਖ ਸਟੋਰੇਜ ਵਜੋਂ ਨਹੀਂ ਸਮਝਿਆ; ਇਹ ਕਾਫ਼ੀ ਸੀ ਕਿ ਅਸੀਂ ਹੇਜ਼ਲਕਾਸਟ ਲਿਆ, ਜਿਸ ਨਾਲ ਅਸੀਂ ਪਹਿਲਾਂ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਸੀ.

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

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

ਤੁਸੀਂ ਬਹੁ-ਕਿਰਾਏਦਾਰ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਵੈੱਬਸਾਈਟ 'ਤੇ ਸਿਟਸ ਡੇਟਾ.

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

ਸਾਡੇ ਕੋਲ ਇੱਕ ਮੁੱਖ ਡੇਟਾਬੇਸ ਹੈ ਜਿੱਥੇ ਇੱਕ ਰੂਟਿੰਗ ਟੇਬਲ ਨੂੰ ਸਾਰੇ ਗਾਹਕ ਡੇਟਾਬੇਸ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦੇ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਮੁੱਖ ਡੇਟਾਬੇਸ ਨੂੰ ਰੁਕਾਵਟ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ, ਅਸੀਂ ਰੂਟਿੰਗ ਟੇਬਲ (ਅਤੇ ਹੋਰ ਅਕਸਰ ਲੋੜੀਂਦੇ ਡੇਟਾ) ਨੂੰ ਕੈਸ਼ ਵਿੱਚ ਰੱਖਦੇ ਹਾਂ।

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

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

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

ਖੋਜ ਲਈ ਲਚਕਦਾਰ ਖੋਜ

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

github 'ਤੇ ਸਾਨੂੰ ਮਿਲਿਆ ਰੂਸੀ ਰੂਪ ਵਿਗਿਆਨ ਪਲੱਗਇਨ Elasticsearch ਲਈ ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕਰੋ। Elasticsearch ਸੂਚਕਾਂਕ ਵਿੱਚ ਅਸੀਂ ਸ਼ਬਦ ਰੂਟ (ਜੋ ਪਲੱਗਇਨ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ) ਅਤੇ N-ਗ੍ਰਾਮ ਸਟੋਰ ਕਰਦੇ ਹਾਂ। ਜਿਵੇਂ ਹੀ ਉਪਭੋਗਤਾ ਖੋਜ ਕਰਨ ਲਈ ਟੈਕਸਟ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਸੀਂ N-ਗ੍ਰਾਮਾਂ ਵਿੱਚ ਟਾਈਪ ਕੀਤੇ ਟੈਕਸਟ ਦੀ ਖੋਜ ਕਰਦੇ ਹਾਂ। ਜਦੋਂ ਸੂਚਕਾਂਕ ਵਿੱਚ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸ਼ਬਦ "ਟੈਕਸਟ" ਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ N-ਗ੍ਰਾਮਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਵੇਗਾ:

[ਉਹ, ਟੇਕ, ਟੇਕ, ਟੈਕਸਟ, ਟੈਕਸਟ, ਇਕ, ਐਕਸ, ਐਕਸਟ, ਟੈਕਸਟ, ਕੇਐਸ, ਕੇਐਸਟੀ, ਕੇਸਟੀ, ਸਟ, ਸਟਾਈ, ਤੁਸੀਂ],

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

ਵੱਡੀ ਤਸਵੀਰ

ਲੇਖ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਤਸਵੀਰ ਨੂੰ ਦੁਹਰਾਓ, ਪਰ ਸਪੱਸ਼ਟੀਕਰਨ ਦੇ ਨਾਲ:

• ਇੰਟਰਨੈੱਟ 'ਤੇ ਬੈਲੰਸਰ ਦਾ ਪਰਦਾਫਾਸ਼; ਸਾਡੇ ਕੋਲ nginx ਹੈ, ਇਹ ਕੋਈ ਵੀ ਹੋ ਸਕਦਾ ਹੈ।
• ਜਾਵਾ ਐਪਲੀਕੇਸ਼ਨ ਉਦਾਹਰਨਾਂ ਹੇਜ਼ਲਕਾਸਟ ਦੁਆਰਾ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸੰਚਾਰ ਕਰਦੀਆਂ ਹਨ।
• ਇੱਕ ਵੈੱਬ ਸਾਕਟ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ ਨੇਟੀ.
• Java ਐਪਲੀਕੇਸ਼ਨ Java 8 ਵਿੱਚ ਲਿਖੀ ਗਈ ਹੈ ਅਤੇ ਇਸ ਵਿੱਚ ਬੰਡਲ ਹਨ ਓਐਸਜੀ. ਯੋਜਨਾਵਾਂ ਵਿੱਚ Java 10 ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਅਤੇ ਮੋਡੀਊਲ ਵਿੱਚ ਤਬਦੀਲੀ ਸ਼ਾਮਲ ਹੈ।

ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ

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

ਲੋਡ ਟੈਸਟਿੰਗ ਅਤੇ ਮੈਮੋਰੀ ਲੀਕ

ਹਰੇਕ SV ਰੀਲੀਜ਼ ਦੀ ਰਿਲੀਜ਼ ਵਿੱਚ ਲੋਡ ਟੈਸਟਿੰਗ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ। ਇਹ ਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ:

• ਟੈਸਟ ਨੇ ਕਈ ਦਿਨਾਂ ਤੱਕ ਕੰਮ ਕੀਤਾ ਅਤੇ ਕੋਈ ਸੇਵਾ ਅਸਫਲਤਾਵਾਂ ਨਹੀਂ ਸਨ
• ਮੁੱਖ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਜਵਾਬ ਸਮਾਂ ਇੱਕ ਆਰਾਮਦਾਇਕ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਨਹੀਂ ਸੀ
• ਪਿਛਲੇ ਸੰਸਕਰਣ ਦੇ ਮੁਕਾਬਲੇ ਪ੍ਰਦਰਸ਼ਨ ਵਿੱਚ ਗਿਰਾਵਟ 10% ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੈ

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

ਅਸੀਂ ਤਿੰਨ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਇੰਟਰਐਕਸ਼ਨ ਸਿਸਟਮ ਦੀ ਲੋਡ ਟੈਸਟਿੰਗ ਕਰਦੇ ਹਾਂ:

1. ਤਣਾਅ ਟੈਸਟ
2. ਸਿਰਫ਼ ਕੁਨੈਕਸ਼ਨ
3. ਗਾਹਕ ਰਜਿਸਟ੍ਰੇਸ਼ਨ

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

ਉਦਾਹਰਨ ਲਈ, ਤਣਾਅ ਟੈਸਟ ਦਾ ਇਹ ਹਿੱਸਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

• ਉਪਭੋਗਤਾ ਲੌਗ ਇਨ ਕਰਦਾ ਹੈ
  • ਤੁਹਾਡੀਆਂ ਨਾ-ਪੜ੍ਹੀਆਂ ਚਰਚਾਵਾਂ ਲਈ ਬੇਨਤੀ ਕਰਦਾ ਹੈ
  • 50% ਸੁਨੇਹੇ ਪੜ੍ਹਨ ਦੀ ਸੰਭਾਵਨਾ ਹੈ
  • 50% ਟੈਕਸਟ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਹੈ
  • ਅਗਲਾ ਉਪਭੋਗਤਾ:
    • ਨਵੀਂ ਚਰਚਾ ਬਣਾਉਣ ਦੀ 20% ਸੰਭਾਵਨਾ ਹੈ
    • ਬੇਤਰਤੀਬ ਇਸਦੀ ਕਿਸੇ ਵੀ ਚਰਚਾ ਨੂੰ ਚੁਣਦਾ ਹੈ
    • ਅੰਦਰ ਜਾਂਦਾ ਹੈ
    • ਸੁਨੇਹਿਆਂ, ਉਪਭੋਗਤਾ ਪ੍ਰੋਫਾਈਲਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ
    • ਇਸ ਚਰਚਾ ਤੋਂ ਬੇਤਰਤੀਬ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੰਬੋਧਿਤ ਪੰਜ ਸੁਨੇਹੇ ਬਣਾਉਂਦਾ ਹੈ
    • ਚਰਚਾ ਛੱਡਦੀ ਹੈ
    • 20 ਵਾਰ ਦੁਹਰਾਉਂਦਾ ਹੈ
    • ਲੌਗ ਆਉਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਸਕ੍ਰਿਪਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਵਾਪਸ ਜਾਂਦਾ ਹੈ

  • ਇੱਕ ਚੈਟਬੋਟ ਸਿਸਟਮ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦਾ ਹੈ (ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਤੋਂ ਮੈਸੇਜਿੰਗ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ)
    • ਡੇਟਾ ਐਕਸਚੇਂਜ ਲਈ ਇੱਕ ਨਵਾਂ ਚੈਨਲ ਬਣਾਉਣ ਦੀ 50% ਸੰਭਾਵਨਾ ਹੈ (ਵਿਸ਼ੇਸ਼ ਚਰਚਾ)
    • 50% ਮੌਜੂਦਾ ਚੈਨਲਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਸੁਨੇਹਾ ਲਿਖਣ ਦੀ ਸੰਭਾਵਨਾ ਹੈ

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

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

ਅਸੀਂ ਲੋਡ ਜਨਰੇਟਰ ਵਜੋਂ ਵਰਤਦੇ ਹਾਂ ਜੇਮੀਟਰ. ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਵੈਬਸਾਕੇਟ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ; ਇਸ ਨੂੰ ਇੱਕ ਪਲੱਗਇਨ ਦੀ ਲੋੜ ਹੈ। "jmeter websocket" ਪੁੱਛਗਿੱਛ ਲਈ ਖੋਜ ਨਤੀਜਿਆਂ ਵਿੱਚ ਪਹਿਲੇ ਹਨ: ਬਲੇਜ਼ਮੀਟਰ ਤੋਂ ਲੇਖ, ਜੋ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਨ Maciej Zaleski ਦੁਆਰਾ ਪਲੱਗਇਨ.

ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ.

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

ਪਲੱਗਇਨ ਇੱਕ ਵੱਖਰੀ ਵੱਡੀ ਕਹਾਣੀ ਹੈ; 176 ਤਾਰਿਆਂ ਦੇ ਨਾਲ, ਇਸ ਵਿੱਚ ਗਿਥਬ ਉੱਤੇ 132 ਫੋਰਕ ਹਨ। ਲੇਖਕ ਨੇ ਖੁਦ 2015 ਤੋਂ ਇਸ ਲਈ ਵਚਨਬੱਧ ਨਹੀਂ ਕੀਤਾ ਹੈ (ਅਸੀਂ ਇਸਨੂੰ 2015 ਵਿੱਚ ਲਿਆ ਸੀ, ਫਿਰ ਇਸ ਨੇ ਸ਼ੱਕ ਪੈਦਾ ਨਹੀਂ ਕੀਤਾ), ਮੈਮੋਰੀ ਲੀਕ ਦੇ ਸੰਬੰਧ ਵਿੱਚ ਕਈ ਗਿਥਬ ਮੁੱਦੇ, 7 ਅਣਕੁੱਝੀਆਂ ਪੁੱਲ ਬੇਨਤੀਆਂ।
ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਪਲੱਗਇਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲੋਡ ਟੈਸਟਿੰਗ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਚਰਚਾਵਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ:

1. ਇੱਕ ਬਹੁ-ਥ੍ਰੈੱਡਡ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਇੱਕ ਨਿਯਮਤ ਲਿੰਕਡਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ, ਅਤੇ ਨਤੀਜਾ ਸੀ ਐਨ.ਪੀ.ਈ. ਰਨਟਾਈਮ ਵਿੱਚ. ਇਸ ਨੂੰ ਜਾਂ ਤਾਂ ConcurrentLinkedDeque ਵਿੱਚ ਬਦਲ ਕੇ ਜਾਂ ਸਮਕਾਲੀ ਬਲਾਕਾਂ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਅਸੀਂ ਆਪਣੇ ਲਈ ਪਹਿਲਾ ਵਿਕਲਪ ਚੁਣਿਆ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. ਮੈਮੋਰੀ ਲੀਕ; ਡਿਸਕਨੈਕਟ ਕਰਨ ਵੇਲੇ, ਕੁਨੈਕਸ਼ਨ ਜਾਣਕਾਰੀ ਨਹੀਂ ਮਿਟਾਈ ਜਾਂਦੀ ਹੈ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. ਸਟ੍ਰੀਮਿੰਗ ਮੋਡ ਵਿੱਚ (ਜਦੋਂ ਵੈਬਸਾਕੇਟ ਨਮੂਨੇ ਦੇ ਅੰਤ ਵਿੱਚ ਬੰਦ ਨਹੀਂ ਹੁੰਦਾ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਯੋਜਨਾ ਵਿੱਚ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ), ਜਵਾਬ ਪੈਟਰਨ ਕੰਮ ਨਹੀਂ ਕਰਦੇ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

ਇਹ ਗਿਥਬ 'ਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ। ਅਸੀਂ ਕੀ ਕੀਤਾ:

1. ਲੈ ਲਏ ਹਨ ਫੋਰਕ ਏਲੀਰਨ ਕੋਗਨ (@elyrank) - ਇਹ ਸਮੱਸਿਆਵਾਂ 1 ਅਤੇ 3 ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ
2. ਹੱਲ ਕੀਤੀ ਸਮੱਸਿਆ 2
3. ਜੈੱਟੀ ਨੂੰ 9.2.14 ਤੋਂ 9.3.12 ਤੱਕ ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ
4. ਥ੍ਰੈਡਲੋਕਲ ਵਿੱਚ ਲਪੇਟਿਆ SimpleDateFormat; SimpleDateFormat ਥ੍ਰੈਡ-ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਹੈ, ਜਿਸ ਕਾਰਨ ਰਨਟਾਈਮ 'ਤੇ NPE ਹੋ ਗਿਆ
5. ਇੱਕ ਹੋਰ ਮੈਮੋਰੀ ਲੀਕ ਨੂੰ ਠੀਕ ਕੀਤਾ (ਕੁਨੈਕਸ਼ਨ ਡਿਸਕਨੈਕਟ ਹੋਣ 'ਤੇ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਬੰਦ ਹੋ ਗਿਆ ਸੀ)

ਅਤੇ ਫਿਰ ਵੀ ਇਹ ਵਗਦਾ ਹੈ!

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

ਦੋ ਦਿਨ ਹੋ ਗਏ...

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

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਹੇਜ਼ਲਕਾਸਟ 3.4 ਵਿੱਚ, ਜਦੋਂ ਇੱਕ ਨਕਸ਼ਾ / ਮਲਟੀਮੈਪ (map.destroy()) ਨੂੰ ਮਿਟਾਉਂਦੇ ਹੋ, ਤਾਂ ਮੈਮੋਰੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੁਕਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

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

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

ਕਾਲ ਕਰੋ:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

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

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

ਚਾਰਟ ਵਿੱਚ ਸੁਧਾਰ ਹੋਇਆ ਹੈ।

ਅਸੀਂ ਲੋਡ ਟੈਸਟਿੰਗ ਬਾਰੇ ਹੋਰ ਕੀ ਸਿੱਖਿਆ ਹੈ?

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

ਹੇਜ਼ਲਕਾਸਟ ਦੇ ਨਾਲ ਸਾਡੇ ਤਜ਼ਰਬੇ ਬਾਰੇ

ਹੇਜ਼ਲਕਾਸਟ ਸਾਡੇ ਲਈ ਇੱਕ ਨਵਾਂ ਉਤਪਾਦ ਸੀ, ਅਸੀਂ ਇਸਦੇ ਨਾਲ ਵਰਜਨ 3.4.1 ਤੋਂ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਹੁਣ ਸਾਡਾ ਉਤਪਾਦਨ ਸਰਵਰ ਸੰਸਕਰਣ 3.9.2 ਚਲਾ ਰਿਹਾ ਹੈ (ਲਿਖਣ ਦੇ ਸਮੇਂ, ਹੇਜ਼ਲਕਾਸਟ ਦਾ ਨਵੀਨਤਮ ਸੰਸਕਰਣ 3.10 ਹੈ)।

ID ਬਣਾਉਣਾ

ਅਸੀਂ ਪੂਰਨ ਅੰਕ ਪਛਾਣਕਰਤਾਵਾਂ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕੀਤੀ। ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਸਾਨੂੰ ਇੱਕ ਨਵੀਂ ਹਸਤੀ ਲਈ ਇੱਕ ਹੋਰ ਲੌਂਗ ਦੀ ਲੋੜ ਹੈ। ਡੇਟਾਬੇਸ ਵਿੱਚ ਕ੍ਰਮ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ, ਟੇਬਲ ਸ਼ਾਰਡਿੰਗ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ - ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ DB1 ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ID=1 ਅਤੇ DB1 ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ID=2 ਹੈ, ਤੁਸੀਂ ਇਸ ID ਨੂੰ Elasticsearch ਵਿੱਚ ਨਹੀਂ ਪਾ ਸਕਦੇ ਹੋ, ਨਾ ਹੀ Hazelcast ਵਿੱਚ , ਪਰ ਸਭ ਤੋਂ ਬੁਰੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਤੁਸੀਂ ਦੋ ਡੇਟਾਬੇਸ ਤੋਂ ਡੇਟਾ ਨੂੰ ਇੱਕ ਵਿੱਚ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, ਇਹ ਫੈਸਲਾ ਕਰਨਾ ਕਿ ਇਹਨਾਂ ਗਾਹਕਾਂ ਲਈ ਇੱਕ ਡੇਟਾਬੇਸ ਕਾਫੀ ਹੈ)। ਤੁਸੀਂ ਹੇਜ਼ਲਕਾਸਟ ਵਿੱਚ ਕਈ ਐਟੋਮਿਕਲਾਂਗ ਜੋੜ ਸਕਦੇ ਹੋ ਅਤੇ ਕਾਊਂਟਰ ਨੂੰ ਉੱਥੇ ਰੱਖ ਸਕਦੇ ਹੋ, ਫਿਰ ਇੱਕ ਨਵੀਂ ਆਈਡੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਹੈਜ਼ਲਕਾਸਟ ਨੂੰ ਬੇਨਤੀ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ। ਪਰ ਹੇਜ਼ਲਕਾਸਟ ਵਿੱਚ ਕੁਝ ਹੋਰ ਅਨੁਕੂਲ ਹੈ - FlakeIdGenerator. ਹਰੇਕ ਕਲਾਇੰਟ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਵੇਲੇ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਆਈਡੀ ਰੇਂਜ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਪਹਿਲਾ - 1 ਤੋਂ 10 ਤੱਕ, ਦੂਜਾ - 000 ਤੋਂ 10 ਤੱਕ, ਅਤੇ ਹੋਰ ਵੀ। ਹੁਣ ਕਲਾਇੰਟ ਆਪਣੇ ਆਪ ਹੀ ਨਵੇਂ ਪਛਾਣਕਰਤਾ ਜਾਰੀ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਇਸ ਨੂੰ ਜਾਰੀ ਕੀਤੀ ਗਈ ਸੀਮਾ ਖਤਮ ਨਹੀਂ ਹੋ ਜਾਂਦੀ। ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ (ਅਤੇ ਹੇਜ਼ਲਕਾਸਟ ਕਲਾਇੰਟ) ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਨਵਾਂ ਕ੍ਰਮ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ - ਇਸ ਲਈ ਛੱਡਿਆ ਜਾਂਦਾ ਹੈ, ਆਦਿ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡਿਵੈਲਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਕਿ IDs ਪੂਰਨ ਅੰਕ ਕਿਉਂ ਹਨ, ਪਰ ਇੰਨੇ ਅਸੰਗਤ ਹਨ। ਅਸੀਂ ਸਭ ਕੁਝ ਤੋਲਿਆ ਅਤੇ UUIDs 'ਤੇ ਬਦਲਿਆ।

ਤਰੀਕੇ ਨਾਲ, ਉਹਨਾਂ ਲਈ ਜੋ ਟਵਿੱਟਰ ਦੀ ਤਰ੍ਹਾਂ ਬਣਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਇੱਥੇ ਇੱਕ ਅਜਿਹੀ ਸਨੋਕਾਸਟ ਲਾਇਬ੍ਰੇਰੀ ਹੈ - ਇਹ ਹੇਜ਼ਲਕਾਸਟ ਦੇ ਸਿਖਰ 'ਤੇ ਸਨੋਫਲੇਕ ਦਾ ਇੱਕ ਲਾਗੂਕਰਨ ਹੈ. ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਥੇ ਦੇਖ ਸਕਦੇ ਹੋ:

github.com/noctarius/snowcast
github.com/twitter/snowflake

ਪਰ ਅਸੀਂ ਹੁਣ ਇਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਨਹੀਂ ਗਏ ਹਾਂ.

TransactionalMap.replace

ਇੱਕ ਹੋਰ ਹੈਰਾਨੀ: TransactionalMap.replace ਕੰਮ ਨਹੀਂ ਕਰਦਾ। ਇੱਥੇ ਇੱਕ ਟੈਸਟ ਹੈ:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

ਮੈਨੂੰ getForUpdate ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੀ ਖੁਦ ਦੀ ਬਦਲੀ ਲਿਖਣੀ ਪਈ:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

ਨਾ ਸਿਰਫ਼ ਨਿਯਮਤ ਡਾਟਾ ਢਾਂਚੇ, ਸਗੋਂ ਉਹਨਾਂ ਦੇ ਲੈਣ-ਦੇਣ ਵਾਲੇ ਸੰਸਕਰਣਾਂ ਦੀ ਵੀ ਜਾਂਚ ਕਰੋ। ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ ਕਿ IMap ਕੰਮ ਕਰਦਾ ਹੈ, ਪਰ TransactionalMap ਹੁਣ ਮੌਜੂਦ ਨਹੀਂ ਹੈ।

ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਇੱਕ ਨਵਾਂ JAR ਪਾਓ

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

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

ਚੀਤਾਏਮ:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

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

map.addIndex("subscriberId", false);

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

IMap. ਅਸੀਂ 5000 ਵਸਤੂਆਂ ਲਿਖਦੇ ਹਾਂ, ਪੜ੍ਹਦੇ ਹਾਂ। ਹਰ ਚੀਜ਼ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

ਪਰ ਇਹ ਇੱਕ ਲੈਣ-ਦੇਣ ਵਿੱਚ ਕੰਮ ਨਹੀਂ ਕਰਦਾ, ਸਾਨੂੰ ਇੱਕ ClassNotFoundException ਮਿਲਦਾ ਹੈ:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

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

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

ਅਸੀਂ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹਾਂ

ਹੇਜ਼ਲਕਾਸਟ ਦੀਆਂ ਚਾਰ ਯਾਤਰਾਵਾਂ - ਚੰਗੀਆਂ, ਦੋ ਡਾਟਾਬੇਸ ਲਈ - ਮਾੜੀਆਂ

ਡੇਟਾ ਲਈ ਕੈਸ਼ ਵਿੱਚ ਜਾਣਾ ਡੇਟਾਬੇਸ ਵਿੱਚ ਜਾਣ ਨਾਲੋਂ ਹਮੇਸ਼ਾਂ ਬਿਹਤਰ ਹੁੰਦਾ ਹੈ, ਪਰ ਤੁਸੀਂ ਨਾ ਵਰਤੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਅਸੀਂ ਇਸ ਬਾਰੇ ਫੈਸਲਾ ਛੱਡ ਦਿੰਦੇ ਹਾਂ ਕਿ ਵਿਕਾਸ ਦੇ ਆਖਰੀ ਪੜਾਅ ਤੱਕ ਕੀ ਕੈਸ਼ ਕਰਨਾ ਹੈ। ਜਦੋਂ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਕੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ PostgreSQL (log_min_duration_statement ਤੋਂ 0) ਵਿੱਚ ਸਾਰੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਲੌਗਿੰਗ ਨੂੰ ਚਾਲੂ ਕਰਦੇ ਹਾਂ ਅਤੇ 20 ਮਿੰਟਾਂ ਲਈ ਲੋਡ ਟੈਸਟਿੰਗ ਚਲਾਉਂਦੇ ਹਾਂ। ਇਕੱਠੇ ਕੀਤੇ ਲੌਗਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ, pgFouine ਅਤੇ pgBadger ਵਰਗੀਆਂ ਉਪਯੋਗਤਾਵਾਂ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਰਿਪੋਰਟਾਂ ਬਣਾ ਸਕਦੀਆਂ ਹਨ। ਰਿਪੋਰਟਾਂ ਵਿੱਚ, ਅਸੀਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਹੌਲੀ ਅਤੇ ਲਗਾਤਾਰ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਭਾਲ ਕਰਦੇ ਹਾਂ। ਹੌਲੀ ਪੁੱਛਗਿੱਛਾਂ ਲਈ, ਅਸੀਂ ਇੱਕ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਪਲਾਨ ਬਣਾਉਂਦੇ ਹਾਂ (EXPLAIN) ਅਤੇ ਮੁਲਾਂਕਣ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਅਜਿਹੀ ਪੁੱਛਗਿੱਛ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇੱਕੋ ਇਨਪੁਟ ਡੇਟਾ ਲਈ ਵਾਰ-ਵਾਰ ਬੇਨਤੀਆਂ ਕੈਸ਼ ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੁੰਦੀਆਂ ਹਨ। ਅਸੀਂ ਸਵਾਲਾਂ ਨੂੰ "ਫਲੈਟ" ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਪ੍ਰਤੀ ਪੁੱਛਗਿੱਛ ਇੱਕ ਸਾਰਣੀ।

ਲੁੱਟ

SV ਨੂੰ ਇੱਕ ਔਨਲਾਈਨ ਸੇਵਾ ਵਜੋਂ 2017 ਦੀ ਬਸੰਤ ਵਿੱਚ ਚਾਲੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਇੱਕ ਵੱਖਰੇ ਉਤਪਾਦ ਵਜੋਂ, SV ਨੂੰ ਨਵੰਬਰ 2017 ਵਿੱਚ ਜਾਰੀ ਕੀਤਾ ਗਿਆ ਸੀ (ਉਸ ਸਮੇਂ ਬੀਟਾ ਸੰਸਕਰਣ ਸਥਿਤੀ ਵਿੱਚ)।

ਓਪਰੇਸ਼ਨ ਦੇ ਇੱਕ ਸਾਲ ਤੋਂ ਵੱਧ ਸਮੇਂ ਵਿੱਚ, ਸੀਬੀ ਔਨਲਾਈਨ ਸੇਵਾ ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ ਕੋਈ ਗੰਭੀਰ ਸਮੱਸਿਆ ਨਹੀਂ ਆਈ ਹੈ। ਅਸੀਂ ਦੁਆਰਾ ਔਨਲਾਈਨ ਸੇਵਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦੇ ਹਾਂ ਜ਼ੱਬਿਕਸ, ਤੋਂ ਇਕੱਤਰ ਕਰੋ ਅਤੇ ਤੈਨਾਤ ਕਰੋ Bamboo.

SV ਸਰਵਰ ਦੀ ਵੰਡ ਮੂਲ ਪੈਕੇਜਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਸਪਲਾਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: RPM, DEB, MSI। ਵਿੰਡੋਜ਼ ਲਈ ਪਲੱਸ ਅਸੀਂ ਇੱਕ ਸਿੰਗਲ EXE ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਸਿੰਗਲ ਇੰਸਟੌਲਰ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਾਂ ਜੋ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਸਰਵਰ, ਹੇਜ਼ਲਕਾਸਟ ਅਤੇ ਇਲਾਸਟਿਕ ਖੋਜ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਸ਼ੁਰੂ ਵਿੱਚ ਇੰਸਟਾਲੇਸ਼ਨ ਦੇ ਇਸ ਸੰਸਕਰਣ ਨੂੰ "ਡੈਮੋ" ਸੰਸਕਰਣ ਵਜੋਂ ਦਰਸਾਇਆ, ਪਰ ਹੁਣ ਇਹ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ ਕਿ ਇਹ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ ਤੈਨਾਤੀ ਵਿਕਲਪ ਹੈ।

ਸਰੋਤ: www.habr.com