ಎಲ್ಲರಿಗೂ real-time ಅಪ್ಡೇಟ್ಗಳು ಬೇಕೆನಿಸುತ್ತದೆ, ಆದರೆ "ವೇಗ" ಮತ್ತು "ಸರಿಯಾದದ್ದು" ಒಂದೇ ಅಲ್ಲ ಎಂಬುದು ತಿಳಿಯುವವರೆಗೂ. ಒಂದು distributed system ನಲ್ಲಿ, ಘಟನೆಗಳು (events) ಬೆಳಕಿನ ವೇಗದಲ್ಲಿ ಚಲಿಸಿದರೂ ಸಹ ತಪ್ಪು ಕ್ರಮದಲ್ಲಿ ಬರಬಹುದು. WebSockets ಕಡಿತಗೊಳ್ಳಬಹುದು ಮತ್ತು ಮರುಸಂಪರ್ಕಗೊಳ್ಳಬಹುದು. Message brokers ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮರು-ವಿತರಿಸಬಹುದು. Background workers ಟೈಮೌಟ್ ರದ್ದತಿಗಳ ವಿರುದ್ಧ ಸ್ಪರ್ಧಿಸುತ್ತವೆ. ಇದರ ಪರಿಣಾಮವೇನು? ಕ್ಲೈಂಟ್ ಘಟನೆ 42 ಅನ್ನು ನೋಡಬಹುದು, ನಂತರ ಘಟನೆ 40 ಅನ್ನು, ನಂತರ ಸಿಸ್ಟಮ್ ಈಗಾಗಲೇ ಘಟನೆ 45 ರಲ್ಲಿ ಇದೆ ಎಂದು ಹೇಳುವ ಒಂದು snapshot ಅನ್ನು ನೋಡಬಹುದು. ನೀವು ದೀರ್ಘಾವಧಿಯ ಏಜೆಂಟ್ ವರ್ಕ್ಫ್ಲೋಗಳನ್ನು (agent workflows) ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ಆ ಗೊಂದಲವು ಕೇವಲ ಒಂದು edge case ಅಲ್ಲ. ಅದು ಮೂಲಭೂತ ಸತ್ಯ. ವಿತರಣೆಯ ಸಮಯವನ್ನು ಮಿಲಿಸೆಕೆಂಡ್ಗಳಷ್ಟು ಕಡಿಮೆ ಮಾಡುವ ಬಗ್ಗೆ ಚಿಂತಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಘಟನೆಗಳ ಕ್ರಮವನ್ನು ಸರಿಪಡಿಸಿ.
"Real-Time" ನ ಗೊಂದಲಮಯ ವಾಸ್ತವ
Real-time ಎಂಬುದು ಒಂದು transport property. ಅದು ಒಂದು ಪ್ಯಾಕೆಟ್ ವೈರ್ ಮೂಲಕ ಎಷ್ಟು ವೇಗವಾಗಿ ಚಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆಯೇ ಹೊರತು, ಅದು ಹೇಳುವ ಕಥೆ ಅರ್ಥಪೂರ್ಣವಾಗಿದೆಯೇ ಎಂಬುದನ್ನಲ್ಲ. ದೀರ್ಘಾವಧಿಯ ಕಾರ್ಯಗಳು ಪ್ರತಿಯೊಂದು ಅಸಂಗತತೆಯನ್ನು (inconsistency) ಹೆಚ್ಚಿಸುತ್ತವೆ ಏಕೆಂದರೆ ಅವು ಸಮಯದ ಉದ್ದಕ್ಕೂ ವಿಸ್ತರಿಸುತ್ತವೆ. ಮಾಡೆಲ್ ತರಬೇತಿ ಕೆಲಸ (model training job), ಬಹು-ಹಂತದ ಅನುಮೋದನಾ ಪ್ರಕ್ರಿಯೆ (multi-step approval flow), ಅಥವಾ ವಿಡಿಯೋ ರೆಂಡರಿಂಗ್ ಪೈಪ್ಲೈನ್ವು ನಿಮಿಷों ಅಥವಾ ಗಂಟೆಗಳ ಕಾಲ ಡಜನ್ಗಟ್ಟಲೆ ಘಟನೆಗಳನ್ನು ಹೊರಸೂಸಬಹುದು. ಆ ಅವಧಿಯಲ್ಲಿ, ಏನೂ ತಪ್ಪಾಗಬಹುದು.
ಒಂದು ಬ್ರೋಕರ್ ಅಕ್ನಾಲೆಡ್ಜ್ಮೆಂಟ್ (acknowledgement) ಕಳೆದುಹೋದರೆ ಸಂದೇಶವನ್ನು ಮರುಪ್ರಯತ್ನಿಸಬಹುದು. ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಎರಡು ಘಟನೆಗಳನ್ನು ವಿಭಿನ್ನ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗಗಳ ಮೂಲಕ ಕಳುಹಿಸಬಹುದು, ಇದರಿಂದ ಹೊಸದಾದ ಘಟನೆಯು ಮೊದಲು ತಲುಪಬಹುದು. ಒಂದು ವರ್ಕರ್ ಪ್ರಕ್ರಿಯೆಯು ಡೇಟಾಬೇಸ್ಗೆ ಬರೆದ ನಂತರ ಆದರೆ ಯಶಸ್ಸಿನ ಘಟನೆಯನ್ನು ಪ್ರಕಟಿಸುವ ಮೊದಲು ಸ್ಥಗಿತಗೊಳ್ಳಬಹುದು, ನಂತರ ಎರಡನೇ ವರ್ಕರ್ ಆ ಕಾರ್ಯವನ್ನು ಪಡೆದು ತನ್ನದೇ ಆದ ಪ್ರಗತಿಯನ್ನು ಹೊರಸೂಸಬಹುದು. ನಿಮ್ಮ ಫ್ರಂಟ್ಎಂಡ್ ಅತಿ ಕಡೆಯ ಸಂದೇಶವೇ ಅತ್ಯಂತ ನಿಖರವಾದ ಸಂದೇಶ ಎಂದು ಭಾವಿಸಿದರೆ, ಅದು ಎಂದಿಗೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಸ್ಥಿತಿಯನ್ನು (state) ತೋರಿಸುತ್ತದೆ. ಬಳಕೆದಾರರು "completed" ಎಂಬ ಬ್ಯಾಡ್ಜ್ "processing" ಎಂದು ಬದಲಾಗುವುದನ್ನು ನೋಡಬಹುದು, ಅಥವಾ ಅದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ, ರದ್ದಾದ ಕಾರ್ಯವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಮತ್ತೆ ಜೀವಂತವಾಗುವುದನ್ನು ನೋಡಬಹುದು. ಕ್ರಮವಿಲ್ಲದ ವೇಗವು ಕೇವಲ ಹೆಚ್ಚಿನ ಫ್ರೇಮ್ ರೇಟ್ನಲ್ಲಿರುವ ಗೊಂದಲವಷ್ಟೇ.
ಸೀಕ್ವೆನ್ಸ್ ನಂಬರ್ಗಳೇ ನಿಜವಾದ ಗಡಿಯಾರ
ಇದಕ್ಕೆ ಪರಿಹಾರವೆಂದರೆ ಪ್ರೊಡ್ಯೂಸರ್ನಿಂದ ಉತ್ಪಾದಿತ ಕಟ್ಟುನಿಟ್ಟಾದ, monotonic sequence numbers. ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಾಚರಣೆಯು ಯಾವುದೇ ಅಂತರ ಅಥವಾ ಹಿನ್ನಡೆಯಿಲ್ಲದೆ (no gaps and no rollbacks), ನಿಖರವಾಗಿ ಒಂದ씩 ಹೆಚ್ಚಾಗುವ ಸಂಖ್ಯೆಯನ್ನು ಪಡೆಯುತ್ತದೆ. ಆ ಸಂಖ್ಯೆಯು ಘಟನೆಯಂತೆಯೇ ಅದೇ ಟ್ರಾನ್ಸಾಕ್ಷನ್ನಲ್ಲಿ ಉಳಿಸಲ್ಪಟ್ಟಿರಬೇಕು (persisted). ಡೇಟಾಬೇಸ್ ಸಾಲು ಅಪ್ಡೇಟ್ ಆದರೆ ಸೀಕ್ವೆನ್ಸ್ ಕಮಿಟ್ ವಿಫಲವಾದರೆ, ನೀವು ಎರಡನ್ನೂ ರದ್ದುಗೊಳಿಸಬೇಕು (roll back). ಇದು ತಾರ್ಕಿಕ ಕಾಲಾನುಕ್ರಮವನ್ನು (logical timeline) ಸ್ಥಿತಿ ಬದಲಾವಣೆಯೊಂದಿಗೆ ಅಟಾಮಿಕ್ ಆಗಿಡುತ್ತದೆ.
ಇವೆಂಟ್ ಐಡಿಗಳು (Event IDs) ಇನ್ನೂ ಉಪಯುಕ್ತವಾಗಿವೆ, ಆದರೆ ಅವು ಬೇರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ಇವೆಂಟ್ ಐಡಿಯು ನಿರ್ದಿಷ್ಟ ಪೇಲೋಡ್ ಅನ್ನು ಗುರುತಿಸುತ್ತದೆ ಇದರಿಂದ ಬ್ರೋಕರ್ ಒಂದೇ ಸಂದೇಶವನ್ನು ಎರಡು ಬಾರಿ ವಿತರಿಸಿದಾಗ ನೀವು ಅದನ್ನು ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಮಾಡಬಹುದು (deduplicate). ಆದರೆ, ಸೀಕ್ವೆನ್ಸ್ ನಂಬರ್ ಆ ಪೇಲೋಡ್ ಕಾರ್ಯದ ಸರಪಳಿಯಲ್ಲಿ (causal chain) ಎಲ್ಲಿ ಬರುತ್ತದೆ ಎಂದು ತಿಳಿಸುತ್ತದೆ. ಇದು ಅಂತರಗಳನ್ನು (gaps) ಮತ್ತು ಕ್ರಮವನ್ನು (ordering) ಎತ್ತಿ ತೋರಿಸುತ್ತದೆ. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ (Timestamp) ಇವೆರಡನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ಗಡಿಯಾರಗಳು ವಿಚಲಿತಗೊಳ್ಳುತ್ತವೆ (drift), NTP ಹಿಂದಕ್ಕೆ ಹೋಗಬಹುದು ಮತ್ತು ವರ್ಚುವಲ್ ಮೆಷಿನ್ಗಳು ಸ್ಥಗಿತಗೊಳ್ಳಬಹುದು. ಟೈಮ್ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಕೇವಲ ಪ್ರದರ್ಶನದ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಮಾತ್ರ ಬಳಸಿ, ಉದಾಹರಣೆಗೆ "3 ನಿಮಿಷಗಳ ಹಿಂದೆ ಪ್ರಾರಂಭವಾಯಿತು" ಎಂಬಂತಹವುಗಳಿಗಾಗಿ ಬಳಸಿ, ಆದರೆ ಎಂದಿಗೂ ಬಿಸಿನೆಸ್ ಲಾಜಿಕ್ನ ಸಾರ್ಟಿಂಗ್ ಕೀ ಆಗಿ ಬಳಸಬೇಡಿ.
ಕ್ಲೈಂಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕು
ಪ್ರೊಡ್ಯೂಸರ್ ಒಂದು monotonic sequence ಅನ್ನು ಖಾತರಿಪಡಿಸಿದ ನಂತರ, ಕನ್ಸ್ಯೂಮರ್ಗೆ ಸರಳವಾದ, ಕಠಿಣ ನಿಯಮಗಳು ಸಿಗುತ್ತವೆ. ಒಳಬರುವ ಸೀಕ್ವೆನ್ಸ್ ಸಂಖ್ಯೆಯು ಕೊನೆಯ ಅನ್ವಯಿಸಿದ ಸಂಖ್ಯೆಗಿಂತ ಕಡಿಮೆ ಅಥವಾ ಸಮನಾಗಿದ್ದರೆ, ಅದನ್ನು ಬಿಟ್ಟುಬಿಡಿ (drop). ಅದು ಡ್ಯೂಪ್ಲಿಕೇಟ್ ಆಗಿರಬಹುದು ಅಥವಾ ಹಳೆಯದಾಗಿರಬಹುದು. ಸೀಕ್ವೆನ್ಸ್ ಸಂಖ್ಯೆಯು ಕೊನೆಯ ಅನ್ವಯಿಸಿದ ಸಂಖ್ಯೆಗಿಂತ ನಿಖರವಾಗಿ ಒಂದನ್ನು ಹೆಚ್ಚಿದ್ದರೆ, ಅದನ್ನು ತಕ್ಷಣವೇ ಅನ್ವಯಿಸಿ. ಅದು ಸುಗಮ ಹಾದಿ (happy path). ಸೀಕ್ವೆನ್ಸ್ ಸಂಖ್ಯೆಯು ಮುಂದಕ್ಕೆ ಜಿಗಿದರೆ, ಉದಾಹರಣೆಗೆ ನೀವು 12 ಅನ್ನು ನಿರೀಕ್ಷಿಸಿದ್ದೀರಿ ಆದರೆ 15 ಅನ್ನು ಪಡೆದರೆ, ಏನೋ ಒಂದು ಕಾಣೆಯಾಗಿದೆ ಎಂದರ್ಥ. ಹೊಸ ಘಟನೆಯನ್ನು ಬಫರ್ (buffer) ಮಾಡಿ ಮತ್ತು ಮುಂದಿನ ನಿರೀಕ್ಷಿತ ಸೀಕ್ವೆನ್ಸ್ನಿಂದ ಮರುಪ್ರತಿಲಿಪಿಗಾಗಿ (replay) ಸರ್ವರ್ ಅನ್ನು ಕೇಳಿ. ಊಹಿಸಬೇಡಿ. ಅಂತರವು ಮುಖ್ಯವಲ್ಲ ಎಂದು ಭಾವಿಸಿ ಮುಂದಕ್ಕೆ ಹೋಗಬೇಡಿ.
Terminal statesಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗದವುಗಳೆಂದು ಪರಿಗಣಿಸಬೇಕು. ಒಂದು ಕಾರ್ಯವನ್ನು completed, failed, ಅಥವಾ cancelled ಎಂದು ಗುರುತಿಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್ ಆ ಕಾರ್ಯಾಚರಣೆಯ ನಂತರದ ಯಾವುದೇ ಸ್ಥಿತಿ ಬದಲಾವಣೆಗಳನ್ನು ತಿರಸ್ಕರಿಸಬೇಕು. ಇದು ಕೇಳಲು ಸರಳವೆನಿಸಬಹುದು, ಆದರೆ ನೀವು ವ್ಯವಹರಿಸುವವರೆಗೆ