Menerapkan layanan n-Produsen / 1-Konsumen terdistribusi untuk sistem misi kritis
Saya mencoba menerapkan versi multi-produsen / 1-konsumen terdistribusi untuk sistem misi kritis. Saya mencari alternatif yang baik untuk pendekatan saat ini berdasarkan RDBMS.
Masalah
Sistem terdiri dari produsen serveral (50+) yang terus menghasilkan ribuan instance per detik. Setiap instance adalah struktur datar yang ditentukan dengan baik, diberi stempel waktu, dan datar. Setiap contoh disimpan ke dalam satu antrian oleh produsen.
Di sisi lain, saya memiliki konsumen yang menggunakan instans dengan cara FIFO.
Produsen dan Konsumen dijalankan pada mesin berbeda yang dihubungkan oleh jaringan pribadi TCP / IP.
Demi kelengkapan, ada dua syarat kuat
- Konsumen tidak dapat menggunakan sumber daya yang sama dua kali. Ini adalah kesalahan.
- Setiap sumber daya harus dikonsumsi oleh konsumen. Jika sumber daya terlewatkan, itu adalah kerugian
Selain itu, solusi harus berjalan di Server Linux dan Windows.
Pendekatan saat ini
Dalam versi saat ini, sistem mengimplementasikan solusi ini dengan menggunakan database relasional sebagai bus data.
Ada satu server database yang mendukung semua produsen dan konsumen. Produsen memasukkan sumber daya ke dalam tabel yang ditentukan dan konsumen menggunakan sumber daya dari tabel itu seperti yang ditunjukkan pada gambar di atas.
Model transaksi database server / JDBC memungkinkan untuk mengontrol penyisipan / penghapusan untuk menghindari korupsi antrian.
Pendekatan saat ini bekerja dengan baik tetapi:
- Memperkenalkan overhead pemeliharaan seluruh server database relasional untuk tugas yang tidak memerlukan hubungan data;
- Server database relasional harus sesuai dengan persyaratan misi kritis yang sulit dicapai pada beberapa pengaturan nyata saat instance server database tidak didedikasikan
Alternatif
Di sini saya mencantumkan beberapa alternatif untuk pendekatan bus data server database relasional saat ini:
Mendedikasikan server database relasional yang ringan
Ini tampaknya menjadi pendekatan termudah: Menggunakan server database relasional ringan khusus seperti HSQLDB, Apache Derby atau H2.
Pro
Mereka memiliki overhead yang jauh lebih sedikit untuk dipelihara jika dibandingkan dengan RDBMS seperti MS SQL Server, Oracle DB Server atau bahkan MySQL. Selain itu, perubahan kode dan pengujian yang lebih sedikit diperlukan karena mereka pada dasarnya adalah mesin SQL seperti yang digunakan dalam solusi saat ini.
Kontra
Mereka adalah server database relasional sehingga ternyata masih ada beberapa tingkat overhead untuk melakukan tugas bebas hubungan. Poin lainnya adalah aspek misi kritis. Kami menggunakan Derby DB secara internal selama berabad-abad untuk pengawasan sistem waktu nyata dalam mode tertanam dan jaringan. Ini berfungsi dengan baik, tidak ada kerusakan atau kerusakan data. Namun, volume transaksi / detik untuk penggunaan baru tersebut lebih tinggi.
Redis server
Sekilas, Redis terlihat sempurna untuk kasus penggunaan ini. Dalam memori, cepat, tidak ada overhad untuk hubungan data, langsung ke depan. Banyak digunakan sebagai databus dan dilaporkan dapat diandalkan. Tapi tidak untuk Windows. Seperti yang dikatakan di dokumen, Redis di Windows tidak disarankan . The Port Microsoft Windows tidak lagi dipertahankan , tanggal rilis terakhir 2016 sehingga melampirkan Redis ke sistem terlihat tidak promissing.
Menerapkan solusi dari awal
Dengan kata terakhir, ini adalah masalah produsen-konsumen. Menerapkan layanan jaringan menggunakan TCP atau sesuatu yang lebih elegan seperti Camel dan menggunakan antrian konkuren secara internal ditambah beberapa mesin persistensi lokal akan menghabiskan banyak waktu, menemukan kembali roda tetapi masih merupakan pilihan.
Ini adalah alternatif yang kami pertimbangkan sejauh ini. Saya menghargai jika seseorang dapat memberikan beberapa wawasan atau rekomendasi.
Jawaban
Sepertinya Anda sedang mencari antrian pesan. Bergantung pada tumpukan teknologi Anda, ada berbagai penerapan antrean terdistribusi yang mungkin menarik bagi Anda, misalnya ZeroMQ atau RabbitMQ.
Beberapa pendekatan seperti ZeroMQ dapat berjalan tanpa broker pesan, yang berarti produsen dan konsumen berbicara langsung tanpa memerlukan layanan atau database lain untuk mengatur / memperantarai antrian. Menjadi brokerless memiliki keuntungan karena jauh lebih sederhana untuk dikelola secara operasional daripada antrian pesan yang ditengahi, dan menjadi lebih sederhana untuk dipahami dan untuk mengukur dan menyesuaikan, tetapi kerugian utama adalah kurangnya layanan yang biasanya disediakan oleh broker, jadi jika peserta adalah offline, maka pesan mungkin hilang. Jika Anda membutuhkan pesan untuk diproses dengan andal, Anda harus merancang produsen Anda untuk dapat menangani pengiriman ulang jika konsumen tidak tersedia, Anda perlu menambahkan mekanisme untuk pengakuan pengiriman yang berhasil, dan kebutuhan konsumen untuk didesain menjadi idempoten (dapat mendeteksi pesan duplikat dan membuangnya). Keuntungan utama menjadi brokerless adalah Anda bebas untuk menerapkan perilaku broker sebanyak atau sesedikit yang dibutuhkan aplikasi Anda, jadi Anda tidak terikat dengan perilaku broker tertentu.
Antrian pesan yang diperantarai seperti RabbitMQ agak lebih sederhana selama digunakan, karena broker menambahkan lapisan ketekunan dan keandalan pesan ke struktur sistem antrian daripada mengharuskan produsen dan konsumen untuk menerapkannya, tetapi itu menambah kompleksitas dan overhead dalam mengelola broker , dan broker menambahkan latensi sehingga mungkin tidak sesuai untuk skenario di mana milidetik penting atau di mana tingkat skalabilitas target Anda melebihi apa yang dapat dicapai dalam sistem perantara.
masih ada beberapa tingkat overhead untuk melakukan tugas bebas hubungan
Saya menyarankan Anda untuk membuat profil aplikasi Anda untuk benar-benar mengetahui apakah itu benar-benar penting atau tidak. Kemungkinannya adalah jika database SQL dalam proses tidak cukup untuk aplikasi non-konkuren, kemungkinan besar karena Anda menggunakannya secara tidak efisien, bukan karena masalah kinerja dalam manajemen hubungan itu sendiri.