GoDasturchi
Rate Limiting as a System-Level Concern

Rate Limiting as a System-Level Concern

Tizim darajasida so'rovlar tezligini cheklash

Bitta konsert kassasida BITTA xodim, o'ziga kelgan navbatni O'ZI kuzatib, "soatiga 100 tadan ortiq bilet sotmayman" deb hal qilishi OSON. Endi O'SHA konsertning O'NTA turli kassasi bo'lsa-chi — har bir xodim FAQAT o'z navbatini kuzatsa, umumiy limit (masalan, soatiga 100 bilet) OSHIB ketishi mumkin, chunki hech kim UMUMIY rasmni ko'rmaydi. Bu — taqsimlangan rate limiting (distributed rate limiting)ning aynan o'zi duch keladigan muammo.

Project: Rate Limiter kursida va Build a URL Shortener kursidagi "Rate Limiting" darsida siz BITTA server ICHIDA, xotiradagi map orqali ishlaydigan rate limiter QURGAN edingiz — bu, BITTA server uchun MUKAMMAL ishlaydi. Lekin Load Balancing darsida ko'rganingizdek, real tizimda ko'pincha BIR NECHTA server BOR, va load balancer so'rovlarni ULAR orasida TAQSIMLAYDI. Agar HAR bir server O'Z xotirasida ALOHIDA hisoblasa (masalan, har biri "100 tagacha" deb), umumiy limit 3 baravar KO'P server bo'lsa, 3 baravar KO'P so'rovga RUXSAT berilib qo'yishi mumkin.

Yechim — hisoblagichni HAR bir serverning O'Z xotirasida emas, balki BARCHA server BIRGALIKDA murojaat qiladigan, MARKAZIY, tez joyda (odatda Redis kabi in-memory ma'lumotlar bazasida — Build an In-Memory Cache kursida ko'rgan g'oyaning tarmoqqa CHIQARILGAN ko'rinishi) saqlash. Har bir server, so'rovni RUXSAT berishdan OLDIN, O'SHA markaziy hisoblagichni TEKSHIRADI va YANGILAYDI — shunda barcha server BIR XIL, TO'G'RI umumiy sonni ko'radi.

  • •QAYERDA joylashadi? — API Gateway darajasida (barcha so'rov BIR joydan o'tadi, cheklash MARKAZIY va sodda), yoki har bir xizmatning O'ZIDA (moslashuvchan, lekin taqsimlangan hisoblash kerak)
  • •Nima bo'yicha cheklanadi? — foydalanuvchi ID'si, IP manzil, yoki API kaliti bo'yicha — Client Registry darsida ko'rgan g'oyaning, ko'plab server bo'ylab TAQSIMLANGAN ko'rinishi
  • •Markaziy hisoblagichning O'ZI SPOF bo'lib QOLMASLIGI uchun, u ham Reliability and Redundancy darsidagi kabi zaxiralanishi kerak

Bu — Bitta serverdagi rate limiter bilan tizim darajasidagi rate limiting orasidagi ASOSIY farq: MANTIQ (necha so'rovga ruxsat berish) bir xil qoladi, lekin "hisoblagich QAYERDA saqlanadi va KIM bilan BAHAM ko'riladi" degan savol — butunlay YANGI, taqsimlangan tizim muammosiga aylanadi. Aynan shu turdagi "real tizimga ko'chirish" mashqini Designing Real Systems kursida to'liq CASE-STUDY sifatida ko'rib chiqamiz.

Key Takeaway

Key Takeaway:

Bitta serverda rate limiting — xotiradagi hisoblagich bilan oson hal qilinadi, lekin bir nechta serverga tarqalganda, har bir server o'z-o'zicha hisoblasa umumiy limit oshib ketishi mumkin. Yechim — hisoblagichni barcha server BIRGA murojaat qiladigan markaziy, tez saqlash joyida (masalan, Redis) yuritish.

NEXT UP

Choosing the Right Combination of Tools

Rate Limiting as a System-Level Concern

Tizim darajasida so'rovlar tezligini cheklash

Bitta konsert kassasida BITTA xodim, o'ziga kelgan navbatni O'ZI kuzatib, "soatiga 100 tadan ortiq bilet sotmayman" deb hal qilishi OSON. Endi O'SHA konsertning O'NTA turli kassasi bo'lsa-chi — har bir xodim FAQAT o'z navbatini kuzatsa, umumiy limit (masalan, soatiga 100 bilet) OSHIB ketishi mumkin, chunki hech kim UMUMIY rasmni ko'rmaydi. Bu — taqsimlangan rate limiting (distributed rate limiting)ning aynan o'zi duch keladigan muammo.

Project: Rate Limiter kursida va Build a URL Shortener kursidagi "Rate Limiting" darsida siz BITTA server ICHIDA, xotiradagi map orqali ishlaydigan rate limiter QURGAN edingiz — bu, BITTA server uchun MUKAMMAL ishlaydi. Lekin Load Balancing darsida ko'rganingizdek, real tizimda ko'pincha BIR NECHTA server BOR, va load balancer so'rovlarni ULAR orasida TAQSIMLAYDI. Agar HAR bir server O'Z xotirasida ALOHIDA hisoblasa (masalan, har biri "100 tagacha" deb), umumiy limit 3 baravar KO'P server bo'lsa, 3 baravar KO'P so'rovga RUXSAT berilib qo'yishi mumkin.

Yechim — hisoblagichni HAR bir serverning O'Z xotirasida emas, balki BARCHA server BIRGALIKDA murojaat qiladigan, MARKAZIY, tez joyda (odatda Redis kabi in-memory ma'lumotlar bazasida — Build an In-Memory Cache kursida ko'rgan g'oyaning tarmoqqa CHIQARILGAN ko'rinishi) saqlash. Har bir server, so'rovni RUXSAT berishdan OLDIN, O'SHA markaziy hisoblagichni TEKSHIRADI va YANGILAYDI — shunda barcha server BIR XIL, TO'G'RI umumiy sonni ko'radi.

  • •QAYERDA joylashadi? — API Gateway darajasida (barcha so'rov BIR joydan o'tadi, cheklash MARKAZIY va sodda), yoki har bir xizmatning O'ZIDA (moslashuvchan, lekin taqsimlangan hisoblash kerak)
  • •Nima bo'yicha cheklanadi? — foydalanuvchi ID'si, IP manzil, yoki API kaliti bo'yicha — Client Registry darsida ko'rgan g'oyaning, ko'plab server bo'ylab TAQSIMLANGAN ko'rinishi
  • •Markaziy hisoblagichning O'ZI SPOF bo'lib QOLMASLIGI uchun, u ham Reliability and Redundancy darsidagi kabi zaxiralanishi kerak

Bu — Bitta serverdagi rate limiter bilan tizim darajasidagi rate limiting orasidagi ASOSIY farq: MANTIQ (necha so'rovga ruxsat berish) bir xil qoladi, lekin "hisoblagich QAYERDA saqlanadi va KIM bilan BAHAM ko'riladi" degan savol — butunlay YANGI, taqsimlangan tizim muammosiga aylanadi. Aynan shu turdagi "real tizimga ko'chirish" mashqini Designing Real Systems kursida to'liq CASE-STUDY sifatida ko'rib chiqamiz.

Key Takeaway

Key Takeaway:

Bitta serverda rate limiting — xotiradagi hisoblagich bilan oson hal qilinadi, lekin bir nechta serverga tarqalganda, har bir server o'z-o'zicha hisoblasa umumiy limit oshib ketishi mumkin. Yechim — hisoblagichni barcha server BIRGA murojaat qiladigan markaziy, tez saqlash joyida (masalan, Redis) yuritish.

NEXT UP

Choosing the Right Combination of Tools