ರೆಡಿಸ್ ಬಳಸಿ ಲಾಕಿಂಗ್ ಅನ್ನು ವಿತರಿಸಲಾಗಿದೆ

ಹಲೋ, ಹಬ್ರ್!

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

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

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

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

ಅನುಷ್ಠಾನ

ಅಲ್ಗಾರಿದಮ್ನ ವಿವರಣೆಗೆ ತೆರಳುವ ಮೊದಲು, ನಾವು ಸಿದ್ಧ-ಸಿದ್ಧ ಅನುಷ್ಠಾನಗಳಿಗೆ ಹಲವಾರು ಲಿಂಕ್ಗಳನ್ನು ಒದಗಿಸುತ್ತೇವೆ. ಅವುಗಳನ್ನು ಉಲ್ಲೇಖಕ್ಕಾಗಿ ಬಳಸಬಹುದು.

• ರೆಡ್ಲಾಕ್-ಆರ್ಬಿ (ರೂಬಿಗೆ ಅನುಷ್ಠಾನ). ಕೂಡ ಇದೆ ಫೋರ್ಕ್ Redlock-rb, ಇದು ವಿತರಣೆಯ ಸುಲಭಕ್ಕಾಗಿ ಪ್ಯಾಕೇಜ್ (ರತ್ನ) ಅನ್ನು ಸೇರಿಸುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕಾಗಿ ಮಾತ್ರವಲ್ಲ.
• ರೆಡ್ಲಾಕ್-ಪೈ (ಪೈಥಾನ್ ಅನುಷ್ಠಾನ).
• ಏರ್ಡ್ಲಾಕ್ (ಅಸಿನ್ಸಿಯೋ ಪೈಥಾನ್‌ಗಾಗಿ ಅನುಷ್ಠಾನ).
• ರೆಡ್ಲಾಕ್-ಪಿಎಚ್ಪಿ (PHP ಗಾಗಿ ಅನುಷ್ಠಾನ).
• PHPRedisMutex (PHP ಗಾಗಿ ಮತ್ತೊಂದು ಅನುಷ್ಠಾನ)
• cheprasov/php-redis-lock (ಬೀಗಗಳಿಗಾಗಿ PHP ಲೈಬ್ರರಿ)
• ರೆಡ್ಸಿಂಕ್ (ಗೋಗಾಗಿ ಅನುಷ್ಠಾನ).
• ರೆಡಿಸನ್ (ಜಾವಾಕ್ಕೆ ಅನುಷ್ಠಾನ).
• ರೆಡಿಸ್:: ಡಿಸ್ಟ್‌ಲಾಕ್ (ಪರ್ಲ್‌ಗಾಗಿ ಅನುಷ್ಠಾನ).
• ರೆಡ್‌ಲಾಕ್-ಸಿಪಿಪಿ (C++ ಗಾಗಿ ಅನುಷ್ಠಾನ).
• ರೆಡ್ಲಾಕ್-ಸಿಎಸ್ (C#/.NET ಗಾಗಿ ಅನುಷ್ಠಾನ).
• RedLock.net (C#/.NET ಗಾಗಿ ಅನುಷ್ಠಾನ). ಅಸಿಂಕ್ ಮತ್ತು ಲಾಕ್ ವಿಸ್ತರಣೆಗಳಿಗೆ ಬೆಂಬಲದೊಂದಿಗೆ.
• ಸ್ಕಾರ್ಲೆಟ್‌ಲಾಕ್ (ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಡೇಟಾ ಸ್ಟೋರ್‌ನೊಂದಿಗೆ C# .NET ಗಾಗಿ ಅನುಷ್ಠಾನ)
• Redlock4Net (C# .NET ಗಾಗಿ ಅನುಷ್ಠಾನ)
• ನೋಡ್-ರೆಡ್ಲಾಕ್ (NodeJS ಗಾಗಿ ಅನುಷ್ಠಾನ). ಲಾಕ್‌ಗಳನ್ನು ವಿಸ್ತರಿಸಲು ಬೆಂಬಲವನ್ನು ಒಳಗೊಂಡಿದೆ.

ಭದ್ರತೆ ಮತ್ತು ಲಭ್ಯತೆ ಖಾತರಿಗಳು

ನಾವು ನಮ್ಮ ವಿನ್ಯಾಸವನ್ನು ಕೇವಲ ಮೂರು ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ರೂಪಿಸಲಿದ್ದೇವೆ, ಅದು ವಿತರಿಸಿದ ಲಾಕಿಂಗ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲು ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಗ್ಯಾರಂಟಿಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

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

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

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

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

ನಿಸ್ಸಂಶಯವಾಗಿ, ಅಂತಹ ಮಾದರಿಯಲ್ಲಿ ಓಟದ ಸ್ಥಿತಿಯು ಸಂಭವಿಸುತ್ತದೆ:

1. ಕ್ಲೈಂಟ್ ಎ ಮಾಸ್ಟರ್ ಮೇಲೆ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ.
2. ಪ್ರಮುಖ ಪ್ರವೇಶವನ್ನು ಗುಲಾಮನಿಗೆ ವರ್ಗಾಯಿಸುವ ಮೊದಲು ಮಾಸ್ಟರ್ ವಿಫಲಗೊಳ್ಳುತ್ತಾನೆ.
3. ಅನುಯಾಯಿ ನಾಯಕನಾಗಿ ಬಡ್ತಿ ಹೊಂದುತ್ತಾನೆ.
4. A ಈಗಾಗಲೇ ಲಾಕ್ ಮಾಡಿರುವ ಅದೇ ಸಂಪನ್ಮೂಲದ ಮೇಲೆ ಕ್ಲೈಂಟ್ B ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳುತ್ತದೆ. ಭದ್ರತಾ ಉಲ್ಲಂಘನೆ!

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

ಒಂದೇ ನಿದರ್ಶನದೊಂದಿಗೆ ಸರಿಯಾದ ಅನುಷ್ಠಾನ

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

ಲಾಕ್ ಪಡೆಯಲು, ಇದನ್ನು ಮಾಡಿ:

SET resource_name my_random_value NX PX 30000

ಈ ಆಜ್ಞೆಯು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದಿದ್ದರೆ (NX ಆಯ್ಕೆ), 30000 ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳ ಮಾನ್ಯತೆಯ ಅವಧಿಯೊಂದಿಗೆ (PX ಆಯ್ಕೆ) ಮಾತ್ರ ಕೀಲಿಯನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಕೀಲಿಯನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ "myrandomvalue" ಈ ಮೌಲ್ಯವು ಎಲ್ಲಾ ಕ್ಲೈಂಟ್‌ಗಳು ಮತ್ತು ಎಲ್ಲಾ ಲಾಕ್ ವಿನಂತಿಗಳಲ್ಲಿ ಅನನ್ಯವಾಗಿರಬೇಕು.
ಮೂಲಭೂತವಾಗಿ, ಲಾಕ್ ಅನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯವನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಸ್ಕ್ರಿಪ್ಟ್ ರೆಡಿಸ್ಗೆ ಹೇಳುತ್ತದೆ: ಕೀಲಿಯು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ಮಾತ್ರ ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಅದರಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಮೌಲ್ಯವು ನಿಖರವಾಗಿ ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ಕೆಳಗಿನ ಲುವಾ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಇದನ್ನು ಸಾಧಿಸಲಾಗುತ್ತದೆ:

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕುವುದನ್ನು ತಡೆಯಲು ಇದು ಮುಖ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಬಹುದು, ನಂತರ ಕೆಲವು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಲಾಕ್ ಆಗಬಹುದು ಅದು ಮೊದಲ ಲಾಕ್‌ಗಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆ (ಆದ್ದರಿಂದ ಕೀ ಅವಧಿ ಮುಗಿಯುವ ಸಮಯವಿರುತ್ತದೆ), ಮತ್ತು ನಂತರ ಕೆಲವು ಕ್ಲೈಂಟ್ ಇರಿಸಿದ್ದ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ.
ಸರಳವಾದ DEL ಅನ್ನು ಬಳಸುವುದು ಅಸುರಕ್ಷಿತವಾಗಿದೆ ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಹೊಂದಿರುವ ಲಾಕ್ ಅನ್ನು ತೆಗೆದುಹಾಕಬಹುದು. ಇದಕ್ಕೆ ವ್ಯತಿರಿಕ್ತವಾಗಿ, ಮೇಲಿನ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬಳಸುವಾಗ, ಪ್ರತಿ ಲಾಕ್ ಅನ್ನು ಯಾದೃಚ್ಛಿಕ ಸ್ಟ್ರಿಂಗ್ನೊಂದಿಗೆ "ಸಹಿ" ಮಾಡಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದನ್ನು ಹಿಂದೆ ಇರಿಸಿದ ಕ್ಲೈಂಟ್ ಮಾತ್ರ ಅದನ್ನು ತೆಗೆದುಹಾಕಬಹುದು.

ಈ ಯಾದೃಚ್ಛಿಕ ಸ್ಟ್ರಿಂಗ್ ಏನಾಗಿರಬೇಕು? ಇದು /dev/urandom ನಿಂದ 20 ಬೈಟ್‌ಗಳಾಗಿರಬೇಕು ಎಂದು ನಾನು ಊಹಿಸುತ್ತೇನೆ, ಆದರೆ ನಿಮ್ಮ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಸಾಕಷ್ಟು ಅನನ್ಯವಾಗಿಸಲು ನೀವು ಕಡಿಮೆ ವೆಚ್ಚದ ಮಾರ್ಗಗಳನ್ನು ಕಾಣಬಹುದು. ಉದಾಹರಣೆಗೆ, RC4 ಅನ್ನು /dev/urandom ನೊಂದಿಗೆ ಸೀಡ್ ಮಾಡುವುದು ಮತ್ತು ನಂತರ ಅದರಿಂದ ಹುಸಿ-ಯಾದೃಚ್ಛಿಕ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ರಚಿಸುವುದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ. ಸರಳವಾದ ಪರಿಹಾರವು ಮೈಕ್ರೋಸೆಕೆಂಡ್ ರೆಸಲ್ಯೂಶನ್ ಮತ್ತು ಕ್ಲೈಂಟ್ ಐಡಿಯಲ್ಲಿ ಯುನಿಕ್ಸ್ ಸಮಯದ ಸಂಯೋಜನೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ; ಇದು ಸುರಕ್ಷಿತವಲ್ಲ, ಆದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಇದು ಬಹುಶಃ ಕಾರ್ಯಕ್ಕೆ ಬಿಟ್ಟದ್ದು.

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

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

ರೆಡ್‌ಲಾಕ್ ಅಲ್ಗಾರಿದಮ್

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

ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು, ಕ್ಲೈಂಟ್ ಈ ಕೆಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ:

1. ಪ್ರಸ್ತುತ ಸಮಯವನ್ನು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳಲ್ಲಿ ಪಡೆಯುತ್ತದೆ.
2. ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ಒಂದೇ ಪ್ರಮುಖ ಹೆಸರು ಮತ್ತು ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ N ನಿದರ್ಶನಗಳಲ್ಲಿ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ಅನುಕ್ರಮವಾಗಿ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಹಂತ 2 ರಲ್ಲಿ, ಕ್ಲೈಂಟ್ ಪ್ರತಿ ನಿದರ್ಶನದ ಆಧಾರದ ಮೇಲೆ ಲಾಕ್ ಅನ್ನು ಹೊಂದಿಸಿದಾಗ, ಕ್ಲೈಂಟ್ ಅದನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ವಿಳಂಬವನ್ನು ಬಳಸುತ್ತದೆ, ಅದು ಲಾಕ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಿದ ಸಮಯಕ್ಕೆ ಹೋಲಿಸಿದರೆ ಸಾಕಷ್ಟು ಕಡಿಮೆ ಇರುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಿರ್ಬಂಧಿಸುವ ಅವಧಿಯು 10 ಸೆಕೆಂಡುಗಳಾಗಿದ್ದರೆ, ವಿಳಂಬವು ~ 5-50 ಮಿಲಿಸೆಕೆಂಡುಗಳ ವ್ಯಾಪ್ತಿಯಲ್ಲಿರಬಹುದು. ವಿಫಲವಾದ ರೆಡಿಸ್ ನೋಡ್ ಅನ್ನು ತಲುಪಲು ಕ್ಲೈಂಟ್ ದೀರ್ಘಕಾಲದವರೆಗೆ ನಿರ್ಬಂಧಿಸಬಹುದಾದ ಪರಿಸ್ಥಿತಿಯನ್ನು ಇದು ನಿವಾರಿಸುತ್ತದೆ: ನಿದರ್ಶನವು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ನಾವು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಮತ್ತೊಂದು ನಿದರ್ಶನಕ್ಕೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
3. ಲಾಕ್ ತೆಗೆದುಕೊಳ್ಳಲು, ಕ್ಲೈಂಟ್ ಎಷ್ಟು ಸಮಯ ಕಳೆದಿದೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ; ಇದನ್ನು ಮಾಡಲು, ಇದು ಹಂತ 1 ರಲ್ಲಿ ಪಡೆದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ನಿಜವಾದ ಸಮಯದ ಮೌಲ್ಯದಿಂದ ಕಳೆಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ಸಾಧ್ಯವಾದರೆ ಮಾತ್ರ (ಕನಿಷ್ಠ 3), ಮತ್ತು ಅದು ತೆಗೆದುಕೊಂಡ ಒಟ್ಟು ಸಮಯ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಿ, ಲಾಕ್ ಅವಧಿಗಿಂತ ಕಡಿಮೆ, ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.
4. ಲಾಕ್ ಅನ್ನು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡರೆ, ಲಾಕ್ ಅವಧಿಯನ್ನು ಮೂಲ ಲಾಕ್ ಅವಧಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ, ಅದು ಹಂತ 3 ರಲ್ಲಿ ಲೆಕ್ಕಹಾಕಿದ ಸಮಯಕ್ಕಿಂತ ಕಡಿಮೆಯಾಗಿದೆ.
5. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ವಿಫಲವಾದರೆ (ಅದು N/2+1 ನಿದರ್ಶನಗಳನ್ನು ಲಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಅಥವಾ ಲಾಕ್ ಅವಧಿಯು ಋಣಾತ್ಮಕವಾಗಿರುತ್ತದೆ), ನಂತರ ಅದು ಎಲ್ಲಾ ನಿದರ್ಶನಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ (ಅದು ನಿರ್ಬಂಧಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಭಾವಿಸಲಾಗಿದೆ ಕೂಡ). )

ಅಲ್ಗಾರಿದಮ್ ಅಸಮಕಾಲಿಕವಾಗಿದೆಯೇ?

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

ಈ ಹಂತದಲ್ಲಿ, ನಾವು ನಮ್ಮ ಪರಸ್ಪರ ಹೊರಗಿಡುವ ನಿಯಮವನ್ನು ಹೆಚ್ಚು ಎಚ್ಚರಿಕೆಯಿಂದ ರೂಪಿಸಬೇಕು: ಲಾಕ್ ಅನ್ನು ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್ ಲಾಕ್ ಮಾನ್ಯವಾಗಿರುವ ಸಮಯದಲ್ಲಿ ನಿರ್ಗಮಿಸಿದರೆ ಮಾತ್ರ ಪರಸ್ಪರ ಹೊರಗಿಡುವಿಕೆ ಖಾತರಿಪಡಿಸುತ್ತದೆ (ಹಂತ 3 ರಲ್ಲಿ ಈ ಮೌಲ್ಯವನ್ನು ಪಡೆಯಲಾಗಿದೆ), ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಸಮಯ (ಒಟ್ಟು ಕೆಲವು ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವಿನ ಸಮಯದ ವ್ಯತ್ಯಾಸವನ್ನು ಸರಿದೂಗಿಸಲು ಮಿಲಿಸೆಕೆಂಡುಗಳು).

ಕೆಳಗಿನ ಆಸಕ್ತಿದಾಯಕ ಲೇಖನವು ಸಮಯದ ಮಧ್ಯಂತರಗಳ ಸಮನ್ವಯದ ಅಗತ್ಯವಿರುವ ಅಂತಹ ವ್ಯವಸ್ಥೆಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು ಹೇಳುತ್ತದೆ: ಗುತ್ತಿಗೆಗಳು: ವಿತರಿಸಲಾದ ಫೈಲ್ ಸಂಗ್ರಹ ಸ್ಥಿರತೆಗೆ ಸಮರ್ಥ ದೋಷ-ಸಹಿಷ್ಣು ಕಾರ್ಯವಿಧಾನ.

ವೈಫಲ್ಯದ ಮೇಲೆ ಮರುಪ್ರಯತ್ನಿಸಿ

ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ವಿಫಲವಾದಾಗ, ಅದು ಯಾದೃಚ್ಛಿಕ ವಿಳಂಬದ ನಂತರ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕು; ಏಕಕಾಲದಲ್ಲಿ ಒಂದೇ ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಬಹು ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಡಿ-ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ (ಇದು "ಸ್ಪ್ಲಿಟ್-ಮೆದುಳು" ಪರಿಸ್ಥಿತಿಗೆ ಕಾರಣವಾಗಬಹುದು, ಇದರಲ್ಲಿ ವಿಜೇತರು ಇರುವುದಿಲ್ಲ). ಹೆಚ್ಚುವರಿಯಾಗಿ, ಬಹುಪಾಲು ರೆಡಿಸ್ ನಿದರ್ಶನಗಳಲ್ಲಿ ಕ್ಲೈಂಟ್ ವೇಗವಾಗಿ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ವಿಭಜಿತ-ಮೆದುಳಿನ ಪರಿಸ್ಥಿತಿಯು ಸಂಭವಿಸುವ ವಿಂಡೋ ಕಿರಿದಾಗುತ್ತದೆ (ಮತ್ತು ಮರುಪ್ರಯತ್ನಗಳ ಅಗತ್ಯವು ಕಡಿಮೆಯಾಗಿದೆ). ಆದ್ದರಿಂದ, ಆದರ್ಶಪ್ರಾಯವಾಗಿ, ಕ್ಲೈಂಟ್ ಮಲ್ಟಿಪ್ಲೆಕ್ಸಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಏಕಕಾಲದಲ್ಲಿ N ನಿದರ್ಶನಗಳಿಗೆ SET ಆಜ್ಞೆಗಳನ್ನು ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸಬೇಕು.

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

ಲಾಕ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡಿ

ಲಾಕ್ ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವುದು ಒಂದು ಸರಳವಾದ ಕಾರ್ಯಾಚರಣೆಯಾಗಿದ್ದು, ಕ್ಲೈಂಟ್ ಒಂದು ನಿರ್ದಿಷ್ಟ ನಿದರ್ಶನವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಲಾಕ್ ಮಾಡಿರುವುದನ್ನು ಲೆಕ್ಕಿಸದೆಯೇ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುವ ಅಗತ್ಯವಿರುತ್ತದೆ.

ಭದ್ರತಾ ಪರಿಗಣನೆಗಳು

ಅಲ್ಗಾರಿದಮ್ ಸುರಕ್ಷಿತವಾಗಿದೆಯೇ? ವಿಭಿನ್ನ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಊಹಿಸಲು ಪ್ರಯತ್ನಿಸೋಣ.

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

ಹೆಚ್ಚಿನ ಕೀಗಳು ಮಾನ್ಯವಾಗಿರುವ ಸಮಯದಲ್ಲಿ, ಮತ್ತೊಂದು ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ N/2+1 SET NX ಕಾರ್ಯಾಚರಣೆಗಳು N/2+1 ಕೀಗಳು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ಯಶಸ್ವಿಯಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಒಮ್ಮೆ ಲಾಕ್ ಅನ್ನು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡ ನಂತರ, ಅದೇ ಕ್ಷಣದಲ್ಲಿ ಅದನ್ನು ಮತ್ತೆ ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳುವುದು ಅಸಾಧ್ಯ (ಇದು ಪರಸ್ಪರ ಹೊರಗಿಡುವ ಆಸ್ತಿಯನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ).
ಆದಾಗ್ಯೂ, ಒಂದೇ ಸಮಯದಲ್ಲಿ ಲಾಕ್ ಅನ್ನು ಪಡೆಯಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಬಹು ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಬಯಸುತ್ತೇವೆ.

ಕ್ಲೈಂಟ್ ಹೆಚ್ಚಿನ ನಿದರ್ಶನಗಳನ್ನು ಸುಮಾರು ಅಥವಾ ಗರಿಷ್ಠ ಲಾಕ್ ಅವಧಿಗಿಂತ ಹೆಚ್ಚು ಲಾಕ್ ಮಾಡಿದ್ದರೆ, ಅದು ಲಾಕ್ ಅನ್ನು ಅಮಾನ್ಯವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ ಮತ್ತು ನಿದರ್ಶನಗಳನ್ನು ಅನ್ಲಾಕ್ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಕ್ಲೈಂಟ್ ಮುಕ್ತಾಯ ದಿನಾಂಕಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಹೆಚ್ಚಿನ ನಿದರ್ಶನಗಳನ್ನು ನಿರ್ಬಂಧಿಸಲು ನಿರ್ವಹಿಸಿದ ಪ್ರಕರಣವನ್ನು ಮಾತ್ರ ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಮೇಲಿನ ವಾದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಸಮಯದಲ್ಲಿ MIN_VALIDITY ಯಾವುದೇ ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಮರಳಿ ಪಡೆಯಲು ಸಾಧ್ಯವಾಗಬಾರದು. ಆದ್ದರಿಂದ, ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ N/2+1 ನಿದರ್ಶನಗಳನ್ನು ಲಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ (ಇದು ಹಂತ 2 ರ ಕೊನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ) ಬಹುಮತವನ್ನು ಲಾಕ್ ಮಾಡುವ ಸಮಯವು TTL ಸಮಯಕ್ಕಿಂತ ಹೆಚ್ಚಾದಾಗ ಮಾತ್ರ ಲಾಕ್ ಅನ್ನು ಅಮಾನ್ಯಗೊಳಿಸುತ್ತದೆ.

ನೀವು ಭದ್ರತೆಯ ಔಪಚಾರಿಕ ಪುರಾವೆಯನ್ನು ಒದಗಿಸಬಹುದೇ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದೇ ರೀತಿಯ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಸೂಚಿಸಬಹುದೇ ಅಥವಾ ಮೇಲಿನ ದೋಷವನ್ನು ಕಂಡುಹಿಡಿಯಬಹುದೇ?

ಪ್ರವೇಶಿಸುವಿಕೆ ಪರಿಗಣನೆಗಳು

ಸಿಸ್ಟಮ್ ಲಭ್ಯತೆಯು ಮೂರು ಮುಖ್ಯ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ:

1. ಲಾಕ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಿ (ಕೀಗಳು ಅವಧಿ ಮುಗಿಯುತ್ತಿದ್ದಂತೆ): ಲಾಕ್‌ಗಳಿಗೆ ಬಳಸಲು ಕೀಗಳು ಅಂತಿಮವಾಗಿ ಮತ್ತೆ ಲಭ್ಯವಿರುತ್ತವೆ.
2. ಬಯಸಿದ ಲಾಕ್ ಅನ್ನು ಸ್ವಾಧೀನಪಡಿಸಿಕೊಳ್ಳದಿದ್ದಾಗ ಅಥವಾ ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಾಗ ಮತ್ತು ಕೆಲಸ ಪೂರ್ಣಗೊಂಡಾಗ ಗ್ರಾಹಕರು ಸಾಮಾನ್ಯವಾಗಿ ಲಾಕ್‌ಗಳನ್ನು ತೆಗೆದುಹಾಕುವ ಮೂಲಕ ಪರಸ್ಪರ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ; ಆದ್ದರಿಂದ ಲಾಕ್ ಅನ್ನು ಮರುಪಡೆಯಲು ಕೀಗಳ ಅವಧಿ ಮುಗಿಯುವವರೆಗೆ ನಾವು ಕಾಯಬೇಕಾಗಿಲ್ಲ.
3. ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಮರುಪ್ರಯತ್ನಿಸಬೇಕಾದಾಗ, ಹೆಚ್ಚಿನ ಲಾಕ್‌ಗಳನ್ನು ಪಡೆಯಲು ಅಗತ್ಯವಿರುವ ಅವಧಿಗಿಂತ ತುಲನಾತ್ಮಕವಾಗಿ ಹೆಚ್ಚು ಸಮಯ ಕಾಯುತ್ತದೆ. ಇದು ಸಂಪನ್ಮೂಲಗಳಿಗಾಗಿ ಸ್ಪರ್ಧಿಸುವಾಗ ಉಂಟಾಗುವ ವಿಭಜಿತ-ಮೆದುಳಿನ ಪರಿಸ್ಥಿತಿಯ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

ಆದಾಗ್ಯೂ, ನೆಟ್‌ವರ್ಕ್ ವಿಭಾಗಗಳ TTL ಗೆ ಸಮಾನವಾದ ಲಭ್ಯತೆಯ ದಂಡವಿದೆ, ಆದ್ದರಿಂದ ಪಕ್ಕದ ವಿಭಾಗಗಳಿದ್ದರೆ, ದಂಡವು ಅನಿರ್ದಿಷ್ಟವಾಗಿರಬಹುದು. ಕ್ಲೈಂಟ್ ಲಾಕ್ ಅನ್ನು ಪಡೆದುಕೊಂಡಾಗ ಮತ್ತು ಅದನ್ನು ಬಿಡುಗಡೆ ಮಾಡುವ ಮೊದಲು ಮತ್ತೊಂದು ವಿಭಾಗಕ್ಕೆ ಹರಿದುಹೋದಾಗ ಇದು ಸಂಭವಿಸುತ್ತದೆ.

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

ಕಾರ್ಯಕ್ಷಮತೆ, ವೈಫಲ್ಯ ಮತ್ತು fsync

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

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

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

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

ಆದರೆ ಪರಿಸ್ಥಿತಿಯು ಮೊದಲ ನೋಟದಲ್ಲಿ ತೋರುವುದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ. ತಾತ್ವಿಕವಾಗಿ, ಅಲ್ಗಾರಿದಮ್‌ನ ಭದ್ರತೆಯನ್ನು ಸಂರಕ್ಷಿಸಲಾಗಿದೆ ಏಕೆಂದರೆ ವೈಫಲ್ಯದ ನಂತರ ನಿದರ್ಶನವನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ, ಪ್ರಸ್ತುತ ಸಕ್ರಿಯವಾಗಿರುವ ಯಾವುದೇ ಲಾಕ್‌ನಲ್ಲಿ ಅದು ಇನ್ನು ಮುಂದೆ ಭಾಗವಹಿಸುವುದಿಲ್ಲ.

ಇದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ವೈಫಲ್ಯದ ನಂತರ ನಾವು ಬಳಸುವ ಗರಿಷ್ಠ TTL ಅನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಮೀರಿದ ಅವಧಿಗೆ ನಿದರ್ಶನವು ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಈ ರೀತಿಯಾಗಿ ನಾವು ಮುಕ್ತಾಯ ದಿನಾಂಕ ಮತ್ತು ವೈಫಲ್ಯದ ಸಮಯದಲ್ಲಿ ಸಕ್ರಿಯವಾಗಿರುವ ಎಲ್ಲಾ ಕೀಗಳ ಸ್ವಯಂಚಾಲಿತ ಬಿಡುಗಡೆಯವರೆಗೆ ಕಾಯುತ್ತೇವೆ.

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

ನಾವು ಅಲ್ಗಾರಿದಮ್ನ ಲಭ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ: ನಾವು ತಡೆಯುವಿಕೆಯನ್ನು ವಿಸ್ತರಿಸುತ್ತೇವೆ

ಕ್ಲೈಂಟ್‌ಗಳು ನಿರ್ವಹಿಸುವ ಕೆಲಸವು ಸಣ್ಣ ಹಂತಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಡೀಫಾಲ್ಟ್ ಲಾಕ್ ಅವಧಿಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಮತ್ತು ಲಾಕ್‌ಗಳನ್ನು ವಿಸ್ತರಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಿದೆ. ತಾತ್ವಿಕವಾಗಿ, ಕ್ಲೈಂಟ್ ಕಂಪ್ಯೂಟಿಂಗ್‌ನಲ್ಲಿ ನಿರತರಾಗಿದ್ದರೆ ಮತ್ತು ಲಾಕ್ ಮುಕ್ತಾಯದ ಮೌಲ್ಯವು ಅಪಾಯಕಾರಿಯಾಗಿ ಕಡಿಮೆಯಿದ್ದರೆ, ಕೀ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದರೆ ಮತ್ತು ಅದರ ಮೌಲ್ಯವು ಇನ್ನೂ ಯಾದೃಚ್ಛಿಕ ಮೌಲ್ಯವಾಗಿದ್ದರೆ ಕೀಲಿಯ TTL ಅನ್ನು ವಿಸ್ತರಿಸುವ ಎಲ್ಲಾ ನಿದರ್ಶನಗಳಿಗೆ ನೀವು Lua ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಕಳುಹಿಸಬಹುದು ಲಾಕ್ ಸ್ವಾಧೀನಪಡಿಸಿಕೊಂಡಿತು.

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

ನಿಜ, ತಾಂತ್ರಿಕವಾಗಿ ಅಲ್ಗಾರಿದಮ್ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಲಾಕ್‌ಗಳನ್ನು ಪಡೆಯಲು ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪುನರಾವರ್ತಿತ ಪ್ರಯತ್ನಗಳು ಸೀಮಿತವಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಪ್ರವೇಶ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಉಲ್ಲಂಘಿಸಲಾಗುತ್ತದೆ.

ಮೂಲ: www.habr.com