Senario
Semasa jualan kilat, sistem pemprosesan pesanan e-dagang menjadi perlahan. Amaran menunjukkan penggunaan memori Redis meningkat, kedalaman baris gilir RabbitMQ melonjak, dan lag pengguna Kafka semakin meningkat.
Simptom
- Redis: Sambungan pelanggan tamat masa;
INFO statsmenunjukkan evicted_keys melonjak, penggunaan memori hampir had. - RabbitMQ: Mesej bertimbun;
rabbitmqctl list_queuesmenunjukkan jumlah unacknowledged tinggi; masa menunggu I/O cakera bertambah. - Kafka: Lag kumpulan pengguna (
kafka-consumer-groups --describe) terus meningkat; log pengguna melaporkan "Rebalance in progress".
Diagnosis
- Redis: Jalankan
redis-cli info memoryuntuk memeriksa nisbah fragmentasi dan dasar pengusiran. Gunakanredis-cli --bigkeysuntuk mencari kunci besar. Jika banyak kunci sementara tidak mempunyai TTL, mungkin berlaku kebocoran memori. - RabbitMQ: Jalankan
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers memoryuntuk mengenal pasti baris gilir yang tersekat. Periksa ruang cakera melaluirabbitmqctl eval 'rabbit_disk_monitor:get_disk_free_list().'. Jika mesej persisten terkumpul, pengguna mungkin lambat. - Kafka: Pantau kadar masuk dengan
kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec. Periksa pembahagian partition dengankafka-consumer-groups --describe --members --verbose. Pengimbangan semula yang kerap boleh menyebabkan pengguna kebuluran.
Arahan Berguna
# Redis
redis-cli info stats | grep evicted_keys
redis-cli -h <hos> -p <port> --bigkeys
# RabbitMQ
rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers memory --no-table-headers
rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
# Kafka
kafka-consumer-groups --bootstrap-server localhost:9092 --group order-group --describe
kafka-topics --bootstrap-server localhost:9092 --describe --topic orders
Kawalan Risiko
- Redis: Tetapkan
maxmemory-policy allkeys-lru(tidak menyekat). Elakkan kunci besar (>1MB). Gunakan Sentinel atau Cluster untuk HA. - RabbitMQ: Konfigurasikan baris gilir cermin untuk HA. Hadkan panjang baris gilir (
x-max-lengthataux-max-length-bytes). Tetapkan bilangan prefetch pengguna kepada 1 untuk mengelakkan beban lampau. - Kafka: Laraskan
session.timeout.msdan selang degupan jantung untuk pengimbangan semula. Gunakan pengedar partition melekit untuk mengurangkan pengimbangan semula. Pantau lag pengguna dengan amaran.
Penggulungan Semula
- Redis: Jika penulisan semula AOF menyebabkan ketinggalan, lumpuhkan sementara (
CONFIG SET auto-aof-rewrite-percentage 0), tulis semula secara manual kemudian. Jika memori habis, tingkatkan skala atau gunakan swap (tidak disyorkan untuk pengeluaran). - RabbitMQ: Hentikan pengeluar (cth., melalui pemutus litar) untuk membenarkan pengguna mengosongkan timbunan. Jika cakera penuh, pindahkan baris gilir ke nod yang sihat (
rabbitmqctl set_cluster_name ha). - Kafka: Tambah lebih banyak contoh pengguna atau laraskan
fetch.min.bytes. Jika replika tidak segerak, tetapkanmin.insync.replicaskepada 1 buat sementara (berisiko tinggi, perlu berhati-hati).
Pengesahan
- Redis:
redis-cli pingmengembalikan PONG;redis-cli info commandstatsmenunjukkan latensi normal. - RabbitMQ:
rabbitmqctl statusmenunjukkan running;rabbitmqctl list_queueskedalaman baris gilir kembali normal. - Kafka:
kafka-consumer-groups --describeLAG hampir sifar; tiada ralat dalam log pengguna.
Bila Perlu Hantar Tiket OpsGlobal
Tingkatkan apabila pasukan dalaman tidak dapat pulih walaupun mengikuti langkah-langkah: - Kerosakan perkakasan berterusan (kegagalan cakera, partition rangkaian). - Perlu pemulihan data lanjutan (pembaikan RDB rosak). - Penalaan prestasi kluster berskala besar (cth., terlalu banyak partition menyebabkan kesesakan pengawal). - Kurang kepakaran middleware khusus (cth., penyelesaian pemisahan otak kluster RabbitMQ).
Pasukan SRE OpsGlobal menyediakan sokongan jauh 24/7 termasuk penyelesaian masalah masa nyata, pengoptimuman seni bina, dan perancangan pemulihan bencana.
Senario Penggunaan
Sesuai untuk pasukan yang menyelesaikan isu NoSQL dan memerlukan aliran kerja yang jelas.
Latar Belakang Masalah
Panduan langkah demi langkah untuk mendiagnosis dan menyelesaikan isu kebolehpercayaan dalam Redis, RabbitMQ, dan Kafka, termasuk simptom, arahan, kawalan risiko, penggulungan semula, pengesahan, dan bila perlu menghubungi OpsGlobal.
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.