ಹಲೋ, ಹಬ್ರ್!
ನಾನು ಟಿಂಕಾಫ್ ತಂಡದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ, ಅದು ತನ್ನದೇ ಆದ ಅಧಿಸೂಚನೆ ಕೇಂದ್ರವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದೆ. ನಾನು ಹೆಚ್ಚಾಗಿ ಸ್ಪ್ರಿಂಗ್ ಬೂಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಜಾವಾದಲ್ಲಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇನೆ ಮತ್ತು ಯೋಜನೆಯಲ್ಲಿ ಉದ್ಭವಿಸುವ ವಿವಿಧ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತೇನೆ.
ನಮ್ಮ ಹೆಚ್ಚಿನ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಸಂದೇಶ ಬ್ರೋಕರ್ ಮೂಲಕ ಅಸಮಕಾಲಿಕವಾಗಿ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ. ಹಿಂದೆ, ನಾವು IBM MQ ಅನ್ನು ಬ್ರೋಕರ್ ಆಗಿ ಬಳಸಿದ್ದೇವೆ, ಅದು ಇನ್ನು ಮುಂದೆ ಲೋಡ್ ಅನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿತರಣಾ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಹೊಂದಿತ್ತು.
ಬದಲಿಯಾಗಿ, ಹೆಚ್ಚಿನ ಸ್ಕೇಲಿಂಗ್ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಅಪಾಚೆ ಕಾಫ್ಕಾವನ್ನು ನಮಗೆ ನೀಡಲಾಯಿತು, ಆದರೆ, ದುರದೃಷ್ಟವಶಾತ್, ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಬಹುತೇಕ ವೈಯಕ್ತಿಕ ವಿಧಾನದ ಅಗತ್ಯವಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕಾಫ್ಕಾದಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಒಮ್ಮೆಯಾದರೂ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನವು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಅಗತ್ಯವಿರುವ ಮಟ್ಟದ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಮುಂದೆ, ನಾನು ಕಾಫ್ಕಾ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇನೆ, ನಿರ್ದಿಷ್ಟವಾಗಿ, ಒಮ್ಮೆ ವಿತರಣೆಯೊಂದಿಗೆ ಹೇಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಮತ್ತು ಬದುಕುವುದು ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಖಾತರಿಪಡಿಸಿದ ವಿತರಣೆ ಮತ್ತು ಇನ್ನಷ್ಟು
ಕೆಳಗೆ ಚರ್ಚಿಸಲಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಡೀಫಾಲ್ಟ್ ಸಂಪರ್ಕ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ತಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದರೆ ಮೊದಲು ನಾನು ಸಂಭವನೀಯ ಡೀಬಗ್ ಅನ್ನು ಸುಗಮಗೊಳಿಸುವ ಒಂದು ನಿಯತಾಂಕಕ್ಕೆ ಗಮನ ಕೊಡಲು ಬಯಸುತ್ತೇನೆ.
ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ client.id ನಿರ್ಮಾಪಕ ಮತ್ತು ಗ್ರಾಹಕರಿಗಾಗಿ. ಮೊದಲ ನೋಟದಲ್ಲಿ, ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರನ್ನು ಮೌಲ್ಯವಾಗಿ ಬಳಸಬಹುದು, ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್ ಹಲವಾರು ಗ್ರಾಹಕರನ್ನು ಬಳಸುವಾಗ ಮತ್ತು ನೀವು ಅವರಿಗೆ ಒಂದೇ ಕ್ಲೈಂಟ್.ಐಡಿಯನ್ನು ನೀಡಿದಾಗ ಪರಿಸ್ಥಿತಿಯು ಈ ಕೆಳಗಿನ ಎಚ್ಚರಿಕೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ:
org.apache.kafka.common.utils.AppInfoParser — Error registering AppInfo mbean javax.management.InstanceAlreadyExistsException: kafka.consumer:type=app-info,id=kafka.test-0ನೀವು ಕಾಫ್ಕಾ ಜೊತೆಗಿನ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ JMX ಅನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ, ಇದು ಸಮಸ್ಯೆಯಾಗಿರಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರಿನ ಸಂಯೋಜನೆಯನ್ನು ಬಳಸುವುದು ಉತ್ತಮವಾಗಿದೆ ಮತ್ತು ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್.ಐಡಿ ಮೌಲ್ಯದಂತೆ ವಿಷಯದ ಹೆಸರನ್ನು. ನಮ್ಮ ಸಂರಚನೆಯ ಫಲಿತಾಂಶವನ್ನು ಕಮಾಂಡ್ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು ಕಾಫ್ಕಾ-ಗ್ರಾಹಕ-ಗುಂಪುಗಳು ಸಂಗಮದಿಂದ ಉಪಯುಕ್ತತೆಗಳಿಂದ:
ಈಗ ಖಾತರಿಪಡಿಸಿದ ಸಂದೇಶ ವಿತರಣೆಯ ಸನ್ನಿವೇಶವನ್ನು ನೋಡೋಣ. ಕಾಫ್ಕಾ ನಿರ್ಮಾಪಕರು ಒಂದು ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಅಕ್ಗಳು, ಕ್ಲಸ್ಟರ್ ಲೀಡರ್ ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಬರೆದಿರುವುದನ್ನು ಪರಿಗಣಿಸಲು ಎಷ್ಟು ಅಂಗೀಕರಿಸಿದ ನಂತರ ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಈ ನಿಯತಾಂಕವು ಈ ಕೆಳಗಿನ ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು:
- 0 - ಸ್ವೀಕೃತಿಯನ್ನು ಪರಿಗಣಿಸಲಾಗುವುದಿಲ್ಲ.
- 1 ಡೀಫಾಲ್ಟ್ ಪ್ಯಾರಾಮೀಟರ್ ಆಗಿದೆ, ಅಂಗೀಕರಿಸಲು ಕೇವಲ 1 ಪ್ರತಿಕೃತಿ ಅಗತ್ಯವಿದೆ.
- −1 — ಎಲ್ಲಾ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಪ್ರತಿಕೃತಿಗಳಿಂದ ಅಂಗೀಕಾರದ ಅಗತ್ಯವಿದೆ (ಕ್ಲಸ್ಟರ್ ಸೆಟಪ್ min.insync.replicas).
ಪಟ್ಟಿ ಮಾಡಲಾದ ಮೌಲ್ಯಗಳಿಂದ −1 ಗೆ ಸಮಾನವಾದ ಆಕ್‌ಗಳು ಸಂದೇಶವು ಕಳೆದುಹೋಗುವುದಿಲ್ಲ ಎಂಬ ಬಲವಾದ ಭರವಸೆಯನ್ನು ನೀಡುತ್ತದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.
ನಮಗೆ ತಿಳಿದಿರುವಂತೆ, ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಗಳು ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ. ಕ್ಷಣಿಕ ದೋಷಗಳಿಂದ ರಕ್ಷಿಸಲು, ಕಾಫ್ಕಾ ನಿರ್ಮಾಪಕರು ಆಯ್ಕೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ ಮರುಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಇದು ಒಳಗೆ ಮರುಕಳುಹಿಸುವ ಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ delivery.timeout.ms. ಮರುಪ್ರಯತ್ನಗಳ ನಿಯತಾಂಕವು Integer.MAX_VALUE (2147483647) ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, delivery.timeout.ms ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಸಂದೇಶ ಮರುಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸರಿಹೊಂದಿಸಬಹುದು.
ನಾವು ನಿಖರವಾಗಿ ಒಮ್ಮೆ ವಿತರಣೆಯತ್ತ ಸಾಗುತ್ತಿದ್ದೇವೆ
ಪಟ್ಟಿ ಮಾಡಲಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ನಮ್ಮ ನಿರ್ಮಾಪಕರಿಗೆ ಹೆಚ್ಚಿನ ಗ್ಯಾರಂಟಿಯೊಂದಿಗೆ ಸಂದೇಶಗಳನ್ನು ತಲುಪಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಕಾಫ್ಕಾ ವಿಷಯಕ್ಕೆ ಸಂದೇಶದ ಒಂದು ಪ್ರತಿಯನ್ನು ಮಾತ್ರ ಬರೆಯಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ ಎಂಬುದರ ಕುರಿತು ಈಗ ಮಾತನಾಡೋಣ? ಸರಳವಾದ ಸಂದರ್ಭದಲ್ಲಿ, ಇದನ್ನು ಮಾಡಲು, ನೀವು ಪ್ರೊಡ್ಯೂಸರ್ನಲ್ಲಿ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ enable.deempotence ನಿಜಕ್ಕೆ. ಒಂದು ವಿಷಯದ ನಿರ್ದಿಷ್ಟ ವಿಭಾಗಕ್ಕೆ ಕೇವಲ ಒಂದು ಸಂದೇಶವನ್ನು ಬರೆಯಲಾಗಿದೆ ಎಂದು Idempotency ಖಾತರಿಪಡಿಸುತ್ತದೆ. ಐಡೆಂಪೊಟೆನ್ಸಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು ಪೂರ್ವಾಪೇಕ್ಷಿತವೆಂದರೆ ಮೌಲ್ಯಗಳು acks = ಎಲ್ಲಾ, ಮರುಪ್ರಯತ್ನಿಸಿ > 0, max.in.flight.requests.per.connection ≤ 5. ಈ ನಿಯತಾಂಕಗಳನ್ನು ಡೆವಲಪರ್ ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ಮೇಲಿನ ಮೌಲ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಲಾಗುತ್ತದೆ.
ಐಡೆಂಪೊಟೆನ್ಸಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಾಗ, ಅದೇ ಸಂದೇಶಗಳು ಪ್ರತಿ ಬಾರಿಯೂ ಒಂದೇ ವಿಭಾಗಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ. partitioner.class ಕೀ ಮತ್ತು ನಿಯತಾಂಕವನ್ನು ನಿರ್ಮಾಪಕರಿಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ ಇದನ್ನು ಮಾಡಬಹುದು. ಕೀಲಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ಪ್ರತಿ ಸಲ್ಲಿಕೆಗೆ ಇದು ಒಂದೇ ಆಗಿರಬೇಕು. ಮೂಲ ಪೋಸ್ಟ್‌ನಿಂದ ಯಾವುದೇ ವ್ಯಾಪಾರ ID ಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ ಇದನ್ನು ಸುಲಭವಾಗಿ ಸಾಧಿಸಬಹುದು. partitioner.class ಪ್ಯಾರಾಮೀಟರ್ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ - . ಈ ವಿಭಜನಾ ತಂತ್ರದೊಂದಿಗೆ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಾವು ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತೇವೆ:
- ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವಾಗ ವಿಭಾಗವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಬಳಸುತ್ತೇವೆ.
- ವಿಭಾಗವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ಆದರೆ ಕೀಲಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ಕೀಲಿಯ ಹ್ಯಾಶ್ ಮೂಲಕ ವಿಭಾಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.
- ವಿಭಾಗ ಮತ್ತು ಕೀಲಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದಿದ್ದರೆ, ವಿಭಾಗಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಆಯ್ಕೆಮಾಡಿ (ರೌಂಡ್-ರಾಬಿನ್).
ಅಲ್ಲದೆ, ಒಂದು ಪ್ಯಾರಾಮೀಟರ್‌ನೊಂದಿಗೆ ಕೀಲಿಯನ್ನು ಮತ್ತು ಇಂಪೋಟೆಂಟ್ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಬಳಸುವುದು max.in.flight.requests.per.connection = 1 ಗ್ರಾಹಕರ ಮೇಲೆ ಸುವ್ಯವಸ್ಥಿತ ಸಂದೇಶ ಸಂಸ್ಕರಣೆಯನ್ನು ನಿಮಗೆ ನೀಡುತ್ತದೆ. ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ, ವಿಷಯಕ್ಕೆ ಅಸಭ್ಯವಾಗಿ ಬರೆಯಲು ನಿಮಗೆ ಹಕ್ಕುಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯವಾಗಿದೆ.
ಹಠಾತ್ತನೆ ನೀವು ಕೀಲಿಯಿಂದ ಐಡೆಮ್ಪೋಟೆಂಟ್ ಕಳುಹಿಸುವ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಉತ್ಪಾದಕರ ಬದಿಯಲ್ಲಿರುವ ತರ್ಕವು ವಿಭಿನ್ನ ವಿಭಾಗಗಳ ನಡುವೆ ಡೇಟಾ ಸ್ಥಿರತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವ ಅಗತ್ಯವಿದ್ದರೆ, ವಹಿವಾಟುಗಳು ಪಾರುಗಾಣಿಕಾಕ್ಕೆ ಬರುತ್ತವೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸರಪಳಿ ವಹಿವಾಟನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ಕಾಫ್ಕಾದಲ್ಲಿ ದಾಖಲೆಯನ್ನು ಷರತ್ತುಬದ್ಧವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಬಹುದು, ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ದಾಖಲೆಯೊಂದಿಗೆ. ನಿರ್ಮಾಪಕರಿಗೆ ವಹಿವಾಟಿನ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು, ಅದು ಶಕ್ತಿಯುತವಾಗಿರಬೇಕು ಮತ್ತು ಹೆಚ್ಚುವರಿಯಾಗಿ ಹೊಂದಿಸಬೇಕು Transactional.id. ನಿಮ್ಮ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದರೆ, ಐಡೆಂಪೋಟೆಂಟ್ ರೆಕಾರ್ಡ್‌ನಂತಹ ವಹಿವಾಟಿನ ದಾಖಲೆಗೆ ಬರವಣಿಗೆ ಅನುಮತಿಗಳ ಅಗತ್ಯವಿದೆ, ಇದನ್ನು ಟ್ರಾನ್ಸ್‌ಕ್ಯಾಶನಲ್.ಐಡಿಯಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಮೌಲ್ಯವನ್ನು ಬಳಸಿಕೊಂಡು ಮಾಸ್ಕ್ ಮೂಲಕ ನೀಡಬಹುದು.
ಔಪಚಾರಿಕವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರಿನಂತಹ ಯಾವುದೇ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ವಹಿವಾಟು ಗುರುತಿಸುವಿಕೆಯಾಗಿ ಬಳಸಬಹುದು. ಆದರೆ ನೀವು ಅದೇ ಟ್ರಾನ್ಸ್‌ಮ್ಯಾನ್ಸನಲ್.ಐಡಿಯೊಂದಿಗೆ ಒಂದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಲವಾರು ನಿದರ್ಶನಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ಕಾಫ್ಕಾ ಇದನ್ನು ಜೊಂಬಿ ಪ್ರಕ್ರಿಯೆ ಎಂದು ಪರಿಗಣಿಸುವುದರಿಂದ, ಮೊದಲ ಪ್ರಾರಂಭವಾದ ನಿದರ್ಶನವನ್ನು ದೋಷದೊಂದಿಗೆ ನಿಲ್ಲಿಸಲಾಗುತ್ತದೆ.
org.apache.kafka.common.errors.ProducerFencedException: Producer attempted an operation with an old epoch. Either there is a newer producer with the same transactionalId, or the producer's transaction has been expired by the broker.ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು, ನಾವು ಪರಿಸರ ವೇರಿಯಬಲ್‌ಗಳಿಂದ ಪಡೆಯುವ ಹೋಸ್ಟ್ ಹೆಸರಿನ ರೂಪದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರಿಗೆ ಪ್ರತ್ಯಯವನ್ನು ಸೇರಿಸುತ್ತೇವೆ.
ನಿರ್ಮಾಪಕರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ, ಆದರೆ ಕಾಫ್ಕಾದಲ್ಲಿನ ವಹಿವಾಟುಗಳು ಸಂದೇಶದ ವ್ಯಾಪ್ತಿಯನ್ನು ಮಾತ್ರ ನಿಯಂತ್ರಿಸುತ್ತವೆ. ವಹಿವಾಟಿನ ಸ್ಥಿತಿಯ ಹೊರತಾಗಿಯೂ, ಸಂದೇಶವು ತಕ್ಷಣವೇ ವಿಷಯಕ್ಕೆ ಹೋಗುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚುವರಿ ಸಿಸ್ಟಮ್ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಿದೆ.
ಅಂತಹ ಸಂದೇಶಗಳನ್ನು ಗ್ರಾಹಕರು ಸಮಯಕ್ಕಿಂತ ಮುಂಚಿತವಾಗಿ ಓದುವುದನ್ನು ತಡೆಯಲು, ಇದು ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಹೊಂದಿಸುವ ಅಗತ್ಯವಿದೆ ಪ್ರತ್ಯೇಕತೆ. ಮಟ್ಟ ಓದಲು_ಬದ್ಧ ಮೌಲ್ಯಕ್ಕೆ. ಅಂತಹ ಗ್ರಾಹಕರು ಮೊದಲಿನಂತೆ ವಹಿವಾಟು-ಅಲ್ಲದ ಸಂದೇಶಗಳನ್ನು ಮತ್ತು ವಹಿವಾಟಿನ ಸಂದೇಶಗಳನ್ನು ಬದ್ಧತೆಯ ನಂತರವೇ ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ನೀವು ಹಿಂದೆ ಪಟ್ಟಿ ಮಾಡಲಾದ ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿಸಿದ್ದರೆ, ನೀವು ಒಮ್ಮೆ ವಿತರಣೆಯನ್ನು ನಿಖರವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದೀರಿ. ಅಭಿನಂದನೆಗಳು!
ಆದರೆ ಇನ್ನೂ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ. ನಾವು ಮೇಲೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಿರುವ Transactional.id, ವಾಸ್ತವವಾಗಿ ವಹಿವಾಟು ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿದೆ. ವಹಿವಾಟು ನಿರ್ವಾಹಕದಲ್ಲಿ, ಅದಕ್ಕೆ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. ಸ್ವೀಕರಿಸಿದ ಗುರುತನ್ನು ನೀಡಲಾಗುತ್ತದೆ Transactional.id.expiration.ms, ಇದು ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಮತ್ತು "7 ದಿನಗಳು" ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವನ್ನು ಹೊಂದಿದೆ. ಈ ಸಮಯದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್ ಯಾವುದೇ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ನೀವು ಮುಂದಿನ ವಹಿವಾಟು ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ ನೀವು ಸ್ವೀಕರಿಸುತ್ತೀರಿ ಅಮಾನ್ಯವಾದ ಪಿಡ್‌ಮ್ಯಾಪಿಂಗ್ ವಿನಾಯಿತಿ. ವಹಿವಾಟಿನ ಸಂಯೋಜಕರು ನಂತರ ಮುಂದಿನ ವಹಿವಾಟಿಗೆ ಹೊಸ ಅನುಕ್ರಮ ಸಂಖ್ಯೆಯನ್ನು ನೀಡುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, InvalidPidMappingException ಅನ್ನು ಸರಿಯಾಗಿ ನಿರ್ವಹಿಸದಿದ್ದರೆ ಸಂದೇಶವು ಕಳೆದುಹೋಗಬಹುದು.
ಮೊತ್ತದ ಬದಲಿಗೆ
ನೀವು ನೋಡುವಂತೆ, ಕಾಫ್ಕಾಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ಇದು ಸಾಕಾಗುವುದಿಲ್ಲ. ನೀವು ನಿಯತಾಂಕಗಳ ಸಂಯೋಜನೆಯನ್ನು ಆರಿಸಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ತ್ವರಿತ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲು ಸಿದ್ಧರಾಗಿರಿ. ಈ ಲೇಖನದಲ್ಲಿ, ನಾನು ನಿಖರವಾಗಿ ಒಮ್ಮೆ ಡೆಲಿವರಿ ಸೆಟಪ್ ಅನ್ನು ವಿವರವಾಗಿ ತೋರಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ ಮತ್ತು ನಾವು ಎದುರಿಸಿದ ಕ್ಲೈಂಟ್.ಐಡಿ ಮತ್ತು ವಹಿವಾಟು.ಐಡಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳೊಂದಿಗೆ ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ವಿವರಿಸಿದೆ. ನಿರ್ಮಾಪಕ ಮತ್ತು ಗ್ರಾಹಕ ಸೆಟ್ಟಿಂಗ್ಗಳ ಸಾರಾಂಶವನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ.
ನಿರ್ಮಾಪಕ:
- acks = ಎಲ್ಲಾ
- ಮರುಪ್ರಯತ್ನಗಳು > 0
- enable.idempotence = ನಿಜ
- max.in.flight.requests.per.connection ≤ 5 (1 ಕ್ರಮಬದ್ಧವಾಗಿ ಕಳುಹಿಸಲು)
- Transactional.id = ${application-name}-${hostname}
ಗ್ರಾಹಕ:
- isolation.level = read_committed
ಭವಿಷ್ಯದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ದೋಷಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಸ್ಪ್ರಿಂಗ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ನಾವು ನಮ್ಮದೇ ಆದ ಹೊದಿಕೆಯನ್ನು ಮಾಡಿದ್ದೇವೆ, ಅಲ್ಲಿ ಪಟ್ಟಿ ಮಾಡಲಾದ ಕೆಲವು ನಿಯತಾಂಕಗಳಿಗೆ ಮೌಲ್ಯಗಳನ್ನು ಈಗಾಗಲೇ ಹೊಂದಿಸಲಾಗಿದೆ.
ಸ್ವಯಂ ಅಧ್ಯಯನಕ್ಕಾಗಿ ಕೆಲವು ವಸ್ತುಗಳು ಇಲ್ಲಿವೆ:
ಮೂಲ: www.habr.com