ಹಲೋ, ನನ್ನ ಹೆಸರು ಎವ್ಗೆನಿ. ನಾನು Yandex.Market ಹುಡುಕಾಟ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಾನು ಹಬ್ರ್ ಸಮುದಾಯಕ್ಕೆ ಮಾರುಕಟ್ಟೆಯ ಒಳಗಿನ ಅಡುಗೆಮನೆಯ ಬಗ್ಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ - ಮತ್ತು ನಾನು ಹೇಳಲು ಬಹಳಷ್ಟು ಇದೆ. ಮೊದಲನೆಯದಾಗಿ, ಮಾರುಕಟ್ಟೆ ಹುಡುಕಾಟವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪ. ತುರ್ತು ಪರಿಸ್ಥಿತಿಗಳನ್ನು ನಾವು ಹೇಗೆ ಎದುರಿಸುತ್ತೇವೆ: ಒಂದು ಸರ್ವರ್ ಡೌನ್ ಆಗಿದ್ದರೆ ಏನಾಗುತ್ತದೆ? ಅಂತಹ 100 ಸರ್ವರ್‌ಗಳಿದ್ದರೆ ಏನು?
ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಸರ್ವರ್ಗಳ ಗುಂಪಿನಲ್ಲಿ ಹೊಸ ಕಾರ್ಯವನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಸಹ ನೀವು ಕಲಿಯುವಿರಿ. ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ಯಾವುದೇ ಅನಾನುಕೂಲತೆಯನ್ನು ಉಂಟುಮಾಡದೆಯೇ ನಾವು ಸಂಕೀರ್ಣ ಸೇವೆಗಳನ್ನು ನೇರವಾಗಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹೇಗೆ ಪರೀಕ್ಷಿಸುತ್ತೇವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಮಾರುಕಟ್ಟೆ ಹುಡುಕಾಟವು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಇದರಿಂದ ಪ್ರತಿಯೊಬ್ಬರೂ ಉತ್ತಮ ಸಮಯವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.
ನಮ್ಮ ಬಗ್ಗೆ ಸ್ವಲ್ಪ: ನಾವು ಯಾವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ
ನೀವು ಪಠ್ಯವನ್ನು ನಮೂದಿಸಿದಾಗ, ಪ್ಯಾರಾಮೀಟರ್‌ಗಳ ಮೂಲಕ ಉತ್ಪನ್ನವನ್ನು ಹುಡುಕಿದಾಗ ಅಥವಾ ವಿವಿಧ ಅಂಗಡಿಗಳಲ್ಲಿ ಬೆಲೆಗಳನ್ನು ಹೋಲಿಸಿದಾಗ, ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಹುಡುಕಾಟ ಸೇವೆಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಹುಡುಕಾಟವು ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಅತಿದೊಡ್ಡ ಸೇವೆಯಾಗಿದೆ.
ನಾವು ಎಲ್ಲಾ ಹುಡುಕಾಟ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ: sites market.yandex.ru, beru.ru, Supercheck ಸೇವೆ, Yandex.Advisor, ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ. yandex.ru ನಲ್ಲಿ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ನಾವು ಉತ್ಪನ್ನ ಕೊಡುಗೆಗಳನ್ನು ಸಹ ಸೇರಿಸುತ್ತೇವೆ.
ಹುಡುಕಾಟ ಸೇವೆಯ ಮೂಲಕ ನಾನು ಹುಡುಕಾಟವನ್ನು ಮಾತ್ರವಲ್ಲ, ಮಾರುಕಟ್ಟೆಯಲ್ಲಿನ ಎಲ್ಲಾ ಕೊಡುಗೆಗಳೊಂದಿಗೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಅರ್ಥೈಸುತ್ತೇನೆ. ಪ್ರಮಾಣವು ಹೀಗಿದೆ: ದಿನಕ್ಕೆ ಒಂದು ಬಿಲಿಯನ್‌ಗಿಂತಲೂ ಹೆಚ್ಚು ಹುಡುಕಾಟ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಎಲ್ಲವೂ ತ್ವರಿತವಾಗಿ ಕೆಲಸ ಮಾಡಬೇಕು, ಅಡಚಣೆಗಳಿಲ್ಲದೆ ಮತ್ತು ಯಾವಾಗಲೂ ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಉಂಟುಮಾಡಬೇಕು.
ಏನು: ಮಾರುಕಟ್ಟೆ ವಾಸ್ತುಶಿಲ್ಪ
ಮಾರುಕಟ್ಟೆಯ ಪ್ರಸ್ತುತ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನಾನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ. ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರದಿಂದ ಇದನ್ನು ಸ್ಥೂಲವಾಗಿ ವಿವರಿಸಬಹುದು:
ಪಾಲುದಾರ ಅಂಗಡಿ ನಮಗೆ ಬರುತ್ತದೆ ಎಂದು ಹೇಳೋಣ. ನಾನು ಆಟಿಕೆ ಮಾರಾಟ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ: ಈ ದುಷ್ಟ ಬೆಕ್ಕು ಒಂದು ಕೀರಲು ಧ್ವನಿಯಲ್ಲಿದೆ. ಮತ್ತು ಒಂದು squeaker ಇಲ್ಲದೆ ಮತ್ತೊಂದು ಕೋಪಗೊಂಡ ಬೆಕ್ಕು. ಮತ್ತು ಕೇವಲ ಬೆಕ್ಕು. ನಂತರ ಅಂಗಡಿಯು ಮಾರುಕಟ್ಟೆ ಹುಡುಕುವ ಕೊಡುಗೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಅಗತ್ಯವಿದೆ. ಸ್ಟೋರ್ ಕೊಡುಗೆಗಳೊಂದಿಗೆ ವಿಶೇಷ xml ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಮತ್ತು ಅಂಗಸಂಸ್ಥೆ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಈ xml ಗೆ ಮಾರ್ಗವನ್ನು ಸಂವಹಿಸುತ್ತದೆ. ಸೂಚ್ಯಂಕವು ನಂತರ ನಿಯತಕಾಲಿಕವಾಗಿ ಈ xml ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ, ದೋಷಗಳಿಗಾಗಿ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ದೊಡ್ಡ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಉಳಿಸುತ್ತದೆ.
ಅಂತಹ ಅನೇಕ ಉಳಿಸಿದ xmls ಇವೆ. ಈ ಡೇಟಾಬೇಸ್‌ನಿಂದ ಹುಡುಕಾಟ ಸೂಚಿಯನ್ನು ರಚಿಸಲಾಗಿದೆ. ಸೂಚ್ಯಂಕವನ್ನು ಆಂತರಿಕ ರೂಪದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ. ಸೂಚ್ಯಂಕವನ್ನು ರಚಿಸಿದ ನಂತರ, ಲೇಔಟ್ ಸೇವೆಯು ಅದನ್ನು ಹುಡುಕಾಟ ಸರ್ವರ್‌ಗಳಿಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ.
ಪರಿಣಾಮವಾಗಿ, ಸ್ಕೀಕರ್ನೊಂದಿಗೆ ಕೋಪಗೊಂಡ ಬೆಕ್ಕು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಬೆಕ್ಕಿನ ಸೂಚ್ಯಂಕವು ಸರ್ವರ್ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಹುಡುಕಾಟ ವಾಸ್ತುಶೈಲಿಯ ಭಾಗದಲ್ಲಿ ನಾವು ಬೆಕ್ಕನ್ನು ಹೇಗೆ ಹುಡುಕುತ್ತೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.
ಮಾರುಕಟ್ಟೆ ಹುಡುಕಾಟ ವಾಸ್ತುಶಿಲ್ಪ
ನಾವು ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳ ಜಗತ್ತಿನಲ್ಲಿ ವಾಸಿಸುತ್ತಿದ್ದೇವೆ: ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿ ಬಹಳಷ್ಟು ಉಪಪ್ರಶ್ನೆಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ ಮತ್ತು ಡಜನ್‌ಗಟ್ಟಲೆ ಸೇವೆಗಳು ಅವುಗಳ ಸಂಸ್ಕರಣೆಯಲ್ಲಿ ತೊಡಗಿಕೊಂಡಿವೆ. ರೇಖಾಚಿತ್ರವು ಕೆಲವನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತದೆ:
ಸರಳೀಕೃತ ವಿನಂತಿ ಪ್ರಕ್ರಿಯೆ ಯೋಜನೆ
ಪ್ರತಿಯೊಂದು ಸೇವೆಯು ಅದ್ಭುತವಾದ ವಿಷಯವನ್ನು ಹೊಂದಿದೆ - ವಿಶಿಷ್ಟ ಹೆಸರಿನೊಂದಿಗೆ ತನ್ನದೇ ಆದ ಬ್ಯಾಲೆನ್ಸರ್:
ಸೇವೆಯನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಬ್ಯಾಲೆನ್ಸರ್ ನಮಗೆ ಹೆಚ್ಚಿನ ನಮ್ಯತೆಯನ್ನು ನೀಡುತ್ತದೆ: ಉದಾಹರಣೆಗೆ, ನೀವು ಸರ್ವರ್‌ಗಳನ್ನು ಆಫ್ ಮಾಡಬಹುದು, ಇದು ಆಗಾಗ್ಗೆ ನವೀಕರಣಗಳಿಗೆ ಅಗತ್ಯವಾಗಿರುತ್ತದೆ. ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಬ್ಯಾಲೆನ್ಸರ್ ನೋಡುತ್ತಾನೆ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿನಂತಿಗಳನ್ನು ಇತರ ಸರ್ವರ್ಗಳು ಅಥವಾ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸುವಾಗ ಅಥವಾ ತೆಗೆದುಹಾಕುವಾಗ, ಸರ್ವರ್ಗಳ ನಡುವೆ ಲೋಡ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಹಂಚಿಕೆಯಾಗುತ್ತದೆ.
ಬ್ಯಾಲೆನ್ಸರ್ನ ಅನನ್ಯ ಹೆಸರು ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಅವಲಂಬಿಸಿರುವುದಿಲ್ಲ. ಸೇವೆ A B ಗೆ ವಿನಂತಿಯನ್ನು ಮಾಡಿದಾಗ, ಡೀಫಾಲ್ಟ್ ಬ್ಯಾಲೆನ್ಸರ್ B ವಿನಂತಿಯನ್ನು ಪ್ರಸ್ತುತ ಡೇಟಾ ಕೇಂದ್ರಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಸೇವೆಯು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಪ್ರಸ್ತುತ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ, ನಂತರ ವಿನಂತಿಯನ್ನು ಇತರ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ.
ಎಲ್ಲಾ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಒಂದೇ FQDN ಸೇವೆ A ಅನ್ನು ಸ್ಥಳಗಳಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಅಮೂರ್ತಗೊಳಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. ಸೇವೆ B ಗೆ ಅವರ ವಿನಂತಿಯನ್ನು ಯಾವಾಗಲೂ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಸೇವೆಯು ಎಲ್ಲಾ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಇರುವಾಗ ವಿನಾಯಿತಿಯಾಗಿದೆ.
ಆದರೆ ಈ ಬ್ಯಾಲೆನ್ಸರ್ನೊಂದಿಗೆ ಎಲ್ಲವೂ ತುಂಬಾ ರೋಸಿಯಾಗಿರುವುದಿಲ್ಲ: ನಾವು ಹೆಚ್ಚುವರಿ ಮಧ್ಯಂತರ ಘಟಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಬ್ಯಾಲೆನ್ಸರ್ ಅಸ್ಥಿರವಾಗಿರಬಹುದು, ಮತ್ತು ಈ ಸಮಸ್ಯೆಯನ್ನು ಅನಗತ್ಯ ಸರ್ವರ್‌ಗಳಿಂದ ಪರಿಹರಿಸಲಾಗುತ್ತದೆ. A ಮತ್ತು B ಸೇವೆಗಳ ನಡುವೆ ಹೆಚ್ಚುವರಿ ವಿಳಂಬವೂ ಇದೆ. ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು 1 ms ಗಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸೇವೆಗಳಿಗೆ ಇದು ನಿರ್ಣಾಯಕವಲ್ಲ.
ಅನಿರೀಕ್ಷಿತವಾಗಿ ವ್ಯವಹರಿಸುವುದು: ಹುಡುಕಾಟ ಸೇವೆಯ ಸಮತೋಲನ ಮತ್ತು ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವ
ಕುಸಿತವಿದೆ ಎಂದು ಊಹಿಸಿ: ನೀವು ಸ್ಕ್ವೀಕರ್ನೊಂದಿಗೆ ಬೆಕ್ಕನ್ನು ಕಂಡುಹಿಡಿಯಬೇಕು, ಆದರೆ ಸರ್ವರ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ. ಅಥವಾ 100 ಸರ್ವರ್ಗಳು. ಹೊರಬರುವುದು ಹೇಗೆ? ನಾವು ನಿಜವಾಗಿಯೂ ಬೆಕ್ಕು ಇಲ್ಲದೆ ಬಳಕೆದಾರರನ್ನು ಬಿಡುತ್ತೇವೆಯೇ?
ಪರಿಸ್ಥಿತಿ ಭಯಾನಕವಾಗಿದೆ, ಆದರೆ ನಾವು ಅದಕ್ಕೆ ಸಿದ್ಧರಿದ್ದೇವೆ. ನಾನು ನಿಮಗೆ ಕ್ರಮವಾಗಿ ಹೇಳುತ್ತೇನೆ.
ಹುಡುಕಾಟ ಮೂಲಸೌಕರ್ಯವು ಹಲವಾರು ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದೆ:
ವಿನ್ಯಾಸ ಮಾಡುವಾಗ, ಒಂದು ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಮುಚ್ಚುವ ಸಾಧ್ಯತೆಯನ್ನು ನಾವು ಸೇರಿಸುತ್ತೇವೆ. ಜೀವನವು ಆಶ್ಚರ್ಯಗಳಿಂದ ತುಂಬಿದೆ - ಉದಾಹರಣೆಗೆ, ಅಗೆಯುವ ಯಂತ್ರವು ಭೂಗತ ಕೇಬಲ್ ಅನ್ನು ಕತ್ತರಿಸಬಹುದು (ಹೌದು, ಅದು ಸಂಭವಿಸಿದೆ). ಉಳಿದ ದತ್ತಾಂಶ ಕೇಂದ್ರಗಳಲ್ಲಿನ ಸಾಮರ್ಥ್ಯವು ಗರಿಷ್ಠ ಹೊರೆಯನ್ನು ತಡೆದುಕೊಳ್ಳಲು ಸಾಕಾಗುತ್ತದೆ.
ಒಂದೇ ಡೇಟಾ ಕೇಂದ್ರವನ್ನು ಪರಿಗಣಿಸೋಣ. ಪ್ರತಿಯೊಂದು ಡೇಟಾ ಕೇಂದ್ರವು ಒಂದೇ ಬ್ಯಾಲೆನ್ಸರ್ ಕಾರ್ಯಾಚರಣೆ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದೆ:
ಒಂದು ಬ್ಯಾಲೆನ್ಸರ್ ಕನಿಷ್ಠ ಮೂರು ಭೌತಿಕ ಸರ್ವರ್ಗಳು. ಈ ಪುನರಾವರ್ತನೆಯನ್ನು ವಿಶ್ವಾಸಾರ್ಹತೆಗಾಗಿ ಮಾಡಲಾಗಿದೆ. ಬ್ಯಾಲೆನ್ಸರ್ಗಳು HAProx ನಲ್ಲಿ ರನ್ ಆಗುತ್ತವೆ.
ನಾವು HAProx ಅನ್ನು ಅದರ ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆ, ಕಡಿಮೆ ಸಂಪನ್ಮೂಲ ಅಗತ್ಯತೆಗಳು ಮತ್ತು ವ್ಯಾಪಕವಾದ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಕಾರಣದಿಂದಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ನಮ್ಮ ಹುಡುಕಾಟ ಸಾಫ್ಟ್‌ವೇರ್ ಪ್ರತಿ ಸರ್ವರ್‌ನೊಳಗೆ ಚಲಿಸುತ್ತದೆ.
ಒಂದು ಸರ್ವರ್ ವಿಫಲಗೊಳ್ಳುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ. ಆದರೆ ನೀವು ಅನೇಕ ಸರ್ವರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕನಿಷ್ಠ ಒಂದಾದರೂ ಕಡಿಮೆಯಾಗುವ ಸಾಧ್ಯತೆಯು ಹೆಚ್ಚಾಗುತ್ತದೆ.
ಇದು ವಾಸ್ತವದಲ್ಲಿ ಏನಾಗುತ್ತದೆ: ಸರ್ವರ್ಗಳು ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತವೆ. ಆದ್ದರಿಂದ, ಎಲ್ಲಾ ಸರ್ವರ್ಗಳ ಸ್ಥಿತಿಯನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವುದು ಅವಶ್ಯಕ. ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದರೆ, ಅದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳ್ಳುತ್ತದೆ. ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, HAProxy ಅಂತರ್ನಿರ್ಮಿತ ಆರೋಗ್ಯ ತಪಾಸಣೆಯನ್ನು ಹೊಂದಿದೆ. ಇದು HTTP ವಿನಂತಿ "/ಪಿಂಗ್" ನೊಂದಿಗೆ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಿಗೆ ಹೋಗುತ್ತದೆ.
HAProxy ನ ಮತ್ತೊಂದು ವೈಶಿಷ್ಟ್ಯ: ಏಜೆಂಟ್-ಚೆಕ್ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳನ್ನು ಸಮವಾಗಿ ಲೋಡ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, HAProxy ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಮತ್ತು ಅವರು 1 ರಿಂದ 100 ರವರೆಗಿನ ಪ್ರಸ್ತುತ ಲೋಡ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ತಮ್ಮ ತೂಕವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಾರೆ. ಸಂಸ್ಕರಣೆಗಾಗಿ ಸರದಿಯಲ್ಲಿರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರೊಸೆಸರ್‌ನಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಆಧರಿಸಿ ತೂಕವನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.
ಈಗ ಬೆಕ್ಕು ಹುಡುಕುವ ಬಗ್ಗೆ. ಈ ರೀತಿಯ ವಿನಂತಿಗಳಲ್ಲಿ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು: /ಹುಡುಕಾಟ?ಪಠ್ಯ=ಕೋಪ+ಬೆಕ್ಕು. ಹುಡುಕಾಟವು ವೇಗವಾಗಿರಲು, ಸಂಪೂರ್ಣ ಬೆಕ್ಕು ಸೂಚ್ಯಂಕವು RAM ಗೆ ಹೊಂದಿಕೊಳ್ಳಬೇಕು. SSD ಯಿಂದ ಓದುವುದು ಸಹ ಸಾಕಷ್ಟು ವೇಗವಾಗಿಲ್ಲ.
ಒಂದು ಕಾಲದಲ್ಲಿ, ಆಫರ್ ಡೇಟಾಬೇಸ್ ಚಿಕ್ಕದಾಗಿತ್ತು ಮತ್ತು ಒಂದು ಸರ್ವರ್‌ನ RAM ಇದಕ್ಕೆ ಸಾಕಾಗಿತ್ತು. ಆಫರ್ ಬೇಸ್ ಬೆಳೆದಂತೆ, ಎಲ್ಲವೂ ಇನ್ನು ಮುಂದೆ ಈ RAM ಗೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ ಮತ್ತು ಡೇಟಾವನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: ಶಾರ್ಡ್ 1 ಮತ್ತು ಶಾರ್ಡ್ 2.
ಆದರೆ ಇದು ಯಾವಾಗಲೂ ಸಂಭವಿಸುತ್ತದೆ: ಯಾವುದೇ ಪರಿಹಾರ, ಒಳ್ಳೆಯದು ಸಹ, ಇತರ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ಬ್ಯಾಲೆನ್ಸರ್ ಇನ್ನೂ ಯಾವುದೇ ಸರ್ವರ್‌ಗೆ ಹೋಗಿದೆ. ಆದರೆ ವಿನಂತಿ ಬಂದ ಯಂತ್ರದಲ್ಲಿ ಸೂಚ್ಯಂಕದ ಅರ್ಧದಷ್ಟು ಮಾತ್ರ ಇತ್ತು. ಉಳಿದವು ಇತರ ಸರ್ವರ್‌ಗಳಲ್ಲಿತ್ತು. ಆದ್ದರಿಂದ, ಸರ್ವರ್ ಕೆಲವು ನೆರೆಯ ಯಂತ್ರಕ್ಕೆ ಹೋಗಬೇಕಾಯಿತು. ಎರಡೂ ಸರ್ವರ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಮರುಹೊಂದಿಸಲಾಗಿದೆ.
ಬ್ಯಾಲೆನ್ಸರ್ ವಿನಂತಿಗಳನ್ನು ಸಮವಾಗಿ ವಿತರಿಸುವುದರಿಂದ, ಎಲ್ಲಾ ಸರ್ವರ್ಗಳು ಮರು-ಶ್ರೇಯಾಂಕದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿವೆ ಮತ್ತು ಡೇಟಾವನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ.
ನೆರೆಯ ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಸಮಸ್ಯೆ ಸಂಭವಿಸಿದೆ. "ನೆರೆಹೊರೆಯ" ಸರ್ವರ್‌ನಂತೆ ವಿಭಿನ್ನ ಆದ್ಯತೆಗಳೊಂದಿಗೆ ಹಲವಾರು ಸರ್ವರ್‌ಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುವುದು ಪರಿಹಾರವಾಗಿದೆ. ಮೊದಲಿಗೆ, ಪ್ರಸ್ತುತ ರ್ಯಾಕ್‌ನಲ್ಲಿರುವ ಸರ್ವರ್‌ಗಳಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲಾಗಿದೆ. ಯಾವುದೇ ಪ್ರತಿಕ್ರಿಯೆ ಇಲ್ಲದಿದ್ದರೆ, ಈ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಿಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು ಕೊನೆಯದಾಗಿ, ವಿನಂತಿಯು ಇತರ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಹೋಯಿತು.
ಪ್ರಸ್ತಾವನೆಗಳ ಸಂಖ್ಯೆ ಹೆಚ್ಚಾದಂತೆ, ಡೇಟಾವನ್ನು ನಾಲ್ಕು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಆದರೆ ಇದು ಮಿತಿಯಾಗಿರಲಿಲ್ಲ.
ಪ್ರಸ್ತುತ, ಎಂಟು ಚೂರುಗಳ ಸಂರಚನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇನ್ನೂ ಹೆಚ್ಚಿನ ಮೆಮೊರಿಯನ್ನು ಉಳಿಸಲು, ಸೂಚ್ಯಂಕವನ್ನು ಹುಡುಕಾಟ ಭಾಗವಾಗಿ (ಹುಡುಕಾಟಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ) ಮತ್ತು ತುಣುಕಿನ ಭಾಗವಾಗಿ (ಇದು ಹುಡುಕಾಟದಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿಲ್ಲ) ವಿಂಗಡಿಸಲಾಗಿದೆ.
ಒಂದು ಸರ್ವರ್ ಕೇವಲ ಒಂದು ಚೂರುಗಳ ಮಾಹಿತಿಯನ್ನು ಒಳಗೊಂಡಿದೆ. ಆದ್ದರಿಂದ, ಪೂರ್ಣ ಸೂಚಿಯನ್ನು ಹುಡುಕಲು, ನೀವು ವಿವಿಧ ಚೂರುಗಳನ್ನು ಹೊಂದಿರುವ ಎಂಟು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹುಡುಕಬೇಕಾಗಿದೆ.
ಸರ್ವರ್‌ಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗಳಾಗಿ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ. ಪ್ರತಿ ಕ್ಲಸ್ಟರ್ ಎಂಟು ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳು ಮತ್ತು ಒಂದು ಸ್ನಿಪ್ಪೆಟ್ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಸ್ನಿಪ್ಪೆಟ್ ಸರ್ವರ್ ಸ್ಥಿರ ಡೇಟಾದೊಂದಿಗೆ ಕೀ-ಮೌಲ್ಯದ ಡೇಟಾಬೇಸ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ದಾಖಲೆಗಳನ್ನು ನೀಡಲು ಅವರು ಅಗತ್ಯವಿದೆ, ಉದಾಹರಣೆಗೆ, ಸ್ಕ್ವೀಕರ್ನೊಂದಿಗೆ ಬೆಕ್ಕಿನ ವಿವರಣೆ. ಹುಡುಕಾಟ ಸರ್ವರ್ಗಳ ಮೆಮೊರಿಯನ್ನು ಲೋಡ್ ಮಾಡದಂತೆ ಡೇಟಾವನ್ನು ವಿಶೇಷವಾಗಿ ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ.
ಡಾಕ್ಯುಮೆಂಟ್ ಐಡಿಗಳು ಒಂದು ಸೂಚ್ಯಂಕದಲ್ಲಿ ಮಾತ್ರ ಅನನ್ಯವಾಗಿರುವುದರಿಂದ, ತುಣುಕುಗಳಲ್ಲಿ ಯಾವುದೇ ದಾಖಲೆಗಳಿಲ್ಲದ ಪರಿಸ್ಥಿತಿಯು ಉದ್ಭವಿಸಬಹುದು. ಸರಿ, ಅಥವಾ ಒಂದು ಐಡಿಗೆ ವಿಭಿನ್ನ ವಿಷಯವಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ಹುಡುಕಾಟವು ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಮತ್ತು ಫಲಿತಾಂಶಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲು, ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ಸ್ಥಿರತೆಯ ಅಗತ್ಯವಿತ್ತು. ನಾವು ಸ್ಥಿರತೆಯನ್ನು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ಕೆಳಗೆ ಹೇಳುತ್ತೇನೆ.
ಹುಡುಕಾಟವು ಈ ಕೆಳಗಿನಂತೆ ರಚನೆಯಾಗಿದೆ: ಹುಡುಕಾಟ ವಿನಂತಿಯು ಎಂಟು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಬರಬಹುದು. ಅವರು ಸರ್ವರ್ 1 ಗೆ ಬಂದರು ಎಂದು ಹೇಳೋಣ. ಈ ಸರ್ವರ್ ಎಲ್ಲಾ ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಏನು ಮತ್ತು ಹೇಗೆ ನೋಡಬೇಕು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಒಳಬರುವ ವಿನಂತಿಯನ್ನು ಅವಲಂಬಿಸಿ, ಅಗತ್ಯ ಮಾಹಿತಿಗಾಗಿ ಸರ್ವರ್ ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಹೆಚ್ಚುವರಿ ವಿನಂತಿಗಳನ್ನು ಮಾಡಬಹುದು. ಬಾಹ್ಯ ಸೇವೆಗಳಿಗೆ ಹತ್ತು ವಿನಂತಿಗಳವರೆಗೆ ಒಂದು ವಿನಂತಿಯನ್ನು ಅನುಸರಿಸಬಹುದು.
ಅಗತ್ಯ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಿದ ನಂತರ, ಆಫರ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಹುಡುಕಾಟ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಎಂಟು ಸರ್ವರ್‌ಗಳಿಗೆ ಉಪಪ್ರಶ್ನೆಗಳನ್ನು ಮಾಡಲಾಗುತ್ತದೆ.
ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ ನಂತರ, ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಯೋಜಿಸಲಾಗುತ್ತದೆ. ಕೊನೆಯಲ್ಲಿ, ಫಲಿತಾಂಶಗಳನ್ನು ಸೃಷ್ಟಿಸಲು ತುಣುಕಿನ ಸರ್ವರ್‌ಗೆ ಇನ್ನೂ ಹಲವಾರು ಉಪಪ್ರಶ್ನೆಗಳು ಬೇಕಾಗಬಹುದು.
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಹುಡುಕಾಟ ಪ್ರಶ್ನೆಗಳು ಈ ರೀತಿ ಕಾಣುತ್ತವೆ: /shard1?text=angry+cat. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲಸ್ಟರ್‌ನೊಳಗಿನ ಎಲ್ಲಾ ಸರ್ವರ್ಗಳ ನಡುವೆ ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಫಾರ್ಮ್‌ನ ಉಪಪ್ರಶ್ನೆಗಳನ್ನು ನಿರಂತರವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ: / ಸ್ಥಿತಿ.
ವಿನಂತಿ / ಸ್ಥಿತಿ ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಪತ್ತೆ ಮಾಡುತ್ತದೆ.
ಸರ್ಚ್ ಇಂಜಿನ್ ಆವೃತ್ತಿ ಮತ್ತು ಸೂಚ್ಯಂಕ ಆವೃತ್ತಿಯು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅಸಮಂಜಸ ಡೇಟಾ ಇರುತ್ತದೆ ಎಂದು ಇದು ನಿಯಂತ್ರಿಸುತ್ತದೆ.
ಒಂದು ಸ್ನಿಪ್ಪೆಟ್ ಸರ್ವರ್ ಎಂಟು ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳಿಂದ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ಅದರ ಪ್ರೊಸೆಸರ್ ತುಂಬಾ ಲಘುವಾಗಿ ಲೋಡ್ ಆಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಈಗ ತುಣುಕಿನ ಡೇಟಾವನ್ನು ಪ್ರತ್ಯೇಕ ಸೇವೆಗೆ ವರ್ಗಾಯಿಸುತ್ತಿದ್ದೇವೆ.
ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು, ನಾವು ಡಾಕ್ಯುಮೆಂಟ್‌ಗಳಿಗಾಗಿ ಸಾರ್ವತ್ರಿಕ ಕೀಗಳನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ. ಒಂದು ಕೀಲಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಮತ್ತೊಂದು ಡಾಕ್ಯುಮೆಂಟ್‌ನಿಂದ ವಿಷಯವನ್ನು ಹಿಂತಿರುಗಿಸುವ ಪರಿಸ್ಥಿತಿಗೆ ಈಗ ಅದು ಅಸಾಧ್ಯವಾಗಿದೆ.
ಆದರೆ ಮತ್ತೊಂದು ವಾಸ್ತುಶಿಲ್ಪಕ್ಕೆ ಪರಿವರ್ತನೆ ಇನ್ನೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ. ಈಗ ನಾವು ಮೀಸಲಾದ ತುಣುಕಿನ ಸರ್ವರ್ ಅನ್ನು ತೊಡೆದುಹಾಕಲು ಬಯಸುತ್ತೇವೆ. ತದನಂತರ ಕ್ಲಸ್ಟರ್ ರಚನೆಯಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ದೂರ ಸರಿಯಿರಿ. ಇದು ಸುಲಭವಾಗಿ ಅಳೆಯುವುದನ್ನು ಮುಂದುವರಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ಬೋನಸ್ ಗಮನಾರ್ಹ ಕಬ್ಬಿಣದ ಉಳಿತಾಯವಾಗಿದೆ.
ಮತ್ತು ಈಗ ಸಂತೋಷದ ಅಂತ್ಯಗಳೊಂದಿಗೆ ಭಯಾನಕ ಕಥೆಗಳಿಗೆ. ಸರ್ವರ್ ಅಲಭ್ಯತೆಯ ಹಲವಾರು ಪ್ರಕರಣಗಳನ್ನು ಪರಿಗಣಿಸೋಣ.
ಭಯಾನಕ ಏನೋ ಸಂಭವಿಸಿದೆ: ಒಂದು ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲ
ಒಂದು ಸರ್ವರ್ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಹೇಳೋಣ. ನಂತರ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಉಳಿದಿರುವ ಸರ್ವರ್ಗಳು ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು, ಆದರೆ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು ಅಪೂರ್ಣವಾಗಿರುತ್ತವೆ.
ಸ್ಥಿತಿ ಪರಿಶೀಲನೆಯ ಮೂಲಕ / ಸ್ಥಿತಿ ಒಂದು ಲಭ್ಯವಿಲ್ಲ ಎಂದು ನೆರೆಯ ಸರ್ವರ್ಗಳು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತವೆ. ಆದ್ದರಿಂದ, ಸಂಪೂರ್ಣತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳಲು, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಸರ್ವರ್ಗಳು ಪ್ರತಿ ವಿನಂತಿಗೆ /ಪಿಂಗ್ ಅವರು ಸಹ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಸರ್ವರ್ಗಳು ಸತ್ತವು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ (ಇದು ನಿಜವಲ್ಲ). ಇದು ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಯೋಜನೆಯ ಮುಖ್ಯ ನ್ಯೂನತೆಯಾಗಿದೆ - ಅದಕ್ಕಾಗಿಯೇ ನಾವು ಅದರಿಂದ ದೂರವಿರಲು ಬಯಸುತ್ತೇವೆ.
ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾದ ವಿನಂತಿಗಳನ್ನು ಇತರ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಬ್ಯಾಲೆನ್ಸರ್ ಮೂಲಕ ಮರುಕಳಿಸಲಾಗುವುದು.
ಬ್ಯಾಲೆನ್ಸರ್ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಸತ್ತ ಸರ್ವರ್‌ಗಳಿಗೆ ಕಳುಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಆದರೆ ಅವರ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
ಸರ್ವರ್ ಲಭ್ಯವಾದಾಗ, ಅದು ಪ್ರತಿಕ್ರಿಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ /ಪಿಂಗ್. ಸತ್ತ ಸರ್ವರ್‌ಗಳಿಂದ ಪಿಂಗ್‌ಗಳಿಗೆ ಸಾಮಾನ್ಯ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಬರಲು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣ, ಬ್ಯಾಲೆನ್ಸರ್ಗಳು ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಕ್ಲಸ್ಟರ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಹುರ್ರೇ.
ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ: ಅನೇಕ ಸರ್ವರ್ಗಳು ಲಭ್ಯವಿಲ್ಲ
ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿನ ಸರ್ವರ್ಗಳ ಗಮನಾರ್ಹ ಭಾಗವನ್ನು ಕಡಿತಗೊಳಿಸಲಾಗಿದೆ. ಏನು ಮಾಡಬೇಕು, ಎಲ್ಲಿ ಓಡಬೇಕು? ಬ್ಯಾಲೆನ್ಸರ್ ಮತ್ತೆ ಪಾರುಗಾಣಿಕಾಕ್ಕೆ ಬರುತ್ತದೆ. ಪ್ರತಿ ಬ್ಯಾಲೆನ್ಸರ್ ಪ್ರಸ್ತುತ ಲೈವ್ ಸರ್ವರ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರಂತರವಾಗಿ ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತ ಡೇಟಾ ಸೆಂಟರ್ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ದಟ್ಟಣೆಯನ್ನು ಇದು ನಿರಂತರವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ.
ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿನ ಅನೇಕ ಸರ್ವರ್ಗಳು ಡೌನ್‌ಗೆ ಹೋದಾಗ, ಈ ಡೇಟಾ ಸೆಂಟರ್ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಬ್ಯಾಲೆನ್ಸರ್ ಅರಿತುಕೊಳ್ಳುತ್ತಾನೆ.
ನಂತರ ಹೆಚ್ಚುವರಿ ದಟ್ಟಣೆಯನ್ನು ಇತರ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ಯಾದೃಚ್ಛಿಕವಾಗಿ ವಿತರಿಸಲು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಎಲ್ಲರೂ ಸಂತೋಷವಾಗಿರುತ್ತಾರೆ.
ನಾವು ಅದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತೇವೆ: ಬಿಡುಗಡೆಗಳನ್ನು ಪ್ರಕಟಿಸುವುದು
ಸೇವೆಯಲ್ಲಿ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ನಾವು ಹೇಗೆ ಪ್ರಕಟಿಸುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಈಗ ಮಾತನಾಡೋಣ. ಇಲ್ಲಿ ನಾವು ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸರಳಗೊಳಿಸುವ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ: ಹೊಸ ಬಿಡುಗಡೆಯನ್ನು ಹೊರತರುವುದು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿದೆ.
ಯೋಜನೆಯಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದಾಗ, ಹೊಸ ಬಿಡುಗಡೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ಅದರ ನಿರ್ಮಾಣವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ನಂತರ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷೆಗೆ ಹೊರತರಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆಯ ಸ್ಥಿರತೆಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಇದನ್ನು ವಿಶೇಷ ಸೇವೆಯಿಂದ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ನಾನು ಈಗ ಅದರ ಬಗ್ಗೆ ಮಾತನಾಡುವುದಿಲ್ಲ - ಅದರ ವಿವರಣೆಯು ಪ್ರತ್ಯೇಕ ಲೇಖನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿದೆ.
ಪರೀಕ್ಷೆಯಲ್ಲಿನ ಪ್ರಕಟಣೆಯು ಯಶಸ್ವಿಯಾದರೆ, ಪ್ರಿಸ್ಟೇಬಲ್‌ನಲ್ಲಿ ಬಿಡುಗಡೆಯ ಪ್ರಕಟಣೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಪ್ರೆಸ್ಟೇಬಲ್ ಒಂದು ವಿಶೇಷ ಕ್ಲಸ್ಟರ್ ಆಗಿದ್ದು, ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ. ಅದು ದೋಷವನ್ನು ಹಿಂದಿರುಗಿಸಿದರೆ, ಬ್ಯಾಲೆನ್ಸರ್ ಉತ್ಪಾದನೆಗೆ ಮರು ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತದೆ.
ಪ್ರೆಸ್ಟೇಬಲ್ನಲ್ಲಿ, ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವನ್ನು ಅಳೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹಿಂದಿನ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ಹೋಲಿಸಲಾಗುತ್ತದೆ. ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿದ್ದರೆ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ಸಂಪರ್ಕಿಸುತ್ತಾನೆ: ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ಉತ್ಪಾದನೆಗೆ ಹೊರಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.
ಎಲ್ಲಾ ಅತ್ಯುತ್ತಮ ಬಳಕೆದಾರರಿಗೆ ಹೋಗುತ್ತದೆ: A/B ಪರೀಕ್ಷೆ
ಸೇವೆಗೆ ಬದಲಾವಣೆಗಳು ನಿಜವಾದ ಪ್ರಯೋಜನಗಳನ್ನು ತರುತ್ತವೆಯೇ ಎಂಬುದು ಯಾವಾಗಲೂ ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಬದಲಾವಣೆಗಳ ಉಪಯುಕ್ತತೆಯನ್ನು ಅಳೆಯಲು, ಜನರು A/B ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಬಂದರು. Yandex.Market ಹುಡುಕಾಟದಲ್ಲಿ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಮಗೆ ಸ್ವಲ್ಪ ಹೇಳುತ್ತೇನೆ.
ಹೊಸ ಕಾರ್ಯವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವ ಹೊಸ CGI ನಿಯತಾಂಕವನ್ನು ಸೇರಿಸುವುದರೊಂದಿಗೆ ಇದು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನಮ್ಮ ನಿಯತಾಂಕ ಹೀಗಿರಲಿ: market_new_functionality=1. ನಂತರ ಕೋಡ್‌ನಲ್ಲಿ ಫ್ಲ್ಯಾಗ್ ಇದ್ದರೆ ನಾವು ಈ ಕಾರ್ಯವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತೇವೆ:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}ಹೊಸ ಕಾರ್ಯವನ್ನು ಉತ್ಪಾದನೆಗೆ ಹೊರತರಲಾಗುತ್ತಿದೆ.
A/B ಪರೀಕ್ಷೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು, ವಿವರವಾದ ಮಾಹಿತಿಯನ್ನು ಒದಗಿಸುವ ಮೀಸಲಾದ ಸೇವೆಯಿದೆ . ಸೇವೆಯಲ್ಲಿ ಪ್ರಯೋಗವನ್ನು ರಚಿಸಲಾಗಿದೆ. ಸಂಚಾರ ಪಾಲನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, 15%. ಶೇಕಡಾವಾರುಗಳನ್ನು ಪ್ರಶ್ನೆಗಳಿಗೆ ಅಲ್ಲ, ಆದರೆ ಬಳಕೆದಾರರಿಗೆ ಹೊಂದಿಸಲಾಗಿದೆ. ಪ್ರಯೋಗದ ಅವಧಿಯನ್ನು ಸಹ ಸೂಚಿಸಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಒಂದು ವಾರ.
ಹಲವಾರು ಪ್ರಯೋಗಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ನಡೆಸಬಹುದು. ಸೆಟ್ಟಿಂಗ್‌ಗಳಲ್ಲಿ ನೀವು ಇತರ ಪ್ರಯೋಗಗಳೊಂದಿಗೆ ಛೇದಕ ಸಾಧ್ಯವೇ ಎಂಬುದನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.
ಪರಿಣಾಮವಾಗಿ, ಸೇವೆಯು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಾದವನ್ನು ಸೇರಿಸುತ್ತದೆ market_new_functionality=1 15% ಬಳಕೆದಾರರಿಗೆ. ಇದು ಆಯ್ದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಪ್ರಯೋಗ ಪೂರ್ಣಗೊಂಡ ನಂತರ, ವಿಶ್ಲೇಷಕರು ಫಲಿತಾಂಶಗಳನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಸಂಶೋಧನೆಗಳ ಆಧಾರದ ಮೇಲೆ, ಉತ್ಪಾದನೆ ಅಥವಾ ಪರಿಷ್ಕರಣೆಗೆ ಹೊರತರಲು ನಿರ್ಧಾರ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.
ಮಾರುಕಟ್ಟೆಯ ಚತುರ ಕೈ: ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪರೀಕ್ಷೆ
ಉತ್ಪಾದನೆಯಲ್ಲಿ ಹೊಸ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನೀವು ಪರೀಕ್ಷಿಸಬೇಕಾಗಿದೆ ಎಂದು ಆಗಾಗ್ಗೆ ಸಂಭವಿಸುತ್ತದೆ, ಆದರೆ ಭಾರೀ ಹೊರೆಯಲ್ಲಿ "ಯುದ್ಧ" ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅದು ಹೇಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂದು ನಿಮಗೆ ಖಚಿತವಿಲ್ಲ.
ಒಂದು ಪರಿಹಾರವಿದೆ: CGI ಪ್ಯಾರಾಮೀಟರ್‌ಗಳಲ್ಲಿನ ಫ್ಲ್ಯಾಗ್‌ಗಳನ್ನು A/B ಪರೀಕ್ಷೆಗೆ ಮಾತ್ರವಲ್ಲದೆ ಹೊಸ ಕಾರ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಲು ಸಹ ಬಳಸಬಹುದು.
ಸೇವೆಯನ್ನು ಅಪಾಯಗಳಿಗೆ ಒಡ್ಡದೆ ಸಾವಿರಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತಕ್ಷಣವೇ ಬದಲಾಯಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಧನವನ್ನು ನಾವು ಮಾಡಿದ್ದೇವೆ. ಇದನ್ನು "ಸ್ಟಾಪ್ ಟ್ಯಾಪ್" ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಲೇಔಟ್ ಇಲ್ಲದೆಯೇ ಕೆಲವು ಕಾರ್ಯಗಳನ್ನು ತ್ವರಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುವುದು ಮೂಲ ಕಲ್ಪನೆ. ನಂತರ ಉಪಕರಣವು ವಿಸ್ತರಿಸಿತು ಮತ್ತು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಯಿತು.
ಸೇವಾ ಹರಿವಿನ ರೇಖಾಚಿತ್ರವನ್ನು ಕೆಳಗೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ:
ಫ್ಲ್ಯಾಗ್ ಮೌಲ್ಯಗಳನ್ನು API ಮೂಲಕ ಹೊಂದಿಸಲಾಗಿದೆ. ನಿರ್ವಹಣಾ ಸೇವೆಯು ಈ ಮೌಲ್ಯಗಳನ್ನು ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಸರ್ವರ್ಗಳು ಪ್ರತಿ ಹತ್ತು ಸೆಕೆಂಡುಗಳಿಗೊಮ್ಮೆ ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಗಿ, ಫ್ಲ್ಯಾಗ್ ಮೌಲ್ಯಗಳನ್ನು ಪಂಪ್ ಮಾಡಿ ಮತ್ತು ಪ್ರತಿ ವಿನಂತಿಗೆ ಈ ಮೌಲ್ಯಗಳನ್ನು ಅನ್ವಯಿಸಿ.
ಸ್ಟಾಪ್ ಟ್ಯಾಪ್ನಲ್ಲಿ ನೀವು ಎರಡು ರೀತಿಯ ಮೌಲ್ಯಗಳನ್ನು ಹೊಂದಿಸಬಹುದು:
1) ಷರತ್ತುಬದ್ಧ ಅಭಿವ್ಯಕ್ತಿಗಳು. ಮೌಲ್ಯಗಳಲ್ಲಿ ಒಂದು ನಿಜವಾಗಿರುವಾಗ ಅನ್ವಯಿಸಿ. ಉದಾಹರಣೆಗೆ:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}ಸ್ಥಳ DC3 ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ "1" ಮೌಲ್ಯವನ್ನು ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಮತ್ತು beru.ru ಸೈಟ್‌ಗಾಗಿ ಎರಡನೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿದಾಗ ಮೌಲ್ಯವು "4" ಆಗಿದೆ.
2) ಬೇಷರತ್ತಾದ ಮೌಲ್ಯಗಳು. ಯಾವುದೇ ಷರತ್ತುಗಳನ್ನು ಪೂರೈಸದಿದ್ದರೆ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಅನ್ವಯಿಸಿ. ಉದಾಹರಣೆಗೆ:
ಮೌಲ್ಯ, ಮೌಲ್ಯ!
ಒಂದು ಮೌಲ್ಯವು ಆಶ್ಚರ್ಯಸೂಚಕ ಬಿಂದುವಿನೊಂದಿಗೆ ಕೊನೆಗೊಂಡರೆ, ಅದಕ್ಕೆ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯನ್ನು ನೀಡಲಾಗುತ್ತದೆ.
CGI ಪ್ಯಾರಾಮೀಟರ್ ಪಾರ್ಸರ್ URL ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡುತ್ತದೆ. ನಂತರ ಸ್ಟಾಪ್ ಟ್ಯಾಪ್‌ನಿಂದ ಮೌಲ್ಯಗಳನ್ನು ಅನ್ವಯಿಸುತ್ತದೆ.
ಕೆಳಗಿನ ಆದ್ಯತೆಗಳೊಂದಿಗೆ ಮೌಲ್ಯಗಳನ್ನು ಅನ್ವಯಿಸಲಾಗಿದೆ:
- ಸ್ಟಾಪ್ ಟ್ಯಾಪ್‌ನಿಂದ ಹೆಚ್ಚಿನ ಆದ್ಯತೆಯೊಂದಿಗೆ (ಆಶ್ಚರ್ಯಾರ್ಥ ಚಿಹ್ನೆ).
- ವಿನಂತಿಯಿಂದ ಮೌಲ್ಯ.
- ಸ್ಟಾಪ್ ಟ್ಯಾಪ್‌ನಿಂದ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯ.
- ಕೋಡ್‌ನಲ್ಲಿ ಡೀಫಾಲ್ಟ್ ಮೌಲ್ಯ.
ಷರತ್ತುಬದ್ಧ ಮೌಲ್ಯಗಳಲ್ಲಿ ಸೂಚಿಸಲಾದ ಅನೇಕ ಧ್ವಜಗಳಿವೆ - ನಮಗೆ ತಿಳಿದಿರುವ ಎಲ್ಲಾ ಸನ್ನಿವೇಶಗಳಿಗೆ ಅವು ಸಾಕು:
- ಡೇಟಾ ಸೆಂಟರ್.
- ಪರಿಸರ: ಉತ್ಪಾದನೆ, ಪರೀಕ್ಷೆ, ನೆರಳು.
- ಸ್ಥಳ: ಮಾರುಕಟ್ಟೆ, ಬೇರು.
- ಕ್ಲಸ್ಟರ್ ಸಂಖ್ಯೆ.
ಈ ಉಪಕರಣದೊಂದಿಗೆ, ನೀವು ಒಂದು ನಿರ್ದಿಷ್ಟ ಗುಂಪಿನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಹೊಸ ಕಾರ್ಯವನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು (ಉದಾಹರಣೆಗೆ, ಕೇವಲ ಒಂದು ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ) ಮತ್ತು ಸಂಪೂರ್ಣ ಸೇವೆಗೆ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಅಪಾಯವಿಲ್ಲದೆ ಈ ಕಾರ್ಯದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು. ನೀವು ಎಲ್ಲೋ ಗಂಭೀರ ತಪ್ಪು ಮಾಡಿದರೂ ಸಹ, ಎಲ್ಲವೂ ಬೀಳಲು ಪ್ರಾರಂಭಿಸಿತು ಮತ್ತು ಸಂಪೂರ್ಣ ಡೇಟಾ ಕೇಂದ್ರವು ಕೆಳಗಿಳಿಯಿತು, ಬ್ಯಾಲೆನ್ಸರ್ಗಳು ಇತರ ಡೇಟಾ ಕೇಂದ್ರಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಅಂತಿಮ ಬಳಕೆದಾರರು ಏನನ್ನೂ ಗಮನಿಸುವುದಿಲ್ಲ.
ನೀವು ಸಮಸ್ಯೆಯನ್ನು ಗಮನಿಸಿದರೆ, ನೀವು ತಕ್ಷಣವೇ ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಅದರ ಹಿಂದಿನ ಮೌಲ್ಯಕ್ಕೆ ಹಿಂತಿರುಗಿಸಬಹುದು ಮತ್ತು ಬದಲಾವಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ.
ಈ ಸೇವೆಯು ಅದರ ದುಷ್ಪರಿಣಾಮಗಳನ್ನು ಸಹ ಹೊಂದಿದೆ: ಡೆವಲಪರ್‌ಗಳು ಇದನ್ನು ತುಂಬಾ ಇಷ್ಟಪಡುತ್ತಾರೆ ಮತ್ತು ಆಗಾಗ್ಗೆ ಎಲ್ಲಾ ಬದಲಾವಣೆಗಳನ್ನು ಸ್ಟಾಪ್ ಟ್ಯಾಪ್‌ಗೆ ತಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ. ನಾವು ದುರುಪಯೋಗವನ್ನು ಎದುರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.
ಉತ್ಪಾದನೆಗೆ ಹೊರತರಲು ನೀವು ಈಗಾಗಲೇ ಸ್ಥಿರ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಸ್ಟಾಪ್ ಟ್ಯಾಪ್ ವಿಧಾನವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನೀವು ಇನ್ನೂ ಅನುಮಾನಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ, ಮತ್ತು ನೀವು "ಯುದ್ಧ" ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೋಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಲು ಬಯಸುತ್ತೀರಿ.
ಆದಾಗ್ಯೂ, ಸ್ಟಾಪ್ ಟ್ಯಾಪ್ ಅಭಿವೃದ್ಧಿಯ ಸಮಯದಲ್ಲಿ ಪರೀಕ್ಷೆಗೆ ಸೂಕ್ತವಲ್ಲ. ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ "ನೆರಳು ಕ್ಲಸ್ಟರ್" ಎಂದು ಕರೆಯಲ್ಪಡುವ ಪ್ರತ್ಯೇಕ ಕ್ಲಸ್ಟರ್ ಇದೆ.
ರಹಸ್ಯ ಪರೀಕ್ಷೆ: ನೆರಳು ಕ್ಲಸ್ಟರ್
ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಒಂದರಿಂದ ವಿನಂತಿಗಳನ್ನು ನೆರಳು ಕ್ಲಸ್ಟರ್‌ಗೆ ನಕಲು ಮಾಡಲಾಗುತ್ತದೆ. ಆದರೆ ಬ್ಯಾಲೆನ್ಸರ್ ಈ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಅದರ ಕಾರ್ಯಾಚರಣೆಯ ರೇಖಾಚಿತ್ರವನ್ನು ಕೆಳಗೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ.
ನಾವು ನಿಜವಾದ "ಯುದ್ಧ" ಸ್ಥಿತಿಯಲ್ಲಿರುವ ಪರೀಕ್ಷಾ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಸಾಮಾನ್ಯ ಬಳಕೆದಾರ ಸಂಚಾರ ಅಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ. ಎರಡೂ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿನ ಯಂತ್ರಾಂಶವು ಒಂದೇ ಆಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಕಾರ್ಯಕ್ಷಮತೆ ಮತ್ತು ದೋಷಗಳನ್ನು ಹೋಲಿಸಬಹುದು.
ಮತ್ತು ಬ್ಯಾಲೆನ್ಸರ್ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಲಕ್ಷಿಸುವುದರಿಂದ, ಅಂತಿಮ ಬಳಕೆದಾರರು ನೆರಳು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ನೋಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ತಪ್ಪು ಮಾಡಲು ಹೆದರಿಕೆಯಿಲ್ಲ.
ಸಂಶೋಧನೆಗಳು
ಹಾಗಾದರೆ, ನಾವು ಮಾರುಕಟ್ಟೆ ಹುಡುಕಾಟವನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸಿದ್ದೇವೆ?
ಎಲ್ಲವನ್ನೂ ಸುಗಮವಾಗಿ ಮಾಡಲು, ನಾವು ಕಾರ್ಯವನ್ನು ಪ್ರತ್ಯೇಕ ಸೇವೆಗಳಾಗಿ ಪ್ರತ್ಯೇಕಿಸುತ್ತೇವೆ. ಈ ರೀತಿಯಾಗಿ ನಾವು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಘಟಕಗಳನ್ನು ಮಾತ್ರ ಅಳೆಯಬಹುದು ಮತ್ತು ಘಟಕಗಳನ್ನು ಸರಳಗೊಳಿಸಬಹುದು. ಮತ್ತೊಂದು ತಂಡಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಘಟಕವನ್ನು ನಿಯೋಜಿಸಲು ಮತ್ತು ಅದರ ಮೇಲೆ ಕೆಲಸ ಮಾಡುವ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಸುಲಭವಾಗಿದೆ. ಮತ್ತು ಈ ವಿಧಾನದೊಂದಿಗೆ ಕಬ್ಬಿಣದ ಗಮನಾರ್ಹ ಉಳಿತಾಯವು ಸ್ಪಷ್ಟವಾದ ಪ್ಲಸ್ ಆಗಿದೆ.
ನೆರಳು ಕ್ಲಸ್ಟರ್ ಸಹ ನಮಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ: ನಾವು ಸೇವೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬಹುದು, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅವುಗಳನ್ನು ಪರೀಕ್ಷಿಸಬಹುದು ಮತ್ತು ಬಳಕೆದಾರರಿಗೆ ತೊಂದರೆ ನೀಡುವುದಿಲ್ಲ.
ಸರಿ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಪರೀಕ್ಷೆ, ಸಹಜವಾಗಿ. ಸಾವಿರಾರು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕೇ? ಸುಲಭ, ಸ್ಟಾಪ್ ಟ್ಯಾಪ್ ಬಳಸಿ. ಈ ರೀತಿಯಾಗಿ ನೀವು ತಕ್ಷಣ ಸಿದ್ಧ ಸಂಕೀರ್ಣ ಪರಿಹಾರವನ್ನು ರೋಲ್ ಮಾಡಬಹುದು ಮತ್ತು ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದರೆ ಸ್ಥಿರ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಬಹುದು.
ನಿರಂತರವಾಗಿ ಬೆಳೆಯುತ್ತಿರುವ ಕೊಡುಗೆಗಳೊಂದಿಗೆ ನಾವು ಮಾರುಕಟ್ಟೆಯನ್ನು ಹೇಗೆ ವೇಗವಾಗಿ ಮತ್ತು ಸ್ಥಿರಗೊಳಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ತೋರಿಸಲು ನನಗೆ ಸಾಧ್ಯವಾಯಿತು ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾವು ಸರ್ವರ್ ಸಮಸ್ಯೆಗಳನ್ನು ಹೇಗೆ ಪರಿಹರಿಸುತ್ತೇವೆ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿನಂತಿಗಳನ್ನು ನಿಭಾಯಿಸುತ್ತೇವೆ, ಸೇವೆಯ ನಮ್ಯತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತೇವೆ ಮತ್ತು ಕೆಲಸದ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಅಡ್ಡಿಯಾಗದಂತೆ ಇದನ್ನು ಮಾಡುತ್ತೇವೆ.
ಮೂಲ: www.habr.com