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. # Standardwerte für Amazon MQ für RabbitMQ Broker Wenn Sie einen Amazon MQ für RabbitMQ Broker erstellen, wendet Amazon MQ einen Standardsatz von Broker-Richtlinien und vhost-Limits an, um die Leistung Ihres Brokers zu optimieren. Amazon MQ wendet Vhost-Beschränkungen nur auf den Standardwert (`/`) vhost an. Amazon MQ wendet keine Standardrichtlinien auf neu erstellte vhosts an. Wir empfehlen, diese Standardwerte für alle neuen und bestehenden Broker beizubehalten. Sie können diese Standardwerte jedoch jederzeit ändern, überschreiben oder löschen. Amazon MQ erstellt unterschiedliche Broker-Richtlinien und Vhost-Limits für Amazon MQ for RabbitMQ 3 und RabbitMQ 4. Die Unterschiede werden in den folgenden Unterabschnitten ausführlich erörtert. Amazon MQ erstellt Richtlinien und Limits basierend auf dem Instance-Typ und dem Broker-Bereitstellungsmodus, den Sie beim Erstellen Ihres Brokers auswählen. Die Standardrichtlinien werden gemäß dem Bereitstellungsmodus wie folgt benannt: **Amazon MQ für RabbitMQ 3:** + **Einzelne Instance** – `AWS-DEFAULT-POLICY-SINGLE-INSTANCE` + **Cluster-Bereitstellung — &&** `AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ` `AWS-DEFAULT-QUORUM-QUEUES-POLICY-CLUSTER-MULTI-AZ` **Amazon MQ für RabbitMQ 4:** + **Einzelne Instance** – `AWS-DEFAULT-POLICY-SINGLE-INSTANCE` + **Cluster-Bereitstellung — &&** `AWS-DEFAULT-POLICY-CLUSTER` `AWS-DEFAULT-QUORUM-QUEUES-POLICY-CLUSTER-MULTI-AZ` Für[Single-Instance-Broker](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-single-instance)festgelegt ist, legt Amazon MQ den Richtlinienprioritätswert auf`0`. Um den Standardprioritätswert zu überschreiben, können Sie eigene benutzerdefinierte Richtlinien mit höheren Prioritätswerten erstellen. Für [Cluster-Bereitstellungen](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster), setzt Amazon MQ den Prioritätswert auf`1`für Broker-Standardwerte fest. Um eine eigene benutzerdefinierte Richtlinie für Cluster zu erstellen, weisen Sie einen Prioritätswert zu, der größer als`1` ist. **Anmerkung** In Clusterbereitstellungen `ha-mode` und `ha-sync-mode` Broker-Richtlinien sind für die klassische Spiegelung und Hochverfügbarkeit (HA) erforderlich. Diese Einstellungen gelten nur für Amazon MQ für RabbitMQ 3 und sind nicht für RabbitMQ 4 konfiguriert. Wenn Sie die Standardeinstellung`AWS-DEFAULT-POLICY-CLUSTER-MULTI-AZ`-Richtlinie verwenden, verwendet Amazon MQ die`ha-all-AWS-OWNED-DO-NOT-DELETE`-Richtlinie mit dem Prioritätswert`0`. Dadurch wird sichergestellt, dass die erforderlichen `ha-mode` und `ha-sync-mode`-Richtlinien weiterhin in Kraft sind. Wenn Sie Ihre eigene benutzerdefinierte Richtlinie erstellen, hängt Amazon MQ automatisch `ha-mode` und `ha-sync-mode` zu Ihren Richtliniendefinitionen an. **Topics** + [Richtlinien- und Grenzbeschreibungen](#rabbitmq-defaults-descriptions) + [Empfohlene Standardwerte](#rabbitmq-defaults-values) ## Richtlinien- und Grenzbeschreibungen In der folgenden Liste werden die Standardrichtlinien und -beschränkungen beschrieben, die Amazon MQ für einen neu erstellten Broker anwendet. Die Werte für`max-length`,`max-queues`, und `max-connections` variieren je nach Instance-Typ und Bereitstellungsmodus Ihres Brokers. Diese Werte werden im Feld Abschnitts [Empfohlene Standardwerte](#rabbitmq-defaults-values) erstellt. **Einstellungen sowohl bei RabbitMQ 3- als auch bei RabbitMQ 4-Brokern** + **`queue-mode: lazy`**(Richtlinie) — Aktiviert Lazy-Warteschlangen. Standardmäßig halten Warteschlangen einen In-Memory-Cache von Nachrichten, so dass der Broker Nachrichten so schnell wie möglich an Verbraucher senden kann. Dies kann dazu führen, dass der Broker der Speicher ausläuft und einen Alarm mit hohem Speicher auslöst. Lazy Queues versuchen, Nachrichten so früh wie möglich auf den Datenträger zu verschieben. Dies bedeutet, dass unter normalen Betriebsbedingungen weniger Meldungen im Speicher gespeichert werden. Amazon MQ für RabbitMQ kann mithilfe von Lazy Queues viel größere Messaging-Lasten und längere Warteschlangen unterstützen. Beachten Sie, dass in bestimmten Anwendungsfällen Broker mit faulen Warteschlangen möglicherweise geringfügig langsamer ausgeführt werden. Dies liegt daran, dass Nachrichten vom Datenträger zu Broker verschoben werden, anstatt Nachrichten aus einem In-Memory-Cache zu übermitteln. **Bereitstellungsmodi** Ein Single-Instance-Cluster + **`max-length: {{number-of-messages}}`**(Richtlinie) — Legt ein Limit für die Anzahl der Nachrichten in einer Warteschlange fest. In Clusterbereitstellungen verhindert das Limit die angehaltene Warteschlangensynchronisierung in Fällen wie Broker-Neustarts oder im Anschluss an ein Wartungsfenster. **Bereitstellungsmodi** Cluster + **`overflow: reject-publish`**(policy) — Erzwingt Warteschlangen mit einem`max-length`Um neue Nachrichten abzulehnen, nachdem die Anzahl der Nachrichten in der Warteschlange den`max-length`Wert erreicht. Um sicherzustellen, dass Nachrichten nicht verloren gehen, wenn sich eine Warteschlange in einem Überlaufzustand befindet, müssen Clientanwendungen, die Nachrichten an den Broker [Herausgeber bestätigt](best-practices-message-reliability.md#configure-confirmation-acknowledgement) implementieren. Weitere Informationen zur Implementierung von Publisher-Bestätigungen finden Sie unter [Herausgeber bestätigt](https://www.rabbitmq.com/confirms.html#publisher-confirms) auf der RabbitMQ-Website. **Bereitstellungsmodi** Cluster **Spezifische Einstellungen für RabbitMQ 3** + **`max-queues: {{number-of-queues-per-vhost}}`**(vhost-Limit) — Legt das Limit für die Anzahl der Warteschlangen in einem Broker fest. Ähnlich wie bei `max-length`-Richtliniendefinition verhindert die Begrenzung der Anzahl der Warteschlangen in Clusterbereitstellungen die angehaltene Warteschlangensynchronisierung nach Broker-Neustarts oder Wartungsfenstern. Durch das Beschränken von Warteschlangen wird auch eine übermäßige CPU-Auslastung für die Wartung von Warteschlangen verhindert. **Bereitstellungsmodi** Ein Single-Instance-Cluster + **`max-connections: {{number-of-connections-per-vhost}}`**(vhost-Limit) — Legt das Limit für die Anzahl der Clientverbindungen zum Broker fest. Die Begrenzung der Anzahl an Verbindungen gemäß den empfohlenen Werten verhindert eine übermäßige Broker-Speicherauslastung, die dazu führen könnte, dass der Broker einen Speicher-Alarm auslöst und Operationen pausiert. **Bereitstellungsmodi** Ein Single-Instance-Cluster ## Empfohlene Standardwerte **Wichtig** `max-queues`und `max-connections` gelten nur für Amazon MQ für RabbitMQ 3. **Anmerkung** Die `max-length` und `max-queue` Standardlimits werden basierend auf einer durchschnittlichen Nachrichtengröße von 5 kB getestet und ausgewertet. Wenn Ihre Nachrichten deutlich größer als 5 kB sind, müssen Sie die`max-length` und `max-queue`-Beschränkungen. In der folgenden Tabelle finden Sie die Standardgrenzwerte für einen neu erstellten Broker. Amazon MQ wendet diese Werte entsprechend dem Instance-Typ und dem Bereitstellungsmodus des Brokers an. - **mq.m7g.medium** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 2.500 / **`max-connections`:** 100 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 500 000 / **`max-queues`:** 100 / **`max-connections`:** 100 - **mq.m7g. groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 20 000 / **`max-connections`:** 5,000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 8.000.000 / **`max-queues`:** 10.000 / **`max-connections`:** 5,000 - **mq. 7 g. x groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 30 000 / **`max-connections`:** 10.000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 9.000.000 / **`max-queues`:** 15 000 / **`max-connections`:** 10.000 - **qm 7 g 2 x groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 40 000 / **`max-connections`:** 20 000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 10 000 000 / **`max-queues`:** 40 000 / **`max-connections`:** 20 000 - **mq.m7g.4xgroß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 60 000 / **`max-connections`:** 40 000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 12.000.000 / **`max-queues`:** 30 000 / **`max-connections`:** 40 000 - **mq. 7 g. 8 x groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 80 000 / **`max-connections`:** 80 000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 20,000,000 / **`max-queues`:** 40 000 / **`max-connections`:** 80 000 - **mq.m7g.12x groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 100 000 / **`max-connections`:** 120.000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 30.000.000 / **`max-queues`:** 20 000 / **`max-connections`:** 120.000 - **mq. 7 g. 16 x groß** - **Bereitstellungsmodus:** Single-Instance / **`max-length`:** – / **`max-queues`:** 120.000 / **`max-connections`:** 160 000 - **Bereitstellungsmodus:** Cluster / **`max-length`:** 40.000.000 / **`max-queues`:** 50 000 / **`max-connections`:** 160 000 | Instance-Typ | Bereitstellungsmodus | `max-length` | `max-queues` | `max-connections` | | --- | --- | --- | --- | --- | | t3.micro | Single-Instance | – | 500 | 500 | | m5.large | Single-Instance | – | 20 000 | 4.000 | | m5.large | Cluster | 8.000.000 | 10.000 | 15 000 | | m5.xlarge | Single-Instance | – | 30 000 | 8 000 | | m5.xlarge | Cluster | 9.000.000 | 10.000 | 20 000 | | m5.2xlarge | Single-Instance | – | 60 000 | 15 000 | | m5.2xlarge | Cluster | 10 000 000 | 10.000 | 40 000 | | m5.4xlarge | Single-Instance | – | 150.000 | 30 000 | | m5.4xlarge | Cluster | 12.000.000 | 10.000 | 100 000 |