ಹೆಚ್ಚಿನ Node.js ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಅನ್ನು (error handling) ಕೇವಲ ಒಂದು ನಂತರದ ಕೆಲಸದಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ. ನೀವು ಒಂದು ರೂಟ್ ಹ್ಯಾಂಡ್ಲರ್ ಅನ್ನು try/catch ಬ್ಲಾಕ್ನಲ್ಲಿ ಸುತ್ತುವರಿಯುತ್ತೀರಿ, ಸ್ಟ್ಯಾಕ್ ಟ್ರೇಸ್ ಅನ್ನು ಲಾಗ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು 500 ರಿಸಪಾನ್ಸ್ ನೀಡುತ್ತೀರಿ. ಈ ಮನೋಭಾವ ಉಳಿದಿರುವುದು ಏಕೆಂದರೆ HTTP ರಿಕ್ವೆಸ್ಟ್ನ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಒಬ್ಬ ವ್ಯಕ್ತಿ ಕಾಯುತ್ತಿರುತ್ತಾನೆ. ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ಜಾಬ್ಗಳು (Background jobs) ವಿಭಿನ್ನವಾಗಿವೆ. ಕ್ಯೂ ಸಿಸ್ಟಮ್ನಲ್ಲಿ (queue system), ಉತ್ತರಿಸಲು ಅವಸರವಿರುವ ಕ್ಲೈಂಟ್ ಇಲ್ಲ, ಆಟೋಮ್ಯಾಟಿಕ್ ಬ್ರೌಸರ್ ರಿಫ್ರೆಶ್ ಕೂಡ ಇಲ್ಲ. ಅಲ್ಲಿ ಕೇವಲ ಒಬ್ಬ ವರ್ಕರ್ (worker), ಒಂದು ಪೇಲೋಡ್ (payload) ಮತ್ತು ಮೌನವಾಗಿ ಏರುತ್ತಿರುವ ರಿಟ್ರೈ ಕೌಂಟರ್ (retry counter) ಮಾತ್ರ ಇರುತ್ತದೆ. ತಪ್ಪುಗಳು ಸಂಭವಿಸಿದಾಗ, ಅವು ಮೊದಲು ನಿಧಾನವಾಗಿ, ನಂತರ ಒಮ್ಮೆಗೆ ಎಲ್ಲವೂ ತಪ್ಪಾಗುತ್ತವೆ. ಒಂದು ತಪ್ಪಾಗಿ ವರ್ಗೀಕರಿಸಿದ ಎರರ್ ಇಡೀ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು ಅಥವಾ ಮುಂಜಾನೆ ಮೂರು ಗಂಟೆಗೆ ಇಂಜಿನಿಯರ್ಗೆ ಅಲರ್ಟ್ ನೀಡಬಹುದು.
ಈ ವ್ಯತ್ಯಾಸ ಸರಳವಾಗಿದೆ. ರಿಕ್ವೆಸ್ಟ್-ರಿಸಪಾನ್ಸ್ ಸೈಕಲ್ಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ವಿಫಲವಾಗುತ್ತವೆ. ಕ್ಯೂ ವಿಫಲತೆಯು (queue failure) ಮೌನವಾಗಿರುತ್ತದೆ. ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಕಟ್ ಆಗುವ ಮೊದಲು ವರ್ಕರ್ ನೂರಾರು ಜಾಬ್ಗಳನ್ನು ಪೂರ್ಣಗೊಳಿಸಬಹುದು. ಸ್ಪಷ್ಟವಾದ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ನಿಯಮಗಳಿಲ್ಲದೆ, ವರ್ಕರ್ ತಕ್ಷಣವೇ ರಿಟ್ರೈ ಮಾಡುತ್ತದೆ, ಈಗಾಗಲೇ ಕಷ್ಟಪಡುತ್ತಿರುವ ಡೇಟಾಬೇಸ್ಗೆ ಹೆಚ್ಚಿನ ಒತ್ತಡ ಹೇರುತ್ತದೆ ಮತ್ತು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಯಾರೂ ವರ್ಕರ್ ಅನ್ನು ನೇರವಾಗಿ ಗಮನಿಸದ ಕಾರಣ, ತೊಂದರೆಯ ಮೊದಲ ಲಕ್ಷಣವು ಹೆಚ್ಚಾಗಿ ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ಬ್ಯಾಕಪ್ (cascading backup) ಅಥವಾ ಲಾಗ್ ಫೈಲ್ಗಳಿಂದ ತುಂಬಿದ ಡಿಸ್ಕ್ ಆಗಿರುತ್ತದೆ. ನಿಮಗೆ ಕೇವಲ catch ಬ್ಲಾಕ್ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದರ ಅಗತ್ಯವಿದೆ. ವಿಭಿನ್ನ ವಿಫಲತೆಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ಪರಿಗಣಿಸುವ ಮತ್ತು ಒಂದು ಕೆಟ್ಟ ಜಾಬ್ನಿಂದ ಇಡೀ ಸಿಸ್ಟಮ್ ಅನ್ನು ರಕ್ಷಿಸುವ ತಂತ್ರದ ಅಗತ್ಯವಿದೆ ನಿಮಗೆ.
Two Kinds of Failure
ಪ್ರತಿಯೊಂದು ಎರರ್ ಅನ್ನು ಎರಡು ವರ್ಗಗಳಾಗಿ ವಿಂಗಡಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ.
ರಿಟ್ರೈಯಬಲ್ ಎರರ್ಗಳು (Retryable errors) ತಾತ್ಕಾಲಿಕವಾಗಿರುತ್ತವೆ. ಥರ್ಡ್-ಪಾರ್ಟಿ API ಗೆ ನೆಟ್ವರ್ಕ್ ಟೈಮೌಟ್, 429 ರೇಟ್-ಲಿಮಿಟ್ ರಿಸಪಾನ್ಸ್ ಅಥವಾ ಪ್ರೈಮರಿ ಡೇಟಾಬೇಸ್ನಿಂದ ಹಿಂದೆ ಬಿದ್ದಿರುವ ತಾತ್ಕಾಲಿಕ ಡೇಟಾಬೇಸ್ ರೆಪ್ಲಿಕಾ ಇವುಗಳ ಉದಾಹರಣೆಗಳು. ಇವು ಒತ್ತಡದ ಲಕ್ಷಣಗಳೇ ಹೊರತು ಬಗ್ಗಳಲ್ಲ (bugs). ಸಿಸ್ಟಮ್ ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳಲ್ಲಿ ತನ್ನನ್ನು ತಾನು ಸರಿಪಡಿಸಿಕೊಳ್ಳಬಹುದು. ರಿಟ್ರೈಯಬಲ್ ಜಾಬ್ಗಳಿಗೆ ಮತ್ತೊಂದು ಅವಕಾಶ ನೀಡಬಹುದು, ಆದರೆ ಅದು ನಿಯಂತ್ರಿತ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಮಾತ್ರ ಇರಬೇಕು.
ಪರ್ಮನೆಂಟ್ ಎರರ್ಗಳು (Permanent errors) ತಪ್ಪುಗಳು. ಪೇಲೋಡ್ನಲ್ಲಿನ ಅಮಾನ್ಯ JSON, ಇಲ್ಲದ ಯೂಸರ್ ಐಡಿ, ಸ್ಟೋರೇಜ್ನಲ್ಲಿ ಇಲ್ಲದ ಅಗತ್ಯ ಫೈಲ್ ಇವುಗಳ ಉದಾಹರಣೆಗಳು. ಇವು ಮೊದಲ ಪ್ರಯತ್ನದಲ್ಲಿ ಹೇಗೆ ವಿಫಲವಾದವೋ, ನೂರನೇ ಪ್ರಯತ್ನದಲ್ಲೂ ಹಾಗೆಯೇ ವಿಫಲವಾಗುತ್ತವೆ. ಇವುಗಳನ್ನು ರಿಟ್ರೈ ಮಾಡುವುದು CPU ಸೈಕಲ್ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ, ಕ್ಯೂ ಸ್ಲಾಟ್ಗಳನ್ನು ಹಾಳು ಮಾಡುತ್ತದೆ ಮತ್ತು ಆರೋಗ್ಯಕರ ಜಾಬ್ಗಳನ್ನು ವಿಳಂಬಗೊಳಿಸುವ ಟಾಕ್ಸಿಕ್ ಬ್ಯಾಕ್-ಪ್ರೆಶರ್ (toxic back-pressure) ಅನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಪರ್ಮನೆಂಟ್ ಫೈಲ್ಯೂರ್ಗೆ ಉಪಯುಕ್ತವಾದ ಸ್ಥಳವೆಂದರೆ ಲಾಗ್, ಅಲರ್ಟ್ ಅಥವಾ ಡೆಡ್-ಲೆಟರ್ ಕ್ಯೂ (dead-letter queue). ಇದು ರಿಟ್ರೈ ಲೂಪ್ನಲ್ಲಿ ಇರಬಾರದು.
Build a Decision Engine
ತಕ್ಷಣವೇ ವರ್ಗೀಕರಿಸಿ. ಈ ನಿರ್ಧಾರವನ್ನು ಕ್ಯೂ ಫ್ರೇಮ್ವರ್ಕ್ಗೆ ಬಿಡಬೇಡಿ. ನೀವು ಎರರ್ ಅನ್ನು ಹಿಡಿದ ತಕ್ಷಣವೇ, ಅದರ ವಿಧವನ್ನು ನಿರ್ಧರಿಸಿ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಇದರರ್ಥ ವಿಫಲತೆಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಕಸ್ಟಮ್ ಎರರ್ ಕ್ಲಾಸ್ಗಳು ಅಥವಾ ವ್ಯಾಪರ್ ಫಂಕ್ಷನ್ಗಳನ್ನು (wrapper functions) ರಚಿಸುವುದು. ಡೇಟಾಬೇಸ್ ಡ್ರೈವರ್ ಕನೆಕ್ಷನ್ ರಿಸೆಟ್ (connection reset) ಎಸೆಯುತ್ತಿದ್ದರೆ, ನಿಮ್ಮ ಹ್ಯಾಂಡ್ಲರ್ ಅದನ್ನು ರಿಟ್ರೈಯಬಲ್ ಎಂದು ಟ್ಯಾಗ್ ಮಾಡಬೇಕು. ಪೇಲೋಡ್ ವ್ಯಾಲಿಡೇಟರ್ ಸ್ಕೀಮಾ ಮಿಸ್ಮ್ಯಾಚ್ (schema mismatch) ಎಸೆಯುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಪರ್ಮನೆಂಟ್ ಎಂದು ಟ್ಯಾಗ್ ಮಾಡಿ. ಅನೇಕ ಜಾಬ್ ಪ್ರೊಸೆಸರ್ಗಳು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಎಲ್ಲವನ್ನೂ ರಿಟ್ರೈ ಮಾಡುತ್ತವೆ, ಇದು ನೀವು ಮಾಡುವ ಅತ್ಯಂತ ದುಬಾರಿ ನಿರ್ಧಾರವಾಗಿದೆ. ಪರ್ಮನೆಂಟ್ ಜಾಬ್ಗಳನ್ನು ತಕ್ಷಣವೇ ತಿರಸ್ಕರಿಸಿ. ಅವುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡಿ ಅಥವಾ ಡೆಡ್-ಲೆಟರ್ ಕ್ಯೂಗೆ ರೌಟ್ ಮಾಡಿ, ಅಲ್ಲಿ ಅವು ಮುಖ್ಯ ಪೈಪ್ಲೈನ್ ಅನ್ನು ಹಾಳು ಮಾಡಲಾರವು. ಈ ಒಂದು ಅಭ್ಯಾಸವು ಯಾವುದೇ ಇನ್ಫ್ರಾಸ್ಟ್ರಕ್ಚರ್ ಬದಲಾವಣೆಗಿಂತ ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸ್ನೋಬಾಲ್ ಎಫೆಕ್ಟ್ಗಳನ್ನು (snowball effects) ತಡೆಯುತ್ತದೆ.
Back Off, But Smarter
ನೀವು ರಿಟ್ರೈ ಮಾಡುವಾಗ, ಎಂದಿಗೂ ತಕ್ಷಣವೇ ಮಾಡಬೇಡಿ. ಡೇಟಾಬೇಸ್ ಡೌನ್ ಆಗಿದ್ದರೆ, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೂ ವರ್ಕರ್ಸ್ಗಳು ಅದರ ಮೇಲೆ ದಾಳಿ ಮಾಡುವುದು ಒಳಗಿನಿಂದಲೇ 'ಡಿನೈಯಲ್-ಆಫ್-ಸರ್ವಿಸ್' (denial-of-service) ದಾಳಿಯಂತೆ ಕಾಣುತ್ತದೆ. ಎಕ್ಸ್ಪೊನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕಫ್ (exponential backoff) ಬಳಸಿ. ಒಂದು ನಿಮಿಷ, ನಂತರ ಐದು, ನಂತರ ಹದಿನೈದು ನಿಮಿಷ ಕಾಯಿರಿ. ಅಪ್ಸ್ಟ್ರೀಮ್ ಸಿಸ್ಟಮ್ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸಮಯ ನೀಡಿ.
ಆದರೆ ಕೇವಲ ಎಕ್ಸ್ಪೊನೆನ್ಶಿಯಲ್ ಬ್ಯಾಕಫ್ ಸಾಕಾಗುವುದಿಲ್ಲ. ಒಂದು ಸರ್ವಿಸ್ ರೀಸ್ಟಾರ್ಟ್ ಆದ ಕಾರಣ ಸಾವಿರಾರು ಜಾಬ್ಗಳು ಏಕಕಾಲದಲ್ಲಿ ವಿಫಲವಾದರೆ, ಅವುಗಳ ರಿಟ್ರೈ ವೇಳಾಪಟ್ಟಿಗಳು ಒಂದೇ ಆಗಿರುತ್ತವೆ. ಸರ್ವಿಸ್ ಆನ್ಲೈನ್ ಬಂದಾಗ ಅವು ಏಕಕಾಲದಲ್ಲಿ ಆ ಸರ್ವಿಸ್ ಮೇಲೆ ದಾಳಿ ಮಾಡುತ್ತವೆ, ಇದು ಅದನ್ನು ಮತ್ತೆ ಡೌನ್ ಮಾಡಬಹುದು. ಜಿಟ್ಟರ್ (jitter) ಸೇರಿಸಿ: ಪ್ರತಿ ವಿಳಂಬಕ್ಕೆ ಒಂದು ಸಣ್ಣ ರ್ಯಾಂಡಮ್ ಆಫೆಟ್ (random offset) ನೀಡಿ. ರಿಟ್ರೈಗಳನ್ನು ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಡುವೆ ಹರಡುವುದರಿಂದ ಸಿಂಕ್ರೊನೈಸ್ಡ್ ಸ್ಟ್ಯಾಂಪೀಡ್ಗಳನ್ನು (synchronized stampedes) ತಡೆಯಬಹುದು. ಗಣಿತ ಸರಳವಾಗಿದೆ, ಆದರೆ ಅದು ನೀಡುವ ಸ್ಥಿರತೆ ಅಪಾರವಾಗಿದೆ.
Preserve the Evidence
ಡೆಡ್-ಲೆಟರ್ ಕ್ಯೂ (DLQ) ಎಂಬುದು ನಿಮ್ಮ ಆಡಿಟ್ ಟ್ರೈಲ್ (audit trail), ಕಸದ ಬುಟ್ಟಿ ಅಲ್ಲ. ಒಂದು ಜಾಬ್ ತನ್ನ ಕೊನೆಯ ರಿಟ್ರೈಯನ್ನು ಮುಗಿಸಿದಾಗ, ಅದನ್ನು ಸುಮ್ಮನೆ ಡಿಲೀಟ್ ಮಾಡಬೇಡಿ. ಪೇಲೋಡ್, ಎರರ್ ಕಾನ್ಟೆಕ್ಸ್ ಮತ್ತು ರಿಟ್ರೈ ಇತಿಹಾಸದೊಂದಿಗೆ ಇಡೀ ಪೇಲೋಡ್ ಅನ್ನು DLQ ಗೆ ವರ್ಗಾಯಿಸಿ.
ಇದು ಸಾಕ್ಷ್ಯಗಳನ್ನು ಉಳಿಸುತ್ತದೆ. ಒಬ್ಬ ಮನುಷ್ಯ ಜಾಬ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸಬಹುದು ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಅದನ್ನು ಮ್ಯಾನುಯಲ್ ಆಗಿ ರಿಪ್ಲೇ ಮಾಡಬಹುದು. ಮುಖ್ಯವಾಗಿ, ನಿಮ್ಮ DLQ ನ ಆಳವನ್ನು (depth) ಗಮನಿಸಿ. ಡೆಡ್-ಲೆಟರ್ ಜಾಬ್ಗಳಲ್ಲಿನ ಹಠಾತ್ ಏರಿಕೆಯು ಕೆಟ್ಟ ಡಿಪ್ಲಾಯ್ (bad deploy), ತಪ್ಪಾದ ಸ್ಕೀಮಾ ಬದಲಾವಣೆ ಅಥವಾ ಬಾಹ್ಯ ವೆಂಡರ್ ಒಪ್ಪಂದವನ್ನು ಉಲ್ಲಂಘಿಸಿರುವುದಕ್ಕೆ ಮೊದಲ ಎಚ್ಚರಿಕೆಯಾಗಿರುತ್ತದೆ. DLQ ಬೆಳವಣಿಗೆಯನ್ನು ಲೀಡಿಂಗ್ ಇಂಡಿಕೇಟರ್ (leading indicator) ಆಗಿ ಪರಿಗಣಿಸಿ, ಟ್ರೈಲಿಂಗ್ ಇಂಡಿಕೇಟರ್ ಆಗಿಯಲ್ಲ. ನಿಮ್ಮ DLQ ತುಂಬುತ್ತಿದ್ದರೆ, ಅಪ್ಸ್ಟ್ರೀಮ್ನಲ್ಲಿ ಏನೋ ಬದಲಾಗಿದೆ ಮತ್ತು ಬ್ಯಾಕ್ಲಾಗ್ ಹರಡುವ ಮೊದಲು ನಿಮ್ಮ ತಂಡಕ್ಕೆ ತಿಳಿಯಬೇಕಾಗುತ್ತದೆ.
Design for the Retry
ಪ್ರತಿಯೊಂದು ಕೆಲಸವನ್ನೂ (job) ಅದು ಎರಡು ಬಾರಿ ಕಾರ್ಯಗತಗೊಳ್ಳಬಹುದು ಎಂಬಂತೆ ವಿನ್ಯಾಸಗೊಳಿಸಿ, ಏಕೆಂದರೆ ಅದು ನಿಜವಾಗಿಯೂ ಆಗಬಹುದು. ಒಂದು ವರ್ಕರ್ ಪ್ರಕ್ರಿಯೆಯ ಮಧ್ಯದಲ್ಲಿ ವಿಫಲವಾಗಿ, ಮರು-ನಿಗದಿತವಾಗಿ (rescheduled), ಮತ್ತೆ ಕಾರ್ಯಗತಗೊಳ್ಳಬಹುದು. ನಿಮ್ಮ ಕೆಲಸವು ಗ್ರಾಹಕರಿಂದ ಹಣ ಪಡೆಯುವಾಗ, ಇಮೇಲ್ ಕಳುಹಿಸುವಾಗ ಅಥವಾ ಇನ್ವೆಂಟರಿ ಎಣಿಕೆಯನ್ನು ಹೆಚ್ಚಿಸುವಾಗ, ಕೇವಲ ಸರಳವಾದ ಮರುಪ್ರಯತ್ನವು (naive retry) ಡ್ಯುಪ್ಲಿಕೇಟ್ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.
ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ 'idempotency'. ನೀವು ಯಾವುದಾದರೂ side effect ಅನ್ನು ಮಾಡುವ ಮೊದಲು, ಅದು ಈಗಾಗಲೇ ಆಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. job payload ನಿಂದ ಒಂದು unique identifier ಅನ್ನು idempotency key ಆಗಿ ಬಳಸಿ. ಆ ಕೀಯನ್ನು short-lived cache ಅಥವಾ uniqueness constraint ಇರುವ database table ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಒಂದು ವೇಳೆ ಆ ಕೀ ಈಗಾಗಲೇ ಇದ್ದರೆ, ಕೆಲಸವನ್ನು ಬಿಟ್ಟುಬಿಡಿ ಮತ್ತು success ಎಂದು ವಾಪಸ್ ಕಳುಹಿಸಿ. ಇದು ಮರುಪ್ರಯತ್ನಗಳನ್ನು (retries) ಅಪಾಯದಿಂದ ಹಾನಿಕಾರಕವಲ್ಲದ no-op ಆಗಿ ಬದಲಾಯಿಸುತ್ತದೆ. ಇದಕ್ಕೆ ಕೆಲವು ಹೆಚ್ಚುವರಿ ಸಾಲುಗಳ ಕೋಡ್ ಬೇಕಾಗಬಹುದು, ಆದರೆ ರಾತ್ರೋರಾತ್ರಿ ಆದಾಯವು ಹೇಗೆ ದ್ವಿಗುಣಗೊಂಡಿತು ಎಂದು ಹಣಕಾಸು ವಿಭಾಗಕ್ಕೆ (finance) ವಿವರಿಸುವ ಅವಶ್ಯಕತೆಯಿಂದ ಇದು ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸುತ್ತದೆ.
ಪ್ರಕ್ರಿಯೆಯನ್ನು ರಕ್ಷಿಸಿ
Unbounded promise rejections ಮತ್ತು stray exceptionsಗಳು ಎಚ್ಚರಿಕೆಯಿಲ್ಲದೆ Node.js ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲಬಹುದು. ವರ್ಕರ್ನಲ್ಲಿ, ಇದರರ್ಥ ಕೆಲಸಗಳು ಕೈಬಿಡಲ್ಪಡುತ್ತವೆ ಮತ್ತು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಹರಸಾಹಸ ಪಡಬೇಕಾಗುತ್ತದೆ.
unhandledRejection ಮತ್ತು uncaughtException ಗಾಗಿ ಗ್ಲೋಬಲ್ ಹ್ಯಾಂಡ್ಲರ್ಗಳನ್ನು ನೋಂದಾಯಿಸಿ. ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ರಕ್ಷಿಸುವುದು ಅವುಗಳ ಕೆಲಸವಲ್ಲ. ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಕ್ಲೀನಪ್ ಅನ್ನು ಮಾಡಿ, ನಂತರ ಹೊರಬರುವುದು (exit) ಅವುಗಳ ಕೆಲಸ. Docker, Kubernetes ಅಥವಾ systemd ಮೂಲಕ ವರ್ಕರ್ ಅನ್ನು ಸ್ವಚ್ಛವಾದ ಮೆಮೊರಿ ಸ್ಟೇಟ್ನೊಂದಿಗೆ ಮರುಪ್ರಾರಂಭಿಸಲು ಬಿಡಿ. ಗ್ಲೋಬಲ್ ಹ್ಯಾಂಡ್ಲರ್ ಕಾರ್ಯಗತಗೊಂಡ ನಂತರವೂ ಅರೆಬರೆ ಸ್ಥಿತಿಯಲ್ಲಿ ಮುಂದುವರಿಯುವುದು ಮೆಮೊರಿ ಲೀಕ್ ಮತ್ತು ಹಾಳಾದ ಸ್ಥಿತಿಗೆ (corrupted state) ಕಾರಣವಾಗಬಹುದು. ಕೆಲಸಗಳನ್ನು ತಪ್ಪಾಗಿ ನಿರ್ವಹಿಸುವ ನಿಧಾನಗತಿಯ 'zombie process' ಗಿಂತ, ವೇಗವಾದ ಮತ್ತು ಸ್ವಚ್ಛವಾದ ಅಂತ್ಯವೇ ಸುರಕ್ಷಿತ. ನಿಮ್ಮ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಿಮ್ಮನ್ನು ಮರಳಿ ತರುತ್ತದೆ ಎಂದು ನಂಬಿ; ಹಾಳಾದ ರನ್-ಟೈಮ್ ಅನ್ನು ಸರಿಪಡಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಡಿ.
ಸಿಗ್ನಲ್ಗಳಿಗೆ ಗೌರವ ನೀಡಿ
ಡಿಸ್ಪ್ಲಾಯ್ಮೆಂಟ್ಗಳು, ಸ್ಕೇಲಿಂಗ್ ಇವೆಂಟ್ಗಳು ಮತ್ತು ನೋಡ್ ರೊಟೇಶನ್ಗಳ ಸಮಯದಲ್ಲಿ ವರ್ಕರ್ಸ್ಗಳನ್ನು ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ. ನಿಮ್ಮ ಪ್ರಕ್ರಿಯೆಯು SIGTERM ಅನ್ನು ತಕ್ಷಣವೇ ಸ್ವೀಕರಿಸಿದಾಗ ಸ್ಥಗಿತಗೊಂಡರೆ, ಚಾಲನೆಯಲ್ಲಿರುವ (in flight) ಯಾವುದೇ ಕೆಲಸವನ್ನು ನೀವು ಅರ್ಧಕ್ಕೆ ನಿಲ್ಲಿಸುತ್ತೀರಿ. ಆ ಕೆಲಸವು ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳ್ಳದಿರಬಹುದು ಮತ್ತು ಅದರ ಮರುಪ್ರಯತ್ನದ ಎಣಿಕೆ (retry counter) ಇನ್ನೂ ಹೆಚ್ಚಾಗಿರಲಿಕ್ಕಿಲ್ಲ.
SIGTERM ಮತ್ತು SIGINT ಗೆ ಕಿವಿಕೊಡಿ (Listen). ಸಿಗ್ನಲ್ ಬಂದಾಗ, ಕ್ಯೂ (queue) ನಿಂದ ಹೊಸ ಕೆಲಸಗಳನ್ನು ಪಡೆಯುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಸಾಧ್ಯವಾದರೆ ಪ್ರಸ್ತುತ ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಿ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಮಿತಿ (hard timeout), ಬಹುಶಃ ಮೂವತ್ತು ಸೆಕೆಂಡುಗಳನ್ನು ನಿಗದಿಪಡಿಸಿ, ಅದರ ನಂತರ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲೂ ಹೊರಬನ್ನಿ. ಈ 'graceful shutdown' ಕ್ಯೂಗೆ ಗೌರವ ನೀಡುತ್ತದೆ ಮತ್ತು ತಪ್ಪು ವೈಫಲ್ಯಗಳನ್ನು (false failures) ತಪ್ಪಿಸುತ್ತದೆ. ನಿಮ್ಮ ಡಿಸ್ಪ್ಲಾಯ್ಮೆಂಟ್ ಪೈಪ್ಲೈನ್ ಸ್ವಚ್ಛವಾಗಿ ಹೊರಬರುವ ವರ್ಕರ್ ಅನ್ನು 'healthy' ಎಂದು ಪರಿಗಣಿಸಬೇಕು, ಆದರೆ ಕ್ರ್ಯಾಶ್ ಆದ ವರ್ಕರ್ ಅಲರ್ಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸಬೇಕು.
ನಿಜವಾದ ಸಾರಾಂಶ
ನಂಬಿಕಾರ್ಹ ಕ್ಯೂ ನಿರ್ವಹಣೆ ಎಂದರೆ ಪ್ರತಿಯೊಂದು ದೋಷವನ್ನು ಹಿಡಿಯುವುದಲ್ಲ. ಇದು ಪ್ರತಿ ವೈಫಲ್ಯದ ವಿಧಾನಕ್ಕೆ (failure mode) ಉದ್ದೇಶಪೂರ್ವಕ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಾಗಿದೆ. ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯಗಳನ್ನು ತಾಳ್ಮೆಯಿಂದ ಮರುಪ್ರಯತ್ನಿಸಿ. ಖಾಯಂ ವೈಫಲ್ಯಗಳನ್ನು ಶೀಘ್ರವಾಗಿ ಬಗೆಹರಿಸಿ. ನಿಮ್ಮ ವರ್ಕರ್ಸ್ಗಳನ್ನು ಅತಿಯಾದ ಒತ್ತಡದಿಂದ (stampedes) ರಕ್ಷಿಸಿ, ಐಡೆಂಪೊಟೆನ್ಸಿ ಕೀಗಳೊಂದಿಗೆ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ರಕ್ಷಿಸಿ ಮತ್ತು ಅಂತ್ಯಗೊಳ್ಳುತ್ತಿರುವ ಪ್ರಕ್ರಿಯೆಗಳು ಸ್ವಚ್ಛವಾಗಿ ಹೊರಬರಲು ಬಿಡಿ. ಪ್ರತಿ ವೈಫಲ್ಯಕ್ಕೂ ಒಂದು ನಿರ್ದಿಷ್ಟ ಹಾದಿ ಇದ್ದಾಗ, ಮುಂಜಾನೆ ಮೂರು ಗಂಟೆಯೂ ಕೇವಲ ಸಾಮಾನ್ಯ ಸಮಯದಂತೆ ಭಾಸವಾಗುತ್ತದೆ. ನಿಮ್ಮ ಪೈಪ್ಲೈನ್ ಚಲಿಸುತ್ತಲೇ ಇರುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ತಂಡವು ನೆಮ್ಮದಿಯಿಂದ ನಿದ್ರಿಸುತ್ತದೆ.