Fejlretningsproblemer med datakorruption #
Et problem, der kan være svært at fejlfinde, er, hvis den samme RedisClient
instans deles på tværs af flere tråde, hvilket kan resultere i returnering af beskadigede data. Typisk er dette et resultat af brug af IRedisClient
felt i en singleton-instans eller deling af det som en statisk instans. For at forhindre dette skal hver tråd, der bruger Redis, hente redis-klienten i en brugersætning, f.eks.:
using var redis = redisManager.GetClient();
//...
Desværre identificerer opkaldsstedet, som returnerer det korrupte svar eller runtime-undtagelsen, ikke, hvor ellers Redis-klientforekomsten blev brugt. For at hjælpe med at identificere, hvor klientforekomster bliver brugt, kan du hævde, at klienten kun bruges i den tråd, der løste den fra puljen med:
RedisConfig.AssertAccessOnlyOnSameThread = true;
Dette fanger trådens StackTrace, hver gang klienten løses fra puljen, som da det tilføjer en masse overhead, kun bør aktiveres ved fejlfinding af forbindelsesproblemer.
Hvis den registrerer, at klienten bliver tilgået fra en anden tråd, vil den udsende en InvalidAccessException
med meddelelsen, der indeholder de forskellige tråds-id'er og den originale StackTrace hvor klienten blev løst fra puljen. Du kan sammenligne dette med Undtagelsens StackTrace for forhåbentlig at identificere, hvor klienten bliver brugt forkert.
Undgå problemer med samtidig brug #
Hvad skal du være opmærksom på i din kodebase for at forhindre flere samtidige brug af en IRedisClient
eksempel:
- Brug
IRedisClient
redis instansklient i enusing
erklæring - Brug aldrig en klientinstans, efter at den er blevet bortskaffet
- Brug (eller returner) aldrig en "serversamling eller -ressource" (f.eks. Redis.Lists, lås), efter at klienten er blevet bortskaffet
- Opbevar aldrig en Singleton eller
static
instans til en redis-klient (kunIRedisClientsManager
fabrik) - Brug aldrig den samme redis-klient i flere tråde, dvs. lad hver tråd løse deres egen klient fra fabrikken