Kebolehpercayaan Middleware dalam Amalan: Redis, RabbitMQ, dan Kafka

Senario

Dalam seni bina mikroservis moden, Redis, RabbitMQ, dan Kafka membentuk tulang belakang middleware teras. Pada suatu hari, pasukan perniagaan melaporkan gangguan berselang: permintaan pengguna menjadi perlahan, beberapa pemprosesan pesanan tertunda, dan kadang-kadang mesej hilang. Pemeriksaan awal mendedahkan bahawa nisbah hit cache Redis telah menurun, giliran RabbitMQ mengalami pembekakan yang ketara, dan kumpulan pengguna Kafka menunjukkan ketinggalan yang jelas.

Gejala

• Redis: INFO stats menunjukkan evicted_keys terus meningkat, nisbah keyspace_hits vs keyspace_misses tidak seimbang, dan SLOWLOG menunjukkan banyak pertanyaan perlahan.
• RabbitMQ: Bilangan messages dan messages_unacknowledged dalam giliran meningkat, bilangan sambungan pengguna menurun, dan amaran memori/disk dicetuskan.
• Kafka: LAG dalam kumpulan pengguna terus berkembang, ISR (In-Sync Replicas) partition mengecut, atau anda melihat ralat OutOfRangeException.

Perintah Diagnosis

Diagnosis Redis

# Lihat statistik utama
redis-cli INFO stats
redis-cli INFO keyspace

# Lihat pertanyaan perlahan terkini (10 terakhir)
redis-cli SLOWLOG GET 10

# Semak keadaan persistensi untuk mengelakkan sekatan semasa penulisan semula RDB/AOF
redis-cli INFO persistence

Nota: Perintah ini hanya boleh dibaca dan tidak menjejaskan produksi. Walau bagaimanapun, SLOWLOG RESET akan memadam log; elakkan jika perlu menyimpannya.

Diagnosis RabbitMQ

# Senaraikan butiran giliran (bilangan mesej, tidak diakui, pengguna)
rabbitmqctl list_queues name messages messages_unacknowledged consumers

# Semak keadaan sambungan dan saluran
rabbitmqctl list_connections name state

# Semak amaran memori atau disk
rabbitmqctl list_nodes name mem_used disk_free_alarm

Perintah ini tidak mengubah sebarang keadaan tetapi memerlukan keistimewaan admin. Jalankan dalam tetingkap penyelenggaraan.

Diagnosis Kafka

# Lihat kemajuan penggunaan semua kumpulan pengguna dan ketinggalan
kafka-consumer-groups.sh --bootstrap-server <broker>:9092 --describe --all-groups

# Periksa replika partition topik dan status ISR
kafka-topics.sh --bootstrap-server <broker>:9092 --describe --topic <topic>

# Semak log broker dan penggunaan disk (melalui JMX atau log)
# Contoh: Dapatkan bilangan partition yang kurang direplikasi
kafka-run-class.sh kafka.tools.JmxTool --object-name kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

kafka-run-class.sh melancarkan JVM, yang mungkin meningkatkan penggunaan memori secara sementara; nilai terlebih dahulu sebelum menjalankan. Semua perintah adalah hanya baca.

Kawalan Risiko

Sebelum melaksanakan pembaikan, risiko perlu dikawal:

1. Sandarkan Konfigurasi: Sandarkan redis.conf, rabbitmq.conf, server.properties Kafka, dan tetapan kumpulan pengguna.
2. Aktifkan Mod Penyelenggaraan: Untuk Kafka, berhentikan penghasilan sementara jika boleh; untuk RabbitMQ, berhentikan sebahagian pengguna (tetapi berhati-hati untuk mengelakkan timbunan mesej bertambah).
3. Kadar Had dan Pemutus Litar: Tambah had kadar di pintu masuk dan buka pemutus litar untuk mengelakkan kegagalan bertingkat.
4. Tetapkan Tetingkap Perubahan: Semua operasi mesti dilakukan pada waktu luar puncak, dan pasukan berkaitan perlu dimaklumkan.
5. Pemantauan Dipertingkat: Aktifkan log terperinci dan pengumpulan metrik untuk mengesan anomali dengan serta-merta.

Pelan Rollback

Rollback Redis

• Jika perubahan konfigurasi (contohnya, maxmemory-policy) menyebabkan masalah, pulihkan sandaran dan mulakan semula Redis.
• Langkah rollback selamat: bash # Salin konfigurasi asal cp /etc/redis/redis.conf.bak /etc/redis/redis.conf # Mulakan semula Redis (peringatan: ini mengganggu perkhidmatan) sudo systemctl restart redis
• Jangan gunakan FLUSHALL atau FLUSHDB sebagai rollback; ia akan kehilangan data.

Rollback RabbitMQ

• Jika perubahan dasar atau parameter menyebabkan masalah, padam atau pulihkan dasar: bash rabbitmqctl clear_policy <vhost> <policy_name> # Atau gunakan semula definisi dasar sandaran
• Melumpuhkan penyegerakan automatik untuk giliran berketersediaan tinggi mungkin menyebabkan ketidaklengkapan giliran cermin; pastikan anda mempunyai pelan yang jelas.

Rollback Kafka

• Jika offset kumpulan pengguna diubah, tetapkan semula: bash kafka-consumer-groups.sh --bootstrap-server <broker>:9092 --group <group> --topic <topic> --reset-offsets --to-earliest --execute

  Ini akan menggunakan semula mesej sejarah, berpotensi menyebabkan pemprosesan berulang; jalankan dengan berhati-hati.

• Jika isu disebabkan oleh peningkatan versi, kembali kepada binari sebelumnya dan pulihkan fail konfigurasi asal.

Langkah Pengesahan

Selepas pembaikan, sahkan:

• Redis: Semak sama ada evicted_keys telah menurun, nisbah hit pulih, SLOWLOG dipendekkan, dan kependaman INFO ping kembali normal.
• RabbitMQ: Bilangan messages dan unacknowledged terus menurun, sambungan pengguna stabil, amaran memori/disk hilang.
• Kafka: LAG kumpulan pengguna secara beransur-ansur mencecah sifar, ISR dipulihkan sepenuhnya, dan semua replika partition disegerakkan.

Juga lakukan pengesahan peringkat perniagaan: simulasikan aliran pembayaran, pesanan, dan kritikal lain untuk memastikan tiada kehilangan atau pengulangan mesej. Pantau metrik SLO (contohnya, kependaman p99) untuk memastikan ia kembali ke garis dasar.

Bila Perlu Menghantar Tiket OpsGlobal

Hantar tiket dengan segera jika:

1. Anda tidak dapat mengenal pasti punca selepas 30+ minit menyelesaikan masalah.
2. Terdapat kehilangan atau kerosakan data yang memerlukan perkhidmatan pembaikan data profesional.
3. Isu perkakasan atau kernel asas disyaki, seperti I/O disk yang tidak normal atau getaran rangkaian.
4. Pertukaran gagal yang kompleks merentasi zon ketersediaan atau kluster diperlukan.
5. Pasukan anda kekurangan pengalaman operasi mendalam dengan komponen middleware ini dan memerlukan panduan pakar.

Pasukan SRE OpsGlobal boleh memberikan diagnosis pantas, peningkatan prestasi, dan sokongan pemulihan bencana tanpa menceroboh kod perniagaan, membantu anda meminimumkan masa henti.