Kekalkan Rangkaian Middleware Anda: Panduan Lapangan untuk Kebolehpercayaan Redis, RabbitMQ, dan Kafka

Senario

Platform e-dagang biasa bergantung pada Redis untuk caching, RabbitMQ untuk barisan tugas, dan Kafka untuk penstriman acara. Pada suatu hari, latensi aplikasi melonjak, pemprosesan pesanan menjadi perlahan, dan muatan halaman tamat masa. Pasukan infrastruktur menyedari penggunaan memori Redis menghampiri had, kedalaman barisan RabbitMQ terus meningkat, dan pengguna Kafka ketinggalan ratusan ribu mesej. Pengguna mula mengadu, dan perniagaan terjejas.

Simptom

• Redis: INFO memory menunjukkan used_memory menghampiri maxmemory, INFO stats menunjukkan evicted_keys dan expired_keys meningkat, dan log perlahan menangkap banyak arahan KEYS atau SMEMBERS.
• RabbitMQ: UI pengurusan atau rabbitmqctl list_queues menunjukkan peningkatan mendadak dalam bilangan mesej dalam barisan, bilangan pengguna menurun, dan rabbitmq-diagnostics melaporkan amaran memori dan cakera.
• Kafka: kafka-consumer-groups menunjukkan lag kumpulan pengguna terus meningkat, penggunaan CPU dan I/O cakera broker meningkat, dan replika partition mengalami pengecutan ISR.

Diagnosis

1. Kenal pasti hotspot: Gunakan alat APM dan pemantauan (contohnya Prometheus/Grafana) untuk memeriksa volum permintaan, kadar ralat, dan latensi. Periksa sama ada terdapat trafik mendadak atau kecacatan kod.
2. Diagnosis Redis: Jalankan redis-cli --latency dan redis-cli --stat, serta dapatkan arahan perlahan dengan SLOWLOG GET. Analisis untuk kunci besar, hotkey, dan sama ada dasar pengusiran sesuai.
3. Diagnosis RabbitMQ: Periksa bilangan sambungan, saluran, dan mesej yang tidak diakui. Gunakan rabbitmqctl list_consumers untuk sahkan pengguna berada dalam talian, dan rabbitmqctl list_queues name messages consumers untuk melihat status barisan. Punca biasa termasuk kuasa pemprosesan pengguna yang tidak mencukupi atau gelung tak terhingga.
4. Diagnosis Kafka: Gunakan kafka-consumer-groups --describe --group <group> untuk memeriksa lag per partition. Periksa konfigurasi pengguna seperti max.poll.records dan session.timeout.ms, serta metrik cakera dan rangkaian broker.

Arahan

Redis

# Semak memori dan statistik keyspace
redis-cli INFO memory
redis-cli INFO keyspace

# Lihat pertanyaan perlahan
redis-cli SLOWLOG GET 10

# Semak kunci besar (gunakan alat pihak ketiga seperti redis-rdb-tools)
redis-cli --bigkeys

# Jika menggunakan kluster, lihat status kluster
redis-cli CLUSTER INFO

RabbitMQ

# Lihat status barisan
rabbitmqctl list_queues name messages consumers

# Lihat sambungan dan saluran
rabbitmqctl list_connections
rabbitmqctl list_channels

# Semak amaran memori dan cakera
rabbitmq-diagnostics check_running
rabbitmq-diagnostics memory_breakdown

# Kosongkan barisan (bahaya, gunakan dengan berhati-hati)
rabbitmqctl purge_queue <queue_name>

Kafka

# Lihat lag kumpulan pengguna
kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group my-consumer-group

# Lihat butiran topik
kafka-topics --bootstrap-server localhost:9092 --describe --topic orders

# Lihat log broker untuk pengecualian
journalctl -u kafka -n 200

Kawalan Risiko

• Redis: Tetapkan dasar maxmemory-policy yang sesuai (contohnya allkeys-lru atau volatile-lru), elakkan arahan KEYS, dan gunakan SCAN sebagai ganti. Pastikan ruang memori mencukupi apabila persistence (RDB/AOF) diaktifkan.
• RabbitMQ: Konfigurasikan had panjang barisan (x-max-length) dan TTL mesej, dan gunakan barisan surat mati untuk mesej yang tidak boleh digunakan. Aktifkan barisan malas untuk barisan throughput tinggi untuk mengurangkan tekanan memori.
• Kafka: Laraskan replica.lag.time.max.ms dan min.insync.replicas untuk mengelakkan pengecutan ISR. Optimumkan fetch.max.bytes dan max.poll.records di sisi pengguna untuk mengelakkan tamat masa pemprosesan.
• Umum: Sediakan amaran pemantauan untuk setiap middleware, seperti penggunaan memori Redis, kedalaman barisan RabbitMQ, dan lag pengguna Kafka. Jalankan ujian beban dan sandarkan konfigurasi sebelum perubahan.

Rollback

Jika perubahan konfigurasi memburukkan keadaan, segera undurkan.

• Redis: Gunakan CONFIG GET dan CONFIG SET untuk perubahan sementara, tetapi kemas kini fail konfigurasi secara manual untuk kekal. Jika AOF diaktifkan, undurkan konfigurasi tanpa perlu but semula. Jika anda tersilap menggunakan FLUSHALL, hentikan Redis dengan segera dan pulihkan sandaran terakhir (RDB).
• RabbitMQ: Jika dasar menyebabkan masalah, padamkannya dengan rabbitmqctl clear_policy <name>. Jika barisan dikosongkan, data tidak dapat dipulihkan; anda perlu bina semula daripada pengeluar atau sandaran.
• Kafka: Jika konfigurasi broker diubah, mulakan semula contoh Kafka (lakukan but semula bergilir). Untuk kumpulan pengguna, set semula offset dengan --to-earliest atau --to-latest, tetapi ambil perhatian ini mungkin menghasilkan pendua atau kehilangan mesej.
• Nota keselamatan: Pastikan sandaran wujud dan maklumkan ahli pasukan sebelum sebarang arahan yang merosakkan.

Pengesahan

Selepas menggunakan pembetulan, sahkan bahawa middleware telah pulih.

• Redis: INFO stats menunjukkan evicted_keys stabil, dan latensi kembali normal. Sahkan latensi <1ms dengan redis-cli --latency.
• RabbitMQ: Kedalaman barisan menurun, bilangan pengguna pulih, dan rabbitmq-diagnostics status menunjukkan semua nod berjalan.
• Kafka: Lag kumpulan pengguna turun kepada sifar atau menghampiri sifar, dan ISR stabil. Gunakan kafka-producer-perf-test dan kafka-consumer-perf-test untuk mengesahkan throughput.
• Tahap perniagaan: Masa tindak balas API teras menurun, dan pemprosesan pesanan tidak lagi terkumpul.

Bila Perlu Hantar Tiket OpsGlobal

Jika pasukan anda menghadapi situasi berikut, sudah tiba masanya untuk menghubungi OpsGlobal:

• Isu middleware yang sama berulang tanpa punca jelas.
• Perlu penalaan mendalam atau perubahan seni bina (contohnya sharding, migrasi kluster).
• Kehilangan data atau ketidakseimbangan data dalam pengeluaran memerlukan pemulihan pantas.
• Pasukan anda kekurangan sokongan 24x7 manakala masalah berlaku pada waktu kritikal.

Pakar SRE OpsGlobal dapat mengenal pasti kesesakan dengan cepat, menyediakan penyelesaian pengukuhan tahap pengeluaran, dan memberikan respons mengikut SLA. Jangan tunggu sehingga kegagalan merebak; hantar tiket lebih awal untuk memastikan kesinambungan perniagaan.