Tempah Konsultasi Hantar Tiket

Panduan Praktikal Mendalam Tentang Kebolehpercayaan Middleware: Redis, RabbitMQ, Kafka

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.

Panduan Praktikal Mendalam Tentang Kebolehpercayaan Middleware: Redis, RabbitMQ, Kafka
NoSQL 6min 32 paparan 2026-07-21
RedisRabbitMQKafkaKebolehpercayaan MiddlewareSREKubernetes

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 stats menunjukkan evicted_keys melonjak, penggunaan memori hampir had.
  • RabbitMQ: Mesej bertimbun; rabbitmqctl list_queues menunjukkan 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

  1. Redis: Jalankan redis-cli info memory untuk memeriksa nisbah fragmentasi dan dasar pengusiran. Gunakan redis-cli --bigkeys untuk mencari kunci besar. Jika banyak kunci sementara tidak mempunyai TTL, mungkin berlaku kebocoran memori.
  2. RabbitMQ: Jalankan rabbitmqctl list_queues name messages_ready messages_unacknowledged consumers memory untuk mengenal pasti baris gilir yang tersekat. Periksa ruang cakera melalui rabbitmqctl eval 'rabbit_disk_monitor:get_disk_free_list().'. Jika mesej persisten terkumpul, pengguna mungkin lambat.
  3. Kafka: Pantau kadar masuk dengan kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec. Periksa pembahagian partition dengan kafka-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-length atau x-max-length-bytes). Tetapkan bilangan prefetch pengguna kepada 1 untuk mengelakkan beban lampau.
  • Kafka: Laraskan session.timeout.ms dan 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, tetapkan min.insync.replicas kepada 1 buat sementara (berisiko tinggi, perlu berhati-hati).

Pengesahan

  • Redis: redis-cli ping mengembalikan PONG; redis-cli info commandstats menunjukkan latensi normal.
  • RabbitMQ: rabbitmqctl status menunjukkan running; rabbitmqctl list_queues kedalaman baris gilir kembali normal.
  • Kafka: kafka-consumer-groups --describe LAG 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.

Tiket Hubungi WhatsApp Konsultasi