データ破損の問題のデバッグ#
デバッグが難しい問題は、同じRedisClient
の場合です。 インスタンスは複数のスレッド間で共有されるため、破損したデータが返される可能性があります。通常、これはIRedisClient
を使用した結果です。 シングルトンインスタンスのフィールド、または静的インスタンスとして共有します。これを防ぐには、Redisを使用する各スレッドは、usingステートメント内でredisクライアントを取得する必要があります(例:
using var redis = redisManager.GetClient();
//...
残念ながら、破損した応答またはランタイムExceptionを返す呼び出しサイトは、Redisクライアントインスタンスが使用されていた他の場所を識別しません。クライアントインスタンスが使用されている場所を特定しやすくするために、クライアントがプールから解決されたスレッドでのみ使用されていることを表明できます。
RedisConfig.AssertAccessOnlyOnSameThread = true;
これにより、クライアントがプールから解決されるたびにスレッドのStackTraceがキャプチャされます。これにより、多くのオーバーヘッドが追加されるため、接続の問題をデバッグする場合にのみ有効にする必要があります。
クライアントが別のスレッドからアクセスされていることを検出した場合、InvalidAccessException
をスローします さまざまなスレッドIDを含むメッセージ および元のStackTrace クライアントがプールから解決された場所。これを例外のStackTraceと比較して、クライアントが不適切に使用されている場所を特定できれば幸いです。
同時使用の問題の回避#
IRedisClient
の複数の同時使用を防ぐためにコードベースで注意すべき点 インスタンス:
-
IRedisClient
を使用するusing
内のインスタンスクライアントをredisします ステートメント - 破棄した後はクライアントインスタンスを使用しないでください
- クライアントが破棄された後は、「サーバーコレクションまたはリソース」(Redis.Lists、ロックなど)を使用(または返却)しないでください
- シングルトンまたは
static
を絶対に保持しないでください redisクライアントへのインスタンス(IRedisClientsManager
のみ) 工場) - 複数のスレッドで同じredisクライアントを使用しないでください。つまり、各スレッドにファクトリから独自のクライアントを解決させます