1

2ノードのredisデプロイメントに対して実行されているServiceStack.Redisクライアントで遊んでいます。

メソッド ServiceStack.Redis.Support.ConsistentHash.AddTarget は、次のコードを使用してノードを円にマップすることに気付きました。

文字列識別子 = node.GetHashCode().ToString() + "-" + i;

この場合、ノードのタイプは ShardedConnectionPool で、GetHashCode は次のようにオーバーライドされます。

名前を返す.GetHashCode();

これには問題があると思います:

まず第一に、GetHashCode の結果はデプロイメント間で同じであるとは限りません。http://msdn.microsoft.com/en-us/library/system.string.gethashcode.aspxから

「ハッシュ コード自体が安定しているとは限りません。同一の文字列のハッシュ コードは、.NET Framework のバージョン間、および .NET Framework の単一バージョンのプラットフォーム (32 ビットと 64 ビットなど) 間で異なる場合があります」

わずかに異なるインスタンスで実行されているクライアントはキーを異なる方法でマッピングするため、シャーディングの影響はかなり深刻です。

第 2 に、GetHashCode() は他のクラス (Dictionary など) によって依存されており、この実装はいくつかの問題を引き起こす可能性があります。「GetHashCode をオーバーライドする派生クラスは、等しいと見なされる 2 つのオブジェクトが同じハッシュ コードを持つことを保証するために、Equals もオーバーライドする必要があります。そうしないと、Hashtable 型が正しく機能しない可能性があります」など、GetHashCode には多くの要件があります。

の「ノード」タイプに追加の制約を持たないことが意図されていたと思いますが、上記のように、キーを形成するフィールドを提供するメソッドを使用してクラスにインターフェイスを実装することを要求する方がおそらくクリーンです。

簡単な修正として (実際にこの問題に遭遇しました)、名前を返すように ToString() メソッドをオーバーライドし、AddTarget メソッドを調整しました。

考え?

4

0 に答える 0