Membangun Alat Validasi Penerima Burung Asinkron Massal
·
26 Mei 2022

Poin Penting
Penulis membangun alat validasi penerima massal untuk memvalidasi jutaan alamat email secara efisien menggunakan API Validasi Penerima Bird.
Node.js terbukti lebih cepat dan lebih scalable daripada Python karena non-blocking I/O dan tidak adanya batasan GIL.
Alat ini membaca file CSV secara asinkron, memanggil API validasi untuk setiap email, dan menulis hasilnya ke CSV baru secara real-time.
Pendekatan ini menghindari kemacetan memori dan meningkatkan throughput menjadi sekitar 100,000 validasi dalam waktu kurang dari satu menit.
Peningkatan di masa depan dapat mencakup penanganan ulang yang lebih baik, antarmuka pengguna yang ramah, atau migrasi ke lingkungan tanpa server untuk skalabilitas.
Sorotan Tanya jawab
Apa tujuan dari Alat Validasi Penerima Asinkron Massal?
Ini memvalidasi volume besar alamat email dengan mengintegrasikan langsung dengan API Validasi Penerima Bird, menghasilkan hasil yang terverifikasi dengan cepat tanpa perlu unggahan manual.
Mengapa Python awalnya digunakan dan kemudian digantikan oleh Node.js?
Kunci Interpreter Global Python (GIL) membatasi konkurensi, sementara Node.js memungkinkan eksekusi asinkron yang sebenarnya, menghasilkan panggilan API paralel yang jauh lebih cepat.
Bagaimana alat ini menangani file besar tanpa kehabisan memori?
Alih-alih memuat semua data sekaligus, skrip memproses setiap baris CSV secara individual—mengirimkan permintaan validasi dan segera menulis hasilnya ke file CSV baru.
Masalah apa yang dipecahkan oleh alat ini untuk pengembang?
Ini memungkinkan validasi daftar email dalam skala besar, mengatasi batas 20MB dari validator berbasis UI SparkPost dan menghilangkan kebutuhan untuk mengunggah banyak berkas secara manual.
Seberapa cepat versi final dari program tersebut?
Sekitar 100.000 validasi selesai dalam 55 detik, dibandingkan dengan lebih dari satu menit menggunakan versi UI.
Masalah apa yang ditemui di sistem Windows?
Pengelolaan koneksi klien HTTP Node.js menyebabkan kesalahan “ENOBUFS” setelah banyak permintaan bersamaan, yang diperbaiki dengan mengonfigurasi penggunaan ulang koneksi axios.
Apa peningkatan masa depan yang disarankan?
Menambahkan penanganan kesalahan dan pengulangan, membuat antarmuka front-end, atau menerapkan alat tersebut sebagai Fungsi Azure tanpa server untuk skalabilitas dan ketahanan yang lebih baik.
Bagi seseorang yang mencari program sederhana dan cepat yang menerima file csv, memanggil API validasi penerima, dan mengeluarkan file CSV, program ini cocok untuk Anda.
Ketika membangun aplikasi email, pengembang sering perlu mengintegrasikan beberapa layanan dan API. Memahami dasar-dasar API email dalam infrastruktur cloud memberikan fondasi untuk membangun alat yang tangguh seperti sistem validasi massal yang akan kita buat dalam panduan ini.
Salah satu pertanyaan yang kadang-kadang kami terima adalah, bagaimana saya bisa melakukan validasi massal daftar email dengan validasi penerima? Ada dua opsi di sini, satu adalah mengunggah file melalui UI SparkPost untuk validasi, dan yang lainnya adalah melakukan panggilan individu per email ke API (karena API hanya untuk validasi email tunggal).
Opsi pertama bekerja dengan baik tetapi memiliki batasan 20Mb (sekitar 500.000 alamat). Bagaimana jika seseorang memiliki daftar email yang berisi jutaan alamat? Itu bisa berarti membagi-baginya menjadi 1.000-an unggahan file CSV.
Karena mengunggah ribuan file CSV tampaknya agak berlebihan, saya mengambil kasus penggunaan itu dan mulai bertanya-tanya seberapa cepat saya bisa mendapatkan API untuk berjalan. Dalam posting blog ini, saya akan menjelaskan apa yang saya coba dan bagaimana saya akhirnya datang ke program yang bisa mencapai 100.000 validasi dalam 55 detik (Sementara di UI saya mendapatkan sekitar 100.000 validasi dalam 1 menit 10 detik).
Pendekatan | Validasi Diuji | Waktu untuk Selesai | Perkiraan Throughput |
|---|---|---|---|
Tool Node.js async massal | 100.000 | 55 detik | ~1.818 validasi/detik |
Unggah UI SparkPost | 100.000 | 1 menit 10 detik | ~1.428 validasi/detik |
Dan sementara ini masih akan memakan waktu sekitar 100 jam untuk menyelesaikan dengan sekitar 654 juta validasi, skrip ini dapat berjalan di latar belakang menghemat waktu yang signifikan.
Versi akhir dari program ini dapat ditemukan di sini.
Kesalahan pertama saya: menggunakan Python
Kesalahan kedua saya: mencoba membaca file ke dalam memori
Ide awal saya adalah sebagai berikut:

Pertama, ambil daftar email dalam format CSV. Kedua, masukkan email ke dalam array dan periksa apakah formatnya sudah benar. Ketiga, panggil API validasi penerima secara asinkron. Keempat, tunggu hasilnya dan masukkan ke dalam variabel. Dan terakhir, keluarkan variabel ini ke file CSV.
Ini sangat berhasil untuk file yang lebih kecil. Masalah muncul ketika saya mencoba menjalankan 100.000 email. Program terhenti pada sekitar 12.000 validasi. Dengan bantuan salah satu pengembang front-end kami, saya melihat bahwa masalahnya adalah memuat semua hasil ke dalam variabel (dan oleh karena itu cepat kehabisan memori). Jika Anda ingin melihat iterasi pertama dari program ini, saya telah menautkannya di sini: Versi 1 (TIDAK DISARANKAN).

Pertama, ambil daftar email dalam format CSV. Kedua, hitung jumlah email dalam file untuk tujuan pelaporan. Ketiga, saat setiap baris dibaca secara asinkron, panggil API validasi penerima dan keluarkan hasilnya ke file CSV.
Dengan demikian, untuk setiap baris yang dibaca, saya memanggil API dan menuliskan hasilnya secara asinkron agar tidak menyimpan data ini dalam memori jangka panjang. Saya juga menghapus pemeriksaan sintaks email setelah berbicara dengan tim validasi penerima, karena mereka memberi tahu saya bahwa validasi penerima sudah memiliki pemeriksaan bawaan untuk memeriksa apakah email valid atau tidak.
Membongkar kode akhir
Langkah Selanjutnya
Untuk seseorang yang mencari program cepat sederhana yang menerima csv, memanggil API validasi penerima, dan mengeluarkan CSV, program ini untuk Anda.
Beberapa tambahan untuk program ini adalah sebagai berikut:
Membangun antarmuka depan atau UI yang lebih mudah digunakan
Pemrosesan error dan pengulangan yang lebih baik karena jika karena alasan tertentu API menghasilkan kesalahan, program saat ini tidak mencoba kembali panggilan tersebut
Pertimbangkan untuk mengimplementasikan sebagai Fungsi Azure tanpa server untuk penskalaan otomatis dan pengelolaan infrastruktur yang lebih sedikit
Saya juga penasaran untuk melihat apakah hasil yang lebih cepat dapat dicapai dengan bahasa lain seperti Golang atau Erlang/Elixir. Selain pilihan bahasa, batasan infrastruktur juga dapat mempengaruhi kinerja - kami telah belajar ini secara langsung ketika kami menghadapi batas DNS yang tidak terdokumentasi di AWS yang mempengaruhi sistem pemrosesan email volume tinggi kami.
Untuk pengembang yang tertarik menggabungkan pemrosesan API dengan alat alur kerja visual, lihat cara mengintegrasikan Flow Builder dengan Google Cloud Functions untuk alur kerja otomatis tanpa kode.
Silakan beri saya masukan atau saran untuk memperluas proyek ini.



