問題タブ [servicestack.redis]

Redis で非常に単純な TTL文字列を実行する方法を探しています。

では、 StackExchange.Redisで以下と同等のことを行うにはどうすればよいでしょうか?

が見つかりましKeyExpireたが、設定したすべてのキーに 2 つの呼び出しが必要ですか?

購読者数など、パブリッシャー アプリに関する統計情報を提供する必要があります。

redisサーバーからその情報を取得するのが見られません

私はすでに「ServiceStack.Redis.RedisSubscription」で見つけようとしました

私はこれを見つけました：

しかし、毎回0を返します。

何か案は？

編集：私はこれを見つけましたhttp://redis.io/commands/client-list しかし、鋼はそれを使用する方法について助けが必要です:)

誰かが AddItemToSet と StoreRelatedEntities をいつ使用するかを理解しようとしています。

前者は、セット ラベルを文字列ベースのアイテム ハンドルに関連付ける方法のようです。

後者は、2 つのエンティティを関連付ける方法であり、より一般化された操作のように見えます。

StoreRelatedEntities ができないことで、AddItemToSet ができることは何ですか?

ありがとう

私はRedisとServiceStack.Redisをクライアントとしていじっています。最初に「AutoMapper」を使用して、キャッシュされたオブジェクトをドメイン オブジェクトにマップしましたが、これはかなり遅かったです。他の人の例を使用して、カスタムマッパーをセットアップしましたが、これも非常に遅いです。

以下のコードに明らかな問題がありますか? Redis から 1000 個のアイテムをマップするのに 4 ～ 5 秒かかります。

ラグを導入しているのは「GetByIds」クライアント メソッドですが、Redis の ID のリストにはこれらをドメイン オブジェクトのリストに変換する別の方法がないため、コレクションを効率的に格納する方法が必要です。

ありがとう！

Redis Store と GetRelatedEntities 呼び出しを使用して、userId をそのユーザーのグループに関連付けています。

サービス呼び出しでは、コストのかかるデータベース呼び出しを呼び出してグループを初めて取得する前に、グループがキャッシュに格納されたことがあるかどうかを確認したいと考えています (これはかなり標準的だと思います)。

その userId に対して StoreRelatedEntities が以前に呼び出されていない場合、GetRelatedEntities 呼び出しは空のリストを返します。ただし、空のリストは、ユーザーがグループを持っていないことを意味する可能性があるため、以前にそのユーザーに対してグループが設定されていないことを確認する方法が必要です。

2 つの状態を区別する方法はありますか?

ありがとう

私は、キューベースのシステムを設計する最初の段階にあり、メッセージのバッキング ストアとしていずれかを使用することの長所と短所を聞きたいと思っています。

大まかな流れ：

ServiceStack の外部 Web サービスは、HTTP メッセージを受信し、それらの DTO を永続的なメッセージ キューにすぐに送信します。この特定のキュー/トピックは PubSub であると想像できます。これは、通知が必要なプロセスが他にもいくつかあるためです。1 つは履歴上の理由からメッセージを保存するプロセスであり、もう 1 つはメッセージ自体に作用して実行するプロセスです。いくつかの操作...リストのサブスクライバー/クライアントは延々と続きます。

ServiceStack と永続的なキュー ベースのメッセージングに関する非常に限られた経験を除いて、これらの線に沿って何かを実装することを妨げているものはありますか?

これまでの私の読書には、次の記事が含まれています。

Redis の永続性

Redis の永続化の謎を解く

ServiceStack - メッセージングと Redis

サービススタック - SMessageService

ServiceStack - RedisMqServerTest

ありがとう、スティーブン

ServiceStack-Redis ライブラリによって提供され、ここで説明されているロック メカニズムを使用して DLM を実装しようとしていますが、API が競合状態を示しているようで、複数のクライアントに同じロックを付与することがあります。

上記のコードを実行して、2 つのクライアントが同じ操作を短い時間連続して試行することをシミュレートすると、3 つの出力が考えられます。最初のケースは、Mutex が適切に機能し、クライアントが適切な順序で処理を進める最適なケースです。2 番目のケースは、2 番目のクライアントがロックの取得を待機中にタイムアウトになった場合です。こちらも納得の結果。ただし、問題はarbitraryDurationOfExecutingCode、ロックを取得するためのタイムアウトに近づくかそれを超えると、1 番目のクライアントがロックを解放する前に 2 番目のクライアントがロックを許可される状況を非常に簡単に再現でき、次のような出力が生成されることです。

client1: ロックを取得しました! (タッチ: 0x)
client2: ロックを取得しました! (タッチ: 0x)
client1: オーケー、ロックを解除しました。今度はあなたの番です。
client2: オーケー、ロックを解除しました。今度はあなたの番です。
合計2回タッチ。

API とそのドキュメントについての私の理解では、ロックを取得するときの引数は、ロックを取得timeOutするためのタイムアウトです。この状態を防ぐためだけに、実行中のコードの継続時間よりも常に長い値を推測する必要がある場合、それはかなりエラーが発生しやすいようです。ロックを永久に待機するために null を渡す以外に回避策がある人はいますか? 私は間違いなくそれをしたくありません。そうしないと、クラッシュしたワーカーからゴーストロックが発生することを知っています。timeOut

すべてのidbclientsが欲しいのですが、redis cliからのスクリプトは何ですか?