تحديد المعدل في Java: كيفية حماية API من التحميل الزائد والروبوتات

تحديد المعدل والاختناق في Java: من النظرية إلى الكود العملي

تخيل: خدمتك المصغرة الجديدة على Java بدأت للتو في العمل، وفجأة تتعرض لوابل من الطلبات. ليس مخربين، لا — مجرد عميل مهمل نسي وضع تأخير في نصه البرمجي. النتيجة: قاعدة البيانات تتعطل، الخادم يختنق، والمستخدمون (بمن فيهم الملتزمون) يحصلون على 502 Bad Gateway. هل يبدو الأمر مألوفًا؟

اليوم سنتحدث عن كيفية تجنب ذلك. موضوع حديثنا هو تحديد المعدل والاختناق في Java. هذه ليست مجرد مصطلحات عصرية من عالم DevOps، بل هي خط دفاعك الأول لأي API عام. سنشرح الفرق بين "تحديد السرعة" و"الاختناق"، ونستعرض الخوارزميات الشائعة، والأهم من ذلك، سنكتب كودًا حقيقيًا.

إذا كنت تكتب بلغة Java وتريد أن تظل خدمتك حية تحت أي حمل — فأنت في المكان الصحيح. هيا بنا!

تحديد المعدل مقابل الاختناق: ما الفرق؟

غالبًا ما يتم الخلط بين هذين المفهومين، على الرغم من أنهما يحلان مشكلات مختلفة، وإن كانت متقاربة.

• تحديد المعدل (Rate Limiting) — هو حاجز صارم. "لا يزيد عن 10 طلبات في الثانية من عنوان IP واحد". تجاوزت الحد؟ احصل على 429 Too Many Requests. الأمر عادل.
• الاختناق (Throttling) — هو آلية أكثر مرونة. الخدمة لا تمنع الطلب، بل تبطئ معالجته. على سبيل المثال، تضع الطلب في قائمة انتظار وتعالجه بسرعة ثابتة.

في المشاريع الحقيقية، غالبًا ما يتم تنفيذ الاختناق في Java من خلال تجمعات الخيوط (ThreadPoolExecutor) ذات السعة المحدودة، بينما يتم تنفيذ تحديد المعدل من خلال العدادات وذاكرة التخزين المؤقت والمرشحات الوسيطة.

خوارزميات تحديد المعدل: اختر سلاحك

قبل كتابة الكود، دعنا نختار استراتيجية. إليك ثلاث من أشهر الخوارزميات لـ تقييد الطلبات في Java.

1. Token Bucket (سلة الرموز)

كلاسيكية. لدينا "دلو" يتم فيه إسقاط N من الرموز الجديدة كل ثانية. لتنفيذ طلب، تحتاج إلى أخذ رمز واحد. إذا كان الدلو فارغًا — يتم رفض الطلب. تتعامل الخوارزمية بشكل ممتاز مع الارتفاعات المفاجئة في حركة المرور، مما يسمح بـ "اقتراض" الرموز مقدمًا (حتى حجم الدلو).

2. Sliding Window (النافذة المنزلقة)

طريقة أكثر دقة. بدلاً من عد الطلبات في ثانية تقويمية، نقوم بتحريك نافذة زمنية. على سبيل المثال، "لا يزيد عن 100 طلب في آخر 60 ثانية". هذا يمنع "الارتفاع" في بداية كل فترة زمنية.

3. Fixed Window (النافذة الثابتة)

الأبسط، ولكنه خطير. إعادة تعيين العداد كل N ثانية. المشكلة: في نهاية النافذة يمكنك إرسال ألف طلب، وفي بداية النافذة التالية — ألف آخر. غير مناسب للأنظمة الحرجة.

سنركز على الأولين — فهما يعطيان أفضل توازن بين الأداء والدقة.

نكتب الكود: محدد معدل بأيدينا

دعنا ننفذ محدد معدل في Java باستخدام خوارزمية Token Bucket. هذا مثال ممتاز لفهم كيفية عمل أنظمة التحديد من الداخل.

import java.util.concurrent.ConcurrentHashMap;import java.util.concurrent.TimeUnit;import java.util.concurrent.atomic.AtomicLong;

public class TokenBucketRateLimiter {

    private final long maxTokens;         // الحجم الأقصى للدلو    private final long refillRate;        // الرموز في الثانية    private final ConcurrentHashMap<String, Bucket> buckets = new ConcurrentHashMap<>();

    public TokenBucketRateLimiter(long maxTokens, long refillRate) {        this.maxTokens = maxTokens;        this.refillRate = refillRate;    }

    public boolean tryAcquire(String clientId) {        Bucket bucket = buckets.computeIfAbsent(clientId, k -> new Bucket(maxTokens));        return bucket.tryConsume();    }

    private class Bucket {        private final AtomicLong tokens;        private volatile long lastRefillTimestamp;

        Bucket(long cap