Publisher-bekreftelser for pålitelighet
Implementer publisher-bekreftelser for å sikre at meldinger er mottatt og behandlet av broker-en. Bygg pålitelige produsenter som kan gjenopprette seg etter nettverks- eller broker-problemer.
Publisher-bekreftelser for pålitelighet er en gratis leksjon i RabbitMQ-meldinger og asynkrone systemer på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i RabbitMQ-meldinger og asynkrone systemer, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i RabbitMQ-meldinger og asynkrone systemer inneholder totalt 4 leksjoner.
Hvorfor Publisher Confirms?
Når De sender en melding til RabbitMQ, hvordan vet De at den faktisk kom trygt frem til broker-en?
Som standard sender produsenter meldinger uten å vente på en eksplisitt bekreftelse fra RabbitMQ. Dette er raskt, men det innebærer at meldinger kan gå tapt på grunn av nettverksproblemer eller feil i broker-en rett etter at de er sendt.
Publisher Confirms er en mekanisme som gjør det mulig for produsenter å motta bekreftelser (ACK-er) fra RabbitMQ når meldinger er mottatt og behandlet av broker-en.
Det usynlige gapet i leveringen
Se for Dem at De sender en viktig bestilling til en behandlingskø. Uten publisher confirms «sender» programmet ganske enkelt meldingen og går videre.
- Hva om nettverksforbindelsen mister meldingen underveis?
- Hva om RabbitMQ-serveren krasjer like etter mottak, men før meldingen er lagret persistent?
Uten en bekreftelse vil produsenten anta at alt gikk bra, noe som kan føre til datatap eller inkonsistente tilstander i systemet.
Slik fungerer confirm-modus
For å bruke publisher confirms aktiverer De «confirm mode» på en kanal. Når modusen er aktivert, tildeles hver melding som publiseres på kanalen en unik delivery tag.
- ACK (Acknowledgement): Broker-en sender en ACK tilbake til produsenten når en melding er mottatt, rutet til køene sine og lagret persistent (hvis den er durable).
- NACK (Negative Acknowledgement): Broker-en sender en NACK hvis den ikke kunne behandle meldingen (for eksempel ved feil under ruting eller en intern feil).
Denne tilbakemeldingssløyfen lukker «leveringsgapet» mellom produsent og broker.
Aktivere confirm-modus
Før De publiserer meldinger, må De fortelle RabbitMQ at De vil bruke publisher confirms på kanalen. Dette er et engangsoppsett for hver kanal.
Prøv å kjøre dette eksempelet for å se hvordan De aktiverer confirm-modus:
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
public class ConfirmSetup {
public static void main(String[] args) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost"); // Assumes RabbitMQ is running locally
try (Connection connection = factory.newConnection();
Channel channel = connection.createChannel()) {
channel.confirmSelect(); // This line enables confirm mode
System.out.println("Channel is now in confirm mode.");
// Further publishing code would go here
}
}
}Synkrone bekreftelser: `waitForConfirms`
En måte å bruke publisher confirms på er synkront. Etter at én eller flere meldinger er publisert, kan produsenten kalle channel.waitForConfirms() eller channel.waitForConfirmsOrDie().
- Metoden blokkerer produsenten til alle meldinger som er publisert siden forrige kall, har fått ACK eller NACK.
- Den er enkel å implementere, men kan redusere gjennomstrømningen betydelig fordi produsenten venter på hver meldingsgruppe.
- Den passer godt for meldinger med lavt volum og høy kritikalitet, der umiddelbar bekreftelse er avgjørende.
Kodeeksempel på synkron bekreftelse
Dette eksempelet viser en produsent som sender én melding og deretter venter på bekreftelsen. Hvis meldingen ikke blir bekreftet innen 5 sekunder, utløper tidsavbruddet.
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.util.concurrent.TimeoutException;
public class SyncConfirmPublisher {
private static final String QUEUE_NAME = "sync_confirm_queue";
public static void main(String[] args) throws IOException, TimeoutException, InterruptedException {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection();
Channel channel = connection.createChannel()) {
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
channel.confirmSelect(); // Enable confirm mode
String message = "Hello, reliable world!";
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF-8"));
System.out.println(" [x] Sent '" + message + "'");
// Wait for confirmation for up to 5 seconds
if (channel.waitForConfirms(5000)) {
System.out.println("Message confirmed by broker!");
} else {
System.out.println("Message not confirmed within timeout! It might be lost or delayed.");
}
}
}
}Asynkrone bekreftelser: Lyttere
For høyere gjennomstrømning kan De bruke asynkrone publisher confirms. I stedet for å blokkere registrerer De en ConfirmListener på kanalen.
- Lytteren har to metoder:
handleAck()for vellykkede bekreftelser oghandleNack()for negative bekreftelser. - RabbitMQ leverer ACK-er og NACK-er til denne lytteren, slik at produsenten kan fortsette å publisere meldinger uten å vente.
- Denne tilnærmingen krever mer kompleks logikk for å holde oversikt over ubekreftede meldinger, men gir bedre ytelse ved publisering av store mengder meldinger.
Kodeeksempel på asynkron bekreftelse
Dette eksempelet viser en asynkron produsent. Den registrerer en lytter som håndterer ACK-er og NACK-er uten å blokkere hovedtråden.
Legg merke til Thread.sleep(), som holder programmet kjørende lenge nok til å motta bekreftelser.
import com.rabbitmq.client.Channel;
import com.rabbitmq.client.ConfirmListener;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import java.io.IOException;
import java.util.concurrent.ConcurrentNavigableMap;
import java.util.concurrent.ConcurrentSkipListMap;
public class AsyncConfirmPublisher {
private static final String QUEUE_NAME = "async_confirm_queue";
public static void main(String[] args) throws Exception {
ConnectionFactory factory = new ConnectionFactory();
factory.setHost("localhost");
try (Connection connection = factory.newConnection();
Channel channel = connection.createChannel()) {
channel.queueDeclare(QUEUE_NAME, false, false, false, null);
channel.confirmSelect(); // Enable confirm mode
// Store unconfirmed messages by their delivery tag
ConcurrentNavigableMap<Long, String> outstandingConfirms = new ConcurrentSkipListMap<>();
channel.addConfirmListener(new ConfirmListener() {
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
if (multiple) {
// Remove all messages up to this deliveryTag
outstandingConfirms.headMap(deliveryTag + 1).clear();
} else {
outstandingConfirms.remove(deliveryTag);
}
System.out.println(" [x] Message with deliveryTag " + deliveryTag + " ACKed! Remaining: " + outstandingConfirms.size());
}
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
String message = outstandingConfirms.get(deliveryTag);
System.out.println(" [!] Message '" + message + "' (deliveryTag " + deliveryTag + ") NACKed! Re-sending or logging error.");
// Handle NACK: re-publish, log, etc.
if (multiple) {
outstandingConfirms.headMap(deliveryTag + 1).clear();
} else {
outstandingConfirms.remove(deliveryTag);
}
}
});
String message = "Hello, async reliable world!";
long nextPublishSeqNo = channel.getNextPublishSeqNo();
outstandingConfirms.put(nextPublishSeqNo, message);
channel.basicPublish("", QUEUE_NAME, null, message.getBytes("UTF-8"));
System.out.println(" [x] Sent '" + message + "' (deliveryTag: " + nextPublishSeqNo + ")");
// Keep main thread alive for a moment to receive confirms
Thread.sleep(2000);
}
}
}Synkron eller asynkron: Velg med omhu
Valget mellom synkrone og asynkrone bekreftelser avhenger av behovene i applikasjonen:
- Synkrone (
waitForConfirms):- Enklere å implementere.
- Lavere gjennomstrømning fordi de blokkerer.
- Passer godt for meldinger med lavt volum og høy kritikalitet, der umiddelbar bekreftelse er nødvendig.
- Asynkrone (
ConfirmListener):- Mer kompleks implementasjon (krever sporing av ubekreftede meldinger).
- Høyere gjennomstrømning fordi de ikke blokkerer.
- Ideelt for publisering av store mengder meldinger, der ytelse er avgjørende.
Kontroll av bekreftelser
De har lært om publisher confirms. La oss se om De kan svare på dette spørsmålet.
Oppsummering: Pålitelig publisering
Gratulerer! De har lært hvordan De gjør RabbitMQ-produsentene Deres virkelig pålitelige ved hjelp av publisher confirms.
- Publisher confirms sikrer at meldinger som sendes av en produsent, blir mottatt og behandlet av RabbitMQ-broker-en.
- De aktiverer confirm-modus på en kanal ved hjelp av
channel.confirmSelect(). - Synkrone bekreftelser (
waitForConfirms()) er enkle, men blokkerer og passer for lavt volum. - Asynkrone bekreftelser (
addConfirmListener()) gir høyere gjennomstrømning i situasjoner med stort volum, men krever mer kompleks sporing av meldinger.
Ved å implementere publisher confirms kan De bygge robuste systemer som minimerer tap av meldinger og sikrer integriteten til kritiske data.
Lær deg RabbitMQ-meldinger og asynkrone systemer med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 11
- Leksjoner
- 44
Ofte stilte spørsmål
Er leksjonen «Publisher-bekreftelser for pålitelighet» gratis?
Ja – du kan lese valgfritt 3 av leksjonene i læringsstien RabbitMQ-meldinger og asynkrone systemer, inkludert «Publisher-bekreftelser for pålitelighet», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i RabbitMQ-meldinger og asynkrone systemer inneholder totalt 4 leksjoner.
Hva lærer jeg i «Publisher-bekreftelser for pålitelighet»?
Implementer publisher-bekreftelser for å sikre at meldinger er mottatt og behandlet av broker-en. Bygg pålitelige produsenter som kan gjenopprette seg etter nettverks- eller broker-problemer. Du øver på RabbitMQ-meldinger og asynkrone systemer med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med RabbitMQ-meldinger og asynkrone systemer?
Ingen tidligere erfaring er nødvendig. RabbitMQ-meldinger og asynkrone systemer på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.
Hvor lang tid tar leksjonen «Publisher-bekreftelser for pålitelighet»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne RabbitMQ-meldinger og asynkrone systemer-leksjonen?
Ja. Alle RabbitMQ-meldinger og asynkrone systemer-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Vedvarende meldinger og køer
- Publisher-bekreftelser for pålitelighet
- Bekreftelser fra consumers og kølegging på nytt
- Transaksjoner kontra publisher confirms