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

ਤਕਨਾਲੋਜੀ ਦੀ ਚੋਣ

ਕੀ ਇਹ ਬੁਰਾ ਹੈ? ਵੱਖਰਾ Redis (ਸਟੈਂਡਅਲੋਨ ਰੀਡਿਸ) 1 ਮਾਸਟਰ ਅਤੇ ਐਨ ਸਲੇਵਜ਼ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ? ਮੈਂ ਇਸਨੂੰ ਪੁਰਾਣੀ ਤਕਨਾਲੋਜੀ ਕਿਉਂ ਆਖਾਂ?

ਨਹੀਂ, ਰੈਡਿਸ ਇੰਨਾ ਬੁਰਾ ਨਹੀਂ ਹੈ... ਹਾਲਾਂਕਿ, ਕੁਝ ਕਮੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਵਿਕਲਪ ਕੀ ਹਨ?

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

ਵਰਤੋਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਆਓ ਦੇਖੀਏ ਕਿ ਅਸੀਂ Redis ਨਾਲ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕੀਤਾ ਹੈ ਅਤੇ ਅਸੀਂ ਕਿਹੜੀ ਕਾਰਜਸ਼ੀਲਤਾ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ:

• ਰਿਮੋਟ ਸੇਵਾਵਾਂ ਜਿਵੇਂ ਕਿ 2GIS ਲਈ ਬੇਨਤੀਆਂ ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ | ਗੋਲੰਗ
  

  MGET MSET "ਚੁਣੋ DB" ਪ੍ਰਾਪਤ ਕਰੋ

• MYSQL ਤੋਂ ਪਹਿਲਾਂ ਕੈਸ਼ | PHP
  

  "ਪੈਟਰਨ ਦੁਆਰਾ ਕੁੰਜੀ" "DB ਚੁਣੋ" ਨੂੰ ਸੈੱਟ ਕਰੋ MGET MSET ਸਕੈਨ ਕਰੋ

• ਸੈਸ਼ਨਾਂ ਅਤੇ ਡਰਾਈਵਰ ਕੋਆਰਡੀਨੇਟਸ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀ ਸੇਵਾ ਲਈ ਮੁੱਖ ਸਟੋਰੇਜ | ਗੋਲੰਗ
  

  MGET MSET ਪ੍ਰਾਪਤ ਕਰੋ "DB ਚੁਣੋ" "ਜੀਓ ਕੁੰਜੀ ਸ਼ਾਮਲ ਕਰੋ" "ਜੀਓ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਕਰੋ" ਸਕੈਨ ਕਰੋ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਕੋਈ ਉੱਚ ਗਣਿਤ ਨਹੀਂ. ਫਿਰ ਮੁਸ਼ਕਲ ਕੀ ਹੈ? ਆਉ ਹਰ ਇੱਕ ਵਿਧੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਖੀਏ.

.ੰਗ
ਵੇਰਵਾ
ਰੈਡਿਸ-ਕਲੱਸਟਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ
ਫੈਸਲੇ ਦਾ

ਪ੍ਰਾਪਤ ਕਰੋ
ਕੁੰਜੀ ਲਿਖੋ/ਪੜ੍ਹੋ

MGET MSET
ਕਈ ਕੁੰਜੀਆਂ ਲਿਖੋ/ਪੜ੍ਹੋ
ਕੁੰਜੀਆਂ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਹੋਣਗੀਆਂ। ਤਿਆਰ ਲਾਇਬ੍ਰੇਰੀਆਂ ਸਿਰਫ ਇੱਕ ਨੋਡ ਦੇ ਅੰਦਰ ਮਲਟੀ-ਓਪਰੇਸ਼ਨ ਕਰ ਸਕਦੀਆਂ ਹਨ
MGET ਨੂੰ N GET ਕਾਰਜਾਂ ਦੀ ਪਾਈਪਲਾਈਨ ਨਾਲ ਬਦਲੋ

DB ਚੁਣੋ
ਉਹ ਅਧਾਰ ਚੁਣੋ ਜਿਸ ਨਾਲ ਅਸੀਂ ਕੰਮ ਕਰਾਂਗੇ
ਮਲਟੀਪਲ ਡਾਟਾਬੇਸ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਦਾ
ਸਭ ਕੁਝ ਇੱਕ ਡਾਟਾਬੇਸ ਵਿੱਚ ਰੱਖੋ. ਕੁੰਜੀਆਂ ਵਿੱਚ ਅਗੇਤਰ ਜੋੜੋ

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

GEO
ਜੀਓਕੀ ਨਾਲ ਓਪਰੇਸ਼ਨ
geokey ਨੂੰ ਕੱਟਿਆ ਨਹੀ ਹੈ

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

Redis ਬਨਾਮ Redis-ਕਲੱਸਟਰ

ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਬਦਲਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਕੀ ਗੁਆਉਂਦੇ ਹਾਂ ਅਤੇ ਕੀ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ?

• ਨੁਕਸਾਨ: ਅਸੀਂ ਕਈ ਡੇਟਾਬੇਸ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਗੁਆ ਦਿੰਦੇ ਹਾਂ।
  • ਜੇਕਰ ਅਸੀਂ ਤਰਕ ਨਾਲ ਗੈਰ-ਸੰਬੰਧਿਤ ਡੇਟਾ ਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਅਗੇਤਰ ਦੇ ਰੂਪ ਵਿੱਚ ਬੈਸਾਖੀਆਂ ਬਣਾਉਣੀਆਂ ਪੈਣਗੀਆਂ।
  • ਅਸੀਂ ਸਾਰੇ "ਬੇਸ" ਓਪਰੇਸ਼ਨ ਗੁਆ ​​ਦਿੰਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ SCAN, DBSIZE, CLEAR DB, ਆਦਿ।
  • ਮਲਟੀ-ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੋ ਗਿਆ ਹੈ ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਕਈ ਨੋਡਾਂ ਤੱਕ ਪਹੁੰਚ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।
• ਪਲੱਸ:
  • ਮਾਸਟਰ ਫੇਲਓਵਰ ਦੇ ਰੂਪ ਵਿੱਚ ਨੁਕਸ ਸਹਿਣਸ਼ੀਲਤਾ.
  • Redis ਪਾਸੇ 'ਤੇ ਸ਼ੇਅਰਿੰਗ.
  • ਪਰਮਾਣੂ ਅਤੇ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਨੋਡਾਂ ਵਿਚਕਾਰ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ।
  • ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਦੇ ਸਮਰੱਥਾ ਅਤੇ ਲੋਡ ਜੋੜੋ ਅਤੇ ਮੁੜ-ਵੰਡੋ।

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

ਜਾਣ ਦੀ ਤਿਆਰੀ ਕਰ ਰਿਹਾ ਹੈ

ਆਉ ਮੂਵ ਕਰਨ ਲਈ ਲੋੜਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ:

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

ਕਲੱਸਟਰ ਦੀ ਸੰਭਾਲ

ਕਦਮ ਚੁੱਕਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੀ ਅਸੀਂ ਕਲੱਸਟਰ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਾਂ:

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

ਮੂਵਿੰਗ

ਅਸੀਂ ਕਿਵੇਂ ਅੱਗੇ ਵਧਾਂਗੇ:

• ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ ਦੇ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਗੋ-ਰੇਡਿਸ ਨੂੰ ਗੋ ਸੰਸਕਰਣ ਦੇ ਅਧਾਰ ਵਜੋਂ ਲਿਆ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਥੋੜਾ ਜਿਹਾ ਬਦਲਿਆ। ਅਸੀਂ ਪਾਈਪਲਾਈਨਾਂ ਰਾਹੀਂ ਮਲਟੀ-ਤਰੀਕਿਆਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਦੁਹਰਾਉਣ ਲਈ ਨਿਯਮਾਂ ਨੂੰ ਵੀ ਥੋੜ੍ਹਾ ਠੀਕ ਕੀਤਾ ਹੈ। PHP ਸੰਸਕਰਣ ਵਿੱਚ ਹੋਰ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਪਰ ਅਸੀਂ ਆਖਰਕਾਰ php-redis 'ਤੇ ਸੈਟਲ ਹੋ ਗਏ। ਉਹਨਾਂ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਕਲੱਸਟਰ ਸਹਾਇਤਾ ਪੇਸ਼ ਕੀਤੀ ਹੈ ਅਤੇ ਇਹ ਸਾਡੀ ਰਾਏ ਵਿੱਚ ਵਧੀਆ ਲੱਗ ਰਿਹਾ ਹੈ.
• ਅੱਗੇ ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ. ਇਹ ਸੰਰਚਨਾ ਫਾਈਲ ਦੇ ਅਧਾਰ ਤੇ ਦੋ ਕਮਾਂਡਾਂ ਵਿੱਚ ਸ਼ਾਬਦਿਕ ਤੌਰ ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਅਸੀਂ ਹੇਠਾਂ ਵਧੇਰੇ ਵਿਸਥਾਰ ਵਿੱਚ ਸੈਟਿੰਗ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ।
• ਹੌਲੀ-ਹੌਲੀ ਅੱਗੇ ਵਧਣ ਲਈ ਅਸੀਂ ਡਰਾਈ-ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਕਿਉਂਕਿ ਸਾਡੇ ਕੋਲ ਇੱਕੋ ਇੰਟਰਫੇਸ ਵਾਲੀ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਦੋ ਸੰਸਕਰਣ ਹਨ (ਇੱਕ ਨਿਯਮਤ ਸੰਸਕਰਣ ਲਈ, ਦੂਜਾ ਕਲੱਸਟਰ ਲਈ), ਇੱਕ ਰੈਪਰ ਬਣਾਉਣ ਲਈ ਇਸਦੀ ਕੋਈ ਕੀਮਤ ਨਹੀਂ ਹੈ ਜੋ ਇੱਕ ਵੱਖਰੇ ਸੰਸਕਰਣ ਨਾਲ ਕੰਮ ਕਰੇਗਾ ਅਤੇ ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਕਲੱਸਟਰ ਦੀਆਂ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਡੁਪਲੀਕੇਟ ਕਰੇਗਾ, ਜਵਾਬਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ ਅਤੇ ਲੌਗਸ ਵਿੱਚ ਅੰਤਰ ਲਿਖੋ (ਨਿਊਰੇਲਿਕ ਵਿੱਚ ਸਾਡੇ ਕੇਸ ਵਿੱਚ)। ਇਸ ਤਰ੍ਹਾਂ, ਭਾਵੇਂ ਰੋਲਆਊਟ ਦੌਰਾਨ ਕਲੱਸਟਰ ਸੰਸਕਰਣ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਸਾਡਾ ਉਤਪਾਦਨ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੋਵੇਗਾ।
• ਡ੍ਰਾਈ ਮੋਡ ਵਿੱਚ ਕਲੱਸਟਰ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਸ਼ਾਂਤ ਰੂਪ ਵਿੱਚ ਪ੍ਰਤੀਕ੍ਰਿਆ ਅੰਤਰਾਂ ਦੇ ਗ੍ਰਾਫ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ। ਜੇਕਰ ਗਲਤੀ ਦਰ ਹੌਲੀ-ਹੌਲੀ ਪਰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੁਝ ਛੋਟੇ ਸਥਿਰਾਂਕ ਵੱਲ ਵਧਦੀ ਹੈ, ਤਾਂ ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਅਜੇ ਵੀ ਮਤਭੇਦ ਕਿਉਂ ਹਨ? ਕਿਉਂਕਿ ਇੱਕ ਵੱਖਰੇ ਸੰਸਕਰਣ ਵਿੱਚ ਰਿਕਾਰਡਿੰਗ ਕਲੱਸਟਰ ਦੇ ਮੁਕਾਬਲੇ ਥੋੜੀ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਮਾਈਕ੍ਰੋਲਾਗ ਦੇ ਕਾਰਨ, ਡੇਟਾ ਵੱਖ ਹੋ ਸਕਦਾ ਹੈ। ਜੋ ਕੁਝ ਬਚਿਆ ਹੈ ਉਹ ਹੈ ਵਿਸੰਗਤੀ ਲੌਗਸ ਨੂੰ ਵੇਖਣਾ, ਅਤੇ ਜੇਕਰ ਉਹ ਸਾਰੇ ਰਿਕਾਰਡ ਦੀ ਗੈਰ-ਪਰਮਾਣੂਤਾ ਦੁਆਰਾ ਸਮਝਾਏ ਗਏ ਹਨ, ਤਾਂ ਅਸੀਂ ਅੱਗੇ ਵਧ ਸਕਦੇ ਹਾਂ।
• ਹੁਣ ਤੁਸੀਂ ਡ੍ਰਾਈ-ਮੋਡ ਨੂੰ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹੋ। ਅਸੀਂ ਕਲੱਸਟਰ ਤੋਂ ਲਿਖਾਂਗੇ ਅਤੇ ਪੜ੍ਹਾਂਗੇ, ਅਤੇ ਇਸਨੂੰ ਇੱਕ ਵੱਖਰੇ ਸੰਸਕਰਣ ਵਿੱਚ ਡੁਪਲੀਕੇਟ ਕਰਾਂਗੇ। ਕਾਹਦੇ ਲਈ? ਅਗਲੇ ਹਫ਼ਤੇ ਮੈਂ ਕਲੱਸਟਰ ਦੇ ਕੰਮ ਦਾ ਨਿਰੀਖਣ ਕਰਨਾ ਚਾਹਾਂਗਾ। ਜੇਕਰ ਇਹ ਅਚਾਨਕ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਪੀਕ ਲੋਡ 'ਤੇ ਸਮੱਸਿਆਵਾਂ ਹਨ, ਜਾਂ ਅਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ, ਤਾਂ ਸਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਪੁਰਾਣੇ ਕੋਡ ਅਤੇ ਮੌਜੂਦਾ ਡੇਟਾ ਲਈ ਡ੍ਰਾਈ-ਮੋਡ ਲਈ ਇੱਕ ਐਮਰਜੈਂਸੀ ਰੋਲਬੈਕ ਹੁੰਦਾ ਹੈ।
• ਜੋ ਕੁਝ ਬਚਿਆ ਹੈ ਉਹ ਡ੍ਰਾਈ-ਮੋਡ ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣਾ ਅਤੇ ਵੱਖਰੇ ਸੰਸਕਰਣ ਨੂੰ ਖਤਮ ਕਰਨਾ ਹੈ।

ਮਹਾਰਤ

ਪਹਿਲਾਂ, ਕਲੱਸਟਰ ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ।

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

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

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

ਹੁਣ ਆਪ੍ਰੇਸ਼ਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਜੋ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਬਿਹਤਰ ਹੋਵੇਗਾ.

ਅਸੀਂ Redis-CLI ਰਾਹੀਂ ਸਿਸਟਮ ਤੱਕ ਪਹੁੰਚ ਕਰਾਂਗੇ। ਕਿਉਂਕਿ Redis ਕੋਲ ਇੱਕ ਵੀ ਐਂਟਰੀ ਪੁਆਇੰਟ ਨਹੀਂ ਹੈ, ਤੁਸੀਂ ਕਿਸੇ ਵੀ ਨੋਡ 'ਤੇ ਹੇਠਾਂ ਦਿੱਤੇ ਓਪਰੇਸ਼ਨ ਕਰ ਸਕਦੇ ਹੋ। ਹਰੇਕ ਬਿੰਦੂ 'ਤੇ ਮੈਂ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲੋਡ ਦੇ ਅਧੀਨ ਓਪਰੇਸ਼ਨ ਕਰਨ ਦੀ ਸੰਭਾਵਨਾ ਵੱਲ ਧਿਆਨ ਖਿੱਚਦਾ ਹਾਂ.

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

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

ਕੌਨਫਿਗਰੇਸ਼ਨ

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

• ਟਾਈਮਆ 0ਟ XNUMX
  ਸਮਾਂ ਜਿਸ ਤੋਂ ਬਾਅਦ ਅਕਿਰਿਆਸ਼ੀਲ ਕਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਜਾਂਦੇ ਹਨ (ਸਕਿੰਟਾਂ ਵਿੱਚ)। 0 - ਬੰਦ ਨਾ ਕਰੋ
  ਸਾਡੀ ਹਰ ਲਾਇਬ੍ਰੇਰੀ ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਬੰਦ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ। ਇਸ ਸੈਟਿੰਗ ਨੂੰ ਅਸਮਰੱਥ ਕਰਨ ਨਾਲ, ਅਸੀਂ ਗਾਹਕਾਂ ਦੀ ਗਿਣਤੀ 'ਤੇ ਸੀਮਾ ਨੂੰ ਮਾਰਨ ਦਾ ਜੋਖਮ ਲੈਂਦੇ ਹਾਂ। ਦੂਜੇ ਪਾਸੇ, ਜੇਕਰ ਅਜਿਹੀ ਕੋਈ ਸਮੱਸਿਆ ਹੈ, ਤਾਂ ਗੁੰਮ ਹੋਏ ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਆਟੋਮੈਟਿਕ ਸਮਾਪਤੀ ਇਸ ਨੂੰ ਮਾਸਕ ਕਰ ਦੇਵੇਗੀ, ਅਤੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਅਸੀਂ ਧਿਆਨ ਨਾ ਦੇਈਏ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਹਾਨੂੰ ਸਥਿਰ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਇਸ ਸੈਟਿੰਗ ਨੂੰ ਸਮਰੱਥ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
• xy ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਹਾਂ ਜੋੜੋ
  ਇੱਕ RDB ਸਨੈਪਸ਼ਾਟ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।
  ਅਸੀਂ ਹੇਠਾਂ ਵਿਸਥਾਰ ਵਿੱਚ RDB/AOF ਮੁੱਦਿਆਂ 'ਤੇ ਚਰਚਾ ਕਰਾਂਗੇ।
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  ਜੇਕਰ ਯੋਗ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੇਕਰ RDB ਸਨੈਪਸ਼ਾਟ ਟੁੱਟ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਮਾਸਟਰ ਤਬਦੀਲੀ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ। ਜੇਕਰ ਮਾਲਕ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਨੌਕਰ ਬੇਨਤੀਆਂ (ਹਾਂ) ਦਾ ਜਵਾਬ ਦੇਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਜਾਂ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦੇਵੇਗਾ (ਨਹੀਂ)
  ਅਸੀਂ ਉਸ ਸਥਿਤੀ ਤੋਂ ਖੁਸ਼ ਨਹੀਂ ਹਾਂ ਜਿਸ ਵਿੱਚ ਰੇਡਿਸ ਇੱਕ ਪੇਠਾ ਵਿੱਚ ਬਦਲ ਜਾਂਦਾ ਹੈ.
• repl-ping-slave-period 5
  ਇਸ ਸਮੇਂ ਦੇ ਬਾਅਦ, ਅਸੀਂ ਚਿੰਤਾ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਵਾਂਗੇ ਕਿ ਮਾਸਟਰ ਟੁੱਟ ਗਿਆ ਹੈ ਅਤੇ ਇਹ ਫੇਲਓਵਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦਾ ਸਮਾਂ ਹੈ.
  ਤੁਹਾਨੂੰ ਗਲਤ ਸਕਾਰਾਤਮਕ ਅਤੇ ਫੇਲਓਵਰ ਨੂੰ ਟਰਿੱਗਰ ਕਰਨ ਵਿਚਕਾਰ ਹੱਥੀਂ ਸੰਤੁਲਨ ਲੱਭਣਾ ਹੋਵੇਗਾ। ਸਾਡੇ ਅਭਿਆਸ ਵਿੱਚ ਇਹ 5 ਸਕਿੰਟ ਹੈ।
• repl-backlog-size 1024mb ਅਤੇ epl-backlog-ttl 0
  ਅਸੀਂ ਇੱਕ ਅਸਫਲ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਲਈ ਇੱਕ ਬਫਰ ਵਿੱਚ ਬਿਲਕੁਲ ਇੰਨਾ ਡੇਟਾ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹਾਂ। ਜੇਕਰ ਬਫਰ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਕਾਲੀ ਕਰਨਾ ਹੋਵੇਗਾ।
  ਅਭਿਆਸ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ ਕਿ ਉੱਚ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰਨਾ ਬਿਹਤਰ ਹੈ. ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਕਾਰਨ ਹਨ ਕਿ ਇੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਪਛੜਨਾ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਇਹ ਪਛੜ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਮਾਸਟਰ ਪਹਿਲਾਂ ਹੀ ਇਸ ਨਾਲ ਸਿੱਝਣ ਲਈ ਸੰਘਰਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਪੂਰਾ ਸਮਕਾਲੀਕਰਨ ਆਖਰੀ ਤੂੜੀ ਹੋਵੇਗੀ.
• maxclients 10000
  ਇੱਕ ਵਾਰ ਦੇ ਗਾਹਕਾਂ ਦੀ ਅਧਿਕਤਮ ਸੰਖਿਆ।
  ਸਾਡੇ ਤਜ਼ਰਬੇ ਵਿੱਚ, ਉੱਚ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰਨਾ ਬਿਹਤਰ ਹੈ. Redis 10k ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਠੀਕ ਤਰ੍ਹਾਂ ਸੰਭਾਲਦਾ ਹੈ। ਬਸ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਸਿਸਟਮ 'ਤੇ ਕਾਫ਼ੀ ਸਾਕਟ ਹਨ.
• maxmemory-policy volatile-ttl
  ਉਹ ਨਿਯਮ ਜਿਸ ਦੁਆਰਾ ਕੁੰਜੀਆਂ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਉਪਲਬਧ ਮੈਮੋਰੀ ਸੀਮਾ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ।
  ਇੱਥੇ ਕੀ ਮਹੱਤਵਪੂਰਨ ਹੈ ਇਹ ਨਿਯਮ ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਸਮਝਣਾ ਕਿ ਇਹ ਕਿਵੇਂ ਹੋਵੇਗਾ. ਜਦੋਂ ਮੈਮੋਰੀ ਸੀਮਾ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ ਤਾਂ ਰੈਡਿਸ ਦੀ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਲਈ ਪ੍ਰਸ਼ੰਸਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

RDB ਅਤੇ AOF ਸਮੱਸਿਆਵਾਂ

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

• RDB-ਸਨੈਪਸ਼ਾਟ - ਸਾਰੇ ਡੇਟਾ ਦਾ ਇੱਕ ਪੂਰਾ ਸਨੈਪਸ਼ਾਟ। ਸੇਵ XY ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈੱਟ ਕਰੋ ਅਤੇ "ਜੇ ਘੱਟੋ-ਘੱਟ Y ਕੁੰਜੀਆਂ ਬਦਲ ਗਈਆਂ ਹਨ ਤਾਂ ਹਰ X ਸਕਿੰਟ ਵਿੱਚ ਸਾਰੇ ਡੇਟਾ ਦਾ ਇੱਕ ਪੂਰਾ ਸਨੈਪਸ਼ਾਟ ਸੁਰੱਖਿਅਤ ਕਰੋ।"
• ਸਿਰਫ਼ ਜੋੜਨ ਵਾਲੀ ਫਾਈਲ - ਓਪਰੇਸ਼ਨਾਂ ਦੀ ਸੂਚੀ ਜਿਸ ਕ੍ਰਮ ਵਿੱਚ ਉਹ ਕੀਤੇ ਜਾਂਦੇ ਹਨ। ਫਾਈਲ ਵਿੱਚ ਹਰ X ਸਕਿੰਟ ਜਾਂ ਹਰ Y ਓਪਰੇਸ਼ਨਾਂ ਵਿੱਚ ਨਵੇਂ ਆਉਣ ਵਾਲੇ ਓਪਰੇਸ਼ਨ ਜੋੜਦਾ ਹੈ।
• RDB ਅਤੇ AOF ਪਿਛਲੇ ਦੋ ਦਾ ਸੁਮੇਲ ਹਨ।

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

ਪਹਿਲਾਂ, ਇੱਕ RDB ਸਨੈਪਸ਼ਾਟ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ FORK ਨੂੰ ਕਾਲ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਬਹੁਤ ਸਾਰਾ ਡਾਟਾ ਹੈ, ਤਾਂ ਇਹ ਕੁਝ ਮਿਲੀਸਕਿੰਟ ਤੋਂ ਇੱਕ ਸਕਿੰਟ ਦੀ ਮਿਆਦ ਲਈ ਸਾਰੇ Redis ਨੂੰ ਲਟਕ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਿਸਟਮ ਨੂੰ ਅਜਿਹੇ ਸਨੈਪਸ਼ਾਟ ਲਈ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਲਾਜ਼ੀਕਲ ਮਸ਼ੀਨ 'ਤੇ ਰੈਮ ਦੀ ਡਬਲ ਸਪਲਾਈ ਰੱਖਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਜੇਕਰ ਰੈਡਿਸ ਲਈ 8 ਜੀਬੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਤਾਂ 16 ਜੀਬੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ 'ਤੇ ਉਪਲਬਧ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਹ.

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

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

ਸਿੱਟਾ

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

ਸਰੋਤ: www.habr.com