Redis, RabbitMQ, Kafka: Panduan Praktikal untuk Kebolehpercayaan Middleware dalam Kubernetes

Senario

Sebuah platform e-dagang berjalan di Kubernetes, menggunakan Redis untuk caching, RabbitMQ untuk pemprosesan pesanan, dan Kafka untuk pengaliran acara. Semasa jualan kilat, pelanggan melaporkan kegagalan pembayaran, muatan halaman perlahan, dan pemprosesan pesanan tertangguh.

Gejala

• Masa respons persentil ke-99 meningkat daripada 50ms kepada 2s
• Penggunaan memori Redis melebihi 80%, log pertanyaan perlahan berkembang pesat
• Baris gilir RabbitMQ sesak: kiraan mesej melonjak dari ratusan ke ratusan ribu
• Ketinggalan pengguna Kafka meningkat dari milisaat ke minit, dengan beberapa kumpulan pengguna mengimbang semula

Diagnosis

Redis

1. Periksa pertanyaan perlahan: redis-cli SLOWLOG GET 10 untuk mengenal pasti arahan perlahan (contohnya, KEYS, SORT, operasi pada kunci besar).
2. Pantau memori: redis-cli INFO memory untuk used_memory_rss dan maxmemory, semak jika dasar pengusiran dicetuskan.
3. Periksa sambungan: redis-cli CLIENT LIST untuk melihat jika bilangan sambungan tidak normal.

RabbitMQ

1. Periksa status baris gilir: rabbitmqctl list_queues name messages_ready messages_unacknowledged untuk mencari baris gilir sesak.
2. Periksa pengguna: rabbitmqctl list_consumers untuk memastikan pengguna bersambung dan tetapan prefetch sesuai.
3. Pantau kesihatan nod: rabbitmqctl status untuk penggera (contohnya, penggera memori atau cakera).

Kafka

1. Lihat ketinggalan kumpulan pengguna: kafka-consumer-groups --bootstrap-server localhost:9092 --group order-consumer --describe untuk LAG.
2. Periksa kepimpinan partition: kafka-topics --describe --topic orders untuk mengesahkan taburan partition seimbang.
3. Pantau cakera dan rangkaian: kafka-log-dirs --describe --bootstrap-server localhost:9092 untuk penggunaan cakera.

Arahan (dengan nota keselamatan)

Redis

• redis-cli --bigkeys untuk mengimbas kunci besar (peringatan: elakkan waktu puncak; gunakan --sleep untuk mengurangkan beban).
• redis-cli config set timeout 30 untuk menetapkan tamat masa klien (peringatan: boleh mengganggu sambungan; uji dahulu).

RabbitMQ

• rabbitmqadmin declare queue name=backup queue_args='{"x-max-length":100000}' untuk mencipta baris gilir terbatas mencegah kesesakan tanpa had.
• Laraskan prefetch: rabbitmqctl set_consumer_prefetch-size <queue_name> 50 (memerlukan mulakan semula pengguna).

Kafka

• Tambah partition: kafka-topics --bootstrap-server localhost:9092 --alter --topic orders --partitions 6 (hanya jika partition ≤ broker dan reka bentuk kunci menyokong).
• Set semula ofset pengguna: kafka-consumer-groups --bootstrap-server localhost:9092 --group order-consumer --reset-offsets --to-earliest --execute (berbahaya: menyebabkan penggunaan duplikat; uji sahaja).

Kawalan Risiko

• Redis: Dayakan log pertanyaan perlahan (slowlog-log-slower-than 10000 mikrosaat), tetapkan maxmemory-policy allkeys-lru, gunakan kolam sambungan.
• RabbitMQ: Tetapkan panjang maksimum baris gilir (x-max-length) dan bait maksimum mesej (x-max-length-bytes), dayakan baris gilir malas, gunakan pengakuan manual.
• Kafka: Konfigurasikan min.insync.replicas=2, tetapkan max.poll.records dan session.timeout.ms pengguna, gunakan pemantauan (contohnya, Prometheus + JMX Exporter).

Pengunduran

Jika perubahan konfigurasi menyebabkan masalah, undur segera: - Redis: redis-cli config set maxmemory-policy volatile-lru untuk memulihkan dasar asal. - RabbitMQ: Padam baris gilir terbatas yang baru dicipta dan pulihkan baris gilir asal. - Kafka: Pengurangan partition tidak disokong; padam dan cipta semula topik. Sebagai alternatif, set semula ofset pengguna ke kedudukan sebelumnya.

Beroperasi di luar waktu puncak dan simpan sandaran konfigurasi.

Pengesahan

• Jalankan transaksi sintetik: simulasikan aliran log masuk, layar, dan pembayaran pengguna, pantau kadar kejayaan.
• Gunakan papan pemuka Prometheus+Grafana: perhatikan kependaman, panjang baris gilir, trend ketinggalan pengguna.
• Lakukan ujian beban ringan: gunakan locust atau jmeter untuk menghantar trafik simulasi dan periksa respons sistem.

Bila Perlu Hantar Tiket OpsGlobal

Jika diagnosis dalaman melebihi 30 minit tanpa mengenal pasti punca utama, atau jika anda memerlukan bantuan pakar untuk perubahan seni bina, pengoptimuman konfigurasi, atau failover, hantar tiket dengan segera. Pasukan SRE OpsGlobal menyediakan sokongan 24/7 untuk membantu anda memulihkan perkhidmatan dengan cepat dan mengoptimumkan sistem.