Merancang arsitektur antrian pesan yang dapat diskalakan

Baru-baru ini saya mulai mempelajari nuansa arsitektur komputer yang dapat diskalakan dan perusahaan, dan salah satu komponen utama adalah antrian pengiriman pesan. Untuk mempelajari semaksimal mungkin dari paradigma pemrograman apa pun, saya mencoba mengimplementasikan versi saya sendiri dari layanan antrian perpesanan.

Sejauh ini, desain awal saya berjalan pada pendengar soket berulir, tetapi untuk mencegah pesan yang sama diunduh dua kali oleh dua node pemrosesan yang terpisah, register indeks antrian pesan dikunci saat pembacaan dimulai, dan dibuka kuncinya setelah register dilakukan. diperbarui. Dengan demikian, ini meniadakan perlunya untuk berulir, dan berarti bahwa ada batas untuk ukuran sistem yang dapat diskalakan berdasarkan kecepatan pemrosesan server yang digunakan layanan antrian pengiriman pesan.

Cara menyiasatinya adalah menjalankan layanan antrian pesan pada beberapa server, tetapi ini akan meningkatkan kemungkinan pesan yang sama diunduh dua kali. Satu-satunya cara untuk mencegah masalah seperti itu terjadi adalah dengan menyertakan panggilan balik pencabutan yang (setelah server, atau bahkan utas pada server tunggal, telah menyinkronkan informasi mereka dan mendeteksi penerbitan ulang seperti itu) akan memerintahkan node pemrosesan untuk menghentikannya. pekerjaan saat ini, dan permintaan ulang antrian pesan untuk pesan berikutnya, tetapi sekali lagi, akan ada langit-langit di mana sebagian besar lalu lintas yang dikirim adalah sinkronisasi, dan pencabutan panggilan balik, menyebabkan kemacetan dan memperlambat pemrosesan informasi sehingga banyak node pemrosesan akan melakukan operasi nol dan membuang-buang waktu.

Cara terakhir yang dapat saya pikirkan untuk mengatasi masalah ini adalah memiliki setiap server antrian pesan (dan setiap utas di setiap server) akan memiliki offset spesifik ke mana dalam antrian yang dicari, tetapi mungkin memiliki masalah berdasarkan pada jenis aplikasi, terutama jika pemrosesan diperlukan untuk dilakukan dalam urutan tertentu.

Jadi, semua yang dikatakan, apakah ada desain arsitektur antrian pesan yang dapat menunjukkan kepada saya bagaimana layanan antrian pesan tingkat perusahaan yang ada menghindari masalah ini?

Pendeknya:

Ini masalah yang sulit. Jangan menemukan kembali roda.

Ada banyak teknologi yang memecahkan lapisan antrian pesan. Mereka termasuk

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, dengan BLPOP atau PUBSUB (Saya sudah bertanya bagaimana melakukan ini di sini ).
• Implementasi AMQP lainnya selain RabbitMQ

Saya pikir itu di luar ruang bagi saya untuk membahas kelemahan masing-masing, paling tidak karena saya tidak benar-benar mengklaim keahlian untuk melakukan batuk ini dengan baik, jangan gunakan batuk Kelinci .

Bahkan jika Anda tidak ingin menggunakan teknologi ini, baca dokumentasi mereka.

Ini akan mendidik Anda tentang pola desain yang dimungkinkan melalui satu sistem. Membaca dokumentasi ZeroMQ akan mendidik Anda tentang banyak arsitektur antrian pesan klasik yang telah mereka terapkan dengan ramah. Bahkan jika Anda tidak menggunakan ZeroMQ, mengetahui pola-pola ini akan membantu Anda mengevaluasi teknologi antrian lainnya dengan menanyakan apakah Anda dapat menerapkan pola itu di sana.

Pelajari tentang model antrian pertukaran RabbitMQ / AMQP. Routing mungkin muncul untuk Anda - ini didukung oleh Redis PUBSUB tapi saya tidak ingat didukung oleh ZeroMQ - dan fanout adalah sesuatu yang digunakan oleh toko saya, meskipun tidak diterapkan dengan baik melalui jajak pendapat Memcached (yuck!), Untuk beberapa waktu .

Bagaimana cara memilihnya?

Saya bekerja di startup yang SLA-nya khas untuk aplikasi-web - beberapa pemadaman tidak masalah, selama kita dapat dengan cepat mengembalikan layanan dengan sedikit kehilangan data. Kami tidak harus memikirkan masalah penskalaan seperti Twitter atau Tumblr, jadi kami belum benar-benar harus memikirkan volume throughput. Karena itu, jika Anda menerapkan SLA yang serupa dengan tambang, pertimbangan ini akan muncul di benak Anda:

• apakah pustaka klien benar-benar berfungsi ? Apakah mudah mempertahankan koneksi di dalamnya? (ZeroMQ, Redis: ya. RabbitMQ: tidak).
• Apakah pemantauan dan pengelolaannya mudah dari konsol server? (Redis: ya, RabbitMQ: ya, ZeroMQ: tidak saya ingat tapi kami tidak menggunakannya selama itu)
• apakah klien mendukung antrian internal sehingga sedikit kehilangan data terjadi dalam pemadaman singkat? (ZeroMQ, Redis: ya. RabbitMQ: tidak.)

Tentu saja jika Anda bekerja untuk, katakanlah, toko perdagangan frekuensi tinggi, ini akan menjadi kekhawatiran Anda yang lebih kecil. Anda akan lebih bersedia untuk memasukkan waktu pengembangan ke pustaka sisi klien dengan imbalan throughput yang lebih tinggi pada akhirnya. Tapi saya menulis ini lebih untuk memperingatkan Anda bahwa teknologi ini cenderung memasarkan berdasarkan kinerja mereka, bukan fungsionalitas out-of-the-box mereka. Jika Anda adalah startup web, Anda jauh lebih tertarik pada yang terakhir daripada yang pertama, dan karenanya, sesuatu seperti Redis, yang lebih dioptimalkan untuk kemudahan penggunaan pada kinerja yang baik daripada kesulitan penggunaan pada kinerja yang hebat, mungkin merupakan pilihan yang lebih baik daripada RabbitMQ. (Saya benar-benar tidak suka RabbitMQ).