ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಮೇಲೆ ಗಮನಹರಿಸಿ ದರ ಮಿತಿ ತಂತ್ರಗಳನ್ನು ಅನ್ವೇಷಿಸಿ. ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಅದರ ಅನುಷ್ಠಾನ, ಅನುಕೂಲಗಳು, ಅನಾನುಕೂಲಗಳು ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಬಳಕೆಯ ಬಗ್ಗೆ ತಿಳಿಯಿರಿ.
ದರ ಮಿತಿ: ಟೋಕನ್ ಬಕೆಟ್ ಅನುಷ್ಠಾನದ ಒಂದು ಆಳವಾದ ನೋಟ
ಇಂದಿನ ಅಂತರ್ಸಂಪರ್ಕಿತ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಮತ್ತು ಎಪಿಐಗಳ ಸ್ಥಿರತೆ ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದು ಬಹಳ ಮುಖ್ಯ. ಬಳಕೆದಾರರು ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ಮಾಡುವ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವ ಮೂಲಕ ಈ ಗುರಿಯನ್ನು ಸಾಧಿಸಲು ದರ ಮಿತಿಯು ನಿರ್ಣಾಯಕ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ಈ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ದರ ಮಿತಿ ತಂತ್ರಗಳ ಬಗ್ಗೆ, ವಿಶೇಷವಾಗಿ ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್, ಅದರ ಅನುಷ್ಠಾನ, ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳ ಬಗ್ಗೆ ವಿಸ್ತಾರವಾದ ವಿವರಣೆಯನ್ನು ನೀಡುತ್ತದೆ.
ದರ ಮಿತಿ ಎಂದರೇನು?
ದರ ಮಿತಿ ಎನ್ನುವುದು ಒಂದು ನಿರ್ದಿಷ್ಟ ಅವಧಿಯಲ್ಲಿ ಸರ್ವರ್ ಅಥವಾ ಸೇವೆಗೆ ಕಳುಹಿಸಲಾದ ಟ್ರಾಫಿಕ್ ಪ್ರಮಾಣವನ್ನು ನಿಯಂತ್ರಿಸಲು ಬಳಸುವ ತಂತ್ರವಾಗಿದೆ. ಇದು ಅತಿಯಾದ ವಿನಂತಿಗಳಿಂದ ಸಿಸ್ಟಮ್‌ಗಳು ಕುಸಿದುಹೋಗದಂತೆ ರಕ್ಷಿಸುತ್ತದೆ, ಸೇವೆಯ ನಿರಾಕರಣೆ (DoS) ದಾಳಿಗಳು, ದುರುಪಯೋಗ ಮತ್ತು ಅನಿರೀಕ್ಷಿತ ಟ್ರಾಫಿಕ್ ಏರಿಕೆಗಳನ್ನು ತಡೆಯುತ್ತದೆ. ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ವಿಧಿಸುವ ಮೂಲಕ, ದರ ಮಿತಿಯು ನ್ಯಾಯಯುತ ಬಳಕೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ, ಒಟ್ಟಾರೆ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಮತ್ತು ಭದ್ರತೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.
ಒಂದು ಫ್ಲ್ಯಾಶ್ ಸೇಲ್ ಸಮಯದಲ್ಲಿ ಇ-ಕಾಮರ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. ದರ ಮಿತಿ ಇಲ್ಲದಿದ್ದರೆ, ಬಳಕೆದಾರರ ವಿನಂತಿಗಳಲ್ಲಿ ಹಠಾತ್ ಏರಿಕೆಯು ಸರ್ವರ್‌ಗಳನ್ನು ಮುಳುಗಿಸಬಹುದು, ಇದು ನಿಧಾನ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಅಥವಾ ಸೇವಾ ಸ್ಥಗಿತಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ದರ ಮಿತಿಯು ಒಬ್ಬ ಬಳಕೆದಾರ (ಅಥವಾ ಐಪಿ ವಿಳಾಸ) ನಿರ್ದಿಷ್ಟ ಸಮಯದ ಚೌಕಟ್ಟಿನಲ್ಲಿ ಮಾಡಬಹುದಾದ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ಇದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದರಿಂದಾಗಿ ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಸುಗಮ ಅನುಭವವನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ.
ದರ ಮಿತಿ ಏಕೆ ಮುಖ್ಯ?
ದರ ಮಿತಿಯು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ನೀಡುತ್ತದೆ, ಅವುಗಳೆಂದರೆ:
- ಸೇವೆಯ ನಿರಾಕರಣೆ (DoS) ದಾಳಿಗಳನ್ನು ತಡೆಯುವುದು: ಯಾವುದೇ ಒಂದು ಮೂಲದಿಂದ ಬರುವ ವಿನಂತಿಗಳ ದರವನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ, ದರ ಮಿತಿಯು ದುರುದ್ದೇಶಪೂರಿತ ಟ್ರಾಫಿಕ್‌ನೊಂದಿಗೆ ಸರ್ವರ್ ಅನ್ನು ಮುಳುಗಿಸುವ ಗುರಿಯನ್ನು ಹೊಂದಿರುವ DoS ದಾಳಿಗಳ ಪರಿಣಾಮವನ್ನು ತಗ್ಗಿಸುತ್ತದೆ.
- ದುರುಪಯೋಗದಿಂದ ರಕ್ಷಣೆ: ದತ್ತಾಂಶವನ್ನು ಸ್ಕ್ರೇಪ್ ಮಾಡುವುದು ಅಥವಾ ನಕಲಿ ಖಾತೆಗಳನ್ನು ರಚಿಸುವಂತಹ ಎಪಿಐಗಳು ಅಥವಾ ಸೇವೆಗಳನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದರಿಂದ ದುರುದ್ದೇಶಪೂರಿತ ನಟರನ್ನು ದರ ಮಿತಿಯು ತಡೆಯುತ್ತದೆ.
- ನ್ಯಾಯಯುತ ಬಳಕೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದು: ದರ ಮಿತಿಯು ವೈಯಕ್ತಿಕ ಬಳಕೆದಾರರು ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗಳು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಏಕಸ್ವಾಮ್ಯಗೊಳಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಾ ಬಳಕೆದಾರರಿಗೆ ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸಲು ನ್ಯಾಯಯುತ ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ.
- ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುವುದು: ವಿನಂತಿ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವ ಮೂಲಕ, ದರ ಮಿತಿಯು ಸರ್ವರ್‌ಗಳು ಓವರ್‌ಲೋಡ್ ಆಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ, ಇದು ವೇಗದ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ಉತ್ತಮ ಒಟ್ಟಾರೆ ಸಿಸ್ಟಮ್ ಕಾರ್ಯಕ್ಷಮತೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
- ವೆಚ್ಚ ನಿರ್ವಹಣೆ: ಕ್ಲೌಡ್-ಆಧಾರಿತ ಸೇವೆಗಳಿಗೆ, ದರ ಮಿತಿಯು ಅತಿಯಾದ ಬಳಕೆಯನ್ನು ತಡೆಯುವ ಮೂಲಕ ವೆಚ್ಚಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಇದು ಅನಿರೀಕ್ಷಿತ ಶುಲ್ಕಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಸಾಮಾನ್ಯ ದರ ಮಿತಿ ಅಲ್ಗಾರಿದಮ್‌ಗಳು
ದರ ಮಿತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹಲವಾರು ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸಬಹುದು. ಕೆಲವು ಸಾಮಾನ್ಯವಾದವುಗಳು:
- ಟೋಕನ್ ಬಕೆಟ್: ಈ ಅಲ್ಗಾರಿದಮ್ ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಒಂದು ಕಾಲ್ಪನಿಕ "ಬಕೆಟ್" ಅನ್ನು ಬಳಸುತ್ತದೆ. ಪ್ರತಿ ವಿನಂತಿಯು ಒಂದು ಟೋಕನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಬಕೆಟ್ ಖಾಲಿಯಾಗಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಟೋಕನ್‌ಗಳನ್ನು ನಿಗದಿತ ದರದಲ್ಲಿ ಬಕೆಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.
- ಲೀಕಿ ಬಕೆಟ್: ಟೋಕನ್ ಬಕೆಟ್‌ನಂತೆಯೇ, ಆದರೆ ವಿನಂತಿಗಳನ್ನು ಆಗಮನದ ದರವನ್ನು ಲೆಕ್ಕಿಸದೆ ಸ್ಥಿರ ದರದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ. ಹೆಚ್ಚುವರಿ ವಿನಂತಿಗಳನ್ನು ಸರದಿಯಲ್ಲಿಡಲಾಗುತ್ತದೆ ಅಥವಾ ಕೈಬಿಡಲಾಗುತ್ತದೆ.
- ಫಿಕ್ಸೆಡ್ ವಿಂಡೋ ಕೌಂಟರ್: ಈ ಅಲ್ಗಾರಿದಮ್ ಸಮಯವನ್ನು ನಿಗದಿತ ಗಾತ್ರದ ವಿಂಡೋಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿ ವಿಂಡೋದಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಎಣಿಸುತ್ತದೆ. ಮಿತಿಯನ್ನು ತಲುಪಿದ ನಂತರ, ವಿಂಡೋ ಮರುಹೊಂದಿಸುವವರೆಗೆ ನಂತರದ ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ.
- ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್: ಈ ವಿಧಾನವು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋದಲ್ಲಿ ವಿನಂತಿ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್‌ಗಳ ಲಾಗ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ವಿಂಡೋದಲ್ಲಿನ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲಾಗ್ ಆಧಾರದ ಮೇಲೆ ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ.
- ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಕೌಂಟರ್: ಉತ್ತಮ ನಿಖರತೆಗಾಗಿ ಫಿಕ್ಸೆಡ್ ವಿಂಡೋ ಮತ್ತು ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಅಂಶಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಒಂದು ಹೈಬ್ರಿಡ್ ವಿಧಾನ.
ಈ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್‌ನ ನಮ್ಯತೆ ಮತ್ತು ವ್ಯಾಪಕ ಅನ್ವಯಿಕತೆಯ ಕಾರಣದಿಂದ ಅದರ ಮೇಲೆ ಗಮನಹರಿಸುತ್ತದೆ.
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್: ಒಂದು ವಿವರವಾದ ವಿವರಣೆ
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ದರ ಮಿತಿ ತಂತ್ರವಾಗಿದ್ದು, ಇದು ಸರಳತೆ ಮತ್ತು ಪರಿಣಾಮಕಾರಿತ್ವದ ನಡುವೆ ಸಮತೋಲನವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿರುವ "ಬಕೆಟ್" ಅನ್ನು ಕಾಲ್ಪನಿಕವಾಗಿ ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಯು ಬಕೆಟ್‌ನಿಂದ ಒಂದು ಟೋಕನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಬಕೆಟ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ; ಇಲ್ಲದಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ (ಅಥವಾ ಅನುಷ್ಠಾನವನ್ನು ಅವಲಂಬಿಸಿ ಸರದಿಯಲ್ಲಿಡಲಾಗುತ್ತದೆ). ಟೋಕನ್‌ಗಳನ್ನು ನಿಗದಿತ ದರದಲ್ಲಿ ಬಕೆಟ್‌ಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಲಭ್ಯವಿರುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಮರುಪೂರಣ ಮಾಡುತ್ತದೆ.
ಪ್ರಮುಖ ಪರಿಕಲ್ಪನೆಗಳು
- ಬಕೆಟ್ ಸಾಮರ್ಥ್ಯ: ಬಕೆಟ್ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದಾದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಟೋಕನ್‌ಗಳು. ಇದು ಬರ್ಸ್ಟ್ ಸಾಮರ್ಥ್ಯವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಕೆಲವು ವಿನಂತಿಗಳನ್ನು ತ್ವರಿತ ಅನುಕ್ರಮದಲ್ಲಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
- ಮರುಪೂರಣ ದರ: ಬಕೆಟ್‌ಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸೇರಿಸುವ ದರ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಟೋಕನ್‌ಗಳಲ್ಲಿ (ಅಥವಾ ಇತರ ಸಮಯ ಘಟಕ) ಅಳೆಯಲಾಗುತ್ತದೆ. ಇದು ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದಾದ ಸರಾಸರಿ ದರವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ.
- ವಿನಂತಿ ಬಳಕೆ: ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಯು ಬಕೆಟ್‌ನಿಂದ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಟೋಕನ್‌ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರತಿ ವಿನಂತಿಯು ಒಂದು ಟೋಕನ್ ಅನ್ನು ಬಳಸುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚು ಸಂಕೀರ್ಣ ಸನ್ನಿವೇಶಗಳು ವಿವಿಧ ರೀತಿಯ ವಿನಂತಿಗಳಿಗೆ ವಿಭಿನ್ನ ಟೋಕನ್ ವೆಚ್ಚಗಳನ್ನು ನಿಯೋಜಿಸಬಹುದು.
ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ
- ಒಂದು ವಿನಂತಿ ಬಂದಾಗ, ಅಲ್ಗಾರಿದಮ್ ಬಕೆಟ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
- ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅನುಗುಣವಾದ ಸಂಖ್ಯೆಯ ಟೋಕನ್‌ಗಳನ್ನು ಬಕೆಟ್‌ನಿಂದ ತೆಗೆದುಹಾಕಲಾಗುತ್ತದೆ.
- ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿಲ್ಲದಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ "ತುಂಬಾ ಹೆಚ್ಚು ವಿನಂತಿಗಳು" ದೋಷ, HTTP 429 ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ) ಅಥವಾ ನಂತರದ ಪ್ರಕ್ರಿಯೆಗಾಗಿ ಸರದಿಯಲ್ಲಿಡಲಾಗುತ್ತದೆ.
- ವಿನಂತಿಯ ಆಗಮನದಿಂದ ಸ್ವತಂತ್ರವಾಗಿ, ಟೋಕನ್‌ಗಳನ್ನು ನಿಯತಕಾಲಿಕವಾಗಿ ನಿಗದಿತ ಮರುಪೂರಣ ದರದಲ್ಲಿ ಬಕೆಟ್‌ನ ಸಾಮರ್ಥ್ಯದವರೆಗೆ ಸೇರಿಸಲಾಗುತ್ತದೆ.
ಉದಾಹರಣೆ
10 ಟೋಕನ್‌ಗಳ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2 ಟೋಕನ್‌ಗಳ ಮರುಪೂರಣ ದರವನ್ನು ಹೊಂದಿರುವ ಟೋಕನ್ ಬಕೆಟ್ ಅನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಆರಂಭದಲ್ಲಿ, ಬಕೆಟ್ ಪೂರ್ಣವಾಗಿರುತ್ತದೆ (10 ಟೋಕನ್‌ಗಳು). ಅಲ್ಗಾರಿದಮ್ ಹೇಗೆ ವರ್ತಿಸಬಹುದು ಎಂಬುದು ಇಲ್ಲಿದೆ:
- ಸೆಕೆಂಡ್ 0: 5 ವಿನಂತಿಗಳು ಬರುತ್ತವೆ. ಬಕೆಟ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ 5 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಬಕೆಟ್ ಈಗ 5 ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ.
- ಸೆಕೆಂಡ್ 1: ಯಾವುದೇ ವಿನಂತಿಗಳು ಬರುವುದಿಲ್ಲ. ಬಕೆಟ್‌ಗೆ 2 ಟೋಕನ್‌ಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ, ಒಟ್ಟು 7 ಟೋಕನ್‌ಗಳಾಗುತ್ತವೆ.
- ಸೆಕೆಂಡ್ 2: 4 ವಿನಂತಿಗಳು ಬರುತ್ತವೆ. ಬಕೆಟ್‌ನಲ್ಲಿ ಸಾಕಷ್ಟು ಟೋಕನ್‌ಗಳಿವೆ, ಆದ್ದರಿಂದ ಎಲ್ಲಾ 4 ವಿನಂತಿಗಳನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಬಕೆಟ್ ಈಗ 3 ಟೋಕನ್‌ಗಳನ್ನು ಹೊಂದಿದೆ. 2 ಟೋಕನ್‌ಗಳನ್ನು ಸಹ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಒಟ್ಟು 5 ಟೋಕನ್‌ಗಳಾಗುತ್ತವೆ.
- ಸೆಕೆಂಡ್ 3: 8 ವಿನಂತಿಗಳು ಬರುತ್ತವೆ. ಕೇವಲ 5 ವಿನಂತಿಗಳನ್ನು ಮಾತ್ರ ಅನುಮತಿಸಬಹುದು (ಬಕೆಟ್‌ನಲ್ಲಿ 5 ಟೋಕನ್‌ಗಳಿವೆ), ಮತ್ತು ಉಳಿದ 3 ವಿನಂತಿಗಳನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಅಥವಾ ಸರದಿಯಲ್ಲಿಡಲಾಗುತ್ತದೆ. 2 ಟೋಕನ್‌ಗಳನ್ನು ಸಹ ಸೇರಿಸಲಾಗುತ್ತದೆ, ಒಟ್ಟು 2 ಟೋಕನ್‌ಗಳಾಗುತ್ತವೆ (5 ವಿನಂತಿಗಳನ್ನು ಮರುಪೂರಣ ಚಕ್ರದ ಮೊದಲು ಪೂರೈಸಿದ್ದರೆ, ಅಥವಾ ಮರುಪೂರಣವು ವಿನಂತಿಗಳನ್ನು ಪೂರೈಸುವ ಮೊದಲು ಸಂಭವಿಸಿದ್ದರೆ 7).
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ವಿವಿಧ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಅನುಷ್ಠಾನಗೊಳಿಸಬಹುದು. ಗೋಲ್ಯಾಂಗ್, ಪೈಥಾನ್ ಮತ್ತು ಜಾವಾದಲ್ಲಿನ ಉದಾಹರಣೆಗಳು ಇಲ್ಲಿವೆ:
ಗೋಲ್ಯಾಂಗ್
```go package main import ( "fmt" "sync" "time" ) // TokenBucket ಒಂದು ಟೋಕನ್ ಬಕೆಟ್ ದರ ಮಿತಿಕಾರಕವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತದೆ. type TokenBucket struct { capacity int tokens int rate time.Duration lastRefill time.Time mu sync.Mutex } // NewTokenBucket ಒಂದು ಹೊಸ TokenBucket ಅನ್ನು ರಚಿಸುತ್ತದೆ. func NewTokenBucket(capacity int, rate time.Duration) *TokenBucket { return &TokenBucket{ capacity: capacity, tokens: capacity, rate: rate, lastRefill: time.Now(), } } // Allow ಟೋಕನ್ ಲಭ್ಯತೆಯ ಆಧಾರದ ಮೇಲೆ ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. func (tb *TokenBucket) Allow() bool { tb.mu.Lock() defer tb.mu.Unlock() now := time.Now() tb.refill(now) if tb.tokens > 0 { tb.tokens-- return true } return false } // refill ಕಳೆದ ಸಮಯದ ಆಧಾರದ ಮೇಲೆ ಬಕೆಟ್‌ಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. func (tb *TokenBucket) refill(now time.Time) { elapsed := now.Sub(tb.lastRefill) newTokens := int(elapsed.Seconds() * float64(tb.capacity) / tb.rate.Seconds()) if newTokens > 0 { tb.tokens += newTokens if tb.tokens > tb.capacity { tb.tokens = tb.capacity } tb.lastRefill = now } } func main() { bucket := NewTokenBucket(10, time.Second) for i := 0; i < 15; i++ { if bucket.Allow() { fmt.Printf("ವಿನಂತಿ %d ಅನುಮತಿಸಲಾಗಿದೆ\n", i+1) } else { fmt.Printf("ವಿನಂತಿ %d ದರ ಮಿತಿಗೊಳಿಸಲಾಗಿದೆ\n", i+1) } time.Sleep(100 * time.Millisecond) } } ```
ಪೈಥಾನ್
```python import time import threading class TokenBucket: def __init__(self, capacity, refill_rate): self.capacity = capacity self.tokens = capacity self.refill_rate = refill_rate self.last_refill = time.time() self.lock = threading.Lock() def allow(self): with self.lock: self._refill() if self.tokens > 0: self.tokens -= 1 return True return False def _refill(self): now = time.time() elapsed = now - self.last_refill new_tokens = elapsed * self.refill_rate self.tokens = min(self.capacity, self.tokens + new_tokens) self.last_refill = now if __name__ == '__main__': bucket = TokenBucket(capacity=10, refill_rate=2) # 10 ಟೋಕನ್‌ಗಳು, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2 ಮರುಪೂರಣ for i in range(15): if bucket.allow(): print(f"ವಿನಂತಿ {i+1} ಅನುಮತಿಸಲಾಗಿದೆ") else: print(f"ವಿನಂತಿ {i+1} ದರ ಮಿತಿಗೊಳಿಸಲಾಗಿದೆ") time.sleep(0.1) ```
ಜಾವಾ
```java import java.util.concurrent.locks.ReentrantLock; import java.util.concurrent.TimeUnit; public class TokenBucket { private final int capacity; private double tokens; private final double refillRate; private long lastRefillTimestamp; private final ReentrantLock lock = new ReentrantLock(); public TokenBucket(int capacity, double refillRate) { this.capacity = capacity; this.tokens = capacity; this.refillRate = refillRate; this.lastRefillTimestamp = System.nanoTime(); } public boolean allow() { try { lock.lock(); refill(); if (tokens >= 1) { tokens -= 1; return true; } else { return false; } } finally { lock.unlock(); } } private void refill() { long now = System.nanoTime(); double elapsedTimeInSeconds = (double) (now - lastRefillTimestamp) / TimeUnit.NANOSECONDS.toNanos(1); double newTokens = elapsedTimeInSeconds * refillRate; tokens = Math.min(capacity, tokens + newTokens); lastRefillTimestamp = now; } public static void main(String[] args) throws InterruptedException { TokenBucket bucket = new TokenBucket(10, 2); // 10 ಟೋಕನ್‌ಗಳು, ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ 2 ಮರುಪೂರಣ for (int i = 0; i < 15; i++) { if (bucket.allow()) { System.out.println("ವಿನಂತಿ " + (i + 1) + " ಅನುಮತಿಸಲಾಗಿದೆ"); } else { System.out.println("ವಿನಂತಿ " + (i + 1) + " ದರ ಮಿತಿಗೊಳಿಸಲಾಗಿದೆ"); } TimeUnit.MILLISECONDS.sleep(100); } } } ```
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಅನುಕೂಲಗಳು
- ನಮ್ಯತೆ: ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಹೆಚ್ಚು ನಮ್ಯವಾಗಿದೆ ಮತ್ತು ವಿವಿಧ ದರ ಮಿತಿ ಸನ್ನಿವೇಶಗಳಿಗೆ ಸುಲಭವಾಗಿ ಹೊಂದಿಕೊಳ್ಳಬಹುದು. ದರ ಮಿತಿ ವರ್ತನೆಯನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ಬಕೆಟ್ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಮರುಪೂರಣ ದರವನ್ನು ಸರಿಹೊಂದಿಸಬಹುದು.
- ಬರ್ಸ್ಟ್ ನಿರ್ವಹಣೆ: ಬಕೆಟ್ ಸಾಮರ್ಥ್ಯವು ನಿರ್ದಿಷ್ಟ ಪ್ರಮಾಣದ ಬರ್ಸ್ಟ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ದರ ಮಿತಿಗೊಳಿಸದೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಇದು ಸಾಂದರ್ಭಿಕ ಟ್ರಾಫಿಕ್ ಏರಿಕೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಉಪಯುಕ್ತವಾಗಿದೆ.
- ಸರಳತೆ: ಅಲ್ಗಾರಿದಮ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ತುಲನಾತ್ಮಕವಾಗಿ ಸರಳವಾಗಿದೆ.
- ಕಾನ್ಫಿಗರ್ ಮಾಡಬಲ್ಲದು: ಇದು ಸರಾಸರಿ ವಿನಂತಿ ದರ ಮತ್ತು ಬರ್ಸ್ಟ್ ಸಾಮರ್ಥ್ಯದ ಮೇಲೆ ನಿಖರವಾದ ನಿಯಂತ್ರಣವನ್ನು ಅನುಮತಿಸುತ್ತದೆ.
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್‌ನ ಅನಾನುಕೂಲಗಳು
- ಸಂಕೀರ್ಣತೆ: ಪರಿಕಲ್ಪನೆಯಲ್ಲಿ ಸರಳವಾಗಿದ್ದರೂ, ಬಕೆಟ್ ಸ್ಥಿತಿ ಮತ್ತು ಮರುಪೂರಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಎಚ್ಚರಿಕೆಯ ಅನುಷ್ಠಾನದ ಅಗತ್ಯವಿರುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ.
- ಅಸಮ ಹಂಚಿಕೆಯ ಸಂಭಾವ್ಯತೆ: ಕೆಲವು ಸನ್ನಿವೇಶಗಳಲ್ಲಿ, ಬರ್ಸ್ಟ್ ಸಾಮರ್ಥ್ಯವು ಕಾಲಾನಂತರದಲ್ಲಿ ವಿನಂತಿಗಳ ಅಸಮ ಹಂಚಿಕೆಗೆ ಕಾರಣವಾಗಬಹುದು.
- ಕಾನ್ಫಿಗರೇಶನ್ ಓವರ್‌ಹೆಡ್: ಅತ್ಯುತ್ತಮ ಬಕೆಟ್ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಮರುಪೂರಣ ದರವನ್ನು ನಿರ್ಧರಿಸಲು ಎಚ್ಚರಿಕೆಯ ವಿಶ್ಲೇಷಣೆ ಮತ್ತು ಪ್ರಯೋಗದ ಅಗತ್ಯವಿರಬಹುದು.
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್‌ಗಾಗಿ ಬಳಕೆಯ ಪ್ರಕರಣಗಳು
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ವ್ಯಾಪಕ ಶ್ರೇಣಿಯ ದರ ಮಿತಿ ಬಳಕೆಯ ಪ್ರಕರಣಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ, ಅವುಗಳೆಂದರೆ:
- API ದರ ಮಿತಿ: ಬಳಕೆದಾರ ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗೆ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ APIಗಳನ್ನು ದುರುಪಯೋಗದಿಂದ ರಕ್ಷಿಸುವುದು ಮತ್ತು ನ್ಯಾಯಯುತ ಬಳಕೆಯನ್ನು ಖಚಿತಪಡಿಸುವುದು. ಉದಾಹರಣೆಗೆ, ಸ್ಪ್ಯಾಮ್ ಅನ್ನು ತಡೆಯಲು ಸಾಮಾಜಿಕ ಮಾಧ್ಯಮ APIಯು ಒಬ್ಬ ಬಳಕೆದಾರ ಪ್ರತಿ ಗಂಟೆಗೆ ಮಾಡಬಹುದಾದ ಪೋಸ್ಟ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸಬಹುದು.
- ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ದರ ಮಿತಿ: ಫಾರ್ಮ್‌ಗಳನ್ನು ಸಲ್ಲಿಸುವುದು ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರವೇಶಿಸುವಂತಹ ವೆಬ್ ಸರ್ವರ್‌ಗಳಿಗೆ ಬಳಕೆದಾರರು ಅತಿಯಾದ ವಿನಂತಿಗಳನ್ನು ಮಾಡುವುದನ್ನು ತಡೆಯುವುದು. ಆನ್‌ಲೈನ್ ಬ್ಯಾಂಕಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್ ಬ್ರೂಟ್-ಫೋರ್ಸ್ ದಾಳಿಗಳನ್ನು ತಡೆಯಲು ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಸುವ ಪ್ರಯತ್ನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸಬಹುದು.
- ನೆಟ್‌ವರ್ಕ್ ದರ ಮಿತಿ: ನಿರ್ದಿಷ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಅಥವಾ ಬಳಕೆದಾರರು ಬಳಸುವ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಸೀಮಿತಗೊಳಿಸುವಂತಹ ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಹರಿಯುವ ಟ್ರಾಫಿಕ್ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವುದು. ISPಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನೆಟ್‌ವರ್ಕ್ ದಟ್ಟಣೆಯನ್ನು ನಿರ್ವಹಿಸಲು ದರ ಮಿತಿಯನ್ನು ಬಳಸುತ್ತಾರೆ.
- ಸಂದೇಶ ಕ್ಯೂ ದರ ಮಿತಿ: ಸಂದೇಶ ಕ್ಯೂ ಮೂಲಕ ಸಂದೇಶಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ದರವನ್ನು ನಿಯಂತ್ರಿಸುವುದು, ಗ್ರಾಹಕರು ಮುಳುಗದಂತೆ ತಡೆಯುವುದು. ಸೇವೆಗಳು ಸಂದೇಶ ಕ್ಯೂಗಳ ಮೂಲಕ ಅಸಮಕಾಲಿಕವಾಗಿ ಸಂವಹನ ನಡೆಸುವ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳಲ್ಲಿ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ.
- ಮೈಕ್ರೋಸರ್ವಿಸ್ ದರ ಮಿತಿ: ಇತರ ಸೇವೆಗಳು ಅಥವಾ ಬಾಹ್ಯ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಅವರು ಸ್ವೀಕರಿಸುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸೀಮಿತಗೊಳಿಸುವ ಮೂಲಕ ವೈಯಕ್ತಿಕ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಳನ್ನು ಓವರ್‌ಲೋಡ್‌ನಿಂದ ರಕ್ಷಿಸುವುದು.
ವಿತರಣಾ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಟೋಕನ್ ಬಕೆಟ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು
ವಿತರಣಾ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಸ್ಥಿರತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ರೇಸ್ ಕಂಡೀಷನ್‌ಗಳನ್ನು ತಪ್ಪಿಸಲು ವಿಶೇಷ ಪರಿಗಣನೆಗಳ ಅಗತ್ಯವಿದೆ. ಇಲ್ಲಿ ಕೆಲವು ಸಾಮಾನ್ಯ ವಿಧಾನಗಳಿವೆ:
- ಕೇಂದ್ರೀಕೃತ ಟೋಕನ್ ಬಕೆಟ್: ಒಂದೇ, ಕೇಂದ್ರೀಕೃತ ಸೇವೆಯು ಎಲ್ಲಾ ಬಳಕೆದಾರರು ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಟೋಕನ್ ಬಕೆಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ವಿಧಾನವು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಸರಳವಾಗಿದೆ ಆದರೆ ಅಡಚಣೆ ಮತ್ತು ವೈಫಲ್ಯದ ಏಕೈಕ ಬಿಂದುವಾಗಬಹುದು.
- Redis ನೊಂದಿಗೆ ವಿತರಿಸಿದ ಟೋಕನ್ ಬಕೆಟ್: Redis, ಒಂದು ಇನ್-ಮೆಮೊರಿ ಡೇಟಾ ಸ್ಟೋರ್, ಟೋಕನ್ ಬಕೆಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಬಳಸಬಹುದು. Redis ಏಕಕಾಲೀನ ಪರಿಸರದಲ್ಲಿ ಬಕೆಟ್ ಸ್ಥಿತಿಯನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ನವೀಕರಿಸಲು ಬಳಸಬಹುದಾದ ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
- ಕ್ಲೈಂಟ್-ಸೈಡ್ ಟೋಕನ್ ಬಕೆಟ್: ಪ್ರತಿಯೊಬ್ಬ ಕ್ಲೈಂಟ್ ತನ್ನದೇ ಆದ ಟೋಕನ್ ಬಕೆಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತಾನೆ. ಈ ವಿಧಾನವು ಹೆಚ್ಚು ಸ್ಕೇಲೆಬಲ್ ಆಗಿದೆ ಆದರೆ ದರ ಮಿತಿಯ ಮೇಲೆ ಯಾವುದೇ ಕೇಂದ್ರೀಯ ನಿಯಂತ್ರಣವಿಲ್ಲದ ಕಾರಣ ಕಡಿಮೆ ನಿಖರವಾಗಿರಬಹುದು.
- ಹೈಬ್ರಿಡ್ ವಿಧಾನ: ಕೇಂದ್ರೀಕೃತ ಮತ್ತು ವಿತರಣಾ ವಿಧಾನಗಳ ಅಂಶಗಳನ್ನು ಸಂಯೋಜಿಸಿ. ಉದಾಹರಣೆಗೆ, ಟೋಕನ್ ಬಕೆಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ವಿತರಿಸಿದ ಕ್ಯಾಶ್ ಅನ್ನು ಬಳಸಬಹುದು, ಬಕೆಟ್‌ಗಳನ್ನು ಮರುಪೂರಣ ಮಾಡಲು ಕೇಂದ್ರೀಕೃತ ಸೇವೆಯು ಜವಾಬ್ದಾರವಾಗಿರುತ್ತದೆ.
Redis ಬಳಸುವ ಉದಾಹರಣೆ (ಕಾಲ್ಪನಿಕ)
ವಿತರಿಸಿದ ಟೋಕನ್ ಬಕೆಟ್‌ಗಾಗಿ Redis ಅನ್ನು ಬಳಸುವುದು ಟೋಕನ್ ಎಣಿಕೆಯನ್ನು ನಿರ್ವಹಿಸಲು ಅದರ ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು (`INCRBY`, `DECR`, `TTL`, `EXPIRE` ನಂತಹ) ಬಳಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಮೂಲ ಹರಿವು ಹೀಗಿರುತ್ತದೆ:
- ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಬಕೆಟ್‌ಗಾಗಿ ಪರಿಶೀಲಿಸಿ: ಬಳಕೆದಾರ/API ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಾಗಿ Redis ನಲ್ಲಿ ಕೀ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆಯೇ ಎಂದು ನೋಡಿ.
- ಅಗತ್ಯವಿದ್ದರೆ ರಚಿಸಿ: ಇಲ್ಲದಿದ್ದರೆ, ಕೀಯನ್ನು ರಚಿಸಿ, ಟೋಕನ್ ಎಣಿಕೆಯನ್ನು ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಪ್ರಾರಂಭಿಸಿ, ಮತ್ತು ಮರುಪೂರಣ ಅವಧಿಗೆ ಹೊಂದಿಸಲು ಅವಧಿಯನ್ನು (TTL) ನಿಗದಿಪಡಿಸಿ.
- ಟೋಕನ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿ: ಪರಮಾಣುವಾಗಿ ಟೋಕನ್ ಎಣಿಕೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ. ಫಲಿತಾಂಶವು >= 0 ಆಗಿದ್ದರೆ, ವಿನಂತಿಯನ್ನು ಅನುಮತಿಸಲಾಗುತ್ತದೆ.
- ಟೋಕನ್ ಖಾಲಿಯಾಗುವುದನ್ನು ನಿರ್ವಹಿಸಿ: ಫಲಿತಾಂಶವು < 0 ಆಗಿದ್ದರೆ, ಇಳಿಕೆಯನ್ನು ಹಿಮ್ಮುಖಗೊಳಿಸಿ (ಪರಮಾಣುವಾಗಿ ಹಿಂತಿರುಗಿ) ಮತ್ತು ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಿ.
- ಮರುಪೂರಣ ತರ್ಕ: ಹಿನ್ನೆಲೆ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಆವರ್ತಕ ಕಾರ್ಯವು ಬಕೆಟ್‌ಗಳನ್ನು ಮರುಪೂರಣ ಮಾಡಬಹುದು, ಸಾಮರ್ಥ್ಯದವರೆಗೆ ಟೋಕನ್‌ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ.
ವಿತರಿಸಿದ ಅನುಷ್ಠಾನಗಳಿಗಾಗಿ ಪ್ರಮುಖ ಪರಿಗಣನೆಗಳು:
- ಪರಮಾಣುತ್ವ: ಏಕಕಾಲೀನ ಪರಿಸರದಲ್ಲಿ ಟೋಕನ್ ಎಣಿಕೆಗಳನ್ನು ಸರಿಯಾಗಿ ನವೀಕರಿಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪರಮಾಣು ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸಿ.
- ಸ್ಥಿರತೆ: ವಿತರಿಸಿದ ವ್ಯವಸ್ಥೆಯಲ್ಲಿನ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಟೋಕನ್ ಎಣಿಕೆಗಳು ಸ್ಥಿರವಾಗಿವೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
- ದೋಷ ಸಹಿಷ್ಣುತೆ: ಕೆಲವು ನೋಡ್‌ಗಳು ವಿಫಲವಾದರೂ ಸಹ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸಲು ವ್ಯವಸ್ಥೆಯನ್ನು ದೋಷ-ಸಹಿಷ್ಣುವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಿ.
- ಸ್ಕೇಲೆಬಿಲಿಟಿ: ಪರಿಹಾರವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರು ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಸ್ಕೇಲ್ ಆಗಬೇಕು.
- ಮೇಲ್ವಿಚಾರಣೆ: ದರ ಮಿತಿಯ ಪರಿಣಾಮಕಾರಿತ್ವವನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳನ್ನು ಗುರುತಿಸಲು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ.
ಟೋಕನ್ ಬಕೆಟ್‌ಗೆ ಪರ್ಯಾಯಗಳು
ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಜನಪ್ರಿಯ ಆಯ್ಕೆಯಾಗಿದ್ದರೂ, ನಿರ್ದಿಷ್ಟ ಅವಶ್ಯಕತೆಗಳನ್ನು ಅವಲಂಬಿಸಿ ಇತರ ದರ-ಮಿತಿ ತಂತ್ರಗಳು ಹೆಚ್ಚು ಸೂಕ್ತವಾಗಿರಬಹುದು. ಕೆಲವು ಪರ್ಯಾಯಗಳೊಂದಿಗೆ ಹೋಲಿಕೆ ಇಲ್ಲಿದೆ:
- ಲೀಕಿ ಬಕೆಟ್: ಟೋಕನ್ ಬಕೆಟ್‌ಗಿಂತ ಸರಳ. ಇದು ಸ್ಥಿರ ದರದಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ. ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸುಗಮಗೊಳಿಸಲು ಒಳ್ಳೆಯದು ಆದರೆ ಬರ್ಸ್ಟ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವಲ್ಲಿ ಟೋಕನ್ ಬಕೆಟ್‌ಗಿಂತ ಕಡಿಮೆ ನಮ್ಯವಾಗಿರುತ್ತದೆ.
- ಫಿಕ್ಸೆಡ್ ವಿಂಡೋ ಕೌಂಟರ್: ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸುಲಭ, ಆದರೆ ವಿಂಡೋ ಗಡಿಗಳಲ್ಲಿ ದರ ಮಿತಿಯ ಎರಡು ಪಟ್ಟು ಅನುಮತಿಸಬಹುದು. ಟೋಕನ್ ಬಕೆಟ್‌ಗಿಂತ ಕಡಿಮೆ ನಿಖರ.
- ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್: ನಿಖರ, ಆದರೆ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಲಾಗ್ ಮಾಡುವುದರಿಂದ ಹೆಚ್ಚು ಮೆಮೊರಿ-ತೀವ್ರವಾಗಿರುತ್ತದೆ. ನಿಖರತೆ ಅತ್ಯಗತ್ಯವಾಗಿರುವ ಸನ್ನಿವೇಶಗಳಿಗೆ ಸೂಕ್ತವಾಗಿದೆ.
- ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಕೌಂಟರ್: ನಿಖರತೆ ಮತ್ತು ಮೆಮೊರಿ ಬಳಕೆಯ ನಡುವಿನ ರಾಜಿ. ಸ್ಲೈಡಿಂಗ್ ವಿಂಡೋ ಲಾಗ್‌ಗಿಂತ ಕಡಿಮೆ ಮೆಮೊರಿ ಓವರ್‌ಹೆಡ್‌ನೊಂದಿಗೆ ಫಿಕ್ಸೆಡ್ ವಿಂಡೋ ಕೌಂಟರ್‌ಗಿಂತ ಉತ್ತಮ ನಿಖರತೆಯನ್ನು ನೀಡುತ್ತದೆ.
ಸರಿಯಾದ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಆರಿಸುವುದು:
ಅತ್ಯುತ್ತಮ ದರ-ಮಿತಿ ಅಲ್ಗಾರಿದಮ್‌ನ ಆಯ್ಕೆಯು ಈ ಕೆಳಗಿನ ಅಂಶಗಳನ್ನು ಅವಲಂಬಿಸಿರುತ್ತದೆ:
- ನಿಖರತೆಯ ಅವಶ್ಯಕತೆಗಳು: ದರ ಮಿತಿಯನ್ನು ಎಷ್ಟು ನಿಖರವಾಗಿ ಜಾರಿಗೊಳಿಸಬೇಕು?
- ಬರ್ಸ್ಟ್ ನಿರ್ವಹಣೆ ಅಗತ್ಯಗಳು: ಸಂಕ್ಷಿಪ್ತ ಟ್ರಾಫಿಕ್ ಬರ್ಸ್ಟ್‌ಗಳನ್ನು ಅನುಮತಿಸುವುದು ಅಗತ್ಯವೇ?
- ಮೆಮೊರಿ ನಿರ್ಬಂಧಗಳು: ದರ-ಮಿತಿ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಎಷ್ಟು ಮೆಮೊರಿಯನ್ನು ಹಂಚಬಹುದು?
- ಅನುಷ್ಠಾನದ ಸಂಕೀರ್ಣತೆ: ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಎಷ್ಟು ಸುಲಭ?
- ಸ್ಕೇಲೆಬಿಲಿಟಿ ಅವಶ್ಯಕತೆಗಳು: ಅಲ್ಗಾರಿದಮ್ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಬಳಕೆದಾರರು ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಎಷ್ಟು ಚೆನ್ನಾಗಿ ಸ್ಕೇಲ್ ಆಗುತ್ತದೆ?
ದರ ಮಿತಿಗಾಗಿ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು
ದರ ಮಿತಿಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಲು ಎಚ್ಚರಿಕೆಯ ಯೋಜನೆ ಮತ್ತು ಪರಿಗಣನೆಯ ಅಗತ್ಯವಿದೆ. ಅನುಸರಿಸಬೇಕಾದ ಕೆಲವು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು ಇಲ್ಲಿವೆ:
- ದರ ಮಿತಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ: ಸರ್ವರ್‌ನ ಸಾಮರ್ಥ್ಯ, ನಿರೀಕ್ಷಿತ ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ಅಗತ್ಯಗಳ ಆಧಾರದ ಮೇಲೆ ಸೂಕ್ತ ದರ ಮಿತಿಗಳನ್ನು ನಿರ್ಧರಿಸಿ.
- ಸ್ಪಷ್ಟ ದೋಷ ಸಂದೇಶಗಳನ್ನು ಒದಗಿಸಿ: ಒಂದು ವಿನಂತಿಯು ದರ-ಮಿತಿಗೊಳಪಟ್ಟಾಗ, ಬಳಕೆದಾರರಿಗೆ ಸ್ಪಷ್ಟ ಮತ್ತು ಮಾಹಿತಿಯುಕ್ತ ದೋಷ ಸಂದೇಶವನ್ನು ಹಿಂತಿರುಗಿಸಿ, ದರ ಮಿತಿಯ ಕಾರಣ ಮತ್ತು ಅವರು ಯಾವಾಗ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬಹುದು ಎಂಬುದನ್ನು ಒಳಗೊಂಡಂತೆ (ಉದಾಹರಣೆಗೆ, `Retry-After` HTTP ಹೆಡರ್ ಬಳಸಿ).
- ಪ್ರಮಾಣಿತ HTTP ಸ್ಥಿತಿ ಕೋಡ್‌ಗಳನ್ನು ಬಳಸಿ: ದರ ಮಿತಿಯನ್ನು ಸೂಚಿಸಲು ಸೂಕ್ತವಾದ HTTP ಸ್ಥಿತಿ ಕೋಡ್‌ಗಳನ್ನು ಬಳಸಿ, ಉದಾಹರಣೆಗೆ 429 (ತುಂಬಾ ಹೆಚ್ಚು ವಿನಂತಿಗಳು).
- ಸುಲಲಿತ ಅವನತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ: ವಿನಂತಿಗಳನ್ನು ಸರಳವಾಗಿ ತಿರಸ್ಕರಿಸುವ ಬದಲು, ಸುಲಲಿತ ಅವನತಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದನ್ನು ಪರಿಗಣಿಸಿ, ಉದಾಹರಣೆಗೆ ಸೇವೆಯ ಗುಣಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಅಥವಾ ಪ್ರಕ್ರಿಯೆಯನ್ನು ವಿಳಂಬಗೊಳಿಸುವುದು.
- ದರ ಮಿತಿ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿ: ದರ ಮಿತಿಯು ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ ಮತ್ತು ಅನಪೇಕ್ಷಿತ ಪರಿಣಾಮಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ದರ-ಮಿತಿಗೊಳಪಟ್ಟ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆ, ಸರಾಸರಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯ ಮತ್ತು ಇತರ ಸಂಬಂಧಿತ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಿ.
- ದರ ಮಿತಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದಂತೆ ಮಾಡಿ: ಬದಲಾಗುತ್ತಿರುವ ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳು ಮತ್ತು ಸಿಸ್ಟಮ್ ಸಾಮರ್ಥ್ಯದ ಆಧಾರದ ಮೇಲೆ ದರ ಮಿತಿಗಳನ್ನು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸರಿಹೊಂದಿಸಲು ನಿರ್ವಾಹಕರಿಗೆ ಅನುಮತಿಸಿ.
- ದರ ಮಿತಿಗಳನ್ನು ದಾಖಲಿಸಿ: API ದಸ್ತಾವೇಜಿನಲ್ಲಿ ದರ ಮಿತಿಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ದಾಖಲಿಸಿ ಇದರಿಂದ ಡೆವಲಪರ್‌ಗಳಿಗೆ ಮಿತಿಗಳ ಬಗ್ಗೆ ತಿಳಿದಿರುತ್ತದೆ ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ತಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಬಹುದು.
- ಹೊಂದಾಣಿಕೆಯ ದರ ಮಿತಿಯನ್ನು ಬಳಸಿ: ಪ್ರಸ್ತುತ ಸಿಸ್ಟಮ್ ಲೋಡ್ ಮತ್ತು ಟ್ರಾಫಿಕ್ ಮಾದರಿಗಳ ಆಧಾರದ ಮೇಲೆ ದರ ಮಿತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸರಿಹೊಂದಿಸುವ ಹೊಂದಾಣಿಕೆಯ ದರ ಮಿತಿಯನ್ನು ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.
- ದರ ಮಿತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ: ವಿವಿಧ ರೀತಿಯ ಬಳಕೆದಾರರು ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ವಿಭಿನ್ನ ದರ ಮಿತಿಗಳನ್ನು ಅನ್ವಯಿಸಿ. ಉದಾಹರಣೆಗೆ, ದೃಢೀಕರಿಸಿದ ಬಳಕೆದಾರರು ಅನಾಮಧೇಯ ಬಳಕೆದಾರರಿಗಿಂತ ಹೆಚ್ಚಿನ ದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಅಂತೆಯೇ, ವಿಭಿನ್ನ API ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳು ವಿಭಿನ್ನ ದರ ಮಿತಿಗಳನ್ನು ಹೊಂದಿರಬಹುದು.
- ಪ್ರಾದೇಶಿಕ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪರಿಗಣಿಸಿ: ನೆಟ್‌ವರ್ಕ್ ಪರಿಸ್ಥಿತಿಗಳು ಮತ್ತು ಬಳಕೆದಾರರ ನಡವಳಿಕೆಯು ವಿವಿಧ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ ಬದಲಾಗಬಹುದು ಎಂದು ತಿಳಿದಿರಲಿ. ಸೂಕ್ತವಾದಲ್ಲಿ ದರ ಮಿತಿಗಳನ್ನು ಅದಕ್ಕೆ ತಕ್ಕಂತೆ ಹೊಂದಿಸಿ.
ತೀರ್ಮಾನ
ಸ್ಥಿತಿಸ್ಥಾಪಕ ಮತ್ತು ಸ್ಕೇಲೆಬಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ದರ ಮಿತಿಯು ಅತ್ಯಗತ್ಯ ತಂತ್ರವಾಗಿದೆ. ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್ ಬಳಕೆದಾರರು ಅಥವಾ ಕ್ಲೈಂಟ್‌ಗಳು ವಿನಂತಿಗಳನ್ನು ಮಾಡುವ ದರವನ್ನು ನಿಯಂತ್ರಿಸಲು ಒಂದು ನಮ್ಯ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುತ್ತದೆ, ವ್ಯವಸ್ಥೆಗಳನ್ನು ದುರುಪಯೋಗದಿಂದ ರಕ್ಷಿಸುತ್ತದೆ, ನ್ಯಾಯಯುತ ಬಳಕೆಯನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಒಟ್ಟಾರೆ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ. ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್‌ನ ತತ್ವಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಮೂಲಕ ಮತ್ತು ಅನುಷ್ಠಾನಕ್ಕಾಗಿ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸುವ ಮೂಲಕ, ಡೆವಲಪರ್‌ಗಳು ಅತ್ಯಂತ ಬೇಡಿಕೆಯ ಟ್ರಾಫಿಕ್ ಲೋಡ್‌ಗಳನ್ನು ಸಹ ನಿಭಾಯಿಸಬಲ್ಲ ದೃಢವಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ವ್ಯವಸ್ಥೆಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.
ಈ ಬ್ಲಾಗ್ ಪೋಸ್ಟ್ ಟೋಕನ್ ಬಕೆಟ್ ಅಲ್ಗಾರಿದಮ್, ಅದರ ಅನುಷ್ಠಾನ, ಅನುಕೂಲಗಳು, ಅನಾನುಕೂಲಗಳು ಮತ್ತು ಬಳಕೆಯ ಪ್ರಕರಣಗಳ ಬಗ್ಗೆ ಸಮಗ್ರ ಅವಲೋಕನವನ್ನು ಒದಗಿಸಿದೆ. ಈ ಜ್ಞಾನವನ್ನು ಬಳಸಿಕೊಂಡು, ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಲ್ಲಿ ದರ ಮಿತಿಯನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು ಮತ್ತು ಪ್ರಪಂಚದಾದ್ಯಂತದ ಬಳಕೆದಾರರಿಗೆ ನಿಮ್ಮ ಸೇವೆಗಳ ಸ್ಥಿರತೆ ಮತ್ತು ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬಹುದು.