Ringkasan antrean Spanner

Antrean Spanner menyediakan 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 konsumsi pesan, yang mengekspos antarmuka SQL bagi penerima untuk meminta dan menerima pesan.

Memilih antara antrean Spanner dan aliran data perubahan

Perbandingan berikut memberikan panduan dalam memilih mekanisme yang tepat untuk pemberitahuan data dan pemrosesan asinkron.

Antrean Spanner

Paling cocok untuk

  • Notifikasi peristiwa transaksional
  • Eksekusi tugas terjadwal di masa mendatang
  • Logika konfirmasi per pesan

Karakteristik utama

  • Payload pesan kecil yang ditentukan pengguna
  • Model pull untuk penggunaan pesan
  • Menskalakan dengan komputasi instance Spanner

Aliran perubahan Spanner

Paling cocok untuk

  • Replikasi data dengan throughput tinggi
  • Menyinkronkan cache atau indeks downstream
  • Logging audit untuk setiap perubahan database

Karakteristik utama

  • Merekam semua fragmen rekaman (hingga 10 MB)
  • Streaming berbasis pull menggunakan token partisi
  • Menyertakan heartbeat dan checkpointing

Keunggulan utama

Antrean Spanner menawarkan beberapa keunggulan:

  • Terintegrasi: pesan diintegrasikan ke dalam database. Dengan demikian, Anda tidak perlu menyediakan, mengelola, dan memindahkan data ke infrastruktur pesan terpisah, sehingga menyederhanakan arsitektur aplikasi dan menurunkan biaya 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.
  • Tahan lama: pesan yang tidak dapat dikirim akan disimpan dalam database. Spanner terus mencoba pengiriman dengan backoff hingga pesan diakui atau dihapus secara eksplisit.
  • Dapat dikueri: pesan dibuat di primitif yang sama dengan tabel Spanner dan disimpan sebagai baris. Anda dapat membuat kueri, menggabungkan, atau memfilternya seperti tabel standar.
  • Skalabel: dibuat dengan skalabilitas yang sama seperti tabel Spanner, pemrosesan pesan diskalakan bersama dengan bagian database Anda lainnya.
  • Andal: Antrean Spanner mewarisi semua primitif ketersediaan tinggi Spanner, sehingga pengiriman dan pemrosesan pesan menjadi fault-tolerant dan tahan terhadap kegagalan zona atau regional.
  • Dapat dijadwalkan: pesan dapat dijadwalkan untuk dikirim di lain waktu, sehingga Anda dapat menunda eksekusi tugas ke stempel waktu tertentu di masa mendatang.
  • Atomik: pengiriman pesan (API INSERT atau mutasi) dan konfirmasi (API DELETE atau mutasi) dijalankan secara atomik dalam transaksi, sehingga memastikan konsistensi dengan status database.
  • Dapat diperpanjang: sewa pesan dapat diperpanjang untuk mendukung waktu pemrosesan yang sangat lama dengan menggabungkan mekanisme pengiriman mendatang dan penyewaan manual.

Kasus penggunaan

Antrean Spanner berguna untuk mengorkestrasi tugas yang ditangguhkan dalam transaksi. Contoh umum meliputi:

  • Menunda pekerjaan komputasi yang berat: situs berbagi foto mungkin perlu melakukan pemrosesan gambar yang intensif saat foto baru diupload. Transaksi yang menulis metadata foto baru dapat menulis pesan antrean secara bersamaan. Penerima antrean kemudian mengambil pesan, melakukan pemrosesan, dan memperbarui metadata secara transaksional.
  • Menunda update transaksional yang besar: di aplikasi kalender, mengundang grup besar ke rapat dalam satu transaksi dapat menyebabkan konflik penguncian dan latensi ekstrem. 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 as a service (SaaS) yang menawarkan uji coba gratis selama 30 hari dapat menyediakan resource pengguna dan sekaligus mengantrekan pesan yang dijadwalkan untuk dikirim dalam 30 hari. Kemudian, worker akan menerima pesan dan menjalankan logika masa berlaku uji coba.
  • Menunda pekerjaan ke sistem eksternal: setelah pengguna mendaftar, aplikasi mungkin perlu mengirim email sambutan hanya jika pendaftaran database berhasil. Transaksi pendaftaran dapat menambahkan entri ke antrean, sehingga memungkinkan worker 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 melakukan checkpoint pada status pipeline dan melanjutkan dari titik kegagalan.

Alur kerja

Alur kerja standar untuk antrean Spanner mengikuti langkah-langkah berikut:

  • Membuat antrean: tentukan antrean menggunakan DDL, mirip dengan tabel. Tabel ini harus menyertakan kolom Payload (payload di PostgreSQL) dan kunci utama.
  • Mengirim pesan: mengantrekan pesan menggunakan DML standar (INSERT) atau API mutasi, secara transaksional dengan operasi database lainnya.
  • Menerima pesan: gunakan ExecuteStreamingSQL API untuk memanggil fungsi bernilai tabel (TVF) bernama RECEIVE_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 mutation API (seperti ack). Hal ini biasanya dilakukan setelah pemrosesan selesai, dalam transaksi.
  • Mengelola sewa: mengelola sewa pesan untuk memastikan bahwa antrean Spanner tidak mengirim ulang pesan saat waktu sewa habis. Metode yang paling umum adalah menggunakan TVF RENEWLEASE_QUEUE_NAME().

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 maksimal satu kali: karena konfirmasi pesan terjadi melalui transaksi, semantik ACID Spanner memastikan bahwa pesan hanya dikonfirmasi satu kali. Mengikuti metode di halaman Pemrosesan tepat satu kali dan konfirmasi paling banyak satu kali untuk menerapkan konfirmasi paling banyak satu kali dengan benar.

Batasan

Antrean Spanner memiliki batasan berikut:

  • Penerima maksimum: ada batas 1.000 kueri penerimaan aktif dengan argumen yang sama per antrean
  • Batas kuota TVF penerimaan serentak: ada batas kuota sebesar 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: AddSplits API tidak didukung untuk antrean. Distribusi workload sepenuhnya bergantung pada pemisahan berbasis beban. Sebaiknya lakukan interleaving antrean dalam tabel 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 ini diperkecil secara proporsional untuk instance terperinci (misalnya, instance dengan 200 unit pemrosesan dibatasi hingga 20 antrean).
  • Penamaan kolom PostgreSQL: Spanner mengekspos kolom deliver_time dan DeliverTime untuk waktu pengiriman pesan. Sebaiknya gunakan kolom deliver_time agar selaras dengan konvensi penamaan PostgreSQL standar, dan karena kolom DeliverTime akan disembunyikan dari skema informasi dalam rilis mendatang.
  • Skema bernama: antrean tidak dapat dibuat dalam skema bernama.

Langkah berikutnya