Antrean Spanner menyediakan pengiriman pesan transaksional untuk membantu Anda mengelola pekerjaan asinkron. Fitur ini menggabungkan kemampuan tersebut dengan skalabilitas dan keandalan Spanner, sehingga Anda dapat membangun aplikasi berbasis peristiwa. Antrean Spanner menggunakan model pull untuk penggunaan pesan, yang mengekspos antarmuka SQL bagi penerima untuk meminta dan menerima pesan.
Memilih antara antrean dan aliran data perubahan Spanner
Perbandingan berikut memberikan panduan tentang cara memilih mekanisme yang tepat untuk propagasi data dan pemrosesan asinkron.
Antrean SpannerPaling cocok untuk
Karakteristik utama
|
Aliran data perubahan SpannerPaling cocok untuk
Karakteristik utama
|
Keunggulan utama
Antrean Spanner menawarkan beberapa keuntungan:
- Terintegrasi: pesan terintegrasi ke dalam database. Dengan demikian, Anda tidak perlu menyediakan, mengelola, dan mengekstraksi data ke infrastruktur pesan terpisah, sehingga menyederhanakan arsitektur aplikasi dan menurunkan biaya secara keseluruhan.
- Transaksional: Anda dapat mengirim dan mengonfirmasi pesan secara atomik dalam transaksi Spanner bersama dengan penulisan database lainnya. Pesan yang diantrekan akan di-roll back dan tidak tersedia untuk pengiriman jika transaksi gagal.
- Durable: pesan yang tidak dapat dikirim disimpan dalam database. Spanner akan terus mencoba pengiriman dengan mundur hingga pesan diakui atau dihapus secara eksplisit.
- Dapat dikueri: pesan dibuat berdasarkan primitif yang sama dengan tabel Spanner dan disimpan sebagai baris. Anda dapat membuat kueri, menggabungkan, atau memfilternya seperti tabel standar.
- Dapat diskalakan: dibangun dengan skalabilitas yang sama seperti tabel Spanner, pemrosesan pesan diskalakan bersama dengan database Anda lainnya.
- Andal: Antrean Spanner mewarisi semua primitif ketersediaan tinggi Spanner, sehingga pengiriman dan pemrosesan pesan menjadi toleran terhadap kesalahan dan tahan terhadap kegagalan zona atau regional.
- Pesan yang dapat dijadwalkan: dapat dijadwalkan untuk pengiriman di masa mendatang, sehingga Anda dapat menunda eksekusi tugas ke stempel waktu tertentu di masa mendatang.
- Atomik: pengiriman pesan (API
INSERTatau mutasi) dan konfirmasi (APIDELETEatau mutasi) dieksekusi secara atomik dalam transaksi, sehingga memastikan konsistensi dengan status database. - Dapat diperpanjang: masa berlaku pesan dapat diperpanjang untuk mendukung waktu pemrosesan yang sangat lama dengan menggabungkan mekanisme pengiriman di masa mendatang dan penyewaan manual.
Kasus penggunaan
Antrean Spanner berguna untuk mengatur tugas yang ditangguhkan dalam transaksi. Contoh umum meliputi:
- Menunda pekerjaan yang berat secara komputasi: situs berbagi foto mungkin perlu melakukan pemrosesan gambar yang intensif saat foto baru diupload. Transaksi yang menulis metadata foto baru dapat secara bersamaan menulis pesan antrean. Penerima antrean kemudian mengambil pesan, melakukan pemrosesan, dan memperbarui metadata secara transaksional.
- Menunda update transaksional besar: di aplikasi kalender, mengundang grup besar ke rapat dalam satu transaksi dapat menyebabkan konflik penguncian dan latensi ekor. Sebagai gantinya, transaksi yang membuat entri kalender dapat menambahkan entri antrean untuk setiap tamu undangan, sehingga penerima dapat mengirim undangan satu per satu.
- Menjadwalkan tugas di masa mendatang: perusahaan software sebagai layanan (SaaS) yang menawarkan uji coba gratis 30 hari dapat menyediakan resource pengguna dan secara bersamaan mengantrekan pesan yang dijadwalkan untuk dikirim dalam 30 hari. Kemudian, pekerja menerima pesan dan menjalankan logika masa berlaku uji coba.
- Menunda pekerjaan ke sistem eksternal: setelah pengguna mendaftar, aplikasi mungkin perlu mengirim email selamat datang hanya jika pendaftaran database berhasil. Transaksi pendaftaran dapat menambahkan entri ke antrean, sehingga pekerja dapat memanggil API email eksternal nanti.
- Mengorkestrasi pipeline multi-langkah: dalam sistem pengelolaan pesanan, pemenuhan pesanan melibatkan beberapa langkah yang dapat gagal secara independen. Dengan merepresentasikan setiap langkah sebagai pesan antrean, sistem dapat membuat titik pemeriksaan status pipeline dan melanjutkan dari titik kegagalan.
Alur kerja
Alur kerja umum untuk antrean Spanner mengikuti langkah-langkah berikut:
- Membuat antrean: tentukan antrean menggunakan DDL, mirip dengan tabel. Tabel harus
mencakup kolom
Payload(payloaddi PostgreSQL) dan kunci primer. - Mengirim pesan: mengantrekan pesan menggunakan DML standar (
INSERT) atau API mutasi, secara transaksional dengan operasi database lainnya. - Menerima pesan: gunakan API
ExecuteStreamingSQLuntuk memanggil fungsi bernilai tabel (TVF) bernamaRECEIVE_QUEUE_NAME(). Fungsi ini mengalirkan pesan ke klien Anda sebagai kueri yang berjalan lama. - Memproses pesan: menggunakan pesan yang diterima dari TVF dengan logika aplikasi Anda.
- Mengonfirmasi pesan: menghapus pesan dari antrean menggunakan DML
(
DELETE) atau API mutasi (sepertiack). Tindakan ini biasanya dilakukan setelah pemrosesan selesai, dalam transaksi. - Mengelola sewa: mengelola sewa pesan untuk memastikan bahwa antrean Spanner tidak mengirim ulang pesan saat waktu tunggu sewa habis.
Metode yang paling umum adalah menggunakan
RENEWLEASE_QUEUE_NAME()TVF.
Selain itu, perhatikan perilaku inti antrean Spanner berikut:
- Pengiriman minimal satu kali: umum untuk sebagian besar sistem antrean berbasis cloud, Spanner menjanjikan pengiriman minimal satu kali. Pengiriman ulang dapat dimitigasi dengan memperpanjang lease.
- Konfirmasi paling banyak sekali: karena konfirmasi pesan terjadi melalui transaksi, semantik ACID Spanner memastikan bahwa pesan hanya dikonfirmasi satu kali. Ikuti metode di halaman Pemrosesan tepat satu kali dan pengakuan paling banyak satu kali untuk menerapkan pengakuan paling banyak satu kali dengan benar.
Batasan
Antrean Spanner memiliki batasan berikut:
- Penerima maksimum: ada batasan 1.000 kueri penerimaan aktif dengan argumen yang sama per antrean
- Batas kuota TVF penerimaan serentak: ada batas kuota 2.000 TVF penerimaan serentak per project per region. Untuk meningkatkan batas kuota, isi formulir Minta Peningkatan Kuota untuk project Cloud Spanner Anda.
- Pemisahan manual: API
AddSplitstidak didukung untuk antrean. Distribusi beban kerja sepenuhnya bergantung pada pemisahan berbasis beban. Menyisipkan antrean dalam tabel direkomendasikan agar pengguna dapat menambahkan titik pemisahan ke tabel. - Kepatuhan partisi geografis: antrean yang dipartisi secara geografis tidak mematuhi residensi data setelah menjalankan operasi
DROP PARTITION. - Batas jumlah antrean: instance dibatasi hingga 100 antrean untuk instance dengan 1 node atau lebih. Batas akan diperkecil secara proporsional untuk instance terperinci (misalnya, instance dengan 200 unit pemrosesan dibatasi hingga 20 antrean).
- Menghapus dan membuat ulang antrean: menghapus dan membuat ulang antrean dengan
nama yang sama tidak didukung sepenuhnya.
RECEIVETVF untuk antrean mungkin memerlukan waktu untuk "mereset" sebelum pesan dapat diterima dengan nama yang sama lagi. - Penamaan kolom PostgreSQL: Spanner mengekspos kolom
deliver_timedanDeliverTimeuntuk waktu pengiriman pesan. Sebaiknya gunakan kolomdeliver_timeagar sesuai dengan konvensi penamaan PostgreSQL standar, dan karena kolomDeliverTimeakan disembunyikan dari skema informasi dalam rilis mendatang. - Skema bernama: antrean tidak dapat dibuat dalam skema bernama.
Langkah berikutnya
- Pelajari cara menggunakan antrean Spanner, termasuk praktik terbaik dan pemantauan.
- Jelajahi lainnya skenario dan contoh antrean Spanner.
- Pelajari pemrosesan tepat satu kali dan konfirmasi paling banyak satu kali.
- Konfigurasi kontrol akses dengan kontrol akses terperinci untuk antrean.