ಒಂದು ಬಾರಿ ಮಾತ್ರ ಹೋಗುವ ಎಚ್ಚರಿಕೆಗಳು, ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ ಒಂದೊಂದಲ್ಲ

ನಮ್ಮ ಕಾರ್ಯಾಚರಣೆ ಎಚ್ಚರಿಕೆಗಳಲ್ಲಿ ಒಂದು — ಬಿಲ್ಡರ್‌ನ ಪ್ರಕಟಿತ ಆ್ಯಪ್‌ಗಾಗಿ "ಕಡಿಮೆ ಕ್ರೆಡಿಟ್‌ಗಳು" — ಗರಿಷ್ಠ ದಿನಕ್ಕೆ ಒಮ್ಮೆ ನಮ್ಮನ್ನು ತಲುಪಬೇಕು ಎಂದು ಉದ್ದೇಶಿಸಲ್ಪಟ್ಟಿದೆ. ಒಂದು ಮಧ್ಯಾಹ್ನ ಅದು ಐದು ಬಾರಿ ಬಂತು. ಕಾರಣ: Mythex API ಯ ಪ್ರತಿಯೊಂದು ಪ್ರತಿಯೂ ತಾನು ಈಗಾಗಲೇ ಕಳುಹಿಸಿದ ಎಚ್ಚರಿಕೆಗಳನ್ನು ತನ್ನದೇ ಮೆಮೊರಿಯಲ್ಲಿ ನೆನಪಿಟ್ಟುಕೊಂಡಿತ್ತು, ಆದ್ದರಿಂದ ಎರಡು ಸರ್ವರ್‌ಗಳು ಅದನ್ನು ಎರಡು ಬಾರಿ ಕಳುಹಿಸಿದವು, ಮತ್ತು ಪ್ರತಿಯೊಂದು ಡಿಪ್ಲಾಯ್ ಆ ಮೆಮೊರಿಯನ್ನು ಅಳಿಸಿ ಅವುಗಳಿಗೆ ಮತ್ತೆ ಕಳುಹಿಸಲು ಅವಕಾಶ ನೀಡಿತು. ಅದೇ ಮಾದರಿ ಹಿನ್ನೆಲೆ ಕೆಲಸವನ್ನು ಎರಡು ಬಾರಿ ಮಾಡುವಂತೆಯೂ ಮಾಡಿತು. ಈಗ ಎರಡೂ ಹಂಚಿಕೆಯ ಸ್ಟೋರ್ ಮೂಲಕ ಸಮನ್ವಯಗೊಳ್ಳುತ್ತವೆ, ಮತ್ತು ಆ ಸ್ಟೋರ್ ಲಭ್ಯವಿಲ್ಲದಾಗ ಎರಡೂ ಸುರಕ್ಷಿತ ಬದಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

ಲಕ್ಷಣ

Mythex ತಂಡಕ್ಕೆ ಯಾವುದಾದರೂ ಗಮನ ಬೇಕಾದಾಗ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ: ಸೇವೆ ಡೌನ್ ಆದಾಗ, ಕೆಲಸ ನಿಂತಾಗ, ಅಥವಾ ಬಿಲ್ಡರ್‌ನ ಕ್ರೆಡಿಟ್ ಬ್ಯಾಲೆನ್ಸ್ ಅವರ ಆ್ಯಪ್ ಪ್ರಕಟವಾಗಿರುವಾಗ ಕಡಿಮೆಯಾದಾಗ. ಪ್ರತಿ ಎಚ್ಚರಿಕೆಗೂ ಡಿಡ್ಡ್ಯೂಪ್ ವಿಂಡೋ ಇದೆ — ಅದರ ಅವಧಿಯಲ್ಲಿ ಅದೇ ಎಚ್ಚರಿಕೆ ಒಮ್ಮೆ ಮಾತ್ರ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ. ಕಡಿಮೆ-ಕ್ರೆಡಿಟ್ ಎಚ್ಚರಿಕೆಗೆ, ಆ ವಿಂಡೋ 24 ಗಂಟೆಗಳು.

ಒಂದು ಮಧ್ಯಾಹ್ನದಲ್ಲಿ ಅದೇ ಎಚ್ಚರಿಕೆಯ ಐದು ಪ್ರತಿಗಳು ಎಂದರೆ ವಿಂಡೋ ಹಿಡಿದಿಡುತ್ತಿಲ್ಲ ಎಂದು. ಇನ್ನಷ್ಟು ಕೆಟ್ಟದಾಗಿ, ಅವು ಸುಮಾರು 11 ನಿಮಿಷಗಳ ಅಂತರದಲ್ಲಿ ಜೋಡಿಗಳಾಗಿ ಬಂದವು.

ಇದು ಏಕೆ ಸಂಭವಿಸಿತು

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

• ಎರಡು API ರೆಪ್ಲಿಕಾಗಳು. ಪ್ರೊಡಕ್ಷನ್ ಎರಡು API ಪ್ರತಿಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದಕ್ಕೂ ತನ್ನದೇ ಕೋಷ್ಟಕವಿತ್ತು, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದೂ ಎಚ್ಚರಿಕೆಯನ್ನು ಒಮ್ಮೆ ಕಳುಹಿಸಿತು. ಅದೇ ಜೋಡಿಗಳು.
• ಡಿಪ್ಲಾಯ್‌ಗಳು. ಪ್ರತಿ ಡಿಪ್ಲಾಯ್ ಎರಡೂ ರೆಪ್ಲಿಕಾಗಳನ್ನು ಖಾಲಿ ಕೋಷ್ಟಕಗಳೊಂದಿಗೆ ಹೊಸ ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಡಿಪ್ಲಾಯ್ ನಂತರ, ಎಚ್ಚರಿಕೆ ಎಂದಿಗೂ ಕಳುಹಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂಬಂತೆ ಮತ್ತೆ ಹೋಯಿತು.

ಪ್ರತಿ ಜೋಡಿಯ ಎರಡು ಎಚ್ಚರಿಕೆಗಳ ನಡುವಿನ ~11 ನಿಮಿಷಗಳ ಅಂತರ ಆ ಎಚ್ಚರಿಕೆಯನ್ನು ಏರಿಸುವ ಕೆಲಸದಿಂದ ಬಂತು. ಆ ಕೆಲಸ ಎರಡೂ ರೆಪ್ಲಿಕಾಗಳಲ್ಲಿ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ಲಾಕ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ರೆಪ್ಲಿಕಾಗಳು ಸರದಿಯಲ್ಲಿ ಅದನ್ನು ಗೆಲ್ಲುತ್ತವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ತನ್ನ ಸರದಿ ಬಂದಾಗ ಎಚ್ಚರಿಕೆಯನ್ನು ಏರಿಸಿತು.

ಅದೇ ಕೋಡ್‌ನಲ್ಲಿ ಎರಡನೇ, ಹೆಚ್ಚು ಗುಟ್ಟಾದ ಬಗ್ ಇತ್ತು. ಕೋಷ್ಟಕ ಅನಂತವಾಗಿ ಬೆಳೆಯದಂತೆ ತಡೆಯಲು, 500 ಕೀಗಳನ್ನು ತಲುಪಿದಾಗ ಅದು ತಾನೇ ಪ್ರುನ್ ಮಾಡುತ್ತಿತ್ತು — ಅದರ ವಿಂಡೋ ಯಾವುದೇ ಇರಲಿ, 15 ನಿಮಿಷಗಳಿಗಿಂತ ಹಳೆಯದಾದ ಪ್ರತಿ ನಮೂದನ್ನು ಅಳಿಸುತ್ತಿತ್ತು. ಭಾರೀ ಲೋಡ್‌ನಲ್ಲಿ, 24 ಗಂಟೆಗಳ ಡಿಡ್ಡ್ಯೂಪ್ ಕಾಲು ಗಂಟೆ ಮಾತ್ರ ಉಳಿಯುತ್ತಿತ್ತು.

ಪರಿಹಾರ

ಪ್ರತಿ ಎಚ್ಚರಿಕೆಗೆ ಒಂದು ಹಂಚಿಕೆಯ ದಾಖಲೆ

ಯಾವುದೇ ಎಚ್ಚರಿಕೆ ಕಳುಹಿಸುವ ಮೊದಲು, API ಈಗ ಆ ಎಚ್ಚರಿಕೆಯ ಡಿಡ್ಡ್ಯೂಪ್ ಕೀಯನ್ನು Redis ನಲ್ಲಿ ಕ್ಲೈಮ್ ಮಾಡುತ್ತದೆ — ಎರಡೂ ರೆಪ್ಲಿಕಾಗಳು ಮಾತನಾಡುವ ಮತ್ತು API ಮರುಪ್ರಾರಂಭವಾದಾಗ ನಿಲ್ಲದ ಹಂಚಿಕೆಯ ಇನ್-ಮೆಮೊರಿ ಸ್ಟೋರ್. ಕ್ಲೈಮ್ ಒಂದೇ "ಈ ಕೀಯನ್ನು ಅದು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ ಮಾತ್ರ ಹೊಂದಿಸಿ, ಮತ್ತು ವಿಂಡೋ ನಂತರ ಅವಧಿ ಮುಗಿಸಿ" ಎಂಬ ಕಾರ್ಯಾಚರಣೆ. ಮೊದಲು ಕ್ಲೈಮ್ ಮಾಡಿದ ರೆಪ್ಲಿಕಾ ಎಚ್ಚರಿಕೆಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ; ಇನ್ನೊಂದು ಕೀ ತೆಗೆದುಕೊಂಡಿರುವುದನ್ನು ಕಂಡು ಸುಮ್ಮನಿರುತ್ತದೆ. ಡಿಪ್ಲಾಯ್ ನಂತರದ ಹೊಸ ಪ್ರಕ್ರಿಯೆ ಕೀ ಇನ್ನೂ ಅಲ್ಲಿರುವುದನ್ನು ಕಾಣುತ್ತದೆ.

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

ವಿಫಲವಾದಾಗ ತೆರೆದಿಡಿ, ಮುಚ್ಚಬೇಡಿ

ಅತ್ಯಂತ ಮುಖ್ಯ ನಿರ್ಧಾರ Redis ತಲುಪಲಾಗದಿದ್ದಾಗ ಏನು ಮಾಡಬೇಕು ಎಂಬುದು. ನಾವು ಎಚ್ಚರಿಕೆಯನ್ನು ಹೇಗಾದರೂ ಕಳುಹಿಸಲು ಆಯ್ಕೆ ಮಾಡಿದೆವು. Redis ಡೌನ್ ಆದರೆ, ಅಥವಾ 1.5 ಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಉತ್ತರಿಸದಿದ್ದರೆ, ಎಚ್ಚರಿಕೆ ಹೋಗುತ್ತದೆ. ನಕಲಿ ಎಚ್ಚರಿಕೆ ಒಂದು ಗದ್ದಲ. ಬಿಟ್ಟುಹೋದ ಎಚ್ಚರಿಕೆ ಎಂದರೆ ಯಾರಿಗಾದರೂ ತಿಳಿಸದಿರುವುದು.

ಅತ್ಯಂತ ಗಂಭೀರ ಎಚ್ಚರಿಕೆಗಳಾದ P0 ಅನ್ನು ಡಿಡ್ಡ್ಯೂಪ್‌ನಿಂದ ಎಂದಿಗೂ ತಡೆಹಿಡಿಯಲಾಗುವುದಿಲ್ಲ.

ಪ್ರತಿ ನಮೂದು ತನ್ನದೇ ವಿಂಡೋ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ

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

ಅದೇ ಬಗ್, ಬೇರೆಡೆ

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

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

ನಾವು ಇದನ್ನು ಹೇಗೆ ಪರೀಕ್ಷಿಸಿದೆವು

ಪರೀಕ್ಷೆಗಳು ನಿಜವಾದ ಸೆಟಪ್ ಅನ್ನು ಮಾದರಿಯಾಗಿಸುತ್ತವೆ. ಅವು ಎಚ್ಚರಿಕೆ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಎರಡು ಬಾರಿ ಲೋಡ್ ಮಾಡುತ್ತವೆ, "ಎರಡು ಪ್ರತ್ಯೇಕ ರೆಪ್ಲಿಕಾಗಳಂತೆ", ಎರಡನ್ನೂ ಒಂದು ಹಂಚಿಕೆಯ ಸ್ಟೋರ್‌ಗೆ ಸೂಚಿಸಿ, ಪ್ರತಿಯೊಂದರಿಂದ ಒಂದೇ ಎಚ್ಚರಿಕೆಯನ್ನು ಏರಿಸಿ, ನಂತರ "ಡಿಪ್ಲಾಯ್ ನಂತರ" ಎಂದು ನಿಲ್ಲುವ ಇನ್ನೊಂದು ತಾಜಾ ಪ್ರತಿಯನ್ನು ಲೋಡ್ ಮಾಡಿ ಅದನ್ನು ಮತ್ತೆ ಏರಿಸುತ್ತವೆ. ಕೇವಲ ಒಂದು ಎಚ್ಚರಿಕೆ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ. ಇತರ ಪರೀಕ್ಷೆಗಳು ಪರಿಶೀಲಿಸುತ್ತವೆ: ಬೇರೆ ಬಿಲ್ಡರ್‌ನ ಎಚ್ಚರಿಕೆ ಇನ್ನೂ ಹೋಗುತ್ತದೆ, ಎರಡೂ ರೆಪ್ಲಿಕಾಗಳಿಂದ P0 ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ಸ್ಟೋರ್ ಡೌನ್ ಆಗಿದ್ದರೂ ಅಥವಾ ಟೈಮ್‌ಔಟ್ ಮೀರಿ ನೇತಾಡಿದರೂ ಎಚ್ಚರಿಕೆ ಇನ್ನೂ ಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ. ಪ್ರುನ್ ಸರಿಪಡಿಸುವಿಕೆಗೆ ತನ್ನದೇ ಪರೀಕ್ಷೆಯಿದೆ: 24 ಗಂಟೆಗಳ ಕೀ, 20 ನಿಮಿಷಗಳ ನಂತರ ಬಂದ 600 ಇತರ ಎಚ್ಚರಿಕೆಗಳನ್ನು ಬದುಕುಳಿಯುತ್ತದೆ.

ಮರುಸಂಘಟನೆ ಜಾಬ್‌ಗಾಗಿ, ಒಂದೇ ವಿಂಡೋದಲ್ಲಿ ಎರಡು ರೆಪ್ಲಿಕಾಗಳು ಒಟ್ಟಿಗೆ ಟಿಕ್ ಮಾಡುವುದು, ಜೊತೆಗೆ ಅದೇ ವಿಂಡೋದಲ್ಲಿ ಮೂರನೇ ಟಿಕ್, ಒಂದೇ ಲಿಸ್ಟಿಂಗ್ ಉತ್ಪಾದಿಸುತ್ತದೆ.

ನಾವು ಕಲಿತದ್ದು

• ಮೆಮೊರಿಯ ಸ್ಥಿತಿ ಪ್ರಕ್ರಿಯೆಗೆ ಮಾತ್ರ ಸೇರಿದ್ದು. ಸರ್ವರ್‌ಗಳಾದ್ಯಂತ ನಿಜವಾಗಿರಬೇಕಾದ ಯಾವುದೇ ವಿಷಯ — "ಒಮ್ಮೆ ಕಳುಹಿಸಲಾಗಿದೆ", "ಒಮ್ಮೆ ಚಲಿಸಿದೆ" — ಅವು ಹಂಚಿಕೊಳ್ಳುವ ಒಂದು ಸ್ಥಳದಲ್ಲಿ ಇರಬೇಕು.
• ಡಿಪ್ಲಾಯ್‌ಗಳು ಮರುಪ್ರಾರಂಭಗಳು. ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದವರೆಗೆ ಮಾತ್ರ ಉಳಿಯುವ ಸ್ಥಿತಿ ಸಾಮಾನ್ಯ ಕೆಲಸದ ದಿನವನ್ನು ಉಳಿಸುವುದಿಲ್ಲ.
• ಯಾವ ರೀತಿ ವಿಫಲವಾಗಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ. ಎಚ್ಚರಿಕೆಗಳಿಗೆ, ಹಂಚಿಕೆಯ ಸ್ಟೋರ್ ಡೌನ್ ಆಗಿರುವುದು ಕಡಿಮೆ ಎಚ್ಚರಿಕೆಗಳಲ್ಲ, ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಗಳು ಎಂದರ್ಥ ಆಗಬೇಕು.
• ನಿದರ್ಶನವನ್ನು ಮಾತ್ರವಲ್ಲ, ಮಾದರಿಯನ್ನು ಹುಡುಕಿ. ಎಚ್ಚರಿಕೆ ಜೋರಾದ ಪ್ರಕರಣವಾಗಿತ್ತು; ಎರಡು ಪಟ್ಟು ಆದ ಮರುಸಂಘಟನೆ ಜಾಬ್ ಅದೇ ಬಗ್ ಆಗಿತ್ತು, ಮೌನವಾಗಿ ಕೆಲಸವನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತಾ.

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