Pertama, mari kita tentukan konsep "antrian".
Pertimbangkan jenis antrian
“FIFO” (masuk pertama, keluar pertama). Jika Anda mengambil nilai dari
Wikipedia - "ini adalah tipe data abstrak dengan disiplin akses ke elemen." Singkatnya, ini berarti bahwa kita tidak bisa mendapatkan data darinya secara acak, tetapi hanya mengambil apa yang datang terlebih dahulu.
Selanjutnya, Anda perlu memutuskan mengapa mereka dibutuhkan sama sekali?
1. Untuk operasi yang ditangguhkan. Contoh klasik adalah pemrosesan gambar. Misalnya, seorang pengguna mengunggah gambar ke situs yang perlu kami proses, operasi ini membutuhkan banyak waktu, pengguna tidak ingin menunggu terlalu lama. Karena itu, kami memuat gambar, lalu mentransfernya ke antrian. Dan itu akan diproses ketika ada "pekerja" yang mendapatkannya.
2. Untuk menangani beban puncak. Misalnya, ada beberapa bagian dari sistem yang terkadang menyebabkan banyak lalu lintas dan tidak memerlukan respons instan. Sebagai opsi, menghasilkan laporan apa pun. Melemparkan tugas ini dalam antrian - kami memberikan kesempatan untuk menanganinya dengan beban seragam pada sistem.
3. Skalabilitas. Dan mungkin alasan terpenting, antrian memungkinkan
meningkatkan skala. Ini berarti bahwa Anda dapat memunculkan beberapa layanan untuk diproses secara paralel, yang akan sangat meningkatkan produktivitas.
Sekarang mari kita lihat masalah yang akan kita hadapi jika kita membuat antrian sendiri:
1. Akses paralel. Hanya satu pawang yang dapat mengambil pesan dari antrian. Artinya, jika pada saat yang sama dua layanan meminta pesan, masing-masing dari mereka harus mengembalikan satu set pesan yang unik. Kalau tidak, ternyata satu pesan diproses dua kali. Apa yang bisa penuh.
2. Mekanisme deduplikasi. Layanan harus memiliki sistem yang melindungi antrian dari duplikat. Mungkin ada situasi di mana satu dan dataset yang sama akan dikirim ke antrian secara kebetulan dua kali. Akibatnya, kami akan memproses hal yang sama dua kali. Yang lagi penuh.
3. Mekanisme penanganan kesalahan. Katakanlah layanan kami mengambil tiga pesan dari antrian. Dua di antaranya ia berhasil diproses dengan mengirimkan permintaan penghapusan dari antrian. Dan yang ketiga dia tidak bisa memproses dan mati. Pesan yang dalam status pemrosesan tidak tersedia untuk layanan lain. Dan seharusnya tidak selamanya tetap dalam status pemrosesan. Pesan semacam itu harus diteruskan ke penangan lain dengan beberapa logika. Contoh implementasi logika ini akan dipertimbangkan segera menggunakan AWS SQS (Layanan Antrian Sederhana) sebagai contoh.
Layanan Web Amazon - Layanan Antrian Sederhana
Sekarang mari kita lihat bagaimana SQS menyelesaikan masalah ini dan apa yang dapat dilakukannya.
1. Akses paralel. Pada antrian, Anda dapat mengatur parameter
batas waktu Visibilitas . Ini menentukan berapa lama pemrosesan pesan dapat berlangsung selama mungkin. Secara default, itu adalah
30 detik. Ketika suatu layanan mengambil pesan, itu ditransfer ke status
"Dalam Penerbangan" selama 30 detik. Jika selama waktu ini tidak ada perintah untuk menghapus pesan ini dari antrian, itu kembali ke awal dan layanan berikutnya dapat menerimanya lagi untuk diproses.
Pekerjaan shemka kecil.
Perhatikan: Hati-hati. SQS dalam beberapa kasus dapat mengirim pesan duplikat (Item "Setidaknya-Sekali Pengiriman"). Karena itu, layanan Anda harus idempoten untuk diproses.
2. Mekanisme penanganan kesalahan. Di SQS, Anda dapat mengonfigurasi belokan kedua untuk pesan "mati" (Antrian Surat Mati). Artinya, mereka yang tidak dapat memproses layanan kami akan dikirim ke antrian terpisah, yang dapat Anda buang sesuai kebijakan Anda. Anda juga dapat mengatur setelah mana jumlah upaya gagal pesan akan masuk ke antrian "mati". Upaya yang gagal adalah berakhirnya "Batas waktu visibilitas". Artinya, jika tidak ada permintaan penghapusan yang dikirim selama waktu ini, pesan seperti itu akan dianggap tidak diproses dan akan kembali ke antrian utama atau pergi ke "mati".
3. Deduplikasi pesan. SQS juga memiliki sistem perlindungan duplikat. Setiap pesan memiliki
"Id Deduplikasi" , SQS tidak akan mengantri pesan
mengulangi "Deduplikasi Id" selama 5 menit. Anda harus menentukan “Id Deduplikasi” di setiap pesan atau mengaktifkan pembuatan id berbasis konten. Ini berarti bahwa hash yang dihasilkan berdasarkan konten Anda akan masuk ke “Id Deduplikasi”. Parameter
"Deduplikasi Berbasis Konten". Lebih lanjut tentang DeduplikasiPerhatian: Hati-hati jika Anda mengirim dua pesan identik dalam 5 menit dan Anda telah mengaktifkan "Deduplikasi Berbasis Konten". SQS tidak akan menambahkan pesan kedua ke antrian.
Perhatikan: Hati-hati, misalnya, jika koneksi terputus pada perangkat dan tidak menerima respons dan kemudian mengirim permintaan kedua setelah 5 menit, duplikat akan dibuat.
4. Polling panjang. Survei panjang . SQS mendukung jenis koneksi ini dengan batas waktu maksimum 20 detik. Apa yang memungkinkan kita menghemat lalu lintas dan "menyentak" layanan.
5. Metrik. Amazon juga menyediakan metrik antrian terperinci. Seperti jumlah pesan yang diterima / dikirim / dihapus, ukuran dalam KB dari pesan-pesan ini dan sebagainya. Anda juga dapat menghubungkan SQS ke layanan log CloudWatch. Di sana Anda dapat melihat lebih banyak lagi. Di sana Anda juga dapat mengkonfigurasi apa yang disebut
"alarm" dan Anda dapat mengkonfigurasi tindakan untuk setiap peristiwa.
Pelajari lebih lanjut tentang menghubungkan ke SQS. Dan
Dokumentasi CloudWatch
Sekarang mari kita lihat pengaturan antrian:
Yang utama:
Batas Waktu Visibilitas Standar - jumlah detik / menit / jam yang pesannya setelah diterima tidak akan terlihat untuk diterima. Waktu pemrosesan maksimum adalah 12 jam.
Periode Retensi Pesan - jumlah detik / menit / jam / hari, yang berarti berapa lama pesan yang belum diproses akan disimpan dalam antrian. Maksimal - 14 hari.
Ukuran Pesan Maksimum - ukuran pesan maksimum dalam KB. Nilainya mulai dari 1KB hingga 256KB.
Keterlambatan pengiriman - Anda dapat mengatur waktu tunda untuk mengirim pesan ke antrian. Dari 0 detik hingga 15 menit (Faktanya, pesan akan berada dalam antrian, tetapi tidak akan terlihat untuk diterima).
Terima Waktu Tunggu Pesan - waktu, berapa lama koneksi akan bertahan jika kita menggunakan "Polling panjang" untuk menerima pesan baru.
Deduplikasi Berbasis Konten - bendera, jika disetel ke true, maka "Deduplikasi Id" akan ditambahkan ke setiap pesan dalam bentuk hash SHA-256 yang dihasilkan dari konten.
Pengaturan Antrian Mati
Gunakan Kebijakan Redrive - bendera, jika disetel, maka pesan akan dialihkan setelah beberapa upaya.
Dead Letter Queue - nama antrian "mati" yang akan dikirimi pesan mentah.
Penerimaan Maksimum - jumlah upaya pemrosesan yang gagal, setelah itu pesan akan dikirim ke antrian "mati"
Perhatikan: Perhatikan juga bahwa kami dapat mengirim semua parameter utama bersama dengan setiap pesan secara terpisah. Misalnya, setiap pesan individu mungkin memiliki Batas Waktu Visibilitas atau Keterlambatan Pengiriman sendiri.
Sekarang sedikit tentang pesan itu sendiri dan propertinya:
Pesan memiliki beberapa parameter:
1. Badan pesan - teks apa saja
2. Id Grup Pesan adalah sesuatu seperti tag, saluran, yang diperlukan untuk semua pesan. Setiap grup tersebut dijamin akan diproses dalam mode FIFO.
3. Pesan Deduplikasi Pesan - string untuk mengidentifikasi duplikat. Jika mode "Deduplikasi Berbasis Konten" diatur, parameternya opsional.
Ada juga atribut pesan
Atribut terdiri dari nama, jenis, dan nilai.
1. Nama - string
2. Jenis - ada beberapa jenis: string, angka, biner. Tipe ini datang hanya sebagai string, dan dimungkinkan untuk menambahkan postfix ke tipe tersebut. Dalam hal ini, tipe akan datang dengan postfix ini melalui titik, misalnya string.example_postfix
3. Nilai - string
Perhatikan: Harap dicatat bahwa jumlah maksimum atribut adalah 10 Detail
PS: Artikel ini menyediakan deskripsi singkat tentang antrian, serta sedikit tentang kemampuan dan mekanisme SQS. Artikel berikut akan dikhususkan untuk
AWS Lambda , dan kemudian berbagi praktisnya.