ಪ್ರೊಹೋಸ್ಟರ್ > Блог > ಆಡಳಿತ > ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಹೇಗೆ ಮತ್ತು ಏಕೆ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಎಂಬುದರ ಕುರಿತು ಮಾತನಾಡುತ್ತೇವೆ ಸಂವಹನ ವ್ಯವಸ್ಥೆ - ಕ್ಲೈಂಟ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಮಾಹಿತಿಯನ್ನು ವರ್ಗಾಯಿಸುವ ಕಾರ್ಯವಿಧಾನ - ಕಾರ್ಯವನ್ನು ಹೊಂದಿಸುವುದರಿಂದ ಹಿಡಿದು ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಅನುಷ್ಠಾನದ ವಿವರಗಳ ಮೂಲಕ ಯೋಚಿಸುವುದು.

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

SV ವಿತರಿಸಿದ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸುತ್ತದೆ ಹ್ಯಾಝೆಲ್ಕಾಸ್ಟ್ ಮತ್ತು ಹುಡುಕಾಟ ಎಂಜಿನ್ Elasticsearch. ನಾವು Java ಮತ್ತು ನಾವು PostgreSQL ಅನ್ನು ಹೇಗೆ ಅಡ್ಡಲಾಗಿ ಅಳೆಯುತ್ತೇವೆ ಎಂಬುದರ ಕುರಿತು ಸಹ ಮಾತನಾಡುತ್ತೇವೆ.
ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

ಸಮಸ್ಯೆ ಹೇಳಿಕೆ

ನಾವು ಸಂವಹನ ವ್ಯವಸ್ಥೆಯನ್ನು ಏಕೆ ರಚಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟಪಡಿಸಲು, 1C ಯಲ್ಲಿ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿವೃದ್ಧಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ನಿಮಗೆ ಸ್ವಲ್ಪ ಹೇಳುತ್ತೇನೆ.

ಮೊದಲಿಗೆ, ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ ಎಂದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲದವರಿಗೆ ನಮ್ಮ ಬಗ್ಗೆ ಸ್ವಲ್ಪ :) ನಾವು 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ತಂತ್ರಜ್ಞಾನ ವೇದಿಕೆಯನ್ನು ತಯಾರಿಸುತ್ತಿದ್ದೇವೆ. ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್ ಡೆವಲಪ್‌ಮೆಂಟ್ ಟೂಲ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ, ಜೊತೆಗೆ ಕ್ರಾಸ್-ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಪರಿಸರದಲ್ಲಿ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಅನುಮತಿಸುವ ರನ್‌ಟೈಮ್.

ಕ್ಲೈಂಟ್-ಸರ್ವರ್ ಅಭಿವೃದ್ಧಿ ಮಾದರಿ

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

ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಲ್ಲಿ, ಕಾರ್ಯವಿಧಾನಗಳು ಮತ್ತು ಕಾರ್ಯಗಳ ಹೆಡರ್‌ಗಳು ಕೋಡ್ ಅನ್ನು ಎಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಸೂಚಿಸಬೇಕು - &AtClient / &AtServer ನಿರ್ದೇಶನಗಳನ್ನು (&AtClient / &AtServer ಭಾಷೆಯ ಇಂಗ್ಲಿಷ್ ಆವೃತ್ತಿಯಲ್ಲಿ) ಬಳಸಿ. 1C ಡೆವಲಪರ್‌ಗಳು ಈಗ ನಿರ್ದೇಶನಗಳು ನಿಜವೆಂದು ಹೇಳುವ ಮೂಲಕ ನನ್ನನ್ನು ಸರಿಪಡಿಸುತ್ತಾರೆ ಹೆಚ್ಚು, ಆದರೆ ನಮಗೆ ಇದು ಈಗ ಮುಖ್ಯವಲ್ಲ.

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

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್
ಬಟನ್ ಕ್ಲಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಕೋಡ್: ಕ್ಲೈಂಟ್‌ನಿಂದ ಸರ್ವರ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕರೆಯುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಸರ್ವರ್‌ನಿಂದ ಕ್ಲೈಂಟ್ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕರೆಯುವುದು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ

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

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

ಉತ್ಪಾದನೆಯೇ

ಸಂದೇಶ ಕಳುಹಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ರಚಿಸಿ. ವೇಗವಾದ, ವಿಶ್ವಾಸಾರ್ಹ, ಖಾತರಿಯ ವಿತರಣೆಯೊಂದಿಗೆ, ಸಂದೇಶಗಳನ್ನು ಸುಲಭವಾಗಿ ಹುಡುಕುವ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ. ಕಾರ್ಯವಿಧಾನದ ಆಧಾರದ ಮೇಲೆ, 1C ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸಂದೇಶವಾಹಕವನ್ನು (ಸಂದೇಶಗಳು, ವೀಡಿಯೊ ಕರೆಗಳು) ಕಾರ್ಯಗತಗೊಳಿಸಿ.

ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಡ್ಡಲಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿ. ನೋಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುವ ಮೂಲಕ ಹೆಚ್ಚುತ್ತಿರುವ ಲೋಡ್ ಅನ್ನು ಮುಚ್ಚಬೇಕು.

Реализация

SV ಯ ಸರ್ವರ್ ಭಾಗವನ್ನು ನೇರವಾಗಿ 1C: ಎಂಟರ್‌ಪ್ರೈಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ಸಂಯೋಜಿಸದಿರಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದರೆ ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನವಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು, 1C ಅಪ್ಲಿಕೇಶನ್ ಪರಿಹಾರಗಳ ಕೋಡ್‌ನಿಂದ API ಅನ್ನು ಕರೆಯಬಹುದು. ಇದನ್ನು ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ಮಾಡಲಾಗಿದೆ, ಅದರಲ್ಲಿ ಮುಖ್ಯವಾದುದೆಂದರೆ ನಾನು ವಿಭಿನ್ನ 1C ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಡುವೆ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮಾಡಲು ಬಯಸುತ್ತೇನೆ (ಉದಾಹರಣೆಗೆ, ವ್ಯಾಪಾರ ನಿರ್ವಹಣೆ ಮತ್ತು ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆ ನಡುವೆ). ವಿಭಿನ್ನ 1C ಅಪ್ಲಿಕೇಶನ್‌ಗಳು 1C ಯ ವಿಭಿನ್ನ ಆವೃತ್ತಿಗಳಲ್ಲಿ ರನ್ ಆಗಬಹುದು: ಎಂಟರ್‌ಪ್ರೈಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್, ವಿಭಿನ್ನ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇದೆ, ಇತ್ಯಾದಿ. ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, 1C ಅನುಸ್ಥಾಪನೆಗಳ "ಬದಿಯಲ್ಲಿ" ಇರುವ ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನವಾಗಿ SV ಅನ್ನು ಅಳವಡಿಸುವುದು ಸೂಕ್ತ ಪರಿಹಾರವಾಗಿದೆ.

ಆದ್ದರಿಂದ, ನಾವು SV ಅನ್ನು ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನವಾಗಿ ಮಾಡಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಸ್ಥಳೀಯ ಸ್ಥಾಪನೆ ಮತ್ತು ಸರ್ವರ್ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಓವರ್‌ಹೆಡ್ ವೆಚ್ಚಗಳನ್ನು ತಪ್ಪಿಸಲು ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ (wss://1cdialog.com) ನಾವು ಸ್ಥಾಪಿಸಿದ CB ಸರ್ವರ್ ಅನ್ನು ಸಣ್ಣ ಕಂಪನಿಗಳು ಬಳಸಬೇಕೆಂದು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ದೊಡ್ಡ ಗ್ರಾಹಕರು ತಮ್ಮ ಸೌಲಭ್ಯಗಳಲ್ಲಿ ತಮ್ಮದೇ ಆದ CB ಸರ್ವರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಸಲಹೆ ನೀಡಬಹುದು. ನಮ್ಮ ಕ್ಲೌಡ್ SaaS ಉತ್ಪನ್ನದಲ್ಲಿ ನಾವು ಇದೇ ವಿಧಾನವನ್ನು ಬಳಸಿದ್ದೇವೆ 1c ತಾಜಾ - ಕ್ಲೈಂಟ್‌ಗಳ ಸೈಟ್‌ಗಳಲ್ಲಿ ಸ್ಥಾಪನೆಗಾಗಿ ಇದನ್ನು ಸಾಮೂಹಿಕ-ಉತ್ಪಾದಿತ ಉತ್ಪನ್ನವಾಗಿ ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಸಹ ನಿಯೋಜಿಸಲಾಗಿದೆ https://1cfresh.com/.

ಅಪ್ಲಿಕೇಶನ್

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

ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ನಡುವಿನ ಸಂವಹನವು ವೆಬ್‌ಸಾಕೆಟ್ ಮೂಲಕ. ಇದು ನೈಜ-ಸಮಯದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.

ವಿತರಿಸಲಾದ ಸಂಗ್ರಹ

ನಾವು Redis, Hazelcast ಮತ್ತು Ehcache ನಡುವೆ ಆಯ್ಕೆ ಮಾಡಿದ್ದೇವೆ. ಇದು 2015. ರೆಡಿಸ್ ಇದೀಗ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿದೆ (ತುಂಬಾ ಹೊಸದು, ಭಯಾನಕ), ಬಹಳಷ್ಟು ನಿರ್ಬಂಧಗಳೊಂದಿಗೆ ಸೆಂಟಿನೆಲ್ ಇದೆ. ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೇಗೆ ಜೋಡಿಸುವುದು ಎಂದು Ehcache ಗೆ ತಿಳಿದಿಲ್ಲ (ಈ ಕಾರ್ಯವು ನಂತರ ಕಾಣಿಸಿಕೊಂಡಿತು). ನಾವು ಇದನ್ನು Hazelcast 3.4 ನೊಂದಿಗೆ ಪ್ರಯತ್ನಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.
ಹ್ಯಾಝೆಲ್ಕ್ಯಾಸ್ಟ್ ಅನ್ನು ಬಾಕ್ಸ್ನಿಂದ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಜೋಡಿಸಲಾಗಿದೆ. ಸಿಂಗಲ್ ನೋಡ್ ಮೋಡ್‌ನಲ್ಲಿ, ಇದು ತುಂಬಾ ಉಪಯುಕ್ತವಲ್ಲ ಮತ್ತು ಸಂಗ್ರಹವಾಗಿ ಮಾತ್ರ ಬಳಸಬಹುದು - ಡಿಸ್ಕ್‌ಗೆ ಡೇಟಾವನ್ನು ಹೇಗೆ ಡಂಪ್ ಮಾಡುವುದು ಎಂದು ಅದು ತಿಳಿದಿಲ್ಲ, ನೀವು ಒಂದೇ ನೋಡ್ ಅನ್ನು ಕಳೆದುಕೊಂಡರೆ, ನೀವು ಡೇಟಾವನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೀರಿ. ನಾವು ಹಲವಾರು ಹ್ಯಾಝೆಲ್‌ಕಾಸ್ಟ್‌ಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ, ಅದರ ನಡುವೆ ನಾವು ನಿರ್ಣಾಯಕ ಡೇಟಾವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡುತ್ತೇವೆ. ನಾವು ಸಂಗ್ರಹವನ್ನು ಬ್ಯಾಕಪ್ ಮಾಡುವುದಿಲ್ಲ - ನಾವು ಅದನ್ನು ಲೆಕ್ಕಿಸುವುದಿಲ್ಲ.

ನಮಗೆ, Hazelcast ಆಗಿದೆ:

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

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

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

DBMS ಆಯ್ಕೆ

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

PostgreSQL ಕ್ಲಸ್ಟರ್‌ನೊಂದಿಗೆ ಇದು ಸುಲಭವಲ್ಲ - ಇದೆ XL, XC, ಸಿಟಸ್, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಇವುಗಳು ಬಾಕ್ಸ್‌ನಿಂದ ಹೊರಗಿರುವ NoSQL ಗಳಲ್ಲ. ನಾವು NoSQL ಅನ್ನು ಮುಖ್ಯ ಸಂಗ್ರಹಣೆ ಎಂದು ಪರಿಗಣಿಸಲಿಲ್ಲ; ನಾವು ಮೊದಲು ಕೆಲಸ ಮಾಡದ Hazelcast ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ ಸಾಕು.

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

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

ನೀವು ಬಹು-ಹಿಡುವಳಿದಾರರ ಬಗ್ಗೆ ಓದಬಹುದು, ಉದಾಹರಣೆಗೆ, ವೆಬ್ಸೈಟ್ನಲ್ಲಿ ಸಿಟಸ್ ಡೇಟಾ.

SV ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಚಂದಾದಾರರ ಪರಿಕಲ್ಪನೆಗಳನ್ನು ಹೊಂದಿದೆ. ಅಪ್ಲಿಕೇಶನ್ ಎನ್ನುವುದು ಅದರ ಬಳಕೆದಾರರು ಮತ್ತು ವ್ಯವಹಾರ ಡೇಟಾದೊಂದಿಗೆ ERP ಅಥವಾ ಲೆಕ್ಕಪತ್ರ ನಿರ್ವಹಣೆಯಂತಹ ವ್ಯಾಪಾರ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿರ್ದಿಷ್ಟ ಸ್ಥಾಪನೆಯಾಗಿದೆ. ಚಂದಾದಾರರು ಸಂಸ್ಥೆ ಅಥವಾ ವ್ಯಕ್ತಿಯಾಗಿದ್ದು, ಅವರ ಪರವಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು SV ಸರ್ವರ್‌ನಲ್ಲಿ ನೋಂದಾಯಿಸಲಾಗಿದೆ. ಚಂದಾದಾರರು ಹಲವಾರು ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನೋಂದಾಯಿಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಈ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಪರಸ್ಪರ ಸಂದೇಶಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು. ಚಂದಾದಾರರು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಬಾಡಿಗೆದಾರರಾದರು. ಹಲವಾರು ಚಂದಾದಾರರಿಂದ ಸಂದೇಶಗಳನ್ನು ಒಂದು ಭೌತಿಕ ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಇರಿಸಬಹುದು; ಚಂದಾದಾರರು ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ಸೃಷ್ಟಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದಾರೆ ಎಂದು ನಾವು ನೋಡಿದರೆ, ನಾವು ಅದನ್ನು ಪ್ರತ್ಯೇಕ ಭೌತಿಕ ಡೇಟಾಬೇಸ್‌ಗೆ (ಅಥವಾ ಪ್ರತ್ಯೇಕ ಡೇಟಾಬೇಸ್ ಸರ್ವರ್) ಸರಿಸುತ್ತೇವೆ.

ಎಲ್ಲಾ ಚಂದಾದಾರರ ಡೇಟಾಬೇಸ್‌ಗಳ ಸ್ಥಳದ ಬಗ್ಗೆ ಮಾಹಿತಿಯೊಂದಿಗೆ ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿರುವ ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಅನ್ನು ನಾವು ಹೊಂದಿದ್ದೇವೆ.

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಅಡಚಣೆಯಾಗದಂತೆ ತಡೆಯಲು, ನಾವು ರೂಟಿಂಗ್ ಟೇಬಲ್ ಅನ್ನು (ಮತ್ತು ಇತರ ಆಗಾಗ್ಗೆ ಅಗತ್ಯವಿರುವ ಡೇಟಾ) ಸಂಗ್ರಹದಲ್ಲಿ ಇರಿಸುತ್ತೇವೆ.

ಚಂದಾದಾರರ ಡೇಟಾಬೇಸ್ ನಿಧಾನವಾಗಲು ಪ್ರಾರಂಭಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಒಳಗೆ ವಿಭಾಗಗಳಾಗಿ ಕತ್ತರಿಸುತ್ತೇವೆ. ನಾವು ಬಳಸುವ ಇತರ ಯೋಜನೆಗಳಲ್ಲಿ pg_pathman.

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

ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿ ಕಳೆದುಹೋದರೆ, ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಯು ಸಿಂಕ್ರೊನಸ್ ಆಗುತ್ತದೆ.
ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಕಳೆದುಹೋದರೆ, ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಯು ಮುಖ್ಯ ಡೇಟಾಬೇಸ್ ಆಗುತ್ತದೆ ಮತ್ತು ಅಸಮಕಾಲಿಕ ಪ್ರತಿಕೃತಿಯು ಸಿಂಕ್ರೊನಸ್ ಪ್ರತಿಕೃತಿಯಾಗುತ್ತದೆ.

ಹುಡುಕಾಟಕ್ಕಾಗಿ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟ

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

ಗಿಥಬ್‌ನಲ್ಲಿ ನಾವು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ ರಷ್ಯಾದ ರೂಪವಿಜ್ಞಾನ ಪ್ಲಗಿನ್ ಸ್ಥಿತಿಸ್ಥಾಪಕ ಹುಡುಕಾಟಕ್ಕಾಗಿ ಮತ್ತು ಅದನ್ನು ಬಳಸಿ. Elasticsearch ಸೂಚ್ಯಂಕದಲ್ಲಿ ನಾವು ಪದದ ಬೇರುಗಳನ್ನು (ಪ್ಲಗಿನ್ ನಿರ್ಧರಿಸುವ) ಮತ್ತು N-ಗ್ರಾಂಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಬಳಕೆದಾರರು ಹುಡುಕಲು ಪಠ್ಯವನ್ನು ನಮೂದಿಸಿದಂತೆ, ನಾವು N-ಗ್ರಾಂಗಳಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಪಠ್ಯವನ್ನು ಹುಡುಕುತ್ತೇವೆ. ಸೂಚ್ಯಂಕಕ್ಕೆ ಉಳಿಸಿದಾಗ, "ಪಠ್ಯಗಳು" ಪದವನ್ನು ಕೆಳಗಿನ N-ಗ್ರಾಂಗಳಾಗಿ ವಿಭಜಿಸಲಾಗುತ್ತದೆ:

[ಅವು, ಟೆಕ್, ಟೆಕ್ಸ್, ಪಠ್ಯ, ಪಠ್ಯಗಳು, ek, ex, ext, ಪಠ್ಯಗಳು, ks, kst, ksty, st, sty, you],

ಮತ್ತು "ಪಠ್ಯ" ಪದದ ಮೂಲವನ್ನು ಸಹ ಸಂರಕ್ಷಿಸಲಾಗುವುದು. ಈ ವಿಧಾನವು ಪದದ ಆರಂಭದಲ್ಲಿ, ಮಧ್ಯದಲ್ಲಿ ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಹುಡುಕಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ದೊಡ್ಡ ಚಿತ್ರ

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್
ಲೇಖನದ ಆರಂಭದಿಂದ ಚಿತ್ರವನ್ನು ಪುನರಾವರ್ತಿಸಿ, ಆದರೆ ವಿವರಣೆಗಳೊಂದಿಗೆ:

  • ಬ್ಯಾಲೆನ್ಸರ್ ಅಂತರ್ಜಾಲದಲ್ಲಿ ಬಹಿರಂಗ; ನಾವು nginx ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಯಾವುದಾದರೂ ಆಗಿರಬಹುದು.
  • Java ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನಗಳು Hazelcast ಮೂಲಕ ಪರಸ್ಪರ ಸಂವಹನ.
  • ನಾವು ಬಳಸುವ ವೆಬ್ ಸಾಕೆಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ನೆಟ್ಟಿ.
  • ಜಾವಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಜಾವಾ 8 ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಬಂಡಲ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಒಎಸ್ಜಿ. ಯೋಜನೆಗಳು Java 10 ಗೆ ವಲಸೆ ಮತ್ತು ಮಾಡ್ಯೂಲ್‌ಗಳಿಗೆ ಪರಿವರ್ತನೆಯನ್ನು ಒಳಗೊಂಡಿವೆ.

ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಪರೀಕ್ಷೆ

SV ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ಪರೀಕ್ಷಿಸುವ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ, ನಾವು ಬಳಸುವ ಉತ್ಪನ್ನಗಳ ಹಲವಾರು ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ನಾವು ನೋಡಿದ್ದೇವೆ.

ಲೋಡ್ ಪರೀಕ್ಷೆ ಮತ್ತು ಮೆಮೊರಿ ಸೋರಿಕೆಗಳು

ಪ್ರತಿ SV ಬಿಡುಗಡೆಯ ಬಿಡುಗಡೆಯು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಇದು ಯಾವಾಗ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ:

  • ಪರೀಕ್ಷೆಯು ಹಲವಾರು ದಿನಗಳವರೆಗೆ ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಯಾವುದೇ ಸೇವಾ ವೈಫಲ್ಯಗಳಿಲ್ಲ
  • ಪ್ರಮುಖ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯವು ಆರಾಮದಾಯಕ ಮಿತಿಯನ್ನು ಮೀರುವುದಿಲ್ಲ
  • ಹಿಂದಿನ ಆವೃತ್ತಿಗೆ ಹೋಲಿಸಿದರೆ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕ್ಷೀಣತೆಯು 10% ಕ್ಕಿಂತ ಹೆಚ್ಚಿಲ್ಲ

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

ನಾವು ಮೂರು ಸಂರಚನೆಗಳಲ್ಲಿ ಪರಸ್ಪರ ವ್ಯವಸ್ಥೆಯ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತೇವೆ:

  1. ಒತ್ತಡ ಪರೀಕ್ಷೆ
  2. ಸಂಪರ್ಕಗಳು ಮಾತ್ರ
  3. ಚಂದಾದಾರರ ನೋಂದಣಿ

ಒತ್ತಡ ಪರೀಕ್ಷೆಯ ಸಮಯದಲ್ಲಿ, ನಾವು ಹಲವಾರು ನೂರು ಎಳೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ಅವರು ನಿಲ್ಲಿಸದೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುತ್ತಾರೆ: ಸಂದೇಶಗಳನ್ನು ಬರೆಯುವುದು, ಚರ್ಚೆಗಳನ್ನು ರಚಿಸುವುದು, ಸಂದೇಶಗಳ ಪಟ್ಟಿಯನ್ನು ಸ್ವೀಕರಿಸುವುದು. ನಾವು ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗಳನ್ನು ಅನುಕರಿಸುತ್ತೇವೆ (ನನ್ನ ಓದದ ಸಂದೇಶಗಳ ಪಟ್ಟಿಯನ್ನು ಪಡೆಯಿರಿ, ಯಾರಿಗಾದರೂ ಬರೆಯಿರಿ) ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಪರಿಹಾರಗಳು (ಬೇರೆ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ರವಾನಿಸಿ, ಎಚ್ಚರಿಕೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಿ).

ಉದಾಹರಣೆಗೆ, ಒತ್ತಡ ಪರೀಕ್ಷೆಯ ಭಾಗವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

  • ಬಳಕೆದಾರ ಲಾಗ್ ಇನ್
    • ನಿಮ್ಮ ಓದದ ಚರ್ಚೆಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ
    • 50% ಸಂದೇಶಗಳನ್ನು ಓದುವ ಸಾಧ್ಯತೆಯಿದೆ
    • 50% ಸಂದೇಶ ಕಳುಹಿಸುವ ಸಾಧ್ಯತೆಯಿದೆ
    • ಮುಂದಿನ ಬಳಕೆದಾರ:
      • ಹೊಸ ಚರ್ಚೆಯನ್ನು ರಚಿಸಲು 20% ಅವಕಾಶವಿದೆ
      • ಅದರ ಯಾವುದೇ ಚರ್ಚೆಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ಆಯ್ಕೆಮಾಡುತ್ತದೆ
      • ಒಳಗೆ ಹೋಗುತ್ತದೆ
      • ಸಂದೇಶಗಳು, ಬಳಕೆದಾರರ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ
      • ಈ ಚರ್ಚೆಯಿಂದ ಯಾದೃಚ್ಛಿಕ ಬಳಕೆದಾರರನ್ನು ಉದ್ದೇಶಿಸಿ ಐದು ಸಂದೇಶಗಳನ್ನು ರಚಿಸುತ್ತದೆ
      • ಚರ್ಚೆಯನ್ನು ಬಿಡುತ್ತದೆ
      • 20 ಬಾರಿ ಪುನರಾವರ್ತಿಸುತ್ತದೆ
      • ಲಾಗ್ ಔಟ್ ಆಗುತ್ತದೆ, ಸ್ಕ್ರಿಪ್ಟ್‌ನ ಆರಂಭಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತದೆ

    • ಚಾಟ್‌ಬಾಟ್ ಸಿಸ್ಟಮ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತದೆ (ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್‌ನಿಂದ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಅನುಕರಿಸುತ್ತದೆ)
      • ಡೇಟಾ ವಿನಿಮಯಕ್ಕಾಗಿ ಹೊಸ ಚಾನಲ್ ರಚಿಸಲು 50% ಅವಕಾಶವಿದೆ (ವಿಶೇಷ ಚರ್ಚೆ)
      • 50% ರಷ್ಟು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಯಾವುದೇ ಚಾನಲ್‌ಗಳಿಗೆ ಸಂದೇಶವನ್ನು ಬರೆಯುವ ಸಾಧ್ಯತೆಯಿದೆ

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

ಚಂದಾದಾರರ ನೋಂದಣಿ ಸ್ಕ್ರಿಪ್ಟ್ ಮೊದಲ ಉಡಾವಣೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ನಾವು ಒತ್ತಡ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ಪತ್ರವ್ಯವಹಾರದ ಸಮಯದಲ್ಲಿ ಸಿಸ್ಟಮ್ ನಿಧಾನವಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತವಾಗಿತ್ತು. ಆದರೆ ಬಳಕೆದಾರರು ಬಂದರು ಮತ್ತು ಸಮಯ ಮೀರಿದ ಕಾರಣ ನೋಂದಣಿ ವಿಫಲಗೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿತು. ನೋಂದಾಯಿಸುವಾಗ ನಾವು ಬಳಸಿದ್ದೇವೆ / dev / ಯಾದೃಚ್ om ಿಕ, ಇದು ವ್ಯವಸ್ಥೆಯ ಎಂಟ್ರೊಪಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಸಾಕಷ್ಟು ಎಂಟ್ರೊಪಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸರ್ವರ್‌ಗೆ ಸಮಯವಿರಲಿಲ್ಲ ಮತ್ತು ಹೊಸ SecureRandom ಅನ್ನು ವಿನಂತಿಸಿದಾಗ, ಅದು ಹತ್ತಾರು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಸ್ಥಗಿತಗೊಂಡಿತು. ಈ ಪರಿಸ್ಥಿತಿಯಿಂದ ಹೊರಬರಲು ಹಲವು ಮಾರ್ಗಗಳಿವೆ, ಉದಾಹರಣೆಗೆ: ಕಡಿಮೆ ಸುರಕ್ಷಿತ /dev/urandom ಗೆ ಬದಲಿಸಿ, ಎಂಟ್ರೊಪಿ ಉತ್ಪಾದಿಸುವ ವಿಶೇಷ ಬೋರ್ಡ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳನ್ನು ಮುಂಚಿತವಾಗಿ ರಚಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಪೂಲ್‌ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಿ. ಪೂಲ್‌ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ತಾತ್ಕಾಲಿಕವಾಗಿ ಮುಚ್ಚಿದ್ದೇವೆ, ಆದರೆ ಅಂದಿನಿಂದ ನಾವು ಹೊಸ ಚಂದಾದಾರರನ್ನು ನೋಂದಾಯಿಸಲು ಪ್ರತ್ಯೇಕ ಪರೀಕ್ಷೆಯನ್ನು ನಡೆಸುತ್ತಿದ್ದೇವೆ.

ನಾವು ಲೋಡ್ ಜನರೇಟರ್ ಆಗಿ ಬಳಸುತ್ತೇವೆ ಜೆಮೆಟರ್. ವೆಬ್‌ಸಾಕೆಟ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು ಎಂದು ಇದಕ್ಕೆ ತಿಳಿದಿಲ್ಲ; ಇದಕ್ಕೆ ಪ್ಲಗಿನ್ ಅಗತ್ಯವಿದೆ. "jmeter websocket" ಪ್ರಶ್ನೆಗಾಗಿ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಮೊದಲನೆಯದು: BlazeMeter ನಿಂದ ಲೇಖನಗಳು, ಇದು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ Maciej Zaleski ಮೂಲಕ ಪ್ಲಗಿನ್.

ಅಲ್ಲಿಯೇ ನಾವು ಪ್ರಾರಂಭಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ.

ಗಂಭೀರ ಪರೀಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದ ತಕ್ಷಣವೇ, JMeter ಮೆಮೊರಿಯನ್ನು ಸೋರಿಕೆ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದೆ ಎಂದು ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ.

ಪ್ಲಗಿನ್ ಒಂದು ಪ್ರತ್ಯೇಕ ದೊಡ್ಡ ಕಥೆಯಾಗಿದೆ; 176 ನಕ್ಷತ್ರಗಳೊಂದಿಗೆ, ಇದು ಗಿಥಬ್‌ನಲ್ಲಿ 132 ಫೋರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. ಲೇಖಕರು ಸ್ವತಃ 2015 ರಿಂದ ಅದಕ್ಕೆ ಬದ್ಧರಾಗಿಲ್ಲ (ನಾವು ಅದನ್ನು 2015 ರಲ್ಲಿ ತೆಗೆದುಕೊಂಡಿದ್ದೇವೆ, ನಂತರ ಅದು ಅನುಮಾನಗಳನ್ನು ಹುಟ್ಟುಹಾಕಲಿಲ್ಲ), ಮೆಮೊರಿ ಸೋರಿಕೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಹಲವಾರು ಗಿಥಬ್ ಸಮಸ್ಯೆಗಳು, 7 ಮುಚ್ಚದ ಪುಲ್ ವಿನಂತಿಗಳು.
ಈ ಪ್ಲಗಿನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ಮಾಡಲು ನೀವು ನಿರ್ಧರಿಸಿದರೆ, ದಯವಿಟ್ಟು ಕೆಳಗಿನ ಚರ್ಚೆಗಳಿಗೆ ಗಮನ ಕೊಡಿ:

  1. ಬಹು-ಥ್ರೆಡ್ ಪರಿಸರದಲ್ಲಿ, ನಿಯಮಿತ ಲಿಂಕ್ಡ್‌ಲಿಸ್ಟ್ ಅನ್ನು ಬಳಸಲಾಯಿತು, ಮತ್ತು ಫಲಿತಾಂಶವು NPE ರನ್ಟೈಮ್ನಲ್ಲಿ. ConcurrentLinkedDeque ಗೆ ಬದಲಾಯಿಸುವ ಮೂಲಕ ಅಥವಾ ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಿದ ಬ್ಲಾಕ್‌ಗಳ ಮೂಲಕ ಇದನ್ನು ಪರಿಹರಿಸಬಹುದು. ನಾವು ನಮಗಾಗಿ ಮೊದಲ ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದ್ದೇವೆ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
  2. ಮೆಮೊರಿ ಸೋರಿಕೆ; ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುವಾಗ, ಸಂಪರ್ಕ ಮಾಹಿತಿಯನ್ನು ಅಳಿಸಲಾಗುವುದಿಲ್ಲ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
  3. ಸ್ಟ್ರೀಮಿಂಗ್ ಮೋಡ್‌ನಲ್ಲಿ (ಮಾದರಿಯ ಕೊನೆಯಲ್ಲಿ ವೆಬ್‌ಸಾಕೆಟ್ ಅನ್ನು ಮುಚ್ಚದಿದ್ದಾಗ, ಆದರೆ ನಂತರ ಯೋಜನೆಯಲ್ಲಿ ಬಳಸಿದಾಗ), ಪ್ರತಿಕ್ರಿಯೆ ಮಾದರಿಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

ಗಿಥಬ್‌ನಲ್ಲಿ ಇದು ಒಂದಾಗಿದೆ. ನಾವು ಏನು ಮಾಡಿದೆವು:

  1. ತೆಗೆದುಕೊಂಡಿದ್ದಾರೆ ಫೋರ್ಕ್ ಎಲಿರಾನ್ ಕೋಗನ್ (@elyrank) - ಇದು 1 ಮತ್ತು 3 ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ
  2. ಪರಿಹರಿಸಿದ ಸಮಸ್ಯೆ 2
  3. ಜೆಟ್ಟಿಯನ್ನು 9.2.14 ರಿಂದ 9.3.12 ಕ್ಕೆ ನವೀಕರಿಸಲಾಗಿದೆ
  4. ಥ್ರೆಡ್‌ಲೋಕಲ್‌ನಲ್ಲಿ ಸುತ್ತುವ ಸರಳ ದಿನಾಂಕ ಸ್ವರೂಪ; SimpleDateFormat ಥ್ರೆಡ್-ಸುರಕ್ಷಿತವಾಗಿಲ್ಲ, ಇದು ರನ್ಟೈಮ್ನಲ್ಲಿ NPE ಗೆ ಕಾರಣವಾಯಿತು
  5. ಮತ್ತೊಂದು ಮೆಮೊರಿ ಸೋರಿಕೆಯನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ (ಸಂಪರ್ಕ ಕಡಿತಗೊಂಡಾಗ ಸಂಪರ್ಕವನ್ನು ತಪ್ಪಾಗಿ ಮುಚ್ಚಲಾಗಿದೆ)

ಮತ್ತು ಇನ್ನೂ ಅದು ಹರಿಯುತ್ತದೆ!

ಸ್ಮರಣೆಯು ಒಂದು ದಿನದಲ್ಲಿ ಖಾಲಿಯಾಗಲು ಪ್ರಾರಂಭಿಸಿತು, ಆದರೆ ಎರಡು ದಿನಗಳಲ್ಲಿ. ಯಾವುದೇ ಸಮಯ ಉಳಿದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಕಡಿಮೆ ಎಳೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಆದರೆ ನಾಲ್ಕು ಏಜೆಂಟ್‌ಗಳಲ್ಲಿ. ಇದು ಕನಿಷ್ಠ ಒಂದು ವಾರದವರೆಗೆ ಸಾಕಾಗಬೇಕಿತ್ತು.

ಎರಡು ದಿನ ಕಳೆದವು...

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

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

hazelcast 3.4 ರಲ್ಲಿ, ನಕ್ಷೆ / ಮಲ್ಟಿಮ್ಯಾಪ್ (map.destroy()) ಅನ್ನು ಅಳಿಸುವಾಗ, ಮೆಮೊರಿ ಸಂಪೂರ್ಣವಾಗಿ ಮುಕ್ತವಾಗುವುದಿಲ್ಲ ಎಂದು ಅದು ಬದಲಾಯಿತು:

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

ದೋಷವನ್ನು ಈಗ 3.5 ರಲ್ಲಿ ಸರಿಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಅದು ಆಗ ಸಮಸ್ಯೆಯಾಗಿತ್ತು. ನಾವು ಡೈನಾಮಿಕ್ ಹೆಸರುಗಳೊಂದಿಗೆ ಹೊಸ ಮಲ್ಟಿಮ್ಯಾಪ್‌ಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ತರ್ಕಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಅವುಗಳನ್ನು ಅಳಿಸಿದ್ದೇವೆ. ಕೋಡ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

public void join(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap<UUID, Authentication> sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

ಕರೆ:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

ಪ್ರತಿ ಚಂದಾದಾರಿಕೆಗೆ ಮಲ್ಟಿಮ್ಯಾಪ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಅಳಿಸಲಾಗಿದೆ. ನಾವು ನಕ್ಷೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ , ಕೀಲಿಯು ಚಂದಾದಾರಿಕೆಯ ಹೆಸರಾಗಿರುತ್ತದೆ ಮತ್ತು ಮೌಲ್ಯಗಳು ಸೆಷನ್ ಗುರುತಿಸುವಿಕೆಗಳಾಗಿರುತ್ತದೆ (ಅಗತ್ಯವಿದ್ದರೆ ನೀವು ಬಳಕೆದಾರ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಪಡೆಯಬಹುದು).

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

ಚಾರ್ಟ್‌ಗಳು ಸುಧಾರಿಸಿವೆ.

ಹೇಗೆ ಮತ್ತು ಏಕೆ ನಾವು 1C ಗಾಗಿ ಹೆಚ್ಚಿನ-ಲೋಡ್ ಸ್ಕೇಲೆಬಲ್ ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ: ಎಂಟರ್‌ಪ್ರೈಸ್: ಜಾವಾ, ಪೋಸ್ಟ್‌ಗ್ರೆಎಸ್‌ಕ್ಯುಎಲ್, ಹ್ಯಾಜೆಲ್‌ಕಾಸ್ಟ್

ಲೋಡ್ ಪರೀಕ್ಷೆಯ ಬಗ್ಗೆ ನಾವು ಇನ್ನೇನು ಕಲಿತಿದ್ದೇವೆ?

  1. JSR223 ಅನ್ನು ಗ್ರೂವಿಯಲ್ಲಿ ಬರೆಯಬೇಕು ಮತ್ತು ಸಂಕಲನ ಸಂಗ್ರಹವನ್ನು ಸೇರಿಸಬೇಕು - ಇದು ಹೆಚ್ಚು ವೇಗವಾಗಿರುತ್ತದೆ. ಲಿಂಕ್.
  2. ಜೆಮೀಟರ್-ಪ್ಲಗಿನ್‌ಗಳ ಗ್ರಾಫ್‌ಗಳು ಪ್ರಮಾಣಿತ ಪದಗಳಿಗಿಂತ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸುಲಭವಾಗಿದೆ. ಲಿಂಕ್.

Hazelcast ಜೊತೆ ನಮ್ಮ ಅನುಭವದ ಬಗ್ಗೆ

Hazelcast ನಮಗೆ ಹೊಸ ಉತ್ಪನ್ನವಾಗಿದೆ, ನಾವು ಅದರೊಂದಿಗೆ 3.4.1 ಆವೃತ್ತಿಯಿಂದ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಈಗ ನಮ್ಮ ಉತ್ಪಾದನಾ ಸರ್ವರ್ ಆವೃತ್ತಿ 3.9.2 ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ (ಬರೆಯುವ ಸಮಯದಲ್ಲಿ, Hazelcast ನ ಇತ್ತೀಚಿನ ಆವೃತ್ತಿಯು 3.10 ಆಗಿದೆ).

ಐಡಿ ಉತ್ಪಾದನೆ

ನಾವು ಪೂರ್ಣಾಂಕ ಗುರುತಿಸುವಿಕೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಹೊಸ ಘಟಕಕ್ಕಾಗಿ ನಮಗೆ ಇನ್ನೊಂದು ಲಾಂಗ್ ಅಗತ್ಯವಿದೆ ಎಂದು ಊಹಿಸೋಣ. ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿನ ಅನುಕ್ರಮವು ಸೂಕ್ತವಲ್ಲ, ಕೋಷ್ಟಕಗಳು ಹಂಚಿಕೆಯಲ್ಲಿ ತೊಡಗಿಕೊಂಡಿವೆ - DB1 ನಲ್ಲಿ ಸಂದೇಶ ID = 1 ಮತ್ತು DB1 ನಲ್ಲಿ ಸಂದೇಶ ID = 2 ಇದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ, ನೀವು ಈ ID ಅನ್ನು Elasticsearch ನಲ್ಲಿ ಅಥವಾ Hazelcast ನಲ್ಲಿ ಹಾಕಲಾಗುವುದಿಲ್ಲ , ಆದರೆ ಕೆಟ್ಟ ವಿಷಯವೆಂದರೆ ನೀವು ಎರಡು ಡೇಟಾಬೇಸ್‌ಗಳಿಂದ ಡೇಟಾವನ್ನು ಒಂದಾಗಿ ಸಂಯೋಜಿಸಲು ಬಯಸಿದರೆ (ಉದಾಹರಣೆಗೆ, ಈ ಚಂದಾದಾರರಿಗೆ ಒಂದು ಡೇಟಾಬೇಸ್ ಸಾಕು ಎಂದು ನಿರ್ಧರಿಸುವುದು). ನೀವು Hazelcast ಗೆ ಹಲವಾರು AtomicLongs ಅನ್ನು ಸೇರಿಸಬಹುದು ಮತ್ತು ಕೌಂಟರ್ ಅನ್ನು ಅಲ್ಲಿ ಇರಿಸಬಹುದು, ನಂತರ ಹೊಸ ID ಯನ್ನು ಪಡೆಯುವ ಕಾರ್ಯಕ್ಷಮತೆಯು incrementAndGet ಜೊತೆಗೆ Hazelcast ಗೆ ವಿನಂತಿಯ ಸಮಯವಾಗಿರುತ್ತದೆ. ಆದರೆ Hazelcast ಹೆಚ್ಚು ಸೂಕ್ತವಾದದ್ದನ್ನು ಹೊಂದಿದೆ - FlakeIdGenerator. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವಾಗ, ಅವರಿಗೆ ID ಶ್ರೇಣಿಯನ್ನು ನೀಡಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, ಮೊದಲನೆಯದು - 1 ರಿಂದ 10 ರವರೆಗೆ, ಎರಡನೆಯದು - 000 ರಿಂದ 10 ವರೆಗೆ, ಇತ್ಯಾದಿ. ಈಗ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಿದ ಶ್ರೇಣಿಯು ಕೊನೆಗೊಳ್ಳುವವರೆಗೆ ತನ್ನದೇ ಆದ ಹೊಸ ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ನೀಡಬಹುದು. ಇದು ತ್ವರಿತವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ (ಮತ್ತು ಹ್ಯಾಝೆಲ್ಕ್ಯಾಸ್ಟ್ ಕ್ಲೈಂಟ್), ಹೊಸ ಅನುಕ್ರಮವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ - ಆದ್ದರಿಂದ ಸ್ಕಿಪ್ಗಳು, ಇತ್ಯಾದಿ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ನಿಜವಾಗಿಯೂ ID ಗಳು ಏಕೆ ಪೂರ್ಣಾಂಕಗಳಾಗಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಅವು ಅಸಮಂಜಸವಾಗಿವೆ. ನಾವು ಎಲ್ಲವನ್ನೂ ಅಳೆದು UUID ಗಳಿಗೆ ಬದಲಾಯಿಸಿದೆವು.

ಅಂದಹಾಗೆ, ಟ್ವಿಟರ್‌ನಂತೆ ಇರಲು ಬಯಸುವವರಿಗೆ, ಅಂತಹ ಸ್ನೋಕ್ಯಾಸ್ಟ್ ಲೈಬ್ರರಿ ಇದೆ - ಇದು ಹ್ಯಾಝೆಲ್‌ಕಾಸ್ಟ್‌ನ ಮೇಲಿರುವ ಸ್ನೋಫ್ಲೇಕ್‌ನ ಅನುಷ್ಠಾನವಾಗಿದೆ. ನೀವು ಅದನ್ನು ಇಲ್ಲಿ ವೀಕ್ಷಿಸಬಹುದು:

github.com/noctarius/snowcast
github.com/twitter/snowflake

ಆದರೆ ನಾವು ಇನ್ನು ಮುಂದೆ ಅದರ ಸುತ್ತಲೂ ಸಿಕ್ಕಿಲ್ಲ.

TransactionalMap.replace

ಮತ್ತೊಂದು ಅಚ್ಚರಿ: TransactionalMap.replace ಕಾರ್ಯನಿರ್ವಹಿಸುವುದಿಲ್ಲ. ಒಂದು ಪರೀಕ್ಷೆ ಇಲ್ಲಿದೆ:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }        
    });
}

Expected : newValue
Actual : oldValue

getForUpdate ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು ನನ್ನದೇ ಆದ ಬದಲಿ ಬರೆಯಬೇಕಾಗಿತ್ತು:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

ನಿಯಮಿತ ಡೇಟಾ ರಚನೆಗಳನ್ನು ಮಾತ್ರವಲ್ಲ, ಅವುಗಳ ವಹಿವಾಟಿನ ಆವೃತ್ತಿಗಳನ್ನೂ ಸಹ ಪರೀಕ್ಷಿಸಿ. IMap ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ TransactionalMap ಇನ್ನು ಮುಂದೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ.

ಅಲಭ್ಯತೆಯಿಲ್ಲದೆ ಹೊಸ JAR ಅನ್ನು ಸೇರಿಸಿ

ಮೊದಲಿಗೆ, ಹ್ಯಾಝೆಲ್ಕ್ಯಾಸ್ಟ್ನಲ್ಲಿ ನಮ್ಮ ತರಗತಿಗಳ ವಸ್ತುಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ ವರ್ಗವನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ಅದನ್ನು ಉಳಿಸಲು ಮತ್ತು ಓದಲು ಬಯಸುತ್ತೇವೆ. ಉಳಿಸಿ:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

ಚಿಟಮ್:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ. ನಂತರ ನಾವು ಹುಡುಕಲು Hazelcast ನಲ್ಲಿ ಸೂಚ್ಯಂಕವನ್ನು ನಿರ್ಮಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೇವೆ:

map.addIndex("subscriberId", false);

ಮತ್ತು ಹೊಸ ಘಟಕವನ್ನು ಬರೆಯುವಾಗ, ಅವರು ClassNotFoundException ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು. Hazelcast ಸೂಚ್ಯಂಕಕ್ಕೆ ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಿದೆ, ಆದರೆ ನಮ್ಮ ವರ್ಗದ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿರಲಿಲ್ಲ ಮತ್ತು ಈ ವರ್ಗದೊಂದಿಗೆ JAR ಅನ್ನು ಅದಕ್ಕೆ ಸರಬರಾಜು ಮಾಡಬೇಕೆಂದು ಬಯಸಿದೆ. ನಾವು ಅದನ್ನು ಮಾಡಿದ್ದೇವೆ, ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡಿದೆ, ಆದರೆ ಹೊಸ ಸಮಸ್ಯೆ ಕಾಣಿಸಿಕೊಂಡಿತು: ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿಲ್ಲಿಸದೆ JAR ಅನ್ನು ಹೇಗೆ ನವೀಕರಿಸುವುದು? ನೋಡ್-ಬೈ-ನೋಡ್ ಅಪ್‌ಡೇಟ್ ಸಮಯದಲ್ಲಿ Hazelcast ಹೊಸ JAR ಅನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಈ ಹಂತದಲ್ಲಿ ನಾವು ಸೂಚ್ಯಂಕ ಹುಡುಕಾಟವಿಲ್ಲದೆ ಬದುಕಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಎಲ್ಲಾ ನಂತರ, ನೀವು ಹ್ಯಾಝೆಲ್ಕ್ಯಾಸ್ಟ್ ಅನ್ನು ಪ್ರಮುಖ ಮೌಲ್ಯದ ಅಂಗಡಿಯಾಗಿ ಬಳಸಿದರೆ, ನಂತರ ಎಲ್ಲವೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ನಿಜವಾಗಿಯೂ ಅಲ್ಲ. ಇಲ್ಲಿ ಮತ್ತೊಮ್ಮೆ IMap ಮತ್ತು TransactionalMap ನ ನಡವಳಿಕೆಯು ವಿಭಿನ್ನವಾಗಿದೆ. IMap ಕಾಳಜಿ ವಹಿಸದಿದ್ದಲ್ಲಿ, TransactionalMap ದೋಷವನ್ನು ಎಸೆಯುತ್ತದೆ.

IMap. ನಾವು 5000 ವಸ್ತುಗಳನ್ನು ಬರೆಯುತ್ತೇವೆ, ಅವುಗಳನ್ನು ಓದಿ. ಎಲ್ಲವನ್ನೂ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ.

@Test
void get5000() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

ಆದರೆ ಇದು ವಹಿವಾಟಿನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ನಾವು ClassNotFoundException ಅನ್ನು ಪಡೆಯುತ್ತೇವೆ:

@Test
void get_transaction() {
    IMap<UUID, Application> map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 ರಲ್ಲಿ, ಬಳಕೆದಾರ ವರ್ಗ ನಿಯೋಜನೆ ಕಾರ್ಯವಿಧಾನವು ಕಾಣಿಸಿಕೊಂಡಿತು. ನೀವು ಒಂದು ಮಾಸ್ಟರ್ ನೋಡ್ ಅನ್ನು ಗೊತ್ತುಪಡಿಸಬಹುದು ಮತ್ತು ಅದರ ಮೇಲೆ JAR ಫೈಲ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು.

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

ನಾವು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ

Hazelcast ಗೆ ನಾಲ್ಕು ಟ್ರಿಪ್‌ಗಳು - ಒಳ್ಳೆಯದು, ಡೇಟಾಬೇಸ್‌ಗೆ ಎರಡು - ಕೆಟ್ಟದು

ಡೇಟಾಬೇಸ್‌ಗೆ ಹೋಗುವುದಕ್ಕಿಂತ ಡೇಟಾಕ್ಕಾಗಿ ಸಂಗ್ರಹಕ್ಕೆ ಹೋಗುವುದು ಯಾವಾಗಲೂ ಉತ್ತಮವಾಗಿರುತ್ತದೆ, ಆದರೆ ಬಳಕೆಯಾಗದ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ನೀವು ಬಯಸುವುದಿಲ್ಲ. ಅಭಿವೃದ್ಧಿಯ ಕೊನೆಯ ಹಂತದವರೆಗೆ ಯಾವುದನ್ನು ಸಂಗ್ರಹಿಸಬೇಕು ಎಂಬುದರ ಕುರಿತು ನಾವು ನಿರ್ಧಾರವನ್ನು ಬಿಡುತ್ತೇವೆ. ಹೊಸ ಕಾರ್ಯವನ್ನು ಕೋಡ್ ಮಾಡಿದಾಗ, ನಾವು PostgreSQL (log_min_duration_statement to 0) ನಲ್ಲಿ ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳ ಲಾಗಿಂಗ್ ಅನ್ನು ಆನ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು 20 ನಿಮಿಷಗಳ ಕಾಲ ಲೋಡ್ ಪರೀಕ್ಷೆಯನ್ನು ರನ್ ಮಾಡುತ್ತೇವೆ. ಸಂಗ್ರಹಿಸಿದ ಲಾಗ್‌ಗಳನ್ನು ಬಳಸಿ, pgFouine ಮತ್ತು pgBadger ನಂತಹ ಉಪಯುಕ್ತತೆಗಳು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ವರದಿಗಳನ್ನು ರಚಿಸಬಹುದು. ವರದಿಗಳಲ್ಲಿ, ನಾವು ಪ್ರಾಥಮಿಕವಾಗಿ ನಿಧಾನ ಮತ್ತು ಆಗಾಗ್ಗೆ ಪ್ರಶ್ನೆಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ. ನಿಧಾನಗತಿಯ ಪ್ರಶ್ನೆಗಳಿಗಾಗಿ, ನಾವು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಯೋಜನೆಯನ್ನು (ವಿವರಣೆ) ನಿರ್ಮಿಸುತ್ತೇವೆ ಮತ್ತು ಅಂತಹ ಪ್ರಶ್ನೆಯನ್ನು ವೇಗಗೊಳಿಸಬಹುದೇ ಎಂದು ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತೇವೆ. ಅದೇ ಇನ್‌ಪುಟ್ ಡೇಟಾಕ್ಕಾಗಿ ಪದೇ ಪದೇ ವಿನಂತಿಗಳು ಸಂಗ್ರಹಕ್ಕೆ ಚೆನ್ನಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ. ನಾವು ಪ್ರಶ್ನೆಗಳನ್ನು "ಫ್ಲಾಟ್" ಇರಿಸಿಕೊಳ್ಳಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಪ್ರತಿ ಪ್ರಶ್ನೆಗೆ ಒಂದು ಟೇಬಲ್.

ಶೋಷಣೆ

SV ಅನ್ನು ಆನ್‌ಲೈನ್ ಸೇವೆಯಾಗಿ 2017 ರ ವಸಂತಕಾಲದಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಯಿತು ಮತ್ತು ಪ್ರತ್ಯೇಕ ಉತ್ಪನ್ನವಾಗಿ, SV ಅನ್ನು ನವೆಂಬರ್ 2017 ರಲ್ಲಿ ಬಿಡುಗಡೆ ಮಾಡಲಾಯಿತು (ಆ ಸಮಯದಲ್ಲಿ ಬೀಟಾ ಆವೃತ್ತಿಯ ಸ್ಥಿತಿಯಲ್ಲಿ).

ಒಂದು ವರ್ಷಕ್ಕೂ ಹೆಚ್ಚು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ, ಸಿಬಿ ಆನ್‌ಲೈನ್ ಸೇವೆಯ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಯಾವುದೇ ಗಂಭೀರ ಸಮಸ್ಯೆಗಳಿಲ್ಲ. ನಾವು ಆನ್‌ಲೈನ್ ಸೇವೆಯ ಮೂಲಕ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಜಬ್ಬಿಕ್ಸ್, ನಿಂದ ಸಂಗ್ರಹಿಸಿ ಮತ್ತು ನಿಯೋಜಿಸಿ ಬಿದಿರು.

SV ಸರ್ವರ್ ವಿತರಣೆಯನ್ನು ಸ್ಥಳೀಯ ಪ್ಯಾಕೇಜ್‌ಗಳ ರೂಪದಲ್ಲಿ ಸರಬರಾಜು ಮಾಡಲಾಗುತ್ತದೆ: RPM, DEB, MSI. ಜೊತೆಗೆ Windows ಗಾಗಿ ನಾವು ಒಂದೇ EXE ರೂಪದಲ್ಲಿ ಒಂದೇ ಸ್ಥಾಪಕವನ್ನು ಒದಗಿಸುತ್ತೇವೆ ಅದು ಸರ್ವರ್, Hazelcast ಮತ್ತು Elasticsearch ಅನ್ನು ಒಂದು ಯಂತ್ರದಲ್ಲಿ ಸ್ಥಾಪಿಸುತ್ತದೆ. ನಾವು ಆರಂಭದಲ್ಲಿ ಅನುಸ್ಥಾಪನೆಯ ಈ ಆವೃತ್ತಿಯನ್ನು "ಡೆಮೊ" ಆವೃತ್ತಿ ಎಂದು ಉಲ್ಲೇಖಿಸಿದ್ದೇವೆ, ಆದರೆ ಇದು ಅತ್ಯಂತ ಜನಪ್ರಿಯ ನಿಯೋಜನೆ ಆಯ್ಕೆಯಾಗಿದೆ ಎಂದು ಈಗ ಸ್ಪಷ್ಟವಾಗಿದೆ.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ