🥇ಸಂದೇಶ ದಲ್ಲಾಳಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ActiveMQ ಮತ್ತು Kafka ನೊಂದಿಗೆ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಕಲಿಯುವುದು. ಅಧ್ಯಾಯ 3. ಕಾಫ್ಕಾ

ಸಣ್ಣ ಪುಸ್ತಕದ ಅನುವಾದದ ಮುಂದುವರಿಕೆ:
ಸಂದೇಶ ಬ್ರೋಕರ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು
ಲೇಖಕ: ಜಾಕುಬ್ ಕೊರಾಬ್, ಪ್ರಕಾಶಕರು: ಓ'ರೈಲಿ ಮೀಡಿಯಾ, ಇಂಕ್., ಪ್ರಕಟಣೆಯ ದಿನಾಂಕ: ಜೂನ್ 2017, ISBN: 9781492049296.

ಹಿಂದಿನ ಅನುವಾದಿಸಿದ ಭಾಗ: ಸಂದೇಶ ದಲ್ಲಾಳಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ActiveMQ ಮತ್ತು Kafka ನೊಂದಿಗೆ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಕಲಿಯುವುದು. ಅಧ್ಯಾಯ 1 ಪರಿಚಯ

ಅಧ್ಯಾಯ 3

ಕಾಫ್ಕ

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

ಈ ಅಂತಿಮ ಗುರಿಯನ್ನು ನೀಡಿದರೆ, ಇತರ ಅವಶ್ಯಕತೆಗಳು ಸ್ವಾಭಾವಿಕವಾಗಿ ಉದ್ಭವಿಸಿದವು. ಕಾಫ್ಕಾ ಮಾಡಬೇಕು:

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

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

ಏಕೀಕೃತ ಗಮ್ಯಸ್ಥಾನ ಮಾದರಿ

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

ಈ ಅಧ್ಯಾಯದ ಉಳಿದ ಭಾಗಕ್ಕೆ, ನಾವು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳದ ಹೊರತು, "ವಿಷಯ" ಎಂಬ ಪದವು ಕಾಫ್ಕಾ ವಿಷಯವನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

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

"ಲಾಗ್" ಮತ್ತು "ಪಾಯಿಂಟರ್" ಪದಗಳು ಕಾಣಿಸುವುದಿಲ್ಲ ಕಾಫ್ಕಾ ದಸ್ತಾವೇಜನ್ನು. ಈ ಸುಪ್ರಸಿದ್ಧ ಪದಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಹಾಯ ಮಾಡಲು ಇಲ್ಲಿ ಬಳಸಲಾಗಿದೆ.

ಈ ಮಾದರಿಯು ActiveMQ ಗಿಂತ ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನವಾಗಿದೆ, ಅಲ್ಲಿ ಎಲ್ಲಾ ಸಾಲುಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಒಂದೇ ಲಾಗ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಬ್ರೋಕರ್ ಸಂದೇಶಗಳನ್ನು ಓದಿದ ನಂತರ ಅಳಿಸಲಾಗಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತಾರೆ.
ಈಗ ಸ್ವಲ್ಪ ಆಳವಾಗಿ ಅಗೆಯೋಣ ಮತ್ತು ವಿಷಯದ ಲಾಗ್ ಅನ್ನು ಹೆಚ್ಚು ವಿವರವಾಗಿ ನೋಡೋಣ.
ಕಾಫ್ಕಾ ಲಾಗ್ ಹಲವಾರು ವಿಭಾಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ (ಚಿತ್ರ 3-1) ಕಾಫ್ಕಾ ಪ್ರತಿ ವಿಭಾಗದಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾದ ಆದೇಶವನ್ನು ಖಾತರಿಪಡಿಸುತ್ತದೆ. ಅಂದರೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಕ್ರಮದಲ್ಲಿ ವಿಭಾಗಕ್ಕೆ ಬರೆದ ಸಂದೇಶಗಳನ್ನು ಅದೇ ಕ್ರಮದಲ್ಲಿ ಓದಲಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ವಿಭಾಗವನ್ನು ಒಳಗೊಂಡಿರುವ ರೋಲಿಂಗ್ ಲಾಗ್ ಫೈಲ್ ಆಗಿ ಅಳವಡಿಸಲಾಗಿದೆ ಉಪವಿಭಾಗ ಅದರ ನಿರ್ಮಾಪಕರು ವಿಷಯಕ್ಕೆ ಕಳುಹಿಸಲಾದ ಎಲ್ಲಾ ಸಂದೇಶಗಳ (ಉಪವಿಭಾಗ). ರಚಿಸಲಾದ ವಿಷಯವು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಒಂದು ವಿಭಾಗವನ್ನು ಒಳಗೊಂಡಿದೆ. ವಿಭಾಗಗಳ ಕಲ್ಪನೆಯು ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ಗಾಗಿ ಕಾಫ್ಕಾದ ಕೇಂದ್ರ ಕಲ್ಪನೆಯಾಗಿದೆ.

ಚಿತ್ರ 3-1. ಕಾಫ್ಕಾ ವಿಭಜನೆಗಳು

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

ಸಂದೇಶಗಳನ್ನು ಓದುವುದು

ಸಂದೇಶಗಳನ್ನು ಓದಲು ಬಯಸುವ ಕ್ಲೈಂಟ್ ಎಂಬ ಹೆಸರಿನ ಪಾಯಿಂಟರ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಗ್ರಾಹಕ ಗುಂಪು, ಇದು ಸೂಚಿಸುತ್ತದೆ ಆಫ್ಸೆಟ್ ವಿಭಾಗದಲ್ಲಿ ಸಂದೇಶಗಳು. ಆಫ್‌ಸೆಟ್ ಒಂದು ಹೆಚ್ಚುತ್ತಿರುವ ಸ್ಥಾನವಾಗಿದ್ದು ಅದು ವಿಭಾಗದ ಪ್ರಾರಂಭದಲ್ಲಿ 0 ರಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಬಳಕೆದಾರ-ವ್ಯಾಖ್ಯಾನಿತ group_id ಮೂಲಕ API ನಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲಾದ ಈ ಗ್ರಾಹಕ ಗುಂಪು, ಅನುರೂಪವಾಗಿದೆ ಒಂದು ತಾರ್ಕಿಕ ಗ್ರಾಹಕ ಅಥವಾ ವ್ಯವಸ್ಥೆ.

ಹೆಚ್ಚಿನ ಸಂದೇಶ ವ್ಯವಸ್ಥೆಗಳು ಸಂದೇಶಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬಹು ನಿದರ್ಶನಗಳು ಮತ್ತು ಥ್ರೆಡ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಗಮ್ಯಸ್ಥಾನದಿಂದ ಡೇಟಾವನ್ನು ಓದುತ್ತವೆ. ಹೀಗಾಗಿ, ಒಂದೇ ಗ್ರಾಹಕ ಗುಂಪನ್ನು ಹಂಚಿಕೊಳ್ಳುವ ಅನೇಕ ಗ್ರಾಹಕ ನಿದರ್ಶನಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇರುತ್ತವೆ.

ಓದುವ ಸಮಸ್ಯೆಯನ್ನು ಈ ಕೆಳಗಿನಂತೆ ನಿರೂಪಿಸಬಹುದು:

ವಿಷಯವು ಬಹು ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದೆ
ಗ್ರಾಹಕರ ಬಹು ಗುಂಪುಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಿಷಯವನ್ನು ಬಳಸಬಹುದು
ಗ್ರಾಹಕರ ಗುಂಪು ಅನೇಕ ಪ್ರತ್ಯೇಕ ನಿದರ್ಶನಗಳನ್ನು ಹೊಂದಬಹುದು

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

ಗ್ರಾಹಕರು ಮತ್ತು ಗ್ರಾಹಕ ಗುಂಪುಗಳು

ಒಂದು ವಿಭಾಗದೊಂದಿಗೆ ವಿಷಯವನ್ನು ಆರಂಭಿಕ ಹಂತವಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ (ಚಿತ್ರ 3-2).

ಚಿತ್ರ 3-2. ಗ್ರಾಹಕರು ವಿಭಜನೆಯಿಂದ ಓದುತ್ತಾರೆ

ಗ್ರಾಹಕ ನಿದರ್ಶನವು ಈ ವಿಷಯಕ್ಕೆ ತನ್ನದೇ ಆದ group_id ನೊಂದಿಗೆ ಸಂಪರ್ಕಗೊಂಡಾಗ, ಅದು ಓದುವ ವಿಭಾಗವನ್ನು ಮತ್ತು ಆ ವಿಭಾಗದಲ್ಲಿ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಈ ಆಫ್‌ಸೆಟ್‌ನ ಸ್ಥಾನವನ್ನು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ಇತ್ತೀಚಿನ ಸ್ಥಾನಕ್ಕೆ (ಹೊಸ ಸಂದೇಶ) ಅಥವಾ ಆರಂಭಿಕ ಸ್ಥಾನಕ್ಕೆ (ಹಳೆಯ ಸಂದೇಶ) ಪಾಯಿಂಟರ್ ಆಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು. ಗ್ರಾಹಕರು ವಿಷಯದಿಂದ ಸಂದೇಶಗಳನ್ನು ವಿನಂತಿಸುತ್ತಾರೆ, ಇದು ಲಾಗ್‌ನಿಂದ ಅನುಕ್ರಮವಾಗಿ ಓದಲು ಕಾರಣವಾಗುತ್ತದೆ.
ಆಫ್‌ಸೆಟ್ ಸ್ಥಾನವನ್ನು ನಿಯಮಿತವಾಗಿ ಕಾಫ್ಕಾಗೆ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆಂತರಿಕ ವಿಷಯದಲ್ಲಿ ಸಂದೇಶಗಳಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ _ಗ್ರಾಹಕ_ಆಫ್‌ಸೆಟ್‌ಗಳು. ಸಾಮಾನ್ಯ ಬ್ರೋಕರ್‌ನಂತೆ ಓದಿದ ಸಂದೇಶಗಳನ್ನು ಇನ್ನೂ ಅಳಿಸಲಾಗಿಲ್ಲ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಈಗಾಗಲೇ ವೀಕ್ಷಿಸಿದ ಸಂದೇಶಗಳನ್ನು ಮರು-ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಆಫ್‌ಸೆಟ್ ಅನ್ನು ರಿವೈಂಡ್ ಮಾಡಬಹುದು.

ಎರಡನೇ ತಾರ್ಕಿಕ ಗ್ರಾಹಕರು ಬೇರೆ group_id ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸಂಪರ್ಕಿಸಿದಾಗ, ಅದು ಮೊದಲನೆಯದಕ್ಕಿಂತ ಸ್ವತಂತ್ರವಾಗಿರುವ ಎರಡನೇ ಪಾಯಿಂಟರ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ (ಚಿತ್ರ 3-3) ಹೀಗಾಗಿ, ಕಾಫ್ಕಾ ವಿಷಯವು ಒಬ್ಬ ಗ್ರಾಹಕರಿರುವ ಸರತಿ ಸಾಲಿನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಬಹು ಗ್ರಾಹಕರು ಚಂದಾದಾರರಾಗುವ ಸಾಮಾನ್ಯ ಪ್ರಕಟಣೆ-ಚಂದಾದಾರ (ಪಬ್-ಸಬ್) ವಿಷಯದಂತೆ, ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹಲವಾರು ಬಾರಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು ಎಂಬ ಹೆಚ್ಚುವರಿ ಪ್ರಯೋಜನದೊಂದಿಗೆ.

ಚಿತ್ರ 3-3. ವಿಭಿನ್ನ ಗ್ರಾಹಕ ಗುಂಪುಗಳಲ್ಲಿ ಇಬ್ಬರು ಗ್ರಾಹಕರು ಒಂದೇ ವಿಭಾಗದಿಂದ ಓದುತ್ತಾರೆ

ಗ್ರಾಹಕ ಗುಂಪಿನಲ್ಲಿ ಗ್ರಾಹಕರು

ಒಂದು ಗ್ರಾಹಕ ನಿದರ್ಶನವು ವಿಭಾಗದಿಂದ ಡೇಟಾವನ್ನು ಓದಿದಾಗ, ಅದು ಪಾಯಿಂಟರ್‌ನ ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿರುತ್ತದೆ ಮತ್ತು ಹಿಂದಿನ ವಿಭಾಗದಲ್ಲಿ ವಿವರಿಸಿದಂತೆ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ.
ಗ್ರಾಹಕರು ಹಲವಾರು ನಿದರ್ಶನಗಳನ್ನು ಒಂದೇ ಗುಂಪು_ಐಡಿಯೊಂದಿಗೆ ಒಂದು ವಿಭಾಗದೊಂದಿಗೆ ವಿಷಯಕ್ಕೆ ಸಂಪರ್ಕಿಸಿದ್ದರೆ, ಕೊನೆಯದಾಗಿ ಸಂಪರ್ಕಪಡಿಸಿದ ನಿದರ್ಶನಕ್ಕೆ ಪಾಯಿಂಟರ್ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ಆ ಕ್ಷಣದಿಂದ ಅದು ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ (ಚಿತ್ರ 3-4).

ಚಿತ್ರ 3-4. ಒಂದೇ ಗ್ರಾಹಕ ಗುಂಪಿನಲ್ಲಿರುವ ಇಬ್ಬರು ಗ್ರಾಹಕರು ಒಂದೇ ವಿಭಾಗದಿಂದ ಓದುತ್ತಾರೆ

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

ಸಾಮಾನ್ಯ JMS ಕ್ಯೂ ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಮೇಲೆ ವಿವರಿಸಿದ ಈ ಸಂದೇಶ ವಿತರಣಾ ನಡವಳಿಕೆಯು ಆಶ್ಚರ್ಯಕರವಾಗಿದೆ. ಈ ಮಾದರಿಯಲ್ಲಿ, ಸರತಿ ಸಾಲಿನಲ್ಲಿ ಕಳುಹಿಸಲಾದ ಸಂದೇಶಗಳನ್ನು ಇಬ್ಬರು ಗ್ರಾಹಕರ ನಡುವೆ ಸಮವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ.

ಹೆಚ್ಚಾಗಿ, ನಾವು ಗ್ರಾಹಕರ ಅನೇಕ ನಿದರ್ಶನಗಳನ್ನು ರಚಿಸಿದಾಗ, ಸಂದೇಶಗಳನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅಥವಾ ಓದುವ ವೇಗವನ್ನು ಹೆಚ್ಚಿಸಲು ಅಥವಾ ಓದುವ ಪ್ರಕ್ರಿಯೆಯ ಸ್ಥಿರತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ಇದನ್ನು ಮಾಡುತ್ತೇವೆ. ಒಂದು ಸಮಯದಲ್ಲಿ ಕೇವಲ ಒಂದು ಗ್ರಾಹಕ ನಿದರ್ಶನವು ವಿಭಜನೆಯಿಂದ ಡೇಟಾವನ್ನು ಓದಬಹುದು, ಕಾಫ್ಕಾದಲ್ಲಿ ಇದನ್ನು ಹೇಗೆ ಸಾಧಿಸಲಾಗುತ್ತದೆ?

ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಓದಲು ಮತ್ತು ಅವುಗಳನ್ನು ಥ್ರೆಡ್ ಪೂಲ್‌ಗೆ ರವಾನಿಸಲು ಒಂದೇ ಗ್ರಾಹಕ ನಿದರ್ಶನವನ್ನು ಬಳಸುವುದು ಇದನ್ನು ಮಾಡಲು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ಈ ವಿಧಾನವು ಸಂಸ್ಕರಣೆಯ ಥ್ರೋಪುಟ್ ಅನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ಇದು ಗ್ರಾಹಕ ತರ್ಕದ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ ಮತ್ತು ಓದುವ ವ್ಯವಸ್ಥೆಯ ದೃಢತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ. ವಿದ್ಯುತ್ ವೈಫಲ್ಯ ಅಥವಾ ಅಂತಹುದೇ ಘಟನೆಯಿಂದಾಗಿ ಗ್ರಾಹಕರ ಒಂದು ನಕಲು ಕಡಿಮೆಯಾದರೆ, ವ್ಯವಕಲನವು ನಿಲ್ಲುತ್ತದೆ.

ಕಾಫ್ಕಾದಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಅಂಗೀಕೃತ ಮಾರ್ಗವೆಂದರೆ ಬಿОಹೆಚ್ಚಿನ ವಿಭಾಗಗಳು.

ವಿಭಜನೆ

ವಿಭಾಗಗಳು ಒಂದೇ ಬ್ರೋಕರ್ ನಿದರ್ಶನದ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನ ಆಚೆಗೆ ವಿಷಯವನ್ನು ಓದುವಿಕೆಯನ್ನು ಸಮಾನಾಂತರಗೊಳಿಸಲು ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಮಾಡಲು ಮುಖ್ಯ ಕಾರ್ಯವಿಧಾನವಾಗಿದೆ. ಇದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಎರಡು ವಿಭಾಗಗಳೊಂದಿಗೆ ಒಂದು ವಿಷಯವಿದೆ ಮತ್ತು ಒಬ್ಬ ಗ್ರಾಹಕರು ಈ ವಿಷಯಕ್ಕೆ ಚಂದಾದಾರರಾಗಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪರಿಗಣಿಸೋಣ (ಚಿತ್ರ 3-5).

ಚಿತ್ರ 3-5. ಒಬ್ಬ ಗ್ರಾಹಕರು ಬಹು ವಿಭಾಗಗಳಿಂದ ಓದುತ್ತಾರೆ

ಈ ಸನ್ನಿವೇಶದಲ್ಲಿ, ಗ್ರಾಹಕರು ಎರಡೂ ವಿಭಾಗಗಳಲ್ಲಿ ಅದರ group_id ಗೆ ಅನುಗುಣವಾದ ಪಾಯಿಂಟರ್‌ಗಳ ಮೇಲೆ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತಾರೆ ಮತ್ತು ಎರಡೂ ವಿಭಾಗಗಳಿಂದ ಸಂದೇಶಗಳನ್ನು ಓದಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.
ಅದೇ group_id ಗಾಗಿ ಹೆಚ್ಚುವರಿ ಗ್ರಾಹಕನನ್ನು ಈ ವಿಷಯಕ್ಕೆ ಸೇರಿಸಿದಾಗ, ಕಾಫ್ಕಾ ಮೊದಲಿನಿಂದ ಎರಡನೆಯ ಗ್ರಾಹಕನಿಗೆ ವಿಭಾಗಗಳಲ್ಲಿ ಒಂದನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡುತ್ತದೆ. ಅದರ ನಂತರ, ಗ್ರಾಹಕರ ಪ್ರತಿ ನಿದರ್ಶನವು ವಿಷಯದ ಒಂದು ವಿಭಾಗದಿಂದ ಓದುತ್ತದೆ (ಚಿತ್ರ 3-6).

ಸಂದೇಶಗಳನ್ನು 20 ಥ್ರೆಡ್‌ಗಳಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಿಮಗೆ ಕನಿಷ್ಠ 20 ವಿಭಾಗಗಳ ಅಗತ್ಯವಿದೆ. ಕಡಿಮೆ ವಿಭಾಗಗಳಿದ್ದರೆ, ವಿಶೇಷ ಗ್ರಾಹಕರ ಚರ್ಚೆಯಲ್ಲಿ ಮೊದಲೇ ವಿವರಿಸಿದಂತೆ ಕೆಲಸ ಮಾಡಲು ಏನೂ ಇಲ್ಲದ ಗ್ರಾಹಕರೊಂದಿಗೆ ನೀವು ಉಳಿಯುತ್ತೀರಿ.

ಚಿತ್ರ 3-6. ಒಂದೇ ಗ್ರಾಹಕ ಗುಂಪಿನಲ್ಲಿರುವ ಇಬ್ಬರು ಗ್ರಾಹಕರು ವಿಭಿನ್ನ ವಿಭಾಗಗಳಿಂದ ಓದುತ್ತಾರೆ

JMS ಸರದಿಯನ್ನು ನಿರ್ವಹಿಸಲು ಅಗತ್ಯವಿರುವ ಸಂದೇಶ ವಿತರಣೆಗೆ ಹೋಲಿಸಿದರೆ ಈ ಯೋಜನೆಯು ಕಾಫ್ಕಾ ಬ್ರೋಕರ್‌ನ ಸಂಕೀರ್ಣತೆಯನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇಲ್ಲಿ ನೀವು ಈ ಕೆಳಗಿನ ಅಂಶಗಳ ಬಗ್ಗೆ ಚಿಂತಿಸಬೇಕಾಗಿಲ್ಲ:

ರೌಂಡ್-ರಾಬಿನ್ ಹಂಚಿಕೆ, ಪ್ರಿಫೆಚ್ ಬಫರ್‌ಗಳ ಪ್ರಸ್ತುತ ಸಾಮರ್ಥ್ಯ ಅಥವಾ ಹಿಂದಿನ ಸಂದೇಶಗಳ ಆಧಾರದ ಮೇಲೆ ಯಾವ ಗ್ರಾಹಕರು ಮುಂದಿನ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಬೇಕು (JMS ಸಂದೇಶ ಗುಂಪುಗಳಿಗೆ).
ಯಾವ ಗ್ರಾಹಕರಿಗೆ ಯಾವ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ ಮತ್ತು ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಅವುಗಳನ್ನು ಮರು-ವಿತರಿಸಬೇಕು.

ಕಾಫ್ಕಾ ಬ್ರೋಕರ್ ಮಾಡಬೇಕಾಗಿರುವುದು ಗ್ರಾಹಕರು ವಿನಂತಿಸಿದಾಗ ಅವರಿಗೆ ಅನುಕ್ರಮವಾಗಿ ಸಂದೇಶಗಳನ್ನು ರವಾನಿಸುವುದು.

ಆದಾಗ್ಯೂ, ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ಅನ್ನು ಸಮಾನಾಂತರಗೊಳಿಸುವ ಮತ್ತು ವಿಫಲವಾದ ಸಂದೇಶಗಳನ್ನು ಮರುಕಳಿಸುವ ಅವಶ್ಯಕತೆಗಳು ದೂರ ಹೋಗುವುದಿಲ್ಲ - ಅವುಗಳ ಜವಾಬ್ದಾರಿಯು ಬ್ರೋಕರ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಸರಳವಾಗಿ ಹಾದುಹೋಗುತ್ತದೆ. ನಿಮ್ಮ ಕೋಡ್‌ನಲ್ಲಿ ಅವುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂದರ್ಥ.

ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತಿದೆ

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

JMS ನಲ್ಲಿ ನಾವು ಮೆಟಾಡೇಟಾ (ಹೆಡರ್‌ಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳು) ಮತ್ತು ಪೇಲೋಡ್ (ಪೇಲೋಡ್) ಹೊಂದಿರುವ ದೇಹವನ್ನು ಹೊಂದಿರುವ ಸಂದೇಶ ರಚನೆಯನ್ನು ಬಳಸುತ್ತೇವೆ, ಆದರೆ ಕಾಫ್ಕಾದಲ್ಲಿ ಸಂದೇಶವು ಜೋಡಿ "ಕೀ-ಮೌಲ್ಯ". ಸಂದೇಶ ಪೇಲೋಡ್ ಅನ್ನು ಮೌಲ್ಯವಾಗಿ ಕಳುಹಿಸಲಾಗಿದೆ. ಮತ್ತೊಂದೆಡೆ, ಕೀಲಿಯನ್ನು ಮುಖ್ಯವಾಗಿ ವಿಭಜನೆಗಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಂದಿರಬೇಕು ವ್ಯಾಪಾರ ತರ್ಕ ನಿರ್ದಿಷ್ಟ ಕೀಅದೇ ವಿಭಾಗದಲ್ಲಿ ಸಂಬಂಧಿಸಿದ ಸಂದೇಶಗಳನ್ನು ಹಾಕಲು.

ಅಧ್ಯಾಯ 2 ರಲ್ಲಿ, ನಾವು ಆನ್‌ಲೈನ್ ಬೆಟ್ಟಿಂಗ್ ಸನ್ನಿವೇಶವನ್ನು ಚರ್ಚಿಸಿದ್ದೇವೆ, ಅಲ್ಲಿ ಸಂಬಂಧಿತ ಈವೆಂಟ್‌ಗಳನ್ನು ಒಬ್ಬ ಗ್ರಾಹಕರು ಕ್ರಮವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು:

ಬಳಕೆದಾರ ಖಾತೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.
ಖಾತೆಗೆ ಹಣ ಜಮಾ ಆಗಿದೆ.
ಖಾತೆಯಿಂದ ಹಣವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಪಂತವನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.

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

ಈ ಇಂಟರ್ಫೇಸ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

ನಿಮ್ಮ ಸ್ವಂತ ವಿಭಜನಾ ತಂತ್ರವನ್ನು ಬರೆಯುವುದು

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

ಮೌಲ್ಯವು ಬ್ಯಾಂಕ್ ವರ್ಗಾವಣೆ ಪೇಲೋಡ್ ಆಗಿರುವುದರಿಂದ ಅದರ ಸಮಗ್ರತೆಯನ್ನು ನಾವು ಸಂರಕ್ಷಿಸಲು ಬಯಸುತ್ತೇವೆ, ಕೀಲಿಯಲ್ಲಿ ಬಳಸಲು ಡೇಟಾ ರಚನೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲು ನಮಗೆ ಯಾವುದೇ ಆಯ್ಕೆಯಿಲ್ಲ. ವಿಭಜನೆಗಾಗಿ ನಮಗೆ ಖಾತೆಯ ಐಡಿ ಅಗತ್ಯವಿದೆ ಎಂದು ಭಾವಿಸಿ, ಖಾತೆಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು, ನಾವು ಈ ಕೆಳಗಿನ JSON ರಚನೆಯೊಂದಿಗೆ ಬರುತ್ತೇವೆ:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

ಏಕೆಂದರೆ ಸಹಿಯ ಮೌಲ್ಯವು ಪೇಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಬದಲಾಗುತ್ತದೆ, ವಿಭಜಕ ಇಂಟರ್ಫೇಸ್ನ ಡೀಫಾಲ್ಟ್ ಹ್ಯಾಶಿಂಗ್ ತಂತ್ರವು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಸಂಬಂಧಿತ ಸಂದೇಶಗಳನ್ನು ಗುಂಪು ಮಾಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ನಾವು ಈ ಕೀಲಿಯನ್ನು ಪಾರ್ಸ್ ಮಾಡುವ ಮತ್ತು accountId ಮೌಲ್ಯವನ್ನು ವಿಭಜಿಸುವ ನಮ್ಮದೇ ಆದ ಕಾರ್ಯತಂತ್ರವನ್ನು ಬರೆಯಬೇಕಾಗಿದೆ.

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

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

ಒಂದು ವಿಷಯದಲ್ಲಿನ ವಿಭಾಗಗಳ ಸಂಖ್ಯೆಯು ಕಾಲಾನಂತರದಲ್ಲಿ ಬದಲಾಗಬಹುದು, ಏಕೆಂದರೆ ಸಂಚಾರ ಆರಂಭಿಕ ನಿರೀಕ್ಷೆಗಳನ್ನು ಮೀರಿ ಹೋದರೆ ಅವುಗಳನ್ನು ಸೇರಿಸಬಹುದು. ಹೀಗಾಗಿ, ಸಂದೇಶದ ಕೀಲಿಗಳನ್ನು ಅವರು ಮೂಲತಃ ಕಳುಹಿಸಲಾದ ವಿಭಜನೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಬಹುದು, ಇದು ನಿರ್ಮಾಪಕ ನಿದರ್ಶನಗಳ ನಡುವೆ ಹಂಚಿಕೊಳ್ಳಬೇಕಾದ ರಾಜ್ಯದ ಭಾಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ.

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

ವಿಭಿನ್ನ ಭೌಗೋಳಿಕ ಸ್ಥಳಗಳಲ್ಲಿ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ಗಳ ನಡುವೆ ಡೇಟಾವನ್ನು ಪುನರಾವರ್ತಿಸುವ ಅಗತ್ಯವನ್ನು ಪರಿಗಣಿಸಿ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ಕಾಫ್ಕಾ MirrorMaker ಎಂಬ ಕಮಾಂಡ್ ಲೈನ್ ಉಪಕರಣದೊಂದಿಗೆ ಬರುತ್ತದೆ, ಇದನ್ನು ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸಂದೇಶಗಳನ್ನು ಓದಲು ಮತ್ತು ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾಯಿಸಲು ಬಳಸಲಾಗುತ್ತದೆ.

ಮಿರರ್‌ಮೇಕರ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ನಡುವೆ ಪುನರಾವರ್ತಿಸುವಾಗ ಸಂದೇಶಗಳ ನಡುವೆ ಸಾಪೇಕ್ಷ ಕ್ರಮವನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು ಪುನರಾವರ್ತಿತ ವಿಷಯದ ಕೀಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ ಆ ವಿಷಯದ ವಿಭಾಗಗಳ ಸಂಖ್ಯೆ ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರುವುದಿಲ್ಲ.

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

ಸಾಂಪ್ರದಾಯಿಕ ಬ್ರೋಕರ್‌ನ ಕೆಲವು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ವರ್ಗಾಯಿಸುವುದರಿಂದ ಕಾಫ್ಕಾದ ಸ್ಕೇಲೆಬಿಲಿಟಿ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಯೋಜನಗಳು ಬರುತ್ತವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಮಾನಾಂತರವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಹಲವಾರು ಗ್ರಾಹಕರ ನಡುವೆ ಸಂಭಾವ್ಯ ಸಂಬಂಧಿತ ಸಂದೇಶಗಳನ್ನು ವಿತರಿಸಲು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.

JMS ಬ್ರೋಕರ್‌ಗಳು ಸಹ ಅಂತಹ ಅವಶ್ಯಕತೆಗಳನ್ನು ಎದುರಿಸಬೇಕಾಗುತ್ತದೆ. ಕುತೂಹಲಕಾರಿಯಾಗಿ, ಅದೇ ಗ್ರಾಹಕರಿಗೆ ಸಂಬಂಧಿಸಿದ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು JMS ಸಂದೇಶ ಗುಂಪುಗಳ ಮೂಲಕ ಅಳವಡಿಸಲಾಗಿದೆ (ಜಿಗುಟಾದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ (ಎಸ್‌ಎಲ್‌ಬಿ) ಕಾರ್ಯತಂತ್ರದ ಬದಲಾವಣೆ), ಕಳುಹಿಸುವವರು ಸಂದೇಶಗಳನ್ನು ಸಂಬಂಧಿಸಿದಂತೆ ಗುರುತಿಸುವ ಅಗತ್ಯವಿದೆ. JMS ಪ್ರಕರಣದಲ್ಲಿ, ಈ ಸಂಬಂಧಿತ ಸಂದೇಶಗಳ ಗುಂಪನ್ನು ಹಲವು ಗ್ರಾಹಕರಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಕಳುಹಿಸಲು ಬ್ರೋಕರ್ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ ಮತ್ತು ಗ್ರಾಹಕರು ಕುಸಿದರೆ ಗುಂಪಿನ ಮಾಲೀಕತ್ವವನ್ನು ವರ್ಗಾಯಿಸುತ್ತಾರೆ.

ನಿರ್ಮಾಪಕ ಒಪ್ಪಂದಗಳು

ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವಾಗ ಪರಿಗಣಿಸಬೇಕಾದ ಏಕೈಕ ವಿಷಯವೆಂದರೆ ವಿಭಜನೆಯಲ್ಲ. ಜಾವಾ API ನಲ್ಲಿ ನಿರ್ಮಾಪಕ ವರ್ಗದ ಕಳುಹಿಸುವ () ವಿಧಾನಗಳನ್ನು ನೋಡೋಣ:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

ಯಾವಾಗಲೂ ಹಾಗೆ, ಕಾರ್ಯಕ್ಷಮತೆಯ ವೆಚ್ಚದಲ್ಲಿ ಕಳುಹಿಸುವ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹೆಚ್ಚು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿಸಲು ಒಂದು ಮಾರ್ಗವಿದೆ. ಈ ಬಫರ್‌ನ ಗಾತ್ರವನ್ನು 0 ಗೆ ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಕಳುಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಥ್ರೆಡ್ ಅನ್ನು ಬ್ರೋಕರ್‌ಗೆ ಸಂದೇಶ ವರ್ಗಾವಣೆ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ, ಈ ಕೆಳಗಿನಂತೆ:

RecordMetadata metadata = producer.send(record).get();

ಸಂದೇಶಗಳನ್ನು ಓದುವ ಕುರಿತು ಇನ್ನಷ್ಟು

ಸಂದೇಶಗಳನ್ನು ಓದುವುದು ಹೆಚ್ಚುವರಿ ಸಂಕೀರ್ಣತೆಗಳನ್ನು ಹೊಂದಿದೆ, ಅದರ ಬಗ್ಗೆ ಊಹಿಸಬೇಕಾಗಿದೆ. JMS API ಗಿಂತ ಭಿನ್ನವಾಗಿ, ಸಂದೇಶಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಸಂದೇಶ ಕೇಳುಗನನ್ನು ಚಲಾಯಿಸಬಹುದು, ದಿ ಗ್ರಾಹಕ ಕಾಫ್ಕಾ ಮಾತ್ರ ಸಮೀಕ್ಷೆಗಳು. ವಿಧಾನವನ್ನು ಹತ್ತಿರದಿಂದ ನೋಡೋಣ ಮತದಾನ()ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ:

ConsumerRecords < K, V > poll(long timeout);

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

ಅಧ್ಯಾಯ 2 ರಲ್ಲಿ ಚರ್ಚಿಸಿದಂತೆ, ಸಂದೇಶಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಅಥವಾ ಯಶಸ್ವಿಯಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ನಂತರ ಅವುಗಳಿಗೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಾವು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಅಥವಾ ಅದು ಸ್ಥಗಿತಗೊಂಡರೆ. JMS ನಲ್ಲಿ, ಇದನ್ನು ಸ್ವೀಕೃತಿ ಮೋಡ್ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗಿದೆ. ಬ್ರೋಕರ್ ಯಶಸ್ವಿಯಾಗಿ ಸಂಸ್ಕರಿಸಿದ ಸಂದೇಶವನ್ನು ಅಳಿಸುತ್ತಾರೆ, ಅಥವಾ ಕಚ್ಚಾ ಅಥವಾ ನಕಲಿ ಸಂದೇಶವನ್ನು ಮರು-ವಿತರಿಸುತ್ತಾರೆ (ವ್ಯವಹಾರಗಳನ್ನು ಬಳಸಲಾಗಿದೆ ಎಂದು ಊಹಿಸಿ).
ಕಾಫ್ಕಾ ತುಂಬಾ ವಿಭಿನ್ನವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ. ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ನಂತರ ಬ್ರೋಕರ್‌ನಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ಅಳಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು ವೈಫಲ್ಯದ ಮೇಲೆ ಏನಾಗುತ್ತದೆ ಎಂಬುದು ಪ್ರೂಫ್ ರೀಡಿಂಗ್ ಕೋಡ್‌ನ ಜವಾಬ್ದಾರಿಯಾಗಿದೆ.

ನಾವು ಹೇಳಿದಂತೆ, ಗ್ರಾಹಕರ ಗುಂಪು ಲಾಗ್‌ನಲ್ಲಿ ಆಫ್‌ಸೆಟ್‌ನೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಈ ಆಫ್‌ಸೆಟ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಲಾಗ್ ಸ್ಥಾನವು ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ನೀಡಬೇಕಾದ ಮುಂದಿನ ಸಂದೇಶಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ ಮತದಾನ(). ಈ ಆಫ್ಸೆಟ್ ಹೆಚ್ಚಾಗುವ ಸಮಯವು ಓದುವಿಕೆಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ.

ಹಿಂದೆ ಚರ್ಚಿಸಿದ ಓದುವ ಮಾದರಿಗೆ ಹಿಂತಿರುಗಿ, ಸಂದೇಶ ಪ್ರಕ್ರಿಯೆಯು ಮೂರು ಹಂತಗಳನ್ನು ಒಳಗೊಂಡಿದೆ:

ಓದುವುದಕ್ಕಾಗಿ ಸಂದೇಶವನ್ನು ಹಿಂಪಡೆಯಿರಿ.
ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ.
ಸಂದೇಶವನ್ನು ದೃಢೀಕರಿಸಿ.

ಕಾಫ್ಕಾ ಗ್ರಾಹಕರು ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಯೊಂದಿಗೆ ಬರುತ್ತಾರೆ enable.auto.commit. "ಸ್ವಯಂ" ಪದವನ್ನು ಹೊಂದಿರುವ ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿರುವಂತೆ ಇದು ಆಗಾಗ್ಗೆ ಬಳಸಲಾಗುವ ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್ ಆಗಿದೆ.

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

ಕಾಫ್ಕಾ 0.10 ರಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಕೋಡ್ ಅನ್ನು ಬದಲಾಯಿಸಲಾಗಿದೆ ಆದ್ದರಿಂದ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಂತೆ ಕ್ಲೈಂಟ್ ಲೈಬ್ರರಿಯಿಂದ ಬದ್ಧತೆಯನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಪ್ರಚೋದಿಸಲಾಗುತ್ತದೆ auto.commit.interval.ms. ಈ ನಡವಳಿಕೆಯು JMS AUTO_ACKNOWLEDGE ಮತ್ತು DUPS_OK_ACKNOWLEDGE ಮೋಡ್‌ಗಳ ನಡುವೆ ಎಲ್ಲೋ ಇದೆ. ಸ್ವಯಂಕಮಿಟ್ ಅನ್ನು ಬಳಸುವಾಗ, ಸಂದೇಶಗಳನ್ನು ವಾಸ್ತವವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಲೆಕ್ಕಿಸದೆ ಬದ್ಧರಾಗಬಹುದು - ಇದು ನಿಧಾನಗತಿಯ ಗ್ರಾಹಕರ ಸಂದರ್ಭದಲ್ಲಿ ಸಂಭವಿಸಬಹುದು. ಗ್ರಾಹಕರು ಸ್ಥಗಿತಗೊಳಿಸಿದರೆ, ಮುಂದಿನ ಗ್ರಾಹಕರು ಸಂದೇಶಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ, ಬದ್ಧ ಸ್ಥಾನದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಇದು ತಪ್ಪಿದ ಸಂದೇಶಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕಾಫ್ಕಾ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲಿಲ್ಲ, ಓದುವ ಕೋಡ್ ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಿಲ್ಲ.

ಈ ಮೋಡ್ ಆವೃತ್ತಿ 0.9 ನಲ್ಲಿರುವಂತೆ ಅದೇ ಭರವಸೆಯನ್ನು ಹೊಂದಿದೆ: ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು, ಆದರೆ ಅದು ವಿಫಲವಾದರೆ, ಆಫ್‌ಸೆಟ್ ಬದ್ಧವಾಗಿಲ್ಲದಿರಬಹುದು, ಇದು ವಿತರಣೆಯನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ. ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ನೀವು ಹೆಚ್ಚು ಸಂದೇಶಗಳನ್ನು ಪಡೆಯುತ್ತೀರಿ ಮತದಾನ(), ಈ ಸಮಸ್ಯೆ ಹೆಚ್ಚು.

ಪುಟ 21 ರಲ್ಲಿ "ಸರದಿಯಿಂದ ಸಂದೇಶಗಳನ್ನು ಓದುವುದು" ನಲ್ಲಿ ಚರ್ಚಿಸಿದಂತೆ, ವೈಫಲ್ಯದ ಮೋಡ್‌ಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡಾಗ ಸಂದೇಶ ಕಳುಹಿಸುವ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂದೇಶದ ಒಂದು-ಬಾರಿ ವಿತರಣೆಯಂತಹ ವಿಷಯವಿಲ್ಲ.

ಕಾಫ್ಕಾದಲ್ಲಿ, ಆಫ್‌ಸೆಟ್ (ಆಫ್‌ಸೆಟ್) ಮಾಡಲು (ಬದ್ಧರಾಗಲು) ಎರಡು ಮಾರ್ಗಗಳಿವೆ: ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮತ್ತು ಹಸ್ತಚಾಲಿತವಾಗಿ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ, ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದರೆ, ಆದರೆ ಕಮಿಟ್ ಮಾಡುವ ಮೊದಲು ವಿಫಲವಾದರೆ ಸಂದೇಶಗಳನ್ನು ಹಲವಾರು ಬಾರಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು. ಬದ್ಧತೆಯು ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಸಂಭವಿಸಿದಲ್ಲಿ ಮತ್ತು ಅದನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಮೊದಲು ನಿಮ್ಮ ಕೋಡ್ ಪೂರ್ಣಗೊಂಡಿದ್ದರೆ (ಬಹುಶಃ ಕಾಫ್ಕಾ 0.9 ಮತ್ತು ಹಿಂದಿನದು) ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸದಿರಲು ನೀವು ಆಯ್ಕೆ ಮಾಡಬಹುದು.

ನಿಯತಾಂಕವನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ನೀವು ಕಾಫ್ಕಾ ಗ್ರಾಹಕ API ನಲ್ಲಿ ಹಸ್ತಚಾಲಿತ ಆಫ್‌ಸೆಟ್ ಕಮಿಟ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು enable.auto.commit ಕೆಳಗಿನ ವಿಧಾನಗಳಲ್ಲಿ ಒಂದನ್ನು ತಪ್ಪಾಗಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಕರೆಯಲು:

void commitSync();
void commitAsync();

ನೀವು "ಕನಿಷ್ಠ ಒಮ್ಮೆ" ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಒಪ್ಪಿಸಬೇಕು ಕಮಿಟ್ ಸಿಂಕ್()ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದ ತಕ್ಷಣ ಈ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮೂಲಕ.

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

ನಕಲಿ ಸಂದೇಶವನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹಿಂತಿರುಗಿಸಿ. ಸಮಸ್ಯಾತ್ಮಕ ಪೇಲೋಡ್‌ಗಳು ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಸ್ಥಗಿತಗಳಿಂದ ಉಂಟಾಗುವ ವಿನಾಯಿತಿಗಳನ್ನು ಗ್ರಾಹಕರು ಸ್ವತಃ ನಿರ್ವಹಿಸಬೇಕು, ಏಕೆಂದರೆ ಅವರು ಸಂದೇಶಗಳನ್ನು ಮರು-ವಿತರಣೆ ಮಾಡಲು ಬ್ರೋಕರ್ ಅನ್ನು ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ.
ಒಂದು ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಬಹು ವಿಷಯಗಳಿಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಿ. ನಾವು ಶೀಘ್ರದಲ್ಲೇ ನೋಡುವಂತೆ, ವಿಭಿನ್ನ ವಿಷಯಗಳು ಮತ್ತು ವಿಭಾಗಗಳ ಮೇಲಿನ ನಿಯಂತ್ರಣವು ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿಭಿನ್ನ ಯಂತ್ರಗಳಲ್ಲಿ ನೆಲೆಸಬಹುದು, ಅದು ಕಳುಹಿಸಿದಾಗ ವಹಿವಾಟುಗಳನ್ನು ಸಂಯೋಜಿಸುವುದಿಲ್ಲ. ಈ ಬರವಣಿಗೆಯ ಸಮಯದಲ್ಲಿ, KIP-98 ನೊಂದಿಗೆ ಇದನ್ನು ಸಾಧ್ಯವಾಗಿಸಲು ಕೆಲವು ಕೆಲಸವನ್ನು ಮಾಡಲಾಗಿದೆ.
ಒಂದು ವಿಷಯದಿಂದ ಒಂದು ಸಂದೇಶವನ್ನು ಇನ್ನೊಂದು ವಿಷಯಕ್ಕೆ ಇನ್ನೊಂದು ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುವುದರೊಂದಿಗೆ ಓದುವುದನ್ನು ಸಂಯೋಜಿಸಿ. ಮತ್ತೆ, ಕಾಫ್ಕಾ ವಾಸ್ತುಶೈಲಿಯು ಒಂದು ಬಸ್‌ನಂತೆ ಚಲಿಸುವ ಅನೇಕ ಸ್ವತಂತ್ರ ಯಂತ್ರಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಮತ್ತು ಇದನ್ನು ಮರೆಮಾಡಲು ಯಾವುದೇ ಪ್ರಯತ್ನವನ್ನು ಮಾಡಲಾಗಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನೀವು ಲಿಂಕ್ ಮಾಡಲು ಅನುಮತಿಸುವ ಯಾವುದೇ API ಘಟಕಗಳಿಲ್ಲ ಗ್ರಾಹಕ и ನಿರ್ಮಾಪಕ ವಹಿವಾಟಿನಲ್ಲಿ. JMS ನಲ್ಲಿ, ಇದನ್ನು ವಸ್ತುವಿನ ಮೂಲಕ ಒದಗಿಸಲಾಗುತ್ತದೆ ಸೆಷನ್ಅದರಿಂದ ರಚಿಸಲಾಗಿದೆ ಸಂದೇಶ ನಿರ್ಮಾಪಕರು и ಸಂದೇಶ ಗ್ರಾಹಕರು.

ನಾವು ವಹಿವಾಟುಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಸಾಂಪ್ರದಾಯಿಕ ಸಂದೇಶ ಕಳುಹಿಸುವ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಒದಗಿಸಲಾದ ಶಬ್ದಗಳಿಗೆ ಹತ್ತಿರವಾದ ಶಬ್ದಾರ್ಥವನ್ನು ನಾವು ಹೇಗೆ ಒದಗಿಸಬಹುದು?

ಗ್ರಾಹಕ ಕುಸಿತದ ಸಮಯದಲ್ಲಿ ಸಂದೇಶವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಮೊದಲು ಗ್ರಾಹಕರ ಆಫ್‌ಸೆಟ್ ಹೆಚ್ಚಾಗುವ ಸಾಧ್ಯತೆಯಿದ್ದರೆ, ಗ್ರಾಹಕರು ವಿಭಜನೆಯನ್ನು ನಿಯೋಜಿಸಿದಾಗ ಅದರ ಗ್ರಾಹಕ ಗುಂಪು ಸಂದೇಶವನ್ನು ತಪ್ಪಿಸಿಕೊಂಡರೆ ಅದನ್ನು ತಿಳಿದುಕೊಳ್ಳಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ. ಆದ್ದರಿಂದ ಆಫ್‌ಸೆಟ್ ಅನ್ನು ಹಿಂದಿನ ಸ್ಥಾನಕ್ಕೆ ರಿವೈಂಡ್ ಮಾಡುವುದು ಒಂದು ತಂತ್ರವಾಗಿದೆ. ಕಾಫ್ಕಾ ಗ್ರಾಹಕ API ಇದಕ್ಕಾಗಿ ಈ ಕೆಳಗಿನ ವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

ವಿಧಾನ ಹುಡುಕು () ವಿಧಾನದೊಂದಿಗೆ ಬಳಸಬಹುದು
ಆಫ್‌ಸೆಟ್‌ಗಳಿಗಾಗಿ ಟೈಮ್ಸ್(ನಕ್ಷೆ ಹುಡುಕಾಟಕ್ಕೆ ಸಮಯಮುದ್ರೆಗಳು) ಹಿಂದಿನ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಹಂತದಲ್ಲಿ ಒಂದು ಸ್ಥಿತಿಗೆ ರಿವೈಂಡ್ ಮಾಡಲು.

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

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

ವೈಯಕ್ತಿಕ ಅವಲೋಕನಗಳು ಸಂದೇಶಗಳ ತೀವ್ರತೆ ಹೆಚ್ಚಾದಂತೆ, ಪ್ರತಿಯೊಂದು ಸಂದೇಶದ ಮೌಲ್ಯವು ಕಡಿಮೆಯಾಗುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಒಟ್ಟುಗೂಡಿದ ರೂಪದಲ್ಲಿ ವೀಕ್ಷಿಸಿದಾಗ ದೊಡ್ಡ ಸಂದೇಶಗಳು ಮೌಲ್ಯಯುತವಾಗಿರುತ್ತವೆ.

ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ

ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಗೆ ಕಾಫ್ಕಾ ಅವರ ವಿಧಾನವು ActiveMQ ನ ವಿಧಾನಕ್ಕಿಂತ ಬಹಳ ಭಿನ್ನವಾಗಿದೆ. ಕಾಫ್ಕಾವನ್ನು ಸ್ಕೇಲ್-ಔಟ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಸುತ್ತಲೂ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ಎಲ್ಲಾ ಬ್ರೋಕರ್ ನಿದರ್ಶನಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ವಿತರಿಸುತ್ತವೆ.

ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್ ವಿವಿಧ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಬಹು ಬ್ರೋಕರ್ ನಿದರ್ಶನಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಕಾಫ್ಕಾವನ್ನು ಸಾಮಾನ್ಯ ಸ್ವತಂತ್ರ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಚಲಾಯಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಅಲ್ಲಿ ಪ್ರತಿ ನೋಡ್ ತನ್ನದೇ ಆದ ಮೀಸಲಾದ ಸಂಗ್ರಹಣೆಯನ್ನು ಹೊಂದಿದೆ. ನೆಟ್‌ವರ್ಕ್ ಲಗತ್ತಿಸಲಾದ ಸಂಗ್ರಹಣೆಯ (SAN) ಬಳಕೆಯನ್ನು ಶಿಫಾರಸು ಮಾಡುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಬಹು ಕಂಪ್ಯೂಟ್ ನೋಡ್‌ಗಳು ಸಮಯಕ್ಕೆ ಸ್ಪರ್ಧಿಸಬಹುದು.Ыಇ ಶೇಖರಣಾ ಮಧ್ಯಂತರಗಳು ಮತ್ತು ಸಂಘರ್ಷಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತವೆ.

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

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

ಮೂಲ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಕೆಳಗಿನ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿಷಯವನ್ನು ರಚಿಸಲಾಗಿದೆ:

ವಿಭಾಗಗಳ ಸಂಖ್ಯೆ. ಮೊದಲೇ ಚರ್ಚಿಸಿದಂತೆ, ಇಲ್ಲಿ ಬಳಸಲಾದ ನಿಖರವಾದ ಮೌಲ್ಯವು ಸಮಾನಾಂತರ ಓದುವಿಕೆಯ ಅಪೇಕ್ಷಿತ ಮಟ್ಟವನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ.
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಎಷ್ಟು ಬ್ರೋಕರ್ ನಿದರ್ಶನಗಳು ಈ ವಿಭಾಗಕ್ಕೆ ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿರಬೇಕು ಎಂಬುದನ್ನು ರೆಪ್ಲಿಕೇಶನ್ ಫ್ಯಾಕ್ಟರ್ (ಅಂಶ) ನಿರ್ಧರಿಸುತ್ತದೆ.

ಸಮನ್ವಯಕ್ಕಾಗಿ ZooKeepers ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಬ್ರೋಕರ್‌ಗಳ ನಡುವೆ ಹೊಸ ವಿಭಾಗಗಳನ್ನು ತಕ್ಕಮಟ್ಟಿಗೆ ವಿತರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ. ನಿಯಂತ್ರಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಏಕೈಕ ನಿದರ್ಶನದಿಂದ ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.

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

ನಾಯಕ ಹೊಂದಿರುವ ಎಲ್ಲಾ ಸಂದೇಶಗಳನ್ನು ಹೊಂದಿರುವ ಅನುಯಾಯಿಯನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಪ್ರತಿಕೃತಿ (ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಸ್ಥಿತಿಯಲ್ಲಿರುವ ಪ್ರತಿಕೃತಿ, ಇನ್-ಸಿಂಕ್ ಪ್ರತಿಕೃತಿ). ವಿಭಜನೆಗೆ ನಾಯಕನಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಬ್ರೋಕರ್ ಕೆಳಗಿಳಿದರೆ, ಆ ವಿಭಜನೆಗೆ ನವೀಕೃತ ಅಥವಾ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಯಾವುದೇ ಬ್ರೋಕರ್ ನಾಯಕನ ಪಾತ್ರವನ್ನು ವಹಿಸಿಕೊಳ್ಳಬಹುದು. ಇದು ನಂಬಲಾಗದಷ್ಟು ಸಮರ್ಥನೀಯ ವಿನ್ಯಾಸವಾಗಿದೆ.

ನಿರ್ಮಾಪಕ ಸಂರಚನೆಯ ಭಾಗವು ಪ್ಯಾರಾಮೀಟರ್ ಆಗಿದೆ ಅಕ್ಗಳು, ಅಪ್ಲಿಕೇಶನ್ ಥ್ರೆಡ್ ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವ ಮೊದಲು ಸಂದೇಶದ ಸ್ವೀಕೃತಿಯನ್ನು ಎಷ್ಟು ಪ್ರತಿಕೃತಿಗಳು ಅಂಗೀಕರಿಸಬೇಕು (ಸ್ವೀಕರಿಸಬೇಕು) ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: 0, 1, ಅಥವಾ ಎಲ್ಲಾ. ಗೆ ಹೊಂದಿಸಿದರೆ ಎಲ್ಲಾ, ನಂತರ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ, ವಿಷಯದ ಸೆಟ್ಟಿಂಗ್‌ನಿಂದ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಹಲವಾರು ಸೂಚನೆಗಳಿಂದ (ಸ್ವತಃ ಸೇರಿದಂತೆ) ದಾಖಲೆಯ ದೃಢೀಕರಣಗಳನ್ನು (ಸ್ವೀಕರಿಸುವಿಕೆಗಳು) ಸ್ವೀಕರಿಸಿದ ತಕ್ಷಣ ನಾಯಕನು ನಿರ್ಮಾಪಕರಿಗೆ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ. min.insync.replicas (ಡೀಫಾಲ್ಟ್ 1). ಸಂದೇಶವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪುನರಾವರ್ತಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನಿರ್ಮಾಪಕರು ಅಪ್ಲಿಕೇಶನ್ ವಿನಾಯಿತಿಯನ್ನು ಎಸೆಯುತ್ತಾರೆ (NotEnoughReplicas ಅಥವಾ NotEnoughReplicasAfterAppend).

ವಿಶಿಷ್ಟವಾದ ಸಂರಚನೆಯು 3 (1 ನಾಯಕ, ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ 2 ಅನುಯಾಯಿಗಳು) ಮತ್ತು ನಿಯತಾಂಕದ ಪ್ರತಿಕೃತಿ ಅಂಶದೊಂದಿಗೆ ವಿಷಯವನ್ನು ರಚಿಸುತ್ತದೆ min.insync.replicas 2 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರದಂತೆ ವಿಷಯ ವಿಭಾಗವನ್ನು ನಿರ್ವಹಿಸುವ ಬ್ರೋಕರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಿಗೆ ಕ್ಲಸ್ಟರ್ ಕೆಳಗೆ ಹೋಗಲು ಅನುಮತಿಸುತ್ತದೆ.

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

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

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

ಒಂದೇ ಕಾಫ್ಕಾ ಬ್ರೋಕರ್‌ಗಿಂತ ಕಾಫ್ಕಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹೆಚ್ಚು ಉತ್ತಮ ಕಾರ್ಯನಿರ್ವಹಣೆ ಸಾಧ್ಯ, ಏಕೆಂದರೆ ವಿಷಯ ವಿಭಾಗಗಳು ಹಲವು ಪ್ರತ್ಯೇಕ ಯಂತ್ರಗಳಲ್ಲಿ ಅಳೆಯಬಹುದು.

ಫಲಿತಾಂಶಗಳು

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

ಹಿಂದಿನ ಅನುವಾದಿಸಿದ ಭಾಗ: ಸಂದೇಶ ದಲ್ಲಾಳಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು. ActiveMQ ಮತ್ತು Kafka ನೊಂದಿಗೆ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯ ಯಂತ್ರಶಾಸ್ತ್ರವನ್ನು ಕಲಿಯುವುದು. ಅಧ್ಯಾಯ 1

ಅನುವಾದ ಮಾಡಲಾಗಿದೆ: tele.gg/middle_java

ಮುಂದುವರೆಸಲು ...

ನೋಂದಾಯಿತ ಬಳಕೆದಾರರು ಮಾತ್ರ ಸಮೀಕ್ಷೆಯಲ್ಲಿ ಭಾಗವಹಿಸಬಹುದು. ಸೈನ್ ಇನ್ ಮಾಡಿ, ದಯವಿಟ್ಟು.

ನಿಮ್ಮ ಸಂಸ್ಥೆಯಲ್ಲಿ ಕಾಫ್ಕಾ ಬಳಸಲಾಗಿದೆಯೇ?

ಹೌದು
ಯಾವುದೇ
ಹಿಂದೆ ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಈಗ ಇಲ್ಲ
ನಾವು ಬಳಸಲು ಯೋಜಿಸಿದ್ದೇವೆ

38 ಬಳಕೆದಾರರು ಮತ ಹಾಕಿದ್ದಾರೆ. 8 ಬಳಕೆದಾರರು ದೂರ ಉಳಿದಿದ್ದಾರೆ.

ಮೂಲ: www.habr.com