Temu Duga Bahagian Belakang Kafka: Bilakah Share Group Perlu Menyediakan Semantik Giliran?

Masalah dan skop

Pemberitahuan pesanan, transformasi imej, dan pengiraan bil selalunya merupakan item kerja yang bebas. Pasukan tersebut sudah pun menulis peristiwa ke Kafka, tetapi Consumer Group tradisional menetapkan partition kepada satu ahli pada satu masa; menambah lebih banyak pekerja berbanding partition tidak meningkatkan keselarian secara langsung. Reka bentuk cara untuk beberapa pengguna bekerjasama dalam kerja, dengan perakuan setiap rekod, percubaan semula, dan percubaan penghantaran yang boleh diperhatikan, sambil mengenal pasti aliran perniagaan yang masih memerlukan susunan partition.

Soalan ini menggunakan model Share Group yang diterangkan oleh KIP-932 Apache Kafka. KIP ini menerangkan jenis kumpulan baharu untuk penggunaan secara bekerjasama pada topik biasa; ia tidak menjadikan Kafka serupa dengan RabbitMQ. Jawapan yang kukuh mengesahkan versi broker yang digunakan, sokongan klien, dan ketersediaan API sebelum mengesyorkan penggunaan pengeluaran.

Perkara yang diuji oleh penemu duga

Bolehkah anda membezakan penugasan partition eksklusif dengan pemerolehan rekod secara bekerjasama?
Bolehkah anda memetakan perakuan (acknowledge), pelepasan (release), penolakan (reject), dan tamat tempoh kunci (lock expiry) kepada keadaan pemprosesan?
Adakah anda tahu bahawa Share Group boleh mempunyai lebih banyak pengguna berbanding partition tanpa mengekalkan intuisi susunan kunci yang biasa?
Adakah percubaan semula, rekod racun (poison records), tarikh akhir pemprosesan, dan had keserentakan sesuai dengan satu model kegagalan dalam jawapan anda?
Adakah anda akan mengesahkan butiran klien, broker, ACL, pemantauan, dan pengunduran (rollback) daripada sekadar menamakan KIP?

Jawapan yang lemah menyatakan "Kafka juga boleh menjadi giliran (queue)." Jawapan yang kukuh menamakan faedah seperti giliran, jaminan yang berubah, dan syarat semakan (gates) yang diperlukan sebelum pelancaran.

Soalan penjelasan untuk ditanya terlebih dahulu

Adakah tugas benar-benar bebas? Jika peristiwa untuk satu pesanan mesti diterapkan mengikut susunan kunci, Share Group mungkin primitif yang salah.
Adakah kegagalan bersifat sementara, boleh dipulihkan secara manual, atau tidak sah secara kekal? Itu menentukan tingkah laku pelepasan, penolakan, dan kuarantin.
Apakah masa pemprosesan p99, keserentakan maksimum, dan kesan sampingan duplikasi yang dibenarkan? Perkara ini membentuk reka bentuk kunci pemerolehan dan keidempotanan.
Adakah perniagaan memerlukan transaksi Kafka dari hujung ke hujung? Jangan anggap Share Group mewarisi pelan transaksi Consumer Group sedia ada.
Adakah topik masih melayani pengguna siaran atau main semula? Mengubah satu kumpulan tidak boleh mengubah kontrak bacaan kumpulan lain.

Jawapan 30 saat

"Saya akan terlebih dahulu mengesahkan sama ada tugas boleh selesai tidak mengikut susunan dan sama ada Kafka serta klien yang digunakan menyokong KIP-932. Share Group membolehkan ahli memperoleh rekod secara bekerjasama daripada topik, membenarkan bilangan ahli melebihi bilangan partition, dan menyokong perakuan setiap rekod, pelepasan, dan penolakan. Consumer Group kekal lebih sesuai untuk susunan tempatan partition dan penaakulan berasaskan offset. Saya akan menjadikan setiap kesan sampingan idempoten, menetapkan dasar kunci dan percubaan semula daripada kependaman pemprosesan, memantau keadaan peroleh, peraku, lepas, tolak, dan tamat masa, serta mengkuarantin rekod racun. Jika susunan, sempadan transaksi, atau sokongan klien belum selesai, saya akan mengekalkan Consumer Group dan mengesahkan topik kerja yang berasingan dengan kohort kecil sebelum berhijrah."

Penaakulan langkah demi langkah

1. Lukiskan dua model penugasan

Consumer Group biasanya menetapkan partition kepada ahli; seorang ahli membaca partition tertentu dalam kumpulan tersebut, jadi keselarian dihadkan oleh bilangan partition. Share Group membolehkan ahli memperoleh rekod secara bekerjasama daripada topik yang dilanggan. Beberapa ahli boleh memproses rekod yang berbeza daripada satu partition, dan bilangan ahli boleh melebihi bilangan partition. Itu berguna untuk tugas yang bebas, tetapi ia tidak membayangkan susunan global.

text

Consumer Group:  partition-0 -> worker-A
                 partition-1 -> worker-B
                 extra workers wait for another partition

Share Group:     partition-0 records -> worker-A, worker-B, worker-C
                 each acquired record is locked for one consumer

Sebab untuk memilih Share Group sepatutnya ialah pemerolehan kerja yang anjal dan penyelesaian setiap rekod, bukan semata-mata "terdapat terlalu sedikit partition." Jika peristiwa untuk seorang pelanggan mesti diterapkan mengikut susunan, kekalkan Consumer Group atau tambahkan mesin keadaan bersiri pada peringkat aplikasi.

2. Modelkan kitaran hayat rekod

KIP-932 menerangkan kunci pemerolehan yang terhad masa. Selepas memperoleh rekod, pengguna boleh memperakui kejayaan, melepaskannya untuk penghantaran lain, menolaknya sebagai tidak boleh diproses, atau tidak melakukan apa-apa sehingga kunci tamat tempoh. KIP menerangkan lalai 30 saat, tetapi tingkah laku pengeluaran mesti menggunakan tetapan broker yang digunakan; nilai lalai bukan SLA.

text

available -> acquired -> acknowledged
                    -> released -> available
                    -> rejected  -> terminal or quarantine
                    -> lock timeout -> available

Pengendali harus mendaftarkan kunci keidempotanan sebelum kesan sampingan luaran. Jika tidak, ranapan klien atau tamat tempoh kunci boleh mengenakan caj, menghantar, atau memberitahu dua kali. Perakuan menyatakan bahawa pemerolehan ini telah selesai; ia tidak boleh mengundurkan kesan sampingan yang telah dilakukan oleh sistem lain.

3. Hadkan percubaan semula, rekod racun, dan keserentakan

Kiraan percubaan penghantaran membantu memisahkan kegagalan sementara daripada rekod yang tidak sah secara kekal. Berundur (back off) dan lepaskan untuk kegagalan rangkaian. Tolak ralat skema atau pengesahan deterministik ke dalam topik kuarantin atau giliran manual. Jangan lepaskan selama-lamanya: satu rekod racun boleh menggunakan kunci dan kapasiti hiliran selama-lamanya.

Tetapkan kunci melebihi masa pemprosesan p99 biasa dengan margin variasi (jitter) yang boleh dijelaskan. Terlalu pendek menyebabkan penghantaran semula bertindih; terlalu lama melambatkan pemulihan. Hadkan juga rekod yang diperoleh bagi setiap partition dan selaraskan semafor pekerja, kolam pangkalan data, dan kuota API luaran. Pantau kunci aktif, tamat masa kunci, taburan percubaan, penolakan, dan kependaman penyelesaian hujung ke hujung bersama-sama.

4. Nyatakan semula jaminan susunan dan duplikasi

Penerangan Kafka sering menukar "tersusun di dalam partition" kepada "pemprosesan perniagaan adalah tersusun." Ahli Share Group boleh memperoleh rekod secara serentak, jadi susunan penyelesaian untuk satu kunci mungkin berbeza daripada susunan penulisan; pelepasan dan penghantaran semula membesarkan perbezaan tersebut. Jika susunan penting, kodkan penyirikan peringkat kunci, semakan versi, atau mesin keadaan dalam aplikasi. Jangan menjawab dengan "Kafka adalah tersusun" semata-mata.

Tepat sekali (Exactly-once) juga tidak muncul secara automatik daripada jenis kumpulan. Jejak sempadan antara pemerolehan rekod, penulisan perniagaan, dan perakuan. Pangkalan data luaran atau perkhidmatan pembayaran masih memerlukan kunci keidempotanan, kekangan penyahduplikasian, atau outbox transaksi. Jika sesuatu gabungan tidak disokong, nyatakan bahawa reka bentuk tersebut adalah sekurang-kurangnya sekali (at-least-once) dengan keidempotanan daripada memanggilnya tepat sekali.

5. Rancang migrasi dan pengunduran

Sahkan versi broker, API klien, konfigurasi kumpulan, ACL, metrik, dan perintah operasi. Kemudian lakukan ujian beban pada topik berasingan atau beban kerja kecil. Suntik kegagalan: ranap selepas pemerolehan, pemprosesan melebihi kunci, penolakan berulang, mulakan semula broker, dan pergerakan penyelaras. Catatkan kunci perniagaan, percubaan, keadaan, dan cap masa untuk setiap rekod.

Jika pengguna lama bergantung pada susunan atau transaksi, jangan ubah kumpulan yang sama di tempat asal. Salin kerja ke topik khusus dan biarkan kumpulan baharu mengambil trafik secara beransur-ansur; pastikan laluan lama boleh dimainkan semula sehingga kadar ralat, kesan sampingan duplikasi, dan kependaman memenuhi syarat semakan. Pengunduran menghentikan pemerolehan baharu dan membiarkan laluan lama menggunakan rekod yang belum berhijrah. Dua laluan aktif tidak boleh melaksanakan kesan sampingan yang sama tanpa sempadan penyahduplikasian yang jelas.

Contoh jawapan berkualiti tinggi

"Saya akan mulakan dengan bertanya sama ada tugas boleh selesai tidak mengikut susunan, sama ada pemprosesan adalah idempoten, dan sama ada broker serta klien yang digunakan menyokong KIP-932. Share Group menganggap rekod topik bebas sebagai kerja secara bekerjasama: beberapa ahli boleh memperoleh rekod berbeza daripada satu partition, bilangan ahli boleh melebihi bilangan partition, dan setiap rekod mempunyai laluan peraku, lepas, tolak, dan tamat tempoh kunci. Ia mengubah intuisi peruntukan dan susunan kumpulan tradisional, jadi saya akan mengekalkan Consumer Group atau menambah semakan versi apabila kunci perniagaan memerlukan susunan.

Saya akan menetapkan kunci keidempotanan pada setiap rekod, menetapkan kunci pemerolehan daripada masa pemprosesan p99, dan mengehadkan kunci aktif serta keserentakan hiliran. Kegagalan sementara dilepaskan dengan penundaan (backoff); data buruk deterministik ditolak ke kuarantin; ambang percubaan menghentikan percubaan semula automatik. Saya akan memantau peroleh, peraku, lepas, tolak, tamat masa, kesan sampingan duplikasi, dan kependaman penyelesaian. Sebelum migrasi saya akan mengesahkan versi, ACL, tingkah laku klien, dan kegagalan yang disuntik pada topik berasingan. Melainkan pemerolehan rekod, penulisan perniagaan, dan perakuan berkongsi satu sempadan transaksi yang terbukti, saya akan memanggil reka bentuk ini sekurang-kurangnya sekali ditambah keidempotanan, bukan tepat sekali."

Kesilapan lazim

Memanggil Share Group sebagai klon RabbitMQ → penyimpanan, main semula, dan pentadbiran berbeza → janjikan hanya semantik pemerolehan dan perakuan secara bekerjasama yang didokumenkan oleh KIP-932.
Mengehadkan pekerja pada bilangan partition → Share Group membenarkan beberapa ahli memproses satu partition → hadkan keserentakan mengikut kunci, kapasiti hiliran, dan kependaman hujung ke hujung.
Menganggap susunan kunci kekal utuh → pemerolehan serentak dan penghantaran semula mengubah susunan penyelesaian → sirikan kunci atau semak versi apabila susunan adalah keperluan.
Memperakui tanpa keidempotanan → ranapan atau tamat tempoh kunci boleh menghantar semula rekod → nyahduplikasi mengikut kunci perniagaan sebelum perakuan.
Melepaskan rekod racun selama-lamanya → percubaan semula menghabiskan kunci dan bajet hiliran → hentikan percubaan semula automatik mengikut jenis ralat, kiraan percubaan, dan dasar kuarantin.
Menganggap 30 saat sebagai jaminan → konfigurasi broker dan kependaman pemprosesan berbeza → uji tetapan kunci yang digunakan terhadap p99.

Soalan susulan dan respons

Bagaimana jika peristiwa untuk satu pesanan mesti disusun secara ketat?

Jangan beralih terus ke Share Group. Kekalkan Consumer Group yang dipartitionkan mengikut ID pesanan, atau gunakan mesin keadaan bersiri peringkat aplikasi. Jika pemerolehan kongsi adalah wajib, tambahkan semakan versi, pengesahan prasyarat, dan penyusunan semula kegagalan, serta akui kerumitan tambahan tersebut.

Bagaimana jika pengguna tergantung selama dua minit selepas pemerolehan?

Tetapkan kunci sedikit melebihi p99 biasa dan berikan amaran tentang tamat masa kunci. Benarkan penghantaran semula selepas tamat tempoh, tetapi wajibkan pengendalian perniagaan yang idempoten. Untuk kerja yang panjang, bahagikan kepada langkah-langkah yang boleh disambung semula atau gunakan pajakan (lease) luaran daripada melanjutkan kunci selama-lamanya.

Bagaimana anda mengendalikan lima kegagalan skema berturut-turut?

Kendalikan ia sebagai ralat deterministik: tolak selepas ambang tertentu dan tulis muatan (payload), versi skema, dan sebab ke kuarantin. Selepas membetulkan pengguna, mainkan semula di bawah prosedur yang terkawal. Jangan biarkan aliran kerja utama mencuba semula selama-lamanya.

Sistem semasa bergantung pada transaksi Kafka. Bolehkah ia beralih secara langsung?

Senaraikan sempadan bacaan, pemprosesan, dan penulisan transaksi, kemudian sahkan sokongan klien dan transaksi Share Group yang sebenar. Jika kesan sampingan luaran berada di luar transaksi yang sama, gunakan outbox, kunci keidempotanan, dan pampasan. Kekalkan Consumer Group apabila sokongan belum terbukti.

Bagaimana anda membuktikan migrasi tidak mengenakan caj dua kali kepada pelanggan?

Catatkan setiap pelaksanaan di bawah kunci perniagaan yang unik dengan kekangan penyahduplikasian. Suntik ranapan, tamat tempoh kunci, percubaan semula, dan pengunduran, kemudian bandingkan kiraan pelaksanaan dan perakuan. Kembangkan trafik hanya apabila invarian kesan sampingan, kependaman, dan kadar ralat dipenuhi.