2017-02-22 4 views
0

紺碧のサービスファブリックの俳優と一緒に遊んでいる間、私は最近気がついた奇妙なことです - パーティショニングのデフォルト設定を変更することはできません。 UniformInt64のNamedパーティショニングやLow/Highキーを設定しようとすると、Visual Studioでプロジェクトをビルドするたびに上書きされます。 statefullサービスのためにこれを行うことは問題ありません。それはアクターだけで起こります。エラーは、イベントログ、ノー何にレコードが...私は、インターネット上で同じ問題についてただ1つの参照見つからなかっました -俳優のパーティショニングスキームを変更できません

https://social.msdn.microsoft.com/Forums/vstudio/en-US/4edbf0a3-307b-489f-b936-43af9a365a0a/applicationmanifestxml-overwritten-on-each-build?forum=AzureServiceFabric

をしかし、私はそれに任意の説明を見ていません - どちらもMSD​​Nや公式文書では扱いません。何か案は?それは本当に「設計通り」でしょうか?

P.S.

アプリをデプロイするためのPowerShellスクリプトを実行するだけで、私が望むようにスキームを設定することができます。それでも、VSでこれを行うことができないというのはイライラしています。おそらくそれには正当な理由があるでしょう...そうでしょう、そうですか? :)

答えて

1

信頼性の高いサービスは、異なるパーティション方式と パーティションキー範囲で作成できます。 Actorサービスは、Int64パーティションの スキームを完全なInt64キー範囲で使用して、アクターをパーティションにマップします。

すべてのActorIdがInt64にハッシュされるため、アクターサービス は、Int64キーの完全な範囲でInt64パーティショニングスキームを使用する必要があります。 しかし、GUID、 文字列、およびInt64を含むカスタムID値をActorIDに使用できます。

GUIDと文字列を使用する場合、値はInt64にハッシュされます。 しかし、明示的にInt64をActorIdに提供する場合、Int64 は、それ以上のハッシングなしで直接パーティションにマップされます。これは、中に配置されているパーティション俳優制御する を使用することができます。

Source

パーティションが命名されている場合は、このアクターID =>のPartitionKey翻訳戦略は動作しません。

+0

返信いただきありがとうございます!アクタはステートフルサービスを拡張しているので、なぜ同じことをやってもスキームを変更できないのですか?何故文字列をIDとして渡したアクターを作成し、そのIDと同じ名前のパーティションにマップすることができないのですか? VSが何のエラー/警告も表示せず、私の設定を何も手渡さずに静かに上書きするのはなぜですか? –

+0

パーティション名に一致するアクター名がある場合、アクターインスタンス数を実際にパーティション数に制限します。これは、Actor理論(一般に、あなたは多くのアクターインスタンスを持つでしょう)とうまく行きません。 VSがあなたに警告しない理由は分かりません。ここで問題を作り出すことができます:https://github.com/Azure/service-fabric-issues/issues – LoekD

+0

ありがとう!私は、マシン間で均等に分散したい多くのタスクと、使用可能なノードの2倍の量のタスクの量を持っています。だから私はいくつかのパーティションをタスクの数に設定することを考えました。そして、タスクを実行する時間が来ると、与えられたタスク名のIDでインスタンス化されます。したがって、ある時点で特定の名前を持つ単一のタスク(アクターはスレッドセーフである)を1つしか持たないことを保証することができ、パーティションは(デフォルトで)クラスタ全体に均等に分散されるので、バランスの取れたそれは理にかなっていますか? –