استكشف استراتيجيات تحديد المعدل مع التركيز على خوارزمية دلو التوكن. تعرف على كيفية تطبيقها ومزاياها وعيوبها وحالات استخدامها العملية لبناء تطبيقات مرنة وقابلة للتطوير.
تحديد المعدل: نظرة عميقة على تطبيق خوارزمية دلو التوكن
في المشهد الرقمي المترابط اليوم، يعد ضمان استقرار وتوافر التطبيقات وواجهات برمجة التطبيقات (APIs) أمرًا بالغ الأهمية. يلعب تحديد المعدل دورًا حاسمًا في تحقيق هذا الهدف من خلال التحكم في المعدل الذي يمكن للمستخدمين أو العملاء تقديم الطلبات به. يقدم هذا المقال استكشافًا شاملًا لاستراتيجيات تحديد المعدل، مع التركيز بشكل خاص على خوارزمية دلو التوكن، وتطبيقها، ومزاياها، وعيوبها.
ما هو تحديد المعدل؟
تحديد المعدل هو تقنية تُستخدم للتحكم في كمية الحركة (traffic) المرسلة إلى خادم أو خدمة خلال فترة زمنية محددة. إنه يحمي الأنظمة من الإرهاق بسبب الطلبات المفرطة، مما يمنع هجمات حجب الخدمة (DoS)، وسوء الاستخدام، والارتفاعات غير المتوقعة في حركة المرور. من خلال فرض حدود على عدد الطلبات، يضمن تحديد المعدل الاستخدام العادل، ويحسن أداء النظام بشكل عام، ويعزز الأمان.
لنأخذ على سبيل المثال منصة تجارة إلكترونية خلال فترة التخفيضات السريعة. بدون تحديد المعدل، يمكن أن يؤدي الارتفاع المفاجئ في طلبات المستخدمين إلى إرهاق الخوادم، مما يؤدي إلى بطء في أوقات الاستجابة أو حتى انقطاع الخدمة. يمكن لتحديد المعدل أن يمنع ذلك عن طريق تقييد عدد الطلبات التي يمكن للمستخدم (أو عنوان IP) إجراؤها خلال إطار زمني معين، مما يضمن تجربة أكثر سلاسة لجميع المستخدمين.
لماذا تحديد المعدل مهم؟
يقدم تحديد المعدل فوائد عديدة، منها:
- منع هجمات حجب الخدمة (DoS): من خلال تحديد معدل الطلبات من أي مصدر واحد، يخفف تحديد المعدل من تأثير هجمات حجب الخدمة التي تهدف إلى إغراق الخادم بحركة مرور ضارة.
- الحماية من سوء الاستخدام: يمكن لتحديد المعدل أن يردع الجهات الخبيثة عن إساءة استخدام واجهات برمجة التطبيقات أو الخدمات، مثل استخلاص البيانات أو إنشاء حسابات مزيفة.
- ضمان الاستخدام العادل: يمنع تحديد المعدل المستخدمين أو العملاء الفرديين من احتكار الموارد ويضمن أن جميع المستخدمين لديهم فرصة عادلة للوصول إلى الخدمة.
- تحسين أداء النظام: من خلال التحكم في معدل الطلبات، يمنع تحديد المعدل الخوادم من التحميل الزائد، مما يؤدي إلى أوقات استجابة أسرع وتحسين أداء النظام بشكل عام.
- إدارة التكاليف: بالنسبة للخدمات المستندة إلى السحابة، يمكن أن يساعد تحديد المعدل في التحكم في التكاليف عن طريق منع الاستخدام المفرط الذي قد يؤدي إلى رسوم غير متوقعة.
خوارزميات تحديد المعدل الشائعة
يمكن استخدام عدة خوارزميات لتطبيق تحديد المعدل. من بين الأكثر شيوعًا:
- دلو التوكن (Token Bucket): تستخدم هذه الخوارزمية "دلوًا" مفاهيميًا يحتوي على توكنات (رموز). كل طلب يستهلك توكن. إذا كان الدلو فارغًا، يتم رفض الطلب. تتم إضافة التوكنات إلى الدلو بمعدل محدد.
- الدلو المتسرب (Leaky Bucket): مشابهة لدلو التوكن، ولكن تتم معالجة الطلبات بمعدل ثابت، بغض النظر عن معدل وصولها. يتم وضع الطلبات الزائدة في قائمة انتظار أو يتم تجاهلها.
- عداد النافذة الثابتة (Fixed Window Counter): تقسم هذه الخوارزمية الوقت إلى نوافذ ذات حجم ثابت وتحسب عدد الطلبات داخل كل نافذة. بمجرد الوصول إلى الحد الأقصى، يتم رفض الطلبات اللاحقة حتى تتم إعادة تعيين النافذة.
- سجل النافذة المنزلقة (Sliding Window Log): يحتفظ هذا النهج بسجل للطوابع الزمنية للطلبات داخل نافذة منزلقة. يتم حساب عدد الطلبات داخل النافذة بناءً على السجل.
- عداد النافذة المنزلقة (Sliding Window Counter): نهج هجين يجمع بين جوانب خوارزميات النافذة الثابتة والنافذة المنزلقة لتحسين الدقة.
سيركز هذا المقال على خوارزمية دلو التوكن نظرًا لمرونتها وتطبيقها الواسع.
خوارزمية دلو التوكن: شرح مفصل
خوارزمية دلو التوكن هي تقنية لتحديد المعدل مستخدمة على نطاق واسع وتوفر توازنًا بين البساطة والفعالية. تعمل من خلال الحفاظ على "دلو" مفاهيمي يحتوي على توكنات. كل طلب وارد يستهلك توكن من الدلو. إذا كان الدلو يحتوي على عدد كافٍ من التوكنات، يُسمح بالطلب؛ وإلا، يتم رفض الطلب (أو وضعه في قائمة انتظار، حسب التطبيق). تتم إضافة التوكنات إلى الدلو بمعدل محدد، مما يجدد السعة المتاحة.
المفاهيم الأساسية
- سعة الدلو: الحد الأقصى لعدد التوكنات التي يمكن أن يحتويها الدلو. يحدد هذا سعة الدفق (burst capacity)، مما يسمح بمعالجة عدد معين من الطلبات في تتابع سريع.
- معدل إعادة التعبئة: المعدل الذي تضاف به التوكنات إلى الدلو، ويُقاس عادةً بالتوكنات في الثانية (أو وحدة زمنية أخرى). يتحكم هذا في متوسط المعدل الذي يمكن به معالجة الطلبات.
- استهلاك الطلب: يستهلك كل طلب وارد عددًا معينًا من التوكنات من الدلو. عادةً، يستهلك كل طلب توكنًا واحدًا، ولكن السيناريوهات الأكثر تعقيدًا يمكن أن تخصص تكاليف توكن مختلفة لأنواع مختلفة من الطلبات.
كيف تعمل
- عند وصول طلب، تتحقق الخوارزمية مما إذا كان هناك عدد كافٍ من التوكنات في الدلو.
- إذا كان هناك عدد كافٍ من التوكنات، يُسمح بالطلب، ويتم إزالة العدد المقابل من التوكنات من الدلو.
- إذا لم يكن هناك عدد كافٍ من التوكنات، يتم رفض الطلب (مع إرجاع خطأ "Too Many Requests"، عادةً HTTP 429) أو وضعه في قائمة انتظار للمعالجة لاحقًا.
- بشكل مستقل عن وصول الطلبات، تتم إضافة التوكنات بشكل دوري إلى الدلو بمعدل إعادة التعبئة المحدد، حتى تصل إلى سعة الدلو.
مثال
تخيل دلو توكن بسعة 10 توكنات ومعدل إعادة تعبئة 2 توكن في الثانية. في البداية، الدلو ممتلئ (10 توكنات). إليك كيف قد تتصرف الخوارزمية:
- الثانية 0: تصل 5 طلبات. الدلو لديه عدد كافٍ من التوكنات، لذا يُسمح بجميع الطلبات الخمسة، ويحتوي الدلو الآن على 5 توكنات.
- الثانية 1: لا تصل أي طلبات. تتم إضافة 2 توكن إلى الدلو، ليصل الإجمالي إلى 7 توكنات.
- الثانية 2: تصل 4 طلبات. الدلو لديه عدد كافٍ من التوكنات، لذا يُسمح بجميع الطلبات الأربعة، ويحتوي الدلو الآن على 3 توكنات. تتم أيضًا إضافة 2 توكن، ليصل الإجمالي إلى 5 توكنات.
- الثانية 3: تصل 8 طلبات. يمكن السماح بـ 5 طلبات فقط (الدلو لديه 5 توكنات)، ويتم رفض الطلبات الثلاثة المتبقية أو وضعها في قائمة انتظار. تتم أيضًا إضافة 2 توكن، ليصل الإجمالي إلى 2 توكن (إذا تمت خدمة الطلبات الخمسة قبل دورة إعادة التعبئة، أو 7 إذا حدثت إعادة التعبئة قبل خدمة الطلبات).
تطبيق خوارزمية دلو التوكن
يمكن تطبيق خوارزمية دلو التوكن بلغات برمجة مختلفة. إليك أمثلة بلغات Golang و Python و Java:
Golang
```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 ينشئ دلو توكن جديد. 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
```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
```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); } } } ```
مزايا خوارزمية دلو التوكن
- المرونة: خوارزمية دلو التوكن مرنة للغاية ويمكن تكييفها بسهولة مع سيناريوهات تحديد المعدل المختلفة. يمكن تعديل سعة الدلو ومعدل إعادة التعبئة لضبط سلوك تحديد المعدل بدقة.
- التعامل مع الدفقات: تسمح سعة الدلو بمعالجة كمية معينة من حركة المرور المتدفقة (burst traffic) دون تحديد معدلها. هذا مفيد للتعامل مع الارتفاعات العرضية في حركة المرور.
- البساطة: الخوارزمية بسيطة نسبيًا في الفهم والتطبيق.
- قابلية التكوين: تتيح التحكم الدقيق في متوسط معدل الطلبات وسعة الدفق.
عيوب خوارزمية دلو التوكن
- التعقيد: على الرغم من بساطة المفهوم، تتطلب إدارة حالة الدلو وعملية إعادة التعبئة تطبيقًا دقيقًا، خاصة في الأنظمة الموزعة.
- احتمالية التوزيع غير المتكافئ: في بعض السيناريوهات، قد تؤدي سعة الدفق إلى توزيع غير متكافئ للطلبات بمرور الوقت.
- عبء التكوين: قد يتطلب تحديد السعة المثلى للدلو ومعدل إعادة التعبئة تحليلًا وتجريبًا دقيقًا.
حالات استخدام خوارزمية دلو التوكن
تعتبر خوارزمية دلو التوكن مناسبة لمجموعة واسعة من حالات استخدام تحديد المعدل، بما في ذلك:
- تحديد معدل واجهة برمجة التطبيقات (API): حماية واجهات برمجة التطبيقات من سوء الاستخدام وضمان الاستخدام العادل عن طريق تحديد عدد الطلبات لكل مستخدم أو عميل. على سبيل المثال، قد تحدد واجهة برمجة تطبيقات لوسائل التواصل الاجتماعي عدد المنشورات التي يمكن للمستخدم إجراؤها في الساعة لمنع البريد العشوائي.
- تحديد معدل تطبيقات الويب: منع المستخدمين من تقديم طلبات مفرطة لخوادم الويب، مثل إرسال النماذج أو الوصول إلى الموارد. قد يحد تطبيق مصرفي عبر الإنترنت من عدد محاولات إعادة تعيين كلمة المرور لمنع هجمات القوة الغاشمة (brute-force).
- تحديد معدل الشبكة: التحكم في معدل حركة المرور المتدفقة عبر الشبكة، مثل تحديد النطاق الترددي الذي يستخدمه تطبيق أو مستخدم معين. غالبًا ما يستخدم مزودو خدمة الإنترنت تحديد المعدل لإدارة ازدحام الشبكة.
- تحديد معدل طابور الرسائل: التحكم في معدل معالجة الرسائل بواسطة طابور الرسائل، مما يمنع المستهلكين من الإرهاق. هذا شائع في معماريات الخدمات المصغرة حيث تتواصل الخدمات بشكل غير متزامن عبر طوابير الرسائل.
- تحديد معدل الخدمات المصغرة: حماية الخدمات المصغرة الفردية من التحميل الزائد عن طريق تحديد عدد الطلبات التي تتلقاها من الخدمات الأخرى أو العملاء الخارجيين.
تطبيق دلو التوكن في الأنظمة الموزعة
يتطلب تطبيق خوارزمية دلو التوكن في نظام موزع اعتبارات خاصة لضمان الاتساق وتجنب حالات التسابق (race conditions). فيما يلي بعض الأساليب الشائعة:
- دلو التوكن المركزي: تدير خدمة مركزية واحدة دلاء التوكن لجميع المستخدمين أو العملاء. هذا النهج بسيط في التنفيذ ولكنه يمكن أن يصبح عنق زجاجة ونقطة فشل واحدة.
- دلو التوكن الموزع مع Redis: يمكن استخدام Redis، وهو مخزن بيانات في الذاكرة، لتخزين وإدارة دلاء التوكن. يوفر Redis عمليات ذرية (atomic) يمكن استخدامها لتحديث حالة الدلو بأمان في بيئة متزامنة.
- دلو التوكن من جانب العميل: يحتفظ كل عميل بدلو التوكن الخاص به. هذا النهج قابل للتطوير بشكل كبير ولكنه قد يكون أقل دقة لأنه لا يوجد تحكم مركزي في تحديد المعدل.
- النهج الهجين: يجمع بين جوانب النهجين المركزي والموزع. على سبيل المثال، يمكن استخدام ذاكرة تخزين مؤقت موزعة لتخزين دلاء التوكن، مع خدمة مركزية مسؤولة عن إعادة تعبئة الدلاء.
مثال باستخدام Redis (مفاهيمي)
يتضمن استخدام Redis لدلو توكن موزع الاستفادة من عملياته الذرية (مثل `INCRBY`، `DECR`، `TTL`، `EXPIRE`) لإدارة عدد التوكنات. سيكون التدفق الأساسي كما يلي:
- التحقق من وجود الدلو: تحقق مما إذا كان هناك مفتاح في Redis للمستخدم/نقطة نهاية الواجهة البرمجية.
- الإنشاء إذا لزم الأمر: إذا لم يكن موجودًا، فأنشئ المفتاح، وقم بتهيئة عدد التوكنات إلى السعة القصوى، وقم بتعيين تاريخ انتهاء صلاحية (TTL) ليتوافق مع فترة إعادة التعبئة.
- محاولة استهلاك توكن: قم بإنقاص عدد التوكنات بشكل ذري. إذا كانت النتيجة >= 0، يُسمح بالطلب.
- التعامل مع استنفاد التوكنات: إذا كانت النتيجة < 0، قم بعكس الإنقاص (زيادة مرة أخرى بشكل ذري) وارفض الطلب.
- منطق إعادة التعبئة: يمكن لعملية خلفية أو مهمة دورية إعادة تعبئة الدلاء، مضيفةً توكنات حتى السعة القصوى.
اعتبارات مهمة للتطبيقات الموزعة:
- الذرية (Atomicity): استخدم العمليات الذرية لضمان تحديث أعداد التوكنات بشكل صحيح في بيئة متزامنة.
- الاتساق (Consistency): تأكد من أن أعداد التوكنات متسقة عبر جميع العقد في النظام الموزع.
- تحمل الأخطاء (Fault Tolerance): صمم النظام ليكون قادرًا على تحمل الأخطاء، بحيث يمكنه الاستمرار في العمل حتى في حالة فشل بعض العقد.
- قابلية التوسع (Scalability): يجب أن يتوسع الحل للتعامل مع عدد كبير من المستخدمين والطلبات.
- المراقبة (Monitoring): قم بتنفيذ المراقبة لتتبع فعالية تحديد المعدل وتحديد أي مشكلات.
بدائل لدلو التوكن
بينما تعد خوارزمية دلو التوكن خيارًا شائعًا، قد تكون تقنيات تحديد المعدل الأخرى أكثر ملاءمة اعتمادًا على المتطلبات المحددة. إليك مقارنة مع بعض البدائل:
- الدلو المتسرب (Leaky Bucket): أبسط من دلو التوكن. يعالج الطلبات بمعدل ثابت. جيد لتنعيم حركة المرور ولكنه أقل مرونة من دلو التوكن في التعامل مع الدفقات.
- عداد النافذة الثابتة (Fixed Window Counter): سهل التنفيذ، ولكنه يمكن أن يسمح بضعف حد المعدل عند حدود النافذة. أقل دقة من دلو التوكن.
- سجل النافذة المنزلقة (Sliding Window Log): دقيق، ولكنه يستهلك ذاكرة أكبر لأنه يسجل جميع الطلبات. مناسب للسيناريوهات التي تكون فيها الدقة أمرًا بالغ الأهمية.
- عداد النافذة المنزلقة (Sliding Window Counter): حل وسط بين الدقة واستخدام الذاكرة. يوفر دقة أفضل من عداد النافذة الثابتة مع استهلاك ذاكرة أقل من سجل النافذة المنزلقة.
اختيار الخوارزمية المناسبة:
يعتمد اختيار أفضل خوارزمية لتحديد المعدل على عوامل مثل:
- متطلبات الدقة: ما مدى الدقة التي يجب أن يتم بها فرض حد المعدل؟
- احتياجات التعامل مع الدفقات: هل من الضروري السماح بدفقات قصيرة من حركة المرور؟
- قيود الذاكرة: ما مقدار الذاكرة التي يمكن تخصيصها لتخزين بيانات تحديد المعدل؟
- تعقيد التنفيذ: ما مدى سهولة تنفيذ الخوارزمية وصيانتها؟
- متطلبات قابلية التوسع: ما مدى قدرة الخوارزمية على التوسع للتعامل مع عدد كبير من المستخدمين والطلبات؟
أفضل الممارسات لتحديد المعدل
يتطلب تطبيق تحديد المعدل بشكل فعال تخطيطًا ودراسة متأنية. إليك بعض أفضل الممارسات التي يجب اتباعها:
- تحديد حدود المعدل بوضوح: حدد حدود المعدل المناسبة بناءً على سعة الخادم وأنماط حركة المرور المتوقعة واحتياجات المستخدمين.
- توفير رسائل خطأ واضحة: عند تحديد معدل طلب ما، أرجع رسالة خطأ واضحة وغنية بالمعلومات للمستخدم، بما في ذلك سبب تحديد المعدل ومتى يمكنه المحاولة مرة أخرى (على سبيل المثال، باستخدام ترويسة HTTP `Retry-After`).
- استخدام رموز حالة HTTP القياسية: استخدم رموز حالة HTTP المناسبة للإشارة إلى تحديد المعدل، مثل 429 (Too Many Requests).
- تنفيذ التدهور التدريجي (Graceful Degradation): بدلاً من مجرد رفض الطلبات، فكر في تنفيذ التدهور التدريجي، مثل تقليل جودة الخدمة أو تأخير المعالجة.
- مراقبة مقاييس تحديد المعدل: تتبع عدد الطلبات التي تم تحديد معدلها، ومتوسط وقت الاستجابة، والمقاييس الأخرى ذات الصلة لضمان فعالية تحديد المعدل وعدم تسببه في عواقب غير مقصودة.
- جعل حدود المعدل قابلة للتكوين: اسمح للمسؤولين بضبط حدود المعدل ديناميكيًا بناءً على أنماط حركة المرور المتغيرة وسعة النظام.
- توثيق حدود المعدل: وثّق حدود المعدل بوضوح في وثائق واجهة برمجة التطبيقات حتى يكون المطورون على دراية بالحدود ويمكنهم تصميم تطبيقاتهم وفقًا لذلك.
- استخدام تحديد المعدل التكيفي: فكر في استخدام تحديد المعدل التكيفي، الذي يضبط حدود المعدل تلقائيًا بناءً على الحمل الحالي للنظام وأنماط حركة المرور.
- التفريق بين حدود المعدل: طبّق حدود معدل مختلفة على أنواع مختلفة من المستخدمين أو العملاء. على سبيل المثال، قد يكون لدى المستخدمين المصادق عليهم حدود معدل أعلى من المستخدمين المجهولين. وبالمثل، قد يكون لنقاط نهاية واجهة برمجة التطبيقات المختلفة حدود معدل مختلفة.
- مراعاة الاختلافات الإقليمية: كن على دراية بأن ظروف الشبكة وسلوك المستخدم يمكن أن تختلف عبر المناطق الجغرافية المختلفة. قم بتخصيص حدود المعدل وفقًا لذلك عند الاقتضاء.
الخاتمة
يعد تحديد المعدل تقنية أساسية لبناء تطبيقات مرنة وقابلة للتطوير. توفر خوارزمية دلو التوكن طريقة مرنة وفعالة للتحكم في المعدل الذي يمكن للمستخدمين أو العملاء تقديم الطلبات به، مما يحمي الأنظمة من سوء الاستخدام، ويضمن الاستخدام العادل، ويحسن الأداء العام. من خلال فهم مبادئ خوارزمية دلو التوكن واتباع أفضل الممارسات للتنفيذ، يمكن للمطورين بناء أنظمة قوية وموثوقة يمكنها التعامل حتى مع أعباء حركة المرور الأكثر تطلبًا.
لقد قدم هذا المقال نظرة شاملة على خوارزمية دلو التوكن، وتطبيقها، ومزاياها، وعيوبها، وحالات استخدامها. من خلال الاستفادة من هذه المعرفة، يمكنك تنفيذ تحديد المعدل بفعالية في تطبيقاتك الخاصة وضمان استقرار وتوافر خدماتك للمستخدمين في جميع أنحاء العالم.