Designing a Distributed Rate Limiter Service

Taqsimlangan rate limiter xizmatini loyihalash

Bitta katta ko'ngil ochish majmuasining KIRISH eshigida, bitta soqchi "soatiga 500 kishidan ORTIQ kiritmayman" deb hisoblab TURADI — bu SODDA. Endi majmuada BESHTA turli eshik bo'lsa-yu, HAR bir eshikda ALOHIDA soqchi TURSA — umumiy 500 limitni SAQLASH uchun, BARCHA beshta soqchi BIR-BIRIGA doimiy ravishda "hozircha nechta kishi kirdi" deb XABAR berib turishi KERAK. Taqsimlangan rate limiter xizmati — aynan shu MUAMMONI hal qiladi.

Rate Limiting as a System-Level Concern darsida ko'rganingizdek, ko'plab server O'ZINING alohida hisoblagichi bilan ishlasa, umumiy limit OSHIB ketishi mumkin. Endi bu MUAMMONI, ALOHIDA, mustaqil XIZMAT sifatida TO'LIQ loyihalaymiz — Project: Rate Limiter kursida QURGAN bitta-jarayonli limiter'ning, BUTUN tizim miqyosidagi VERSIYASI.

Yuqori darajadagi dizayn: barcha xizmat (OrderService, PaymentService va h.k. — Introduction to Microservices kursidan ESLANG) so'rov qabul qilishdan OLDIN, ALOHIDA "Rate Limiter Service"ga MUROJAAT qiladi: "bu foydalanuvchi/IP uchun HALI so'rov yuborish MUMKINMI?" Bu markazlashtirilgan yondashuv — API Gateway darsida ko'rgan "bitta bosh eshik" g'oyasi bilan BOG'LIQ: rate limiting ko'pincha AYNAN API Gateway darajasida amalga oshiriladi, shunda HAR bir alohida xizmat buni O'ZI TAKRORLASH shart emas.

Algoritm	G'oyasi	Kamchiligi
Fixed window (qat'iy oyna)	Har bir 1 daqiqalik oynada, N tagacha so'rovga ruxsat	Oyna CHEGARASIDA (masalan, 0:59 va 1:01) ikki BAROBAR ko'p so'rov o'tib ketishi mumkin
Sliding window (siljuvchi oyna)	Oxirgi 60 soniyani DOIMIY "siljitib" hisoblaydi	Fixed window'dan ANIQROQ, lekin hisoblash biroz MURAKKABROQ
Token bucket (belgi savati)	Har bir foydalanuvchi "savat"ida belgilar bor, HAR so'rov bitta belgi SARFLAYDI, belgilar VAQT bo'yicha to'lib boradi	Qisqa vaqtli "portlash" (burst)ga RUXSAT beradi — ba'zan bu XOHLANGAN xususiyat

Chuqur kirish: markaziy hisoblagich (odatda Redis) — O'ZI ham SPOF bo'lib QOLMASLIGI uchun, Reliability and Redundancy darsidagi kabi REPLIKATSIYA qilinadi. Bundan tashqari, HAR bir so'rov uchun rate limiter'ga MUROJAAT qilish — QO'SHIMCHA tarmoq kechikishi (Numbers Every Engineer Should Know darsi) qo'shadi, shuning uchun ko'p tizim buni JUDA tez (bir necha millisekund) javob beradigan qilib OPTIMALLASHTIRADI, yoki HAR bir xizmatga KICHIK "mahalliy" limitni QO'SHIMCHA ravishda BERADI (markaziy limit BUZILGANDA HAM, xizmat O'ZINI OQILONA himoya qila oladigan qilib).

Murosa: agar rate limiter xizmatining O'ZI vaqtincha JAVOB bermasa nima bo'ladi — barcha so'rovni RAD etamizmi (xavfsizroq, lekin ISHLAMAY qolish xavfi bilan), yoki O'TKAZIB yuboramizmi (mavjudlikni SAQLAYDI, lekin himoyani VAQTINCHA yo'qotadi)? Bu — Designing for Failure darsidagi "graceful degradation" tanlovining ANIQ, real qarori.

Key Takeaway

Key Takeaway:

Taqsimlangan rate limiter — odatda API Gateway darajasida, markaziy, tez saqlash joyi (masalan Redis) ustida qurilgan alohida xizmat sifatida ishlaydi. Token bucket kabi algoritmlar qisqa portlashlarga moslashuvchan ruxsat beradi, va markaziy hisoblagichning o'zi ham zaxiralanishi, ishdan chiqqanda esa aniq bir qarorga (rad etish yoki o'tkazib yuborish) ega bo'lishi kerak.

NEXT UP