Cara saya memproses lebihan Entri setiap permintaan - With Go!

Sebelum kita bermula, sedikit konteks tentang siapa saya dan mengapa ia penting dalam kes ini. Saya seorang pembangun perisian di Syarikat Pembuatan Notebook, bekerja di sini selama dua tahun yang lalu. Dalam pasukan yang saya ada sekarang, saya adalah pembangun tunggal, bertanggungjawab untuk mencipta, memantau dan menyelenggara saluran paip data, automasi dan sistem pemantauan dengan Go dan Grafana.
Satu lagi perkara yang boleh saya tambah, pada tahun sebelumnya, saya adalah seorang pelatih. Dan saya belajar sendiri.

Ok, tetapi mengapa ia penting?

Nah, saya tidak mempunyai pembangun kanan, atau sebarang bentuk bimbingan dari dalam yang boleh membimbing saya apabila saya menghadapi sekatan jalan raya atau masalah yang tidak dapat saya selesaikan sendiri, dan itulah sebab utama saya menulis. Saya fikir ia adalah perkara yang menyeronokkan untuk dilakukan dan ingin dikongsi. Ia tidak akan menjadi perisian yang menakjubkan, kejayaan atau apa-apa seperti itu, tetapi peringatan bahawa adalah mungkin untuk membina sesuatu dari bawah. Anda tidak perlu menjadi satu dalam satu juta pembangun 10x atau sesuatu seperti itu.

P.S: Saya menggunakan neovim btw.

Satu Juta Baris

Nombor ini mungkin kelihatan seperti keterlaluan atau sesuatu seperti itu, dan, walaupun saya harap ia berlaku, tetapi tidak. Lihat, apabila bekerja dalam konteks kilang, kadangkala kami tidak mengambil kira berapa banyak item yang diperlukan dan berapa banyak data yang dijana apabila anda perlu menjejaki setiap titik dalam banyak baris gilir pembuatan, untuk setiap komponen.
Sama ada skru kecil, sama ada CPU gen terakhir, ia mesti dijejaki, dengan cap masa!
Jadi, ya, jumlah data yang dijana adalah betul, dan itu hanya permulaan. Berikut ialah perkara menarik lain yang menjadikan masalah itu sejuk (dalam perspektif saya):

• Sumber data ini tidak dimampatkan atau sebagainya, jadi purata masa permintaan adalah hampir 2 hingga 3 minit pada hari yang baik. Ia boleh melebihi 5 minit jika sumbernya ketinggalan (Ia adalah sistem java yang lebih tua daripada saya.).
• Mengenai format, saya boleh memilih antara menangani respons XML atau respons CSV, sudah tentu saya mengambil laluan CSV. Saya bukan masokis.
• Dan terdapat keperluan untuk memilih selang pengambilan data, dengan sekurang-kurangnya satu jam (Tidak, saya tidak tahu mengapa, ya, saya telah mencuba selang kecil).
• Sumber tidak mempunyai sistem pemuatan malas atau cache, jadi dua permintaan yang sama akan menghasilkan respons yang sama, dengan masa yang berbeza.
• Dan akhirnya, untuk perkara yang pedas, ia adalah perkara Microsoft, yang dikenali sebagai Perkhidmatan Pelaporan Pelayan SQL, dengan kaveatnya yang tidak jelas. Oh, dan pangkalan data yang saya perlu gunakan ialah MSSQL, yang menyakitkan.

Itulah konteks keseluruhannya, dan kini bahagian yang menyeronokkan bermula.

Lelaran pertama - DMP

Cara saya suka mendekati perisian agak mudah. Jadikan ia hodoh dan hampir tidak berfungsi -> Pastikan ia hodoh dan tingkatkan fungsi -> Masih hodoh, tetapi dioptimumkan dengan lebih baik -> Cantik, Dioptimumkan dan Berfungsi -> Kemudian pengurus anda mengatakan bahawa kerja yang anda lakukan terlalu bagus dan sumbernya tidak dapat mengendalikannya, menyebabkan gangguan. FML.

Apa pun, DMP adalah singkatan dari Dumb Mode Protocol, cuma buat ia berfungsi dengan cara yang paling bodoh yang anda boleh, yang bermaksud melakukannya untuk hampir tidak berfungsi.

Jadi, untuk pusingan pertama, matlamat saya adalah mudah, mengesahkan, membuat permintaan, menghuraikan data, menghantar ke pangkalan data. Cukup mudah, bukan? Dan, dalam kertas, ia adalah, sehingga saya mendapati bahawa kaedah pengesahan dan kebenaran yang saya perlu gunakan ialah ntlmssp, iaitu kaedah pengesahan respons-cabaran yang saya tidak tahu wujudnya. Sebenarnya, saya terpaksa pergi ke kod .NET 4 warisan untuk mencarinya. Saya tidak pernah melakukan C#.
Selepas melalui kod warisan yang lebih lama daripada saya, menderita cuba memahaminya kerana, atas sebab tertentu, siapa yang menulisnya berpendapat adalah idea yang baik untuk menyembunyikannya ke dalam 5 lapisan abstraksi, pembina dan perkara OOP. Tidak menyeronokkan, pengalaman yang merendahkan. Dan kemudian saya membuatnya berfungsi. Sejam kemudian saya menyekat pengguna saya kerana, nampaknya, sumbernya mempunyai kadar yang mengehadkan. TAPI TIADA CACHE ATAU MALAS LOADING.

Nah, selepas semua itu, saya hanya perlu lulus paremeter pertanyaan dan mendapatkan data, tiada lagi komplikasi dengan sumbernya. Ok, mari kita cari dokumentasi untuk parameter pertanyaan.

...

Pada ketika ini, semua perkara yang dipertimbangkan, anda mungkin meneka dengan betul. Dokumentasi? Adakah ini sejenis makanan eksotik yang hanya dihidangkan di Silicon Valley?
Bagaimanapun, selepas memerah otak saya, saya memutuskan untuk memeriksa tapak/antara muka Perkhidmatan Pelaporan Pelayan SQL ini, dan, yang menggembirakan saya, dan kemudian rasa benci, ia mempunyai cara untuk mengetahui penapis dan nilainya.

Hanya untuk mengetahui bahawa penapis ("Semua") dalam halaman, untuk memilih, katakan, semua baris pembuatan, hanyalah abstraksi untuk memeriksa semua kotak. Ok, mari salin penapis dan masukkan ke dalam rentetan pertanyaan, kodkannya dan gembira!

IA BERKESAN! Atau begitulah yang saya fikirkan.

Ingat apabila saya mengatakan bahawa pengguna saya disekat? Nah, nampaknya mempunyai kebenaran pentadbir untuk melaksanakan tugas sedemikian, diberi kuasa oleh C-Suite untuk melakukannya (Malah, ia telah diminta oleh mereka), tidak mencukupi untuk membenarkan saya melakukan berbilang permintaan. Pengguna saya telah disekat, tetapi, kepada pengurus saya, ia sama seperti mengatakan "Tiada apa-apa yang berlaku". Nasib baik, saya berjaya menyahsekatnya dengan cepat.

Sementara itu, saya memutuskan untuk bekerja mengikut cara yang saya akan mendekati keseluruhan projek ini. Pada ketika ini saya sudah mempunyai sampel itu, dan ia sesuai dengan tajuk jawatan itu. Melihat tujuh digit itu membuatkan saya mempersoalkan diri saya sama ada saya mampu melakukannya kerana saya tidak mempunyai pengalaman dengan volum data ini.

Untuk mendapatkan idea saya dalam bentuk, saya berharap ke dalam excalidraw dan mereka apa yang saya mahu lakukan. Saya tahu konsep kumpulan pekerja tetapi tidak melaksanakannya sebelum ini. Jadi, saya membaca mengenainya, melihat beberapa pelaksanaan dan bertanya kepada rakan saya yang banyak membantu saya. Dia senior yang saya tak ada.

Selepas menulisnya dalam kod pseudo, saya terfikir sendiri:

"Wah, ini cukup kemas, pastinya ia tidak akan menjana kebocoran memori dengan semua saluran dan goroutin itu, bukan?"

Ok, ia mungkin bukan perkataan yang tepat, tetapi ia sesuai dengan kata-kata itu. Selepas melakukan lelaran pertamanya, menguruskan untuk melakukan permintaan (tanpa disekat), dan memuatkannya ke dalam memori, saya menggunakan konsep kumpulan pekerja.

Dan kemudian saya menghadapi BSOD. Lucunya, pada hari yang sama mogok CrowdStrike, saya pasti tidak menyangka saya menyebabkan gangguan besar di kilang.
Juga ya, saya perlu menggunakan tingkap untuk bekerja, tetapi jangan risau! Saya menggunakan WSL2.

Selepas melalui trek tindanan yang besar bagi limpahan tindanan pertama saya, saya mendapati kesilapan itu. Semasa menghantar data ke saluran pengguna, saya tidak mengambil kira bahawa sesetengah data mungkin ralat, terutamanya disebabkan oleh pelanggaran kunci utama atau hanya kerana, mungkin, saya tidak mengendalikan ralat dengan betul.

Pelajaran yang diperoleh, gunakan saluran ralat untuk mengelakkan masalah besar. Dan kendalikan ralat anda, sama ada melalui semakan rentetan yang mudah (hodoh, tetapi berfungsi), atau hanya log masuk peringkat atas, dan gembira. Memandangkan kesilapan yang saya hadapi tidak kritikal, saya boleh teruskan.

Lelaran kedua. Kebocoran memori.

Jumlah kebocoran memori yang saya hasilkan dalam langkah ini membuatkan saya fikir saya sedang melakukan C. Tetapi ia hanya isu kemahiran utama.
Bagaimanapun, anda mungkin terfikir sendiri:

"Bagaimana anda mencipta kebocoran memori dalam proses yang begitu mudah?"

Mudah sahaja, saya sedang belajar dan mencuba.

Masalah utama semasa langkah ini ialah bagaimana saya, secara naif, tidak memastikan bahawa data dimasukkan dengan betul, dan jumlah pelanggaran kunci utama yang saya peroleh telah melanggar ingatan saya. Ini adalah masalah yang saya tahu bagaimana untuk menyelesaikannya, mari kita cache data!
Tunggu bagaimana hendak membuat Pengecam Unik untuk setiap baris, memandangkan setiap baris adalah unik?

Sekarang, bahagian itulah yang ramai akan ketawakan saya, kerana, untuk berlaku adil, bahagian itulah yang paling mencelah saya. Saya hanya menyertai baris maklumat semasa dan menghuraikannya ke dalam fungsi cincang, dan cincang itu menjadi kunci saya dalam peta.

"Mengapa tidak Redis?" - Anda mungkin bertanya pada diri sendiri.

Mudah sahaja, birokrasi. Ia bukan syarikat kecil. Sebenarnya, ramai di antara anda, mungkin, menggunakan komputer riba yang mereka hasilkan. Tindakan mudah untuk meminta contoh Redis akan mengambil, sekurang-kurangnya, tiga hari bekerja, empat mesyuarat, pengorbanan untuk tuhan birokrasi dan dokumen lengkap yang menerangkan sebab dan bagaimana.
Sooo, ya, mari gunakan peta cincang mudah dan pramulakannya sebelum larian pertama. Ia akan menambah masa pemuatan keseluruhan tetapi ia akan lebih cepat daripada permintaan.

Dengan melakukan itu, proses keseluruhan bertambah baik seperti mempunyai motor baru, memleaks berhenti, kumpulan tidak gagal setiap kali, jumlah ralat dan pemotongan juga berkurangan, cukup bagus, bukan? Betul tak?

Setakat ini, anda tahu ada sesuatu yang bercelaru.

Lelaran ketiga. Kehidupan boleh menjadi baik.

Satu perkara yang saya tidak ambil kira ialah hakikat bahawa, dengan melakukan sisipan kelompok, adalah pengesahan data. Berikut ialah gambaran ringkas aliran.

Ambil data -> Semak sama ada cincangan data wujud dalam peta cincang -> Kelompok & Sisipan

Dan apakah masalahnya? Nah, apakah yang berlaku jika satu sisipan dalam kumpulan saya gagal, adakah ia akan mencuba semula tanpa kemasukan? Jika ya, berapa banyak percubaan semula yang boleh saya lakukan tanpa mengacaukan sistem dan kehilangan kelebihan pelaksanaan kumpulan pekerja?
Hanya satu cara untuk mengetahui! Jom semak.
Satu perkara yang boleh saya tambahkan ialah hakikat sumber ini mengembalikan lebih daripada 25 lajur, jadi saya perlu berhati-hati mengenai jumlah data yang saya masukkan setiap kelompok untuk tidak melebihi 2100 parameter, iaitu had MSSQL.

Pada ketika ini, saya sudah menjalankan sesuatu dalam bekas docker yang meniru ruang pengeluaran dengan sumber yang terhad. Untuk menambah konteks, proses ini berjalan dengan 1GB RAM dan kira-kira 0.5CPU. Saya boleh memperuntukkan lebih banyak sumber, tetapi itu hanya memaksa saya keluar.
Dengan menjalankan lelaran baharu ini di dalam bekas, menambah beberapa cap masa dan log keluar ke fail untuk dianalisis kemudian. Saya mendapati peningkatan kira-kira 5 minit disebabkan jumlah percubaan semula. Ini tidak akan berfungsi, mengalih keluar masukan 'kotor' bukan pilihan.

Lelaran keempat. Kehidupan ADALAH baik.

Untuk menyelesaikan isu ini, saya menambah jumlah pekerja. Saya menggunakan kira-kira 50 pekerja atau lebih, dan terima kasih kepada tekaan rawak pengguna perselisihan di rak teratas ThePrimagen, saya meningkatkannya kepada 1000 pekerja, dan menjadikannya supaya setiap pekerja mengesahkan setiap entri dalam transaksi. Sekiranya urus niaga gagal, saya hanya melancarkannya semula.
Dengan berbuat demikian, saya dapat menyelesaikan isu teras dan meningkatkan kelajuan keseluruhan proses ini secara umum. Kini tiba masanya untuk memasukkannya ke dalam prod dan memantaunya, kerana, anda tahu, bunian prod mungkin mengacaukan perisian anda. (Ia juga dikenali sebagai isu kemahiran, tetapi nama ini dilarang.)

Mengetahui bahawa mengurangkan selang pengambilan sistem ini, di mana ia diminta untuk membuatnya hampir masa nyata (yang bermaksud cukup pantas untuk mereka tidak menyedari kelewatan), saya mencipta bekas baharu, kali ini dengan sedikit lebih mantap untuk periksa sama ada ia boleh menahan beban, dan tetapkan selang masa kepada 3 minit. Memandangkan masa purata untuk mengambil, ini bermakna saya boleh mengalami beberapa pertindihan, tetapi saya benar-benar mahu melihat apa yang akan berlaku.

Saya membiarkannya berjalan semalaman, mencatatkan keputusan untuk menyemaknya kemudian, dan, yang mengejutkan saya, sebelum hari kerja tamat, saya menerima panggilan daripada pengurus saya. Maklumlah, dia bukan orang teknologi atau sebagainya.

"Hei, adakah 'kami' telah menggunakan sesuatu yang berinteraksi dengan [Nama Sistem yang Saya Tidak Boleh Dedahkan]?"

"Ya, saya menggunakan sistem pengambilan data dalam masa nyata yang diminta. Mengapa?"

"Bolehkah awak, hm, hentikan? Ia menyebabkan gangguan dan kami tidak boleh bekerja di sini."_

Ini, gadies dan lentleman, adalah satu lagi tahap yang menarik. Saya, secara literal, menghentikan lebih 20 barisan pengeluaran selama seminit atau lebih. Bagaimanapun, saya menghentikan sistem dan semuanya kembali normal.
Keesokan harinya, saya diminta untuk meningkatkan selang antara pengambilan kepada 30 minit dan bukannya 3, ok, saya rasa. Saya tidak akan berbohong, saya agak sedih kerana saya tidak dapat melihatnya berprestasi pada kelajuan maksimum, tetapi hei, sekurang-kurangnya saya berjaya.

Dengan sistem baharu ini, purata masa kemas kini laporan yang menggunakan data ini berkurangan kepada 8~10 saat, yang menyebabkan lebih banyak laporan daripada sumber yang sama diminta oleh pengurus dengan cara yang sama. Kerja yang baik dibalas dengan lebih banyak kerja!

Pertimbangan

Ia adalah pengalaman yang menyeronokkan, terutamanya disebabkan fakta itu membuatkan saya benar-benar menyedari betapa hebatnya Go. Menggunakan memori yang kurang daripada google chrome, kurang storan daripada apl Microsoft dan kuasa CPU yang kurang daripada kalkulator windows, saya dapat memperbaiki proses lama yang secara literal memaksanya melaluinya (ia benar-benar menyemak setiap baris dalam pangkalan data sebelum memasukkan. Saya tidak 'Tidak tahu bagaimana orang sebelumnya menganggap ia adalah idea yang baik.). Sungguh menyeronokkan.

Apa pun, jangan ragu untuk berkongsi pendapat anda dalam keseluruhan proses ini, bagaimana pendekatan anda dan apakah yang akan anda lakukan secara berbeza. Memandangkan saya tidak mempunyai rakan sekerja dev, saya ingin mengetahui lebih banyak pandangan tentang itu.

Atas ialah kandungan terperinci Cara saya memproses lebihan Entri setiap permintaan - With Go!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!