Kebolehpercayaan Middleware dalam Pengeluaran: Panduan Praktikal untuk Penyelesaian Masalah Redis, RabbitMQ, dan Kafka

Senario

Semasa jualan kilat, platform e-dagang bergantung pada cache Redis, barisan mesej RabbitMQ, dan bas peristiwa Kafka. Tiba-tiba, kependaman pesanan melonjak, beberapa permintaan tamat masa, dan amaran pemantauan berbunyi.

Simptom

• Redis: redis-cli --latency menunjukkan >100ms (biasa <1ms); arahan INFO memaparkan used_memory_peak menghampiri maxmemory.
• RabbitMQ: UI Pengurusan menunjukkan pengumpulan baris; rabbitmqctl list_queues messages_ready mendedahkan berjuta-juta mesej belum digunakan; amaran memori nod.
• Kafka: kafka-consumer-groups --describe menunjukkan pengguna ketinggalan berpuluh ribu; kafka-run-class.sh kafka.tools.JmxTool melaporkan masa pemprosesan permintaan meningkat.

Diagnosis

Redis

# Semak pertanyaan perlahan
redis-cli SLOWLOG GET 10
# Semak penggunaan memori
redis-cli INFO memory | grep used_memory_human
# Cari kunci besar
redis-cli --bigkeys
# Semak bilangan sambungan
redis-cli CLIENT LIST | wc -l

RabbitMQ

# Butiran baris
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers
# Memori nod
rabbitmqctl status | grep memory
# Sambungan
rabbitmqctl list_connections state user
# Mesej belum diakui setiap saluran
rabbitmqctl list_channels connection messages_unacknowledged

Kafka

# Ketinggalan kumpulan pengguna
kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe
# Taburan ketua partition
kafka-topics --describe --topic my-topic --bootstrap-server localhost:9092
# Saiz segmen log
kafka-log-dirs --bootstrap-server localhost:9092 --describe --topic-list my-topic
# Masa pemprosesan permintaan (perlukan JMX diaktifkan)

Kawalan Risiko

Sebelum sebarang perubahan: - Redis: Jika memori hampir had, tetapkan maxmemory dan dasar pengusiran allkeys-lru. Jangan sekali-kali jalankan FLUSHALL dalam pengeluaran tanpa kelulusan dan sandaran. - RabbitMQ: Sahkan kesihatan pengguna sebelum skala. Memadam baris akan kehilangan data; elakkan kecuali perlu. - Kafka: Sandarkan server.properties sebelum perubahan konfigurasi. Jangan gunakan kafka-delete-records pada topik pengeluaran tanpa snapshot.

Undur

Redis

Jika konfigurasi diubah: CONFIG SET maxmemory 0 untuk kembali ke lalai. Jika FLUSHALL dilaksanakan, pulihkan dari RDB/AOF—perhatikan potensi kehilangan data.

RabbitMQ

Jika polisi (contohnya TTL) ditambah: rabbitmqctl clear_policy <queue>. Jika parameter diubah: gunakan rabbitmqctl set_parameter untuk mengembalikan.

Kafka

Jika log.retention.hours diubah: tukar kembali ke nilai asal dan mulakan semula broker secara rolling.

Pengesahan

• Redis: Jalankan redis-cli --latency untuk mengesahkan kependaman menurun; perhatikan penggunaan memori INFO menurun.
• RabbitMQ: Semak kedalaman baris menurun; rabbitmqctl list_queues messages_ready menunjukkan lebih sedikit mesej.
• Kafka: Ketinggalan pengguna mencapai 0; kafka-consumer-groups --describe memaparkan LAG sebagai 0.

Bila Menghantar Tiket OpsGlobal

• Perubahan yang memerlukan koordinasi merentas pasukan (contohnya pengembangan storan).
• Punca akar tidak jelas selepas diagnosis asas.
• Isu berterusan selepas undur, atau perlu pembinaan semula kluster.
• Tampalan keselamatan atau refaktor seni bina diperlukan.

Kesimpulan

Dengan pengiktirafan simptom sistematik, arahan diagnostik selamat, dan undur terkawal, kebanyakan isu middleware dapat diselesaikan dalam 10 minit. OpsGlobal menyediakan sokongan pakar 24/7 untuk memastian laluan kritikal anda sentiasa tersedia.