ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಸೆರ್ಗೆ ಕೋಸ್ಟಾನ್‌ಬೇವ್, ಎಕ್ಸ್‌ಚೇಂಜ್‌ನಲ್ಲಿ ನಾನು ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಯ ತಿರುಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇನೆ.
ಹಾಲಿವುಡ್ ಚಲನಚಿತ್ರಗಳು ನ್ಯೂಯಾರ್ಕ್ ಸ್ಟಾಕ್ ಎಕ್ಸ್ಚೇಂಜ್ ಅನ್ನು ತೋರಿಸಿದಾಗ, ಅದು ಯಾವಾಗಲೂ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: ಜನರ ಗುಂಪುಗಳು, ಎಲ್ಲರೂ ಏನನ್ನಾದರೂ ಕೂಗುತ್ತಿದ್ದಾರೆ, ಪೇಪರ್ಗಳನ್ನು ಬೀಸುತ್ತಿದ್ದಾರೆ, ಸಂಪೂರ್ಣ ಅವ್ಯವಸ್ಥೆ ನಡೆಯುತ್ತಿದೆ. ಮಾಸ್ಕೋ ಎಕ್ಸ್‌ಚೇಂಜ್‌ನಲ್ಲಿ ಇದು ಎಂದಿಗೂ ಸಂಭವಿಸಿಲ್ಲ, ಏಕೆಂದರೆ ವ್ಯಾಪಾರವನ್ನು ಮೊದಲಿನಿಂದಲೂ ವಿದ್ಯುನ್ಮಾನವಾಗಿ ನಡೆಸಲಾಗಿದೆ ಮತ್ತು ಎರಡು ಮುಖ್ಯ ವೇದಿಕೆಗಳನ್ನು ಆಧರಿಸಿದೆ - ಸ್ಪೆಕ್ಟ್ರಾ (ಫಾರೆಕ್ಸ್ ಮಾರುಕಟ್ಟೆ) ಮತ್ತು ASTS (ವಿದೇಶಿ ವಿನಿಮಯ, ಷೇರು ಮತ್ತು ಹಣ ಮಾರುಕಟ್ಟೆ). ಮತ್ತು ಇಂದು ನಾನು ASTS ಟ್ರೇಡಿಂಗ್ ಮತ್ತು ಕ್ಲಿಯರಿಂಗ್ ಸಿಸ್ಟಮ್ನ ವಾಸ್ತುಶಿಲ್ಪದ ವಿಕಾಸದ ಬಗ್ಗೆ, ವಿವಿಧ ಪರಿಹಾರಗಳು ಮತ್ತು ಸಂಶೋಧನೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ. ಕಥೆ ದೀರ್ಘವಾಗಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾನು ಅದನ್ನು ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸಬೇಕಾಗಿತ್ತು.
ಎಲ್ಲಾ ವರ್ಗಗಳ ಸ್ವತ್ತುಗಳನ್ನು ವ್ಯಾಪಾರ ಮಾಡುವ ಮತ್ತು ಸಂಪೂರ್ಣ ಶ್ರೇಣಿಯ ವಿನಿಮಯ ಸೇವೆಗಳನ್ನು ಒದಗಿಸುವ ವಿಶ್ವದ ಕೆಲವು ವಿನಿಮಯ ಕೇಂದ್ರಗಳಲ್ಲಿ ನಾವು ಒಂದಾಗಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ಕಳೆದ ವರ್ಷ ನಾವು ಬಾಂಡ್ ಟ್ರೇಡಿಂಗ್ ಪರಿಮಾಣದ ವಿಷಯದಲ್ಲಿ ಜಗತ್ತಿನಲ್ಲಿ ಎರಡನೇ ಸ್ಥಾನವನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ, ಎಲ್ಲಾ ಸ್ಟಾಕ್ ಎಕ್ಸ್ಚೇಂಜ್ಗಳಲ್ಲಿ 25 ನೇ ಸ್ಥಾನ, ಸಾರ್ವಜನಿಕ ವಿನಿಮಯ ಕೇಂದ್ರಗಳಲ್ಲಿ ಬಂಡವಾಳೀಕರಣದಲ್ಲಿ 13 ನೇ ಸ್ಥಾನ.
ವೃತ್ತಿಪರ ವ್ಯಾಪಾರದಲ್ಲಿ ಭಾಗವಹಿಸುವವರಿಗೆ, ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ, ಸಮಯದ ವಿತರಣೆಯ ಸ್ಥಿರತೆ (ಜಿಟ್ಟರ್) ಮತ್ತು ಸಂಪೂರ್ಣ ಸಂಕೀರ್ಣದ ವಿಶ್ವಾಸಾರ್ಹತೆಯಂತಹ ನಿಯತಾಂಕಗಳು ನಿರ್ಣಾಯಕವಾಗಿವೆ. ನಾವು ಪ್ರಸ್ತುತ ದಿನಕ್ಕೆ ಹತ್ತಾರು ಮಿಲಿಯನ್ ವಹಿವಾಟುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತೇವೆ. ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ನಿಂದ ಪ್ರತಿ ವಹಿವಾಟಿನ ಪ್ರಕ್ರಿಯೆಯು ಹತ್ತಾರು ಮೈಕ್ರೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಹಜವಾಗಿ, ಹೊಸ ವರ್ಷದ ಮುನ್ನಾದಿನದಂದು ಮೊಬೈಲ್ ಆಪರೇಟರ್‌ಗಳು ಅಥವಾ ಸರ್ಚ್ ಇಂಜಿನ್‌ಗಳು ನಮಗಿಂತ ಹೆಚ್ಚಿನ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಆದರೆ ಕೆಲಸದ ಹೊರೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಮೇಲೆ ತಿಳಿಸಿದ ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ, ಕೆಲವರು ನಮ್ಮೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು, ಅದು ನನಗೆ ತೋರುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಒಂದು ಸೆಕೆಂಡಿಗೆ ನಿಧಾನವಾಗುವುದಿಲ್ಲ, ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಥಿರವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಸಮಾನ ಹೆಜ್ಜೆಯಲ್ಲಿದ್ದಾರೆ ಎಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ.
ಸ್ವಲ್ಪ ಇತಿಹಾಸ
1994 ರಲ್ಲಿ, ಆಸ್ಟ್ರೇಲಿಯನ್ ASTS ವ್ಯವಸ್ಥೆಯನ್ನು ಮಾಸ್ಕೋ ಇಂಟರ್ಬ್ಯಾಂಕ್ ಕರೆನ್ಸಿ ಎಕ್ಸ್ಚೇಂಜ್ (MICEX) ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಯಿತು, ಮತ್ತು ಆ ಕ್ಷಣದಿಂದ ಎಲೆಕ್ಟ್ರಾನಿಕ್ ವ್ಯಾಪಾರದ ರಷ್ಯಾದ ಇತಿಹಾಸವನ್ನು ಎಣಿಸಬಹುದು. 1998 ರಲ್ಲಿ, ಇಂಟರ್ನೆಟ್ ವ್ಯಾಪಾರವನ್ನು ಪರಿಚಯಿಸಲು ವಿನಿಮಯ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ಆಧುನೀಕರಿಸಲಾಯಿತು. ಅಂದಿನಿಂದ, ಎಲ್ಲಾ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ಉಪವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಹೊಸ ಪರಿಹಾರಗಳು ಮತ್ತು ವಾಸ್ತುಶಿಲ್ಪದ ಬದಲಾವಣೆಗಳ ಅನುಷ್ಠಾನದ ವೇಗವು ವೇಗವನ್ನು ಪಡೆಯುತ್ತಿದೆ.
ಆ ವರ್ಷಗಳಲ್ಲಿ, ವಿನಿಮಯ ವ್ಯವಸ್ಥೆಯು ಹೈ-ಎಂಡ್ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿತು - ಅಲ್ಟ್ರಾ-ವಿಶ್ವಾಸಾರ್ಹ HP ಸೂಪರ್‌ಡೋಮ್ 9000 ಸರ್ವರ್‌ಗಳು (ನಿರ್ಮಿಸಲಾಗಿದೆ), ಇದರಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲವನ್ನೂ ನಕಲು ಮಾಡಲಾಗಿದೆ: ಇನ್‌ಪುಟ್/ಔಟ್‌ಪುಟ್ ಉಪವ್ಯವಸ್ಥೆಗಳು, ನೆಟ್‌ವರ್ಕ್, RAM (ವಾಸ್ತವವಾಗಿ, RAM ನ RAID ಅರೇ ಇತ್ತು), ಪ್ರೊಸೆಸರ್‌ಗಳು (ಹಾಟ್-ಸ್ವಾಪ್ ಮಾಡಬಹುದಾದ). ಯಂತ್ರವನ್ನು ನಿಲ್ಲಿಸದೆಯೇ ಯಾವುದೇ ಸರ್ವರ್ ಘಟಕವನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ನಾವು ಈ ಸಾಧನಗಳನ್ನು ಅವಲಂಬಿಸಿದ್ದೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ವಾಸ್ತವಿಕವಾಗಿ ವಿಫಲ-ಸುರಕ್ಷಿತವೆಂದು ಪರಿಗಣಿಸಿದ್ದೇವೆ. ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಯುನಿಕ್ಸ್ ತರಹದ HP UX ಸಿಸ್ಟಮ್ ಆಗಿತ್ತು.
ಆದರೆ ಸುಮಾರು 2010 ರಿಂದ, ಹೈ-ಫ್ರೀಕ್ವೆನ್ಸಿ ಟ್ರೇಡಿಂಗ್ (HFT), ಅಥವಾ ಹೆಚ್ಚಿನ ಆವರ್ತನ ವ್ಯಾಪಾರ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ವಿದ್ಯಮಾನವು ಹೊರಹೊಮ್ಮಿದೆ - ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಸ್ಟಾಕ್ ಎಕ್ಸ್ಚೇಂಜ್ ರೋಬೋಟ್ಗಳು. ಕೇವಲ 2,5 ವರ್ಷಗಳಲ್ಲಿ, ನಮ್ಮ ಸರ್ವರ್‌ಗಳಲ್ಲಿನ ಲೋಡ್ 140 ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ.
ಹಳೆಯ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಸಲಕರಣೆಗಳೊಂದಿಗೆ ಅಂತಹ ಹೊರೆಯನ್ನು ತಡೆದುಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯವಾಗಿತ್ತು. ಹೇಗಾದರೂ ಹೊಂದಿಕೊಳ್ಳುವುದು ಅಗತ್ಯವಾಗಿತ್ತು.
Начало
ವಿನಿಮಯ ವ್ಯವಸ್ಥೆಗೆ ವಿನಂತಿಗಳನ್ನು ಎರಡು ವಿಧಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
- ವಹಿವಾಟುಗಳು. ನೀವು ಡಾಲರ್‌ಗಳು, ಷೇರುಗಳು ಅಥವಾ ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಖರೀದಿಸಲು ಬಯಸಿದರೆ, ನೀವು ವಹಿವಾಟು ವ್ಯವಸ್ಥೆಗೆ ವ್ಯವಹಾರವನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ ಮತ್ತು ಯಶಸ್ಸಿನ ಬಗ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.
- ಮಾಹಿತಿ ವಿನಂತಿಗಳು. ನೀವು ಪ್ರಸ್ತುತ ಬೆಲೆಯನ್ನು ಕಂಡುಹಿಡಿಯಲು ಬಯಸಿದರೆ, ಆದೇಶ ಪುಸ್ತಕ ಅಥವಾ ಸೂಚ್ಯಂಕಗಳನ್ನು ವೀಕ್ಷಿಸಿ, ನಂತರ ಮಾಹಿತಿ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸಿ.
ಕ್ರಮಬದ್ಧವಾಗಿ, ವ್ಯವಸ್ಥೆಯ ತಿರುಳನ್ನು ಮೂರು ಹಂತಗಳಾಗಿ ವಿಂಗಡಿಸಬಹುದು:
- ದಲ್ಲಾಳಿಗಳು ಮತ್ತು ಗ್ರಾಹಕರು ಕೆಲಸ ಮಾಡುವ ಕ್ಲೈಂಟ್ ಮಟ್ಟ. ಅವರೆಲ್ಲರೂ ಪ್ರವೇಶ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ.
- ಗೇಟ್ವೇ ಸರ್ವರ್‌ಗಳು ಕ್ಯಾಶಿಂಗ್ ಸರ್ವರ್‌ಗಳು ಸ್ಥಳೀಯವಾಗಿ ಎಲ್ಲಾ ಮಾಹಿತಿ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತವೆ. Sberbank ಷೇರುಗಳು ಪ್ರಸ್ತುತ ಯಾವ ಬೆಲೆಗೆ ವ್ಯಾಪಾರ ಮಾಡುತ್ತಿವೆ ಎಂದು ತಿಳಿಯಲು ನೀವು ಬಯಸುವಿರಾ? ವಿನಂತಿಯು ಪ್ರವೇಶ ಸರ್ವರ್‌ಗೆ ಹೋಗುತ್ತದೆ.
- ಆದರೆ ನೀವು ಷೇರುಗಳನ್ನು ಖರೀದಿಸಲು ಬಯಸಿದರೆ, ನಂತರ ವಿನಂತಿಯು ಕೇಂದ್ರ ಸರ್ವರ್ (ಟ್ರೇಡ್ ಇಂಜಿನ್) ಗೆ ಹೋಗುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ರೀತಿಯ ಮಾರುಕಟ್ಟೆಗೆ ಅಂತಹ ಒಂದು ಸರ್ವರ್ ಇದೆ, ಅವರು ಪ್ರಮುಖ ಪಾತ್ರ ವಹಿಸುತ್ತಾರೆ, ಅವರಿಗಾಗಿ ನಾವು ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ.
ಟ್ರೇಡಿಂಗ್ ಸಿಸ್ಟಮ್ನ ತಿರುಳು ಬುದ್ಧಿವಂತ ಇನ್-ಮೆಮೊರಿ ಡೇಟಾಬೇಸ್ ಆಗಿದ್ದು, ಇದರಲ್ಲಿ ಎಲ್ಲಾ ವಹಿವಾಟುಗಳು ವಿನಿಮಯ ವಹಿವಾಟುಗಳಾಗಿವೆ. ಮೂಲವನ್ನು C ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಕೇವಲ ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳು libc ಲೈಬ್ರರಿ ಮತ್ತು ಯಾವುದೇ ಡೈನಾಮಿಕ್ ಮೆಮೊರಿ ಹಂಚಿಕೆ ಇರಲಿಲ್ಲ. ಸಂಸ್ಕರಣಾ ಸಮಯವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಸಿಸ್ಟಮ್ ಅರೇಗಳ ಸ್ಥಿರ ಸೆಟ್ ಮತ್ತು ಸ್ಥಿರ ಡೇಟಾ ಸ್ಥಳಾಂತರದೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ: ಮೊದಲನೆಯದಾಗಿ, ಪ್ರಸ್ತುತ ದಿನದ ಎಲ್ಲಾ ಡೇಟಾವನ್ನು ಮೆಮೊರಿಗೆ ಲೋಡ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಯಾವುದೇ ಹೆಚ್ಚಿನ ಡಿಸ್ಕ್ ಪ್ರವೇಶವನ್ನು ನಿರ್ವಹಿಸುವುದಿಲ್ಲ, ಎಲ್ಲಾ ಕೆಲಸಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಮಾತ್ರ ನಡೆಸಲಾಗುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಪ್ರಾರಂಭವಾದಾಗ, ಎಲ್ಲಾ ಉಲ್ಲೇಖ ಡೇಟಾವನ್ನು ಈಗಾಗಲೇ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಆದ್ದರಿಂದ ಹುಡುಕಾಟವು ತುಂಬಾ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ರನ್ಟೈಮ್ನಲ್ಲಿ ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಡೈನಾಮಿಕ್ ಡೇಟಾ ರಚನೆಗಳಿಗಾಗಿ ಎಲ್ಲಾ ಕೋಷ್ಟಕಗಳು ಒಳನುಗ್ಗುವ ಪಟ್ಟಿಗಳು ಮತ್ತು ಮರಗಳೊಂದಿಗೆ ಮಾಡಲ್ಪಟ್ಟಿದೆ ಆದ್ದರಿಂದ ಅವುಗಳು ರನ್ಟೈಮ್ನಲ್ಲಿ ಮೆಮೊರಿ ಹಂಚಿಕೆಯ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.
ನಮ್ಮ ವ್ಯಾಪಾರ ಮತ್ತು ಕ್ಲಿಯರಿಂಗ್ ವ್ಯವಸ್ಥೆಯ ಅಭಿವೃದ್ಧಿಯ ಇತಿಹಾಸವನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ನೋಡೋಣ.
ಟ್ರೇಡಿಂಗ್ ಮತ್ತು ಕ್ಲಿಯರಿಂಗ್ ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ಯುನಿಕ್ಸ್ ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ: ಹಂಚಿದ ಮೆಮೊರಿ, ಸೆಮಾಫೋರ್‌ಗಳು ಮತ್ತು ಕ್ಯೂಗಳನ್ನು ಬಳಸಲಾಗುತ್ತಿತ್ತು ಮತ್ತು ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯು ಒಂದೇ ಥ್ರೆಡ್ ಅನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಈ ವಿಧಾನವು 1990 ರ ದಶಕದ ಆರಂಭದಲ್ಲಿ ವ್ಯಾಪಕವಾಗಿ ಹರಡಿತು.
ಸಿಸ್ಟಮ್ನ ಮೊದಲ ಆವೃತ್ತಿಯು ಎರಡು ಹಂತದ ಗೇಟ್ವೇ ಮತ್ತು ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಯ ಕೇಂದ್ರ ಸರ್ವರ್ ಅನ್ನು ಒಳಗೊಂಡಿತ್ತು. ಕೆಲಸದ ಹರಿವು ಹೀಗಿತ್ತು:
- ಕ್ಲೈಂಟ್ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಅದು ಗೇಟ್ವೇ ತಲುಪುತ್ತದೆ. ಇದು ಸ್ವರೂಪದ ಸಿಂಧುತ್ವವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ (ಆದರೆ ಡೇಟಾ ಅಲ್ಲ) ಮತ್ತು ತಪ್ಪಾದ ವಹಿವಾಟುಗಳನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.
- ಮಾಹಿತಿ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದರೆ, ಅದನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ; ನಾವು ವಹಿವಾಟಿನ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, ಅದನ್ನು ಕೇಂದ್ರ ಸರ್ವರ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ.
- ಟ್ರೇಡಿಂಗ್ ಇಂಜಿನ್ ನಂತರ ವಹಿವಾಟನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಸ್ಥಳೀಯ ಮೆಮೊರಿಯನ್ನು ಮಾರ್ಪಡಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತ್ಯೇಕ ಪ್ರತಿಕೃತಿ ಎಂಜಿನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಕಲು ಮಾಡಲು ವಹಿವಾಟು ಮತ್ತು ವಹಿವಾಟಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ.
- ಗೇಟ್ವೇ ಕೇಂದ್ರೀಯ ನೋಡ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಕ್ಲೈಂಟ್‌ಗೆ ರವಾನಿಸುತ್ತದೆ.
- ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ, ಗೇಟ್ವೇ ಪ್ರತಿಕೃತಿ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ವಹಿವಾಟನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಈ ಬಾರಿ ಅದು ಸ್ಥಳೀಯವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ, ಅದರ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ ಇದರಿಂದ ಮುಂದಿನ ಮಾಹಿತಿ ವಿನಂತಿಗಳು ಇತ್ತೀಚಿನ ಡೇಟಾವನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ.
ವಾಸ್ತವವಾಗಿ, ಇದು ಪ್ರತಿಕೃತಿ ಮಾದರಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಗೇಟ್ವೇ ವ್ಯಾಪಾರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಮಾಡಿದ ಕ್ರಿಯೆಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಬಹು ಪ್ರವೇಶ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಒಂದೇ ಕ್ರಮದಲ್ಲಿ ವಹಿವಾಟುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಪ್ರತ್ಯೇಕ ಪ್ರತಿಕೃತಿ ಚಾನಲ್ ಖಚಿತಪಡಿಸುತ್ತದೆ.
ಕೋಡ್ ಏಕ-ಥ್ರೆಡ್ ಆಗಿರುವುದರಿಂದ, ಹಲವಾರು ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸಲು ಪ್ರಕ್ರಿಯೆ ಫೋರ್ಕ್‌ಗಳೊಂದಿಗೆ ಕ್ಲಾಸಿಕ್ ಸ್ಕೀಮ್ ಅನ್ನು ಬಳಸಲಾಯಿತು. ಆದಾಗ್ಯೂ, ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಫೋರ್ಕ್ ಮಾಡುವುದು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ, ಆದ್ದರಿಂದ TCP ಸೆಷನ್‌ಗಳಿಂದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಅವುಗಳನ್ನು ಒಂದು ಸರತಿಗೆ (SystemV ಸಂದೇಶ ಕ್ಯೂ) ವರ್ಗಾಯಿಸುವ ಹಗುರವಾದ ಸೇವಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸಲಾಯಿತು. ಗೇಟ್ವೇ ಮತ್ತು ಟ್ರೇಡ್ ಇಂಜಿನ್ ಈ ಸರದಿಯಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅಲ್ಲಿಂದ ವಹಿವಾಟುಗಳನ್ನು ತೆಗೆದುಕೊಂಡವು. ಅದಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸಲು ಇನ್ನು ಮುಂದೆ ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಏಕೆಂದರೆ ಯಾವ ಸೇವಾ ಪ್ರಕ್ರಿಯೆಯು ಅದನ್ನು ಓದಬೇಕು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ. ಆದ್ದರಿಂದ ನಾವು ಒಂದು ಟ್ರಿಕ್ ಅನ್ನು ಆಶ್ರಯಿಸಿದ್ದೇವೆ: ಪ್ರತಿ ಫೋರ್ಕ್ ಮಾಡಿದ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವತಃ ಪ್ರತಿಕ್ರಿಯೆ ಕ್ಯೂ ಅನ್ನು ರಚಿಸುತ್ತದೆ, ಮತ್ತು ವಿನಂತಿಯು ಒಳಬರುವ ಸರದಿಯಲ್ಲಿ ಬಂದಾಗ, ಪ್ರತಿಕ್ರಿಯೆ ಸರತಿಗೆ ಒಂದು ಟ್ಯಾಗ್ ಅನ್ನು ತಕ್ಷಣವೇ ಸೇರಿಸಲಾಗುತ್ತದೆ.
ಸರದಿಯಿಂದ ಸರತಿಗೆ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ನಿರಂತರವಾಗಿ ನಕಲಿಸುವುದು ಸಮಸ್ಯೆಗಳನ್ನು ಸೃಷ್ಟಿಸಿದೆ, ವಿಶೇಷವಾಗಿ ಮಾಹಿತಿ ವಿನಂತಿಗಳಿಗೆ ವಿಶಿಷ್ಟವಾಗಿದೆ. ಆದ್ದರಿಂದ, ನಾವು ಮತ್ತೊಂದು ಟ್ರಿಕ್ ಅನ್ನು ಬಳಸಿದ್ದೇವೆ: ಪ್ರತಿಕ್ರಿಯೆ ಸರತಿಗೆ ಹೆಚ್ಚುವರಿಯಾಗಿ, ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯು ಹಂಚಿದ ಮೆಮೊರಿಯನ್ನು ಸಹ ರಚಿಸಿದೆ (SystemV ಹಂಚಿಕೆಯ ಮೆಮೊರಿ). ಪ್ಯಾಕೇಜುಗಳನ್ನು ಸ್ವತಃ ಅದರಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ ಮತ್ತು ಸರದಿಯಲ್ಲಿ ಟ್ಯಾಗ್ ಅನ್ನು ಮಾತ್ರ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಇದು ಮೂಲ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಹುಡುಕಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಪ್ರೊಸೆಸರ್ ಸಂಗ್ರಹದಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಹಾಯ ಮಾಡಿತು.
SystemV IPC ಕ್ಯೂ, ಮೆಮೊರಿ ಮತ್ತು ಸೆಮಾಫೋರ್ ವಸ್ತುಗಳ ಸ್ಥಿತಿಯನ್ನು ವೀಕ್ಷಿಸಲು ಉಪಯುಕ್ತತೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ನಿರ್ದಿಷ್ಟ ಕ್ಷಣದಲ್ಲಿ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಏನಾಗುತ್ತಿದೆ, ಅಲ್ಲಿ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಂಗ್ರಹಗೊಂಡವು, ಏನು ನಿರ್ಬಂಧಿಸಲಾಗಿದೆ ಇತ್ಯಾದಿಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾವು ಇದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದ್ದೇವೆ.
ಮೊದಲ ಆಧುನೀಕರಣಗಳು
ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಏಕ-ಪ್ರಕ್ರಿಯೆಯ ಗೇಟ್ವೇ ಅನ್ನು ತೊಡೆದುಹಾಕಿದ್ದೇವೆ. ಇದರ ಗಮನಾರ್ಹ ನ್ಯೂನತೆಯೆಂದರೆ, ಇದು ಒಂದು ಪ್ರತಿಕೃತಿ ವಹಿವಾಟು ಅಥವಾ ಕ್ಲೈಂಟ್‌ನಿಂದ ಒಂದು ಮಾಹಿತಿ ವಿನಂತಿಯನ್ನು ನಿಭಾಯಿಸಬಲ್ಲದು. ಮತ್ತು ಲೋಡ್ ಹೆಚ್ಚಾದಂತೆ, ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಗೇಟ್ವೇ ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಪುನರಾವರ್ತನೆಯ ಹರಿವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲೈಂಟ್ ವಹಿವಾಟನ್ನು ಕಳುಹಿಸಿದರೆ, ನೀವು ಅದರ ಸಿಂಧುತ್ವವನ್ನು ಮಾತ್ರ ಪರಿಶೀಲಿಸಬೇಕು ಮತ್ತು ಅದನ್ನು ಮತ್ತಷ್ಟು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ನಾವು ಏಕ ಗೇಟ್ವೇ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಮಾನಾಂತರವಾಗಿ ಚಲಾಯಿಸಬಹುದಾದ ಬಹು ಘಟಕಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ: ಬಹು-ಥ್ರೆಡ್ ಮಾಹಿತಿ ಮತ್ತು ವಹಿವಾಟು ಪ್ರಕ್ರಿಯೆಗಳು RW ಲಾಕಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹಂಚಿಕೆಯ ಮೆಮೊರಿ ಪ್ರದೇಶದಲ್ಲಿ ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿ ಚಲಿಸುತ್ತವೆ. ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನಾವು ರವಾನೆ ಮತ್ತು ಪ್ರತಿಕೃತಿ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಪರಿಚಯಿಸಿದ್ದೇವೆ.
ಅಧಿಕ ಆವರ್ತನ ವ್ಯಾಪಾರದ ಪರಿಣಾಮ
ವಾಸ್ತುಶಿಲ್ಪದ ಮೇಲಿನ ಆವೃತ್ತಿಯು 2010 ರವರೆಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿತ್ತು. ಏತನ್ಮಧ್ಯೆ, ನಾವು ಇನ್ನು ಮುಂದೆ HP ಸೂಪರ್‌ಡೋಮ್ ಸರ್ವರ್‌ಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯಿಂದ ತೃಪ್ತರಾಗಿದ್ದೇವೆ. ಇದರ ಜೊತೆಗೆ, PA-RISC ಆರ್ಕಿಟೆಕ್ಚರ್ ವಾಸ್ತವಿಕವಾಗಿ ಸತ್ತಿದೆ; ಮಾರಾಟಗಾರರು ಯಾವುದೇ ಮಹತ್ವದ ನವೀಕರಣಗಳನ್ನು ನೀಡಲಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ನಾವು HP UX/PA RISC ನಿಂದ Linux/x86 ಗೆ ಚಲಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಪ್ರವೇಶ ಸರ್ವರ್‌ಗಳ ರೂಪಾಂತರದೊಂದಿಗೆ ಪರಿವರ್ತನೆಯು ಪ್ರಾರಂಭವಾಯಿತು.
ನಾವು ಮತ್ತೆ ವಾಸ್ತುವನ್ನು ಏಕೆ ಬದಲಾಯಿಸಬೇಕಾಗಿತ್ತು? ಹೆಚ್ಚಿನ ಆವರ್ತನದ ವ್ಯಾಪಾರವು ಸಿಸ್ಟಮ್ ಕೋರ್ನಲ್ಲಿನ ಲೋಡ್ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಗಣನೀಯವಾಗಿ ಬದಲಾಯಿಸಿದೆ ಎಂಬುದು ಸತ್ಯ.
ನಾವು ಗಮನಾರ್ಹ ಬೆಲೆ ಬದಲಾವಣೆಗೆ ಕಾರಣವಾದ ಸಣ್ಣ ವಹಿವಾಟನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ - ಯಾರಾದರೂ ಅರ್ಧ ಬಿಲಿಯನ್ ಡಾಲರ್‌ಗಳನ್ನು ಖರೀದಿಸಿದ್ದಾರೆ. ಒಂದೆರಡು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ನಂತರ, ಎಲ್ಲಾ ಮಾರುಕಟ್ಟೆ ಭಾಗವಹಿಸುವವರು ಇದನ್ನು ಗಮನಿಸುತ್ತಾರೆ ಮತ್ತು ತಿದ್ದುಪಡಿ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ವಿನಂತಿಗಳು ದೊಡ್ಡ ಸರದಿಯಲ್ಲಿ ಸಾಲಿನಲ್ಲಿರುತ್ತವೆ, ಅದನ್ನು ತೆರವುಗೊಳಿಸಲು ಸಿಸ್ಟಮ್ ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಈ 50 ms ಮಧ್ಯಂತರದಲ್ಲಿ, ಸರಾಸರಿ ವೇಗವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸುಮಾರು 16 ಸಾವಿರ ವಹಿವಾಟುಗಳು. ನಾವು ವಿಂಡೋವನ್ನು 20 ms ಗೆ ಕಡಿಮೆ ಮಾಡಿದರೆ, ನಾವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಸರಾಸರಿ 90 ಸಾವಿರ ವಹಿವಾಟುಗಳ ವೇಗವನ್ನು ಪಡೆಯುತ್ತೇವೆ, ಗರಿಷ್ಠ 200 ಸಾವಿರ ವಹಿವಾಟುಗಳು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಹಠಾತ್ ಸ್ಫೋಟಗಳೊಂದಿಗೆ ಲೋಡ್ ಸ್ಥಿರವಾಗಿರುವುದಿಲ್ಲ. ಮತ್ತು ವಿನಂತಿಗಳ ಸರದಿಯನ್ನು ಯಾವಾಗಲೂ ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬೇಕು.
ಆದರೆ ಸರತಿ ಸಾಲು ಏಕೆ? ಆದ್ದರಿಂದ, ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ, ಅನೇಕ ಬಳಕೆದಾರರು ಬೆಲೆ ಬದಲಾವಣೆಯನ್ನು ಗಮನಿಸಿದ್ದಾರೆ ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ವಹಿವಾಟುಗಳನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ. ಅವರು ಗೇಟ್‌ವೇಗೆ ಬರುತ್ತಾರೆ, ಅದು ಅವುಗಳನ್ನು ಧಾರಾವಾಹಿ ಮಾಡುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ಆದೇಶವನ್ನು ಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ಅವುಗಳನ್ನು ನೆಟ್ವರ್ಕ್ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ರೂಟರ್‌ಗಳು ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಷಫಲ್ ಮಾಡಿ ಮತ್ತು ಅವುಗಳನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತವೆ. ಯಾರ ಪ್ಯಾಕೇಜ್ ಮೊದಲು ಬಂದಿತು, ಆ ವಹಿವಾಟು "ಗೆದ್ದಿತು". ಪರಿಣಾಮವಾಗಿ, ವಿನಿಮಯ ಗ್ರಾಹಕರು ಅದೇ ವಹಿವಾಟನ್ನು ಹಲವಾರು ಗೇಟ್‌ವೇಗಳಿಂದ ಕಳುಹಿಸಿದರೆ, ಅದರ ಕ್ಷಿಪ್ರ ಪ್ರಕ್ರಿಯೆಯ ಸಾಧ್ಯತೆಗಳು ಹೆಚ್ಚಾಗುತ್ತವೆ ಎಂದು ಗಮನಿಸಲಾರಂಭಿಸಿದರು. ಶೀಘ್ರದಲ್ಲೇ, ವಿನಿಮಯ ರೋಬೋಟ್ಗಳು ವಿನಂತಿಗಳೊಂದಿಗೆ ಗೇಟ್‌ವೇಯನ್ನು ಸ್ಫೋಟಿಸಲು ಪ್ರಾರಂಭಿಸಿದವು ಮತ್ತು ವಹಿವಾಟುಗಳ ಹಿಮಪಾತವು ಹುಟ್ಟಿಕೊಂಡಿತು.
ವಿಕಾಸದ ಹೊಸ ಸುತ್ತು
ವ್ಯಾಪಕವಾದ ಪರೀಕ್ಷೆ ಮತ್ತು ಸಂಶೋಧನೆಯ ನಂತರ, ನಾವು ನೈಜ-ಸಮಯದ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ಕರ್ನಲ್‌ಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ. ಇದಕ್ಕಾಗಿ ನಾವು RedHat Enterprise MRG Linux ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ, ಇಲ್ಲಿ MRG ಎಂದರೆ ಸಂದೇಶ ಕಳುಹಿಸುವ ನೈಜ-ಸಮಯದ ಗ್ರಿಡ್. ನೈಜ-ಸಮಯದ ಪ್ಯಾಚ್‌ಗಳ ಪ್ರಯೋಜನವೆಂದರೆ ಅವು ಸಾಧ್ಯವಾದಷ್ಟು ವೇಗವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಪ್ಟಿಮೈಜ್ ಮಾಡುತ್ತವೆ: ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು FIFO ಕ್ಯೂನಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ, ಕೋರ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಹುದು, ಯಾವುದೇ ಎಜೆಕ್ಷನ್ಗಳಿಲ್ಲ, ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಕಟ್ಟುನಿಟ್ಟಾದ ಅನುಕ್ರಮದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ.
ಕೆಂಪು - ನಿಯಮಿತ ಕರ್ನಲ್‌ನಲ್ಲಿ ಕ್ಯೂನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು, ಹಸಿರು - ನೈಜ-ಸಮಯದ ಕರ್ನಲ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು.
ಆದರೆ ಸಾಮಾನ್ಯ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಡಿಮೆ ಸುಪ್ತತೆಯನ್ನು ಸಾಧಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ:
- x86 ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಪ್ರಮುಖ ಪೆರಿಫೆರಲ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಆಧಾರವಾಗಿರುವ SMI ಮೋಡ್ ಹೆಚ್ಚು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ. ಎಲ್ಲಾ ರೀತಿಯ ಹಾರ್ಡ್‌ವೇರ್ ಈವೆಂಟ್‌ಗಳ ಪ್ರಕ್ರಿಯೆ ಮತ್ತು ಘಟಕಗಳು ಮತ್ತು ಸಾಧನಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಪಾರದರ್ಶಕ SMI ಮೋಡ್‌ನಲ್ಲಿ ಫರ್ಮ್‌ವೇರ್ ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಫರ್ಮ್‌ವೇರ್ ಏನು ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್ ನೋಡುವುದಿಲ್ಲ. ನಿಯಮದಂತೆ, ಎಲ್ಲಾ ಪ್ರಮುಖ ಮಾರಾಟಗಾರರು SMI ಸಂಸ್ಕರಣೆಯ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅನುಮತಿಸುವ ಫರ್ಮ್‌ವೇರ್ ಸರ್ವರ್‌ಗಳಿಗೆ ವಿಶೇಷ ವಿಸ್ತರಣೆಗಳನ್ನು ನೀಡುತ್ತಾರೆ.
- ಪ್ರೊಸೆಸರ್ ಆವರ್ತನದ ಯಾವುದೇ ಡೈನಾಮಿಕ್ ನಿಯಂತ್ರಣ ಇರಬಾರದು, ಇದು ಹೆಚ್ಚುವರಿ ಅಲಭ್ಯತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
- ಫೈಲ್ ಸಿಸ್ಟಮ್ ಲಾಗ್ ಅನ್ನು ಫ್ಲಶ್ ಮಾಡಿದಾಗ, ಕರ್ನಲ್‌ನಲ್ಲಿ ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳು ಸಂಭವಿಸುತ್ತವೆ ಅದು ಅನಿರೀಕ್ಷಿತ ವಿಳಂಬವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
- ನೀವು CPU ಅಫಿನಿಟಿ, ಇಂಟರಪ್ಟ್ ಅಫಿನಿಟಿ, NUMA ನಂತಹ ವಿಷಯಗಳಿಗೆ ಗಮನ ಕೊಡಬೇಕು.
ನೈಜ-ಸಮಯದ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಲಿನಕ್ಸ್ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಕರ್ನಲ್ ಅನ್ನು ಹೊಂದಿಸುವ ವಿಷಯವು ಪ್ರತ್ಯೇಕ ಲೇಖನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ ಎಂದು ನಾನು ಹೇಳಲೇಬೇಕು. ನಾವು ಉತ್ತಮ ಫಲಿತಾಂಶವನ್ನು ಸಾಧಿಸುವ ಮೊದಲು ನಾವು ಪ್ರಯೋಗ ಮತ್ತು ಸಂಶೋಧನೆಗೆ ಸಾಕಷ್ಟು ಸಮಯವನ್ನು ಕಳೆದಿದ್ದೇವೆ.
PA-RISC ಸರ್ವರ್‌ಗಳಿಂದ x86 ಗೆ ಚಲಿಸುವಾಗ, ನಾವು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸಿಸ್ಟಮ್ ಕೋಡ್ ಅನ್ನು ಹೆಚ್ಚು ಬದಲಾಯಿಸಬೇಕಾಗಿಲ್ಲ, ನಾವು ಅದನ್ನು ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ ಮತ್ತು ಮರುಸಂರಚಿಸಿದ್ದೇವೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವು ಹಲವಾರು ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, PA RISC ಒಂದು ಬಿಗ್ ಎಂಡಿಯನ್ ಸಿಸ್ಟಮ್ ಮತ್ತು x86 ಒಂದು ಲಿಟಲ್ ಎಂಡಿಯನ್ ಸಿಸ್ಟಮ್ ಆಗಿರುವ ಪರಿಣಾಮವು ತ್ವರಿತವಾಗಿ ಹೊರಹೊಮ್ಮಿತು: ಉದಾಹರಣೆಗೆ, ಡೇಟಾವನ್ನು ತಪ್ಪಾಗಿ ಓದಲಾಗಿದೆ. ಪಿಎ ಆರ್‌ಐಎಸ್‌ಸಿ ಬಳಸುವ ತಂತ್ರದ ದೋಷ () ಮೆಮೊರಿ ಪ್ರವೇಶ, ಆದರೆ x86 ಓದುವ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಮರುಕ್ರಮಗೊಳಿಸಬಹುದು, ಆದ್ದರಿಂದ ಒಂದು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣವಾಗಿ ಮಾನ್ಯವಾಗಿರುವ ಕೋಡ್ ಇನ್ನೊಂದರಲ್ಲಿ ಮುರಿದುಹೋಯಿತು.
x86 ಗೆ ಬದಲಾಯಿಸಿದ ನಂತರ, ಕಾರ್ಯಕ್ಷಮತೆಯು ಸುಮಾರು ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚಾಗಿದೆ, ಸರಾಸರಿ ವಹಿವಾಟು ಪ್ರಕ್ರಿಯೆಯ ಸಮಯವು 60 μs ಗೆ ಕಡಿಮೆಯಾಗಿದೆ.
ಸಿಸ್ಟಮ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗೆ ಯಾವ ಪ್ರಮುಖ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಲಾಗಿದೆ ಎಂಬುದನ್ನು ಈಗ ಹತ್ತಿರದಿಂದ ನೋಡೋಣ.
ಬಿಸಿ ಮೀಸಲು ಮಹಾಕಾವ್ಯ
ಸರಕು ಸರ್ವರ್‌ಗಳಿಗೆ ಬದಲಾಯಿಸುವಾಗ, ಅವು ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವೆಂದು ನಮಗೆ ತಿಳಿದಿತ್ತು. ಆದ್ದರಿಂದ, ಹೊಸ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ರಚಿಸುವಾಗ, ನಾವು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ನೋಡ್ಗಳ ವೈಫಲ್ಯದ ಸಾಧ್ಯತೆಯನ್ನು ಊಹಿಸಿದ್ದೇವೆ. ಆದ್ದರಿಂದ, ಬ್ಯಾಕ್‌ಅಪ್ ಯಂತ್ರಗಳಿಗೆ ತ್ವರಿತವಾಗಿ ಬದಲಾಯಿಸಬಹುದಾದ ಬಿಸಿ ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಸಿಸ್ಟಮ್ ಅಗತ್ಯವಿದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಇತರ ಅವಶ್ಯಕತೆಗಳು ಇದ್ದವು:
- ಯಾವುದೇ ಸಂದರ್ಭಗಳಲ್ಲಿ ನೀವು ಸಂಸ್ಕರಿಸಿದ ವಹಿವಾಟುಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಾರದು.
- ವ್ಯವಸ್ಥೆಯು ನಮ್ಮ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಸಂಪೂರ್ಣವಾಗಿ ಪಾರದರ್ಶಕವಾಗಿರಬೇಕು.
- ಗ್ರಾಹಕರು ಕಡಿತಗೊಂಡ ಸಂಪರ್ಕಗಳನ್ನು ನೋಡಬಾರದು.
- ಮೀಸಲಾತಿಗಳು ಗಮನಾರ್ಹ ವಿಳಂಬವನ್ನು ಪರಿಚಯಿಸಬಾರದು ಏಕೆಂದರೆ ಇದು ವಿನಿಮಯಕ್ಕೆ ನಿರ್ಣಾಯಕ ಅಂಶವಾಗಿದೆ.
ಬಿಸಿ ಸ್ಟ್ಯಾಂಡ್‌ಬೈ ಸಿಸ್ಟಮ್ ಅನ್ನು ರಚಿಸುವಾಗ, ಅಂತಹ ಸನ್ನಿವೇಶಗಳನ್ನು ನಾವು ಡಬಲ್ ವೈಫಲ್ಯಗಳಾಗಿ ಪರಿಗಣಿಸಲಿಲ್ಲ (ಉದಾಹರಣೆಗೆ, ಒಂದು ಸರ್ವರ್‌ನಲ್ಲಿನ ನೆಟ್‌ವರ್ಕ್ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿತು ಮತ್ತು ಮುಖ್ಯ ಸರ್ವರ್ ಫ್ರೀಜ್); ಸಾಫ್ಟ್‌ವೇರ್‌ನಲ್ಲಿ ದೋಷಗಳ ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಗಣಿಸಲಿಲ್ಲ ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ ಗುರುತಿಸಲಾಗಿದೆ; ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್‌ನ ತಪ್ಪಾದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪರಿಗಣಿಸಲಿಲ್ಲ.
ಪರಿಣಾಮವಾಗಿ, ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಗೆ ಬಂದಿದ್ದೇವೆ:
- ಮುಖ್ಯ ಸರ್ವರ್ ನೇರವಾಗಿ ಗೇಟ್ವೇ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.
- ಮುಖ್ಯ ಸರ್ವರ್‌ನಲ್ಲಿ ಸ್ವೀಕರಿಸಿದ ಎಲ್ಲಾ ವಹಿವಾಟುಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಚಾನಲ್ ಮೂಲಕ ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ಗೆ ತಕ್ಷಣವೇ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ. ಯಾವುದೇ ಸಮಸ್ಯೆಗಳು ಉಂಟಾದರೆ ಆರ್ಬಿಟರ್ (ಗವರ್ನರ್) ಸ್ವಿಚಿಂಗ್ ಅನ್ನು ಸಂಯೋಜಿಸಿದರು.
- ಮುಖ್ಯ ಸರ್ವರ್ ಪ್ರತಿ ವಹಿವಾಟನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ನಿಂದ ದೃಢೀಕರಣಕ್ಕಾಗಿ ಕಾಯುತ್ತಿದೆ. ಸುಪ್ತತೆಯನ್ನು ಕನಿಷ್ಠವಾಗಿರಿಸಲು, ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ನಲ್ಲಿ ವಹಿವಾಟು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ನಾವು ಕಾಯುವುದನ್ನು ತಪ್ಪಿಸಿದ್ದೇವೆ. ನೆಟ್‌ವರ್ಕ್‌ನಾದ್ಯಂತ ಪ್ರಯಾಣಿಸಲು ವಹಿವಾಟು ತೆಗೆದುಕೊಳ್ಳುವ ಸಮಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಮಯಕ್ಕೆ ಹೋಲಿಸಬಹುದಾದ ಕಾರಣ, ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಸುಪ್ತತೆಯನ್ನು ಸೇರಿಸಲಾಗಿಲ್ಲ.
- ಹಿಂದಿನ ವಹಿವಾಟಿನ ಮುಖ್ಯ ಮತ್ತು ಬ್ಯಾಕಪ್ ಸರ್ವರ್‌ಗಳ ಪ್ರಕ್ರಿಯೆಯ ಸ್ಥಿತಿಯನ್ನು ಮಾತ್ರ ನಾವು ಪರಿಶೀಲಿಸಬಹುದು ಮತ್ತು ಪ್ರಸ್ತುತ ವಹಿವಾಟಿನ ಪ್ರಕ್ರಿಯೆಯ ಸ್ಥಿತಿ ತಿಳಿದಿಲ್ಲ. ನಾವು ಇನ್ನೂ ಏಕ-ಥ್ರೆಡ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಬಳಸುತ್ತಿರುವುದರಿಂದ, ಬ್ಯಾಕಪ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುವುದು ಸಂಪೂರ್ಣ ಪ್ರಕ್ರಿಯೆಯ ಹರಿವನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಸಮಂಜಸವಾದ ರಾಜಿ ಮಾಡಿಕೊಂಡಿದ್ದೇವೆ: ನಾವು ಹಿಂದಿನ ವಹಿವಾಟಿನ ಫಲಿತಾಂಶವನ್ನು ಪರಿಶೀಲಿಸಿದ್ದೇವೆ.
ಯೋಜನೆಯು ಈ ಕೆಳಗಿನಂತೆ ಕೆಲಸ ಮಾಡಿದೆ.
ಮುಖ್ಯ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ ಎಂದು ಹೇಳೋಣ, ಆದರೆ ಗೇಟ್‌ವೇಗಳು ಸಂವಹನವನ್ನು ಮುಂದುವರಿಸುತ್ತವೆ. ಬ್ಯಾಕ್‌ಅಪ್ ಸರ್ವರ್‌ನಲ್ಲಿ ಕಾಲಾವಧಿಯು ಸಂಭವಿಸುತ್ತದೆ, ಅದು ಗವರ್ನರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ, ಅವರು ಮುಖ್ಯ ಸರ್ವರ್‌ನ ಪಾತ್ರವನ್ನು ನಿಯೋಜಿಸುತ್ತಾರೆ ಮತ್ತು ಎಲ್ಲಾ ಗೇಟ್‌ವೇಗಳು ಹೊಸ ಮುಖ್ಯ ಸರ್ವರ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತವೆ.
ಮುಖ್ಯ ಸರ್ವರ್ ಆನ್‌ಲೈನ್‌ಗೆ ಹಿಂತಿರುಗಿದರೆ, ಇದು ಆಂತರಿಕ ಸಮಯ ಮೀರುವಿಕೆಯನ್ನು ಪ್ರಚೋದಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ನಿರ್ದಿಷ್ಟ ಸಮಯದವರೆಗೆ ಗೇಟ್‌ವೇನಿಂದ ಸರ್ವರ್‌ಗೆ ಯಾವುದೇ ಕರೆಗಳಿಲ್ಲ. ನಂತರ ಅವರು ರಾಜ್ಯಪಾಲರ ಕಡೆಗೆ ತಿರುಗುತ್ತಾರೆ ಮತ್ತು ಅವರು ಅವರನ್ನು ಯೋಜನೆಯಿಂದ ಹೊರಗಿಡುತ್ತಾರೆ. ಪರಿಣಾಮವಾಗಿ, ವಿನಿಮಯವು ವ್ಯಾಪಾರದ ಅವಧಿಯ ಅಂತ್ಯದವರೆಗೆ ಒಂದು ಸರ್ವರ್ನೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಸರ್ವರ್ ವೈಫಲ್ಯದ ಸಂಭವನೀಯತೆಯು ತುಂಬಾ ಕಡಿಮೆಯಿರುವುದರಿಂದ, ಈ ಯೋಜನೆಯನ್ನು ಸಾಕಷ್ಟು ಸ್ವೀಕಾರಾರ್ಹವೆಂದು ಪರಿಗಣಿಸಲಾಗಿದೆ; ಇದು ಸಂಕೀರ್ಣ ತರ್ಕವನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಸುಲಭವಾಗಿದೆ.
ಮುಂದುವರೆಯಲು.
ಮೂಲ: www.habr.com