Menggunakan Kafka sebagai Eventstore (CQRS). Ide bagus?

219

Meskipun saya telah menemukan Kafka sebelumnya, saya baru-baru ini menyadari Kafka mungkin dapat digunakan sebagai (dasar) CQRS , eventstore .

Salah satu poin utama yang didukung Kafka:

  • Acara menangkap / menyimpan, semua HA tentu saja.
  • Arsitektur pub / sub
  • Kemampuan untuk memutar ulang eventlog yang memungkinkan kemampuan bagi pelanggan baru untuk mendaftar dengan sistem setelah fakta.

Memang saya tidak 100% berpengalaman dalam CQRS / Sumber acara tetapi ini tampaknya cukup dekat dengan apa yang seharusnya menjadi toko acara. Lucunya adalah: Saya benar-benar tidak dapat menemukan banyak tentang Kafka yang digunakan sebagai toko acara, jadi mungkin saya kehilangan sesuatu.

Jadi, ada yang hilang dari Kafka untuk itu menjadi toko acara yang bagus? Apakah ini akan berhasil? Menggunakannya produksi? Tertarik pada wawasan, tautan, dll.

Pada dasarnya keadaan sistem disimpan berdasarkan pada transaksi / peristiwa yang pernah diterima sistem, bukan hanya menyimpan keadaan saat ini / snapshot dari sistem yang biasanya dilakukan. (Anggap saja sebagai Buku Besar Akuntansi: semua transaksi pada akhirnya mencapai kondisi akhir) Hal ini memungkinkan semua jenis hal keren, tetapi baca saja tautan yang disediakan.

cqrs event-sourcing apache-kafka dddd Geert-Jan
sumber
Hai Geert-Jan. Dalam retrospektif, bagaimana Anda menangani masalah ini? Saya punya pertanyaan terkait (diekspos di sini: stackoverflow.com/questions/58763727/… ). Kebanyakan orang menyarankan adopsi Kafka tampaknya bergantung pada poin-poin ketidakmampuan menambahkan-log, throughput yang tinggi, dan jaminan pemesanan partisi. Saya melihat masalah yang terkait dengan pencarian cepat dalam topik (untuk entitas "rekonstruksi"), Tidak ada atomitas transaksional dan tidak ada pemesanan di seluruh partisi (Garansi pesanan 100% menyiratkan hanya menggunakan 1 partisi -kursi concurrency)
tony _008
Tidak memaksanya pada akhirnya karena saya mengakhiri proyek itu. Jadi tidak ada jawaban yang jelas, saya rasa
Geert-Jan

Jawaban:

119

Kafka dimaksudkan untuk menjadi sistem pengiriman pesan yang memiliki banyak kemiripan dengan toko peristiwa namun mengutip intro mereka:

Cluster Kafka mempertahankan semua pesan yang dipublikasikan — baik dikonsumsi atau tidak — untuk jangka waktu yang dapat dikonfigurasi . Misalnya, jika retensi diatur selama dua hari, maka selama dua hari setelah pesan diterbitkan, itu tersedia untuk konsumsi, setelah itu akan dibuang untuk membebaskan ruang. Kinerja Kafka secara konstan konstan sehubungan dengan ukuran data sehingga mempertahankan banyak data tidak menjadi masalah.

Jadi, sementara pesan dapat berpotensi dipertahankan tanpa batas waktu, harapannya adalah bahwa pesan itu akan dihapus. Ini tidak berarti Anda tidak dapat menggunakan ini sebagai toko acara, tetapi mungkin lebih baik menggunakan sesuatu yang lain. Lihatlah EventStore untuk alternatifnya.

MEMPERBARUI

Dokumentasi Kafka :

Sumber acara adalah gaya desain aplikasi di mana perubahan negara dicatat sebagai urutan catatan yang terurut waktu. Dukungan Kafka untuk data log tersimpan sangat besar menjadikannya backend yang sangat baik untuk aplikasi yang dibangun dengan gaya ini.

PEMBARUAN 2

Salah satu perhatian dengan menggunakan Kafka untuk sumber acara adalah sejumlah topik yang diperlukan. Biasanya dalam sumber acara, ada aliran (topik) acara per entitas (seperti pengguna, produk, dll). Dengan cara ini, keadaan saat ini dari entitas dapat disusun kembali dengan menerapkan kembali semua peristiwa di aliran. Setiap topik Kafka terdiri dari satu atau lebih partisi dan setiap partisi disimpan sebagai direktori pada sistem file. Juga akan ada tekanan dari ZooKeeper karena jumlah znode meningkat.

eulerfx
sumber
16
Saya sedang melihat Kafka dan memiliki kekhawatiran lain: saya tidak memperhatikan apapun tentang optimisme-konkurensi. Idealnya saya dapat mengatakan: "Tambahkan acara ini sebagai item N +1 hanya jika acara terbaru objek masih N."
Darien
2
@Darien: Saya mungkin pergi dengan setup di mana Redis memberi makan Kafka (menggunakan Redis Notifications ). Karena Redis memungkinkan konkurensi optimis (menggunakan Watch / multi-exec), ini seharusnya berfungsi
Geert-Jan
2
@Darien Saya bukan ahli tentang sumber acara, tetapi pemahaman saya adalah bahwa secara umum Anda tidak perlu konkurensi optimis karena peristiwa secara definisi mencatat hal-hal yang telah terjadi secara historis.
John
4
@ John Saya pikir jika Anda sudah memiliki pemesanan resmi acara yang tidak bertentangan, yang menyiratkan di mana pun mereka tinggal adalah teknologi acara-toko Anda yang sebenarnya, dan Kafka hanya digunakan sebagai sistem sekunder untuk mendistribusikannya.
Darien
1
Ada juga informasi berharga di sini: groups.google.com/forum/#!topic/dddcqrs/rm02iCfffUY
manuc66
283

Saya adalah salah satu penulis asli Kafka. Kafka akan bekerja dengan sangat baik sebagai log untuk sumber acara. Ini toleran terhadap kesalahan, skala untuk ukuran data yang sangat besar, dan memiliki model partisi yang dibangun.

Kami menggunakannya untuk beberapa kasus penggunaan formulir ini di LinkedIn. Misalnya sistem pemrosesan sumber terbuka kami, Apache Samza, dilengkapi dengan dukungan bawaan untuk sumber acara.

Saya pikir Anda tidak mendengar banyak tentang menggunakan Kafka untuk sumber acara terutama karena terminologi sumber acara tampaknya tidak terlalu lazim di ruang web konsumen di mana Kafka paling populer.

Saya telah menulis sedikit tentang gaya penggunaan Kafka di sini .

Jay Kreps
sumber
2
Akan memposting tautan itu :) Posting blog yang luar biasa. Akan lebih baik untuk bisa berkomentar karena saya punya banyak pertanyaan. @ Geert-Jan juga melihat "arsitektur Lambda", ini sangat mirip dan namanya diberikan dari penulis Storm, sebagian besar menggunakan beberapa jenis event log berbasis hadoop di banyak contoh
Sebastien Lorber
6
@ Jay: Karena saya telah memperbarui minat pada topik ini, dapatkah Anda menjelaskan sedikit tentang fakta bahwa Kafka tampaknya dirancang untuk membuat pesan-pesannya yang diterbitkan kadaluwarsa setelah jangka waktu tertentu? Jika menggunakan Kafka sebagai sumber acara, pesan harus disimpan tanpa batas waktu. Ini mungkin dapat dikonfigurasi, tetapi apakah ini akan menimbulkan masalah?
Geert-Jan
2
Apakah ada perbandingan antara kafka dan eventstore? Secara khusus saya suka fokus pada FRP di eventstore yang disebut Proyeksi. Apakah ada yang seperti itu di Kafka / Samza?
CMCDragonkai
4
Saya juga tertarik pada pertanyaan @ Geert-Jan untuk Jay. Kafka tidak cocok untuk sisi transaksional sumber acara yang sebenarnya, karena membutuhkan aliran peristiwa (topik) per agregat domain (pikirkan jutaan). Namun, idealnya cocok untuk memasukkan acara ke dalamnya dari misalnya GetEventStore. Tetapi ini hanya akan bekerja dengan kejadian yang tak terbatas dipertahankan (dalam kasus kami), dan selain dari beberapa komentar singkat, ini tampaknya bukan kasus penggunaan yang didukung Kafka? Apakah saya salah di sini? Samza, misalnya, mengasumsikan hanya ada dua skenario: retensi berbasis waktu atau retensi berbasis kunci. Ada yang lain ..
Stephen Drew
3
@eulerfx Dengan asumsi kami ingin menggunakan Kafka sebagai penyimpanan untuk sistem bersumber acara, bagaimana seharusnya penguncian / konkurensi optimistis diterapkan?
Krzysztof Branicki
51

Saya terus kembali ke QA ini. Dan saya tidak menemukan jawaban yang ada cukup bernuansa, jadi saya menambahkan jawaban ini.

TL; DR. Ya atau Tidak, tergantung pada penggunaan sumber acara Anda.

Ada dua jenis utama sistem sumber acara yang saya sadari.

Prosesor acara hilir = Ya

Dalam sistem semacam ini, peristiwa terjadi di dunia nyata dan dicatat sebagai fakta. Seperti sistem gudang untuk melacak palet produk. Pada dasarnya tidak ada peristiwa yang saling bertentangan. Semuanya sudah terjadi, walaupun itu salah. (Yaitu palet 123456 memakai truk A, tetapi dijadwalkan untuk truk B.) Kemudian fakta diperiksa untuk pengecualian melalui mekanisme pelaporan. Kafka tampaknya sangat cocok untuk aplikasi pemrosesan acara seperti ini.

Dalam konteks ini, dapat dimengerti mengapa orang Kafka mengadvokasi itu sebagai solusi Event Sourcing. Karena sangat mirip dengan cara penggunaannya, misalnya, klik aliran. Namun, orang yang menggunakan istilah Pengadaan Acara (yang bertentangan dengan Pemrosesan Streaming) cenderung merujuk pada penggunaan kedua ...

Sumber kebenaran yang dikendalikan aplikasi = Tidak

Aplikasi semacam ini menyatakan acara sendiri sebagai hasil dari permintaan pengguna yang melewati logika bisnis. Kafka tidak berfungsi dengan baik dalam hal ini karena dua alasan utama.

Kurangnya isolasi entitas

Skenario ini membutuhkan kemampuan untuk memuat aliran acara untuk entitas tertentu. Alasan umum untuk ini adalah untuk membangun model tulis sementara untuk logika bisnis untuk digunakan untuk memproses permintaan. Melakukan ini tidak praktis di Kafka. Menggunakan topik per entitas dapat memungkinkan hal ini, kecuali ini bukan permulaan ketika mungkin ada ribuan atau jutaan entitas. Ini karena batasan teknis di Kafka / Zookeeper.

Salah satu alasan utama untuk menggunakan model tulis sementara dengan cara ini adalah untuk membuat perubahan logika bisnis murah dan mudah digunakan.

Disarankan menggunakan topik per jenis untuk Kafka, tetapi ini membutuhkan pemuatan acara untuk setiap entitas dari tipe itu hanya untuk mendapatkan acara untuk satu entitas. Karena Anda tidak dapat mengetahui posisi log peristiwa mana yang dimiliki entitas mana. Bahkan menggunakan Snapshots untuk memulai dari posisi log yang diketahui, ini bisa menjadi sejumlah besar peristiwa yang harus dilalui.

Kurangnya deteksi konflik

Kedua, pengguna dapat membuat kondisi balapan karena permintaan bersamaan terhadap entitas yang sama. Mungkin sangat tidak diinginkan untuk menyimpan peristiwa yang saling bertentangan dan menyelesaikannya setelah fakta. Jadi penting untuk bisa mencegah peristiwa yang saling bertentangan. Untuk skala pemuatan permintaan, adalah umum untuk menggunakan layanan stateless sambil mencegah konflik penulisan menggunakan penulisan bersyarat (hanya menulis jika peristiwa entitas terakhir adalah #x). Aka Optimis Concurrency. Kafka tidak mendukung konkurensi optimis. Bahkan jika itu mendukungnya di tingkat topik, itu akan perlu sampai ke tingkat entitas untuk menjadi efektif. Untuk menggunakan Kafka dan mencegah peristiwa yang saling bertentangan, Anda harus menggunakan penulis berseri, berseri di tingkat aplikasi. Ini adalah persyaratan / batasan arsitektur yang signifikan.

Informasi lebih lanjut

Perbarui per komentar

Komentar telah dihapus, tetapi pertanyaannya adalah seperti: apa yang digunakan orang untuk penyimpanan acara?

Tampaknya sebagian besar orang menggelar implementasi penyimpanan acara mereka sendiri di atas basis data yang ada. Untuk skenario yang tidak terdistribusi, seperti back-end internal atau produk yang berdiri sendiri, terdokumentasi dengan baik bagaimana membuat event store berbasis SQL. Dan ada perpustakaan yang tersedia di atas berbagai macam basis data. Ada juga EventStore , yang dibangun untuk tujuan ini.

Dalam skenario terdistribusi, saya telah melihat beberapa implementasi yang berbeda. Proyek Jet's Panther menggunakan Azure CosmosDB , dengan fitur Change Feed untuk memberi tahu pendengar. Implementasi serupa lainnya yang pernah saya dengar di AWS adalah menggunakan DynamoDB dengan fitur Streams untuk memberi tahu pendengar. Kunci partisi mungkin harus menjadi id aliran untuk distribusi data terbaik (untuk mengurangi jumlah penyediaan berlebihan). Namun, replay penuh lintas sungai di Dynamo mahal (baca dan hemat biaya). Jadi impl ini juga disiapkan untuk Dynamo Streams untuk membuang acara ke S3. Ketika pendengar baru daring, atau pendengar yang ada ingin ulangan penuh, ia akan membaca S3 untuk mengejar ketinggalan terlebih dahulu.

Proyek saya saat ini adalah skenario multi-tenant, dan saya menggulirkan sendiri di atas Postgres. Sesuatu seperti Citus tampaknya sesuai untuk skalabilitas, dipartisi oleh aliran + tentant.

Kafka masih sangat berguna dalam skenario terdistribusi. Merupakan masalah non-sepele untuk mengekspos acara masing-masing layanan ke layanan lain. Sebuah toko acara tidak dibangun untuk itu biasanya, tapi justru itulah yang dilakukan Kafka dengan baik. Setiap layanan memiliki sumber kebenaran internal sendiri (dapat berupa penyimpanan acara atau lainnya), tetapi mendengarkan Kafka untuk mengetahui apa yang terjadi "di luar". Layanan ini juga dapat memposting acara ke Kafka untuk menginformasikan "luar" hal-hal menarik yang dilakukan layanan.

Kasey Speakman
sumber
1
@Dominik Saya menyebutkan EventStore di bagian Pembaruan (paragraf ke-2). Saya akan kembali dan menautkannya. Saya sudah mencobanya, dan memiliki perf yang mengesankan. Untuk tim kecil kami, tidak memperkenalkan database lain dianggap lebih penting untuk saat ini, maka Postgres (yang juga digunakan untuk tampilan). Mungkin saja kami pindah ke EventStore di masa depan atau di produk masa depan.
Kasey Speakman
2
@KaseySpeakman Topik tidak sama dengan partisi. Sebuah topik memiliki satu atau lebih partisi. Partisi dijamin hanya memiliki satu konsumen per grup pada saat tertentu. Partisi entitas Anda sedemikian rupa untuk memanfaatkan itu. Anda tidak perlu topik per entitas atau bahkan partisi per entitas. Anda hanya perlu mempartisi mereka sedemikian rupa untuk menjamin bahwa semua perintah yang ditujukan ke entitas yang sama pergi ke partisi yang sama.
Andrew Larsson
1
@KaseySpeakman Banyak entitas dapat berbagi satu partisi. Siapa bilang Anda selalu harus memuat status entitas langsung dari toko acara dengan memutar ulang acara? Ada cara lain untuk mencapai konsep yang sama tanpa secara ketat mengikuti implementasi Greg Young baris demi baris.
Andrew Larsson
1
@AndrewLarsson Jika Anda tidak mempartisi per entitas, lalu bagaimana Anda akan mencegah peristiwa yang bertentangan di tingkat entitas? Karena kita telah kembali ke konflik konkurensi, maka mungkin Anda harus memposting artikel Anda sendiri di media atau sesuatu tentang bagaimana Anda telah menggunakan Kafka untuk sumber acara (bukan stream processing) dalam produksi. Bagaimana Anda mencapainya dengan partisi berdasarkan jenis dan tanpa kontrol konkurensi tingkat entitas. Saya akan membacanya, dan saya bahkan tidak akan komentar Anda jika saya tidak setuju.
Kasey Speakman
2
@KaseySpeakman Menggunakan Kafka dengan cara ini tidak mudah dengan cara apa pun. Tetapi jika Anda berada pada skala di mana Anda secara serius mempertimbangkan CQRS dan Event Sourcing, maka Anda berada pada skala di mana Anda tidak mampu melakukan hal-hal dengan cara mudah. Model konkurensi Anda memiliki dampak langsung pada skala Anda - jangan pilih yang sewenang-wenang. Selain itu, HTTP bukan transportasi yang andal, dan sekali lagi, jika Anda berada pada skala itu, Anda tidak mampu menghabiskan waktu untuk menyelesaikan masalah pesan yang hilang dan / atau duplikat. Ini semua bisa diselesaikan dengan menggunakan Kafka antara klien dan pemroses perintah, tetapi ya, itu datang pada biaya kompleksitas.
Andrew Larsson
20

Anda dapat menggunakan Kafka sebagai toko acara, tetapi saya tidak merekomendasikan melakukannya, meskipun ini mungkin pilihan yang bagus:

  • Kafka hanya menjamin setidaknya sekali pengiriman dan ada duplikat di toko acara yang tidak dapat dihapus. Pembaruan: Di sini Anda dapat membaca mengapa begitu sulit dengan Kafka dan beberapa berita terbaru tentang bagaimana akhirnya mencapai perilaku ini: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-kafka-do-it /
  • Karena kekekalan, tidak ada cara untuk memanipulasi event store ketika aplikasi berkembang dan acara perlu diubah (tentu saja ada metode seperti upcasting, tapi ...). Sekali mungkin mengatakan Anda tidak perlu mengubah peristiwa, tetapi itu bukan asumsi yang benar, mungkin ada situasi di mana Anda membuat cadangan asli, tetapi Anda meng-upgrade mereka ke versi terbaru. Itulah persyaratan yang valid dalam arsitektur yang digerakkan oleh peristiwa.
  • Tidak ada tempat untuk menyimpan snapshot entitas / agregat dan pemutaran ulang akan menjadi lebih lambat dan lebih lambat. Membuat snapshot adalah fitur untuk penyimpanan acara dari perspektif jangka panjang.
  • Mengingat partisi Kafka didistribusikan dan mereka sulit untuk mengelola dan membuat cadangan dibandingkan dengan database. Basis data lebih sederhana :-)

Jadi, sebelum Anda membuat pilihan, Anda berpikir dua kali. Event store sebagai kombinasi antarmuka lapisan aplikasi (pemantauan dan manajemen), toko SQL / NoSQL dan Kafka sebagai broker adalah pilihan yang lebih baik daripada meninggalkan Kafka menangani kedua peran untuk membuat fitur lengkap solusi lengkap.

Event store adalah layanan kompleks yang membutuhkan lebih dari apa yang dapat ditawarkan Kafka jika Anda serius menerapkan sumber acara, CQRS, Sagas, dan pola lainnya dalam arsitektur yang digerakkan oleh acara dan tetap berkinerja tinggi.

Jangan ragu untuk menantang jawaban saya! Anda mungkin tidak menyukai apa yang saya katakan tentang broker favorit Anda dengan banyak kemampuan yang tumpang tindih, tetapi tetap saja, Kafka tidak dirancang sebagai event store, tetapi lebih sebagai broker dan buffer berkinerja tinggi pada saat yang sama untuk menangani produsen cepat versus skenario konsumen yang lambat, sebagai contoh.

Silakan lihat framework open source eventuate.io microservices untuk menemukan lebih banyak tentang masalah potensial: http://eventuate.io/

Pembaruan pada 8 Februari 2018

Saya tidak memasukkan info baru dari komentar, tetapi menyetujui beberapa aspek tersebut. Pembaruan ini lebih lanjut tentang beberapa rekomendasi untuk platform yang didorong oleh acara microservice. Jika Anda serius tentang desain microservice yang tangguh dan kinerja setinggi mungkin secara umum, saya akan memberikan beberapa petunjuk yang mungkin menarik bagi Anda.

  1. Jangan gunakan Spring - itu hebat (saya sering menggunakannya sendiri), tetapi berat dan lambat pada saat yang sama. Dan itu bukan platform microservice sama sekali. Ini "hanya" kerangka kerja untuk membantu Anda menerapkannya (banyak pekerjaan di balik ini ..). Kerangka kerja lainnya adalah "hanya" REST ringan atau JPA atau kerangka kerja yang berbeda fokus. Saya merekomendasikan mungkin platform microservice lengkap open source terbaik di kelasnya yang tersedia yang kembali ke akar Java murni: https://github.com/networknt

Jika Anda bertanya-tanya tentang kinerja, Anda dapat membandingkan diri Anda dengan benchmark benchmark yang ada. https://github.com/networknt/microservices-framework-benchmark

  1. Jangan gunakan Kafka sama sekali :-)) Ini setengah bercanda. Maksud saya sementara Kafka hebat, itu adalah sistem sentris broker lain. Saya pikir masa depan adalah dalam sistem pesan tanpa perantara. Anda mungkin terkejut tetapi ada yang lebih cepat daripada sistem Kafka :-), tentu saja Anda harus turun ke level yang lebih rendah. Lihatlah Chronicle.

  2. Untuk Event store, saya merekomendasikan ekstensi Postgresql superior yang disebut TimescaleDB, yang berfokus pada pemrosesan data deret waktu kinerja tinggi (peristiwa adalah deret waktu) dalam volume besar. Tentu saja CQRS, Event sourcing (fitur replay, dll.) Dibangun dalam kerangka light4j di luar kotak yang menggunakan Postgres sebagai penyimpanan rendah.

  3. Untuk olahpesan coba lihat Chronicle Queue, Map, Engine, Network. Maksud saya menyingkirkan solusi sentris broker kuno dan pergi dengan sistem pesan mikro (tertanam satu). Antrian Chronicle sebenarnya bahkan lebih cepat dari Kafka. Tapi saya setuju itu tidak semua dalam satu solusi dan Anda perlu melakukan pengembangan jika tidak Anda pergi dan membeli versi Perusahaan (berbayar). Pada akhirnya, upaya untuk membangun dari Chronicle, lapisan pesan Anda sendiri akan dibayar dengan menghilangkan beban mempertahankan cluster Kafka.

kensai
sumber
Tampilan menarik. Ingin menguraikan beberapa poin? > Kafka hanya menjamin setidaknya sekali pengiriman dan ada duplikat di toko acara yang tidak dapat dihapus. Anda tampaknya menyiratkan bahwa ada hal yang tepat sekali pengiriman. afaik (dan saya cukup yakin tentang itu) tidak ada hal seperti itu dalam sistem terdistribusi. 2) Adapun poin Anda 2: pemikiran sekolah klasik (event sourcing / dddd) adalah bahwa peristiwa secara inheren tidak dapat diubah. Yaitu: mereka bahagia, tidak ada cara untuk mengubah masa lalu. Apa gunanya sebenarnya - tas mengubahnya dalam retrospeksi? Terima kasih!
Geert-Jan
1.) Hazelcast untuk memastikan setiap pesan akan diproses sekali dan hanya sekali. 2.) Saya tidak suka apa pun seperti _V2 dalam kode layanan, jadi Anda akan mencadangkan ke arsip dan membuat kembali acara lama ke versi baru mereka (Anda masih memiliki kebenaran asli), atau Anda dapat menyembunyikan / membangun fungsi ini langsung ke dalam Acara Simpan fungsionalitas snapshot, sehingga ada satu titik upcasting -> store event. Apa solusi Anda untuk ini?
kensai
1) paling sedikit sekali + idempotensi pada konsumen. Yaitu: periksa apakah acara sudah terlihat. Jika demikian lewati. Atau lebih baik lagi, memiliki tindakan idempoten. Tentu saja, ini tidak selalu memungkinkan. 2) Saya belum pernah menemukan perlu versi acara. Saya selalu memperlakukan peristiwa itu sendiri sebagai sumber kebenaran dan memasukkan semua info yang saya perlukan tentang mereka. Melakukan ini, saya tidak pernah mengalami situasi di mana saya membutuhkan struktur acara yang berbeda dan / atau data tentang suatu peristiwa. Tapi mungkin ymmv. Tertarik untuk mendengar dalam situasi apa Anda sebenarnya perlu memperbarui acara.
Geert-Jan
1.) bisa menjadi cara pilihan .. 2.) maka struktur data Anda sempurna dari awal :-) beruntung, haha. Saya mungkin tidak membutuhkannya pada proyek saya saat ini, tetapi saya sedang membangun seluruh platform pada garpu eventuate.io digabung dengan beberapa pendekatan JEE berkinerja tinggi yang diambil dari light eventuj 4j ... seluruh diskusi ini bukan tempat untuk komentar tentang stackoverflow , tetapi jika Anda tertarik untuk menyelam lebih dalam, saya merekomendasikan artikel ini: leanpub.com/esversioning/read
kensai
1
Kafka mendukung pengiriman tepat satu kali sekarang. Perbarui bullet 1
OneCricketeer
8

Ya, Anda dapat menggunakan Kafka sebagai toko acara. Ini bekerja cukup baik, terutama dengan pengenalan Kafka Streams , yang menyediakan cara asli Kafka untuk memproses acara Anda menjadi keadaan terakumulasi yang dapat Anda tanyakan .

Mengenai:

Kemampuan untuk memutar ulang eventlog yang memungkinkan kemampuan bagi pelanggan baru untuk mendaftar dengan sistem setelah fakta.

Ini bisa rumit. Saya membahasnya secara rinci di sini: https://stackoverflow.com/a/48482974/741970

Dmitry Minkovsky
sumber
0

Ya, Kafka bekerja dengan baik dalam model sumber acara khusus CQRS, namun Anda harus berhati-hati saat menetapkan TTL untuk topik dan selalu ingat bahwa Kafka tidak dirancang untuk model ini, namun kami dapat menggunakannya dengan sangat baik.

Brijendra Verma
sumber
0

Saya pikir Anda harus melihat kerangka akson bersama dengan dukungan mereka untuk Kafka

Darshu Bc
sumber