Sistem rosak Ia hanya mengenali kod tetapi bukan orangnya.

Rakan-rakan yang dihormati, dengar nasihat saya semasa menulis kod untuk menyediakan kaedah untuk orang lain membuat panggilan, sama ada panggilan sistem dalaman, panggilan sistem luaran atau panggilan yang dicetuskan secara pasif (seperti penggunaan MQ, pelaksanaan panggilan balik. dll.), anda mesti menambah semakan keadaan yang diperlukan. Jangan percaya sesetengah rakan sekerja yang mengatakan bahawa keadaan ini pasti akan berjangkit, pasti ada nilai, pasti tidak akan kosong, dll. Tidak, sebelum Tahun Baru Cina, saya telah ditipu dan mengalami kemalangan pengeluaran, jadi bonus akhir tahun saya pada dasarnya dikurangkan separuh.

Saya memutuskan untuk menumpukan pada kod itu sendiri, bukannya orang, untuk memastikan ketersediaan dan kestabilan sistem yang tinggi. Berikut adalah beberapa pelajaran kecil yang mungkin membantu anda juga.

1. Apa yang berlaku

Senario perniagaan saya ialah: apabila perniagaan A berubah, ia akan mencetuskan penghantaran mesej MQ, dan kemudian aplikasi akan menerima mesej MQ, dan selepas pemprosesan, data akan ditulis kepada Elasticsearch.

(1) Menerima penggera yang tidak normal daripada perniagaan A. Penggera pada masa itu adalah seperti berikut:

(2) Nampaknya agak pelik pada pandangan pertama. Bagaimanakah ia boleh menjadi anomali Redis? Kemudian saya menyambung ke Redis dan tidak ada masalah saya memeriksa kelompok Redis sekali lagi dan semuanya normal. Jadi saya melepaskannya, memikirkan ia adalah masalah rangkaian yang tidak disengajakan.

Kemudian, dalam kumpulan masalah teknikal, perkhidmatan pelanggan melaporkan bahawa beberapa pengguna mengalami situasi tidak normal saya segera memeriksa sistem untuk mengesahkan kewujudan masalah sporadis.

(4) Jadi saya melihat beberapa komponen teras di luar kebiasaan:

• Status gerbang, status muat Pod perniagaan teras dan status muat Pod pusat pengguna.
• Situasi MySQL: memori, CPU, SQL perlahan, kebuntuan, bilangan sambungan, dsb.

Menemui situasi SQL yang perlahan dan masa kunci metadata yang panjang, terutamanya disebabkan oleh jumlah data yang besar dan kelajuan pelaksanaan yang perlahan yang disebabkan oleh pertanyaan jadual penuh jadual besar, yang seterusnya menyebabkan kunci metadata bertahan terlalu lama, sekali gus meletihkan nombor sambungan pangkalan data.

SELECT xxx,xxx,xxx,xxx FROM 一张大表

(6) Selepas membunuh beberapa sesi perlahan serta-merta, saya mendapati sistem masih belum pulih sepenuhnya Mengapa? Sekarang bahawa pangkalan data adalah normal, mengapa ia tidak dipulihkan sepenuhnya? Saya terus melihat pemantauan aplikasi dan mendapati bahawa 2 daripada 10 Pod di pusat pengguna adalah tidak normal, dan CPU dan memori telah habis. Tidak hairanlah ada keabnormalan sekali-sekala apabila menggunakannya. Jadi saya dengan cepat memulakan semula Pod dan memulihkan aplikasi terlebih dahulu.

(7) Masalahnya telah ditemui Seterusnya, kami akan terus menyiasat mengapa Pod di pusat pengguna ditutup. Mulakan analisis dari titik keraguan berikut:

• Adakah terdapat sesuatu yang salah dengan kod untuk menyegerakkan data ke Elasticsearch Mengapa ia tidak boleh menyambung ke Redis?
• Bolehkah terdapat terlalu banyak pengecualian, menyebabkan baris gilir kumpulan benang untuk menghantar mesej amaran pengecualian penuh, dan kemudian OOM?
• Di manakah saya boleh melakukan pertanyaan jadual penuh tanpa syarat pada jadual besar perniagaan A?

(8) Teruskan menyiasat titik syak a pada mulanya, saya fikir pautan Redis tidak dapat diperoleh, yang menyebabkan pengecualian memasuki baris gilir benang, dan kemudian baris gilir itu pecah, menyebabkan OOM. Menurut idea ini, saya mengubah suai kod, menaik taraf dan terus memerhati, tetapi letupan SQL dan pusat pengguna yang sama masih berlaku. Kerana tiada kelainan, syak point b juga boleh diketepikan.

(9) Pada ketika ini, hampir pasti bahawa titik c disyaki, iaitu tempat pertanyaan jadual penuh bagi jadual besar perniagaan A dipanggil, yang menyebabkan memori dalam pusat pengguna menjadi terlalu besar, dan JVM tidak mempunyai masa untuk mengitar semulanya, dan kemudian terus meletupkan CPU. Pada masa yang sama, kerana keseluruhan data jadual terlalu besar, masa kunci metadata semasa pertanyaan terlalu lama, menyebabkan sambungan tidak dapat dikeluarkan dalam masa dan akhirnya hampir habis.

(10) Jadi syarat pengesahan yang diperlukan untuk menanyakan jadual besar perniagaan A telah diubah suai dan digunakan semula untuk pemerhatian dalam talian. Terdapat masalah dengan kedudukan akhir.

2. Punca masalah

Kerana apabila menukar jadual perniagaan B, anda perlu menghantar mesej MQ (segerakkan data jadual perniagaan A ke ES Selepas menerima mesej MQ, tanya data yang berkaitan dengan jadual perniagaan A, dan kemudian selaraskan data ke Elasticsearch.

Tetapi apabila menukar jadual perniagaan B, tiada syarat yang diperlukan untuk jadual perniagaan A. Pada masa yang sama, saya tidak mengesahkan syarat yang diperlukan, yang mengakibatkan imbasan jadual penuh bagi jadual perniagaan A yang besar. Kerana:

某些同事说，“这个条件肯定会传、肯定有值、肯定不为空...”，结果我真信了他！！！

Disebabkan oleh perubahan yang kerap dalam jadual perniagaan B pada masa itu, lebih banyak mesej MQ telah dihantar dan digunakan, yang mencetuskan lebih banyak imbasan jadual penuh bagi jadual besar perniagaan A, yang seterusnya membawa kepada lebih banyak masa penguncian metadata Mysql yang terlalu panjang dan bilangan sambungan terakhir telah digunakan secara berlebihan.

Pada masa yang sama, hasil pertanyaan jadual besar perniagaan A dikembalikan ke memori pusat pengguna setiap kali, sekali gus mencetuskan kutipan sampah JVM, tetapi ia tidak boleh dikitar semula, memori dan CPU habis .

Pengecualian Redis tidak boleh mendapatkan sambungan, ia hanyalah bom asap Kerana terlalu banyak acara MQ yang dihantar dan digunakan, sebilangan kecil benang tidak dapat mendapatkan sambungan Redis dalam sekelip mata.

Akhir sekali, saya menambahkan pengesahan syarat dalam kod untuk menggunakan acara MQ, dan juga menambahkan pengesahan syarat yang diperlukan pada jadual perniagaan pertanyaan A, mengatur semula dalam talian dan menyelesaikan masalah.

3. Ringkaskan pelajaran

Selepas kejadian ini, saya juga merumuskan beberapa pengajaran dan berkongsi dengan anda:

(1) Sentiasa berwaspada dengan masalah dalam talian Apabila masalah berlaku, anda tidak boleh melepaskannya dan menyiasatnya dengan cepat. Jangan ragu lagi masalah kegelisahan rangkaian. Kebanyakan masalah tiada kaitan dengan rangkaian.

(2) Meja perniagaan yang besar itu sendiri mesti mengetahui tentang perlindungan, dan pertanyaan mesti menambah pengesahan syarat yang diperlukan.

(3) Apabila menggunakan mesej MQ, anda mesti mengesahkan syarat yang diperlukan dan tidak mempercayai mana-mana sumber maklumat.

(4) Jangan sesekali percaya dengan rakan sekerja yang berkata, "Keadaan ini pasti akan berjangkit, pasti ada nilai, pasti tidak akan kosong," dsb. Untuk memastikan ketersediaan dan kestabilan sistem yang tinggi, kami hanya mengenali kod dan bukan orangnya.

(5) Urutan penyelesaian masalah umum apabila masalah berlaku:

• CPU pangkalan data, kebuntuan, SQL perlahan.
• CPU, memori dan log gerbang masuk dan komponen teras aplikasi.

(6) Kebolehmerhatian dan penggera perniagaan adalah penting dan mesti menyeluruh, supaya masalah dapat ditemui dan diselesaikan dengan lebih cepat.

Atas ialah kandungan terperinci Sistem rosak Ia hanya mengenali kod tetapi bukan orangnya.. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!