Redis-en gutxien erabilitako proxya modu atomikoan esleitu

Erabili multzo ordenatu bat eta Lua script labur bat proxy baten esleipen-kontagailua hautatzeko eta handitzeko langileen artean.

Hainbat langilek Redis bidez pool bat partekatzen dutenean, multzo ordenatu batek politika sinplea ezar dezake: erregistratutako esleipen gutxien dituen proxy egokia hautatzea. Gorde proxyaren identifikatzailea kide gisa eta haren esleipen-kontagailua puntuazio gisa.

Baimendutako eskaera publikoei zerbitzatzen dien pool baterako, proxy librearen zerrendak amaierako puntuen hautagaiak eman ditzake, pool horren egokitasun-arauen arabera ebaluatzeko. Hasieratu kide egokiak adostutako hasierako kontagailu batekin. Ondoren, egin hautaketa eta gehiketa zerbitzariaren aldeko eragiketa bakar batean:

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 chosen

Pasa multzo ordenatuaren gakoa scriptaren gako-argumentu bakarra bezala zure Redis bezeroaren EVAL interfazearen bidez. Pool huts batek null emaitza sortzen du, aplikazioak eskaerarik egin gabe kudeatu behar duena.

Zergatik konbinatu bi komandoak?

Irakurketa eta gehiketa bereiziek bi langileei gutxieneko bera ikusteko aukera ematen diete, inork eguneratu aurretik. Redisek Lua script bat atomikoki exekutatzen du, beraz beste langile batek ezin du hautaketarik sartu script honen irakurketaren eta gehigarriaren artean. Eduki ezazu scripta labur, haren exekuzioak Redis lan beste bat blokeatzen baitu.

ZRANGEk puntuazio baxuena itzultzen du lehenengo; puntuazio berdinak kideen ordenaren arabera ebazten dira, ez ausaz. ZINCRBYk hautatutako kidearen puntuazioa bat igotzen du hurrengo esleipenerako.

Definitu zer esan nahi duen puntuazioak

Honek esleipenak zenbatzen ditu, sare-eskaera geroago huts egiten duen esleipena barne. Ez du latentzia, eskaera arrakastatsuak edo martxan dagoen lana neurtzen. Kide egoki bakarra behin eta berriz hautatzea oraindik posible da; scriptak ez du esklusiboki erreserbatzen.

Mantendu egokitasuna poolaren osasun- eta politika-arauen bidez. Kide bat kendu eta gero berrezartzen baduzu, erabaki haren kontagailu historikoa mantendu behar den. Berrezarritako proxy bat zerotik abiatzeak esleipenak harengan kontzentra ditzake hura berreskuratzen den bitartean.

Gutxieneko konkurrentzia-politikak beste bizi-ziklo bat behar du, osatzea eta utzitako lanen kudeaketa barne. Ez interpretatu metatze-kontagailu hau bizi-ziklo hori bezala.

Erlazionatutako artikuluak