Python pieprasījumu ierobežošana: Žetonu spainis pret bīdošo logu – visaptverošs ceļvedis

Mūsdienu savstarpēji savienotajā pasaulē stabilas API ir būtiskas lietojumprogrammu panākumiem. Tomēr nekontrolēta API piekļuve var izraisīt servera pārslodzi, pakalpojumu pasliktināšanos un pat pakalpojumu atteikuma (DoS) uzbrukumus. Pieprasījumu ierobežošana ir vitāli svarīga metode jūsu API aizsardzībai, ierobežojot pieprasījumu skaitu, ko lietotājs vai pakalpojums var veikt noteiktā laika posmā. Šajā rakstā aplūkotas divas populāras Python pieprasījumu ierobežošanas algoritmi: Žetonu spainis un Bīdošais logs, sniedzot visaptverošu salīdzinājumu un praktiskus ieviešanas piemērus.

Kāpēc pieprasījumu ierobežošana ir svarīga

Pieprasījumu ierobežošana piedāvā daudzas priekšrocības, tostarp:

• Vardarbības novēršana: Ierobežo ļaunprātīgu lietotāju vai botu spēju pārslogot jūsu serverus ar pārmērīgiem pieprasījumiem.
• Godīgas lietošanas nodrošināšana: Vienmērīgi sadala resursus starp lietotājiem, neļaujot vienam lietotājam monopolizēt sistēmu.
• Infrastruktūras aizsardzība: Aizsargā jūsu serverus un datu bāzes no pārslodzes un avārijām.
• Izmaksu kontrole: Novērš negaidītus resursu patēriņa pieaugumus, tādējādi ietaupot izmaksas.
• Veiktspējas uzlabošana: Uztur stabilu veiktspēju, novēršot resursu izsīkšanu un nodrošinot konsekventus atbildes laikus.

Izpratne par pieprasījumu ierobežošanas algoritmiem

Pastāv vairāki pieprasījumu ierobežošanas algoritmi, katram no tiem ir savas stiprās un vājās puses. Mēs koncentrēsimies uz diviem no visbiežāk izmantotajiem algoritmiem: Žetonu spainis un Bīdošais logs.

1. Žetonu spaiņa algoritms

Žetonu spaiņa algoritms ir vienkārša un plaši izmantota pieprasījumu ierobežošanas metode. Tas darbojas, uzturot "spaini", kas glabā žetonus. Katrs žetons apzīmē atļauju veikt vienu pieprasījumu. Spainim ir maksimālā ietilpība, un žetoni tiek pievienoti spainim ar fiksētu ātrumu.

Kad pienāk pieprasījums, pieprasījumu ierobežotājs pārbauda, vai spainī ir pietiekami daudz žetonu. Ja ir, pieprasījums tiek atļauts, un attiecīgais žetonu skaits tiek izņemts no spaiņa. Ja spainis ir tukšs, pieprasījums tiek noraidīts vai aizkavēts, līdz kļūst pieejami pietiekami daudz žetonu.

Žetonu spaiņa ieviešana Python

Šeit ir Žetonu spaiņa algoritma pamata Python ieviešana, izmantojot moduli threading, lai pārvaldītu vienlaicīgumu:

import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        tokens_to_add = delta * self.fill_rate
        self._tokens = min(self.capacity, self._tokens + tokens_to_add)
        self.last_refill = now

    def consume(self, tokens):
        with self.lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

# Piemēra lietošana
bucket = TokenBucket(capacity=10, fill_rate=2)  # 10 tokens, refill at 2 tokens per second

for i in range(15):
    if bucket.consume(1):
        print(f"Pieprasījums {i+1}: Atļauts")
    else:
        print(f"Pieprasījums {i+1}: Ierobežots")
    time.sleep(0.2)

Paskaidrojums:

• TokenBucket(capacity, fill_rate): Inicializē spaini ar maksimālo ietilpību un uzpildes ātrumu (žetoni sekundē).
• _refill(): Uzpilda spaini ar žetoniem, pamatojoties uz laiku, kas pagājis kopš pēdējās uzpildes.
• consume(tokens): Mēģina patērēt norādīto žetonu skaitu. Atgriež True, ja veiksmīgi (pieprasījums atļauts), False pretējā gadījumā (pieprasījums ierobežots).
• Pavedienu bloķēšana: Izmanto pavedienu bloķēšanu (self.lock), lai nodrošinātu pavedienu drošību vienlaicīgās vidēs.

Žetonu spaiņa priekšrocības

• Viegli ieviešams: Salīdzinoši viegli saprotams un ieviešams.
• Datplūsmas uzplūdu apstrāde: Var apstrādāt ik pa laikam notiekošus datplūsmas uzplūdus, ja spainī ir pietiekami daudz žetonu.
• Konfigurējams: Ietilpību un uzpildes ātrumu var viegli pielāgot, lai atbilstu specifiskām prasībām.

Žetonu spaiņa trūkumi

• Nav pilnīgi precīzs: Papildināšanas mehānisma dēļ var atļaut nedaudz vairāk pieprasījumu, nekā konfigurētais ātrums.
• Parametru regulēšana: Nepieciešama rūpīga ietilpības un uzpildes ātruma izvēle, lai sasniegtu vēlamo pieprasījumu ierobežošanas darbību.

2. Bīdošā loga algoritms

Bīdošā loga algoritms ir precīzāka pieprasījumu ierobežošanas metode, kas sadala laiku fiksēta izmēra logos. Tas izseko pieprasījumu skaitu, kas veikti katrā logā. Kad pienāk jauns pieprasījums, algoritms pārbauda, vai pieprasījumu skaits pašreizējā logā pārsniedz ierobežojumu. Ja tas pārsniedz, pieprasījums tiek noraidīts vai aizkavēts.

"Bīdošais" aspekts izriet no tā, ka logs virzās uz priekšu laikā, kad pienāk jauni pieprasījumi. Kad pašreizējais logs beidzas, sākas jauns logs un skaitītājs tiek atjaunots. Pastāv divas galvenās Bīdošā loga algoritma variācijas: Bīdošais žurnāls un Fiksētā loga skaitītājs.

2.1. Bīdošais žurnāls

Bīdošā žurnāla algoritms uztur laika zīmogu žurnālu par katru pieprasījumu, kas veikts noteiktā laika posmā. Kad pienāk jauns pieprasījums, tas summē visus žurnālā esošos pieprasījumus, kas ietilpst logā, un salīdzina to ar pieprasījumu ierobežojumu. Tas ir precīzs, taču var būt dārgs atmiņas un apstrādes jaudas ziņā.

2.2. Fiksētā loga skaitītājs

Fiksētā loga skaitītāja algoritms sadala laiku fiksētos logos un uztur skaitītāju katram logam. Kad pienāk jauns pieprasījums, algoritms palielina pašreizējā loga skaitītāju. Ja skaitītājs pārsniedz ierobežojumu, pieprasījums tiek noraidīts. Tas ir vienkāršāk nekā bīdošais žurnāls, taču tas var atļaut pieprasījumu uzplūdu divu logu robežā.

Bīdošā loga ieviešana Python (Fiksētā loga skaitītājs)

Šeit ir Bīdošā loga algoritma Python ieviešana, izmantojot fiksētā loga skaitītāja pieeju:

import time
import threading

class SlidingWindowCounter:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size  # seconds
        self.max_requests = max_requests
        self.request_counts = {}
        self.lock = threading.Lock()

    def is_allowed(self, client_id):
        with self.lock:
            current_time = int(time.time())
            window_start = current_time - self.window_size

            # Notīrīt vecos pieprasījumus
            self.request_counts = {ts: count for ts, count in self.request_counts.items() if ts > window_start}

            total_requests = sum(self.request_counts.values())

            if total_requests < self.max_requests:
                self.request_counts[current_time] = self.request_counts.get(current_time, 0) + 1
                return True
            else:
                return False


# Piemēra lietošana
window_size = 60  # 60 sekundes
max_requests = 10  # 10 pieprasījumi minūtē
rate_limiter = SlidingWindowCounter(window_size, max_requests)

client_id = "user123"

for i in range(15):
    if rate_limiter.is_allowed(client_id):
        print(f"Pieprasījums {i+1}: Atļauts")
    else:
        print(f"Pieprasījums {i+1}: Ierobežots")
    time.sleep(5)

Paskaidrojums:

• SlidingWindowCounter(window_size, max_requests): Inicializē loga izmēru (sekundēs) un maksimālo atļauto pieprasījumu skaitu logā.
• is_allowed(client_id): Pārbauda, vai klientam ir atļauts veikt pieprasījumu. Tas notīra vecos pieprasījumus ārpus loga, summē atlikušos pieprasījumus un palielina pašreizējā loga skaitītāju, ja limits nav pārsniegts.
• self.request_counts: Vārdnīca, kas glabā pieprasījumu laika zīmogus un to skaitu, ļaujot apkopot un tīrīt vecākus pieprasījumus.
• Pavedienu bloķēšana: Izmanto pavedienu bloķēšanu (self.lock), lai nodrošinātu pavedienu drošību vienlaicīgās vidēs.

Bīdošā loga priekšrocības

• Precīzāks: Nodrošina precīzāku pieprasījumu ierobežošanu nekā Žetonu spainis, īpaši Bīdošā žurnāla ieviešana.
• Novērš uzplūdus robežās: Samazina uzplūdu iespējamību divu laika logu robežā (efektīvāk ar Bīdošo žurnālu).

Bīdošā loga trūkumi

• Sarežģītāks: Sarežģītāks ieviešanā un izpratnē, salīdzinot ar Žetonu spaini.
• Lielākas papildu izmaksas: Var radīt lielākas papildu izmaksas, īpaši Bīdošā žurnāla ieviešanā, jo ir jāglabā un jāapstrādā pieprasījumu žurnāli.

Žetonu spainis pret bīdošo logu: detalizēts salīdzinājums

Šeit ir tabula, kas apkopo galvenās atšķirības starp Žetonu spaiņa un Bīdošā loga algoritmiem:

Funkcija	Žetonu spainis	Bīdošais logs
Sarežģītība	Vienkāršāk	Sarežģītāk
Precizitāte	Mazāk precīzs	Precīzāks
Datplūsmas uzplūdu apstrāde	Laba	Laba (īpaši Bīdošais žurnāls)
Papildu izmaksas	Zemākas	Augstākas (īpaši Bīdošais žurnāls)
Ieviešanas piepūle	Vienkāršāka	Grūtāka

Pareizā algoritma izvēle

Izvēle starp Žetonu spaini un Bīdošo logu ir atkarīga no jūsu specifiskajām prasībām un prioritātēm. Apsveriet šādus faktorus:

• Precizitāte: Ja jums nepieciešama ļoti precīza pieprasījumu ierobežošana, parasti priekšroka tiek dota Bīdošā loga algoritmam.
• Sarežģītība: Ja prioritāte ir vienkāršība, Žetonu spaiņa algoritms ir laba izvēle.
• Veiktspēja: Ja veiktspēja ir kritiska, rūpīgi apsveriet Bīdošā loga algoritma, īpaši Bīdošā žurnāla ieviešanas, papildu izmaksas.
• Datplūsmas uzplūdu apstrāde: Abi algoritmi var apstrādāt datplūsmas uzplūdus, taču Bīdošais logs (Bīdošais žurnāls) nodrošina konsekventāku pieprasījumu ierobežošanu uzplūdu apstākļos.
• Mērogojamība: Augsti mērogojamām sistēmām apsveriet sadalīto pieprasījumu ierobežošanas tehniku izmantošanu (aprakstīts zemāk).

Daudzos gadījumos Žetonu spaiņa algoritms nodrošina pietiekamu pieprasījumu ierobežošanas līmeni ar salīdzinoši zemām ieviešanas izmaksām. Tomēr lietojumprogrammām, kurām nepieciešama precīzāka pieprasījumu ierobežošana un kuras var paciest palielināto sarežģītību, Bīdošā loga algoritms ir labāka izvēle.

Sadalītā pieprasījumu ierobežošana

Sadalītās sistēmās, kur vairāki serveri apstrādā pieprasījumus, bieži ir nepieciešams centralizēts pieprasījumu ierobežošanas mehānisms, lai nodrošinātu konsekventu pieprasījumu ierobežošanu visos serveros. Sadalītajai pieprasījumu ierobežošanai var izmantot vairākas pieejas:

• Centralizēta datu krātuve: Izmantojiet centralizētu datu krātuvi, piemēram, Redis vai Memcached, lai uzglabātu pieprasījumu ierobežošanas stāvokli (piemēram, žetonu skaitu vai pieprasījumu žurnālus). Visi serveri piekļūst un atjaunina kopīgo datu krātuvi, lai ieviestu pieprasījumu ierobežojumus.
• Slodzes balansētāja pieprasījumu ierobežošana: Konfigurējiet savu slodzes balansētāju, lai veiktu pieprasījumu ierobežošanu, pamatojoties uz IP adresi, lietotāja ID vai citiem kritērijiem. Šī pieeja var atbrīvot jūsu lietojumprogrammu serverus no pieprasījumu ierobežošanas.
• Īpašs pieprasījumu ierobežošanas pakalpojums: Izveidojiet īpašu pieprasījumu ierobežošanas pakalpojumu, kas apstrādā visus pieprasījumu ierobežošanas pieprasījumus. Šo pakalpojumu var mērogot neatkarīgi un optimizēt veiktspējai.
• Klienta puses pieprasījumu ierobežošana: Lai gan tā nav primārā aizsardzība, informējiet klientus par viņu pieprasījumu ierobežojumiem, izmantojot HTTP galvenes (piemēram, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset). Tas var mudināt klientus pašiem regulēt savu ātrumu un samazināt nevajadzīgus pieprasījumus.

Šeit ir piemērs, kā izmantot Redis ar Žetonu spaiņa algoritmu sadalītai pieprasījumu ierobežošanai:

import redis
import time

class RedisTokenBucket:
    def __init__(self, redis_client, bucket_key, capacity, fill_rate):
        self.redis_client = redis_client
        self.bucket_key = bucket_key
        self.capacity = capacity
        self.fill_rate = fill_rate

    def consume(self, tokens):
        now = time.time()
        capacity = self.capacity
        fill_rate = self.fill_rate

        # Lua skripts atomiskai žetonu spaiņa atjaunināšanai Redis
        script = '''
        local bucket_key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local fill_rate = tonumber(ARGV[2])
        local tokens_to_consume = tonumber(ARGV[3])
        local now = tonumber(ARGV[4])

        local last_refill = redis.call('get', bucket_key .. ':last_refill')
        if not last_refill then
            last_refill = now
            redis.call('set', bucket_key .. ':last_refill', now)
        else
            last_refill = tonumber(last_refill)
        end

        local tokens = redis.call('get', bucket_key .. ':tokens')
        if not tokens then
            tokens = capacity
            redis.call('set', bucket_key .. ':tokens', capacity)
        else
            tokens = tonumber(tokens)
        end

        -- Uzpildīt spaini
        local time_since_last_refill = now - last_refill
        local tokens_to_add = time_since_last_refill * fill_rate
        tokens = math.min(capacity, tokens + tokens_to_add)

        -- Patērēt žetonus
        if tokens >= tokens_to_consume then
            tokens = tokens - tokens_to_consume
            redis.call('set', bucket_key .. ':tokens', tokens)
            redis.call('set', bucket_key .. ':last_refill', now)
            return 1  -- Panākumi
        else
            return 0  -- Ierobežots pieprasījums
        end
        '''

        # Izpildīt Lua skriptu
        consume_script = self.redis_client.register_script(script)
        result = consume_script(keys=[self.bucket_key], args=[capacity, fill_rate, tokens, now])
        return result == 1


# Piemēra lietošana
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
bucket = RedisTokenBucket(redis_client, bucket_key='my_api:user123', capacity=10, fill_rate=2)

for i in range(15):
    if bucket.consume(1):
        print(f"Pieprasījums {i+1}: Atļauts")
    else:
        print(f"Pieprasījums {i+1}: Ierobežots")
    time.sleep(0.2)

Svarīgi apsvērumi sadalītām sistēmām:

• Atomiskums: Nodrošiniet, lai žetonu patēriņa vai pieprasījumu skaitīšanas operācijas būtu atomiskas, lai novērstu sacensību apstākļus. Redis Lua skripti nodrošina atomiskas operācijas.
• Aizkave: Samaziniet tīkla aizkavi, piekļūstot centralizētajai datu krātuvei.
• Mērogojamība: Izvēlieties datu krātuvi, kas spēj mērogoties, lai apstrādātu paredzamo slodzi.
• Datu konsekvence: Risiniet potenciālās datu konsekvences problēmas sadalītās vidēs.

Labākā prakse pieprasījumu ierobežošanā

Šeit ir dažas labākās prakses, kas jāievēro, ieviešot pieprasījumu ierobežošanu:

• Definējiet pieprasījumu ierobežošanas prasības: Nosakiet atbilstošos pieprasījumu ierobežojumus dažādiem API galapunktiem un lietotāju grupām, pamatojoties uz to lietošanas paradumiem un resursu patēriņu. Apsveriet iespēju piedāvāt dažādu līmeņu piekļuvi, pamatojoties uz abonementa līmeni.
• Izmantojiet jēgpilnus HTTP statusa kodus: Atgrieziet atbilstošus HTTP statusa kodus, lai norādītu uz pieprasījumu ierobežošanu, piemēram, 429 Too Many Requests.
• Iekļaujiet pieprasījumu ierobežojuma galvenes: Iekļaujiet pieprasījumu ierobežojuma galvenes jūsu API atbildēs, lai informētu klientus par viņu pašreizējo pieprasījumu ierobežojuma statusu (piemēram, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).
• Nodrošiniet skaidrus kļūdu ziņojumus: Sniedziet informatīvus kļūdu ziņojumus klientiem, kad viņu pieprasījumi tiek ierobežoti, paskaidrojot iemeslu un ierosinot, kā atrisināt problēmu. Nodrošiniet atbalsta kontaktinformāciju.
• Ieviesiet pakāpenisku degradāciju: Kad tiek piemērota pieprasījumu ierobežošana, apsveriet iespēju nodrošināt degradētu pakalpojumu, nevis pilnībā bloķēt pieprasījumus. Piemēram, piedāvājiet kešatmiņā saglabātus datus vai samazinātu funkcionalitāti.
• Uzraugiet un analizējiet pieprasījumu ierobežošanu: Uzraugiet savu pieprasījumu ierobežošanas sistēmu, lai identificētu potenciālās problēmas un optimizētu tās veiktspēju. Analizējiet lietošanas paradumus, lai pēc vajadzības pielāgotu pieprasījumu ierobežojumus.
• Nodrošiniet savu pieprasījumu ierobežošanu: Novērsiet lietotājiem iespēju apiet pieprasījumu ierobežojumus, validējot pieprasījumus un ieviešot atbilstošus drošības pasākumus.
• Dokumentējiet pieprasījumu ierobežojumus: Skaidri dokumentējiet savas pieprasījumu ierobežošanas politikas jūsu API dokumentācijā. Nodrošiniet piemēru kodu, kas parāda klientiem, kā apstrādāt pieprasījumu ierobežojumus.
• Pārbaudiet savu ieviešanu: Rūpīgi pārbaudiet savu pieprasījumu ierobežošanas ieviešanu dažādos slodzes apstākļos, lai pārliecinātos, ka tā darbojas pareizi.
• Apsveriet reģionālās atšķirības: Ieviešot globāli, ņemiet vērā reģionālās atšķirības tīkla latentumā un lietotāju uzvedībā. Iespējams, būs jāpielāgo pieprasījumu ierobežojumi, pamatojoties uz reģionu. Piemēram, mobilajiem pakalpojumiem orientētam tirgum, piemēram, Indijai, var būt nepieciešami atšķirīgi pieprasījumu ierobežojumi, salīdzinot ar augstas joslas platuma reģionu, piemēram, Dienvidkoreju.

Reālās pasaules piemēri

• Twitter: Twitter plaši izmanto pieprasījumu ierobežošanu, lai aizsargātu savu API no ļaunprātīgas izmantošanas un nodrošinātu godīgu lietošanu. Tie nodrošina detalizētu dokumentāciju par saviem pieprasījumu ierobežojumiem un izmanto HTTP galvenes, lai informētu izstrādātājus par viņu pieprasījumu ierobežojuma statusu.
• GitHub: GitHub arī izmanto pieprasījumu ierobežošanu, lai novērstu ļaunprātīgu izmantošanu un uzturētu savas API stabilitāti. Tie izmanto IP balstītu un lietotāja balstītu pieprasījumu ierobežojumu kombināciju.
• Stripe: Stripe izmanto pieprasījumu ierobežošanu, lai aizsargātu savu maksājumu apstrādes API no krāpnieciskām darbībām un nodrošinātu uzticamu pakalpojumu saviem klientiem.
• E-komercijas platformas: Daudzas e-komercijas platformas izmanto pieprasījumu ierobežošanu, lai aizsargātos pret botu uzbrukumiem, kas mēģina iegūt informāciju par produktiem vai veikt pakalpojumu atteikuma uzbrukumus zibakciju laikā.
• Finanšu iestādes: Finanšu iestādes ievieš pieprasījumu ierobežošanu savās API, lai novērstu nesankcionētu piekļuvi sensitīviem finanšu datiem un nodrošinātu atbilstību normatīvajām prasībām.

Secinājums

Pieprasījumu ierobežošana ir būtiska metode jūsu API aizsardzībai un lietojumprogrammu stabilitātes un uzticamības nodrošināšanai. Žetonu spaiņa un Bīdošā loga algoritmi ir divas populāras iespējas, katrai no tām ir savas stiprās un vājās puses. Izprotot šos algoritmus un ievērojot labāko praksi, jūs varat efektīvi ieviest pieprasījumu ierobežošanu savās Python lietojumprogrammās un veidot noturīgākas un drošākas sistēmas. Atcerieties ņemt vērā savas īpašās prasības, rūpīgi izvēlēties atbilstošo algoritmu un uzraudzīt tā ieviešanu, lai nodrošinātu, ka tas atbilst jūsu vajadzībām. Mērogojot lietojumprogrammu, apsveriet sadalīto pieprasījumu ierobežošanas tehniku ieviešanu, lai uzturētu konsekventu pieprasījumu ierobežošanu visos serveros. Neaizmirstiet par skaidras komunikācijas nozīmi ar API patērētājiem, izmantojot pieprasījumu ierobežojuma galvenes un informatīvus kļūdu ziņojumus.