ಕಾಫ್ಕಾದಿಂದ ಪಡೆದ ಈವೆಂಟ್‌ಗಳನ್ನು ಮರುಸಂಸ್ಕರಿಸುವುದು

ಹೇ ಹಬ್ರ್.

ಇತ್ತೀಚೆಗೆ ಐ ತಮ್ಮ ಅನುಭವ ಹಂಚಿಕೊಂಡರು ಕಾಫ್ಕಾ ನಿರ್ಮಾಪಕರು ಮತ್ತು ಗ್ರಾಹಕರು ಖಾತರಿಪಡಿಸಿದ ವಿತರಣೆಗೆ ಹತ್ತಿರವಾಗಲು ತಂಡವಾಗಿ ನಾವು ಯಾವ ನಿಯತಾಂಕಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು. ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯ ತಾತ್ಕಾಲಿಕ ಅಲಭ್ಯತೆಯ ಪರಿಣಾಮವಾಗಿ ಕಾಫ್ಕಾದಿಂದ ಸ್ವೀಕರಿಸಿದ ಈವೆಂಟ್‌ನ ಮರು-ಸಂಸ್ಕರಣೆಯನ್ನು ನಾವು ಹೇಗೆ ಆಯೋಜಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ.

ಆಧುನಿಕ ಅನ್ವಯಿಕೆಗಳು ಬಹಳ ಸಂಕೀರ್ಣ ವಾತಾವರಣದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಆಧುನಿಕ ತಂತ್ರಜ್ಞಾನದ ಸ್ಟ್ಯಾಕ್‌ನಲ್ಲಿ ಸುತ್ತುವ ವ್ಯಾಪಾರ ತರ್ಕ, ಕುಬರ್ನೆಟ್ಸ್ ಅಥವಾ ಓಪನ್‌ಶಿಫ್ಟ್‌ನಂತಹ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ನಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಡಾಕರ್ ಇಮೇಜ್‌ನಲ್ಲಿ ರನ್ ಆಗುತ್ತದೆ ಮತ್ತು ಭೌತಿಕ ಮತ್ತು ವರ್ಚುವಲ್ ರೂಟರ್‌ಗಳ ಸರಣಿಯ ಮೂಲಕ ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಅಥವಾ ಎಂಟರ್‌ಪ್ರೈಸ್ ಪರಿಹಾರಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಅಂತಹ ವಾತಾವರಣದಲ್ಲಿ, ಏನಾದರೂ ಯಾವಾಗಲೂ ಮುರಿಯಬಹುದು, ಆದ್ದರಿಂದ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಒಂದು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಈವೆಂಟ್‌ಗಳನ್ನು ಮರುಸಂಸ್ಕರಿಸುವುದು ನಮ್ಮ ವ್ಯವಹಾರ ಪ್ರಕ್ರಿಯೆಗಳ ಪ್ರಮುಖ ಭಾಗವಾಗಿದೆ.

ಕಾಫ್ಕಾ ಮೊದಲು ಹೇಗಿತ್ತು

ಹಿಂದಿನ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಅಸಮಕಾಲಿಕ ಸಂದೇಶ ವಿತರಣೆಗಾಗಿ IBM MQ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ. ಸೇವೆಯ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ದೋಷ ಸಂಭವಿಸಿದಲ್ಲಿ, ಸ್ವೀಕರಿಸಿದ ಸಂದೇಶವನ್ನು ಮತ್ತಷ್ಟು ಹಸ್ತಚಾಲಿತ ಪಾರ್ಸಿಂಗ್ಗಾಗಿ ಡೆಡ್-ಲೆಟರ್-ಕ್ಯೂ (DLQ) ನಲ್ಲಿ ಇರಿಸಬಹುದು. ಒಳಬರುವ ಸರದಿಯ ಪಕ್ಕದಲ್ಲಿ DLQ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ, ಸಂದೇಶವನ್ನು IBM MQ ಒಳಗೆ ವರ್ಗಾಯಿಸಲಾಯಿತು.

ದೋಷವು ತಾತ್ಕಾಲಿಕವಾಗಿದ್ದರೆ ಮತ್ತು ನಾವು ಅದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಸಾಧ್ಯವಾದರೆ (ಉದಾಹರಣೆಗೆ, HTTP ಕರೆಯಲ್ಲಿನ ResourceAccessException ಅಥವಾ MongoDb ವಿನಂತಿಯ ಮೇಲೆ MongoTimeoutException), ನಂತರ ಮರುಪ್ರಯತ್ನ ತಂತ್ರವು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಶಾಖೆಯ ತರ್ಕವನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ, ಮೂಲ ಸಂದೇಶವನ್ನು ವಿಳಂಬ ಕಳುಹಿಸುವಿಕೆಗಾಗಿ ಸಿಸ್ಟಮ್ ಕ್ಯೂಗೆ ಅಥವಾ ಸಂದೇಶಗಳನ್ನು ಮರುಕಳುಹಿಸಲು ಬಹಳ ಹಿಂದೆಯೇ ಮಾಡಿದ ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸರಿಸಲಾಗಿದೆ. ಇದು ವಿಳಂಬ ಮಧ್ಯಂತರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಕಾರ್ಯತಂತ್ರದ ಅಂತ್ಯಕ್ಕೆ ಸಂಬಂಧಿಸಿರುವ ಸಂದೇಶದ ಹೆಡರ್‌ನಲ್ಲಿ ಮರುಕಳುಹಿಸುವ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ನಾವು ಕಾರ್ಯತಂತ್ರದ ಅಂತ್ಯವನ್ನು ತಲುಪಿದ್ದರೂ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯು ಇನ್ನೂ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನಂತರ ಸಂದೇಶವನ್ನು ಹಸ್ತಚಾಲಿತ ಪಾರ್ಸಿಂಗ್‌ಗಾಗಿ DLQ ನಲ್ಲಿ ಇರಿಸಲಾಗುತ್ತದೆ.

ಪರಿಹಾರ ಹುಡುಕಾಟ

ಅಂತರ್ಜಾಲದಲ್ಲಿ ಹುಡುಕಲಾಗುತ್ತಿದೆ, ನೀವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಕಾಣಬಹುದು ಪುನಃ. ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಹೇಳುವುದಾದರೆ, ಪ್ರತಿ ವಿಳಂಬದ ಮಧ್ಯಂತರಕ್ಕೆ ವಿಷಯವನ್ನು ರಚಿಸಲು ಮತ್ತು ಬದಿಯಲ್ಲಿ ಗ್ರಾಹಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿದೆ, ಇದು ಅಗತ್ಯವಿರುವ ವಿಳಂಬದೊಂದಿಗೆ ಸಂದೇಶಗಳನ್ನು ಓದುತ್ತದೆ.

ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಕಾರಾತ್ಮಕ ವಿಮರ್ಶೆಗಳ ಹೊರತಾಗಿಯೂ, ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಯಶಸ್ವಿಯಾಗಲಿಲ್ಲ ಎಂದು ನನಗೆ ತೋರುತ್ತದೆ. ಮೊದಲನೆಯದಾಗಿ, ಏಕೆಂದರೆ ಡೆವಲಪರ್, ವ್ಯವಹಾರದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದರ ಜೊತೆಗೆ, ವಿವರಿಸಿದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾಗುತ್ತದೆ.

ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದರೆ, ನೀವು ವಿಷಯಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ಅವುಗಳಿಗೆ ಅಗತ್ಯವಾದ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲು ಸ್ವಲ್ಪ ಸಮಯವನ್ನು ಕಳೆಯಬೇಕಾಗುತ್ತದೆ. ಇದರ ಜೊತೆಗೆ, ನೀವು ಪ್ರತಿಯೊಂದು ಮರುಪ್ರಯತ್ನದ ವಿಷಯಗಳಿಗೆ ಸರಿಯಾದ retention.ms ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಬೇಕಾಗುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಸಂದೇಶಗಳನ್ನು ಮರುಕಳಿಸಲು ಸಮಯವಿರುತ್ತದೆ ಮತ್ತು ಅದರಿಂದ ಕಣ್ಮರೆಯಾಗುವುದಿಲ್ಲ. ಪ್ರತಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅಥವಾ ಹೊಸ ಸೇವೆಗಾಗಿ ಅನುಷ್ಠಾನ ಮತ್ತು ಪ್ರವೇಶದ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕಾಗುತ್ತದೆ.

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

ಸ್ಪ್ರಿಂಗ್-ಕಾಫ್ಕಾ ಸ್ವತಃ ContainerAwareErrorHandler ನ ಹಲವಾರು ಅಳವಡಿಕೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ, ಉದಾಹರಣೆಗೆ SeekToCurrentErrorHandler, ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸದೆಯೇ ನೀವು ನಂತರ ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ಸ್ಪ್ರಿಂಗ್-ಕಾಫ್ಕಾ 2.3 ಆವೃತ್ತಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಬ್ಯಾಕ್‌ಆಫ್ ಪಾಲಿಸಿಯನ್ನು ಹೊಂದಿಸಲು ಸಾಧ್ಯವಾಯಿತು.

ಈ ವಿಧಾನವು ಮರುಸಂಸ್ಕರಿಸಿದ ಸಂದೇಶಗಳನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಮರುಪ್ರಾರಂಭದಿಂದ ಬದುಕಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಇನ್ನೂ ಯಾವುದೇ DLQ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ. ನಾವು 2019 ರ ಆರಂಭದಲ್ಲಿ ಈ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇವೆ, DLQ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಆಶಾವಾದಿಯಾಗಿ ನಂಬಿದ್ದೇವೆ (ನಾವು ಅದೃಷ್ಟವಂತರು ಮತ್ತು ಅಂತಹ ಮರು ಸಂಸ್ಕರಣಾ ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸಿದ ಹಲವಾರು ತಿಂಗಳ ನಂತರ ಅದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿರಲಿಲ್ಲ). ತಾತ್ಕಾಲಿಕ ದೋಷಗಳು SeekToCurrentErrorHandler ಬೆಂಕಿಗೆ ಕಾರಣವಾಯಿತು. ಉಳಿದ ದೋಷಗಳನ್ನು ಲಾಗ್‌ನಲ್ಲಿ ಮುದ್ರಿಸಲಾಗಿದೆ, ಇದು ಆಫ್‌ಸೆಟ್‌ಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಸಂದೇಶದೊಂದಿಗೆ ಪ್ರಕ್ರಿಯೆಯು ಮುಂದುವರಿಯುತ್ತದೆ.

ಕೊನೆಯ ನಿರ್ಧಾರ

SeekToCurrentErrorHandler ಅನ್ನು ಆಧರಿಸಿದ ಅನುಷ್ಠಾನವು ಸಂದೇಶಗಳನ್ನು ಮರುಕಳುಹಿಸಲು ನಮ್ಮದೇ ಆದ ಕಾರ್ಯವಿಧಾನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ನಮ್ಮನ್ನು ಪ್ರೇರೇಪಿಸಿತು.

ಮೊದಲನೆಯದಾಗಿ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಅನುಭವವನ್ನು ಬಳಸಲು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ತರ್ಕವನ್ನು ಅವಲಂಬಿಸಿ ಅದನ್ನು ವಿಸ್ತರಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಲೀನಿಯರ್ ಲಾಜಿಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ, ಮರುಪ್ರಯತ್ನ ತಂತ್ರದಿಂದ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಅಲ್ಪಾವಧಿಗೆ ಹೊಸ ಸಂದೇಶಗಳನ್ನು ಓದುವುದನ್ನು ನಿಲ್ಲಿಸುವುದು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ. ಇತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ, ಮರುಪ್ರಯತ್ನ ಕಾರ್ಯತಂತ್ರವನ್ನು ಜಾರಿಗೊಳಿಸುವ ಏಕೈಕ ಬಿಂದುವನ್ನು ಹೊಂದಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಈ ಏಕ ಬಿಂದುವು ಎರಡೂ ವಿಧಾನಗಳಿಗೆ DLQ ಕಾರ್ಯವನ್ನು ಹೊಂದಿರಬೇಕು.

ಮರುಪ್ರಯತ್ನ ತಂತ್ರವನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು, ಇದು ತಾತ್ಕಾಲಿಕ ದೋಷ ಸಂಭವಿಸಿದಾಗ ಮುಂದಿನ ಮಧ್ಯಂತರವನ್ನು ಹಿಂಪಡೆಯಲು ಕಾರಣವಾಗಿದೆ.

ಲೀನಿಯರ್ ಲಾಜಿಕ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಗ್ರಾಹಕರನ್ನು ನಿಲ್ಲಿಸುವುದು

ಸ್ಪ್ರಿಂಗ್-ಕಾಫ್ಕಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವಾಗ, ಗ್ರಾಹಕರನ್ನು ನಿಲ್ಲಿಸುವ ಕೋಡ್ ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

public void pauseListenerContainer(MessageListenerContainer listenerContainer, 
                                   Instant retryAt) {
        if (nonNull(retryAt) && listenerContainer.isRunning()) {
            listenerContainer.stop();
            taskScheduler.schedule(() -> listenerContainer.start(), retryAt);
            return;
        }
        // to DLQ
    }

ಉದಾಹರಣೆಯಲ್ಲಿ, RetryAt ಎಂಬುದು MessageListenerContainer ಇನ್ನೂ ಚಾಲನೆಯಲ್ಲಿದ್ದರೆ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವ ಸಮಯವಾಗಿದೆ. TaskScheduler ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾದ ಪ್ರತ್ಯೇಕ ಥ್ರೆಡ್‌ನಲ್ಲಿ ಮರು-ಉಡಾವಣೆ ಸಂಭವಿಸುತ್ತದೆ, ಅದರ ಅನುಷ್ಠಾನವನ್ನು ವಸಂತಕಾಲದಿಂದಲೂ ಒದಗಿಸಲಾಗುತ್ತದೆ.

ನಾವು ಈ ಕೆಳಗಿನ ರೀತಿಯಲ್ಲಿ retryAt ಮೌಲ್ಯವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ:

1. ಮರು ಕರೆ ಕೌಂಟರ್‌ನ ಮೌಲ್ಯವನ್ನು ನೋಡಲಾಗುತ್ತದೆ.
2. ಕೌಂಟರ್ ಮೌಲ್ಯವನ್ನು ಆಧರಿಸಿ, ಮರುಪ್ರಯತ್ನ ತಂತ್ರದಲ್ಲಿನ ಪ್ರಸ್ತುತ ವಿಳಂಬ ಮಧ್ಯಂತರವನ್ನು ಹುಡುಕಲಾಗುತ್ತದೆ. ತಂತ್ರವನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿಯೇ ಘೋಷಿಸಲಾಗಿದೆ; ಅದನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು JSON ಸ್ವರೂಪವನ್ನು ಆರಿಸಿದ್ದೇವೆ.
3. JSON ಅರೇಯಲ್ಲಿ ಕಂಡುಬರುವ ಮಧ್ಯಂತರವು ಸಂಸ್ಕರಣೆಯನ್ನು ಪುನರಾವರ್ತಿಸಬೇಕಾದ ಸೆಕೆಂಡುಗಳ ಸಂಖ್ಯೆಯನ್ನು ಒಳಗೊಂಡಿದೆ. retryAt ಗಾಗಿ ಮೌಲ್ಯವನ್ನು ರೂಪಿಸಲು ಈ ಸಂಖ್ಯೆಯ ಸೆಕೆಂಡುಗಳನ್ನು ಪ್ರಸ್ತುತ ಸಮಯಕ್ಕೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.
4. ಮಧ್ಯಂತರವು ಕಂಡುಬರದಿದ್ದರೆ, retryAt ಮೌಲ್ಯವು ಶೂನ್ಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸಂದೇಶವನ್ನು ಹಸ್ತಚಾಲಿತ ಪಾರ್ಸಿಂಗ್‌ಗಾಗಿ DLQ ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

ಈ ವಿಧಾನದೊಂದಿಗೆ, ಪ್ರಸ್ತುತ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಿರುವ ಪ್ರತಿ ಸಂದೇಶಕ್ಕೆ ಪುನರಾವರ್ತಿತ ಕರೆಗಳ ಸಂಖ್ಯೆಯನ್ನು ಉಳಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ, ಉದಾಹರಣೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಮೆಮೊರಿಯಲ್ಲಿ. ಈ ವಿಧಾನಕ್ಕೆ ಮರುಪ್ರಯತ್ನದ ಎಣಿಕೆಯನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು ನಿರ್ಣಾಯಕವಲ್ಲ, ಏಕೆಂದರೆ ರೇಖೀಯ ತರ್ಕ ಅಪ್ಲಿಕೇಶನ್ ಒಟ್ಟಾರೆಯಾಗಿ ಸಂಸ್ಕರಣೆಯನ್ನು ನಿಭಾಯಿಸುವುದಿಲ್ಲ. ಸ್ಪ್ರಿಂಗ್-ಮರುಪ್ರಯತ್ನದಂತೆ, ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದರಿಂದ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಮರುಸಂಸ್ಕರಿಸಲು ಕಳೆದುಹೋಗುವುದಿಲ್ಲ, ಆದರೆ ಕಾರ್ಯತಂತ್ರವನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಈ ವಿಧಾನವು ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯಿಂದ ಲೋಡ್ ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದು ತುಂಬಾ ಭಾರವಾದ ಹೊರೆಯಿಂದಾಗಿ ಲಭ್ಯವಿಲ್ಲ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಮರುಸಂಸ್ಕರಣೆಯ ಜೊತೆಗೆ, ನಾವು ಮಾದರಿಯ ಅನುಷ್ಠಾನವನ್ನು ಸಾಧಿಸಿದ್ದೇವೆ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್.

ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ದೋಷ ಥ್ರೆಶೋಲ್ಡ್ ಕೇವಲ 1 ಆಗಿದೆ, ಮತ್ತು ತಾತ್ಕಾಲಿಕ ನೆಟ್‌ವರ್ಕ್ ನಿಲುಗಡೆಗಳಿಂದಾಗಿ ಸಿಸ್ಟಮ್ ಡೌನ್‌ಟೈಮ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಸಣ್ಣ ಲೇಟೆನ್ಸಿ ಮಧ್ಯಂತರಗಳೊಂದಿಗೆ ನಾವು ತುಂಬಾ ಹರಳಿನ ಮರುಪ್ರಯತ್ನ ತಂತ್ರವನ್ನು ಬಳಸುತ್ತೇವೆ. ಇದು ಎಲ್ಲಾ ಗುಂಪಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲ, ಆದ್ದರಿಂದ ದೋಷ ಮಿತಿ ಮತ್ತು ಮಧ್ಯಂತರ ಮೌಲ್ಯದ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಸಿಸ್ಟಮ್‌ನ ಗುಣಲಕ್ಷಣಗಳ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆ ಮಾಡಬೇಕು.

ನಿರ್ಣಾಯಕವಲ್ಲದ ತರ್ಕದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್

ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ (ಮರುಪ್ರಯತ್ನಕ) ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವ ಕೋಡ್‌ನ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ, ಇದು RETRY_AT ಸಮಯವನ್ನು ತಲುಪಿದಾಗ DESTINATION ವಿಷಯಕ್ಕೆ ಮರುಕಳುಹಿಸುತ್ತದೆ:

public <K, V> void retry(ConsumerRecord<K, V> record, String retryToTopic, 
                         Instant retryAt, String counter, String groupId, Exception e) {
        Headers headers = ofNullable(record.headers()).orElse(new RecordHeaders());
        List<Header> arrayOfHeaders = 
            new ArrayList<>(Arrays.asList(headers.toArray()));
        updateHeader(arrayOfHeaders, GROUP_ID, groupId::getBytes);
        updateHeader(arrayOfHeaders, DESTINATION, retryToTopic::getBytes);
        updateHeader(arrayOfHeaders, ORIGINAL_PARTITION, 
                     () -> Integer.toString(record.partition()).getBytes());
        if (nonNull(retryAt)) {
            updateHeader(arrayOfHeaders, COUNTER, counter::getBytes);
            updateHeader(arrayOfHeaders, SEND_TO, "retry"::getBytes);
            updateHeader(arrayOfHeaders, RETRY_AT, retryAt.toString()::getBytes);
        } else {
            updateHeader(arrayOfHeaders, REASON, 
                         ExceptionUtils.getStackTrace(e)::getBytes);
            updateHeader(arrayOfHeaders, SEND_TO, "backout"::getBytes);
        }
        ProducerRecord<K, V> messageToSend =
            new ProducerRecord<>(retryTopic, null, null, record.key(), record.value(), arrayOfHeaders);
        kafkaTemplate.send(messageToSend);
    }

ಹೆಡರ್‌ಗಳಲ್ಲಿ ಬಹಳಷ್ಟು ಮಾಹಿತಿಯನ್ನು ರವಾನಿಸಲಾಗಿದೆ ಎಂದು ಉದಾಹರಣೆ ತೋರಿಸುತ್ತದೆ. RETRY_AT ಮೌಲ್ಯವು ಗ್ರಾಹಕ ನಿಲುಗಡೆಯ ಮೂಲಕ ಮರುಪ್ರಯತ್ನದ ಕಾರ್ಯವಿಧಾನದ ರೀತಿಯಲ್ಲಿಯೇ ಕಂಡುಬರುತ್ತದೆ. DESTINATION ಮತ್ತು RETRY_AT ಜೊತೆಗೆ ನಾವು ಕಳುಹಿಸುತ್ತೇವೆ:

• GROUP_ID, ಹಸ್ತಚಾಲಿತ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಸರಳೀಕೃತ ಹುಡುಕಾಟಕ್ಕಾಗಿ ನಾವು ಸಂದೇಶಗಳನ್ನು ಗುಂಪು ಮಾಡುತ್ತೇವೆ.
• ಮರು-ಸಂಸ್ಕರಣೆಗಾಗಿ ಅದೇ ಗ್ರಾಹಕರನ್ನು ಇರಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸಲು ORIGINAL_PARTITION. ಈ ಪ್ಯಾರಾಮೀಟರ್ ಶೂನ್ಯವಾಗಬಹುದು, ಈ ಸಂದರ್ಭದಲ್ಲಿ ಮೂಲ ಸಂದೇಶದ record.key() ಕೀಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಸ ವಿಭಾಗವನ್ನು ಪಡೆಯಲಾಗುತ್ತದೆ.
• ಮರುಪ್ರಯತ್ನ ತಂತ್ರವನ್ನು ಅನುಸರಿಸಲು COUNTER ಮೌಲ್ಯವನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ.
• SEND_TO ಎಂಬುದು RETRY_AT ತಲುಪಿದ ನಂತರ ಮರುಸಂಸ್ಕರಣೆಗಾಗಿ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಲಾಗಿದೆಯೇ ಅಥವಾ DLQ ನಲ್ಲಿ ಇರಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ.
• ಕಾರಣ - ಸಂದೇಶ ಪ್ರಕ್ರಿಯೆಗೆ ಅಡ್ಡಿಯುಂಟಾಗಲು ಕಾರಣ.

PostgreSQL ನಲ್ಲಿ ಮರುಹಂಚಿಕೆ ಮತ್ತು ಹಸ್ತಚಾಲಿತ ಪಾರ್ಸಿಂಗ್‌ಗಾಗಿ ಮರುಪ್ರಯತ್ನಕ ಸಂದೇಶಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಟೈಮರ್ RETRY_AT ನೊಂದಿಗೆ ಸಂದೇಶಗಳನ್ನು ಹುಡುಕುವ ಕಾರ್ಯವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಕೀ record.key() ನೊಂದಿಗೆ DESTINATION ವಿಷಯದ ORIGINAL_PARTITION ವಿಭಾಗಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ.

ಒಮ್ಮೆ ಕಳುಹಿಸಿದ ನಂತರ, PostgreSQL ನಿಂದ ಸಂದೇಶಗಳನ್ನು ಅಳಿಸಲಾಗುತ್ತದೆ. ಸಂದೇಶಗಳ ಹಸ್ತಚಾಲಿತ ಪಾರ್ಸಿಂಗ್ ಸರಳ UI ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತದೆ, ಅದು REST API ಮೂಲಕ ಮರುಪ್ರಯತ್ನಕದೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. DLQ ನಿಂದ ಸಂದೇಶಗಳನ್ನು ಮರುಕಳುಹಿಸುವುದು ಅಥವಾ ಅಳಿಸುವುದು, ದೋಷದ ಮಾಹಿತಿಯನ್ನು ವೀಕ್ಷಿಸುವುದು ಮತ್ತು ಸಂದೇಶಗಳನ್ನು ಹುಡುಕುವುದು ಇದರ ಮುಖ್ಯ ಲಕ್ಷಣಗಳಾಗಿವೆ, ಉದಾಹರಣೆಗೆ ದೋಷ ಹೆಸರಿನ ಮೂಲಕ.

ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿರುವುದರಿಂದ, ಮರುಪ್ರಯತ್ನಕಾರರು ಕೇಳುತ್ತಿರುವ ವಿಷಯಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ ಪ್ರವೇಶವನ್ನು ವಿನಂತಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ ಮತ್ತು DESTINATION ವಿಷಯಕ್ಕೆ ಬರೆಯಲು ಮರುಪ್ರಯತ್ನಿಸುವವರಿಗೆ ಅನುಮತಿಸಿ. ಇದು ಅನಾನುಕೂಲವಾಗಿದೆ, ಆದರೆ, ಮಧ್ಯಂತರ ವಿಷಯದ ವಿಧಾನದಂತೆ, ಅದನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಪೂರ್ಣ ಪ್ರಮಾಣದ DLQ ಮತ್ತು UI ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಒಳಬರುವ ವಿಷಯವನ್ನು ಹಲವಾರು ವಿಭಿನ್ನ ಗ್ರಾಹಕ ಗುಂಪುಗಳು ಓದಿದಾಗ ಪ್ರಕರಣಗಳಿವೆ, ಅವರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ವಿಭಿನ್ನ ತರ್ಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತವೆ. ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಮರುಪ್ರಯತ್ನಕ ಮೂಲಕ ಸಂದೇಶವನ್ನು ಮರುಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವುದರಿಂದ ಇನ್ನೊಂದರಲ್ಲಿ ನಕಲು ಉಂಟಾಗುತ್ತದೆ. ಇದರ ವಿರುದ್ಧ ರಕ್ಷಿಸಲು, ಮರು-ಸಂಸ್ಕರಣೆಗಾಗಿ ನಾವು ಪ್ರತ್ಯೇಕ ವಿಷಯವನ್ನು ರಚಿಸುತ್ತೇವೆ. ಒಳಬರುವ ಮತ್ತು ಮರುಪ್ರಯತ್ನಿಸುವ ವಿಷಯಗಳನ್ನು ಯಾವುದೇ ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ ಅದೇ ಗ್ರಾಹಕರು ಓದಬಹುದು.

ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಈ ವಿಧಾನವು ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್ ಕಾರ್ಯವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಆದಾಗ್ಯೂ ಇದನ್ನು ಬಳಸಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸೇರಿಸಬಹುದು ಸ್ಪ್ರಿಂಗ್-ಕ್ಲೌಡ್-ನೆಟ್ಫ್ಲಿಕ್ಸ್ ಅಥವಾ ಹೊಸದು ಸ್ಪ್ರಿಂಗ್ ಕ್ಲೌಡ್ ಸರ್ಕ್ಯೂಟ್ ಬ್ರೇಕರ್, ಬಾಹ್ಯ ಸೇವೆಗಳನ್ನು ಸೂಕ್ತವಾದ ಅಮೂರ್ತತೆಗಳಾಗಿ ಕರೆಯುವ ಸ್ಥಳಗಳನ್ನು ಸುತ್ತುವುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ತಂತ್ರವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಬಲ್ಕ್ ಹೆಡ್ ಮಾದರಿ, ಇದು ಸಹ ಉಪಯುಕ್ತವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಸ್ಪ್ರಿಂಗ್-ಕ್ಲೌಡ್-ನೆಟ್‌ಫ್ಲಿಕ್ಸ್‌ನಲ್ಲಿ ಇದು ಥ್ರೆಡ್ ಪೂಲ್ ಅಥವಾ ಸೆಮಾಫೋರ್ ಆಗಿರಬಹುದು.

ತೀರ್ಮಾನಕ್ಕೆ

ಇದರ ಪರಿಣಾಮವಾಗಿ, ಯಾವುದೇ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಯು ತಾತ್ಕಾಲಿಕವಾಗಿ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಸಂದೇಶ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪುನರಾವರ್ತಿಸಲು ನಮಗೆ ಅನುಮತಿಸುವ ಪ್ರತ್ಯೇಕ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.

ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದು ಪ್ರಮುಖ ಪ್ರಯೋಜನವೆಂದರೆ, ಅದೇ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಾಹ್ಯ ವ್ಯವಸ್ಥೆಗಳು ತಮ್ಮ ಬದಿಯಲ್ಲಿ ಗಮನಾರ್ಹ ಮಾರ್ಪಾಡುಗಳಿಲ್ಲದೆ ಇದನ್ನು ಬಳಸಬಹುದು! ಅಂತಹ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮರುಪ್ರಯತ್ನದ ವಿಷಯವನ್ನು ಮಾತ್ರ ಪ್ರವೇಶಿಸಬೇಕಾಗುತ್ತದೆ, ಕೆಲವು ಕಾಫ್ಕಾ ಹೆಡರ್‌ಗಳನ್ನು ಭರ್ತಿ ಮಾಡಿ ಮತ್ತು ಮರುಪ್ರಯತ್ನಕರಿಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸಬೇಕು. ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಮರುಪ್ರಯತ್ನಕ ಮತ್ತು ಹಿಂದಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾದ ಸಂದೇಶಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನಾವು ರೇಖೀಯ ತರ್ಕದೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಗ್ರಾಹಕ ನಿಲುಗಡೆ ಮೂಲಕ ಮರು-ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ್ದೇವೆ.

ಮೂಲ: www.habr.com