közben jobban belemélyedtem a redises témába, és mint kiderült, a redisnél a SETNX/SET NX EX hívások bizony nem majdnem atomikusak, hanem *teljesen* atomikusak (nem is csoda, főleg ha figyelembe vesszük, hogy a redis single thread/single process alapon megy, tehát minden bejövő kérés várósorba kerül, ha éppen fut valami). tehát biztosított, hogy ha két kérés is befut szorosan egymás után ugyanarra a resource ID lockra, akkor a queueing miatt az egyik meg fogja kapni a lockot, a másik meg nem, és pötty.
ugyan blocking típusú lockot nem tud a redis natívan, de spinlock-kal meg lehet oldani a dolgot kliens oldalon. ráadásul a SET NX EX formátumban expiration is megadható a lockhoz, tehát ha be is halna az eredeti lockot tartó processz, az egy adott idő után felszabadul, és pöröghet tovább a rendszer. így már csak az az egy kérdés marad, hogy mennyi időre kérjem a lockot, amit viszont be tudok lőni úgy, hogy a spinlock expiration (merthogy azt sem engedem a világ végéig pörögni magában) alá essen mondjuk 1-2 ciklussal, így, ha a php script sokáig is blokkolna, előbb-utóbb biztosan végrehajtaná a műveletet.
no meg ott az az előny is, hogy redis kliens nagyjából mindenhez van natívan, és pont a lockolásra kitalált redises megoldásokkal is teli a net.
(arról aztán végképp nem beszélve, hogy bár az elején biztosan memcached-et fogunk használni a serverwide változókra és a megosztott session kezelésre (mert azt már teszteltük, és működik), később lehet, hogy az is átkerülne redisre.)