Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Grundlegendes zu Feature-Flag-Regeln mit mehreren Varianten
Wenn Sie eine Feature-Flag-Variante erstellen, geben Sie eine Regel dafür an. Regeln sind Ausdrücke, die Kontextwerte als Eingabe verwenden und als Ausgabe ein boolesches Ergebnis erzeugen. Sie könnten beispielsweise eine Regel definieren, um eine Flag-Variante für Beta-Benutzer auszuwählen, die anhand ihrer Konto-ID identifiziert werden, um eine Aktualisierung der Benutzeroberfläche zu testen. Für dieses Szenario gehen Sie wie folgt vor:
1. Erstellen Sie ein neues Feature-Flag-Konfigurationsprofil mit dem Namen *UI Refresh*.
1. Erstellen Sie ein neues Feature-Flag namens *ui\_refresh*.
1. Bearbeiten Sie das Feature-Flag, nachdem Sie es erstellt haben, um Varianten hinzuzufügen.
1. Erstellen und aktivieren Sie eine neue Variante namens *BetaUsers*.
1. Definieren Sie eine Regel für *BetaUsers*die Auswahl der Variante, wenn die Konto-ID aus dem Anforderungskontext in einer Liste von Konto-IDs enthalten ist, die für die Nutzung der neuen Beta-Version zugelassen sind.
1. Vergewissern Sie sich, dass der Status der Standardvariante auf **Deaktiviert** gesetzt ist.
**Anmerkung**
Varianten werden anhand der Reihenfolge, in der sie in der Konsole definiert sind, als geordnete Liste bewertet. Die Variante ganz oben in der Liste wird zuerst ausgewertet. Wenn keine Regeln mit dem angegebenen Kontext übereinstimmen, wird die Standardvariante AWS AppConfig zurückgegeben.
Bei AWS AppConfig der Verarbeitung der Feature-Flag-Anforderung wird der angegebene Kontext, der die AccountID (für dieses Beispiel) enthält, zuerst mit der BetaUsers Variante verglichen. Wenn der Kontext der Regel für entspricht BetaUsers, werden die Konfigurationsdaten für das Beta-Erlebnis AWS AppConfig zurückgegeben. Wenn der Kontext keine Konto-ID enthält oder wenn die Konto-ID auf etwas anderes als 123 endet, werden Konfigurationsdaten für die Standardregel AWS AppConfig zurückgegeben, was bedeutet, dass der Benutzer das aktuelle Erlebnis in der Produktionsumgebung aufruft.
**Anmerkung**
Informationen zum Abrufen von Feature-Flags mit mehreren Varianten finden Sie unter. [Feature-Flags für grundlegende und variantenreiche Funktionen werden abgerufen](appconfig-integration-retrieving-feature-flags.md)
## Den Split-Operator verstehen
Im folgenden Abschnitt wird beschrieben, wie sich der `split` Operator verhält, wenn er in verschiedenen Szenarien verwendet wird. Zur Erinnerung: Es wird `true` für einen bestimmten Prozentsatz des Datenverkehrs auf der Grundlage eines konsistenten Hashwerts des angegebenen Kontextwerts `split` ausgewertet. Um dies besser zu verstehen, stellen Sie sich das folgende Basisszenario vor, das Split mit zwei Varianten verwendet:
```
A: (split by::$uniqueId pct::20)
C:
```
Erwartungsgemäß ergibt die Bereitstellung einer zufälligen Menge von `uniqueId` Werten eine Verteilung, die ungefähr:
```
A: 20%
C: 80%
```
Wenn Sie eine dritte Variante hinzufügen, aber denselben aufgeteilten Prozentsatz wie folgt verwenden:
```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C:
```
Am Ende erhalten Sie die folgende Verteilung:
```
A: 20%
B: 0%
C: 80%
```
Diese potenziell unerwartete Verteilung tritt auf, weil jede Variantenregel der Reihe nach ausgewertet wird und die erste Übereinstimmung die zurückgegebene Variante bestimmt. Wenn Regel A ausgewertet wird, stimmen 20% der `uniqueId` Werte mit ihr überein, sodass die erste Variante zurückgegeben wird. Als Nächstes wird Regel B ausgewertet. Alle `uniqueId` Werte, die mit der zweiten Split-Anweisung übereinstimmen würden, wurden jedoch bereits durch Variantenregel A abgeglichen, sodass keine Werte mit B übereinstimmen. Stattdessen wird die Standardvariante zurückgegeben.
Betrachten Sie nun ein drittes Beispiel.
```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C:
```
Wie im vorherigen Beispiel entsprechen die ersten 20% der `uniqueId` Werte Regel A. Bei Variante B würden 25% aller `uniqueId` Werte übereinstimmen, aber die meisten der Werte, die zuvor mit Regel A übereinstimmten, so dass 5% der Gesamtsumme für Variante B übrig bleiben und der Rest Variante C erhält. Die Verteilung würde wie folgt aussehen:
```
A: 20%
B: 5%
C: 75%
```
**Verwendung der `seed` Eigenschaft**
Sie können die `seed` Eigenschaft verwenden, um sicherzustellen, dass der Datenverkehr für einen bestimmten Kontextwert konsistent aufgeteilt wird, unabhängig davon, wo der Split-Operator verwendet wird. Wenn Sie nichts angeben`seed`, ist der Hash *lokal* konsistent, was bedeutet, dass der Verkehr für dieses Flag konsistent aufgeteilt wird, aber andere Flags, die denselben Kontextwert erhalten, den Verkehr möglicherweise anders aufteilen. Wenn angegeben, `seed` wird garantiert, dass jeder eindeutige Wert den Datenverkehr konsistent auf Feature-Flags, Konfigurationsprofile und aufteilt AWS-Konten.
In der Regel verwenden Kunden denselben `seed` Wert für alle Varianten innerhalb eines Flags, wenn sie den Traffic auf dieselbe Kontexteigenschaft aufteilen. Gelegentlich kann es jedoch sinnvoll sein, einen anderen Startwert zu verwenden. Hier ist ein Beispiel, das unterschiedliche Ausgangswerte für die Regeln A und B verwendet:
```
A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C:
```
Wie zuvor entsprechen 20% der übereinstimmenden `uniqueId` Werte Regel A. Das bedeutet, dass 80% der Werte durchfallen und anhand der Variantenregel B getestet werden. Da es sich um einen anderen Ausgangswert handelt, besteht keine Korrelation zwischen den Werten, die mit A übereinstimmen, und den Werten, die B entsprechen. Es müssen jedoch nur 80% so viele `uniqueId` Werte aufgeteilt werden, wobei 25% dieser Zahl Regel B entsprechen und 75% nicht. Das ergibt die folgende Verteilung:
```
A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%)
C: 60%
```