Kebolehpercayaan Middleware dalam Amalan: Penyelesaian Masalah Redis, RabbitMQ dan Kafka

Senario

Sebuah platform e-dagang menggunakan Redis, RabbitMQ dan Kafka di Kubernetes. Semasa jualan kilat, Redis kerap timeout, RabbitMQ mesej bertimbun, dan Kafka offset kumpulan pengguna diset semula, menyebabkan kelewatan pemprosesan pesanan.

Simptom

• Redis: Log aplikasi menunjukkan 'Connection refused' atau 'Timeout'; kadar hit cache menurun mendadak.
• RabbitMQ: Kedalaman baris gilir meningkat pesat; daya pemprosesan pengguna merosot; beberapa mesej di-requeue atau hilang.
• Kafka: Kumpulan pengguna mengalami 'OffsetOutOfRange' atau 'Rebalance' kerap; lag pengguna meningkat.

Diagnosis

Redis

1. Periksa kesihatan perkhidmatan Redis: bash kubectl exec -it redis-pod -- redis-cli ping Patut balas PONG. Jika gagal, periksa log pod: bash kubectl logs redis-pod --tail=50
2. Semak status Sentinel atau Cluster: bash redis-cli -h redis-sentinel -p 26379 sentinel master mymaster
3. Semak memori dan pertanyaan lambat: bash redis-cli info memory redis-cli slowlog get

RabbitMQ

1. Lihat status nod: bash kubectl exec rabbitmq-pod -- rabbitmqctl status
2. Senarai baris gilir dan pengguna: bash rabbitmqctl list_queues name messages_ready messages_unacknowledged rabbitmqctl list_consumers
3. Lihat log: bash kubectl logs rabbitmq-pod

Kafka

1. Semak metadata broker dan topik: bash kubectl exec kafka-pod -- kafka-broker-api-versions.sh --bootstrap-server localhost:9092 kafka-topics.sh --describe --topic orders --bootstrap-server localhost:9092
2. Periksa status kumpulan pengguna: bash kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group order-group --describe
3. Periksa segmen log: bash kafka-run-class.sh kafka.tools.DumpLogSegments --files /data/kafka/orders-0/00000000000000000000.log --print-data-log

Kawalan Risiko

• Redis: Gunakan Sentinel atau Cluster untuk elak titik kegagalan tunggal; set maxmemory dan polisi pengusiran (cth. allkeys-lru); aktifkan persistensi RDB/AOF.
• RabbitMQ: Konfigurasi baris gilir terpantul (ha-mode: all); aktifkan pengesahan penerbit (publisher confirms) dan ack manual pengguna; set pertukaran surat mati (dead letter exchange) untuk mesej gagal.
• Kafka: Set faktor replikasi >= 3; konfigurasi min.insync.replicas=2; penghasil set acks=all; pengguna guna auto.offset.reset=none atau earliest.

Balik

• Redis: Pulihkan dari snapshot RDB terkini atau fail AOF; muat semula ke nod induk.
• RabbitMQ: Jika baris gilir terpantul digunakan, tukar ke nod sihat; jika tidak, pulihkan data baris gilir dari sandaran.
• Kafka: Guna alat kafka-reassign-partitions untuk agihkan semula replika; jika data rosak, pulihkan topik dari sandaran.

Pengesahan

• Redis: redis-cli --latency -h <host> untuk uji kependaman; redis-cli info persistence untuk status persistensi; simulasi failover dan sahkan pemulihan automatik.
• RabbitMQ: Terbitkan dan guna mesej ujian; periksa kedalaman baris gilir dan kadar ack.
• Kafka: Hasilkan/guna mesej ujian; pastikan offset berterusan; guna kafka-verifiable-producer dan kafka-verifiable-consumer untuk pengesahan hujung ke hujung.

Bila Serah Tiket OpsGlobal

• Apabila masalah melebihi kapasiti pasukan (cth. partition rangkaian merentas AZ, kerosakan data teruk);
• Apabila perlu semakan seni bina berwibawa (cth. pelan skala kluster);
• Apabila ketidakstabilan berterusan tanpa punca yang jelas;
• Apabila ingin membina sistem pemantauan dan amaran yang lebih mantap.