Senario
Platform e-dagang anda mengalami kegagalan checkout. Pemantauan menunjukkan latensi Redis meningkat ke 500ms, baris gilir RabbitMQ berkembang ke 100k mesej, dan ketinggalan pengguna Kafka melebihi 10k setiap partition. Puncanya? Gabungan had memori yang salah konfigurasi, kod pengguna yang tidak dioptimumkan, dan partition rangkaian.
Gejala
- Latensi p99 tinggi dalam pertanyaan Redis
- Baris gilir RabbitMQ memberi amaran penggera memori
- Amaran ketinggalan pengguna Kafka
- Ralat yang dilihat pengguna dalam pemprosesan pembayaran
Diagnosis
Redis
Jalankan redis-cli info stats | tail -20 untuk memeriksa instantaneous_ops_per_sec dan rejected_connections. Gunakan redis-cli memory stats untuk melihat nisbah fragmentasi.
RabbitMQ
Gunakan rabbitmqctl list_queues name messages messages_ready messages_unacknowledged consumers memory untuk mengenal pasti baris gilir yang membengkak. Periksa rabbitmq-diagnostics status untuk penggera.
Kafka
Jalankan kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --describe untuk melihat ketinggalan. Periksa kafka-log-dirs untuk penggunaan cakera.
Arahan
# Redis: Periksa latensi
redis-cli --intrinsic-latency 100
# RabbitMQ: Kosongkan baris gilir (gunakan dengan berhati-hati)
rabbitmqctl purge_queue my_queue
# Kafka: Tetapkan semula offset pengguna (berhati-hati)
kafka-consumer-groups --bootstrap-server localhost:9092 --group my-group --topic my-topic --reset-offsets --to-earliest --execute
Nota: Pembersihan dan penetapan semula boleh menyebabkan kehilangan data; gunakan hanya apabila kehilangan mesej boleh diterima.
Kawalan Risiko
- Dayakan lazy freeing Redis:
CONFIG SET lazyfree-lazy-eviction yes - Hadkan panjang baris gilir RabbitMQ dengan x-max-length
- Tambah partition Kafka atau selari pengguna
- Laksanakan pemutus litar dalam aplikasi untuk mengelakkan kegagalan berantai
Rollback
- Redis: Kembalikan perubahan konfigurasi dengan
CONFIG SET lazyfree-lazy-eviction no - RabbitMQ: Guna semula had baris gilir asal
- Kafka: Pulihkan offset pengguna sebelumnya atau mulakan semula dengan konfigurasi betul
- Umum: Kembalikan perubahan kod aplikasi
Pengesahan
- Periksa latensi Redis turun di bawah 10ms
- Kiraan baris gilir RabbitMQ berkurang
- Ketinggalan pengguna Kafka berkurang ke sifar
- Pantau masa tindak balas aplikasi
Bila Menghantar Tiket OpsGlobal
Jika anda kekurangan kapasiti untuk melaksanakan kawalan, atau jika isu berterusan selepas penyelesaian masalah asas, hantar tiket. SRE OpsGlobal boleh mendiagnosis isu mendalam seperti bufferbloat, penalaan kernel, dan partition rangkaian kompleks.
Senario Penggunaan
Sesuai untuk pasukan yang menyelesaikan isu NoSQL dan memerlukan aliran kerja yang jelas.
Latar Belakang Masalah
Pelajari cara mendiagnosis dan menyelesaikan isu kebolehpercayaan biasa dalam Redis, RabbitMQ, dan Kafka. Panduan ini merangkumi senario sebenar, gejala, arahan diagnosis, kawalan risiko, prosedur rollback, dan bila perlu menghubungi OpsGlobal untuk sokongan SRE jarak jauh.
Langkah Penyelesaian
Sahkan impak dan perubahan terkini, kumpul log, konfigurasi dan metrik, kemudian baiki mengikut risiko.
Contoh Arahan
Gantikan contoh dengan nama sumber sebenar dan simpan kata laluan, token atau kunci dalam pembolehubah persekitaran.
Risiko
Sebelum operasi produksi, semak sandaran, akses, tetingkap perubahan dan pelan rollback.
Pelan Rollback
Simpan konfigurasi dan versi asal; rollback konfigurasi, imej atau perubahan pangkalan data jika metrik tidak normal.
Senarai Serahan
Rekod punca isu, arahan penting, langkah pembaikan, hasil pengesahan dan cadangan susulan.
Perlu bantuan isu teknikal serupa?
Jika pelayan, Kubernetes, Docker, CI/CD, pangkalan data atau pemantauan anda bermasalah, hantar log dan konfigurasi untuk diagnosis jauh.