Antrian Pesan. Database vs MQ Khusus

17

Saya mencari saran tentang antrian pesan. Kami memiliki persyaratan untuk "pekerjaan" untuk dikirim ke antrian pesan.

Saran asli adalah hanya menggunakan contoh SQL Server dan memproses pesan dari itu. Semua yang saya baca di internet menunjukkan bahwa menggunakan database untuk Antrian Pesan bukan solusi yang dapat diskalakan. Untuk alasan ini, ide untuk menggunakan RabbitMQ atau MQ pihak ketiga lainnya disarankan.

Hal lain yang perlu dipertimbangkan adalah bahwa persyaratan untuk "pengerjaan pekerjaan" tidak akan lebih rendah dari 30 detik, sehingga proses yang melakukan pekerjaan akan melakukan polling pada basis data setiap 30 detik. Bagi saya, ini tampaknya tidak terlalu buruk dan mungkin akan berfungsi dengan baik tanpa menambahkan beban besar ke Database.

Kami sudah memiliki Database di klien kami, kami dapat menggunakan ini sehingga tidak akan menambahkan banyak dukungan tambahan yang diperlukan untuk klien kami, sedangkan jika kami menambahkan MQ pihak ke-3 akan ada dukungan tambahan untuk konfigurasi jaringan dll, yang akan menjadi cukup banyak mengingat ada banyak pengguna.

Opsi lain yang saya pertimbangkan adalah memungkinkan pengguna untuk memilih di antara keduanya. Jika mereka adalah pengguna kecil maka solusi Sql Server akan baik-baik saja, tetapi jika mereka adalah pengguna yang lebih besar maka kami mengizinkan mereka untuk mengkonfigurasi solusi MQ pihak ke-3.

Saya tidak menjual pada solusi apa pun, saya bertanya-tanya apakah ada yang punya sesuatu yang harus saya pertimbangkan atau saran.

database message-queue

— pengguna1653400
sumber

1

Apakah 'pekerjaan' ini 'kebakaran dan lupakan' atau apakah prosesnya harus menelepon kembali ke rumah agar server mengetahui status pekerjaan itu?

— c_maker

Bagaimana scalable itu perlu? Apakah Anda menjalankan beberapa ratus ribu pesan melalui itu sehari atau beberapa miliar?

— Blrfl

Terima kasih atas komentarnya: ada persyaratan agar pekerjaan tersebut ditandai sebagai tidak lengkap (dianggap selesai kecuali ditandai sebagai tidak lengkap / gagal). Saya pikir tidak lebih dari 20.000 pesan sehari. Kemungkinan besar hanya beberapa ribu.

— user1653400

Gunakan alat yang paling tepat untuk pekerjaan itu. Jika Anda membutuhkan antrian pesan, maka gunakan antrian pesan, bukan database. Saya telah melihat orang-orang menggunakan tabel database sebagai antrian pesan sebelumnya dan saya menganggapnya sebagai anti-pola. Anda dapat menggunakan obeng sebagai palu, tetapi palu berfungsi lebih baik jika Anda perlu mengemudi dengan paku. Sebagian besar waktu ketika orang melakukan ini, itu karena mereka mengerti basis data tetapi bukan antrian pesan.

— Jesper

Ada beberapa petunjuk bagus di sini: rusanu.com/2010/03/26/using-tables-as-queues

— Michael Green

18

Semua yang saya baca di internet menunjukkan bahwa menggunakan database untuk Antrian Pesan bukan solusi yang dapat diskalakan.

Kenyataan yang sering diabaikan oleh kerumunan " jangan gunakan X karena tidak berskala " (tautan berisi bahasa yang beberapa orang mungkin merasa keberatan) adalah bahwa skala tidak selalu penting. Saya akan mengatakan bahwa jika Anda melihat setiap aplikasi di muka planet ini secara agregat, skala jarang penting.

Komentar Anda mengutip tingkat 20.000 pesan setiap hari, yang berarti Anda akan melihat perlu untuk mendukung tingkat rata-rata 0,23 pesan per detik (satu setiap 4,3 detik). Jika proyek Anda ternyata dua kali lipat lebih sukses daripada yang Anda harapkan, persyaratan Anda langsung memproses 23 pesan per detik, yang merupakan tugas yang saya akan sangat nyaman untuk diberikan kepada ponsel saya yang berusia empat tahun atau Raspberry. Pi. Ini masih bukan aplikasi skala tinggi bahkan jika Anda menangani beberapa pesanan besar lainnya.

Saya telah menyaksikan (untungnya, dari sela-sela) proyek berakhir dengan buruk karena mereka terlalu banyak menghabiskan waktu terlalu dini untuk terobsesi pada skala yang tidak akan terjadi atau tidak ada waktu untuk itu apa pun dan dihancurkan oleh skala yang akhirnya terjadi. Seperti yang lainnya, ada media yang menyenangkan. Jika Anda berpikir skala besar untuk aplikasi Anda adalah kemungkinan yang realistis, tidak akan sulit untuk membuat kasus bisnis untuk melakukan sejumlah kecil pekerjaan tambahan untuk membangun abstraksi yang cukup di sekitar bagian yang tidak dapat diskalakan yang murah untuk digunakan sekarang . Melakukan ini berarti bahwa nanti , jika kebutuhan untuk skala harus muncul, Anda memiliki cara (dan mungkin pendapatan) untuk melakukan penggantian grosir bagian-bagian tersebut tanpa harus memikirkan kembali seluruh sistem.

Walaupun volume pesan aplikasi Anda tidak akan membuat basis data atau sistem antrian pesan berkeringat bahkan pada perangkat keras sederhana, Anda mungkin memiliki persyaratan lain tentang bagaimana transaksi pesan Anda ditangani yang membuat satu atau yang lain pilihan yang lebih baik. Persyaratan itu adalah apa yang harus Anda evaluasi.

— Blrfl
sumber

Saya memiliki database yang memiliki jutaan transaksi dilakukan setiap hari. yang saya perlu proses melalui sms. Saat ini saya menggunakan tabel sql sebagai antrian tetapi saya macet ketika mengumpulkan sejumlah besar data. Saya tidak dapat menggunakan MQ karena saya harus merutekan sms berdasarkan konfigurasi waktu nyata. Jika saya menggunakan MQ maka tidak menggunakan konfigurasi saat ini untuk klien. karena kami mengubah penyedia di backend ketika beberapa penyedia gagal memproses. Jadi kalian, apa yang menyarankan saya dalam skenario saya?

— mayur Rathod

@mayurRathod Topik itu sepertinya seperti pakan untuk pertanyaan terpisah. Katakan dengan hati-hati, karena permintaan untuk alat atau sumber daya tertentu akan ditutup sebagai di luar topik.

— Blrfl

9

Antrian Pesan benar-benar menjadi milik mereka ketika Anda memiliki banyak dari mereka dan merutekan pesan di antara mereka, menyebar ke lebih dari satu konsumen dll.

Jika Anda hanya memiliki satu 'antrian pekerjaan' dari hal-hal yang ingin Anda proses 'off line' maka tabel SQL akan baik-baik saja.

Jangan lupa untuk memastikan bahwa Anda memiliki beberapa cara untuk menandai pekerjaan yang sedang berlangsung, membersihkan yang lama dan mengingatkan ketika sistem berhenti. Tetapi untuk satu antrian yang secara manual mengelola hal-hal ini akan kurang bekerja daripada mempertahankan solusi antrian yang terpisah.

— Ewan
sumber

5

Seperti yang telah disebutkan skala lainnya mungkin tidak penting di sini. Masalah dengan menggunakan dua mekanisme penyimpanan yang berbeda adalah integritas transaksional.

Jika menggunakan antrian pesan khusus, Anda harus memilih salah satu dari yang berikut jika terjadi kegagalan.

Izinkan data itu bisa di mb tetapi tidak di db
Izinkan data itu bisa dalam db tetapi tidak dalam mb
Setup dua fase melakukan atau mendistribusikan transaksi antara db an mq yang bisa rumit

Semua masalah ini hilang jika Anda hanya menyimpan data di satu tempat menggunakan transaksi normal. Untuk alasan ini menggunakan db sebagai antrian tugas adalah solusi yang sangat bagus.

— Esben Skov Pedersen
sumber

4

Secara praktis, alasan utama saya menggunakan antrian pesan adalah:

Saya tidak harus menemukan kembali kemudi. Merancang bahkan antrian pesan yang paling sederhana menggunakan database memerlukan setidaknya beberapa jam berpikir, beberapa jam pengkodean, dan sebagainya. Dibandingkan dengan mengimplementasikan antrian pesan, waktu yang diperlukan untuk mengonfigurasi dan / atau mengotomatiskan konfigurasi adalah sepele
Antrian pesan memiliki antarmuka yang bagus dan jelas untuk produsen dan konsumen. Ini mungkin yang paling penting dalam menulis aplikasi. Tanpa antarmuka, antrian pesan pada dasarnya hanya kumpulan data
Antrian pesan memberikan lebih banyak fitur yang mungkin diperlukan di masa mendatang

Mengenai memungkinkan pengguna untuk memilih, itu benar-benar detail implementasi yang seharusnya tidak dipedulikan pengguna. Pengguna harus mendapatkan antarmuka yang sama dan seharusnya tidak ada perbedaan bagi pengguna jika basis data atau antrian pesan digunakan. Setelah satu desain ditetapkan, pilihan yang mungkin bagi pengguna adalah berapa banyak node yang perlu digunakan untuk mengakomodasi kebutuhan mereka.

— imel96
sumber

1

Saya telah membuat solusi antrian pesan Mssql yang dapat menangani operasi 20k per detik, menurut tes kinerja, dan kami membutuhkan 10 / detik sebagian besar waktu. Saya pikir fakta bahwa Anda sebenarnya dapat memiliki prioritas bawaan adalah fitur yang tidak dimiliki antrian pesan khusus. Dan ini adalah persyaratan utama dalam kasus saya.

— Stephan Ryer
sumber