Redis詳細(一)StackExchange.Redis Client

今回はStackExchange.Redisを見てみましょう.これはredisです.Netクライアントの1つです.Redisは、データベース、キャッシュ、またはMessage Agentサービスに使用できるオープンソースのメモリ・データ・ストレージです.現在、ServiceStack.Redisを使用している人が少なくありません.Netクライアントですが、この最新バージョンは現在ビジネスソフトウェアになっています.ServiceStack.Redisのこのような動作については、低バージョンのオープンソースバージョンを使用するか、他のクライアントに移行するかの選択を残していません.
StackExchangeといえばRedisは、BookSleeveとの関係を言わざるを得ない.BookSleeveはすでに比較的完璧なredis sdkですが、なぜBookSleeveの著者はredisのクライアントsdkを書き直すのでしょうか.興味のある学生はここを見ることができますwhy i wrote another redis clientは、実は一言:不快だと思ったら逆戻りします.
(╯◕◞౪◟◕‵)╯︵ ┴─┴ (╯-_-)╯╧╧ (╯‵□′)╯︵┴─┴ (╯' - ')╯︵ ┻━┻ ┬─┬ ノ
StackExchange.Redisインストール

        NuGet。

PM> Install-Package StackExchange.Redis

強力な署名が必要なバージョンは次のコマンドを実行し、もちろん著者は強力な署名のことに恨みを抱いている.

PM> Install-Package StackExchange.Redis.StrongName

ConnectionMultiplexer
ConnectionMultiplexerオブジェクトはStackExchangeです.Redisの最中枢のオブジェクト.このクラスのインスタンスは、アプリケーションドメイン全体で共有および再利用される必要があります.各操作でオブジェクトのインスタンスを作成し続けないでください.したがって、単一のインスタンスを使用してオブジェクトを作成および保存する必要があります.

    public static ConnectionMultiplexer Manager
    {
        get
        {
            if (_redis == null)
            {
                lock (_locker)
                {
                    if (_redis != null) return _redis;

                    _redis = GetManager();
                    return _redis;
                }
            }

            return _redis;
        }
    }

    private static ConnectionMultiplexer GetManager(string connectionString = null)
    {
        if (string.IsNullOrEmpty(connectionString))
        {
            connectionString = GetDefaultConnectionString();
        }

        return ConnectionMultiplexer.Connect(connectionString);
    }

ConnectionMultiplexerはIDisposableインタフェースを実装していますが、再利用の考慮に基づいて、一般的に解放する必要はありません.
メモリ・データベースとして使用

IDatabase db = redis.GetDatabase();

ここでGetDatabase()が返すdbオブジェクトは軽量レベルであり,キャッシュする必要はなく,毎回持つだけでよい.IDatabaseのすべての方法には同期と非同期の実装がある.その中の非同期実装はawait可能である.
いくつかの基礎的な操作のパッケージ.

    public bool Remove(string key)
    {
        key = MergeKey(key);
        var db = RedisManager.Manager.GetDatabase(Database);

        return db.KeyDelete(key);
    }

    public string Get(string key)
    {
        key = this.MergeKey(key);
        var db = RedisManager.Manager.GetDatabase(Database);

        return db.StringGet(key);
    }

    public bool Set(string key, string value, int expireMinutes = 0)
    {
        key = MergeKey(key);
        var db = RedisManager.Manager.GetDatabase(Database);

        if (expireMinutes > 0)
        {
            db.StringSet(key, value, TimeSpan.FromMinutes(expireMinutes));
        }
        else
        {
            db.StringSet(key, value);
        }

        return db.StringSet(key, value);
    }

    public bool HasKey(string key)
    {
        key = MergeKey(key);
        var db = RedisManager.Manager.GetDatabase(Database);

        return db.KeyExists(key);
    }

ここで、MergeKeyは、Keyのプレフィックスを接続するために使用され、具体的には、異なるビジネスモジュールは、異なるプレフィックスを使用する.
ここでServiceStack.Redisと大きな違いは、デフォルトの接続プール管理がないことです.接続プールがないことにはメリットとデメリットがあります.最大のメリットは、接続の取得を待つ待機時間がなくなり、接続プール内の接続が正しく解放されていないなどの理由で無限に待機しているため、デッドロック状態になることはありません.欠点は、いくつかの低品質のコードがサーバリソースを消費する可能性があることです.しかし、接続プールを提供するなどのブロックと待機の手段は、著者の設計理念に反している.StackExchange.Redisここではパイプと多重化の技術を用いて接続の低減を実現し,ここでは後で議論する.
Message Agentミドルウェアとして使用
メッセージ構築において、重要な概念は生産者、消費者、メッセージミドルウェアである.

ISubscriber sub = redis.GetSubscriber();

まず、まずISubscriberオブジェクトを手に入れます.生産者側では、次のメッセージを発表します.

sub.Publish("messages", "hello");

消費者側でこのメッセージを入手して出力する

sub.Subscribe("messages", (channel, message) => {
    Console.WriteLine((string)message);
});

このようなビジネスシーンを処理するために、よりプロフェッショナルなメッセージキューが一般的に使用されるため、ここでは省略します.
3つのコマンドモード
Sync vs Async vs Fire-and-Forget
最後に、ここでは、StackExchange.Redisの3つの異なる使用シーンに対応する3つのコマンドモードがある.
Syncでは、同期モードは呼び出し元を直接ブロックしますが、他のスレッドはブロックされません.
Async,非同期モードで直接歩いたのはTaskモデルである.
Fire-and-Forgetは、コマンドを送信し、最終的にいつコマンド操作が完了するかは全く気にしません.

db.StringIncrement(pageKey, flags: CommandFlags.FireAndForget);

ここで注目すべきは、Fire-and-Forgetモードでは、false=default(bool)のため、すべてのコマンドがすぐに戻り値を取得します.もちろん、この値は戻り値タイプのデフォルト値です.たとえば、操作戻りタイプがboolであれば、falseがすぐにfalseを取得します.
しっかりと
転載先:https://www.cnblogs.com/bnbqian/p/4962855.html