Tempah Konsultasi Hantar Tiket

Panduan Praktikal Kebolehpercayaan Middleware Redis, RabbitMQ & Kafka

Penerokaan mendalam tentang memastikan ketersediaan tinggi Redis, RabbitMQ, dan Kafka dalam persekitaran Kubernetes pengeluaran. Merangkumi senario, simptom, diagnosis, arahan, kawalan risiko, rollback, pengesahan, dan kriteria eskalasi untuk tiket OpsGlobal.

Panduan Praktikal Kebolehpercayaan Middleware Redis, RabbitMQ & Kafka
NoSQL 6min 10 paparan 2026-06-18
KubernetesSRERedisRabbitMQKafkaKebolehpercayaan Middleware

Senario

Anda menguruskan kluster Kubernetes multi-penyewa yang menempatkan cache Redis, baris gilir mesej RabbitMQ, dan strim peristiwa Kafka. Suatu hari, pengguna melaporkan kelewatan pemprosesan pesanan yang teruk dan kegagalan pengesahan pembayaran. Pemerhatian awal menunjukkan induk Redis kerap bertukar, baris gilir RabbitMQ bertimbun, dan kumpulan pengguna Kafka semakin ketinggalan.

Simptom

  • Redis: INFO stats menunjukkan keyspace_misses meningkat, latensi >100ms, dan repl_backlog_active berubah-ubah.
  • RabbitMQ: UI pengurusan panjang baris gilir meningkat, rabbitmqctl list_queues menunjukkan bilangan mesej melebihi ambang, beberapa baris gilir ada mesej unacked.
  • Kafka: kafka-consumer-groups --describe menunjukkan LAG meningkat secara berterusan, penggunaan cakera broker hampir 90%.

Diagnosis

  1. Redis: Jalankan redis-cli -h <host> -p <port> info replication untuk memeriksa status induk-hamba. Gunakan SLOWLOG GET 10 untuk menganalisis pertanyaan perlahan. Periksa systemctl status redis dan log.
  2. RabbitMQ: Laksanakan rabbitmqctl list_queues name messages consumers untuk menilai kecekapan pengguna. Gunakan rabbitmqctl status untuk penggera memori/cakera. Jalankan rabbitmq-diagnostics untuk pemeriksaan sambungan/saluran.
  3. Kafka: Gunakan kafka-topics --describe --topic <topic> --bootstrap-server <broker> untuk melihat taburan partition. kafka-log-dirs --describe --bootstrap-server <broker> mengesan ketidakseimbangan cakera. Periksa /var/log/kafka/server.log untuk ralat.

Arahan

Pembetulan Redis

# Paksa pemilihan semula (jika gagal auto-failover)
redis-cli -h <slave_ip> -p 6379 replicaof no one

# Promosi hamba, kemudian arah hamba lain ke induk baru
redis-cli -h <other_slave> -p 6379 replicaof <new_master_ip> 6379

# Laraskan log perlahan
redis-cli CONFIG SET slowlog-log-slower-than 10000
redis-cli CONFIG SET slowlog-max-len 128

# Hadkan memori
redis-cli CONFIG SET maxmemory 4gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru

Pembetulan RabbitMQ

# Paksa pengisytiharan semula baris gilir
rabbitmqctl eval 'rabbit_amqqueue:declare(rabbit_misc:r(<<"/">>, queue, <<"queue_name">>), true, false, []).'

# Tutup sambungan tersekat
rabbitmqctl list_connections name | awk '{print $1}' | xargs -I {} rabbitmqctl close_connection {} "ditutup secara manual"

# Guna dasar HA
rabbitmqctl set_policy ha-all ".*" '{"ha-mode":"all","ha-sync-mode":"automatic"}' --priority 1

Pembetulan Kafka

# Imbangkan semula kumpulan pengguna
kafka-consumer-groups --bootstrap-server <broker> --group <group> --reset-offsets --to-latest --execute

# Tambah partition (tidak boleh balik)
kafka-topics --alter --topic <topic> --partitions <new_count> --bootstrap-server <broker>

# Pendekkan pengekalan untuk kosongkan ruang
kafka-configs --bootstrap-server <broker> --entity-type topics --entity-name <topic> --alter --add-config retention.ms=86400000

Kawalan Risiko

  • Redis: Sebelum REPLICAOF, pastikan hamba diselaraskan sepenuhnya; semasa melaraskan maxmemory, tinggalkan ruang untuk elak OOM.
  • RabbitMQ: Menutup sambungan mungkin kehilangan mesej transaksi; sandarkan dasar sebelum pengubahsuaian.
  • Kafka: Penambahan partition tidak boleh balik; nilaikan keserasian pengguna hiliran. Set semula offset boleh menyebabkan penduaan atau kehilangan mesej.

Rollback

  • Redis: Pasang semula induk lama: redis-cli -h <old_master> replicaof <new_master> 6379, kemudian promosi semula jika perlu.
  • RabbitMQ: Buang dasar: rabbitmqctl clear_policy ha-all. Mulakan semula nod: systemctl restart rabbitmq-server.
  • Kafka: Tidak boleh kurangkan partition; buat semula topik dan migrasi. Set semula offset menggunakan --to-earliest.

Pengesahan

  • Redis: INFO stats menunjukkan nisbah keyspace_hits >99%, kependaman <10ms, replikasi OK.
  • RabbitMQ: Panjang baris gilir normal, rabbitmqctl list_queues menunjukkan 0 unacked, kadar pengguna sepadan.
  • Kafka: kafka-consumer-groups --describe LAG hampir 0, daya pemprosesan pengeluar memenuhi SLO.

Bila Hantar Tiket OpsGlobal

  • Masalah berulang selepas beberapa campur tangan manual.
  • Perlu naik taraf perkakasan atau perubahan seni bina kluster.
  • Perniagaan teras terjejas dan pasukan dalaman tidak dapat selesaikan dengan cepat.
  • Perlu audit profesional konfigurasi dan penalaan prestasi.

Senario Penggunaan

Sesuai untuk pasukan yang menyelesaikan isu NoSQL dan memerlukan aliran kerja yang jelas.

Latar Belakang Masalah

Penerokaan mendalam tentang memastikan ketersediaan tinggi Redis, RabbitMQ, dan Kafka dalam persekitaran Kubernetes pengeluaran. Merangkumi senario, simptom, diagnosis, arahan, kawalan risiko, rollback, pengesahan, dan kriteria eskalasi untuk tiket 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