

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.

# Express-Broker-Konfigurationen
<a name="msk-configuration-express"></a>

Apache Kafka verfügt über Hunderte von Broker-Konfigurationen, mit denen Sie die Leistung Ihres von MSK bereitgestellten Clusters optimieren können. Das Einstellen fehlerhafter oder suboptimaler Werte kann sich auf die Zuverlässigkeit und Leistung des Clusters auswirken. Express-Broker verbessern die Verfügbarkeit und Haltbarkeit Ihrer von MSK bereitgestellten Cluster, indem sie optimale Werte für kritische Konfigurationen festlegen und diese vor häufigen Fehlkonfigurationen schützen. Es gibt drei Kategorien von Konfigurationen, die auf Lese- und Schreibzugriff basieren: Konfigurationen mit [Lese-/Schreibzugriff (bearbeitbar)](msk-configuration-express-read-write.md), Nur-Lese-Konfigurationen und Konfigurationen ohne [Lese-/Schreibzugriff](msk-configuration-express-read-only.md). Einige Konfigurationen verwenden immer noch den Standardwert von Apache Kafka für die Apache Kafka-Version, die auf dem Cluster ausgeführt wird. Wir kennzeichnen diese als Apache Kafka Default.

**Topics**
+ [Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)](msk-configuration-express-read-write.md)
+ [Express vermittelt Konfigurationen, die nur lesbar sind](msk-configuration-express-read-only.md)

# Benutzerdefinierte MSK Express-Broker-Konfigurationen (Lese-/Schreibzugriff)
<a name="msk-configuration-express-read-write"></a>

Sie können read/write Broker-Konfigurationen entweder mithilfe der [Konfigurationsaktualisierungsfunktion von Amazon MSK oder mithilfe der API von Apache Kafka aktualisieren](msk-update-cluster-config.md). AlterConfig Die Apache Kafka-Broker-Konfigurationen sind entweder statisch oder dynamisch. Statische Konfigurationen erfordern einen Broker-Neustart, damit die Konfiguration angewendet werden kann, während dynamische Konfigurationen keinen Broker-Neustart erfordern. Weitere Informationen zu Konfigurationseigenschaften und Aktualisierungsmodi finden Sie unter [Broker-Konfigurationen aktualisieren](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).

**Topics**
+ [Statische Konfigurationen auf MSK Express-Brokern](#msk-configuration-express-static-configuration)
+ [Dynamische Konfigurationen auf Express Brokers](#msk-configuration-express-dynamic-configuration)
+ [Konfigurationen auf Themenebene auf Express Brokers](#msk-configuration-express-topic-configuration)

## Statische Konfigurationen auf MSK Express-Brokern
<a name="msk-configuration-express-static-configuration"></a>

Sie können Amazon MSK verwenden, um eine benutzerdefinierte MSK-Konfigurationsdatei zu erstellen, um die folgenden statischen Eigenschaften festzulegen. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können statische Konfigurationsdateien über die MSK-Konsole oder mithilfe des Befehls [configurations](msk-configuration-operations-create.md) erstellen und aktualisieren.


| Property (Eigenschaft) | Description (Beschreibung) | Standardwert | 
| --- | --- | --- | 
|  allow.everyone.if.no.acl.found  |  Wenn Sie diese Eigenschaft auf false setzen möchten, stellen Sie zunächst sicher, dass Sie Apache Kafka ACLs für Ihren Cluster definieren. Wenn Sie diese Eigenschaft auf false setzen und Apache Kafka nicht zuerst definieren ACLs, verlieren Sie den Zugriff auf den Cluster. In diesem Fall können Sie die Konfiguration erneut aktualisieren und diese Eigenschaft auf true setzen, um wieder Zugriff auf den Cluster zu erhalten.  |  true  | 
|  auto.create.topics.enable  |  Aktiviert die automatische Erstellung eines Themas auf dem Server.  |  false  | 
| compression.type |  Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs: gzip, snappy, lz4, zstd. Diese Konfiguration akzeptiert zusätzlich`uncompressed`, was gleichbedeutend mit keiner Komprimierung ist. Das bedeutet`producer`, dass der ursprüngliche vom Hersteller festgelegte Komprimierungscodec beibehalten wird. | Apache Kafka (Standard) | 
|  connections.max.idle.ms  |  Timeout bei inaktiven Verbindungen in Millisekunden. Die Threads des Server-Socket-Prozessors schließen die Verbindungen, die länger als den von Ihnen für diese Eigenschaft festgelegten Wert inaktiv sind.  |  Apache Kafka Standard  | 
|  delete.topic.enable  |  Aktiviert den Vorgang zum Löschen von Themen. Wenn Sie diese Einstellung deaktivieren, können Sie ein Thema nicht über das Admin-Tool löschen.  |  Apache Kafka Standard  | 
|  group.initial.rebalance.delay.ms  |   Die Zeit, die der Gruppenkoordinator darauf wartet, dass mehr Verbraucher einer neuen Gruppe beitreten, bevor der erste Neuausgleich durchgeführt wird. Eine längere Verzögerung bedeutet potenziell wenigere Neuausgleiche, erhöht aber die Zeit bis zum Beginn der Verarbeitung.  |  Apache Kafka Standard  | 
|  group.max.session.timeout.ms  |  Maximales Sitzungs-Timeout für registrierte Konsumenten. Längere Timeouts verschaffen Verbrauchern mehr Zeit für die Verarbeitung von Nachrichten zwischen Heartbeats, sie führen aber auch zu einer längeren Fehlererkennungszeit.  |  Apache Kafka Standard  | 
|  leader.imbalance.per.broker.percentage  |  Das Verhältnis des zulässigen Führungsungleichgewichts pro Broker. Der Controller löst einen Führungsausgleich aus, wenn er diesen Wert pro Broker übersteigt. Dieser Wert wird in Prozent angegeben.  |  Apache Kafka Standard  | 
| log.cleanup.policy | Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind delete und compact. Für Cluster mit aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. delete | Apache Kafka Standard | 
| log.message.timestamp.after.max.ms |  Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`.  | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) | 
| log.message.timestamp.before.max.ms |  Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`.  | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) | 
| log.message.timestamp.type | Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind CreateTime und LogAppendTime. | Apache Kafka Standard | 
| log.retention.bytes | Maximale Größe des Protokolls vor dem Löschen. | Apache Kafka Standard | 
| log.retention.ms | Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird. | Apache Kafka Standard | 
| max.connections.per.ip | Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, 0 wenn mithilfe der max.connections.per.ip.overrides Eigenschaft Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden gelöscht, wenn das Limit erreicht wird. | Apache Kafka Standard | 
|  max.incremental.fetch.session.cache.slots  |  Maximale Anzahl inkrementeller Abrufsitzungen, die beibehalten werden.  |  Apache Kafka Standard  | 
| message.max.bytes |  Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können. In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Sie können diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen.  | Apache Kafka Standard | 
|  num.partitions  |  Standardanzahl von Partitionen pro Thema.  |  1  | 
|  offsets.retention.minutes  |  Nachdem eine Konsumentengruppe alle Konsumenten verliert (d. h. sie ist dann leer), werden die Offsets für diesen Aufbewahrungszeitraum aufbewahrt, bevor sie verworfen werden. Für eigenständige Benutzer (d. h. Benutzer, die die manuelle Zuweisung verwenden) laufen Offsets nach dem Zeitpunkt der letzten Übertragung zuzüglich dieser Aufbewahrungsfrist ab.  |  Apache Kafka (Standard)  | 
|  replica.fetch.max.bytes  |  Anzahl der Bytes von Nachrichten, die für jede Partition abgerufen werden sollen. Es handelt sich nicht um ein absolutes Maximum. Wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch zurückgegeben, damit Fortschritte gemacht werden können. Die Eigenschaften message.max.bytes (Broker-Konfiguration) oder max.message.bytes (Themenkonfiguration) geben die maximale vom Broker akzeptierte Datensatz-Batch-Größe an.  |  Apache Kafka Standard  | 
|  replica.selector.class  |  Der vollqualifizierte Klassenname, der implementiert wird. ReplicaSelector Der Broker verwendet diesen Wert, um das bevorzugte Lesereplikat zu finden. Wenn Sie es Verbrauchern ermöglichen möchten, Daten vom nächstgelegenen Replikat abzurufen, setzen Sie diese Eigenschaft auf. `org.apache.kafka.common.replica.RackAwareReplicaSelector`  |  Apache Kafka Standard  | 
|  socket.receive.buffer.bytes  |  Der SO\$1RCVBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet.  |  102400  | 
|  socket.request.max.bytes  |  Maximale Anzahl von Bytes in einer Socket-Anforderung.  |  104857600  | 
|  socket.send.buffer.bytes  |  Der SO\$1SNDBUF-Puffer der Socket-Server-Sockets. Wenn der Wert -1 ist, wird der Standardwert des Betriebssystems verwendet.  |  102400  | 
|  transaction.max.timeout.ms  |  Maximales Timeout für Transaktionen. Wenn die angeforderte Transaktionszeit eines Kunden diesen Wert überschreitet, gibt der Broker einen Fehler in InitProducerIdRequest zurück. So wird ein zu großer Timeout auf Client-Seite verhindert, der Verbraucher am Lesen aus Themen, die in der Transaktion vorhanden sind, hindern könnte.  |  Apache Kafka (Standard)  | 
|  transactional.id.expiration.ms  |  Die Zeit in Millisekunden, in der der Transaktionskoordinator auf Aktualisierungen des Transaktionsstatus für die aktuelle Transaktion wartet, bevor der Koordinator seine Transaktions-ID ablaufen lässt. Diese Einstellung beeinflusst auch den Ablauf der Producer-ID, da sie dazu führt IDs , dass der Producer abläuft, wenn diese Zeit nach dem letzten Schreibvorgang mit der angegebenen Producer-ID verstrichen ist. Producer läuft aufgrund der Aufbewahrungseinstellungen für das Thema IDs möglicherweise früher ab, wenn der letzte Schreibvorgang aus der Producer-ID gelöscht wird. Der Mindestwert für diese Eigenschaft ist 1 Millisekunde.  |  Apache Kafka (Standard)  | 

## Dynamische Konfigurationen auf Express Brokers
<a name="msk-configuration-express-dynamic-configuration"></a>

Sie können die Apache AlterConfig Kafka-API oder das Tool Kafka-configs.sh verwenden, um die folgenden dynamischen Konfigurationen zu bearbeiten. Amazon MSK legt alle anderen Eigenschaften fest und verwaltet sie, die Sie nicht festlegen. Sie können dynamisch Konfigurationseigenschaften auf Cluster- und Broker-Ebene festlegen, für die kein Neustart des Brokers erforderlich ist.


| Property (Eigenschaft) | Description (Beschreibung) | Standardwert | 
| --- | --- | --- | 
|  advertised.listeners  |  Listener, die veröffentlicht werden sollen, damit Clients sie verwenden können, sofern sie sich von der Eigenschaft config unterscheiden. `listeners` In IaaS-Umgebungen muss sich dies möglicherweise von der Schnittstelle unterscheiden, an die der Broker bindet. Wenn dies nicht festgelegt ist, wird der Wert für Listener verwendet. Im Gegensatz zu Listenern ist es nicht zulässig, die 0.0.0.0-Metaadresse bekannt zu geben. Im Gegensatz dazu kann diese Eigenschaft doppelte Ports enthalten`listeners`, sodass ein Listener so konfiguriert werden kann, dass er die Adresse eines anderen Listeners bekannt gibt. Dies kann in einigen Fällen nützlich sein, in denen externe Load Balancer verwendet werden. Diese Eigenschaft wird auf Broker-Ebene festgelegt.  |  Null  | 
|  compression.type  |  Der endgültige Komprimierungstyp für ein bestimmtes Thema. Sie können diese Eigenschaft auf die Standard-Komprimierungscodecs (`gzip`, `snappy`, `lz4` und `zstd`) festlegen. Akzeptiert zusätzlich `uncompressed`. Dieser Wert entspricht keiner Komprimierung. Wenn Sie den Wert auf `producer` setzen, bedeutet dies, dass der ursprüngliche Komprimierungs-Codec beibehalten wird, den der Produzent festlegt.  | Apache Kafka (Standard) | 
| log.cleaner.delete.retention.ms | Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka-Standardeinstellung | 
| log.cleaner.min.compaction.lag.ms | Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. | 0, Apache Kafka-Standard | 
| log.cleaner.max.compaction.lag.ms | Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. | 9223372036854775807, Apache Kafka Standard | 
|  log.cleanup.policy  |  Die Standard-Bereinigungsrichtlinie für Segmente außerhalb des Aufbewahrungsfensters. Eine durch Kommata getrennte Liste gültiger Richtlinien. Gültige Richtlinien sind `delete` und `compact`. Für Cluster mit aktiviertem Tiered Storage gilt nur eine gültige Richtlinie. `delete`  | Apache Kafka Standard | 
|  log.message.timestamp.after.max.ms  |  Die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`.  | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) | 
|  log.message.timestamp.before.max.ms  |  Die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`log.message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`log.message.timestamp.type=LogAppendTime`.  | 86400000 (24\$1 60\$1 60\$1 1000 ms, also 1 Tag) | 
|  log.message.timestamp.type  |  Gibt an, wenn der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Anfügezeit des Protokolls widerspiegelt. Die zulässigen Werte sind `CreateTime` und `LogAppendTime`.  | Apache Kafka Standard | 
|  log.retention.bytes  |  Maximale Größe des Protokolls vor dem Löschen.  |  Apache Kafka Standard  | 
|  log.retention.ms  |  Anzahl der Millisekunden, für die eine Protokolldatei aufbewahrt werden muss, bevor sie gelöscht wird.  |  Apache Kafka Standard  | 
|  max.connection.creation.rate  |  Die maximale Verbindungsaufbaurate, die im Broker zu einem beliebigen Zeitpunkt zulässig ist.  |  Apache Kafka Standard  | 
|  maximale Anzahl an Verbindungen  |  Die maximale Anzahl von Verbindungen, die im Broker zu einem beliebigen Zeitpunkt zulässig sind. Dieses Limit wird zusätzlich zu allen IP-Limits angewendet, die mit `max.connections.per.ip` konfiguriert wurden.  |  Apache Kafka Standard  | 
|  max.connections.per.ip  |  Die maximale Anzahl von Verbindungen, die von jeder IP-Adresse aus zulässig sind. Dies kann auf eingestellt werden, `0` wenn mit der Eigenschaft max.connections.per.ip.overrides Überschreibungen konfiguriert wurden. Neue Verbindungen von der IP-Adresse werden unterbrochen, wenn das Limit erreicht wird.  |  Apache Kafka Standard  | 
|  max.connections.per.ip.overrides  |  Eine durch Kommas getrennte Liste von IP-Adressen oder Hostnamen setzt die standardmäßige maximale Anzahl von Verbindungen außer Kraft. Ein Beispielwert ist `hostName:100,127.0.0.1:200`  | Apache Kafka Standard | 
|  message.max.bytes  |  Die größte von Kafka unterstützte Protokoll-Batch-Größe. Wenn Sie diesen Wert erhöhen und Verbraucher älter als 0.10.2 vorhanden sind, müssen Sie auch die Abrufgröße der Verbraucher erhöhen, damit sie diese großen Datensatz-Batch abrufen können. In der neuesten Nachrichtenformat-Version werden Datensätze aus gründen der Effizienz immer in Batches gruppiert. In früheren Nachrichtenformat-Versionen werden nicht komprimierte Datensätze nicht in Batches gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Sie können diesen Wert pro Thema mit der `max.message.bytes` Konfiguration auf Themenebene festlegen.  | Apache Kafka Standard | 
|  producer.id.expiration.ms  |  Die Zeit in ms, die ein Topic-Partitionsleiter abwartet, bevor der Producer abläuft. IDs Der Producer IDs läuft nicht ab, solange eine mit ihm verknüpfte Transaktion noch läuft. Beachten Sie, dass Producer IDs möglicherweise früher abläuft, wenn der letzte Schreibvorgang aus der Producer-ID aufgrund der Aufbewahrungseinstellungen des Themas gelöscht wird. Wenn Sie diesen Wert auf den gleichen Wert oder einen höheren Wert setzen, `delivery.timeout.ms` können Sie das Ablaufen bei Wiederholungsversuchen verhindern und die Duplizierung von Nachrichten verhindern. Die Standardeinstellung sollte jedoch für die meisten Anwendungsfälle angemessen sein.  | Apache Kafka (Standard) | 

## Konfigurationen auf Themenebene auf Express Brokers
<a name="msk-configuration-express-topic-configuration"></a>

Sie können Apache Kafka-Befehle verwenden, um Konfigurationseigenschaften auf Themenebene für neue und vorhandene Themen festzulegen oder zu ändern. Wenn Sie keine Konfiguration auf Themenebene angeben können, verwendet Amazon MSK den Broker-Standard. Wie bei Konfigurationen auf Brokerebene schützt Amazon MSK einige der Konfigurationseigenschaften auf Themenebene vor Änderungen. Beispiele hierfür sind der Replikationsfaktor und. `min.insync.replicas` `unclean.leader.election.enable` Wenn Sie versuchen, ein Thema mit einem anderen Replikationsfaktorwert als zu erstellen`3`, erstellt Amazon MSK das Thema standardmäßig mit einem Replikationsfaktor `3` von. Weitere Informationen zu Konfigurationseigenschaften auf Themenebene und Beispiele zum Festlegen dieser Eigenschaften finden Sie unter [Konfigurationen auf Themenebene](https://kafka.apache.org/documentation/#topicconfigs) in der Apache-Kafka-Dokumentation.


| Property (Eigenschaft) | Description (Beschreibung) | 
| --- | --- | 
|  cleanup.policy  |  Diese Konfiguration legt die Aufbewahrungsrichtlinie fest, die für Protokollsegmente verwendet werden soll. Die Richtlinie „Löschen“ (die Standardeinstellung) verwirft alte Segmente, wenn ihre Aufbewahrungszeit oder Größenbeschränkung erreicht ist. Die Richtlinie „Compact“ ermöglicht die Protokollkomprimierung, bei der der aktuelle Wert für jeden Schlüssel beibehalten wird. Es ist auch möglich, beide Richtlinien in einer durch Kommas getrennten Liste anzugeben (z. B. „Löschen, Komprimieren“). In diesem Fall werden alte Segmente gemäß der Konfiguration für Aufbewahrungszeit und Größe verworfen, während die beibehaltenen Segmente komprimiert werden. Die Komprimierung auf Express-Brokern wird ausgelöst, wenn die Daten in einer Partition 256 MB erreicht haben.  | 
|  compression.type  |  Geben Sie den endgültigen Komprimierungstyp für ein bestimmtes Thema an. Diese Konfiguration akzeptiert die Standard-Komprimierungscodecs (`gzip`,, `snappy``lz4`,`zstd`). Sie akzeptiert außerdem`uncompressed`, was einer Nichtkomprimierung entspricht, und `producer` das bedeutet, dass der vom Hersteller festgelegte ursprüngliche Komprimierungscodec beibehalten wird.  | 
| .retention.ms löschen |  Der Zeitraum, in dem gelöschte Tombstone-Markierungen für im Protokoll komprimierte Themen aufbewahrt werden sollen. Diese Einstellung gibt auch eine Grenze für die Zeit, in der ein Benutzer einen Lesevorgang abschließen muss, wenn er bei Offset 0 beginnt, um sicherzustellen, dass er einen gültigen Snapshot der letzten Phase erhält. Andernfalls könnten gelöschte Tombstones gesammelt werden, bevor der Scan abgeschlossen ist. Der Standardwert für diese Einstellung ist 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, also 1 Tag), Apache Kafka Default  | 
|  max.message.bytes  |  Die größte von Kafka zulässige Batchgröße für Datensätze (nach der Komprimierung, sofern die Komprimierung aktiviert ist). Wenn dieser Wert erhöht wird und es Verbraucher gibt, die älter sind als`0.10.2`, muss auch die Abrufgröße der Verbraucher erhöht werden, damit sie so große Datensatzstapel abrufen können. In der neuesten Nachrichtenformatversion werden Datensätze aus gründen der Effizienz immer in Stapeln gruppiert. In früheren Nachrichtenformatversionen werden nicht komprimierte Datensätze nicht in Stapeln gruppiert und diese Beschränkung gilt in diesem Fall nur für einen einzelnen Datensatz. Dies kann pro Thema mit der Themenebene festgelegt werden. `max.message.bytes config`  | 
|  message.timestamp.after.max.ms  |  Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Nachrichtenzeitstempel und dem Zeitstempel des Brokers fest. Der Nachrichtenzeitstempel kann später als oder gleich dem Zeitstempel des Brokers sein, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied zwischen den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`.  | 
|  message.timestamp.before.max.ms  |  Diese Konfiguration legt die zulässige Zeitstempeldifferenz zwischen dem Zeitstempel des Brokers und dem Nachrichtenzeitstempel fest. Der Nachrichtenzeitstempel kann vor dem Zeitstempel des Brokers liegen oder diesem entsprechen, wobei die maximal zulässige Differenz durch den in dieser Konfiguration festgelegten Wert bestimmt wird. Falls`message.timestamp.type=CreateTime`, wird die Nachricht zurückgewiesen, wenn der Unterschied in den Zeitstempeln diesen angegebenen Schwellenwert überschreitet. Diese Konfiguration wird ignoriert, wenn`message.timestamp.type=LogAppendTime`.  | 
|  message.timestamp.type  |  Definieren Sie, ob der Zeitstempel in der Nachricht die Erstellungszeit der Nachricht oder die Zeit für das Anhängen des Protokolls ist. Der Wert sollte entweder oder sein `CreateTime` `LogAppendTime`  | 
| min.compaction.lag.ms |  Die Mindestdauer, für die eine Nachricht unkomprimiert im Protokoll verbleibt. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Der Standardwert für diese Einstellung ist 0, Apache Kafka Default  | 
| max.compaction.lag.ms |  Die maximale Zeit, für die eine Nachricht im Protokoll nicht komprimiert werden kann. Diese Einstellung gilt nur für Protokolle, die gerade komprimiert werden. Diese Konfiguration wäre auf den Bereich [7 Tage, Long.Max] begrenzt. Der Standardwert für diese Einstellung ist 9223372036854775807, Apache Kafka Default.  | 
|  retention.bytes  |  Diese Konfiguration steuert die maximale Größe, auf die eine Partition (die aus Protokollsegmenten besteht) anwachsen kann, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Standardmäßig gibt es keine Größenbeschränkung, nur eine Zeitbegrenzung. Da dieses Limit auf Partitionsebene durchgesetzt wird, multiplizieren Sie es mit der Anzahl der Partitionen, um die Beibehaltung des Themas in Byte zu berechnen. Darüber hinaus `retention.bytes configuration` funktioniert es unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst es das Rollen eines neuen Segments aus, wenn das auf Null konfiguriert `retention.bytes` ist.  | 
|  retention.ms  |  Diese Konfiguration legt fest, wie lange wir ein Protokoll maximal aufbewahren, bevor wir alte Protokollsegmente verwerfen, um Speicherplatz freizugeben, wenn wir die Aufbewahrungsrichtlinie „Löschen“ verwenden. Dies stellt eine SLA dar, die festlegt, wie schnell Verbraucher ihre Daten lesen müssen. Wenn auf gesetzt`-1`, wird kein Zeitlimit angewendet. Darüber hinaus funktioniert die `retention.ms` Konfiguration unabhängig von `segment.ms` den `segment.bytes` Konfigurationen. Darüber hinaus löst sie das Rollen eines neuen Segments aus, wenn die `retention.ms` Bedingung erfüllt ist.  | 

# Express vermittelt Konfigurationen, die nur lesbar sind
<a name="msk-configuration-express-read-only"></a>

Amazon MSK legt die Werte für diese Konfigurationen fest und schützt sie vor Änderungen, die sich auf die Verfügbarkeit Ihres Clusters auswirken könnten. Diese Werte können sich je nach der Apache Kafka-Version, die auf dem Cluster ausgeführt wird, ändern. Denken Sie also daran, die Werte Ihres spezifischen Clusters zu überprüfen.

In der folgenden Tabelle sind die schreibgeschützten Konfigurationen für Express-Broker aufgeführt.


| Property (Eigenschaft) | Description (Beschreibung) | Der Wert von Express Broker | 
| --- | --- | --- | 
| broker.id | Die Broker-ID für diesen Server. | 1,2,3... | 
| Broker.Rack | Rack des Brokers. Dies wird aus Gründen der Fehlertoleranz bei der Zuweisung von Replikationen mit Rack-Unterstützung verwendet. Beispiele: `RACK1`, `us-east-1d` | AZ-ID oder Subnetz-ID | 
|  default.replication.factor  |  Standardreplikationsfaktoren für alle Themen.  |  3  | 
| fetch.max.bytes | Die maximale Anzahl von Byte, die wir für eine Abrufanforderung zurückgeben. | Apache Kafka Standard | 
| group.max.size | Die maximale Anzahl von Verbrauchern, die eine einzelne Verbrauchergruppe aufnehmen kann. | Apache Kafka Standard | 
| inter.broker.listener.name | Name des Listeners, der für die Kommunikation zwischen Brokern verwendet wird. | REPLICATION\$1SECURE oder REPLICATION | 
| inter.broker.protocol.version | Gibt an, welche Version des Inter-Broker-Protokolls verwendet wird. | Apache Kafka (Standard) | 
| Listener | Listener-Liste — Kommagetrennte Liste der Listener-Namen, auf die URIs wir hören werden. Sie können die Eigenschaft festlegenadvertised.listeners property, aber nicht die Eigenschaft. listeners | Von MSK generiert | 
| log.message.format.version | Geben Sie die Version des Nachrichtenformats an, die der Broker verwenden wird, um Nachrichten an die Protokolle anzuhängen. | Apache Kafka (Standard) | 
| min.insync.replicas | Wenn ein Producer acks auf `all` (oder`-1`) setzt, `min.insync.replicas` gibt der Wert in die Mindestanzahl von Replikaten an, die einen Schreibvorgang bestätigen müssen, damit der Schreibvorgang als erfolgreich angesehen wird. Wenn dieses Minimum nicht erreicht werden kann, löst der Producer eine Ausnahme aus (entweder `NotEnoughReplicas` oder`NotEnoughReplicasAfterAppend`). Sie können die Value-Acks Ihres Herstellers verwenden, um höhere Haltbarkeitsgarantien durchzusetzen. Indem Sie Acks auf „Alle“ setzen. Dadurch wird sichergestellt, dass der Produzent eine Ausnahme auslöst, wenn die Mehrheit der Replikate keinen Schreibvorgang erhält. | 2 | 
| num.io.threads | Anzahl der Threads, die der Server verwendet, um Anfragen zu erzeugen, die Festplatten-I/O beinhalten können. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | Basierend auf dem Instanztyp. =Math.max (8, 2 \$1 v) CPUs | 
| num.network.threads | Anzahl der Threads, die der Server verwendet, um Anfragen vom Netzwerk zu empfangen und Antworten an das Netzwerk zu senden. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | Basiert auf dem Instanztyp. =Math.max (8, v) CPUs | 
| replica.fetch.response.max.bytes | Die maximale Anzahl von Bytes, die für die gesamte Abrufantwort erwartet wird. Datensätze werden in Batches abgerufen und wenn der erste Datensatz-Batch in der ersten nicht leeren Partition des Abrufs größer ist als dieser Wert, wird der Datensatz-Batch weiterhin zurückgegeben, damit Fortschritte gemacht werden können. Es handelt sich nicht um ein absolutes Maximum. Die Eigenschaften message.max.bytes (broker config) oder max.message.bytes (topic config) geben die maximale Batchgröße von Datensätzen an, die der Broker akzeptiert. | Apache Kafka (Standard) | 
| request.timeout.ms | Die Konfiguration steuert, wie lange der Client maximal auf die Antwort auf eine Anfrage wartet. Wenn die Antwort nicht vor Ablauf des Timeouts eingeht, sendet der Client die Anfrage gegebenenfalls erneut oder schlägt die Anfrage fehl, wenn die Wiederholungsversuche erschöpft sind. | Apache Kafka (Standard) | 
| transaction.state.log.min.isr | Die min.insync.replicas Konfiguration für das Transaktionsthema wurde außer Kraft gesetzt. | 2 | 
| transaction.state.log.replication.factor | Der Replikationsfaktor für das Transaktionsthema. | Apache Kafka (Standard) | 
| unclean.leader.election.enable | Ermöglicht Replikaten, die nicht in der ISR-Gruppe enthalten sind, als letztes Mittel als führendes Mittel zu dienen, auch wenn dies zu Datenverlust führen kann. | FALSE | 