VKontakte ನಲ್ಲಿ ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಕೆಲಸದ ಮೇಲೆ 🥇FAQ

VKontakte ರಚನೆಯ ಇತಿಹಾಸವು ವಿಕಿಪೀಡಿಯಾದಲ್ಲಿದೆ; ಇದನ್ನು ಪಾವೆಲ್ ಸ್ವತಃ ಹೇಳಿದ್ದಾನೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಅವಳನ್ನು ಈಗಾಗಲೇ ತಿಳಿದಿದ್ದಾರೆ ಎಂದು ತೋರುತ್ತದೆ. ಹೈಲೋಡ್++ ಪಾವೆಲ್‌ನಲ್ಲಿ ಸೈಟ್‌ನ ಆಂತರಿಕ, ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ರಚನೆಯ ಬಗ್ಗೆ 2010 ರಲ್ಲಿ ನನಗೆ ಹೇಳಿದರು. ಅಂದಿನಿಂದ ಅನೇಕ ಸರ್ವರ್‌ಗಳು ಸೋರಿಕೆಯಾಗಿವೆ, ಆದ್ದರಿಂದ ನಾವು ಮಾಹಿತಿಯನ್ನು ನವೀಕರಿಸುತ್ತೇವೆ: ನಾವು ಅದನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ, ಒಳಭಾಗಗಳನ್ನು ಹೊರತೆಗೆಯುತ್ತೇವೆ, ಅದನ್ನು ತೂಕ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ತಾಂತ್ರಿಕ ದೃಷ್ಟಿಕೋನದಿಂದ ವಿಕೆ ಸಾಧನವನ್ನು ನೋಡುತ್ತೇವೆ.

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

ನಾಲ್ಕು ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ನಾನು ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ರೀತಿಯ ಕಾರ್ಯಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತಿದ್ದೇನೆ.

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

ಈ ಸಮಯದಲ್ಲಿ, ನಾನು ಸೈಟ್‌ನ ಅನೇಕ ಘಟಕಗಳಲ್ಲಿ ಕೈ ಹೊಂದಿದ್ದೆ. ನಾನು ಈ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇನೆ.

ಸಾಮಾನ್ಯ ವಾಸ್ತುಶಿಲ್ಪ

ಎಲ್ಲವೂ ಎಂದಿನಂತೆ, ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸರ್ವರ್ ಅಥವಾ ಸರ್ವರ್‌ಗಳ ಗುಂಪಿನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.

ಮುಂಭಾಗದ ಸರ್ವರ್

ಮುಂಭಾಗದ ಸರ್ವರ್ HTTPS, RTMP ಮತ್ತು WSS ಮೂಲಕ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ.

, HTTPS - ಇವುಗಳು ಸೈಟ್‌ನ ಮುಖ್ಯ ಮತ್ತು ಮೊಬೈಲ್ ವೆಬ್ ಆವೃತ್ತಿಗಳಿಗೆ ವಿನಂತಿಗಳಾಗಿವೆ: vk.com ಮತ್ತು m.vk.com, ಮತ್ತು ನಮ್ಮ API ಯ ಇತರ ಅಧಿಕೃತ ಮತ್ತು ಅನಧಿಕೃತ ಕ್ಲೈಂಟ್‌ಗಳು: ಮೊಬೈಲ್ ಕ್ಲೈಂಟ್‌ಗಳು, ಸಂದೇಶವಾಹಕರು. ನಮಗೆ ಸ್ವಾಗತವಿದೆ ಆರ್‌ಟಿಎಂಪಿಪ್ರತ್ಯೇಕ ಮುಂಭಾಗದ ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ನೇರ ಪ್ರಸಾರಕ್ಕಾಗಿ ಸಂಚಾರ ಮತ್ತು WSS- ಸ್ಟ್ರೀಮಿಂಗ್ API ಗಾಗಿ ಸಂಪರ್ಕಗಳು.

ಸರ್ವರ್‌ಗಳಲ್ಲಿ HTTPS ಮತ್ತು WSS ಗಾಗಿ ಇದು ಯೋಗ್ಯವಾಗಿದೆ nginx. RTMP ಪ್ರಸಾರಗಳಿಗಾಗಿ, ನಾವು ಇತ್ತೀಚೆಗೆ ನಮ್ಮ ಸ್ವಂತ ಪರಿಹಾರಕ್ಕೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ ಕಿವ್ಆದರೆ ಇದು ವರದಿಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿದೆ. ದೋಷ ಸಹಿಷ್ಣುತೆಗಾಗಿ, ಈ ಸರ್ವರ್‌ಗಳು ಸಾಮಾನ್ಯ IP ವಿಳಾಸಗಳನ್ನು ಜಾಹೀರಾತು ಮಾಡುತ್ತವೆ ಮತ್ತು ಗುಂಪುಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಆದ್ದರಿಂದ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಸಮಸ್ಯೆಯಿದ್ದರೆ, ಬಳಕೆದಾರರ ವಿನಂತಿಗಳು ಕಳೆದುಹೋಗುವುದಿಲ್ಲ. HTTPS ಮತ್ತು WSS ಗಾಗಿ, ಇದೇ ಸರ್ವರ್‌ಗಳು ತಮ್ಮ ಮೇಲೆ CPU ಲೋಡ್‌ನ ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಸಲುವಾಗಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತವೆ.

ನಾವು WSS ಮತ್ತು RTMP ಯ ಬಗ್ಗೆ ಹೆಚ್ಚಿನದನ್ನು ಮಾತನಾಡುವುದಿಲ್ಲ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ವೆಬ್ ಪ್ರಾಜೆಕ್ಟ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಪ್ರಮಾಣಿತ HTTPS ವಿನಂತಿಗಳ ಬಗ್ಗೆ ಮಾತ್ರ.

ಬ್ಯಾಕೆಂಡ್

ಮುಂಭಾಗದ ಹಿಂದೆ ಸಾಮಾನ್ಯವಾಗಿ ಬ್ಯಾಕೆಂಡ್ ಸರ್ವರ್‌ಗಳಿವೆ. ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಮುಂಭಾಗದ ಸರ್ವರ್ ಸ್ವೀಕರಿಸುವ ವಿನಂತಿಗಳನ್ನು ಅವರು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತಾರೆ.

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

ವಿತರಣೆಯನ್ನು ಲೋಡ್ ಮಾಡಿ

ನಮ್ಮ ಎಲ್ಲಾ ಬ್ಯಾಕೆಂಡ್‌ಗಳು ಯಾವುದೇ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ಯಂತ್ರಗಳ ಬೃಹತ್ ಪೂಲ್ ಅಲ್ಲ. ನಾವು ಅವರನ್ನು ಪ್ರತ್ಯೇಕ ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ: ಸಾಮಾನ್ಯ, ಮೊಬೈಲ್, ಎಪಿಐ, ವಿಡಿಯೋ, ಸ್ಟೇಜಿಂಗ್... ಪ್ರತ್ಯೇಕ ಗುಂಪಿನ ಯಂತ್ರಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಯು ಇತರರ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ವೀಡಿಯೊದಲ್ಲಿ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಸಂಗೀತವನ್ನು ಕೇಳುವ ಬಳಕೆದಾರರಿಗೆ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರುವುದಿಲ್ಲ. ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಯಾವ ಬ್ಯಾಕೆಂಡ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಪ್ರಕಾರ ಮುಂಭಾಗದಲ್ಲಿ nginx ನಿರ್ಧರಿಸುತ್ತದೆ.

ಮೆಟ್ರಿಕ್ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಮರುಸಮತೋಲನ

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

ನಮ್ಮಲ್ಲಿ ಇಂತಹ ಸಾವಿರಾರು ಸರ್ವರ್‌ಗಳಿವೆ. ಪ್ರತಿಯೊಂದು ಭೌತಿಕ ಸರ್ವರ್ ಎಲ್ಲಾ ಕೋರ್ಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಲು kPHP ಗುಂಪನ್ನು ನಡೆಸುತ್ತದೆ (ಏಕೆಂದರೆ kPHP ಒಂದೇ ಥ್ರೆಡ್ ಆಗಿರುತ್ತದೆ).

ವಿಷಯ ಸರ್ವರ್

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

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

ಪು/ಪಿಪಿ

ನೀವು VK ನಲ್ಲಿ ನೆಟ್ವರ್ಕ್ ಟ್ಯಾಬ್ ಅನ್ನು ತೆರೆದರೆ, ನೀವು pu/pp ಅನ್ನು ನೋಡಿದ್ದೀರಿ.

ಪು/ಪಿಪಿ ಎಂದರೇನು? ನಾವು ಒಂದು ಸರ್ವರ್ ಅನ್ನು ಇನ್ನೊಂದರ ನಂತರ ಮುಚ್ಚಿದರೆ, ಮುಚ್ಚಿದ ಸರ್ವರ್‌ಗೆ ಫೈಲ್ ಅನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಎರಡು ಆಯ್ಕೆಗಳಿವೆ: ನೇರವಾಗಿ ಮೂಲಕ http://cs100500.userapi.com/path ಅಥವಾ ಮಧ್ಯಂತರ ಸರ್ವರ್ ಮೂಲಕ - http://pu.vk.com/c100500/path.

ಪು ಫೋಟೋ ಅಪ್‌ಲೋಡ್‌ಗೆ ಐತಿಹಾಸಿಕ ಹೆಸರು, ಮತ್ತು ಪಿಪಿ ಫೋಟೋ ಪ್ರಾಕ್ಸಿ ಆಗಿದೆ. ಅಂದರೆ, ಒಂದು ಸರ್ವರ್ ಫೋಟೋಗಳನ್ನು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಇನ್ನೊಂದು ಅಪ್‌ಲೋಡ್ ಮಾಡಲು. ಈಗ ಫೋಟೋಗಳನ್ನು ಮಾತ್ರ ಲೋಡ್ ಮಾಡಲಾಗಿಲ್ಲ, ಆದರೆ ಹೆಸರನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ.

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

ಯಂತ್ರಗಳು ನಮ್ಮ ಇತರ ಯಂತ್ರಗಳಿಂದ ಮುಚ್ಚಲ್ಪಟ್ಟಿರುವುದರಿಂದ, ನಾವು ಅವರಿಗೆ "ಬಿಳಿ" ಬಾಹ್ಯ ಐಪಿಗಳನ್ನು ನೀಡದಿರಲು ಶಕ್ತರಾಗಿದ್ದೇವೆ ಮತ್ತು "ಬೂದು" ನೀಡಿ. ಈ ರೀತಿಯಾಗಿ ನಾವು ಐಪಿ ಪೂಲ್‌ನಲ್ಲಿ ಉಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಹೊರಗಿನ ಪ್ರವೇಶದಿಂದ ಯಂತ್ರಗಳನ್ನು ರಕ್ಷಿಸಲು ಖಾತರಿಪಡಿಸುತ್ತೇವೆ - ಅದರಲ್ಲಿ ಪ್ರವೇಶಿಸಲು ಯಾವುದೇ ಐಪಿ ಇಲ್ಲ.

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

ವಿವಾದಾತ್ಮಕ ಅಂಶವೆಂದರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಕಡಿಮೆ ಸಂಪರ್ಕಗಳನ್ನು ಇರಿಸುತ್ತದೆ. ಹಲವಾರು ಯಂತ್ರಗಳಿಗೆ ಒಂದೇ IP ಇದ್ದರೆ - ಅದೇ ಹೋಸ್ಟ್‌ನೊಂದಿಗೆ: pu.vk.com ಅಥವಾ pp.vk.com, ಕ್ಲೈಂಟ್ ಬ್ರೌಸರ್ ಒಂದು ಹೋಸ್ಟ್‌ಗೆ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಮಿತಿಯನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಆದರೆ ಸರ್ವತ್ರ HTTP/2 ಸಮಯದಲ್ಲಿ, ಇದು ಇನ್ನು ಮುಂದೆ ಅಷ್ಟು ಪ್ರಸ್ತುತವಲ್ಲ ಎಂದು ನಾನು ನಂಬುತ್ತೇನೆ.

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

ಬಹಳ ಹಿಂದೆಯೇ ನಾವು ಪ್ರಾಕ್ಸಿಯ ಸುಧಾರಿತ ಆವೃತ್ತಿಯನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ. ಅವರು ಸಾಮಾನ್ಯರಿಂದ ಹೇಗೆ ಭಿನ್ನರಾಗಿದ್ದಾರೆ ಮತ್ತು ಇದು ಏಕೆ ಅಗತ್ಯ ಎಂದು ಈಗ ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

ಸನ್

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

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

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

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

ತೂಕ ಬೆಂಬಲ. ಈಗ ನಾವು ಅಗತ್ಯವಿರುವಂತೆ ವಿಭಿನ್ನ ಶಕ್ತಿಯ ಯಂತ್ರಗಳನ್ನು ಸ್ಥಾಪಿಸಲು ಶಕ್ತರಾಗಿದ್ದೇವೆ ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ, ಕೆಲಸ ಮಾಡುವ "ಸೂರ್ಯಗಳ" ತೂಕವನ್ನು ಅವುಗಳ ಮೇಲಿನ ಹೊರೆ ಕಡಿಮೆ ಮಾಡಲು ಬದಲಾಯಿಸಬಹುದು, ಇದರಿಂದ ಅವರು "ವಿಶ್ರಾಂತಿ" ಮತ್ತು ಮತ್ತೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ವಿಷಯ ಐಡಿ ಮೂಲಕ ಹಂಚಿಕೆ. ಹಂಚುವಿಕೆಯ ಬಗ್ಗೆ ಒಂದು ತಮಾಷೆಯ ವಿಷಯ: ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ವಿಷಯವನ್ನು ಚೂರುಚೂರು ಮಾಡುತ್ತೇವೆ ಇದರಿಂದ ವಿಭಿನ್ನ ಬಳಕೆದಾರರು ಒಂದೇ ಫೈಲ್‌ಗೆ ಒಂದೇ “ಸೂರ್ಯ” ಮೂಲಕ ಹೋಗುತ್ತಾರೆ ಇದರಿಂದ ಅವರು ಸಾಮಾನ್ಯ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ.

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

ಒಂದೇ ಫೈಲ್‌ಗಾಗಿ ವಿನಂತಿಗಳ ಸ್ಫೋಟಗಳನ್ನು ತಡೆದುಕೊಳ್ಳುವ ಸಲುವಾಗಿ, ನಿರ್ದಿಷ್ಟ ಪ್ರಕಾರದ ವಿಷಯಕ್ಕಾಗಿ ನಾವು ಪ್ರದೇಶದಲ್ಲಿ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ "ಸೂರ್ಯ" ಗಳಲ್ಲಿ ಫೈಲ್‌ಗಳನ್ನು ಹರಡುವ ಮೂರ್ಖ ಯೋಜನೆಯನ್ನು ಆನ್ ಮಾಡುತ್ತೇವೆ.

ಒಳಗಿನಿಂದ ಸೂರ್ಯ

nginx ನಲ್ಲಿ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ, RAM ನಲ್ಲಿ ಅಥವಾ ವೇಗದ Optane/NVMe ಡಿಸ್ಕ್‌ಗಳಲ್ಲಿ ಸಂಗ್ರಹ. ಉದಾಹರಣೆ: http://sun4-2.userapi.com/c100500/path - "ಸೂರ್ಯ" ಗೆ ಲಿಂಕ್, ಇದು ನಾಲ್ಕನೇ ಪ್ರದೇಶದಲ್ಲಿ, ಎರಡನೇ ಸರ್ವರ್ ಗುಂಪಿನಲ್ಲಿದೆ. ಇದು ಪಾಥ್ ಫೈಲ್ ಅನ್ನು ಮುಚ್ಚುತ್ತದೆ, ಅದು ಭೌತಿಕವಾಗಿ ಸರ್ವರ್ 100500 ನಲ್ಲಿದೆ.

ಕವರ್

ನಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಸ್ಕೀಮ್‌ಗೆ ನಾವು ಇನ್ನೊಂದು ನೋಡ್ ಅನ್ನು ಸೇರಿಸುತ್ತೇವೆ - ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಪರಿಸರ.

ಕೆಳಗೆ ಲೇಔಟ್ ರೇಖಾಚಿತ್ರವಾಗಿದೆ ಪ್ರಾದೇಶಿಕ ಸಂಗ್ರಹಗಳು, ಅವುಗಳಲ್ಲಿ ಸುಮಾರು 20 ಇವೆ. ಇವುಗಳು ಸಂಗ್ರಹಗಳು ಮತ್ತು "ಸೂರ್ಯಗಳು" ಇರುವ ಸ್ಥಳಗಳಾಗಿವೆ, ಅವುಗಳು ತಮ್ಮ ಮೂಲಕ ದಟ್ಟಣೆಯನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು.

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

ಬಳಕೆದಾರರ ಪ್ರದೇಶವನ್ನು ನಿರ್ಧರಿಸಲು, ನಾವು ಪ್ರದೇಶಗಳಲ್ಲಿ ಘೋಷಿಸಲಾದ BGP ನೆಟ್‌ವರ್ಕ್ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ನಾವು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಫಾಲ್‌ಬ್ಯಾಕ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಮೂಲಕ IP ಅನ್ನು ಕಂಡುಹಿಡಿಯಲಾಗದಿದ್ದರೆ ನಾವು ಜಿಯೋಪ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸಹ ಪಾರ್ಸ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಬಳಕೆದಾರರ IP ಮೂಲಕ ನಾವು ಪ್ರದೇಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ಕೋಡ್‌ನಲ್ಲಿ, ನಾವು ಬಳಕೆದಾರರ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಪ್ರದೇಶಗಳನ್ನು ನೋಡಬಹುದು - ಅವರು ಭೌಗೋಳಿಕವಾಗಿ ಹತ್ತಿರವಿರುವ ಬಿಂದುಗಳು.

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ?

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

ಅದೇ ಸಮಯದಲ್ಲಿ, ದೆವ್ವಗಳು - ಪ್ರದೇಶಗಳಲ್ಲಿ ಸೇವೆಗಳು - ಕಾಲಕಾಲಕ್ಕೆ API ಗೆ ಬಂದು ಹೀಗೆ ಹೇಳುತ್ತವೆ: “ನಾನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಸಂಗ್ರಹ, ನನ್ನ ಪ್ರದೇಶದಲ್ಲಿ ಇನ್ನೂ ಇಲ್ಲದಿರುವ ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಫೈಲ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನನಗೆ ನೀಡಿ. ” API ರೇಟಿಂಗ್ ಮೂಲಕ ವಿಂಗಡಿಸಲಾದ ಫೈಲ್‌ಗಳ ಗುಂಪನ್ನು ನೀಡುತ್ತದೆ, ಡೀಮನ್ ಅವುಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಅವುಗಳನ್ನು ಪ್ರದೇಶಗಳಿಗೆ ಕೊಂಡೊಯ್ಯುತ್ತದೆ ಮತ್ತು ಅಲ್ಲಿಂದ ಫೈಲ್‌ಗಳನ್ನು ತಲುಪಿಸುತ್ತದೆ. ಇದು ಸಂಗ್ರಹಗಳಿಂದ pu/pp ಮತ್ತು Sun ನಡುವಿನ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವಾಗಿದೆ: ಈ ಫೈಲ್ ಕ್ಯಾಶ್‌ನಲ್ಲಿ ಇಲ್ಲದಿದ್ದರೂ ಸಹ ಅವರು ಫೈಲ್ ಅನ್ನು ತಕ್ಷಣವೇ ತಮ್ಮ ಮೂಲಕ ನೀಡುತ್ತಾರೆ ಮತ್ತು ಸಂಗ್ರಹವು ಮೊದಲು ಫೈಲ್ ಅನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಮರಳಿ ನೀಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಪಡೆಯುತ್ತೇವೆ ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರವಾಗಿರುವ ವಿಷಯ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಲೋಡ್ ಅನ್ನು ಹರಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಮಾಸ್ಕೋ ಸಂಗ್ರಹದಿಂದ ಮಾತ್ರ ನಾವು ಗರಿಷ್ಠ ಸಮಯದಲ್ಲಿ 1 Tbit/s ಗಿಂತ ಹೆಚ್ಚು ವಿತರಿಸುತ್ತೇವೆ.

ಆದರೆ ಸಮಸ್ಯೆಗಳಿವೆ - ಸಂಗ್ರಹ ಸರ್ವರ್‌ಗಳು ರಬ್ಬರ್ ಅಲ್ಲ. ಸೂಪರ್ ಜನಪ್ರಿಯ ವಿಷಯಕ್ಕಾಗಿ, ಕೆಲವೊಮ್ಮೆ ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ಗಾಗಿ ಸಾಕಷ್ಟು ನೆಟ್‌ವರ್ಕ್ ಇರುವುದಿಲ್ಲ. ನಮ್ಮ ಸಂಗ್ರಹ ಸರ್ವರ್‌ಗಳು 40-50 Gbit/s, ಆದರೆ ಅಂತಹ ಚಾನಲ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಮುಚ್ಚುವ ವಿಷಯವಿದೆ. ನಾವು ಪ್ರದೇಶದಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಜನಪ್ರಿಯ ಫೈಲ್‌ಗಳ ಸಂಗ್ರಹಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವತ್ತ ಸಾಗುತ್ತಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು ವರ್ಷಾಂತ್ಯದೊಳಗೆ ಜಾರಿಗೆ ತರುತ್ತೇವೆ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

ನಾವು ಸಾಮಾನ್ಯ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನೋಡಿದ್ದೇವೆ.

ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಮುಂಭಾಗದ ಸರ್ವರ್‌ಗಳು.
ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಬ್ಯಾಕೆಂಡ್‌ಗಳು.
ಎರಡು ರೀತಿಯ ಪ್ರಾಕ್ಸಿಗಳಿಂದ ಮುಚ್ಚಿದ ಸಂಗ್ರಹಣೆಗಳು.
ಪ್ರಾದೇಶಿಕ ಸಂಗ್ರಹಗಳು.

ಈ ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಏನು ಕಾಣೆಯಾಗಿದೆ? ಸಹಜವಾಗಿ, ನಾವು ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸುವ ಡೇಟಾಬೇಸ್ಗಳು.

ಡೇಟಾಬೇಸ್‌ಗಳು ಅಥವಾ ಎಂಜಿನ್‌ಗಳು

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

ಇದು ಅಗತ್ಯ ಕ್ರಮವಾಗಿದೆ. ಇದು ಸಂಭವಿಸಿತು ಏಕೆಂದರೆ 2008-2009 ರಲ್ಲಿ, ವಿಕೆ ಜನಪ್ರಿಯತೆಯ ಸ್ಫೋಟಕ ಬೆಳವಣಿಗೆಯನ್ನು ಹೊಂದಿದ್ದಾಗ, ಯೋಜನೆಯು ಸಂಪೂರ್ಣವಾಗಿ MySQL ಮತ್ತು Memcache ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿತು ಮತ್ತು ಸಮಸ್ಯೆಗಳಿವೆ. MySQL ಫೈಲ್‌ಗಳನ್ನು ಕ್ರ್ಯಾಶ್ ಮಾಡಲು ಮತ್ತು ಭ್ರಷ್ಟಗೊಳಿಸಲು ಇಷ್ಟಪಟ್ಟಿತು, ಅದರ ನಂತರ ಅದು ಚೇತರಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಮತ್ತು ಮೆಮ್‌ಕಾಚೆ ಕಾರ್ಯಕ್ಷಮತೆಯಲ್ಲಿ ಕ್ರಮೇಣ ಕ್ಷೀಣಿಸಿತು ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಬೇಕಾಯಿತು.

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

ಪರಿಹಾರ ಯಶಸ್ವಿಯಾಯಿತು. ಇದನ್ನು ಮಾಡಲು ಅವಕಾಶವಿತ್ತು, ಜೊತೆಗೆ ವಿಪರೀತ ಅವಶ್ಯಕತೆಯಿದೆ, ಏಕೆಂದರೆ ಆ ಸಮಯದಲ್ಲಿ ಸ್ಕೇಲಿಂಗ್ನ ಇತರ ವಿಧಾನಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಡೇಟಾಬೇಸ್‌ಗಳ ಗುಂಪೇ ಇರಲಿಲ್ಲ, NoSQL ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, MySQL, Memcache, PostrgreSQL ಮಾತ್ರ ಇದ್ದವು - ಮತ್ತು ಅಷ್ಟೆ.

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

ಎಂಜಿನ್ಗಳ ವಿಧಗಳು

ತಂಡವು ಕೆಲವು ಎಂಜಿನ್ಗಳನ್ನು ಬರೆದಿದೆ. ಅವುಗಳಲ್ಲಿ ಕೆಲವು ಇಲ್ಲಿವೆ: ಸ್ನೇಹಿತ, ಸುಳಿವು, ಚಿತ್ರ, ipdb, ಅಕ್ಷರಗಳು, ಪಟ್ಟಿಗಳು, ದಾಖಲೆಗಳು, memcached, meowdb, ಸುದ್ದಿ, ನಾಸ್ಟ್ರಾಡಾಮಸ್, ಫೋಟೋ, ಪ್ಲೇಪಟ್ಟಿಗಳು, pmemcached, ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್, ಹುಡುಕಾಟ, ಸಂಗ್ರಹಣೆ, ಇಷ್ಟಗಳು, ಕಾರ್ಯಗಳು, ...

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

ನಮಗೆ ಪ್ರತ್ಯೇಕ ಎಂಜಿನ್ ಇದೆ ಮೆಮ್ಕಾಚೆಡ್, ಇದು ಸಾಮಾನ್ಯ ಒಂದನ್ನು ಹೋಲುತ್ತದೆ, ಆದರೆ ಗುಡಿಗಳ ಗುಂಪಿನೊಂದಿಗೆ, ಮತ್ತು ಇದು ನಿಧಾನವಾಗುವುದಿಲ್ಲ. ಕ್ಲಿಕ್‌ಹೌಸ್ ಅಲ್ಲ, ಆದರೆ ಇದು ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರತ್ಯೇಕವಾಗಿ ಲಭ್ಯವಿದೆ pmmcached - ಇದು ನಿರಂತರ memcached, ಇದು ಡಿಸ್ಕ್ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಬಹುದು, ಮೇಲಾಗಿ, RAM ಗೆ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಮರುಪ್ರಾರಂಭಿಸುವಾಗ ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ವೈಯಕ್ತಿಕ ಕಾರ್ಯಗಳಿಗಾಗಿ ವಿವಿಧ ಎಂಜಿನ್‌ಗಳಿವೆ: ಸರತಿ ಸಾಲುಗಳು, ಪಟ್ಟಿಗಳು, ಸೆಟ್‌ಗಳು - ನಮ್ಮ ಯೋಜನೆಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲವೂ.

ಸಮೂಹಗಳು

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

ಕೋಡ್ ಭೌತಿಕ ಸ್ಥಳ, ಗಾತ್ರ ಅಥವಾ ಸರ್ವರ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ತಿಳಿದುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲ. ನಿರ್ದಿಷ್ಟ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅವನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೋಗುತ್ತಾನೆ.

ಇದು ಕೆಲಸ ಮಾಡಲು, ಕೋಡ್ ಮತ್ತು ಎಂಜಿನ್‌ಗಳ ನಡುವೆ ಇರುವ ಇನ್ನೊಂದು ಘಟಕವನ್ನು ನೀವು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ - ಪ್ರಾಕ್ಸಿ.

RPC ಪ್ರಾಕ್ಸಿ

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

ಪ್ರೋಗ್ರಾಮರ್‌ಗಳು ಎಷ್ಟು, ಎಲ್ಲಿ ಮತ್ತು ಏನು ವೆಚ್ಚವಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ - ಅವರು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೋಗುತ್ತಾರೆ. ಇದು ನಮಗೆ ಬಹಳಷ್ಟು ಅನುಮತಿಸುತ್ತದೆ. ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುವಾಗ, ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಯನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ, ಎಲ್ಲಿಗೆ ತಿಳಿಯುತ್ತದೆ - ಇದು ಸ್ವತಃ ನಿರ್ಧರಿಸುತ್ತದೆ.

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

ನಿರ್ದಿಷ್ಟ ಅನುಷ್ಠಾನಗಳು

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

MySQL ಗಾಗಿ, ನಾವು ಇನ್ನೂ ಇಲ್ಲಿ ಮತ್ತು ಅಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ, ನಾವು db-proxy ಅನ್ನು ಬಳಸುತ್ತೇವೆ ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ - ಕಿಟನ್ಹೌಸ್.

ಇದು ಸಾಮಾನ್ಯವಾಗಿ ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಒಂದು ನಿರ್ದಿಷ್ಟ ಸರ್ವರ್ ಇದೆ, ಇದು kPHP, Go, Python ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ - ಸಾಮಾನ್ಯವಾಗಿ, ನಮ್ಮ RPC ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಳಸಬಹುದಾದ ಯಾವುದೇ ಕೋಡ್. ಕೋಡ್ ಸ್ಥಳೀಯವಾಗಿ RPC ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಚಲಿಸುತ್ತದೆ - ಕೋಡ್ ಇರುವ ಪ್ರತಿಯೊಂದು ಸರ್ವರ್ ತನ್ನದೇ ಆದ ಸ್ಥಳೀಯ ಪ್ರಾಕ್ಸಿಯನ್ನು ನಡೆಸುತ್ತದೆ. ವಿನಂತಿಯ ಮೇರೆಗೆ, ಪ್ರಾಕ್ಸಿ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ.

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

ಎಲ್ಲಾ ಇಂಜಿನ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಟಿಎಲ್-ಸ್ಕೀಮ್‌ನ ಉದಾಹರಣೆ.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

ಇದು ಬೈನರಿ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ, ಇದು ಹತ್ತಿರದ ಅನಲಾಗ್ ಆಗಿದೆ ಪ್ರೋಟೋಬಫ್. ಸ್ಕೀಮಾವು ಐಚ್ಛಿಕ ಕ್ಷೇತ್ರಗಳು, ಸಂಕೀರ್ಣ ಪ್ರಕಾರಗಳು - ಅಂತರ್ನಿರ್ಮಿತ ಸ್ಕೇಲರ್‌ಗಳ ವಿಸ್ತರಣೆಗಳು ಮತ್ತು ಪ್ರಶ್ನೆಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಈ ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರ ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

TCP/UDP ಮೇಲೆ TL ಮೇಲೆ RPC... UDP?

TL ಸ್ಕೀಮ್‌ನ ಮೇಲಿರುವ ಎಂಜಿನ್ ವಿನಂತಿಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು RPC ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದೆಲ್ಲವೂ TCP/UDP ಸಂಪರ್ಕದ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಟಿಸಿಪಿ ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ, ಆದರೆ ನಮಗೆ ಆಗಾಗ್ಗೆ ಯುಡಿಪಿ ಏಕೆ ಬೇಕು?

UDP ಸಹಾಯ ಮಾಡುತ್ತದೆ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂಪರ್ಕಗಳ ಸಮಸ್ಯೆಯನ್ನು ತಪ್ಪಿಸಿ. ಪ್ರತಿ ಸರ್ವರ್ RPC ಪ್ರಾಕ್ಸಿಯನ್ನು ಹೊಂದಿದ್ದರೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಅದು ಯಾವುದೇ ಎಂಜಿನ್‌ಗೆ ಹೋಗಬಹುದು, ನಂತರ ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಹತ್ತು ಸಾವಿರ TCP ಸಂಪರ್ಕಗಳಿವೆ. ಹೊರೆ ಇದೆ, ಆದರೆ ಅದು ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. UDP ಯ ಸಂದರ್ಭದಲ್ಲಿ ಈ ಸಮಸ್ಯೆಯು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.

ಯಾವುದೇ ಅನಗತ್ಯ TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ಇಲ್ಲ. ಇದು ವಿಶಿಷ್ಟವಾದ ಸಮಸ್ಯೆಯಾಗಿದೆ: ಹೊಸ ಎಂಜಿನ್ ಅಥವಾ ಹೊಸ ಸರ್ವರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಅನೇಕ TCP ಸಂಪರ್ಕಗಳನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾಗುತ್ತದೆ. ಸಣ್ಣ ಹಗುರವಾದ ವಿನಂತಿಗಳಿಗಾಗಿ, ಉದಾಹರಣೆಗೆ, UDP ಪೇಲೋಡ್, ಕೋಡ್ ಮತ್ತು ಎಂಜಿನ್ ನಡುವಿನ ಎಲ್ಲಾ ಸಂವಹನ ಎರಡು UDP ಪ್ಯಾಕೆಟ್‌ಗಳು: ಒಂದು ಒಂದು ದಿಕ್ಕಿನಲ್ಲಿ ಹಾರುತ್ತದೆ, ಎರಡನೆಯದು ಇನ್ನೊಂದು ದಿಕ್ಕಿನಲ್ಲಿ. ಒಂದು ರೌಂಡ್ ಟ್ರಿಪ್ - ಮತ್ತು ಕೋಡ್ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಇಲ್ಲದೆ ಎಂಜಿನ್‌ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯಿತು.

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

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

ನಿರಂತರ ಡೇಟಾ ಸಂಗ್ರಹಣೆ

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

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

ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವವನ್ನು ನಾನು ತ್ವರಿತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ. ಎಂಜಿನ್ ಚಲಿಸುವ ಸರ್ವರ್ ಇದೆ. ಅವರು ಬರವಣಿಗೆಗಾಗಿ ಹೊಸ ಖಾಲಿ ಬಿನ್ಲಾಗ್ ಅನ್ನು ತೆರೆಯುತ್ತಾರೆ ಮತ್ತು ಅದಕ್ಕೆ ಬದಲಾವಣೆಗಾಗಿ ಈವೆಂಟ್ ಅನ್ನು ಬರೆಯುತ್ತಾರೆ.

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

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

ಸ್ನ್ಯಾಪ್‌ಶಾಟ್ ರಚಿಸಲಾದ ಸಮಯದಲ್ಲಿ ಇದ್ದ ಸ್ಥಾನ ಮತ್ತು ಬಿನ್‌ಲಾಗ್‌ನ ಗಾತ್ರವನ್ನು ಓದುತ್ತದೆ.

ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ಪಡೆಯಲು ಬಿನ್‌ಲಾಗ್‌ನ ಅಂತ್ಯವನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಮುಂದಿನ ಈವೆಂಟ್‌ಗಳನ್ನು ಬರೆಯುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಇದು ಸರಳವಾದ ಯೋಜನೆಯಾಗಿದೆ; ನಮ್ಮ ಎಲ್ಲಾ ಎಂಜಿನ್ಗಳು ಅದರ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

ಡೇಟಾ ಪುನರಾವರ್ತನೆ

ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮಲ್ಲಿ ಡೇಟಾ ಪುನರಾವರ್ತನೆ ಹೇಳಿಕೆ ಆಧಾರಿತ — ನಾವು ಬಿಲ್ಲಾಗ್‌ನಲ್ಲಿ ಯಾವುದೇ ಪುಟ ಬದಲಾವಣೆಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ಅವುಗಳೆಂದರೆ ವಿನಂತಿಗಳನ್ನು ಬದಲಾಯಿಸಿ. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಬರುವಂತೆಯೇ ಹೋಲುತ್ತದೆ, ಸ್ವಲ್ಪ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ.

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

ಅಗತ್ಯವಿದ್ದರೆ ಓದುವ ಪ್ರತಿಕೃತಿCPU ಓದುವ ಲೋಡ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಓದುವ ಎಂಜಿನ್ ಅನ್ನು ಸರಳವಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ, ಇದು ಬಿನ್ಲಾಗ್ನ ಅಂತ್ಯವನ್ನು ಓದುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಈ ಆಜ್ಞೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ.

ಇಲ್ಲಿ ವಿಳಂಬವು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿದೆ, ಮತ್ತು ಪ್ರತಿಕೃತಿಯು ಮಾಸ್ಟರ್ಗಿಂತ ಎಷ್ಟು ಹಿಂದುಳಿದಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಸಾಧ್ಯ.

RPC ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಡೇಟಾ ಹಂಚಿಕೆ

ಶೇರ್ಡಿಂಗ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಯಾವ ಕ್ಲಸ್ಟರ್ ಚೂರುಗಳನ್ನು ಕಳುಹಿಸಬೇಕೆಂದು ಪ್ರಾಕ್ಸಿ ಹೇಗೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ? ಕೋಡ್ ಹೇಳುವುದಿಲ್ಲ: "15 ಚೂರುಗಳಿಗೆ ಕಳುಹಿಸಿ!" - ಇಲ್ಲ, ಇದನ್ನು ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಮಾಡಲಾಗುತ್ತದೆ.

ಸರಳವಾದ ಯೋಜನೆ ಫಸ್ಟ್ಇಂಟ್ ಆಗಿದೆ - ವಿನಂತಿಯಲ್ಲಿ ಮೊದಲ ಸಂಖ್ಯೆ.

get(photo100_500) => 100 % N.

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

ನಾವು ಒಂದೇ ಘಟಕದ ಡೇಟಾ ಸ್ಥಳವನ್ನು ಹೊಂದಲು ಬಯಸಿದಾಗ ಇದು ಉಪಯುಕ್ತವಾಗಿದೆ. 100 ಒಂದು ಬಳಕೆದಾರ ಅಥವಾ ಗುಂಪು ID ಎಂದು ಹೇಳೋಣ ಮತ್ತು ಸಂಕೀರ್ಣವಾದ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ ಒಂದು ಘಟಕದ ಎಲ್ಲಾ ಡೇಟಾ ಒಂದೇ ಚೂರುಗಳಲ್ಲಿರಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.

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

hash(photo100_500) => 3539886280 % N

ನಾವು ಹ್ಯಾಶ್, ವಿಭಜನೆಯ ಶೇಷ ಮತ್ತು ಶಾರ್ಡ್ ಸಂಖ್ಯೆಯನ್ನು ಸಹ ಪಡೆಯುತ್ತೇವೆ.

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

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

ಸೂಪರ್-ನಿರ್ದಿಷ್ಟ ವಿನಂತಿಗಳಿವೆ. ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ: RPC ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಯಾವ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೋಗಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಶಾರ್ಡ್ ಅನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ನಂತರ ಬರವಣಿಗೆಯ ಮಾಸ್ಟರ್ಸ್ ಇವೆ, ಅಥವಾ, ಕ್ಲಸ್ಟರ್ ಪ್ರತಿಕೃತಿ ಬೆಂಬಲವನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಬೇಡಿಕೆಯ ಮೇಲೆ ಪ್ರತಿಕೃತಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಇದೆಲ್ಲವನ್ನೂ ಮಾಡುತ್ತದೆ.

ದಾಖಲೆಗಳು

ನಾವು ಹಲವಾರು ರೀತಿಯಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ. ಅತ್ಯಂತ ಸ್ಪಷ್ಟ ಮತ್ತು ಸರಳವಾದದ್ದು memcache ಗೆ ದಾಖಲೆಗಳನ್ನು ಬರೆಯಿರಿ.

ring-buffer: prefix.idx = line

ಒಂದು ಪ್ರಮುಖ ಪೂರ್ವಪ್ರತ್ಯಯವಿದೆ - ಲಾಗ್‌ನ ಹೆಸರು, ಒಂದು ಸಾಲು, ಮತ್ತು ಈ ಲಾಗ್‌ನ ಗಾತ್ರವಿದೆ - ಸಾಲುಗಳ ಸಂಖ್ಯೆ. ನಾವು 0 ರಿಂದ 1 ಗೆರೆಗಳ ಸಂಖ್ಯೆಗೆ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. memcache ನಲ್ಲಿನ ಕೀಲಿಯು ಈ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ಪೂರ್ವಪ್ರತ್ಯಯವಾಗಿದೆ. ನಾವು ಲಾಗ್ ಲೈನ್ ಮತ್ತು ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ಮೌಲ್ಯಕ್ಕೆ ಉಳಿಸುತ್ತೇವೆ.

ದಾಖಲೆಗಳನ್ನು ಓದಲು ಅಗತ್ಯವಾದಾಗ, ನಾವು ಕೈಗೊಳ್ಳುತ್ತೇವೆ ಬಹು ಪಡೆಯಿರಿ ಎಲ್ಲಾ ಕೀಗಳನ್ನು ಸಮಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ವಿಂಗಡಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ನೈಜ ಸಮಯದಲ್ಲಿ ಉತ್ಪಾದನಾ ಲಾಗ್ ಅನ್ನು ಪಡೆಯಿರಿ. ನೀವು ನೈಜ ಸಮಯದಲ್ಲಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಏನನ್ನಾದರೂ ಡೀಬಗ್ ಮಾಡಬೇಕಾದಾಗ, ಯಾವುದನ್ನೂ ಮುರಿಯದೆ, ಇತರ ಯಂತ್ರಗಳಿಗೆ ಸಂಚಾರವನ್ನು ನಿಲ್ಲಿಸದೆ ಅಥವಾ ಅನುಮತಿಸದೆಯೇ ಈ ಯೋಜನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಆದರೆ ಈ ಲಾಗ್ ದೀರ್ಘಕಾಲ ಉಳಿಯುವುದಿಲ್ಲ.

ಲಾಗ್ಗಳ ವಿಶ್ವಾಸಾರ್ಹ ಸಂಗ್ರಹಣೆಗಾಗಿ ನಾವು ಎಂಜಿನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ದಾಖಲೆಗಳು-ಎಂಜಿನ್. ಇದಕ್ಕಾಗಿಯೇ ಇದನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ನನಗೆ ತಿಳಿದಿರುವ ಅತಿದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ 600 TB ಪ್ಯಾಕ್ ಮಾಡಿದ ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ.

ಎಂಜಿನ್ ತುಂಬಾ ಹಳೆಯದು, ಈಗಾಗಲೇ 6-7 ವರ್ಷ ವಯಸ್ಸಿನ ಕ್ಲಸ್ಟರ್‌ಗಳಿವೆ. ನಾವು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸಮಸ್ಯೆಗಳಿವೆ, ಉದಾಹರಣೆಗೆ, ಲಾಗ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.

ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲಾಗುತ್ತಿದೆ

ಈ ರೇಖಾಚಿತ್ರವು ನಾವು ನಮ್ಮ ಎಂಜಿನ್‌ಗಳಲ್ಲಿ ಹೇಗೆ ನಡೆಯುತ್ತೇವೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

RPC ಮೂಲಕ RPC-ಪ್ರಾಕ್ಸಿಗೆ ಸ್ಥಳೀಯವಾಗಿ ಹೋಗುವ ಕೋಡ್ ಇದೆ ಮತ್ತು ಎಂಜಿನ್‌ಗೆ ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ಅದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯಲು ಬಯಸಿದರೆ, ಈ ಯೋಜನೆಯಲ್ಲಿ ನಾವು ಎರಡು ಭಾಗಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿದೆ:

ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ಕೆಲವು ಎಂಜಿನ್ ಅನ್ನು ಬದಲಾಯಿಸಿ;
ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗದ RPC ಪ್ರಾಕ್ಸಿಯನ್ನು ಬದಲಾಯಿಸಿ, ಮತ್ತು RPC ಮೂಲಕ ಕೆಲವು ಪರಿಹಾರಗಳೊಂದಿಗೆ.

ಎಂಜಿನ್ ಸರಳವಾಗಿದೆ - ನಾವು ಅದನ್ನು ಸರ್ವರ್ ಅಥವಾ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ಸರ್ವರ್‌ಗಳ ಕ್ಲಸ್ಟರ್‌ನೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ.

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

ಕೆಲವೊಮ್ಮೆ ನಾವು RPC ಯೋಜನೆಯನ್ನು ಪ್ರಮಾಣಿತವಲ್ಲದ ಪರಿಹಾರಗಳಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಬಯಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, nginx ನಲ್ಲಿ. ಆದ್ದರಿಂದ, ಕಿಟನ್‌ಹೌಸ್ UDP ಮೂಲಕ ಲಾಗ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ.

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

ಮಾನಿಟರಿಂಗ್

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

ಸಿಸ್ಟಮ್ ಮೆಟ್ರಿಕ್ಸ್

ಇದು ನಮ್ಮ ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ನೆಟ್‌ಡೇಟಾ, ಇದು ಅಂಕಿಅಂಶಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ ಕಳುಹಿಸುತ್ತದೆ ಗ್ರ್ಯಾಫೈಟ್ ಕಾರ್ಬನ್. ಆದ್ದರಿಂದ, ಕ್ಲಿಕ್‌ಹೌಸ್ ಅನ್ನು ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆಯಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಉದಾಹರಣೆಗೆ ವಿಸ್ಪರ್ ಅಲ್ಲ. ಅಗತ್ಯವಿದ್ದರೆ, ನೀವು ನೇರವಾಗಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಿಂದ ಓದಬಹುದು ಅಥವಾ ಬಳಸಬಹುದು ಗ್ರಾಫಾನಾ ಮೆಟ್ರಿಕ್‌ಗಳು, ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ವರದಿಗಳಿಗಾಗಿ. ಡೆವಲಪರ್‌ಗಳಾಗಿ, ನಾವು Netdata ಮತ್ತು Grafana ಗೆ ಸಾಕಷ್ಟು ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ಉತ್ಪನ್ನ ಮೆಟ್ರಿಕ್ಸ್

ಅನುಕೂಲಕ್ಕಾಗಿ, ನಾವು ಬಹಳಷ್ಟು ವಿಷಯಗಳನ್ನು ಬರೆದಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ಎಣಿಕೆಗಳು, ವಿಶಿಷ್ಟ ಎಣಿಕೆಗಳ ಮೌಲ್ಯಗಳನ್ನು ಅಂಕಿಅಂಶಗಳಾಗಿ ಬರೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಮಾನ್ಯ ಕಾರ್ಯಗಳ ಒಂದು ಸೆಟ್ ಇದೆ, ಅದನ್ನು ಎಲ್ಲೋ ಮುಂದೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

ತರುವಾಯ, ನಾವು ವಿಂಗಡಿಸುವ ಮತ್ತು ಗುಂಪು ಮಾಡುವ ಫಿಲ್ಟರ್‌ಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಅಂಕಿಅಂಶಗಳಿಂದ ನಮಗೆ ಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು - ಗ್ರಾಫ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿ, ವಾಚ್‌ಡಾಗ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ.

ನಾವು ತುಂಬಾ ಬರೆಯುತ್ತೇವೆ ಅನೇಕ ಮೆಟ್ರಿಕ್‌ಗಳು ಘಟನೆಗಳ ಸಂಖ್ಯೆ ದಿನಕ್ಕೆ 600 ಶತಕೋಟಿಯಿಂದ 1 ಟ್ರಿಲಿಯನ್ ಆಗಿದೆ. ಆದಾಗ್ಯೂ, ನಾವು ಅವುಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ ಕನಿಷ್ಠ ಒಂದೆರಡು ವರ್ಷಗಳುಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿನ ಪ್ರವೃತ್ತಿಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು. ಎಲ್ಲವನ್ನೂ ಒಟ್ಟುಗೂಡಿಸಿ ನಾವು ಇನ್ನೂ ಪರಿಹರಿಸದ ದೊಡ್ಡ ಸಮಸ್ಯೆಯಾಗಿದೆ. ಕಳೆದ ಕೆಲವು ವರ್ಷಗಳಿಂದ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

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

ಅಗತ್ಯವಿದ್ದರೆ, ನಾವು ನೇರವಾಗಿ ದಾಖಲೆಗಳು-ಸಂಗ್ರಾಹಕರಿಗೆ ಬರೆಯಬಹುದು.

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

ಮುಂದೆ, ದಾಖಲೆಗಳು-ಸಂಗ್ರಾಹಕರು ಅಂಕಿಅಂಶಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುತ್ತಾರೆ ಮಿಯಾವ್ಡಿಬಿ - ಇದು ನಮ್ಮ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ, ಇದು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಹ ಸಂಗ್ರಹಿಸಬಹುದು.

ನಂತರ ನಾವು ಕೋಡ್‌ನಿಂದ ಬೈನರಿ "ಸಮೀಪ-SQL" ಆಯ್ಕೆಗಳನ್ನು ಮಾಡಬಹುದು.

ಪ್ರಯೋಗ

2018 ರ ಬೇಸಿಗೆಯಲ್ಲಿ, ನಾವು ಆಂತರಿಕ ಹ್ಯಾಕಥಾನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ ಮತ್ತು ರೇಖಾಚಿತ್ರದ ಕೆಂಪು ಭಾಗವನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಬಹುದಾದ ಯಾವುದನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಆಲೋಚನೆ ಬಂದಿತು. ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಅದನ್ನು ಏಕೆ ಪ್ರಯತ್ನಿಸಬಾರದು?

ನಾವು ಕಿಟನ್‌ಹೌಸ್ ಮೂಲಕ ಲಾಗ್‌ಗಳನ್ನು ಬರೆಯುವ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ.

ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ ರೇಖಾಚಿತ್ರಕ್ಕೆ ಮತ್ತೊಂದು "*ಮನೆ" ಸೇರಿಸಿ, ಇದು ನಮ್ಮ ಕೋಡ್ UDP ಮೂಲಕ ಬರೆಯುವ ಸ್ವರೂಪದಲ್ಲಿ ನಿಖರವಾಗಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ನಂತರ ಈ *ಹೌಸ್ ಅವುಗಳನ್ನು ಲಾಗ್‌ಗಳಂತಹ ಇನ್ಸರ್ಟ್‌ಗಳಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ, ಇದನ್ನು ಕಿಟನ್‌ಹೌಸ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಅವರು ಈ ಲಾಗ್‌ಗಳನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಲುಪಿಸಬಹುದು, ಅದು ಅವುಗಳನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

memcache, stats-demon ಮತ್ತು logs-collectors ಡೇಟಾಬೇಸ್‌ನೊಂದಿಗಿನ ಸ್ಕೀಮ್ ಅನ್ನು ಇದರೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗಿದೆ.

ಇಲ್ಲಿ ಕೋಡ್‌ನಿಂದ ರವಾನೆ ಇದೆ, ಇದನ್ನು ಸ್ಥಳೀಯವಾಗಿ StatsHouse ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ.
StatsHouse ಯುಡಿಪಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಬರೆಯುತ್ತದೆ, ಈಗಾಗಲೇ SQL ಇನ್‌ಸರ್ಟ್‌ಗಳಾಗಿ ಮಾರ್ಪಡಿಸಲಾಗಿದೆ, ಬ್ಯಾಚ್‌ಗಳಲ್ಲಿ KittenHouse ಗೆ.
ಕಿಟನ್‌ಹೌಸ್ ಅವರನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ನಾವು ಅವುಗಳನ್ನು ಓದಲು ಬಯಸಿದರೆ, ನಾವು ಅವುಗಳನ್ನು StatsHouse ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡುವುದನ್ನು ಓದುತ್ತೇವೆ - ಸಾಮಾನ್ಯ SQL ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೇರವಾಗಿ ClickHouse ನಿಂದ.

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

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

ನಿಯೋಜಿಸಿ

ಮೊದಲಿಗೆ, PHP ನಿಯೋಜನೆಯನ್ನು ನೋಡೋಣ. ನಾವು ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದ್ದೇವೆ ಹೋಗಿ: ಬಳಸಿ ಗಿಟ್ಲಾಬ್ и ಟೀಮ್‌ಸಿಟಿ ನಿಯೋಜನೆಗಾಗಿ. ಅಭಿವೃದ್ಧಿ ಶಾಖೆಗಳನ್ನು ಮಾಸ್ಟರ್ ಶಾಖೆಯಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ, ಪರೀಕ್ಷೆಗಾಗಿ ಮಾಸ್ಟರ್‌ನಿಂದ ಅವುಗಳನ್ನು ಸ್ಟೇಜಿಂಗ್‌ಗೆ ಮತ್ತು ಸ್ಟೇಜಿಂಗ್‌ನಿಂದ ಉತ್ಪಾದನೆಗೆ ವಿಲೀನಗೊಳಿಸಲಾಗುತ್ತದೆ.

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

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

ಮೂಲಭೂತವಾಗಿ ಬೈನರಿಗಳಾಗಿರುವ ನಮ್ಮ ಎಂಜಿನ್‌ಗಳಿಗೆ, ಯೋಜನೆಯು ತುಂಬಾ ಹೋಲುತ್ತದೆ:

git ಮಾಸ್ಟರ್ ಶಾಖೆ;
ಬೈನರಿ ಇನ್ .deb;
ಆವೃತ್ತಿಯನ್ನು ಬಿನ್‌ಲಾಗ್ ಕಾಪಿಫಾಸ್ಟ್‌ಗೆ ಬರೆಯಲಾಗಿದೆ;
ಸರ್ವರ್‌ಗಳಿಗೆ ಪುನರಾವರ್ತಿಸಲಾಗಿದೆ;
ಸರ್ವರ್ ತಾಜಾ .dep ಅನ್ನು ಹೊರತೆಗೆಯುತ್ತದೆ;
dpkg -i;
ಹೊಸ ಆವೃತ್ತಿಗೆ ಆಕರ್ಷಕವಾದ ಮರುಪ್ರಾರಂಭ.

ವ್ಯತ್ಯಾಸವೆಂದರೆ ನಮ್ಮ ಬೈನರಿಯನ್ನು ಆರ್ಕೈವ್‌ಗಳಲ್ಲಿ ಪ್ಯಾಕ್ ಮಾಡಲಾಗಿದೆ .deb, ಮತ್ತು ಅವುಗಳನ್ನು ಪಂಪ್ ಮಾಡುವಾಗ dpkg -i ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಇರಿಸಲಾಗಿದೆ. kPHP ಅನ್ನು ಬೈನರಿಯಾಗಿ ಏಕೆ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ಎಂಜಿನ್‌ಗಳನ್ನು dpkg ಎಂದು ನಿಯೋಜಿಸಲಾಗಿದೆ? ಅದು ಆ ರೀತಿ ನಡೆಯಿತು. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ - ಅದನ್ನು ಮುಟ್ಟಬೇಡಿ.

ಉಪಯುಕ್ತ ಲಿಂಕ್‌ಗಳು:

ಆಂಟನ್ ಕಿರ್ಯುಶ್ಕಿನ್ ಅವರ ವರದಿ "Vkontakte ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರು. ಹೇಗೆ?" ಕಾಪಿಫಾಸ್ಟ್ ಮತ್ತು ಗಾಸಿಪ್ ಬಗ್ಗೆ ವಿವರಗಳೊಂದಿಗೆ.
ಯೂರಿ ನಸ್ರೆಟ್ಡಿನೋವ್ ಅವರ ವರದಿ "ಹತ್ತಾರು ಸಾವಿರ ಸರ್ವರ್‌ಗಳಿಂದ ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ವಿಕೆ ಡೇಟಾವನ್ನು ಹೇಗೆ ಸೇರಿಸುತ್ತದೆ".
ನನ್ನ ವರದಿ "VKontakte ನ ಉದಾಹರಣೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಬೆಳೆಯುತ್ತಿರುವ ಯೋಜನೆಯ ಆರ್ಕಿಟೆಕ್ಚರ್", ಆದರೆ ಅಭಿವೃದ್ಧಿಯ ದೃಷ್ಟಿಕೋನದಿಂದ, ಹಾರ್ಡ್ವೇರ್ ಅಲ್ಲ.

ಕಾರ್ಯಕ್ರಮ ಸಮಿತಿಯ ಭಾಗವಾಗಿ ಸಹಾಯ ಮಾಡುವವರಲ್ಲಿ ಅಲೆಕ್ಸಿ ಅಕುಲೋವಿಚ್ ಒಬ್ಬರು ಪಿಎಚ್ಪಿ ರಷ್ಯಾ ಮೇ 17 ರಂದು PHP ಡೆವಲಪರ್‌ಗಳಿಗೆ ಇತ್ತೀಚಿನ ದಿನಗಳಲ್ಲಿ ಅತಿ ದೊಡ್ಡ ಕಾರ್ಯಕ್ರಮವಾಗಲಿದೆ. ನಮ್ಮ ಬಳಿ ಎಷ್ಟು ತಂಪಾದ ಪಿಸಿ ಇದೆ ಎಂದು ನೋಡಿ ಭಾಷಿಕರು (ಅವುಗಳಲ್ಲಿ ಎರಡು PHP ಕೋರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿವೆ!) - ನೀವು PHP ಅನ್ನು ಬರೆದರೆ ನೀವು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಾರದು ಎಂದು ತೋರುತ್ತದೆ.

ಮೂಲ: www.habr.com

VKontakte ನ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಕೆಲಸದ ಮೇಲೆ FAQ