Kebolehpercayaan Middleware: Menjinakkan Redis, RabbitMQ, dan Kafka dalam Pengeluaran

Senario

Pelanggan perkhidmatan kewangan mengalami lonjakan latensi yang teruk dan ketidakkonsistenan data semasa waktu puncak. Platform Kubernetes mereka menjalankan Redis sebagai cache dan stor sesi, RabbitMQ untuk pemesejan transaksi, dan Kafka untuk pengaliran acara. Beban kerja campuran mula menjejaskan satu sama lain, menyebabkan kegagalan berantai.

Simptom

• Redis: Nisbah pukulan cache menurun, kiraan pengusiran (evicted_keys) meningkat, latensi melebihi 100ms. Pelanggan melihat OOM command not allowed when used memory > maxmemory.
• RabbitMQ: Baris gilir terkumpul sehingga berjuta mesej. Pengguna terputus sambungan dengan channel error dan precondition failed.
• Kafka: Ketinggalan kumpulan pengguna (lag) terus meningkat, faktor replikasi petak jatuh di bawah nilai yang dikonfigurasikan, dan ISR (in-sync replicas) mengecil.

Diagnosis

1. Kumpul Metrik

Gunakan Prometheus dan Grafana untuk memerhatikan metrik utama ini:

• Redis: redis_memory_used, redis_evicted_keys, redis_commands_processed.
• RabbitMQ: rabbitmq_queue_messages, rabbitmq_connection_open, rabbitmq_channel_open.
• Kafka: kafka_consumergroup_lag, kafka_partition_underreplicated, kafka_server_replica_fetcher_manager_leader_count.

2. Periksa Log

# Dapatkan log pod Redis
kubectl logs -l app=redis -n middleware

# Dapatkan log RabbitMQ dan Kafka
kubectl logs -l app=rabbitmq -n middleware
kubectl logs -l app=kafka -n middleware

Cari anomali seperti Redis WARNING tentang fragmentasi memori, RabbitMQ connection_closed_abruptly, Kafka OffsetOutOfRangeException atau ralat ReplicaFetcherThread.

3. Arahan Langsung

Redis

kubectl exec -it <redis-pod> -- redis-cli INFO memory
kubectl exec -it <redis-pod> -- redis-cli INFO stats | grep evicted
kubectl exec -it <redis-pod> -- redis-cli --bigkeys

Semak sama ada memori hampir maxmemory dan jika terdapat kunci besar.

RabbitMQ

kubectl exec -it <rabbitmq-pod> -- rabbitmqctl list_queues name messages consumers
kubectl exec -it <rabbitmq-pod> -- rabbitmqctl list_connections name state

Kenal pasti baris gilir yang tertunggak dan sama ada pengguna masih bersambung.

Kafka

kubectl exec -it <kafka-pod> -- kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group <group>
kubectl exec -it <kafka-pod> -- kafka-topics --bootstrap-server localhost:9092 --describe --topic <topic>

Semak ketinggalan pengguna dan status replikasi petak.

Kawalan Risiko

• Sebelum sebarang operasi, sandarkan Redis melalui SAVE atau BGSAVE; eksport metadata RabbitMQ; pastikan faktor replikasi Kafka > 1 dan ISR sihat.
• Elakkan FLUSHALL atau memadam baris gilir/topik secara langsung dalam pengeluaran.
• Sentiasa ada pelan rollback dan uji sambungan sebelum menukar konfigurasi.
• Gunakan kubectl rollout restart daripada memadam pod secara manual untuk mengurangkan gangguan.

Arahan Pemulihan (Contoh)

Redis: Laras Polisi Memori

kubectl exec -it <redis-pod> -- redis-cli CONFIG SET maxmemory-policy allkeys-lru
kubectl exec -it <redis-pod> -- redis-cli CONFIG REWRITE

RabbitMQ: Skala Pengguna Sementara

kubectl scale deployment <consumer-deployment> --replicas=5 -n middleware

Kafka: Tetapkan Semula Ofset Kumpulan Pengguna (Gunakan dengan berhati-hati)

kubectl exec -it <kafka-pod> -- kafka-consumer-groups --bootstrap-server localhost:9092 --group <group> --topic <topic> --reset-offsets --to-earliest --execute

Rollback

• Jika perubahan polisi Redis menjejaskan prestasi, kembalikan dengan CONFIG SET maxmemory-policy volatile-lru.
• Jika penskalaan pengguna tidak membantu, kurangkan semula replika.
• Jika tetapan semula ofset Kafka menyebabkan kekacauan, rollback menggunakan --to-latest atau ofset asal.

Pengesahan

• Pastikan Redis evicted_keys dan used_memory kembali normal.
• Semak panjang baris gilir RabbitMQ menurun dan sambungan pengguna stabil.
• Sahkan ketinggalan pengguna Kafka menghampiri sifar dan ISR sihat.
• Uji latensi dengan redis-benchmark atau permintaan perniagaan sebenar.

Bila Menghantar Tiket OpsGlobal

Jika anda masih tidak dapat mencari punca selepas diagnosis, atau jika anda memerlukan pemantauan 24/7 dan tindak balas pantas, hantar tiket OpsGlobal. Pakar SRE kami menyediakan: - Pemantauan dan amaran penuh tindanan 24/7 - Perancangan kapasiti proaktif dan penalaan prestasi - Latihan pemulihan bencana dan failover - Penyelesaian masalah lanjutan dan analisis punca punca

Kami campur tangan dalam beberapa minit untuk membantu pasukan anda mengurangkan MTTR dan memastikan kesinambungan perniagaan.