ਲਾਭ:
- ਸਪੀਡ ਸੀਮਾਵਾਂ (RPM/ITPM/OTPM) ਅਤੇ 429 ਗਲਤੀਆਂ ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹੈ
- ਘਾਤਕ ਬੈਕਆਫ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਨਾਲ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ
- ਆਮ HTTP ਗਲਤੀ ਕੋਡਾਂ (400/401/429/500/529) ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਵਰਗੀਕ੍ਰਿਤ ਅਤੇ ਹੈਂਡਲ ਕਰਦਾ ਹੈ
ਇੱਕ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਕੋਈ ਵੀ API ਹਰ ਸਮੇਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਕਈ ਵਾਰ ਤੁਸੀਂ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਬੇਨਤੀਆਂ ਭੇਜਦੇ ਹੋ ਅਤੇ ਸੀਮਾ ਨੂੰ ਮਾਰਦੇ ਹੋ; ਕਈ ਵਾਰ ਸਰਵਰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਵਿਅਸਤ ਹੁੰਦਾ ਹੈ; ਕਈ ਵਾਰ ਤੁਹਾਡੀ ਬੇਨਤੀ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਗਲਤ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਸ਼ੁਕੀਨ ਕੋਸ਼ਿਸ਼ ਤੋਂ ਇੱਕ ਠੋਸ ਏਕੀਕਰਣ ਨੂੰ ਜੋ ਵੱਖਰਾ ਕਰਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਇਹ ਇਹਨਾਂ ਸਥਿਤੀਆਂ ਨੂੰ ਭਵਿੱਖਬਾਣੀ ਅਤੇ ਆਪਣੇ ਆਪ ਹੀ ਸੰਭਾਲਦਾ ਹੈ। ਇਸ ਯੂਨਿਟ ਵਿੱਚ ਤੁਸੀਂ ਰੇਟ ਸੀਮਾਵਾਂ (RPM/ITPM/OTPM), 429 ਗਲਤੀ, ਘਾਤਕ ਬੈਕਆਫ ਦੇ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਅਤੇ ਆਮ HTTP ਗਲਤੀ ਕੋਡਾਂ ਦੇ ਸਹੀ ਵਰਗੀਕਰਨ ਬਾਰੇ ਸਿੱਖੋਗੇ। ਟੀਚਾ: ਇੱਕ ਅਜਿਹਾ ਪ੍ਰਵਾਹ ਬਣਾਉਣਾ ਜੋ ਇੰਨਾ ਮਜਬੂਤ ਹੋਵੇ ਕਿ ਇੱਕ ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਕਦੇ ਵੀ ਨੋਟਿਸ ਨਹੀਂ ਕਰੇਗਾ।
ਸਪੀਡ ਸੀਮਾਵਾਂ ਕੀ ਹਨ?
ਪ੍ਰਦਾਤਾ ਇਹ ਸੀਮਤ ਕਰਦਾ ਹੈ ਕਿ ਇੱਕ ਦਿੱਤੇ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਸਵਿੱਚ ਕਿੰਨਾ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ; ਇਹ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਤੁਹਾਨੂੰ ਅਚਾਨਕ ਹੋਣ ਵਾਲੇ ਧਮਾਕਿਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ। ਸੀਮਾਵਾਂ ਦੀਆਂ ਤਿੰਨ ਆਮ ਕਿਸਮਾਂ ਹਨ:
- RPM (ਪ੍ਰਤੀ ਮਿੰਟ ਬੇਨਤੀਆਂ): ਪ੍ਰਤੀ ਮਿੰਟ ਬੇਨਤੀਆਂ ਦੀ ਸੰਖਿਆ।
- ITPM (ਇਨਪੁਟ ਟੋਕਨ ਪ੍ਰਤੀ ਮਿੰਟ): ਇਨਪੁਟ ਟੋਕਨ ਜਿਸ 'ਤੇ ਪ੍ਰਤੀ ਮਿੰਟ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।
- OTPM (ਆਉਟਪੁੱਟ ਟੋਕਨ ਪ੍ਰਤੀ ਮਿੰਟ): ਆਉਟਪੁੱਟ ਟੋਕਨ ਜੋ ਪ੍ਰਤੀ ਮਿੰਟ ਪੈਦਾ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਵੀ ਸੀਮਾ ਨੂੰ ਪਾਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਦਾਤਾ ਬੇਨਤੀ ਨੂੰ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ 429 ਗਲਤੀ ਕੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਸੀਮਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਡੇ ਖਾਤੇ ਦੇ ਪੱਧਰ (ਟੀਅਰ) ਦੇ ਆਧਾਰ 'ਤੇ ਵੱਖ-ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਵਧੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।
ਸੁਝਾਅ: ਤੁਸੀਂ ਜਵਾਬ ਦੇ ਸਿਰਲੇਖਾਂ ਤੋਂ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ 'ਤੇ ਦੇਖ ਸਕਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਪ੍ਰਦਾਤਾ x-ratelimit-remaining-* ਵਰਗੇ ਸਿਰਲੇਖਾਂ ਨਾਲ ਤੁਹਾਡੇ ਬਾਕੀ ਬਚੇ ਕੋਟੇ ਦੀ ਰਿਪੋਰਟ ਕਰਦੇ ਹਨ। ਇਹਨਾਂ ਮੁੱਲਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨਾ ਅਤੇ ਸਾਹਮਣੇ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਥਰੋਟਲ ਕਰਨਾ 429 ਪ੍ਰਾਪਤ ਕੀਤੇ ਬਿਨਾਂ ਸਮੱਸਿਆ ਨੂੰ ਰੋਕਣ ਦਾ ਸਭ ਤੋਂ ਪਰਿਪੱਕ ਤਰੀਕਾ ਹੈ।
429 ਅਤੇ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਰੀਟਰੇਸਮੈਂਟ
429 (ਦਰ ਦੀ ਸੀਮਾ) ਇੱਕ ਅਸਥਾਈ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ ਗਲਤੀ ਹੈ। ਸਹੀ ਜਵਾਬ ਕੁਝ ਦੇਰ ਲਈ ਬੇਨਤੀ ਦੀ ਉਡੀਕ ਕਰਨਾ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ। ਪਰ ਇੱਕ ਲਗਾਤਾਰ ਉਡੀਕ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ; ਜੇਕਰ ਹਰ ਕੋਈ ਇੱਕੋ ਸਮੇਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਤਾਂ ਸੀਮਾ ਦੁਬਾਰਾ ਪਹੁੰਚ ਜਾਵੇਗੀ। ਹੱਲ ਘਾਤਕ ਬੈਕਆਫ ਹੈ: ਹਰੇਕ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਦੇ ਨਾਲ ਉਡੀਕ ਸਮੇਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਵਧਾਉਣਾ।
# ਘਾਤਕ ਬੈਕਆਫ ਤਰਕ ਅਜ਼ਮਾਇਸ਼ 1 → 429 → ਉਡੀਕ ਕਰੋ 1 ਸਕਿੰਟ ਅਜ਼ਮਾਇਸ਼ 2 → 429 → ਉਡੀਕ ਕਰੋ 2 ਸਕਿੰਟ ਅਜ਼ਮਾਇਸ਼ 3 → 429 → ਉਡੀਕ ਕਰੋ 4 ਸਕਿੰਟ ਅਜ਼ਮਾਇਸ਼ 4 → 429 → ਉਡੀਕ ਕਰੋ 8 ਸਕਿੰਟ (+ ਛੋਟਾ ਬੇਤਰਤੀਬ "ਜਿੱਟਰ")... ਛੱਡੋ ਅਤੇ ਜ਼ਿਆਦਾਤਰ N ਟ੍ਰਾਇਲ ਤੋਂ ਬਾਅਦ ਰਿਪੋਰਟ ਕਰੋ
ਇਸ ਵਿੱਚ ਥੋੜੀ ਜਿਹੀ ਬੇਤਰਤੀਬੀ (ਜਿੱਟਰ) ਜੋੜਨਾ ਉਸੇ ਸਮੇਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵੇਲੇ ਬੇਨਤੀਆਂ ਨੂੰ ਟਕਰਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, 429 ਜਵਾਬ ਅਕਸਰ 'ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ' ਸਿਰਲੇਖ ਰੱਖਦਾ ਹੈ: "ਇਸ ਕਈ ਸਕਿੰਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ"। ਇਸ ਖਿਤਾਬ ਦਾ ਸਤਿਕਾਰ ਕਰਨਾ ਅੰਨ੍ਹੇਵਾਹ ਉਡੀਕ ਕਰਨ ਨਾਲੋਂ ਵਧੇਰੇ ਸਹੀ ਹੈ।
ਸਾਵਧਾਨ: ਜਦੋਂ ਤੁਸੀਂ 429 ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ, ਤਾਂ "ਹੋਰ ਬੇਨਤੀਆਂ ਭੇਜ ਕੇ ਇਸ ਨੂੰ ਮਜਬੂਰ ਕਰਨਾ" ਸਥਿਤੀ ਨੂੰ ਹੋਰ ਵਿਗੜ ਜਾਵੇਗਾ; ਸੀਮਾ ਨੂੰ ਭਰਿਆ ਜਾਣਾ ਜਾਰੀ ਹੈ ਅਤੇ ਕੋਈ ਬੇਨਤੀ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ। ਸਹੀ ਜਵਾਬ ਪਿੱਛੇ ਹਟਣਾ ਹੈ, ਪ੍ਰਵੇਗ ਨਹੀਂ। ਚੰਗੀ ਖ਼ਬਰ: ਬਹੁਤੇ ਅਧਿਕਾਰਤ SDK 429 ਅਤੇ ਸਰਵਰ ਦੀਆਂ ਤਰੁੱਟੀਆਂ ਨੂੰ ਬੈਕਆਫ ਨਾਲ ਮੁੜ-ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ — ਇਸਨੂੰ ਹੱਥੀਂ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ SDK ਦੇ ਇਸ ਵਿਵਹਾਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।
HTTP ਗਲਤੀ ਕੋਡ ਦਾ ਵਰਗੀਕਰਨ
ਹਰ ਗਲਤੀ ਇੱਕੋ ਜਿਹੀ ਨਹੀਂ ਹੁੰਦੀ। ਨਾਜ਼ੁਕ ਅੰਤਰ: ਕੀ ਇਸਦੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਜਾਂ ਕੀ ਇਹ ਇੱਕ ਬੇਨਤੀ/ਪਛਾਣ ਦਾ ਮੁੱਦਾ ਹੈ?
ਕੋਡ
ਭਾਵ
ਕੀ ਇਹ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ?
ਸਹੀ ਜਵਾਬ
400
ਅਵੈਧ ਬੇਨਤੀ (ਫਾਰਮੈਟ/ਪੈਰਾਮੀਟਰ ਗਲਤੀ)
ਨਹੀਂ
ਬੇਨਤੀ ਨੂੰ ਠੀਕ ਕਰੋ; ਉਸੇ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਭੇਜੋ
401
ਪ੍ਰਮਾਣਿਕਤਾ ਗਲਤੀ (ਕੁੰਜੀ ਅਵੈਧ/ਗੁੰਮ)
ਨਹੀਂ
ਕੁੰਜੀ/ਸਿਰਲੇਖ ਨੂੰ ਠੀਕ ਕਰੋ
403
ਕੋਈ ਅਧਿਕਾਰ ਨਹੀਂ (ਮਾਡਲ/ਵਿਸ਼ੇਸ਼ਤਾ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਨਹੀਂ)
ਨਹੀਂ
ਅਨੁਮਤੀਆਂ/ਸਕੋਪ ਦੀ ਜਾਂਚ ਕਰੋ
404
ਨਹੀਂ ਮਿਲਿਆ (ਗਲਤ ਮਾਡਲ ID/ਅੰਤ ਬਿੰਦੂ)
ਨਹੀਂ
ਸਹੀ ਮਾਡਲ ID/ਪਤਾ
429
ਗਤੀ ਸੀਮਾ ਵੱਧ ਗਈ
ਹਾਂ
ਰੀਟਰੀਟ + ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼-ਬਾਅਦ
500
ਸਰਵਰ ਗੜਬੜ
ਹਾਂ
ਰੀਟਰੀਟ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ
529
ਸਰਵਰ ਓਵਰਲੋਡ ਹੋਇਆ
ਹਾਂ
ਰੀਟਰੀਟ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ
ਸੁਨਹਿਰੀ ਨਿਯਮ: 429, 500 ਅਤੇ 529 ਅਸਥਾਈ ਹਨ; ਇਸ ਨੂੰ ਵਾਪਸ ਲੈਣ ਨਾਲ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। 400, 401, 403, 404 ਬੇਨਤੀ/ਪਛਾਣ ਦੇ ਮੁੱਦੇ ਹਨ; ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਇਸਦਾ ਹੱਲ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਇਹ ਕੋਸ਼ਿਸ਼ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਇਹਨਾਂ ਦੋ ਸਮੂਹਾਂ ਵਿੱਚ ਫਰਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਕਦਮ ਦਰ ਕਦਮ: ਟਿਕਾਊ ਕਾਲ
- ਬੇਨਤੀ ਦਰਜ ਕਰੋ। ਜੇ ਸਫਲ ਹੋ, ਤਾਂ ਜਾਰੀ ਰੱਖੋ।
- ਗਲਤੀ ਕੋਡ ਦਾ ਵਰਗੀਕਰਨ ਕਰੋ। ਕੀ ਇਹ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ?
- ਜੇਕਰ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ ਹੈ: ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਦੀ ਪਾਲਣਾ ਕਰੋ, ਘਾਤਕ ਬੈਕਆਫ + ਜਿਟਰ ਲਾਗੂ ਕਰੋ, ਸੀਮਤ ਗਿਣਤੀ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਅਧਿਕਤਮ 5)।
- ਜੇਕਰ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਗਈ: ਫਿਕਸ (ਫਾਰਮੈਟ/ਕੁੰਜੀ) ਅਤੇ ਬੰਦ ਕਰੋ; ਲੂਪ ਵਿੱਚ ਉਹੀ ਗਲਤ ਬੇਨਤੀ ਨਾ ਦੁਹਰਾਓ।
- ਛੱਡਣ ਬਾਰੇ ਵਿਚਾਰ ਕਰੋ। ਜੇਕਰ n ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਵੀ ਅਸਫਲ ਰਿਹਾ, ਤਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਨਰਮ ਸੁਨੇਹਾ ਦਿਖਾਓ ਅਤੇ ਇਵੈਂਟ ਨੂੰ ਲੌਗ ਕਰੋ (ਟਰੈਕਿੰਗ ਯੂਨਿਟ 11)।
# ਮਜਬੂਤ ਕਾਲ pseudo-codedene = 0repeat: response = request_at() if response.success: ਜਵਾਬ ਦਿਓ ਜੇ [429, 500, 529] ਵਿੱਚ response.code ਅਤੇ ਕੋਸ਼ਿਸ਼ ਕਰੋ <5: wait = retry_after ?? (2^ਕੋਸ਼ਿਸ਼ ਸਕਿੰਟ + ਝਟਕਾ) ਨੀਂਦ (ਉਡੀਕ); ਕੋਸ਼ਿਸ਼ ਕਰੋ += 1; git ਦੁਬਾਰਾ ਜੇ [400, 401, 403, 404] ਵਿੱਚ response.code: save_error(response); ਵਾਪਸੀ "ਬੇਨਤੀ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ" ਵਾਪਸੀ "ਸਥਾਈ ਗਲਤੀ, ਬਾਅਦ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰੋ"
# ਉਪਭੋਗਤਾ ਨੂੰ ਨਰਮ ਫੀਡਬੈਕ (ਜਦੋਂ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਖਤਮ ਹੋ ਜਾਂਦੀਆਂ ਹਨ) "ਮੈਂ ਇਸ ਸਮੇਂ ਰੁੱਝਿਆ ਹੋਇਆ ਹਾਂ, ਮੈਂ ਤੁਹਾਡੀ ਬੇਨਤੀ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕਰ ਸਕਿਆ। ਜਲਦੀ ਹੀ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਜਾਂ ਮੈਂ ਤੁਹਾਡੀ ਬੇਨਤੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰ ਲਿਆ ਹੈ, ਜਦੋਂ ਇਹ ਤਿਆਰ ਹੋ ਜਾਵੇਗੀ ਤਾਂ ਮੈਂ ਤੁਹਾਡੇ ਕੋਲ ਵਾਪਸ ਆਵਾਂਗਾ।"
ਕਮਜ਼ੋਰ ਪ੍ਰੋਂਪਟ / ਮਜ਼ਬੂਤ ਪ੍ਰੋਂਪਟ (ਇੱਥੇ: ਗਲਤੀ ਸੁਨੇਹਾ ਡਿਜ਼ਾਈਨ)
# ਕਮਜ਼ੋਰ (ਉਪਭੋਗਤਾ ਨੂੰ ਕੱਚੀ ਗਲਤੀ ਦਿਖਾਉਂਦਾ ਹੈ)"ਗਲਤੀ 429: ਦਰ_ਸੀਮਾ_ਤਰੁੱਟੀ"
# STRONG (ਉਪਭੋਗਤਾ-ਅਨੁਕੂਲ, ਭਰੋਸੇਮੰਦ, ਕਾਰਵਾਈ-ਸੁਝਾਅ) "ਸਿਸਟਮ ਵਿੱਚ ਇੱਕ ਅਸਥਾਈ ਭੀੜ ਸੀ। ਸਾਨੂੰ ਤੁਹਾਡੀ ਬੇਨਤੀ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਪ੍ਰਾਪਤ ਹੋਈ ਹੈ ਅਤੇ ਇਸਨੂੰ ਆਪਣੇ ਆਪ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਜੇਕਰ ਨਤੀਜਾ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਨਹੀਂ ਆਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਪੰਨੇ ਨੂੰ ਤਾਜ਼ਾ ਕਰ ਸਕਦੇ ਹੋ।"
ਅੰਤਮ ਉਪਭੋਗਤਾ ਨੂੰ ਕੱਚੀ ਤਕਨੀਕੀ ਗਲਤੀ ਦਾ ਖੁਲਾਸਾ ਕਰਨਾ ਵਿਸ਼ਵਾਸ ਨੂੰ ਕਮਜ਼ੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸੁਰੱਖਿਆ ਕਮਜ਼ੋਰੀ ਹੋ ਸਕਦਾ ਹੈ। ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਗਲਤੀਆਂ ਨੂੰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਸ਼ਾਂਤ, ਕਾਰਵਾਈ-ਮੁਖੀ ਸੁਨੇਹਾ ਦਿਓ; ਰਿਕਾਰਡ ਲਈ ਸਿਰਫ਼ ਤਕਨੀਕੀ ਵੇਰਵੇ ਲਿਖੋ।
ਤਿੰਨ ਮਿੰਨੀ ਕੇਸ
ਕੇਸ 1 - ਟ੍ਰੈਫਿਕ ਧਮਾਕੇ ਵਿੱਚ ਕਿਸ਼ਤੀ ਹਾਦਸਾਗ੍ਰਸਤ ਹੋ ਗਈ। ਇੱਕ ਗਾਹਕ ਸੇਵਾ ਬੋਟ ਨੂੰ ਮੁਹਿੰਮ ਵਾਲੇ ਦਿਨ ਵੱਧ ਟ੍ਰੈਫਿਕ ਵਿੱਚ 429 ਪ੍ਰਾਪਤ ਹੋਏ; ਕੋਡ ਵਿੱਚ ਕੋਈ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ, ਹਰ ਗਲਤੀ ਸਿੱਧੇ ਉਪਭੋਗਤਾ ਨੂੰ "ਗਲਤੀ" ਵਜੋਂ ਪ੍ਰਤੀਬਿੰਬਿਤ ਕੀਤੀ ਗਈ ਸੀ। ਉਹਨਾਂ ਨੇ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਰੀਟਰੇਸਮੈਂਟ + ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਸ਼ਾਮਲ ਕੀਤਾ; ਉਸੇ ਟ੍ਰੈਫਿਕ ਦੇ ਨਾਲ, ਬੇਨਤੀਆਂ ਨੂੰ ਕਈ ਸਕਿੰਟਾਂ ਦੀ ਦੇਰੀ ਨਾਲ ਪਾਸ ਕੀਤਾ ਗਿਆ, ਉਪਭੋਗਤਾ ਨੂੰ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਦਿਖਾਈ ਦਿੱਤੀ।
ਕੇਸ 2 - ਲੂਪ ਵਿੱਚ 400 ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਇੱਕ ਅਯੋਗ ਮਾਡਲ ID ਦੇ ਕਾਰਨ ਇੱਕ ਏਕੀਕਰਣ ਇੱਕ 404 ਪ੍ਰਾਪਤ ਕਰ ਰਿਹਾ ਸੀ, ਪਰ ਸਾਰੀਆਂ ਤਰੁੱਟੀਆਂ ਨੂੰ "ਅਸਥਾਈ" ਸਮਝ ਰਿਹਾ ਸੀ ਅਤੇ ਇੱਕ ਅਨੰਤ ਲੂਪ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਸੀ; ਲੌਗ ਸੁੱਜ ਗਿਆ ਅਤੇ ਬੇਲੋੜਾ ਲੋਡ ਬਣਾਇਆ ਗਿਆ। ਉਹਨਾਂ ਨੇ ਗਲਤੀ ਵਰਗੀਕਰਣ ਜੋੜਿਆ: 404 ਨੂੰ ਸਥਾਈ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ, ਲੂਪ ਨੂੰ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਮਾਡਲ ID ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਬਕ: ਹਰ ਗਲਤੀ ਨੂੰ ਦੁਬਾਰਾ ਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ।
ਕੇਸ 3 - ਸਾਹਮਣੇ ਤੋਂ ਸੀਮਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ। 429 ਦੀ ਸੀਮਾ 'ਤੇ ਇੱਕ ਡਾਟਾ ਸੰਸ਼ੋਧਨ ਕੰਮ ਲਗਾਤਾਰ ਚੱਲ ਰਿਹਾ ਸੀ। ਉਹਨਾਂ ਨੇ x-ratelimit-ਬਾਕੀ ਹੈਡਰ ਦੀ ਪਾਲਣਾ ਕੀਤੀ ਅਤੇ ਕੋਟੇ ਦੇ ਅਨੁਸਾਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਥਰੋਟਲ ਕੀਤਾ. ਇਸ ਲਈ ਉਹਨਾਂ ਨੇ ਬਿਨਾਂ ਕਿਸੇ 429s ਲਏ, ਸੀਮਾ ਤੋਂ ਬਿਲਕੁਲ ਹੇਠਾਂ ਇੱਕ ਸਥਿਰ ਗਤੀ ਬਣਾਈ ਰੱਖੀ; ਕੰਮ ਵਧੇਰੇ ਅਨੁਮਾਨਤ ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਕੀਤਾ ਗਿਆ ਸੀ.
ਆਮ ਗਲਤੀਆਂ
- 429 ਵਿੱਚ ਗਤੀ ਵਧਾਉਣਾ: ਸਥਿਤੀ ਨੂੰ ਵਿਗੜਦਾ ਹੈ; ਵਾਪਸੀ ਲਈ ਸਵਿਚ ਕਰੋ।
- ਹਰੇਕ ਗਲਤੀ ਦੀ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ: 400/401/404 ਸਥਾਈ ਹੈ; ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਵਿਅਰਥ ਹੈ।
- ਸਥਿਰ ਉਡੀਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ: ਇੱਕ ਟੱਕਰ ਬਣਾਉਂਦਾ ਹੈ; ਘਾਤਕ + ਜਿਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ।
- 'ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ' ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ: ਪ੍ਰਦਾਤਾ ਦੁਆਰਾ ਨਿਰਧਾਰਤ ਸਮੇਂ ਦੀ ਪਾਲਣਾ ਕਰਨਾ ਸਭ ਤੋਂ ਸਹੀ ਹੈ।
- ਉਪਭੋਗਤਾ ਨੂੰ ਕੱਚੀ ਗਲਤੀ ਦਾ ਖੁਲਾਸਾ ਕਰਨਾ: ਵਿਸ਼ਵਾਸ ਨੂੰ ਹਿਲਾ ਦਿੰਦਾ ਹੈ, ਕਮਜ਼ੋਰੀਆਂ ਪੈਦਾ ਕਰਦਾ ਹੈ; ਅੰਦਰ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰੋ.
- ਅਸੀਮਤ ਕੋਸ਼ਿਸ਼ਾਂ: ਇੱਕ ਉਪਰਲੀ ਸੀਮਾ ਸੈਟ ਕਰੋ (ਜਿਵੇਂ ਕਿ 5 ਮੁੜ ਕੋਸ਼ਿਸ਼ਾਂ); ਫਿਰ ਕਿਰਪਾ ਨਾਲ ਛੱਡ ਦਿਓ।
ਡੂੰਘੇ: ਕਤਾਰਬੰਦੀ, ਇਕਸਾਰਤਾ, ਅਤੇ ਸਰਕਟ ਤੋੜਨ ਵਾਲੇ
ਇੱਕੋ ਇੱਛਾ ਦਾ ਧੀਰਜ ਪਹਿਲਾ ਕਦਮ ਹੈ; ਅਸਲ ਪਰਿਪੱਕਤਾ ਸੀਮਾ ਨੂੰ ਦੱਬੇ ਬਿਨਾਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਹੈ। ਇੱਥੇ ਤਿੰਨ ਧਾਰਨਾਵਾਂ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ।
ਕਤਾਰ: ਤੁਸੀਂ ਬੇਨਤੀਆਂ ਨੂੰ ਤੁਰੰਤ ਭੇਜਣ ਦੀ ਬਜਾਏ ਇੱਕ ਨਿਯੰਤਰਿਤ ਰਫ਼ਤਾਰ ਨਾਲ ਭੇਜਣ ਲਈ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਰੱਖਦੇ ਹੋ। ਕਤਾਰ ਟ੍ਰੈਫਿਕ ਦੇ ਅਚਾਨਕ ਵਿਸਫੋਟ ਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਂਦੀ ਹੈ: ਭਾਵੇਂ 1,000 ਬੇਨਤੀਆਂ ਇੱਕੋ ਵਾਰ ਆਉਂਦੀਆਂ ਹਨ, ਕਤਾਰ ਉਹਨਾਂ ਨੂੰ ਸੀਮਾ ਤੋਂ ਘੱਟ ਦਰ 'ਤੇ ਜਾਰੀ ਕਰੇਗੀ। ਇਸ ਤਰ੍ਹਾਂ ਤੁਸੀਂ 429 ਨੂੰ ਰੋਕਦੇ ਹੋ, ਫਿਰ ਤੁਹਾਨੂੰ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।
ਸਮਰੂਪਤਾ ਸੀਮਾ: ਤੁਸੀਂ ਸੀਮਤ ਕਰਦੇ ਹੋ ਕਿ ਇੱਕੋ ਸਮੇਂ "ਹਵਾ ਵਿੱਚ" ਕਿੰਨੀਆਂ ਬੇਨਤੀਆਂ ਹਨ। ਅਸੀਮਤ ਸਮਾਨਾਂਤਰ ਬੇਨਤੀਆਂ ਤੇਜ਼ੀ ਨਾਲ RPM ਅਤੇ TPM ਸੀਮਾਵਾਂ ਨੂੰ ਭਰ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਵਾਜਬ ਸਮਕਾਲੀ ਸੀਲਿੰਗ (ਜਿਵੇਂ ਕਿ 10 ਸਮਕਾਲੀ ਬੇਨਤੀਆਂ ਤੋਂ ਵੱਧ ਨਹੀਂ) ਦੋਵੇਂ ਸੀਮਾਵਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਦੀਆਂ ਹਨ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਅਨੁਮਾਨ ਲਗਾਉਣ ਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਸਰਕਟ ਤੋੜਨ ਵਾਲਾ: ਜੇਕਰ ਪ੍ਰਦਾਤਾ 500/529 ਨੂੰ ਵਾਪਸ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਹਰ ਬੇਨਤੀ ਨੂੰ ਸਖਤੀ ਨਾਲ ਅਜ਼ਮਾਉਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਕੁਝ ਸਮੇਂ ਲਈ "ਸਰਕਟ ਤੋੜੋ" ਅਤੇ ਬੇਨਤੀ ਨੂੰ ਕਦੇ ਵੀ ਭੇਜੇ ਬਿਨਾਂ ਤੁਰੰਤ ਅਸਫਲ ਹੋ ਜਾਂਦੇ ਹੋ। ਇੱਕ ਉਡੀਕ ਤੋਂ ਬਾਅਦ, ਤੁਸੀਂ ਸਰਕਟ ਨੂੰ ਵਾਪਸ ਚਾਲੂ ਕਰੋ ਅਤੇ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਇਹ ਪੈਟਰਨ ਇੱਕ ਅਸਥਾਈ ਪ੍ਰਦਾਤਾ ਅਸਫਲਤਾ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਤੁਹਾਡੇ ਸਿਸਟਮ ਨੂੰ ਕਰੈਸ਼ ਹੋਣ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਇਕੱਠੇ, ਇਹ ਤਿੰਨ ਇੱਕ ਸਿੰਗਲ ਕਾਲ ਦੇ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਤਰਕ ਤੋਂ ਪਰੇ ਸਿਸਟਮ-ਪੱਧਰ ਦੀ ਲਚਕਤਾ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ। ਛੋਟੇ ਪੈਮਾਨੇ 'ਤੇ, SDK ਦੀ ਆਟੋਮੈਟਿਕ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਾਫ਼ੀ ਹੈ; ਜਿਵੇਂ-ਜਿਵੇਂ ਸਕੇਲ ਵਧਦਾ ਹੈ, ਕਤਾਰਬੰਦੀ, ਸਮਰੂਪਤਾ, ਅਤੇ ਸਰਕਟ ਬ੍ਰੇਕਰ ਲਾਜ਼ਮੀ ਬਣ ਜਾਂਦੇ ਹਨ। ਉਹਨਾਂ ਸਾਰਿਆਂ ਦਾ ਇੱਕੋ ਜਿਹਾ ਟੀਚਾ ਹੈ: ਉਪਭੋਗਤਾ ਲਈ ਇੱਕ ਅਸਥਾਈ ਸਮੱਸਿਆ ਨੂੰ ਕਰੈਸ਼ ਵਜੋਂ ਨਹੀਂ, ਪਰ ਕੁਝ ਸਕਿੰਟਾਂ ਦੀ ਅਦਿੱਖ ਦੇਰੀ ਵਜੋਂ ਪ੍ਰਤੀਬਿੰਬਤ ਕਰਨਾ।
ਸੰਖੇਪ ਵਿੱਚ
429 ਵਾਪਸੀ ਜਦੋਂ ਸਪੀਡ ਸੀਮਾਵਾਂ (RPM/ITPM/OTPM) ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ; ਇਹ ਇੱਕ ਅਸਥਾਈ ਤਰੁਟੀ ਹੈ ਅਤੇ ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਅਤੇ ਘਾਤਕ ਬੈਕਆਫ + ਜਿਟਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਜਾਵੇਗੀ। 500 ਅਤੇ 529 ਵੀ ਆਰਜ਼ੀ ਹਨ; 400/401/403/404 ਇੱਕ ਬੇਨਤੀ/ਪਛਾਣ ਦਾ ਮੁੱਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਕੇ ਹੱਲ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਇੱਕ ਮਜ਼ਬੂਤ ਪ੍ਰਵਾਹ ਇਹਨਾਂ ਦੋ ਸਮੂਹਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ, ਸੀਮਤ ਗਿਣਤੀ ਵਿੱਚ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਸਾਹਮਣੇ ਤੋਂ ਸੀਮਾ ਦੀ ਨਿਗਰਾਨੀ ਕਰਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਸ਼ਾਂਤ ਸੰਦੇਸ਼ ਦਿਖਾਉਂਦਾ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਕੰਮ
ਆਪਣੇ ਏਕੀਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। (1) ਉਹਨਾਂ ਗਲਤੀ ਕੋਡਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਸਾਹਮਣਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ "ਮੁੜ ਕੋਸ਼ਿਸ਼ਯੋਗ / ਸਥਾਈ" ਵਿੱਚ ਵੱਖ ਕਰੋ। (2) ਆਪਣੀ ਘਾਤਕ ਪੁੱਲਬੈਕ ਯੋਜਨਾ (ਸ਼ੁਰੂਆਤੀ ਹੋਲਡ, ਗੁਣਾਂਕ, ਕੈਪ, ਜਿਟਰ) ਨੂੰ ਲਿਖੋ। (3) ਮੁੜ-ਕੋਸ਼ਿਸ਼-ਬਾਅਦ ਸਿਰਲੇਖ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਬਾਰੇ ਦੱਸੋ। (4) ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ਾਂ ਦੇ ਖਤਮ ਹੋਣ 'ਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ ਨਰਮ ਸੰਦੇਸ਼ ਲਿਖੋ।
ਚੈੱਕਲਿਸਟ
- [ ] ਮੈਂ RPM/ITPM/OTPM ਸੀਮਾਵਾਂ ਅਤੇ 429 ਦੀ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।
- [ ] ਮੈਂ ਐਕਸਪੋਨੈਂਸ਼ੀਅਲ ਰੀਟਰੀਟ + ਜਿਟਰ + ਰੀਟ੍ਰੀ-ਆਫਟਰ ਦੇ ਤਰਕ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹਾਂ।
- [ ] ਮੈਂ ਗਲਤੀ ਕੋਡਾਂ ਨੂੰ ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਯੋਗ/ਸਥਾਈ ਵਜੋਂ ਸ਼੍ਰੇਣੀਬੱਧ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ।
- [ ] ਮੈਂ ਜਾਣਦਾ ਹਾਂ ਕਿ ਸਾਨੂੰ ਹਰ ਗਲਤੀ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।
- [ ] ਇੱਕ ਕੱਚੀ ਗਲਤੀ ਦੀ ਬਜਾਏ, ਮੈਂ ਉਪਭੋਗਤਾ ਨੂੰ ਇੱਕ ਸ਼ਾਂਤ, ਕਾਰਵਾਈ-ਮੁਖੀ ਸੁਨੇਹਾ ਦਿਖਾ ਸਕਦਾ ਹਾਂ।