ವೇಗದ ಮಿತಿಗಳು ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕ ದೋಷ ನಿರ್ವಹಣೆ

ಲಾಭಗಳು:

• ವೇಗದ ಮಿತಿಗಳನ್ನು (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 ಸೆಕೆಂಡ್ ನಿರೀಕ್ಷಿಸಿ "ಜಿಟ್ಟರ್" ನಂತರ ಹೆಚ್ಚಿನ ಪ್ರಯೋಗ

ಇದಕ್ಕೆ ಸ್ವಲ್ಪ ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು (ಜಿಟ್ಟರ್) ಸೇರಿಸುವುದರಿಂದ ಅದೇ ಸಮಯದಲ್ಲಿ ಮರುಪ್ರಯತ್ನಿಸಲು ಪ್ರಯತ್ನಿಸುವಾಗ ವಿನಂತಿಗಳು ಡಿಕ್ಕಿಯಾಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, 429 ಪ್ರತಿಕ್ರಿಯೆಯು ಸಾಮಾನ್ಯವಾಗಿ `ಮರುಪ್ರಯತ್ನ-ನಂತರ` ಹೆಡರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ: "ಇಷ್ಟು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ". ಕುರುಡಾಗಿ ಕಾಯುವುದಕ್ಕಿಂತ ಈ ಶೀರ್ಷಿಕೆಯನ್ನು ಗೌರವಿಸುವುದು ಹೆಚ್ಚು ನಿಖರವಾಗಿದೆ.

ಎಚ್ಚರಿಕೆ: ನೀವು 429 ಅನ್ನು ಪಡೆದಾಗ, "ಹೆಚ್ಚು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವ ಮೂಲಕ ಅದನ್ನು ಒತ್ತಾಯಿಸುವುದು" ಪರಿಸ್ಥಿತಿಯನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ; ಮಿತಿಯನ್ನು ಭರ್ತಿ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸಲಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ವಿನಂತಿಗಳು ಹಾದುಹೋಗುವುದಿಲ್ಲ. ಸರಿಯಾದ ಪ್ರತಿಕ್ರಿಯೆ ಹಿಮ್ಮೆಟ್ಟುವಿಕೆ, ವೇಗವರ್ಧನೆ ಅಲ್ಲ. ಒಳ್ಳೆಯ ಸುದ್ದಿ: ಹೆಚ್ಚಿನ ಅಧಿಕೃತ SDKಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ 429 ಅನ್ನು ಮರುಪ್ರಯತ್ನಿಸುತ್ತವೆ ಮತ್ತು ಬ್ಯಾಕ್‌ಆಫ್‌ನೊಂದಿಗೆ ಸರ್ವರ್ ದೋಷಗಳು - ಹಸ್ತಚಾಲಿತವಾಗಿ ಸ್ಥಾಪಿಸುವ ಮೊದಲು SDK ನ ಈ ನಡವಳಿಕೆಯನ್ನು ಬಳಸಿ.

HTTP ದೋಷ ಕೋಡ್‌ಗಳನ್ನು ವರ್ಗೀಕರಿಸಲಾಗುತ್ತಿದೆ

ಪ್ರತಿಯೊಂದು ತಪ್ಪು ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ. ವಿಮರ್ಶಾತ್ಮಕ ವ್ಯತ್ಯಾಸ: ಇದನ್ನು ಮರುಪ್ರಯತ್ನಿಸಬಹುದೇ ಅಥವಾ ಇದು ವಿನಂತಿ/ಗುರುತಿನ ಸಮಸ್ಯೆಯೇ?

ಕೋಡ್

ಅರ್ಥ

ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದೇ?

ಸರಿಯಾದ ಪ್ರತಿಕ್ರಿಯೆ

400

ಅಮಾನ್ಯ ವಿನಂತಿ (ಫಾರ್ಮ್ಯಾಟ್/ಪ್ಯಾರಾಮೀಟರ್ ದೋಷ)

ಇಲ್ಲ

ವಿನಂತಿಯನ್ನು ಸರಿಪಡಿಸಿ; ಮತ್ತೆ ಅದೇ ಕಳುಹಿಸಬೇಡಿ

401

ದೃಢೀಕರಣ ದೋಷ (ಕೀಲಿ ಅಮಾನ್ಯವಾಗಿದೆ/ಕಾಣೆಯಾಗಿದೆ)

ಇಲ್ಲ

ಕೀ / ಶೀರ್ಷಿಕೆಯನ್ನು ಸರಿಪಡಿಸಿ

403

ಯಾವುದೇ ದೃಢೀಕರಣವಿಲ್ಲ (ಮಾದರಿ/ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ಪ್ರವೇಶವಿಲ್ಲ)

ಇಲ್ಲ

ಅನುಮತಿಗಳು/ವ್ಯಾಪ್ತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

404

ಕಂಡುಬಂದಿಲ್ಲ (ತಪ್ಪಾದ ಮಾದರಿ ID/ಎಂಡ್ ಪಾಯಿಂಟ್)

ಇಲ್ಲ

ಸರಿಯಾದ ಮಾದರಿ ಐಡಿ/ವಿಳಾಸ

429

ವೇಗದ ಮಿತಿ ಮೀರಿದೆ

ಹೌದು

ಹಿಮ್ಮೆಟ್ಟುವಿಕೆ + ಮರುಪ್ರಯತ್ನ-ನಂತರ

500

ಸರ್ವರ್ ದೋಷ

ಹೌದು

ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಯೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ

529

ಸರ್ವರ್ ಓವರ್ಲೋಡ್ ಆಗಿದೆ

ಹೌದು

ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಯೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ

ಸುವರ್ಣ ನಿಯಮ: 429, 500 ಮತ್ತು 529 ತಾತ್ಕಾಲಿಕ; ಅದನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವುದರೊಂದಿಗೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತದೆ. 400, 401, 403, 404 ವಿನಂತಿ/ಗುರುತಿನ ಸಮಸ್ಯೆಗಳು; ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ಅದನ್ನು ಪರಿಹರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದು ಶ್ರಮವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್ ಈ ಎರಡು ಗುಂಪುಗಳ ನಡುವೆ ವ್ಯತ್ಯಾಸವನ್ನು ಹೊಂದಿರಬೇಕು.

ಹಂತ ಹಂತವಾಗಿ: ಬಾಳಿಕೆ ಬರುವ ಕರೆ

1. ವಿನಂತಿಯನ್ನು ಸಲ್ಲಿಸಿ. ಯಶಸ್ವಿಯಾದರೆ, ಮುಂದುವರಿಯಿರಿ.
2. ದೋಷ ಕೋಡ್ ಅನ್ನು ವರ್ಗೀಕರಿಸಿ. ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದೇ?
3. ಪ್ರಯತ್ನಿಸಬಹುದಾದರೆ: ಮರುಪ್ರಯತ್ನ-ನಂತರ ಅನುಸರಿಸಿ, ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್ + ಜಿಟ್ಟರ್ ಅನ್ನು ಅನ್ವಯಿಸಿ, ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಬಾರಿ ಪ್ರಯತ್ನಿಸಿ (ಉದಾ. 5 ಗರಿಷ್ಠ).
4. ಪ್ರಯತ್ನಿಸದಿದ್ದರೆ: ಸರಿಪಡಿಸಿ (ಫಾರ್ಮ್ಯಾಟ್/ಕೀ) ಮತ್ತು ನಿಲ್ಲಿಸಿ; ಲೂಪ್‌ನಲ್ಲಿ ಅದೇ ತಪ್ಪಾದ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ.
5. ಬಿಟ್ಟುಕೊಡುವುದನ್ನು ಪರಿಗಣಿಸಿ. n ಪ್ರಯತ್ನಗಳ ನಂತರವೂ ವಿಫಲವಾದರೆ, ಬಳಕೆದಾರರಿಗೆ ಸಭ್ಯ ಸಂದೇಶವನ್ನು ತೋರಿಸಿ ಮತ್ತು ಈವೆಂಟ್ ಅನ್ನು ಲಾಗ್ ಮಾಡಿ (ಟ್ರ್ಯಾಕಿಂಗ್ ಘಟಕ 11).

# ದೃಢವಾದ ಕರೆ ಸ್ಯೂಡೋ-ಕೋಡೆಡೆನ್ = 0ಪುನರಾವರ್ತನೆ: ಪ್ರತಿಕ್ರಿಯೆ = ವಿನಂತಿ_ಅಟ್() ಒಂದು ವೇಳೆ ಪ್ರತಿಕ್ರಿಯೆ. ಯಶಸ್ಸು: ಪ್ರತಿಕ್ರಿಯೆ ವೇಳೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸಿ [429, 500, 529] ರಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆ.ಕೋಡ್ ಮತ್ತು <5: ನಿರೀಕ್ಷಿಸಿ = ಮರುಪ್ರಯತ್ನಿಸಿ_ನಂತರ ?? (2^ಪ್ರಯತ್ನ ಸೆಕೆಂಡು + ನಡುಗುವಿಕೆ) ನಿದ್ರೆ(ನಿರೀಕ್ಷಿಸಿ); ಪ್ರಯತ್ನಿಸಿ += 1; [400, 401, 403, 404] ನಲ್ಲಿ response.code ಆಗಿದ್ದರೆ ಮತ್ತೆ git: save_error(response); ಹಿಂತಿರುಗಿ "ವಿನಂತಿಯನ್ನು ಸರಿಪಡಿಸಬೇಕು" ಹಿಂತಿರುಗಿ "ಶಾಶ್ವತ ದೋಷ, ನಂತರ ಪ್ರಯತ್ನಿಸಿ"

# ಬಳಕೆದಾರರಿಗೆ ಸಭ್ಯ ಪ್ರತಿಕ್ರಿಯೆ (ಮರುಪ್ರಯತ್ನಗಳು ಖಾಲಿಯಾದಾಗ) "ನಾನು ಇದೀಗ ಕಾರ್ಯನಿರತನಾಗಿದ್ದೇನೆ, ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ನನಗೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಶೀಘ್ರದಲ್ಲೇ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಿ, ಅಥವಾ ನಾನು ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ಉಳಿಸಿದ್ದೇನೆ, ಅದು ಸಿದ್ಧವಾದಾಗ ನಾನು ನಿಮ್ಮನ್ನು ಸಂಪರ್ಕಿಸುತ್ತೇನೆ."

ದುರ್ಬಲ ಪ್ರಾಂಪ್ಟ್ / ಬಲವಾದ ಪ್ರಾಂಪ್ಟ್ (ಇಲ್ಲಿ: ದೋಷ ಸಂದೇಶ ವಿನ್ಯಾಸ)

# ದುರ್ಬಲ (ಬಳಕೆದಾರರಿಗೆ ಕಚ್ಚಾ ದೋಷವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ)"ದೋಷ 429: ದರ_ಮಿತಿ_ದೋಷ"

# STRONG (ಬಳಕೆದಾರ ಸ್ನೇಹಿ, ಭರವಸೆ ನೀಡುವ, ಕ್ರಮ-ಸೂಚನೆ) "ಸಿಸ್ಟಂನಲ್ಲಿ ತಾತ್ಕಾಲಿಕ ದಟ್ಟಣೆ ಕಂಡುಬಂದಿದೆ. ನಿಮ್ಮ ವಿನಂತಿಯನ್ನು ನಾವು ಸುರಕ್ಷಿತವಾಗಿ ಸ್ವೀಕರಿಸಿದ್ದೇವೆ ಮತ್ತು ಅದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ. ಕೆಲವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಫಲಿತಾಂಶವು ಗೋಚರಿಸದಿದ್ದರೆ, ನೀವು ಪುಟವನ್ನು ರಿಫ್ರೆಶ್ ಮಾಡಬಹುದು."

ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ಕಚ್ಚಾ ತಾಂತ್ರಿಕ ದೋಷವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು ನಂಬಿಕೆಯನ್ನು ದುರ್ಬಲಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಭದ್ರತಾ ದುರ್ಬಲತೆಯಾಗಿರಬಹುದು. ದೋಷಗಳನ್ನು ಆಂತರಿಕವಾಗಿ ವರ್ಗೀಕರಿಸಿ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಶಾಂತ, ಕ್ರಿಯೆ-ಆಧಾರಿತ ಸಂದೇಶವನ್ನು ನೀಡಿ; ದಾಖಲೆಗಾಗಿ ತಾಂತ್ರಿಕ ವಿವರಗಳನ್ನು ಬರೆಯಿರಿ.

ಮೂರು ಮಿನಿ ಪ್ರಕರಣಗಳು

ಪ್ರಕರಣ 1 - ಟ್ರಾಫಿಕ್ ಸ್ಫೋಟದಲ್ಲಿ ದೋಣಿ ಅಪಘಾತಕ್ಕೀಡಾಗಿದೆ. ಪ್ರಚಾರದ ದಿನದಂದು ಹೆಚ್ಚಿದ ದಟ್ಟಣೆಯಲ್ಲಿ ಗ್ರಾಹಕ ಸೇವಾ ಬೋಟ್ 429 ಅನ್ನು ಸ್ವೀಕರಿಸಿತು; ಕೋಡ್‌ನಲ್ಲಿ ಯಾವುದೇ ಮರುಪ್ರಯತ್ನವಿಲ್ಲ, ಪ್ರತಿ ದೋಷವು ಬಳಕೆದಾರರಿಗೆ ನೇರವಾಗಿ "ದೋಷ" ಎಂದು ಪ್ರತಿಫಲಿಸುತ್ತದೆ. ಅವರು ಘಾತೀಯ ಹಿಂಪಡೆಯುವಿಕೆ + ಮರುಪ್ರಯತ್ನದ ನಂತರ; ಅದೇ ದಟ್ಟಣೆಯೊಂದಿಗೆ, ಹಲವಾರು ಸೆಕೆಂಡುಗಳ ವಿಳಂಬದೊಂದಿಗೆ ವಿನಂತಿಗಳನ್ನು ರವಾನಿಸಲಾಗಿದೆ, ಬಳಕೆದಾರರು ಯಾವುದೇ ದೋಷಗಳನ್ನು ನೋಡಲಿಲ್ಲ.

ಪ್ರಕರಣ 2 - ಲೂಪ್‌ನಲ್ಲಿ 400 ಅನ್ನು ಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ. ಅಮಾನ್ಯವಾದ ಮಾದರಿ ಐಡಿಯಿಂದಾಗಿ ಏಕೀಕರಣವು 404 ಅನ್ನು ಪಡೆಯುತ್ತಿದೆ, ಆದರೆ ಎಲ್ಲಾ ದೋಷಗಳನ್ನು "ಅಸ್ಥಿರ" ಎಂದು ಪರಿಗಣಿಸುತ್ತಿದೆ ಮತ್ತು ಅನಂತ ಲೂಪ್‌ನಲ್ಲಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ; ಲಾಗ್ ಊದಿಕೊಂಡಿತು ಮತ್ತು ಅನಗತ್ಯ ಲೋಡ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ಅವರು ದೋಷ ವರ್ಗೀಕರಣವನ್ನು ಸೇರಿಸಿದ್ದಾರೆ: 404 ಅನ್ನು ಶಾಶ್ವತವೆಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ, ಲೂಪ್ ಅನ್ನು ನಿಲ್ಲಿಸಲಾಗಿದೆ ಮತ್ತು ಮಾದರಿ ID ಅನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ. ಪಾಠ: ಪ್ರತಿ ತಪ್ಪನ್ನು ಮತ್ತೊಮ್ಮೆ ಪ್ರಯತ್ನಿಸಬೇಡಿ.

ಪ್ರಕರಣ 3 - ಮುಂಭಾಗದಿಂದ ಮಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವುದು. ಡೇಟಾ ಪುಷ್ಟೀಕರಣದ ಕೆಲಸವು 429 ಮಿತಿಯಲ್ಲಿ ನಿರಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಅವರು x-ರೇಟ್‌ಲಿಮಿಟ್-ಉಳಿದ ಹೆಡರ್ ಅನ್ನು ಅನುಸರಿಸಿದರು ಮತ್ತು ಕೋಟಾದ ಪ್ರಕಾರ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಥ್ರೊಟಲ್ ಮಾಡಿದರು. ಆದ್ದರಿಂದ ಅವರು ಯಾವುದೇ 429ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳದೆ, ಮಿತಿಗಿಂತ ಸ್ವಲ್ಪ ಕೆಳಗೆ ಸ್ಥಿರವಾದ ವೇಗವನ್ನು ಉಳಿಸಿಕೊಂಡರು; ಕೆಲಸವನ್ನು ಹೆಚ್ಚು ನಿರೀಕ್ಷಿತವಾಗಿ ಮತ್ತು ವೇಗವಾಗಿ ಮಾಡಲಾಯಿತು.

ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

• 429 ರಲ್ಲಿ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸುವುದು: ಪರಿಸ್ಥಿತಿಯನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ; ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಗೆ ಬದಲಿಸಿ.
• ಪ್ರತಿ ದೋಷವನ್ನು ಮರುಪ್ರಯತ್ನಿಸಲಾಗುತ್ತಿದೆ: 400/401/404 ಶಾಶ್ವತವಾಗಿದೆ; ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವುದು ವ್ಯರ್ಥ.
• ಸ್ಥಿರ ಕಾಯುವಿಕೆಯನ್ನು ಬಳಸುವುದು: ಘರ್ಷಣೆಯನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಘಾತೀಯ + ನಡುಗುವಿಕೆಯನ್ನು ಬಳಸಿ.
• 'ಮರುಪ್ರಯತ್ನ-ನಂತರ' ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತಿದೆ: ಒದಗಿಸುವವರು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಮಯವನ್ನು ಅನುಸರಿಸುವುದು ಅತ್ಯಂತ ನಿಖರವಾಗಿದೆ.
• ಬಳಕೆದಾರರಿಗೆ ಕಚ್ಚಾ ದೋಷವನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದು: ನಂಬಿಕೆಯನ್ನು ಅಲುಗಾಡಿಸುತ್ತದೆ, ದುರ್ಬಲತೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ; ಒಳಗೆ ವರ್ಗೀಕರಿಸಿ.
• ಅನಿಯಮಿತ ಮರುಪ್ರಯತ್ನಗಳು: ಮೇಲಿನ ಮಿತಿಯನ್ನು ಹೊಂದಿಸಿ (ಉದಾ. 5 ಮರುಪ್ರಯತ್ನಗಳು); ನಂತರ ಆಕರ್ಷಕವಾಗಿ ಬಿಟ್ಟುಬಿಡಿ.

ಡೀಪರ್: ಕ್ಯೂಯಿಂಗ್, ಕನ್‌ಕರೆನ್ಸಿ ಮತ್ತು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್‌ಗಳು

ಒಂದೇ ಬಯಕೆಯ ಸಹಿಷ್ಣುತೆ ಮೊದಲ ಹೆಜ್ಜೆ; ಮಿತಿಗಳನ್ನು ಹೊಡೆಯದೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು ನಿಜವಾದ ಪ್ರಬುದ್ಧತೆಯಾಗಿದೆ. ಇಲ್ಲಿ ಮೂರು ಪರಿಕಲ್ಪನೆಗಳು ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತವೆ.

ಸರತಿ: ನೀವು ವಿನಂತಿಗಳನ್ನು ತಕ್ಷಣವೇ ಕಳುಹಿಸುವ ಬದಲು ನಿಯಂತ್ರಿತ ವೇಗದಲ್ಲಿ ಕಳುಹಿಸಲು ಸರದಿಯಲ್ಲಿ ಇರಿಸಿದ್ದೀರಿ. ಸರತಿ ಸಾಲು ಹಠಾತ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ: ಒಮ್ಮೆಗೆ 1,000 ವಿನಂತಿಗಳು ಬಂದರೂ ಸಹ, ಸರತಿಯು ಅವುಗಳನ್ನು ಮಿತಿಗಿಂತ ಕಡಿಮೆ ದರದಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು 429 ಅನ್ನು ತಡೆಗಟ್ಟುತ್ತೀರಿ, ನಂತರ ಅದನ್ನು ಸರಿಪಡಿಸುವ ಬಗ್ಗೆ ನೀವು ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ.

ಏಕಕಾಲಿಕ ಮಿತಿ: ಒಂದೇ ಸಮಯದಲ್ಲಿ "ಗಾಳಿಯಲ್ಲಿ" ಎಷ್ಟು ವಿನಂತಿಗಳನ್ನು ನೀವು ಮಿತಿಗೊಳಿಸುತ್ತೀರಿ. ಅನಿಯಮಿತ ಸಮಾನಾಂತರ ವಿನಂತಿಗಳು ತ್ವರಿತವಾಗಿ RPM ಮತ್ತು TPM ಮಿತಿಗಳನ್ನು ತುಂಬುತ್ತವೆ. ಸಮಂಜಸವಾದ ಏಕಕಾಲಿಕ ಸೀಲಿಂಗ್ (ಉದಾಹರಣೆಗೆ 10 ಏಕಕಾಲೀನ ವಿನಂತಿಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲ) ಎರಡೂ ಮಿತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ವ್ಯವಸ್ಥೆಯನ್ನು ಊಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ.

ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್: ಪೂರೈಕೆದಾರರು 500/529 ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿದ್ದರೆ, ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಪಟ್ಟುಬಿಡದೆ ಪ್ರಯತ್ನಿಸುವ ಬದಲು, ನೀವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ "ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಮುರಿಯಿರಿ" ಮತ್ತು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸದೆಯೇ ತ್ವರಿತವಾಗಿ ವಿಫಲಗೊಳ್ಳುತ್ತೀರಿ. ಕಾಯುವ ನಂತರ, ನೀವು ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಮತ್ತೆ ಆನ್ ಮಾಡಿ ಮತ್ತು ಪ್ರಯತ್ನಿಸಿ. ತಾತ್ಕಾಲಿಕ ಪೂರೈಕೆದಾರರ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮ್ಮ ಸಿಸ್ಟಮ್ ಕ್ರ್ಯಾಶ್ ಆಗುವುದನ್ನು ಈ ಮಾದರಿಯು ತಡೆಯುತ್ತದೆ.

ಒಟ್ಟಿಗೆ, ಈ ಮೂರು ಒಂದೇ ಕರೆಯ ಮರುಪ್ರಯತ್ನದ ತರ್ಕವನ್ನು ಮೀರಿ ಸಿಸ್ಟಮ್-ಮಟ್ಟದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವವನ್ನು ಸ್ಥಾಪಿಸುತ್ತವೆ. ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ, SDK ಯ ಸ್ವಯಂಚಾಲಿತ ಮರುಪ್ರಯತ್ನವು ಸಾಕಾಗುತ್ತದೆ; ಪ್ರಮಾಣವು ಬೆಳೆದಂತೆ, ಸರತಿ ಸಾಲಿನಲ್ಲಿ ನಿಲ್ಲುವುದು, ಏಕಕಾಲಿಕತೆ ಮತ್ತು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಅನಿವಾರ್ಯವಾಗುತ್ತದೆ. ಅವರೆಲ್ಲರೂ ಒಂದೇ ಸಾಮಾನ್ಯ ಗುರಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ: ಬಳಕೆದಾರರಿಗೆ ತಾತ್ಕಾಲಿಕ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತಿಬಿಂಬಿಸಲು ಕ್ರ್ಯಾಶ್ ಆಗಿ ಅಲ್ಲ, ಆದರೆ ಕೆಲವು ಸೆಕೆಂಡುಗಳ ಅದೃಶ್ಯ ವಿಳಂಬವಾಗಿ.

ಸಾರಾಂಶದಲ್ಲಿ

ವೇಗದ ಮಿತಿಗಳನ್ನು (RPM/ITPM/OTPM) ಮೀರಿದಾಗ 429 ಹಿಂತಿರುಗಿಸುತ್ತದೆ; ಇದು ತಾತ್ಕಾಲಿಕ ದೋಷವಾಗಿದೆ ಮತ್ತು ಮರುಪ್ರಯತ್ನದ ನಂತರ ಮತ್ತು ಘಾತೀಯ ಬ್ಯಾಕ್‌ಆಫ್ + ಜಿಟ್ಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಮರುಪ್ರಯತ್ನಿಸಲಾಗುತ್ತದೆ. 500 ಮತ್ತು 529 ಸಹ ತಾತ್ಕಾಲಿಕವಾಗಿವೆ; 400/401/403/404 ವಿನಂತಿ/ಗುರುತಿನ ಸಮಸ್ಯೆಯಾಗಿದೆ ಮತ್ತು ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುವ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುವುದಿಲ್ಲ. ದೃಢವಾದ ಹರಿವು ಈ ಎರಡು ಗುಂಪುಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಸೀಮಿತ ಸಂಖ್ಯೆಯ ಬಾರಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮುಂಭಾಗದಿಂದ ಮಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಶಾಂತ ಸಂದೇಶಗಳನ್ನು ತೋರಿಸುತ್ತದೆ.

ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯ

ನಿಮ್ಮ ಏಕೀಕರಣವನ್ನು ಪರಿಗಣಿಸಿ. (1) ನೀವು ಎದುರಿಸಬಹುದಾದ ದೋಷ ಕೋಡ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು "ಮರುಪ್ರಯತ್ನಿಸಬಹುದಾದ / ಶಾಶ್ವತ" ಎಂದು ಪ್ರತ್ಯೇಕಿಸಿ. (2) ನಿಮ್ಮ ಘಾತೀಯ ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಯೋಜನೆಯನ್ನು ಬರೆಯಿರಿ (ಆರಂಭಿಕ ಹಿಡಿತ, ಗುಣಾಂಕ, ಕ್ಯಾಪ್, ಜಿಟ್ಟರ್). (3) ಮರುಪ್ರಯತ್ನದ ನಂತರ ಹೆಡರ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿ. (4) ಮರುಪ್ರಯತ್ನಗಳು ಖಾಲಿಯಾದಾಗ ಬಳಕೆದಾರರಿಗೆ ಪ್ರದರ್ಶಿಸಬೇಕಾದ ಸಭ್ಯ ಸಂದೇಶವನ್ನು ಬರೆಯಿರಿ.

ಪರಿಶೀಲನಾಪಟ್ಟಿ

• [ ] ನಾನು RPM/ITPM/OTPM ಮಿತಿಗಳು ಮತ್ತು 429 ಅನ್ನು ವಿವರಿಸಬಲ್ಲೆ.
• [ ] ನಾನು ಘಾತೀಯ ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಯ ತರ್ಕವನ್ನು ಅನ್ವಯಿಸಬಹುದು + ನಡುಗುವಿಕೆ + ಮರುಪ್ರಯತ್ನದ ನಂತರ.
• [ ] ನಾನು ದೋಷ ಕೋಡ್‌ಗಳನ್ನು ಮರುಪ್ರಯತ್ನಿಸಬಹುದಾದ/ಶಾಶ್ವತ ಎಂದು ವರ್ಗೀಕರಿಸಬಹುದು.
• [ ] ನಾವು ಪ್ರತಿ ತಪ್ಪನ್ನು ಪ್ರಯತ್ನಿಸಬಾರದು ಎಂದು ನನಗೆ ತಿಳಿದಿದೆ.
• [ ] ಕಚ್ಚಾ ದೋಷದ ಬದಲಿಗೆ, ನಾನು ಬಳಕೆದಾರರಿಗೆ ಶಾಂತವಾದ, ಕ್ರಿಯೆ-ಆಧಾರಿತ ಸಂದೇಶವನ್ನು ತೋರಿಸಬಹುದು.