Felsökning av problem

Felsökning av datakorruptionsproblem #

Ett problem som kan vara svårt att felsöka är om samma RedisClient instans delas över flera trådar vilket kan resultera i att skadad data returneras. Vanligtvis är detta ett resultat av att använda IRedisClient fält i en singleton-instans eller dela det som en statisk instans. För att förhindra detta bör varje tråd som använder Redis hämta redis-klienten i en användningssats, t.ex.:

using var redis = redisManager.GetClient();
//...

Tyvärr identifierar inte samtalsplatsen som returnerar det korrupta svaret eller körtidsundantaget var annars Redis-klientinstansen användes. För att hjälpa till att identifiera var klientinstanser används kan du hävda att klienten endast används i tråden som löste det från poolen med:

RedisConfig.AssertAccessOnlyOnSameThread = true;

Detta fångar trådens StackTrace varje gång klienten löses från poolen, vilket, eftersom det lägger till mycket overhead, endast bör aktiveras vid felsökning av anslutningsproblem.

Om den upptäcker att klienten nås från en annan tråd kommer den att skicka en InvalidAccessException med meddelandet som innehåller de olika tråd-ID:n och original StackTrace där klienten löstes från poolen. Du kan jämföra detta med StackTrace of the Exception för att förhoppningsvis identifiera var klienten används felaktigt.

Undvika problem med samtidig användning #

Vad du ska hålla utkik efter i din kodbas för att förhindra flera samtidig användning av en IRedisClient instans:

• Använd IRedisClient redis instansklient inom en using uttalande
• Använd aldrig en klientinstans efter att den har kasserats
• Använd (eller returnera) aldrig en "serversamling eller -resurs" (t.ex. Redis.Lists, lås) efter att klienten har kasserats
• Behåll aldrig en Singleton eller static instans till en redis-klient (bara IRedisClientsManager fabrik)
• Använd aldrig samma redis-klient i flera trådar, d.v.s. låt varje tråd lösa sin egen klient från fabriken