2

私は、Redis、MongoDb、またはその他の高度にスケーラブルなツールなどの外部Dbsに.NETセッション状態をキャッシュしてもよいかどうかについて調査を行ってきました。

私の調査の結果は、MongoDBにはこの種のことを行うためのより多くの統合がありますが、Redisの方がはるかにパフォーマンスが高く、使用するオプション(キーの有効期限、セットなど)がはるかに多いようです。

RedisClientを実装したServiceStackと呼ばれるこの他のフレームワークがありますが、IMHOの実装方法は、私が望むよりもはるかに結合されています。

 public override object OnGet(CachedOrders request)
    {
        var cacheKey = "some_unique_key_for_order";
        return base.RequestContext.ToOptimizedResultUsingCache(this.CacheClient, cacheKey, () =>
            {
                    //This delegate will be executed if the cache doesn't have an item
                    //with the provided key

                //Return here your response DTO
                //It will be cached automatically
            });
    }

したがって、この調査の後、あなたの意見と、この種のキャッシュをいずれかのアプリに実装したかどうかを知りたいと思います。経験を共有していただけますか?

ありがとう!

4

2 に答える 2

5

ServiceStack のキャッシングは結合されていません。このToOptimizedResultUsingCache()メソッドは、必要最小限のボイラープレートで共通のキャッシング パターンを実装できる便利な拡張メソッドです。このToOptimizedResultメソッドは、IRequestContext からの MimeType と CompressionType に基づいて、最も最適化された結果を返します。たとえば、JSON サービスでは、通常、JSON 応答 DTO の圧縮された出力になります。

拡張メソッドを使用する必要はなく、ICacheClient APIはクラスの自動配線プロパティであるため、直接アクセスできますServiceBase。ICacheClient API が提供できる以上の機能が必要な場合は、RedisServiceStack の C# RedisClientを使用することをお勧めします。これにより、分散された comp-sci コレクションへの高速でアトミックなアクセスが可能になります。

APIを使用する利点はICacheClient、現在InMemory、Redis、および Memcached プロバイダーを持つ、テスト可能な実装に依存しないキャッシュ インターフェイスであることです。

于 2012-05-13T15:52:04.750 に答える
0

この 2 年前に NuGet パッケージを作成し、それ以来、運用環境で使用しています。SessionStateProvider次のようなさまざまな機能を備えた、Redis への永続性を可能にするカスタム クラスで.NET をオーバーライドします。

  • 値が変更されたときにのみ Redis に書き込む
  • 同じセッション ID を持つ複数のリクエストからの同時セッション アクセス
  • Web API からセッションにアクセスする機能 (ただし、そうするのは REST の原則に違反しますが、気にする必要はありません)
  • シリアル化形式の簡単なカスタマイズ (独自のロールまたは Json 構造の変更)

ここで入手できます: https://www.nuget.org/packages/RedisSessionProvider

ドキュメント: https://github.com/welegan/RedisSessionProvider

于 2014-09-10T14:12:34.667 に答える