Atomikong ilaan ang pinakakaunting ginagamit na proxy sa Redis
Gumamit ng sorted set at maikling Lua script upang piliin at dagdagan ang bilang ng paglalaan ng proxy sa mga worker.
Kapag maraming worker ang nagbabahagi ng pool sa pamamagitan ng Redis, ang sorted set ay makapagpapatupad ng simpleng patakaran: piliin ang karapat-dapat na proxy na may pinakakaunting naitalang paglalaan. Itabi ang identifier ng proxy bilang miyembro at ang bilang ng paglalaan nito bilang iskor.
Para sa pool na nagsisilbi sa pinapayagang pampublikong kahilingan, ang listahan ng libreng proxy ay makapagbibigay ng mga kandidatong endpoint na susuriin ayon sa mga tuntunin ng pagiging karapat-dapat ng pool na iyon. Simulan ang mga karapat-dapat na miyembro sa napagkasunduang panimulang bilang. Pagkatapos ay gawing isang operasyon sa panig ng server ang pagpili at pagdagdag:
local chosen = redis.call('ZRANGE', KEYS[1], 0, 0)[1]
if not chosen then
return nil
end
redis.call('ZINCRBY', KEYS[1], 1, chosen)
return chosenIpasa ang susi ng sorted set bilang nag-iisang argumentong susi ng script sa pamamagitan ng EVAL interface ng iyong Redis client. Ang walang laman na pool ay gumagawa ng null na resulta na dapat harapin ng aplikasyon nang walang kahilingan.
Bakit pagsamahin ang dalawang utos?
Ang hiwalay na pagbasa at pagdagdag ay nagpapahintulot sa dalawang worker na makita ang parehong minimum bago pa ito i-update ng sinuman. Ang Redis ay nagpapatupad ng Lua script nang atomiko, kaya hindi makapagpasok ang ibang worker ng pagpili sa pagitan ng pagbasa at pagdagdag ng script na ito. Panatilihing maikli ang script dahil hinaharangan ng pagpapatupad nito ang ibang gawain ng Redis.
Ibinabalik ng ZRANGE ang pinakamababang iskor muna; ang magkaparehong iskor ay nilulutas ng pagkakasunod-sunod ng miyembro, hindi nang random. Dinadagdagan ng ZINCRBY ng isa ang iskor ng napiling miyembro para sa susunod na paglalaan.
Tukuyin ang kahulugan ng iskor
Binibilang nito ang mga paglalaan, kabilang ang paglalaan na nabigo ang kahilingan sa network sa kalaunan. Hindi nito sinusukat ang latency, matagumpay na kahilingan, o kasalukuyang gawaing nagaganap. Posible pa ring piliin nang paulit-ulit ang nag-iisang karapat-dapat na miyembro; hindi ito inilalaan ng script nang eksklusibo.
Panatilihin ang pagiging karapat-dapat gamit ang mga tuntunin ng kalusugan at patakaran ng pool. Kung aalisin mo ang isang miyembro at ibabalik ito mamaya, magpasya kung pananatilihin ang makasaysayang bilang nito. Ang pagsisimula ng naibalik na proxy sa zero ay maaaring mag-concentrate ng mga paglalaan dito habang nakakabawi ito.
Ang patakaran ng pinakamababang sabay-sabay ay nangangailangan ng ibang lifecycle, kabilang ang pagkumpleto at paghawak ng mga inabandunang trabaho. Huwag bigyang-kahulugan ang cumulative counter na ito bilang lifecycle na iyon.