ಹಲೋ, ಹಬ್ರ್!

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

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

ಸಮತಲ ಸ್ಕೇಲಿಂಗ್

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

ಉದಾಹರಣೆಗೆ, ನಾನು ಅಮೂರ್ತ ಕ್ಲೌಡ್ ಫೈಲ್ ಸಂಗ್ರಹಣೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತೇನೆ, ಅಂದರೆ, OwnCloud, OneDrive, ಇತ್ಯಾದಿಗಳ ಕೆಲವು ಅನಲಾಗ್.

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

ವಿಧಾನಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ: ಲಂಬ ಸ್ಕೇಲಿಂಗ್‌ನಲ್ಲಿ, ನೋಡ್‌ಗಳ ಶಕ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸಲು ನಾವು ಸಿದ್ಧರಿದ್ದೇವೆ ಮತ್ತು ಸಮತಲ ಸ್ಕೇಲಿಂಗ್‌ನಲ್ಲಿ, ಲೋಡ್ ಅನ್ನು ವಿತರಿಸಲು ನಾವು ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಸೇರಿಸಲು ಸಿದ್ಧರಿದ್ದೇವೆ.

CQRS

ಕಮಾಂಡ್ ಕ್ವೆರಿ ಜವಾಬ್ದಾರಿ ಪ್ರತ್ಯೇಕತೆ ಒಂದು ಪ್ರಮುಖ ಮಾದರಿ, ಏಕೆಂದರೆ ಇದು ವಿಭಿನ್ನ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ವಿಭಿನ್ನ ಸೇವೆಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಮಾತ್ರವಲ್ಲದೆ ಅದೇ ಈವೆಂಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಹ ಅನುಮತಿಸುತ್ತದೆ. ಸರಳವಾದ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಇದರ ಪ್ರಯೋಜನಗಳು ಅಷ್ಟು ಸ್ಪಷ್ಟವಾಗಿಲ್ಲ, ಆದರೆ ಕಾರ್ಯನಿರತ ಸೇವೆಗೆ ಇದು ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ (ಮತ್ತು ಸರಳ). ಇದರ ಸಾರ: ಒಳಬರುವ ಮತ್ತು ಹೊರಹೋಗುವ ಡೇಟಾ ಹರಿವುಗಳು ಛೇದಿಸಬಾರದು. ಅಂದರೆ, ನೀವು ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಲು ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ; ಬದಲಿಗೆ, ನೀವು ಸೇವೆ A ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತೀರಿ, ಆದರೆ ಸೇವೆ B ಯಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತೀರಿ.

ಈ ವಿಧಾನದ ಮೊದಲ ಬೋನಸ್ ದೀರ್ಘ ವಿನಂತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಸಂಪರ್ಕವನ್ನು (ಪದದ ವಿಶಾಲ ಅರ್ಥದಲ್ಲಿ) ಮುರಿಯುವ ಸಾಮರ್ಥ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಪ್ರಮಾಣಿತ ಅನುಕ್ರಮವನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ:

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

ಪಾಯಿಂಟ್ 2 ರಲ್ಲಿ ಸಂಪರ್ಕವು ಮುರಿದುಹೋಗಿದೆ ಎಂದು ಊಹಿಸೋಣ (ಅಥವಾ ನೆಟ್‌ವರ್ಕ್ ಮರುಸಂಪರ್ಕಿಸಲಾಗಿದೆ, ಅಥವಾ ಬಳಕೆದಾರರು ಮತ್ತೊಂದು ಪುಟಕ್ಕೆ ಹೋದರು, ಸಂಪರ್ಕವನ್ನು ಮುರಿಯುತ್ತಾರೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಖರವಾಗಿ ಏನನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗಿದೆ ಎಂಬುದರ ಕುರಿತು ಮಾಹಿತಿಯೊಂದಿಗೆ ಬಳಕೆದಾರರಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಕಳುಹಿಸಲು ಸರ್ವರ್‌ಗೆ ಕಷ್ಟವಾಗುತ್ತದೆ. CQRS ಅನ್ನು ಬಳಸುವುದರಿಂದ, ಅನುಕ್ರಮವು ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ:

ಕ್ಲೈಂಟ್ ನವೀಕರಣಗಳಿಗೆ ಚಂದಾದಾರರಾಗಿದ್ದಾರೆ.
ಕ್ಲೈಂಟ್ ಸರ್ವರ್‌ಗೆ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದಾರೆ.
"ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ" ಎಂದು ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ.
"1" ಬಿಂದುವಿನಿಂದ ಚಾನಲ್ ಮೂಲಕ ಫಲಿತಾಂಶದೊಂದಿಗೆ ಸರ್ವರ್ ಪ್ರತಿಕ್ರಿಯಿಸಿದೆ.

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

ಕುತೂಹಲಕಾರಿಯಾಗಿ, ಒಳಬರುವ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಕೋಡ್ ಕ್ಲೈಂಟ್‌ನಿಂದ ಪ್ರಭಾವಿತವಾದ ಈವೆಂಟ್‌ಗಳಿಗೆ ಮತ್ತು ಇತರ ಕ್ಲೈಂಟ್‌ಗಳು ಸೇರಿದಂತೆ ಇತರ ಈವೆಂಟ್‌ಗಳಿಗೆ ಒಂದೇ ಆಗಿರುತ್ತದೆ (100% ಅಲ್ಲ).

ಆದಾಗ್ಯೂ, ವಾಸ್ತವದಲ್ಲಿ ನಾವು ಏಕಮುಖ ಹರಿವನ್ನು ಕ್ರಿಯಾತ್ಮಕ ಶೈಲಿಯಲ್ಲಿ (RX ಮತ್ತು ಅಂತಹುದೇ ಬಳಸಿ) ನಿರ್ವಹಿಸಬಹುದೆಂಬ ಅಂಶದಿಂದಾಗಿ ಹೆಚ್ಚುವರಿ ಬೋನಸ್ ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಮತ್ತು ಇದು ಈಗಾಗಲೇ ಗಂಭೀರವಾದ ಪ್ಲಸ್ ಆಗಿದೆ, ಏಕೆಂದರೆ ಮೂಲಭೂತವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಮಾಡಬಹುದು ಮತ್ತು ಕ್ರಿಯಾತ್ಮಕ ವಿಧಾನವನ್ನು ಸಹ ಬಳಸಬಹುದು. ಕೊಬ್ಬಿನ ಕಾರ್ಯಕ್ರಮಗಳಿಗಾಗಿ, ಇದು ಗಮನಾರ್ಹವಾಗಿ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಬೆಂಬಲ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸಬಹುದು.

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

ಈವೆಂಟ್ ಸೋರ್ಸಿಂಗ್

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

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

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

ಆದಾಗ್ಯೂ, ಮೂಲ ಕಾರ್ಯಕ್ಕೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ವ್ಯವಸ್ಥೆಯ ಭಾಗವನ್ನು ನಿರ್ಮಿಸಬಹುದಾದರೆ ಅಂತಿಮವಾಗಿ ಸ್ಥಿರತೆ, ನಂತರ ನಾವು ಈ ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವನ್ನು ರಚಿಸಬಹುದು.

ಈ ವಿಧಾನದ ಪ್ರಮುಖ ಲಕ್ಷಣಗಳು:

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

ಆನ್‌ಲೈನ್ ಫೈಲ್ ಸಂಗ್ರಹಣೆಯ ಪ್ರಕರಣವನ್ನು ನಾವು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

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

ಮತ್ತು ಇಬ್ಬರು ಬಳಕೆದಾರರಿಗೆ ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ (ವಿಭಿನ್ನ ಬಳಕೆದಾರರಿಗೆ ಉದ್ದೇಶಿಸಲಾದ ಸೇವೆಗಳನ್ನು ವಿವಿಧ ಬಣ್ಣಗಳಲ್ಲಿ ಸೂಚಿಸಲಾಗುತ್ತದೆ):

ಅಂತಹ ಸಂಯೋಜನೆಯಿಂದ ಬೋನಸ್ಗಳು:

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

ಆದಾಗ್ಯೂ, ಅನಾನುಕೂಲಗಳು ತಕ್ಷಣವೇ ಗೋಚರಿಸುತ್ತವೆ:

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

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

ಪರಿಣಾಮವಾಗಿ:

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

ತೀಕ್ಷ್ಣಗೊಳಿಸುವಿಕೆ

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

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

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

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

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

ಹೀಗಾಗಿ, ಫೈಲ್‌ಗಳಿಗಾಗಿ ಆನ್‌ಲೈನ್ ಸಂಗ್ರಹಣೆಯ ಕುರಿತು ನಮ್ಮ ಉದಾಹರಣೆಯನ್ನು ಮುಂದುವರಿಸುವುದರಿಂದ, ಅಂತಹ ವಾಸ್ತುಶಿಲ್ಪವು ಈಗಾಗಲೇ ನಮಗೆ ಹಲವಾರು ಬೋನಸ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ:

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

ಸ್ಥಿರ ವಿಷಯ ಹೋಸ್ಟಿಂಗ್

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

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

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

ಸರ್ವರ್ ಡೌನ್‌ಲೋಡ್ URL ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಫೈಲ್_ಐಡಿ + ಕೀ ಫಾರ್ಮ್ ಆಗಿರಬಹುದು, ಅಲ್ಲಿ ಕೀ ಎನ್ನುವುದು ಮಿನಿ-ಡಿಜಿಟಲ್ ಸಿಗ್ನೇಚರ್ ಆಗಿದ್ದು ಅದು ಮುಂದಿನ XNUMX ಗಂಟೆಗಳವರೆಗೆ ಸಂಪನ್ಮೂಲವನ್ನು ಪ್ರವೇಶಿಸುವ ಹಕ್ಕನ್ನು ನೀಡುತ್ತದೆ.
ಕೆಳಗಿನ ಆಯ್ಕೆಗಳೊಂದಿಗೆ ಫೈಲ್ ಅನ್ನು ಸರಳ nginx ಮೂಲಕ ವಿತರಿಸಲಾಗುತ್ತದೆ:
- ವಿಷಯ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆ. ಈ ಸೇವೆಯನ್ನು ಪ್ರತ್ಯೇಕ ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಿಸಬಹುದಾದ ಕಾರಣ, ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಇತ್ತೀಚಿನ ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ನಾವು ಭವಿಷ್ಯಕ್ಕಾಗಿ ಮೀಸಲು ಇರಿಸಿದ್ದೇವೆ.
- ಸಂಪರ್ಕವನ್ನು ರಚಿಸುವ ಸಮಯದಲ್ಲಿ ಕೀಲಿಯನ್ನು ಪರಿಶೀಲಿಸಲಾಗುತ್ತಿದೆ
ಐಚ್ಛಿಕ: ಸ್ಟ್ರೀಮಿಂಗ್ ವಿಷಯ ಪ್ರಕ್ರಿಯೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಸೇವೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಫೈಲ್‌ಗಳನ್ನು ಸಂಕುಚಿತಗೊಳಿಸಿದರೆ, ನಂತರ ನಾವು ಈ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಅನ್ಜಿಪ್ ಮಾಡಬಹುದು. ಪರಿಣಾಮವಾಗಿ: IO ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಅವರು ಸೇರಿರುವ ಸ್ಥಳದಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ. ಜಾವಾದಲ್ಲಿನ ಆರ್ಕೈವರ್ ಸುಲಭವಾಗಿ ಹೆಚ್ಚುವರಿ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ, ಆದರೆ ವ್ಯಾಪಾರ ತರ್ಕದೊಂದಿಗೆ ಸೇವೆಯನ್ನು ರಸ್ಟ್/ಸಿ++ ಷರತ್ತುಗಳಿಗೆ ಪುನಃ ಬರೆಯುವುದು ಸಹ ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿರಬಹುದು. ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ವಿಭಿನ್ನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು (ಅಥವಾ ಸೇವೆಗಳನ್ನು ಸಹ) ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಆದ್ದರಿಂದ ನಾವು ವ್ಯವಹಾರ ತರ್ಕ ಮತ್ತು IO ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಸಾಕಷ್ಟು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಪ್ರತ್ಯೇಕಿಸಬಹುದು.

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

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

ಆದಾಗ್ಯೂ, ನಾವು ನಮ್ಮ ಸಿಸ್ಟಮ್‌ಗೆ ಹಿಂತಿರುಗಿದರೆ, ನಾವು ಇದೇ ರೀತಿಯ ರೇಖಾಚಿತ್ರವನ್ನು ಪಡೆಯುತ್ತೇವೆ:

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

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

ತೀರ್ಮಾನಕ್ಕೆ

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

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

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

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

ಮೂಲ: www.habr.com

ಅನುಕೂಲಕರ ವಾಸ್ತುಶಿಲ್ಪದ ಮಾದರಿಗಳು