2017-02-22 2 views
0

Während ich mit azurblauen Stoffdarstellern spiele, hier ist das seltsame Ding, das ich kürzlich herausgefunden habe - ich kann die Standardeinstellungen für die Partitionierung nicht ändern. Wenn ich beispielsweise versuche, Named Partitioning zu setzen oder den Low/High-Key für UniformInt64 zu ändern, wird es jedes Mal überschrieben, wenn ich mein Projekt in Visual Studio erstelle. Es ist kein Problem, dies für den Stateful Service zu tun, es passiert nur mit Schauspielern.Partitionierungsschema für Schauspieler kann nicht geändert werden

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

Aber ich habe keine Erklärungen gesehen - keine Fehler, keine Datensätze in Ereignisprotokoll, kein nichts ... Ich habe nur eine einzige Referenz über das gleiche Problem im Internet - weder auf MSDN noch in offizieller Dokumentation. Irgendwelche Ideen? Wäre es wirklich "von Entwurf"?

P.S.

Wenn Sie nur Powershell-Skript ausführen, um die App zu implementieren, kann ich das Schema so einrichten, wie ich es möchte. Trotzdem ist es frustrierend, dies in VS nicht zu können. Wahrscheinlich gibt es einen guten Grund dafür ... sollte es sein, oder? :)

Antwort

1

Zuverlässige Dienste können mit verschiedenen Partitionsschemata und Partition Schlüsselbereiche erstellt werden. Der Actor-Dienst verwendet das Int64-Partitionierungsschema mit dem vollständigen Int64-Schlüsselbereich, um Akteure zu Partitionen zuzuordnen.

Jede ActorId wird mit Int64 hashed, weshalb der Schauspielerdienst ein Int64-Partitionierungsschema mit dem vollen Int64-Schlüsselbereich verwenden muss. Benutzerdefinierte ID-Werte können jedoch für eine ActorID verwendet werden, einschließlich GUIDs, Zeichenfolgen und Int64s.

Bei der Verwendung von GUIDs und Strings werden die Werte auf Int64 hashed. Wenn Int64 jedoch explizit einer ActorId bereitgestellt wird, wird der Int64 ohne weitere Hashvorgänge direkt auf eine Partition abgebildet. Dies kann werden verwendet, um die Partition Akteure in platziert zu steuern.

(Source)

Diese ActorID => PartitionKey Übersetzungsstrategie funktioniert nicht, wenn Ihre Partitionen genannt werden.

+0

Danke für die Antwort! Ja, ich verstehe, dass ActorID auf eine bestimmte Partition abgebildet wird, aber, da Actor eine Erweiterung über Stateful Service ist, warum kann ich nicht das Gleiche tun und das Schema ändern? Warum können wir keinen Akteur erstellen, der eine Zeichenfolge als ID übergibt und sie einer Partition zuordnet, deren Name genau dieser ID entspricht? Und warum zeigt VS keinen Fehler/keine Warnung und überschreibt stillschweigend meine Einstellungen, ohne mir irgendwelche Hinweise zu geben? –

+0

Wenn Sie einen Actor-Namen haben, der mit einem Partitionsnamen übereinstimmt, begrenzen Sie effektiv die Anzahl der Actor-Instanzen auf die Anzahl Ihrer Partitionen. Dies passt nicht gut zur Actor-Theorie (im Allgemeinen haben Sie viele Actor-Instanzen). Warum VS dich nicht warnt, weiß ich nicht. Sie könnten ein Problem dafür hier erstellen: https://github.com/Azure/service-fabric-issues/issues – LoekD

+0

Danke! Ich habe eine Reihe von Aufgaben, die ich gleichmäßig auf Maschinen verteilen möchte, und die Anzahl der Aufgaben, die doppelt so viele verfügbare Knoten haben. Also dachte ich darüber nach, eine Anzahl von Partitionen auf die Anzahl der Aufgaben zu setzen, und wenn die Zeit gekommen ist, eine Aufgabe auszuführen, würde ich Schauspieler mit der ID eines gegebenen Aufgabennamens instanziiert haben. So konnte ich garantieren, dass ich zu einem bestimmten Zeitpunkt nur eine Aufgabe mit einem bestimmten Namen haben würde (Actors sind Thread-sicher), und da Partitionen gleichmäßig über den Cluster verteilt sind (standardmäßig), würde ich wissen, dass Tasks sind ausgewogen. Macht das Sinn? –

Verwandte Themen