В ಕೊನೆಯ ಲೇಖನ ದೋಷ ಸಹಿಷ್ಣುತೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಗಾಗಿ ನಾವು RabbitMQ ಕ್ಲಸ್ಟರಿಂಗ್ ಅನ್ನು ನೋಡಿದ್ದೇವೆ. ಈಗ ನಾವು ಅಪಾಚೆ ಕಾಫ್ಕಾವನ್ನು ಆಳವಾಗಿ ಅಗೆಯೋಣ.

ಇಲ್ಲಿ ಪ್ರತಿಕೃತಿಯ ಘಟಕವು ವಿಭಜನೆಯಾಗಿದೆ. ಪ್ರತಿಯೊಂದು ವಿಷಯವು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ವಿಭಾಗಗಳನ್ನು ಹೊಂದಿದೆ. ಪ್ರತಿ ವಿಭಾಗವು ಅನುಯಾಯಿಗಳೊಂದಿಗೆ ಅಥವಾ ಇಲ್ಲದೆ ನಾಯಕನನ್ನು ಹೊಂದಿದೆ. ವಿಷಯವನ್ನು ರಚಿಸುವಾಗ, ನೀವು ವಿಭಾಗಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರತಿಕೃತಿ ಗುಣಾಂಕವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೀರಿ. ಸಾಮಾನ್ಯ ಮೌಲ್ಯವು 3 ಆಗಿದೆ, ಅಂದರೆ ಮೂರು ಪ್ರತಿಕೃತಿಗಳು: ಒಬ್ಬ ನಾಯಕ ಮತ್ತು ಇಬ್ಬರು ಅನುಯಾಯಿಗಳು.

ಅಕ್ಕಿ. 1. ಮೂರು ದಲ್ಲಾಳಿಗಳ ನಡುವೆ ನಾಲ್ಕು ವಿಭಾಗಗಳನ್ನು ವಿತರಿಸಲಾಗಿದೆ

ಎಲ್ಲಾ ಓದಲು ಮತ್ತು ಬರೆಯಲು ವಿನಂತಿಗಳು ನಾಯಕನಿಗೆ ಹೋಗುತ್ತವೆ. ಇತ್ತೀಚಿನ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಅನುಯಾಯಿಗಳು ನಿಯತಕಾಲಿಕವಾಗಿ ನಾಯಕನಿಗೆ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ. ಗ್ರಾಹಕರು ಎಂದಿಗೂ ಅನುಯಾಯಿಗಳ ಕಡೆಗೆ ತಿರುಗುವುದಿಲ್ಲ; ಎರಡನೆಯದು ಪುನರಾವರ್ತನೆ ಮತ್ತು ತಪ್ಪು ಸಹಿಷ್ಣುತೆಗಾಗಿ ಮಾತ್ರ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ.

ವಿಭಜನೆಯ ವೈಫಲ್ಯ

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

ಬ್ರೋಕರ್ 3 ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ತೊರೆಯುತ್ತಾನೆ ಮತ್ತು ಬ್ರೋಕರ್ 2 ನಲ್ಲಿ ವಿಭಾಗ 2 ಕ್ಕೆ ಹೊಸ ನಾಯಕನನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 2. ಬ್ರೋಕರ್ 3 ಸಾಯುತ್ತಾನೆ ಮತ್ತು ಬ್ರೋಕರ್ 2 ನಲ್ಲಿ ಅವನ ಅನುಯಾಯಿಯು ವಿಭಜನೆ 2 ರ ಹೊಸ ನಾಯಕನಾಗಿ ಆಯ್ಕೆಯಾಗುತ್ತಾನೆ

ನಂತರ ಬ್ರೋಕರ್ 1 ಎಲೆಗಳು ಮತ್ತು ವಿಭಾಗ 1 ಸಹ ತನ್ನ ನಾಯಕನನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಅದರ ಪಾತ್ರವು ಬ್ರೋಕರ್ 2 ಗೆ ಹಾದುಹೋಗುತ್ತದೆ.

ಅಕ್ಕಿ. 3. ಒಬ್ಬ ಬ್ರೋಕರ್ ಉಳಿದಿದ್ದಾರೆ. ಎಲ್ಲಾ ನಾಯಕರು ಶೂನ್ಯ ಪುನರುಕ್ತಿಯೊಂದಿಗೆ ಒಂದು ಬ್ರೋಕರ್‌ನಲ್ಲಿದ್ದಾರೆ

ಬ್ರೋಕರ್ 1 ಆನ್‌ಲೈನ್‌ಗೆ ಹಿಂತಿರುಗಿದಾಗ, ಅದು ನಾಲ್ಕು ಅನುಯಾಯಿಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಕೆಲವು ಪುನರಾವರ್ತನೆಯನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ ಎಲ್ಲಾ ನಾಯಕರು ಇನ್ನೂ ಬ್ರೋಕರ್ 2 ನಲ್ಲಿಯೇ ಇದ್ದರು.

ಅಕ್ಕಿ. 4. ನಾಯಕರು ಬ್ರೋಕರ್ 2 ನಲ್ಲಿ ಉಳಿಯುತ್ತಾರೆ

ಬ್ರೋಕರ್ 3 ಬಂದಾಗ, ನಾವು ಪ್ರತಿ ವಿಭಾಗಕ್ಕೆ ಮೂರು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ. ಆದರೆ ಎಲ್ಲಾ ನಾಯಕರು ಇನ್ನೂ ಬ್ರೋಕರ್ 2 ನಲ್ಲಿದ್ದಾರೆ.

ಅಕ್ಕಿ. 5. ದಲ್ಲಾಳಿಗಳ ಮರುಸ್ಥಾಪನೆಯ ನಂತರ ನಾಯಕರ ಅಸಮತೋಲಿತ ನಿಯೋಜನೆ 1 ಮತ್ತು 3

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

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

ಇದನ್ನು ಸರಿಪಡಿಸಲು, ಕಾಫ್ಕಾ ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ನೀಡುತ್ತದೆ:

• ಆಯ್ಕೆ auto.leader.rebalance.enable=true ನಿಯಂತ್ರಕ ನೋಡ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಾಯಕರನ್ನು ಆದ್ಯತೆಯ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಮರುಹೊಂದಿಸಲು ಮತ್ತು ಆ ಮೂಲಕ ಏಕರೂಪದ ವಿತರಣೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
• ನಿರ್ವಾಹಕರು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು kafka-preferred-replica-election.sh ಹಸ್ತಚಾಲಿತ ಮರುನಿಯೋಜನೆಗಾಗಿ.

ಅಕ್ಕಿ. 6. ಮರುಸಮತೋಲನದ ನಂತರ ಪ್ರತಿಕೃತಿಗಳು

ಇದು ವೈಫಲ್ಯದ ಸರಳೀಕೃತ ಆವೃತ್ತಿಯಾಗಿದೆ, ಆದರೆ ವಾಸ್ತವವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗಿದೆ, ಆದರೂ ಇಲ್ಲಿ ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಏನೂ ಇಲ್ಲ. ಇದು ಎಲ್ಲಾ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರುತ್ತದೆ (ಇನ್-ಸಿಂಕ್ ರೆಪ್ಲಿಕಾಸ್, ISR).

ಸಿಂಕ್ರೊನೈಸ್ಡ್ ರೆಪ್ಲಿಕಾಸ್ (ISR)

ISR ಎನ್ನುವುದು "ಸಿಂಕ್ರೊನೈಸ್" (ಇನ್-ಸಿಂಕ್) ಎಂದು ಪರಿಗಣಿಸಲಾದ ವಿಭಾಗದ ಪ್ರತಿಕೃತಿಗಳ ಒಂದು ಗುಂಪಾಗಿದೆ. ನಾಯಕನಿದ್ದಾನೆ, ಆದರೆ ಅನುಯಾಯಿಗಳು ಇಲ್ಲದಿರಬಹುದು. ಮಧ್ಯಂತರ ಅವಧಿ ಮುಗಿಯುವ ಮೊದಲು ಎಲ್ಲಾ ನಾಯಕರ ಸಂದೇಶಗಳ ನಿಖರವಾದ ಪ್ರತಿಗಳನ್ನು ಮಾಡಿದರೆ ಅನುಯಾಯಿಯನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. replica.lag.time.max.ms.

ಒಂದು ವೇಳೆ ISR ಸೆಟ್‌ನಿಂದ ಅನುಯಾಯಿಯನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ:

• ಮಧ್ಯಂತರಕ್ಕೆ ಆಯ್ಕೆ ಮಾಡಲು ವಿನಂತಿಯನ್ನು ಮಾಡಲಿಲ್ಲ replica.lag.time.max.ms (ಸತ್ತೆಂದು ಭಾವಿಸಲಾಗಿದೆ)
• ಮಧ್ಯಂತರದಲ್ಲಿ ನವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ replica.lag.time.max.ms (ನಿಧಾನವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ)

ಅನುಯಾಯಿಗಳು ಮಧ್ಯಂತರದಲ್ಲಿ ಮಾದರಿ ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತಾರೆ replica.fetch.wait.max.ms, ಇದು 500ms ಗೆ ಡಿಫಾಲ್ಟ್ ಆಗುತ್ತದೆ.

ISR ನ ಉದ್ದೇಶವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿವರಿಸಲು, ನಾವು ನಿರ್ಮಾಪಕರಿಂದ ದೃಢೀಕರಣಗಳನ್ನು ಮತ್ತು ಕೆಲವು ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶಗಳನ್ನು ನೋಡಬೇಕಾಗಿದೆ. ಬ್ರೋಕರ್ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸಿದಾಗ ನಿರ್ಮಾಪಕರು ಆಯ್ಕೆ ಮಾಡಬಹುದು:

• acks=0, ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸಲಾಗಿಲ್ಲ
• acks=1, ನಾಯಕನು ತನ್ನ ಸ್ಥಳೀಯ ಲಾಗ್‌ಗೆ ಸಂದೇಶವನ್ನು ಬರೆದ ನಂತರ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ
• acks=ಎಲ್ಲಾ, ISR ನಲ್ಲಿನ ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳು ಸ್ಥಳೀಯ ಲಾಗ್‌ಗಳಿಗೆ ಸಂದೇಶವನ್ನು ಬರೆದ ನಂತರ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ

ಕಾಫ್ಕಾ ಪರಿಭಾಷೆಯಲ್ಲಿ, ISR ಸಂದೇಶವನ್ನು ಉಳಿಸಿದ್ದರೆ, ಅದು "ಬದ್ಧವಾಗಿದೆ". ಅಕ್ಸ್=ಎಲ್ಲವೂ ಸುರಕ್ಷಿತ ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ಹೆಚ್ಚುವರಿ ವಿಳಂಬವನ್ನು ಕೂಡ ಸೇರಿಸುತ್ತದೆ. ವೈಫಲ್ಯದ ಎರಡು ಉದಾಹರಣೆಗಳನ್ನು ನೋಡೋಣ ಮತ್ತು ವಿಭಿನ್ನ 'ಅಕ್ಸ್' ಆಯ್ಕೆಗಳು ISR ಪರಿಕಲ್ಪನೆಯೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ.

ಅಕ್ಸ್=1 ಮತ್ತು ISR

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ಎಲ್ಲಾ ಅನುಯಾಯಿಗಳಿಂದ ಪ್ರತಿ ಸಂದೇಶವನ್ನು ಉಳಿಸಲು ನಾಯಕ ಕಾಯದಿದ್ದರೆ, ನಾಯಕ ವಿಫಲವಾದರೆ ಡೇಟಾ ನಷ್ಟ ಸಾಧ್ಯ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ. ಸಿಂಕ್ ಮಾಡದ ಅನುಯಾಯಿಗಳಿಗೆ ನ್ಯಾವಿಗೇಟ್ ಮಾಡುವುದನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು ಅಥವಾ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು unclean.leader.election.enable.

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ತಯಾರಕರು ಮೌಲ್ಯ acks=1 ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ. ವಿಭಾಗವನ್ನು ಎಲ್ಲಾ ಮೂರು ದಲ್ಲಾಳಿಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗಿದೆ. ಬ್ರೋಕರ್ 3 ಹಿಂದೆ ಇದೆ, ಇದು ಎಂಟು ಸೆಕೆಂಡುಗಳ ಹಿಂದೆ ನಾಯಕನೊಂದಿಗೆ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಮತ್ತು ಈಗ 7456 ಸಂದೇಶಗಳ ಹಿಂದೆ ಇದೆ. ಬ್ರೋಕರ್ 1 ಕೇವಲ ಒಂದು ಸೆಕೆಂಡ್ ಹಿಂದಿದ್ದರು. ನಮ್ಮ ನಿರ್ಮಾಪಕರು ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ನಾಯಕನು ಕಾಯದೆ ಇರುವ ನಿಧಾನ ಅಥವಾ ಸತ್ತ ಅನುಯಾಯಿಗಳ ಓವರ್‌ಹೆಡ್ ಇಲ್ಲದೆ ತ್ವರಿತವಾಗಿ ಬ್ಯಾಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ.

ಅಕ್ಕಿ. 7. ಮೂರು ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ISR

ಬ್ರೋಕರ್ 2 ವಿಫಲಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಿರ್ಮಾಪಕರು ಸಂಪರ್ಕ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ನಾಯಕತ್ವವು ಬ್ರೋಕರ್ 1 ಗೆ ಹೋದ ನಂತರ, ನಾವು 123 ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಬ್ರೋಕರ್ 1 ರ ಅನುಯಾಯಿ ISR ನ ಭಾಗವಾಗಿದ್ದರು, ಆದರೆ ಅದು ಬಿದ್ದಾಗ ನಾಯಕನೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಸಿಂಕ್ರೊನೈಸ್ ಆಗಿರಲಿಲ್ಲ.

ಅಕ್ಕಿ. 8. ಕ್ರ್ಯಾಶ್ ಆದಾಗ ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ

ಸಂರಚನೆಯಲ್ಲಿ bootstrap.servers ತಯಾರಕರು ಹಲವಾರು ದಲ್ಲಾಳಿಗಳನ್ನು ಪಟ್ಟಿಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಹೊಸ ವಿಭಾಗದ ನಾಯಕರಾಗಿರುವ ಇನ್ನೊಬ್ಬ ಬ್ರೋಕರ್ ಅನ್ನು ಕೇಳಬಹುದು. ಇದು ನಂತರ ಬ್ರೋಕರ್ 1 ಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ ಮತ್ತು ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 9. ಸಣ್ಣ ವಿರಾಮದ ನಂತರ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವುದು ಪುನರಾರಂಭವಾಗುತ್ತದೆ

ಬ್ರೋಕರ್ 3 ಇನ್ನೂ ಹಿಂದುಳಿದಿದೆ. ಇದು ತರಲು ವಿನಂತಿಗಳನ್ನು ಮಾಡುತ್ತದೆ ಆದರೆ ಸಿಂಕ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಬ್ರೋಕರ್‌ಗಳ ನಡುವಿನ ನಿಧಾನಗತಿಯ ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕದಿಂದಾಗಿರಬಹುದು, ಸಂಗ್ರಹಣೆ ಸಮಸ್ಯೆ ಇತ್ಯಾದಿ. ಇದನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ. ಈಗ ISR ಒಂದು ಪ್ರತಿಕೃತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ - ನಾಯಕ! ತಯಾರಕರು ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮತ್ತು ದೃಢೀಕರಣಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ.

ಅಕ್ಕಿ. 10. ಬ್ರೋಕರ್ 3 ನಲ್ಲಿ ಅನುಸರಿಸುವವರನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ

ಬ್ರೋಕರ್ 1 ಕೆಳಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು 3 ಸಂದೇಶಗಳ ನಷ್ಟದೊಂದಿಗೆ ನಾಯಕತ್ವದ ಪಾತ್ರವು ಬ್ರೋಕರ್ 15286 ಗೆ ಹೋಗುತ್ತದೆ! ತಯಾರಕರು ಸಂಪರ್ಕ ದೋಷ ಸಂದೇಶವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ. ISR ನ ಹೊರಗಿನ ನಾಯಕನಿಗೆ ಪರಿವರ್ತನೆಯು ಸೆಟ್ಟಿಂಗ್‌ನಿಂದ ಮಾತ್ರ ಸಾಧ್ಯವಾಯಿತು unclean.leader.election.enable=true. ಅದನ್ನು ಸ್ಥಾಪಿಸಿದರೆ ಸುಳ್ಳು, ನಂತರ ಪರಿವರ್ತನೆಯು ಸಂಭವಿಸುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಓದುವ ಮತ್ತು ಬರೆಯುವ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ರೋಕರ್ 1 ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ತನ್ನ ಅಖಂಡ ಡೇಟಾದೊಂದಿಗೆ ಹಿಂತಿರುಗಲು ನಾವು ಕಾಯುತ್ತೇವೆ, ಅದು ಮತ್ತೆ ನಾಯಕತ್ವವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಅಕ್ಕಿ. 11. ಬ್ರೋಕರ್ 1 ಬೀಳುತ್ತದೆ. ವೈಫಲ್ಯ ಸಂಭವಿಸಿದಾಗ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ

ನಿರ್ಮಾಪಕರು ಕೊನೆಯ ಬ್ರೋಕರ್‌ನೊಂದಿಗೆ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತಾರೆ ಮತ್ತು ಅವರು ಈಗ ವಿಭಾಗದ ನಾಯಕರಾಗಿದ್ದಾರೆ ಎಂದು ನೋಡುತ್ತಾರೆ. ಅವನು ಬ್ರೋಕರ್ 3 ಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ.

ಅಕ್ಕಿ. 12. ಸ್ವಲ್ಪ ವಿರಾಮದ ನಂತರ, ಸಂದೇಶಗಳನ್ನು ಮತ್ತೆ ವಿಭಾಗ 0 ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ

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

ಅಕ್ಸ್=ಎಲ್ಲಾ ಮತ್ತು ISR

ಈ ಸನ್ನಿವೇಶವನ್ನು ಮತ್ತೊಮ್ಮೆ ಪುನರಾವರ್ತಿಸೋಣ, ಆದರೆ ಇದರೊಂದಿಗೆ acks=ಎಲ್ಲಾ. ಬ್ರೋಕರ್ 3 ಸರಾಸರಿ ನಾಲ್ಕು ಸೆಕೆಂಡುಗಳ ಸುಪ್ತತೆಯನ್ನು ಹೊಂದಿದೆ. ತಯಾರಕರು ಇದರೊಂದಿಗೆ ಸಂದೇಶವನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ acks=ಎಲ್ಲಾ, ಮತ್ತು ಈಗ ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ISR ನಲ್ಲಿನ ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳಿಂದ ಸಂದೇಶವನ್ನು ಉಳಿಸಲು ನಾಯಕ ಕಾಯುತ್ತಾನೆ.

ಅಕ್ಕಿ. 13. ಮೂರು ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ISR. ಒಂದು ನಿಧಾನವಾಗಿರುತ್ತದೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ ರೆಕಾರ್ಡಿಂಗ್ ವಿಳಂಬವಾಗುತ್ತದೆ

ನಾಲ್ಕು ಸೆಕೆಂಡುಗಳ ಹೆಚ್ಚುವರಿ ವಿಳಂಬದ ನಂತರ, ಬ್ರೋಕರ್ 2 ಒಂದು AC ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಈಗ ಸಂಪೂರ್ಣವಾಗಿ ನವೀಕರಿಸಲಾಗಿದೆ.

ಅಕ್ಕಿ. 14. ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳು ಸಂದೇಶಗಳನ್ನು ಉಳಿಸುತ್ತವೆ ಮತ್ತು ಅಕ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತವೆ

ಬ್ರೋಕರ್ 3 ಈಗ ಮತ್ತಷ್ಟು ಹಿಂದುಳಿದಿದೆ ಮತ್ತು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ. ISR ನಲ್ಲಿ ಯಾವುದೇ ನಿಧಾನವಾದ ಪ್ರತಿಕೃತಿಗಳು ಉಳಿದಿಲ್ಲದ ಕಾರಣ ಸುಪ್ತತೆಯು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಾಗಿದೆ. ಬ್ರೋಕರ್ 2 ಈಗ ಬ್ರೋಕರ್ 1 ಗಾಗಿ ಮಾತ್ರ ಕಾಯುತ್ತಿದೆ ಮತ್ತು ಅವನು ಸರಾಸರಿ 500 ಎಂಎಸ್ ವಿಳಂಬವನ್ನು ಹೊಂದಿದ್ದಾನೆ.

ಅಕ್ಕಿ. 15. ಬ್ರೋಕರ್ 3 ರ ಪ್ರತಿಕೃತಿಯನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ

ನಂತರ ಬ್ರೋಕರ್ 2 ಬೀಳುತ್ತದೆ ಮತ್ತು ಸಂದೇಶಗಳ ನಷ್ಟವಿಲ್ಲದೆಯೇ ಬ್ರೋಕರ್ 1 ಗೆ ನಾಯಕತ್ವವು ಹಾದುಹೋಗುತ್ತದೆ.

ಅಕ್ಕಿ. 16. ಬ್ರೋಕರ್ 2 ಬೀಳುತ್ತದೆ

ತಯಾರಕರು ಹೊಸ ನಾಯಕನನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು ಅವರಿಗೆ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ISR ಈಗ ಒಂದು ಪ್ರತಿಕೃತಿಯನ್ನು ಒಳಗೊಂಡಿರುವ ಕಾರಣ ಸುಪ್ತತೆಯನ್ನು ಮತ್ತಷ್ಟು ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ! ಆದ್ದರಿಂದ ಆಯ್ಕೆ acks=ಎಲ್ಲಾ ಪುನರುಕ್ತಿ ಸೇರಿಸುವುದಿಲ್ಲ.

ಅಕ್ಕಿ. 17. ಬ್ರೋಕರ್ 1 ರ ಪ್ರತಿಕೃತಿಯು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಮುನ್ನಡೆ ಸಾಧಿಸುತ್ತದೆ

ನಂತರ ಬ್ರೋಕರ್ 1 ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ಲೀಡ್ ಬ್ರೋಕರ್ 3 ಗೆ 14238 ಸಂದೇಶಗಳ ನಷ್ಟದೊಂದಿಗೆ ಹೋಗುತ್ತದೆ!

ಅಕ್ಕಿ. 18. ಬ್ರೋಕರ್ 1 ಡೈಸ್ ಮತ್ತು ಅಶುಚಿಯಾದ ಸೆಟ್ಟಿಂಗ್‌ನೊಂದಿಗೆ ನಾಯಕತ್ವದ ಪರಿವರ್ತನೆಯು ವ್ಯಾಪಕವಾದ ಡೇಟಾ ನಷ್ಟಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ

ನಾವು ಆಯ್ಕೆಯನ್ನು ಸ್ಥಾಪಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ unclean.leader.election.enable ಅರ್ಥದಲ್ಲಿ ನಿಜವಾದ. ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇದು ಸಮಾನವಾಗಿರುತ್ತದೆ ಸುಳ್ಳು. ಸಂಯೋಜನೆಗಳು acks=ಎಲ್ಲಾ с unclean.leader.election.enable=true ಕೆಲವು ಹೆಚ್ಚುವರಿ ಡೇಟಾ ಭದ್ರತೆಯೊಂದಿಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ ನೀವು ನೋಡುವಂತೆ, ನಾವು ಇನ್ನೂ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದು.

ಆದರೆ ನಾವು ಡೇಟಾ ಸುರಕ್ಷತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಬಯಸಿದರೆ ಏನು? ನೀವು ಹಾಕಬಹುದು unclean.leader.election.enable = ತಪ್ಪು, ಆದರೆ ಇದು ಡೇಟಾ ನಷ್ಟದಿಂದ ನಮ್ಮನ್ನು ರಕ್ಷಿಸುವುದಿಲ್ಲ. ನಾಯಕನು ಕಷ್ಟಪಟ್ಟು ಅದರೊಂದಿಗೆ ಡೇಟಾವನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಸಂದೇಶಗಳು ಇನ್ನೂ ಕಳೆದುಹೋಗಿವೆ, ಜೊತೆಗೆ ನಿರ್ವಾಹಕರು ಪರಿಸ್ಥಿತಿಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸುವವರೆಗೆ ಲಭ್ಯತೆ ಕಳೆದುಹೋಗುತ್ತದೆ.

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

Acks=all, min.insync.replicas ಮತ್ತು ISR

ವಿಷಯದ ಸಂರಚನೆಯೊಂದಿಗೆ min.insync.replicas ನಾವು ಡೇಟಾ ಸುರಕ್ಷತೆಯ ಮಟ್ಟವನ್ನು ಹೆಚ್ಚಿಸುತ್ತಿದ್ದೇವೆ. ಹಿಂದಿನ ಸನ್ನಿವೇಶದ ಕೊನೆಯ ಭಾಗವನ್ನು ಮತ್ತೊಮ್ಮೆ ನೋಡೋಣ, ಆದರೆ ಈ ಬಾರಿ min.insync.replicas=2.

ಆದ್ದರಿಂದ ಬ್ರೋಕರ್ 2 ಪ್ರತಿಕೃತಿ ನಾಯಕನನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಬ್ರೋಕರ್ 3 ನಲ್ಲಿನ ಅನುಯಾಯಿಯನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 19. ಎರಡು ಪ್ರತಿಕೃತಿಗಳಿಂದ ISR

ಬ್ರೋಕರ್ 2 ಬೀಳುತ್ತದೆ ಮತ್ತು ನಾಯಕತ್ವವು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ಬ್ರೋಕರ್ 1 ಗೆ ಹಾದುಹೋಗುತ್ತದೆ. ಆದರೆ ಈಗ ISR ಕೇವಲ ಒಂದು ಪ್ರತಿಕೃತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಇದು ದಾಖಲೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಬ್ರೋಕರ್ ಬರೆಯುವ ಪ್ರಯತ್ನಕ್ಕೆ ದೋಷದೊಂದಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಾನೆ NotEnoughReplicas.

ಅಕ್ಕಿ. 20. ISR ಗಳ ಸಂಖ್ಯೆಯು min.insync.replicas ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿರುವುದಕ್ಕಿಂತ ಒಂದು ಕಡಿಮೆಯಾಗಿದೆ

ಈ ಕಾನ್ಫಿಗರೇಶನ್ ಸ್ಥಿರತೆಗಾಗಿ ಲಭ್ಯತೆಯನ್ನು ತ್ಯಾಗ ಮಾಡುತ್ತದೆ. ಸಂದೇಶವನ್ನು ಅಂಗೀಕರಿಸುವ ಮೊದಲು, ಅದನ್ನು ಕನಿಷ್ಠ ಎರಡು ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಬರೆಯಲಾಗಿದೆ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ. ಇದು ತಯಾರಕರಿಗೆ ಹೆಚ್ಚಿನ ವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ. ಇಲ್ಲಿ, ಸಂದೇಶವನ್ನು ಹೆಚ್ಚುವರಿ ಅನುಯಾಯಿಗಳಿಗೆ ಪುನರಾವರ್ತಿಸುವವರೆಗೆ ಎರಡು ಪ್ರತಿಕೃತಿಗಳು ಸಣ್ಣ ಮಧ್ಯಂತರದಲ್ಲಿ ಏಕಕಾಲದಲ್ಲಿ ವಿಫಲವಾದರೆ ಮಾತ್ರ ಸಂದೇಶ ನಷ್ಟ ಸಾಧ್ಯ, ಅದು ಅಸಂಭವವಾಗಿದೆ. ಆದರೆ ನೀವು ಸೂಪರ್ ಪ್ಯಾರನಾಯ್ಡ್ ಆಗಿದ್ದರೆ, ನೀವು ಪ್ರತಿಕೃತಿ ಅಂಶವನ್ನು 5 ಗೆ ಹೊಂದಿಸಬಹುದು ಮತ್ತು min.insync.replicas 3 ರಿಂದ. ಇಲ್ಲಿ ಮೂರು ದಲ್ಲಾಳಿಗಳು ದಾಖಲೆಯನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಬೀಳಬೇಕು! ಸಹಜವಾಗಿ, ನೀವು ಹೆಚ್ಚುವರಿ ಸುಪ್ತತೆಯಲ್ಲಿ ಈ ವಿಶ್ವಾಸಾರ್ಹತೆಗೆ ಪಾವತಿಸುತ್ತೀರಿ.

ಡೇಟಾ ಸುರಕ್ಷತೆಗಾಗಿ ಪ್ರವೇಶಿಸುವಿಕೆ ಅಗತ್ಯವಿದ್ದಾಗ

ಸೈನ್ ಇನ್ RabbitMQ ನೊಂದಿಗೆ ಪ್ರಕರಣ, ಡೇಟಾ ಸುರಕ್ಷತೆಗಾಗಿ ಕೆಲವೊಮ್ಮೆ ಪ್ರವೇಶಿಸುವಿಕೆ ಅಗತ್ಯ. ನೀವು ಯೋಚಿಸಬೇಕಾದದ್ದು ಇಲ್ಲಿದೆ:

• ಪ್ರಕಾಶಕರು ದೋಷವನ್ನು ಹಿಂತಿರುಗಿಸಬಹುದೇ ಮತ್ತು ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಸೇವೆ ಅಥವಾ ಬಳಕೆದಾರರು ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದೇ?
• ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಲು ಪ್ರಕಾಶಕರು ಸಂದೇಶವನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಅಥವಾ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಉಳಿಸಬಹುದೇ?

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

ISR ನ ಅರ್ಥ

ಡೇಟಾ ಸುರಕ್ಷತೆ ಮತ್ತು ಸುಪ್ತತೆಯ ನಡುವಿನ ಅತ್ಯುತ್ತಮ ಸಮತೋಲನವನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ISR ಸೂಟ್ ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಬಹುಪಾಲು ಪ್ರತಿಕೃತಿಗಳ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ ಲಭ್ಯತೆಯನ್ನು ಖಾತ್ರಿಪಡಿಸಿಕೊಳ್ಳಿ, ಲೇಟೆನ್ಸಿ ವಿಷಯದಲ್ಲಿ ಸತ್ತ ಅಥವಾ ನಿಧಾನವಾದ ಪ್ರತಿಕೃತಿಗಳ ಪ್ರಭಾವವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಅರ್ಥವನ್ನು ನಾವೇ ಆರಿಸಿಕೊಳ್ಳುತ್ತೇವೆ replica.lag.time.max.ms ನಿಮ್ಮ ಅಗತ್ಯಗಳಿಗೆ ಅನುಗುಣವಾಗಿ. ಮೂಲಭೂತವಾಗಿ, ಈ ಪ್ಯಾರಾಮೀಟರ್ ಎಂದರೆ ನಾವು ಎಷ್ಟು ವಿಳಂಬವನ್ನು ಯಾವಾಗ ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧರಿದ್ದೇವೆ acks=ಎಲ್ಲಾ. ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯವು ಹತ್ತು ಸೆಕೆಂಡುಗಳು. ಇದು ನಿಮಗೆ ತುಂಬಾ ಉದ್ದವಾಗಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು. ನಂತರ ISR ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಆವರ್ತನವು ಹೆಚ್ಚಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅನುಯಾಯಿಗಳನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಸೇರಿಸಲಾಗುತ್ತದೆ.

RabbitMQ ಸರಳವಾಗಿ ನಕಲು ಮಾಡಬೇಕಾದ ಕನ್ನಡಿಗಳ ಗುಂಪಾಗಿದೆ. ನಿಧಾನ ಕನ್ನಡಿಗಳು ಹೆಚ್ಚುವರಿ ಲೇಟೆನ್ಸಿಯನ್ನು ಪರಿಚಯಿಸುತ್ತವೆ ಮತ್ತು ಪ್ರತಿ ನೋಡ್‌ನ (ನೆಟ್ ಟಿಕ್) ಲಭ್ಯತೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಪ್ರತಿಕ್ರಿಯಿಸುವವರೆಗೆ ಡೆಡ್ ಮಿರರ್‌ಗಳು ಕಾಯಬಹುದು. ಈ ಲೇಟೆನ್ಸಿ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ISR ಒಂದು ಆಸಕ್ತಿದಾಯಕ ಮಾರ್ಗವಾಗಿದೆ. ಆದರೆ ISR ನಾಯಕನಿಗೆ ಮಾತ್ರ ಕುಗ್ಗುವುದರಿಂದ ನಾವು ಪುನರುಕ್ತಿ ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ. ಈ ಅಪಾಯವನ್ನು ತಪ್ಪಿಸಲು, ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬಳಸಿ min.insync.replicas.

ಗ್ರಾಹಕ ಸಂಪರ್ಕ ಖಾತರಿ

ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ bootstrap.servers ಗ್ರಾಹಕರನ್ನು ಸಂಪರ್ಕಿಸಲು ನಿರ್ಮಾಪಕ ಮತ್ತು ಗ್ರಾಹಕರು ಬಹು ದಲ್ಲಾಳಿಗಳನ್ನು ಸೂಚಿಸಬಹುದು. ಕಲ್ಪನೆಯು ಒಂದು ನೋಡ್ ಕೆಳಗೆ ಹೋದಾಗ, ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯಬಹುದಾದ ಹಲವಾರು ಬಿಡಿ ಬಿಡಿಗಳು ಉಳಿದಿವೆ. ಇವುಗಳು ಅಗತ್ಯವಾಗಿ ವಿಭಾಗದ ನಾಯಕರಲ್ಲ, ಆದರೆ ಆರಂಭಿಕ ಲೋಡಿಂಗ್‌ಗೆ ಕೇವಲ ಸ್ಪ್ರಿಂಗ್‌ಬೋರ್ಡ್. ವಿಭಜನಾ ನಾಯಕನನ್ನು ಓದಲು/ಬರೆಯಲು ಯಾವ ನೋಡ್ ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ ಎಂದು ಕ್ಲೈಂಟ್ ಅವರನ್ನು ಕೇಳಬಹುದು.

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

ಕಾಫ್ಕಾ ಒಮ್ಮತದ ವಾಸ್ತುಶಿಲ್ಪ

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

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

ಝೂಕೀಪರ್ ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ:

• ವಿಷಯಗಳ ಪಟ್ಟಿ, ವಿಭಾಗಗಳು, ಕಾನ್ಫಿಗರೇಶನ್, ಪ್ರಸ್ತುತ ನಾಯಕ ಪ್ರತಿಕೃತಿಗಳು, ಆದ್ಯತೆಯ ಪ್ರತಿಕೃತಿಗಳು.
• ಕ್ಲಸ್ಟರ್ ಸದಸ್ಯರು. ಪ್ರತಿ ಬ್ರೋಕರ್ ಝೂಕೀಪರ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪಿಂಗ್ ಮಾಡುತ್ತಾರೆ. ನಿಗದಿತ ಅವಧಿಯೊಳಗೆ ಅದು ಪಿಂಗ್ ಅನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ಬ್ರೋಕರ್ ಲಭ್ಯವಿಲ್ಲ ಎಂದು Zookeeper ದಾಖಲಿಸುತ್ತದೆ.
• ನಿಯಂತ್ರಕಕ್ಕಾಗಿ ಮುಖ್ಯ ಮತ್ತು ಬಿಡಿ ನೋಡ್ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತಿದೆ.

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

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

ಪ್ರತಿ ವಿಭಾಗದ ನಿಯಂತ್ರಕಕ್ಕೆ:

• ISR ಮತ್ತು ನಾಯಕನ ಕುರಿತು Zookeeper ನಲ್ಲಿ ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸುತ್ತದೆ;
• ಈ ವಿಭಾಗದ ಪ್ರತಿಕೃತಿಯನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಪ್ರತಿ ಬ್ರೋಕರ್‌ಗೆ ನಾಯಕ ಮತ್ತು ಐಎಸ್ಆರ್‌ಕಮಾಂಡ್ ಅನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಐಎಸ್‌ಆರ್ ಮತ್ತು ಲೀಡರ್ ಬಗ್ಗೆ ಬ್ರೋಕರ್‌ಗಳಿಗೆ ತಿಳಿಸುತ್ತದೆ.

ನಾಯಕನೊಂದಿಗಿನ ಬ್ರೋಕರ್ ಬಿದ್ದಾಗ, ಜೂಕೀಪರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಅಧಿಸೂಚನೆಯನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ ಮತ್ತು ಅದು ಹೊಸ ನಾಯಕನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಮತ್ತೊಮ್ಮೆ, ನಿಯಂತ್ರಕವು ಮೊದಲು ಝೂಕೀಪರ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ನಾಯಕತ್ವ ಬದಲಾವಣೆಯ ಬಗ್ಗೆ ತಿಳಿಸುವ ಪ್ರತಿ ಬ್ರೋಕರ್‌ಗೆ ಆಜ್ಞೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ.

ISR ಗಳನ್ನು ನೇಮಕ ಮಾಡುವ ಜವಾಬ್ದಾರಿ ಪ್ರತಿಯೊಬ್ಬ ನಾಯಕನ ಮೇಲಿದೆ. ಸಂಯೋಜನೆಗಳು replica.lag.time.max.ms ಅಲ್ಲಿ ಯಾರು ಪ್ರವೇಶಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ISR ಬದಲಾದಾಗ, ನಾಯಕನು ಹೊಸ ಮಾಹಿತಿಯನ್ನು Zookeeper ಗೆ ರವಾನಿಸುತ್ತಾನೆ.

ಝೂಕೀಪರ್ ಯಾವಾಗಲೂ ಯಾವುದೇ ಬದಲಾವಣೆಗಳ ಬಗ್ಗೆ ತಿಳಿಸುತ್ತಾರೆ ಆದ್ದರಿಂದ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ, ನಿರ್ವಹಣೆ ಸರಾಗವಾಗಿ ಹೊಸ ನಾಯಕನಿಗೆ ಪರಿವರ್ತನೆಯಾಗುತ್ತದೆ.

ಅಕ್ಕಿ. 21. ಕಾಫ್ಕಾ ಒಮ್ಮತ

ನಕಲು ಪ್ರೋಟೋಕಾಲ್

ಪ್ರತಿಕೃತಿಯ ವಿವರಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಸಂಭಾವ್ಯ ಡೇಟಾ ನಷ್ಟದ ಸನ್ನಿವೇಶಗಳನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಮಾದರಿ ಪ್ರಶ್ನೆಗಳು, ಲಾಗ್ ಎಂಡ್ ಆಫ್‌ಸೆಟ್ (LEO) ಮತ್ತು ಹೈವಾಟರ್ ಮಾರ್ಕ್ (HW)

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

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

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

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

ನಾಯಕ ವೈಫಲ್ಯ

ನಾಯಕ ಬಿದ್ದಾಗ, ಝೂಕೀಪರ್ ನಿಯಂತ್ರಕಕ್ಕೆ ಸೂಚನೆ ನೀಡುತ್ತಾನೆ ಮತ್ತು ಅದು ಹೊಸ ನಾಯಕನ ಪ್ರತಿಕೃತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಹೊಸ ನಾಯಕನು ತನ್ನ LEO ಪ್ರಕಾರ ಹೊಸ HW ಮಾರ್ಕ್ ಅನ್ನು ಹೊಂದಿಸುತ್ತಾನೆ. ನಂತರ ಅನುಯಾಯಿಗಳು ಹೊಸ ನಾಯಕನ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪಡೆಯುತ್ತಾರೆ. ಕಾಫ್ಕಾದ ಆವೃತ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿ, ಅನುಯಾಯಿಗಳು ಎರಡು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ:

1. ಇದು ಸ್ಥಳೀಯ ಲಾಗ್ ಅನ್ನು ತಿಳಿದಿರುವ HW ಗೆ ಮೊಟಕುಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಈ ಗುರುತು ನಂತರ ಸಂದೇಶಗಳಿಗಾಗಿ ಹೊಸ ನಾಯಕನಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
2. ಅವರು ನಾಯಕರಾಗಿ ಆಯ್ಕೆಯಾದ ಸಮಯದಲ್ಲಿ HW ಅನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾಯಕನಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಈ ಆಫ್‌ಸೆಟ್‌ಗೆ ಲಾಗ್ ಅನ್ನು ಮೊಟಕುಗೊಳಿಸುತ್ತಾರೆ. ಇದು ನಂತರ ಈ ಆಫ್‌ಸೆಟ್‌ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಆವರ್ತಕ ತರಲು ವಿನಂತಿಗಳನ್ನು ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಕೆಳಗಿನ ಕಾರಣಗಳಿಗಾಗಿ ಅನುಯಾಯಿಗಳು ಲಾಗ್ ಅನ್ನು ಮೊಟಕುಗೊಳಿಸಬೇಕಾಗಬಹುದು:

• ನಾಯಕ ವಿಫಲವಾದಾಗ, ಝೂಕೀಪರ್‌ನಲ್ಲಿ ನೋಂದಾಯಿಸಲಾದ ISR ಸೆಟ್‌ನಲ್ಲಿ ಮೊದಲ ಅನುಯಾಯಿ ಚುನಾವಣೆಯಲ್ಲಿ ಗೆದ್ದು ನಾಯಕನಾಗುತ್ತಾನೆ. ISR ನಲ್ಲಿನ ಎಲ್ಲಾ ಅನುಯಾಯಿಗಳು, "ಸಿಂಕ್‌ನಲ್ಲಿ" ಎಂದು ಪರಿಗಣಿಸಲಾಗಿದ್ದರೂ, ಹಿಂದಿನ ನಾಯಕರಿಂದ ಎಲ್ಲಾ ಸಂದೇಶಗಳ ನಕಲುಗಳನ್ನು ಸ್ವೀಕರಿಸದೇ ಇರಬಹುದು. ವೈಶಿಷ್ಟ್ಯಗೊಳಿಸಿದ ಅನುಯಾಯಿಗಳು ಅತ್ಯಂತ ನವೀಕೃತ ನಕಲನ್ನು ಹೊಂದಿಲ್ಲದಿರುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಸಾಧ್ಯ. ಕಾಫ್ಕಾ ಪ್ರತಿಕೃತಿಗಳ ನಡುವೆ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ವ್ಯತ್ಯಾಸಗಳನ್ನು ತಪ್ಪಿಸಲು, ಪ್ರತಿಯೊಬ್ಬ ಅನುಯಾಯಿಯು ತನ್ನ ಚುನಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಹೊಸ ನಾಯಕನ HW ಮೌಲ್ಯಕ್ಕೆ ಅದರ ಲಾಗ್ ಅನ್ನು ಮೊಟಕುಗೊಳಿಸಬೇಕು. ಹೊಂದಿಸಲು ಇದು ಮತ್ತೊಂದು ಕಾರಣವಾಗಿದೆ acks=ಎಲ್ಲಾ ಸ್ಥಿರತೆಗೆ ತುಂಬಾ ಮುಖ್ಯವಾಗಿದೆ.
• ಸಂದೇಶಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾದರೆ, ವಿಭಿನ್ನ ಆಫ್‌ಸೆಟ್‌ಗಳೊಂದಿಗೆ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗುತ್ತದೆ. ದಲ್ಲಾಳಿಗಳು ಆನ್‌ಲೈನ್‌ಗೆ ಹಿಂತಿರುಗಿದಾಗ, ಆಯ್ಕೆಯಾದ ಹೊಸ ನಾಯಕನು ತನ್ನ ಅನುಯಾಯಿಗಳ ಹಿಂದೆ ಇರುವ ಸಾಧ್ಯತೆಯಿದೆ ಏಕೆಂದರೆ ಅವನು ಇತರರಿಗಿಂತ ಮೊದಲು ಡಿಸ್ಕ್‌ಗೆ ಉಳಿಸಲ್ಪಟ್ಟನು.

ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಪುನರ್ಮಿಲನ

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

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

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

ಸಂಪರ್ಕದ ನಷ್ಟ

ಕಾಫ್ಕಾವು RabbitMQ ಗಿಂತ ಹೆಚ್ಚಿನ ಘಟಕಗಳನ್ನು ಹೊಂದಿದೆ, ಆದ್ದರಿಂದ ಕ್ಲಸ್ಟರ್ ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ಇದು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ನಡವಳಿಕೆಗಳನ್ನು ಹೊಂದಿದೆ. ಆದರೆ ಕಾಫ್ಕಾವನ್ನು ಮೂಲತಃ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಪರಿಹಾರಗಳನ್ನು ಚೆನ್ನಾಗಿ ಯೋಚಿಸಲಾಗಿದೆ.

ಹಲವಾರು ಸಂಪರ್ಕ ವೈಫಲ್ಯದ ಸನ್ನಿವೇಶಗಳನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ:

• ಸನ್ನಿವೇಶ 1: ಅನುಯಾಯಿಯು ನಾಯಕನನ್ನು ನೋಡುವುದಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುತ್ತಾನೆ.
• ಸನ್ನಿವೇಶ 2: ನಾಯಕನು ಯಾವುದೇ ಅನುಯಾಯಿಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುತ್ತಾನೆ.
• ಸನ್ನಿವೇಶ 3: ಅನುಯಾಯಿ ನಾಯಕನನ್ನು ನೋಡುತ್ತಾನೆ, ಆದರೆ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ.
• ಸನ್ನಿವೇಶ 4: ನಾಯಕನು ಅನುಯಾಯಿಗಳನ್ನು ನೋಡುತ್ತಾನೆ, ಆದರೆ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ.
• ಸನ್ನಿವೇಶ 5: ಅನುಯಾಯಿಯು ಇತರ ಕಾಫ್ಕಾ ನೋಡ್‌ಗಳು ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿದೆ.
• ಸನ್ನಿವೇಶ 6: ನಾಯಕ ಇತರ ಕಾಫ್ಕಾ ನೋಡ್‌ಗಳು ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿದೆ.
• ಸನ್ನಿವೇಶ 7: ಕಾಫ್ಕಾ ನಿಯಂತ್ರಕ ನೋಡ್ ಮತ್ತೊಂದು ಕಾಫ್ಕಾ ನೋಡ್ ಅನ್ನು ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಸನ್ನಿವೇಶ 8: ಕಾಫ್ಕಾ ನಿಯಂತ್ರಕವು ಝೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ.

ಪ್ರತಿಯೊಂದು ಸನ್ನಿವೇಶವು ತನ್ನದೇ ಆದ ನಡವಳಿಕೆಯನ್ನು ಹೊಂದಿದೆ.

ಸನ್ನಿವೇಶ 1: ಅನುಸರಿಸುವವರು ನಾಯಕನನ್ನು ನೋಡುವುದಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುತ್ತಾರೆ

ಅಕ್ಕಿ. 22. ಸನ್ನಿವೇಶ 1: ಮೂರು ಪ್ರತಿಕೃತಿಗಳ ISR

ಸಂಪರ್ಕ ವೈಫಲ್ಯವು ಬ್ರೋಕರ್ 3 ಅನ್ನು ಬ್ರೋಕರ್‌ಗಳು 1 ಮತ್ತು 2 ರಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ, ಆದರೆ ಝೂಕೀಪರ್‌ನಿಂದ ಅಲ್ಲ. ಬ್ರೋಕರ್ 3 ಇನ್ನು ಮುಂದೆ ತರಲು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಸಮಯ ಕಳೆದ ನಂತರ replica.lag.time.max.ms ಇದನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ ಮತ್ತು ಸಂದೇಶ ಕಮಿಟ್‌ಗಳಲ್ಲಿ ಭಾಗವಹಿಸುವುದಿಲ್ಲ. ಒಮ್ಮೆ ಸಂಪರ್ಕವನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ, ಅದು ವಿನಂತಿಗಳನ್ನು ಪಡೆಯುವುದನ್ನು ಪುನರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅದು ನಾಯಕನನ್ನು ಹಿಡಿದಾಗ ISR ಅನ್ನು ಸೇರುತ್ತದೆ. ಝೂಕೀಪರ್ ಪಿಂಗ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ಮತ್ತು ಬ್ರೋಕರ್ ಜೀವಂತವಾಗಿದ್ದಾರೆ ಮತ್ತು ಚೆನ್ನಾಗಿದ್ದಾರೆ ಎಂದು ಭಾವಿಸುತ್ತಾರೆ.

ಅಕ್ಕಿ. 23. ಸನ್ನಿವೇಶ 1: replica.lag.time.max.ms ಮಧ್ಯಂತರದೊಳಗೆ ಯಾವುದೇ ತರಲು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ ISR ನಿಂದ ಬ್ರೋಕರ್ ಅನ್ನು ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ

RabbitMQ ನಲ್ಲಿರುವಂತೆ ಯಾವುದೇ ಸ್ಪ್ಲಿಟ್-ಮೆದುಳು ಅಥವಾ ನೋಡ್ ಅಮಾನತು ಇಲ್ಲ. ಬದಲಿಗೆ, ಪುನರುಕ್ತಿ ಕಡಿಮೆಯಾಗಿದೆ.

ಸನ್ನಿವೇಶ 2: ನಾಯಕನು ಯಾವುದೇ ಅನುಯಾಯಿಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ, ಆದರೆ ಇನ್ನೂ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುತ್ತಾನೆ

ಅಕ್ಕಿ. 24. ಸನ್ನಿವೇಶ 2. ನಾಯಕ ಮತ್ತು ಇಬ್ಬರು ಅನುಯಾಯಿಗಳು

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

ಅಕ್ಕಿ. 25. ಸನ್ನಿವೇಶ 2. ನಾಯಕನಿಗೆ ಮಾತ್ರ ISR ಕುಗ್ಗಿದೆ

ಸನ್ನಿವೇಶ 3. ಹಿಂಬಾಲಕರು ನಾಯಕನನ್ನು ನೋಡುತ್ತಾರೆ, ಆದರೆ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ

ಅನುಯಾಯಿಗಳು ಝೂಕೀಪರ್‌ನಿಂದ ಬೇರ್ಪಟ್ಟಿದ್ದಾರೆ, ಆದರೆ ನಾಯಕನೊಂದಿಗಿನ ಬ್ರೋಕರ್‌ನಿಂದ ಅಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಅನುಯಾಯಿಗಳು ವಿನಂತಿಗಳನ್ನು ಪಡೆಯುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ಮತ್ತು ISR ನ ಸದಸ್ಯರಾಗಿ. ಜೂಕೀಪರ್ ಇನ್ನು ಮುಂದೆ ಪಿಂಗ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಬ್ರೋಕರ್ ಕ್ರ್ಯಾಶ್ ಅನ್ನು ನೋಂದಾಯಿಸುವುದಿಲ್ಲ, ಆದರೆ ಇದು ಕೇವಲ ಅನುಯಾಯಿಯಾಗಿರುವುದರಿಂದ, ಚೇತರಿಕೆಯ ನಂತರ ಯಾವುದೇ ಪರಿಣಾಮಗಳಿಲ್ಲ.

ಅಕ್ಕಿ. 26. ಸನ್ನಿವೇಶ 3: ಅನುಸರಿಸುವವರು ನಾಯಕನಿಗೆ ತರಲು ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ

ಸನ್ನಿವೇಶ 4. ನಾಯಕನು ಅನುಯಾಯಿಗಳನ್ನು ನೋಡುತ್ತಾನೆ, ಆದರೆ ಜೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ

ಅಕ್ಕಿ. 27. ಸನ್ನಿವೇಶ 4. ನಾಯಕ ಮತ್ತು ಇಬ್ಬರು ಅನುಯಾಯಿಗಳು

ನಾಯಕನು ಝೂಕೀಪರ್‌ನಿಂದ ಬೇರ್ಪಟ್ಟಿದ್ದಾನೆ, ಆದರೆ ಅನುಯಾಯಿಗಳೊಂದಿಗೆ ಬ್ರೋಕರ್‌ಗಳಿಂದ ಅಲ್ಲ.

ಅಕ್ಕಿ. 28. ಸನ್ನಿವೇಶ 4: ಝೂಕೀಪರ್‌ನಿಂದ ನಾಯಕನನ್ನು ಪ್ರತ್ಯೇಕಿಸಲಾಗಿದೆ

ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಝೂಕೀಪರ್ ಬ್ರೋಕರ್ ವೈಫಲ್ಯವನ್ನು ನೋಂದಾಯಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರ ಬಗ್ಗೆ ನಿಯಂತ್ರಕರಿಗೆ ಸೂಚಿಸುತ್ತಾರೆ. ಅವರು ತಮ್ಮ ಅನುಯಾಯಿಗಳ ನಡುವೆ ಹೊಸ ನಾಯಕನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ. ಆದಾಗ್ಯೂ, ಮೂಲ ನಾಯಕ ತಾನು ನಾಯಕ ಎಂದು ಭಾವಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ ಮತ್ತು ನಮೂದುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ acks=1. ಅನುಯಾಯಿಗಳು ಇನ್ನು ಮುಂದೆ ಅವರಿಗೆ ವಿನಂತಿಗಳನ್ನು ತರಲು ಕಳುಹಿಸುತ್ತಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವರು ಸತ್ತರು ಎಂದು ಪರಿಗಣಿಸುತ್ತಾರೆ ಮತ್ತು ISR ಅನ್ನು ಸ್ವತಃ ಕುಗ್ಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ಆದರೆ ಇದು ಝೂಕೀಪರ್‌ಗೆ ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿಲ್ಲದ ಕಾರಣ, ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಆ ಸಮಯದಲ್ಲಿ ಯಾವುದೇ ಹೆಚ್ಚಿನ ನಮೂದುಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ.

ಸಂದೇಶಗಳನ್ನು acks=ಎಲ್ಲಾ ISR ಮೊದಲು ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಆನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಂದೇಶಗಳು ಅವರನ್ನು ತಲುಪುವುದಿಲ್ಲವಾದ್ದರಿಂದ ಸ್ವೀಕೃತಿಯನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. ಮೂಲ ನಾಯಕ ಅವರನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಅದು ಹಾಗೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

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

ಅಕ್ಕಿ. 29. ಸನ್ನಿವೇಶ 4. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ ಬ್ರೋಕರ್ 1 ರ ನಾಯಕನು ಅನುಯಾಯಿಯಾಗುತ್ತಾನೆ

ಸನ್ನಿವೇಶ 5: ಅನುಯಾಯಿಯು ಇತರ ಕಾಫ್ಕಾ ನೋಡ್‌ಗಳು ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿದೆ

ಅನುಯಾಯಿಯು ಇತರ ಕಾಫ್ಕಾ ನೋಡ್‌ಗಳು ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದ್ದಾನೆ. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸುವವರೆಗೆ ಅವನು ತನ್ನನ್ನು ತಾನೇ ISR ನಿಂದ ತೆಗೆದುಹಾಕುತ್ತಾನೆ ಮತ್ತು ನಂತರ ಇತರರೊಂದಿಗೆ ಹಿಡಿಯುತ್ತಾನೆ.

ಅಕ್ಕಿ. 30. ಸನ್ನಿವೇಶ 5: ಪ್ರತ್ಯೇಕವಾದ ಅನುಯಾಯಿಯನ್ನು ISR ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗಿದೆ

ಸನ್ನಿವೇಶ 6: ನಾಯಕ ಇತರ ಕಾಫ್ಕಾ ನೋಡ್‌ಗಳು ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕವಾಗಿದೆ

ಅಕ್ಕಿ. 31. ಸನ್ನಿವೇಶ 6. ನಾಯಕ ಮತ್ತು ಇಬ್ಬರು ಅನುಯಾಯಿಗಳು

ನಾಯಕನು ತನ್ನ ಅನುಯಾಯಿಗಳು, ನಿಯಂತ್ರಕ ಮತ್ತು ಝೂಕೀಪರ್‌ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲ್ಪಟ್ಟಿದ್ದಾನೆ. ಅಲ್ಪಾವಧಿಗೆ ಇದು ನಮೂದುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ acks=1.

ಅಕ್ಕಿ. 32. ಸನ್ನಿವೇಶ 6: ಇತರ ಕಾಫ್ಕಾ ಮತ್ತು ಝೂಕೀಪರ್ ನೋಡ್‌ಗಳಿಂದ ನಾಯಕನನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು

ಅವಧಿ ಮುಗಿದ ನಂತರ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸದಿರುವುದು replica.lag.time.max.ms, ಇದು ISR ಅನ್ನು ತನ್ನಷ್ಟಕ್ಕೆ ಕುಗ್ಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಆದರೆ Zookeeper ನೊಂದಿಗೆ ಯಾವುದೇ ಸಂವಹನವಿಲ್ಲದ ಕಾರಣ ಹಾಗೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ನಂತರ ಅದು ಬರಹಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ.

ಏತನ್ಮಧ್ಯೆ, ಝೂಕೀಪರ್ ಪ್ರತ್ಯೇಕವಾದ ಬ್ರೋಕರ್ ಅನ್ನು ಸತ್ತಂತೆ ಗುರುತಿಸುತ್ತಾರೆ ಮತ್ತು ನಿಯಂತ್ರಕ ಹೊಸ ನಾಯಕನನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ.

ಅಕ್ಕಿ. 33. ಸನ್ನಿವೇಶ 6. ಇಬ್ಬರು ನಾಯಕರು

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

ಅಕ್ಕಿ. 34. ಸನ್ನಿವೇಶ 6: ತಯಾರಕರು ಹೊಸ ನಾಯಕನಿಗೆ ಬದಲಾಯಿಸುತ್ತಾರೆ

ಸಂಪರ್ಕದ ನಷ್ಟದಿಂದ ಮೂಲ ನಾಯಕ ಮಾಡಿದ ಎಲ್ಲಾ ದೃಢೀಕೃತ ನಮೂದುಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ, ಮೂಲ ನಾಯಕನು ತಾನು ಇನ್ನು ಮುಂದೆ ನಾಯಕನಲ್ಲ ಎಂದು ಝೂಕೀಪರ್ ಮೂಲಕ ಕಂಡುಹಿಡಿಯುತ್ತಾನೆ. ನಂತರ ಅದು ಚುನಾವಣೆಯ ಸಮಯದಲ್ಲಿ ಹೊಸ ನಾಯಕನ HW ಗೆ ತನ್ನ ಲಾಗ್ ಅನ್ನು ಮೊಟಕುಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಅನುಯಾಯಿಯಾಗಿ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಅಕ್ಕಿ. 35. ಸನ್ನಿವೇಶ 6: ನೆಟ್‌ವರ್ಕ್ ಸಂಪರ್ಕವನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ ಮೂಲ ನಾಯಕ ಅನುಯಾಯಿಯಾಗುತ್ತಾನೆ

ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ತಾರ್ಕಿಕ ಬೇರ್ಪಡಿಕೆ ಅಲ್ಪಾವಧಿಗೆ ಸಂಭವಿಸಬಹುದು, ಆದರೆ ಮಾತ್ರ acks=1 и min.insync.replicas 1. ತಾರ್ಕಿಕ ಬೇರ್ಪಡಿಕೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ, ಮೂಲ ನಾಯಕ ತಾನು ಇನ್ನು ಮುಂದೆ ನಾಯಕನಲ್ಲ ಎಂದು ಅರಿತುಕೊಂಡಾಗ ಅಥವಾ ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ನಾಯಕ ಬದಲಾಗಿದ್ದಾನೆ ಎಂದು ಅರಿತು ಹೊಸ ನಾಯಕನಿಗೆ ಬರೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ - ಯಾವುದು ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆಯೋ ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲವು ಸಂದೇಶಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ, ಆದರೆ ಜೊತೆಗೆ ಮಾತ್ರ acks=1.

ಈ ಸನ್ನಿವೇಶದ ಮತ್ತೊಂದು ರೂಪಾಂತರವಿದೆ, ಅಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ವಿಭಜನೆಯ ಸ್ವಲ್ಪ ಮೊದಲು, ಅನುಯಾಯಿಗಳು ಹಿಂದೆ ಬಿದ್ದರು ಮತ್ತು ನಾಯಕನು ISR ಅನ್ನು ತನಗೆ ಸಂಕುಚಿತಗೊಳಿಸಿದನು. ನಂತರ ಸಂಪರ್ಕ ಕಡಿತದಿಂದಾಗಿ ಅದು ಪ್ರತ್ಯೇಕವಾಗುತ್ತದೆ. ಹೊಸ ನಾಯಕನನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ, ಆದರೆ ಮೂಲ ನಾಯಕನು ನಮೂದುಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾನೆ acks=ಎಲ್ಲಾ, ಏಕೆಂದರೆ ISR ನಲ್ಲಿ ಅವನನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಯಾರೂ ಇಲ್ಲ. ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಿದ ನಂತರ ಈ ದಾಖಲೆಗಳು ಕಳೆದುಹೋಗುತ್ತವೆ. ಈ ಆಯ್ಕೆಯನ್ನು ತಪ್ಪಿಸುವ ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ min.insync.replicas = 2.

ಸನ್ನಿವೇಶ 7: ಕಾಫ್ಕಾ ನಿಯಂತ್ರಕ ನೋಡ್ ಮತ್ತೊಂದು ಕಾಫ್ಕಾ ನೋಡ್ ಅನ್ನು ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ

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

ಸನ್ನಿವೇಶ 8: ಕಾಫ್ಕಾ ನಿಯಂತ್ರಕವು ಝೂಕೀಪರ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ

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

ಸನ್ನಿವೇಶಗಳಿಂದ ತೀರ್ಮಾನಗಳು

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

ಸಂಪರ್ಕದ ನಷ್ಟದಿಂದಾಗಿ ನಾಯಕನು ಝೂಕೀಪರ್‌ನಿಂದ ಬೇರ್ಪಟ್ಟರೆ, ಇದು ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಲು ಕಾರಣವಾಗಬಹುದು acks=1. ಜೂಕೀಪರ್ ಜೊತೆಗಿನ ಸಂವಹನದ ಕೊರತೆಯು ಇಬ್ಬರು ನಾಯಕರೊಂದಿಗೆ ಸಂಕ್ಷಿಪ್ತ ತಾರ್ಕಿಕ ವಿಭಜನೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ಪ್ಯಾರಾಮೀಟರ್ ಮೂಲಕ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ acks=ಎಲ್ಲಾ.

ನಿಯತಾಂಕ min.insync.replicas ಎರಡು ಅಥವಾ ಹೆಚ್ಚಿನ ಪ್ರತಿಕೃತಿಗಳಲ್ಲಿ ಅಂತಹ ಅಲ್ಪಾವಧಿಯ ಸನ್ನಿವೇಶಗಳು ಸನ್ನಿವೇಶ 6 ರಂತೆ ಕಳೆದುಹೋದ ಸಂದೇಶಗಳಿಗೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ ಎಂದು ಹೆಚ್ಚುವರಿ ಭರವಸೆ ನೀಡುತ್ತದೆ.

ಕಳೆದುಹೋದ ಸಂದೇಶಗಳ ಸಾರಾಂಶ

ಕಾಫ್ಕಾದಲ್ಲಿ ನೀವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಎಲ್ಲಾ ವಿಧಾನಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡೋಣ:

• ಸಂದೇಶಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೃಢೀಕರಿಸಿದರೆ ಯಾವುದೇ ನಾಯಕ ವೈಫಲ್ಯ acks=1
• ನಾಯಕತ್ವದ ಯಾವುದೇ ಅಶುದ್ಧ ಪರಿವರ್ತನೆ, ಅಂದರೆ, ISR ನ ಹೊರಗಿನ ಅನುಯಾಯಿಗಳಿಗೆ, ಸಹ acks=ಎಲ್ಲಾ
• ಸಂದೇಶಗಳನ್ನು ಬಳಸಿಕೊಂಡು ದೃಢೀಕರಿಸಿದರೆ ಜೂಕೀಪರ್‌ನಿಂದ ನಾಯಕನನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು acks=1
• ಈಗಾಗಲೇ ISR ಗುಂಪನ್ನು ಕುಗ್ಗಿಸಿದ ನಾಯಕನ ಸಂಪೂರ್ಣ ಪ್ರತ್ಯೇಕತೆ. ಎಲ್ಲಾ ಸಂದೇಶಗಳು ಸಹ ಕಳೆದುಹೋಗುತ್ತವೆ acks=ಎಲ್ಲಾ. ಇದು ನಿಜವಾಗಿದ್ದರೆ ಮಾತ್ರ min.insync.replicas=1.
• ಎಲ್ಲಾ ವಿಭಜನಾ ನೋಡ್‌ಗಳ ಏಕಕಾಲಿಕ ವೈಫಲ್ಯಗಳು. ಏಕೆಂದರೆ ಸಂದೇಶಗಳನ್ನು ಮೆಮೊರಿಯಿಂದ ಅಂಗೀಕರಿಸಲಾಗಿದೆ, ಕೆಲವು ಇನ್ನೂ ಡಿಸ್ಕ್ಗೆ ಬರೆಯಲಾಗುವುದಿಲ್ಲ. ಸರ್ವರ್‌ಗಳನ್ನು ರೀಬೂಟ್ ಮಾಡಿದ ನಂತರ, ಕೆಲವು ಸಂದೇಶಗಳು ಕಾಣೆಯಾಗಿರಬಹುದು.

ಅಶುದ್ಧ ನಾಯಕತ್ವದ ಸ್ಥಿತ್ಯಂತರಗಳನ್ನು ನಿಷೇಧಿಸುವ ಮೂಲಕ ಅಥವಾ ಕನಿಷ್ಠ ಎರಡು ಪುನರಾವರ್ತನೆಗಳನ್ನು ಖಾತ್ರಿಪಡಿಸುವ ಮೂಲಕ ತಪ್ಪಿಸಬಹುದು. ಹೆಚ್ಚು ಬಾಳಿಕೆ ಬರುವ ಸಂರಚನೆಯು ಸಂಯೋಜನೆಯಾಗಿದೆ acks=ಎಲ್ಲಾ и min.insync.replicas 1 ಕ್ಕಿಂತ ಹೆಚ್ಚು.

RabbitMQ ಮತ್ತು ಕಾಫ್ಕಾದ ವಿಶ್ವಾಸಾರ್ಹತೆಯ ನೇರ ಹೋಲಿಕೆ

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

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

ಒಂದು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅನೇಕ ಸರ್ವರ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾದಾಗ ವಿಶ್ವಾಸಾರ್ಹತೆಯಲ್ಲಿ RabbitMQ ಕಾಫ್ಕಾಗಿಂತ ಉತ್ತಮವಾಗಿದೆ. ನಾವು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಸಂದೇಶವನ್ನು ಮಾಸ್ಟರ್ ಮತ್ತು ಎಲ್ಲಾ ಕನ್ನಡಿಗಳು ಡಿಸ್ಕ್ಗೆ ಬರೆದ ನಂತರ ಮಾತ್ರ RabbitMQ ಪ್ರಕಾಶಕರಿಗೆ ದೃಢೀಕರಣವನ್ನು ಕಳುಹಿಸುತ್ತದೆ. ಆದರೆ ಇದು ಎರಡು ಕಾರಣಗಳಿಗಾಗಿ ಹೆಚ್ಚುವರಿ ಸುಪ್ತತೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ:

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

ಕಾಫ್ಕಾ ಅವರ ಪಣವೆಂದರೆ ಸಂದೇಶವನ್ನು ಬಹು ನೋಡ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದರೆ, ಅದು ಮೆಮೊರಿಯನ್ನು ಹೊಡೆದ ತಕ್ಷಣ ಸಂದೇಶಗಳನ್ನು ಅಂಗೀಕರಿಸುತ್ತದೆ. ಈ ಕಾರಣದಿಂದಾಗಿ, ಯಾವುದೇ ರೀತಿಯ ಸಂದೇಶಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ (ಸಹ acks=ಎಲ್ಲಾ, min.insync.replicas=2) ಏಕಕಾಲಿಕ ವೈಫಲ್ಯದ ಸಂದರ್ಭದಲ್ಲಿ.

ಒಟ್ಟಾರೆಯಾಗಿ, ಕಾಫ್ಕಾ ಉತ್ತಮ ಸಾಫ್ಟ್‌ವೇರ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗಳಿಗಾಗಿ ನೆಲದಿಂದ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ ಅಗತ್ಯವಿದ್ದರೆ ಅನುಯಾಯಿಗಳ ಸಂಖ್ಯೆಯನ್ನು 11 ಕ್ಕೆ ಹೆಚ್ಚಿಸಬಹುದು. ರೆಪ್ಲಿಕೇಶನ್ ಫ್ಯಾಕ್ಟರ್ 5 ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳು min.insync.replicas=3 ಸಂದೇಶ ನಷ್ಟವನ್ನು ಬಹಳ ಅಪರೂಪದ ಘಟನೆಯನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯವು ಈ ಪುನರಾವರ್ತನೆಯ ಅನುಪಾತ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ಮಟ್ಟವನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ನೀವು ಈ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿಕೊಳ್ಳಬಹುದು.

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

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

ಅಂತಿಮವಾಗಿ, RabbitMQ ಮತ್ತು Kafka ಎರಡರ ಕ್ಲಸ್ಟರಿಂಗ್ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ಕಾರ್ಯವಿಧಾನಗಳಲ್ಲಿನ ಹಲವಾರು ದೋಷಗಳ ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ. ಕಾಲಾನಂತರದಲ್ಲಿ, ವ್ಯವಸ್ಥೆಗಳು ಹೆಚ್ಚು ಪ್ರಬುದ್ಧ ಮತ್ತು ಸ್ಥಿರವಾಗಿವೆ, ಆದರೆ ಯಾವುದೇ ಸಂದೇಶವು ನಷ್ಟದಿಂದ 100% ಸುರಕ್ಷಿತವಾಗಿರುವುದಿಲ್ಲ! ಜೊತೆಗೆ, ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಅಪಘಾತಗಳು ಸಂಭವಿಸುತ್ತವೆ!

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

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

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

ಈ ವಿಶ್ವಾಸಾರ್ಹತೆ ಮತ್ತು ಖಾತರಿಯ ಆದೇಶವನ್ನು ಹೊಂದಿರದ ಇತರ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ, ನಂತರ ನಾನು RabbitMQ ಮತ್ತು Kafka ಅನ್ನು ನೋಡುತ್ತೇನೆ ಮತ್ತು ಈ ಎರಡೂ ವ್ಯವಸ್ಥೆಗಳ ನಂಬಲಾಗದ ಮೌಲ್ಯವನ್ನು ಅರಿತುಕೊಳ್ಳುತ್ತೇನೆ.

ಮೂಲ: www.habr.com