Ringkasan
Kafka tidak menyediakan mekanisme Ketersediaan Tinggi dalam versi sebelum 0.8. Setelah satu atau lebih Pialang mati, semua Partisi di atasnya tidak dapat terus menyediakan layanan selama waktu henti. Jika Broker tidak pernah dapat dipulihkan, atau disk gagal, data di dalamnya akan hilang. Salah satu tujuan desain Kafka adalah untuk memberikan persistensi data, sedangkan untuk sistem terdistribusi, terutama ketika ukuran cluster naik ke tingkat tertentu, kemungkinan satu atau lebih mesin turun sangat meningkat. Untuk mekanisme Failover Permintaannya sangat tinggi. Karenanya, Kafka telah menyediakan mekanisme Ketersediaan Tinggi sejak 0.8. Artikel ini memperkenalkan mekanisme HA Kafka dari dua aspek: Replikasi Data dan Pemilihan Pemimpin.
Mengapa Anda membutuhkan Replikasi
Pada Kafka versi sebelum 0.8, tidak ada Replikasi, sekali Broker down, semua data Partisi di dalamnya tidak dapat digunakan, yang bertentangan dengan tujuan desain dari ketahanan data Kafka dan Delivery Guarantee. Pada saat yang sama, Produser tidak dapat lagi menyimpan data di Partisi ini.
- Jika Produser menggunakan mode sinkron, Produser akan menampilkan Exception setelah mencoba mengirim ulang message.send.max.retries (nilai defaultnya adalah 3) kali. Pengguna dapat memilih untuk berhenti mengirim data berikutnya atau memilih untuk melanjutkan pengiriman. Yang pertama akan menyebabkan pemblokiran data, dan yang terakhir akan menyebabkan hilangnya data yang seharusnya dikirim ke Pialang.
- Jika Producer menggunakan mode asynchronous, Producer akan mencoba mengirim ulang message.send.max.retries (nilai default-nya adalah 3) kali dan kemudian mencatat pengecualian dan terus mengirim data berikutnya. Hal ini akan menyebabkan kehilangan data dan pengguna hanya dapat menemukan masalah melalui log .
Dapat dilihat bahwa tanpa Replikasi, setelah mesin mati atau Broker berhenti bekerja, ketersediaan seluruh sistem akan berkurang. Dengan meningkatnya skala cluster, kemungkinan anomali seperti di seluruh cluster meningkat pesat, Oleh karena itu, pengenalan mekanisme Replikasi sangat penting untuk sistem produksi.
Mengapa Anda membutuhkan Pemilihan Pemimpin
(Pemilihan Pemimpin yang disebutkan dalam artikel ini terutama mengacu pada (Pemilihan Pemimpin) di antara Replika
Setelah pengenalan Replikasi, Partisi yang sama dapat memiliki beberapa replika. Pada saat ini, pemimpin perlu dipilih di antara Replikasi ini. Produsen dan Konsumen hanya berinteraksi dengan pemimpin ini, dan replika lainnya bertindak sebagai pengikut untuk mereplikasi data dari pemimpin.
Karena diperlukan untuk memastikan konsistensi data antara beberapa Replika dari Partisi yang sama (setelah salah satu Replika turun, Replika lainnya harus dapat terus ditayangkan dan tidak menyebabkan duplikasi data atau kehilangan data). Jika tidak ada pemimpin, semua Replika dapat membaca / menulis data pada saat yang sama, maka perlu untuk memastikan bahwa beberapa Replika menyinkronkan data satu sama lain (saluran N × N). Konsistensi dan urutan data sangat sulit untuk dipastikan, yang sangat meningkat Kompleksitas implementasi Replikasi juga meningkatkan kemungkinan pengecualian. Setelah pengenalan pemimpin, hanya pemimpin yang bertanggung jawab untuk membaca dan menulis data, dan pengikut hanya mengambil data secara berurutan (N saluran) ke pemimpin, sistem ini lebih sederhana dan lebih efisien.
Cara mendistribusikan Replika secara merata ke seluruh cluster
Untuk keseimbangan beban yang lebih baik, Kafka mencoba mendistribusikan semua partisi secara merata ke seluruh cluster. Metode penyebaran tipikal adalah bahwa jumlah Partisi suatu topik lebih besar dari jumlah Broker. Pada saat yang sama, untuk meningkatkan toleransi kesalahan Kafka, juga perlu mendistribusikan replika Partisi yang sama ke mesin yang berbeda sebanyak mungkin. Faktanya, jika semua Replika berada di Pialang yang sama, setelah Pialang mati, semua Replika Partisi tidak akan berfungsi, dan efek HA tidak akan tercapai. Pada saat yang sama, jika Pialang turun, Anda perlu memastikan bahwa beban di atasnya dapat didistribusikan secara merata ke semua Pialang lain yang masih hidup.
Kafka mengalokasikan algoritma Replica sebagai berikut:
- Urutkan semua Broker (dengan asumsi total n Broker) dan Partisi yang akan dialokasikan
- Tetapkan Partisi ke-i ke Broker ke-(i mod n)
- Tetapkan Replika ke-j dari Partisi ke-i ke ((i + j) mode n) Pialang
Replikasi Data
Replikasi Data Kafka perlu menyelesaikan masalah berikut:
- Bagaimana Menyebarkan Pesan
- Sebelum mengirim ACK ke Produser, perlu dipastikan berapa banyak Replika yang telah menerima pesan tersebut
- Cara menangani situasi di mana Replika tidak berfungsi
- Bagaimana menangani pemulihan Replika Gagal
Sebarkan berita
Ketika Produser menerbitkan pesan ke Partisi, pertama-tama Produser menemukan Pemimpin Partisi melalui Zookeeper, dan kemudian terlepas dari Faktor Replikasi dari Topik (yaitu, berapa banyak replika yang ada di Partisi), Produser hanya mengirim pesan tersebut ke Leader of the Partition . Pemimpin akan menulis pesan ke Log lokalnya. Setiap pengikut menarik data dari pemimpin. Dengan cara ini, urutan data yang disimpan oleh Follower konsisten dengan Leader. Setelah Follower menerima pesan dan menulis Log-nya, ia mengirimkan ACK ke Leader. Setelah Leader menerima ACK dari semua Replika di ISR, pesan tersebut dianggap telah dilakukan, dan Leader akan meningkatkan HW dan mengirimkan ACK ke Produser.
Untuk meningkatkan kinerja, setiap pengikut mengirimkan ACK ke Pemimpin segera setelah menerima data, alih-alih menunggu data untuk ditulis ke dalam Log. Oleh karena itu, untuk pesan yang telah dikomit, Kafka hanya dapat menjamin bahwa ia disimpan dalam memori beberapa Replika, tetapi tidak dapat menjamin bahwa mereka disimpan ke disk, dan tidak dapat sepenuhnya menjamin bahwa pesan tersebut akan dikonsumsi oleh Konsumen setelah pengecualian terjadi. . Tetapi mengingat skenario semacam ini sangat jarang, dapat dianggap bahwa pendekatan ini telah membuat keseimbangan yang lebih baik antara kinerja dan persistensi data. Di versi mendatang, Kafka akan mempertimbangkan untuk memberikan daya tahan yang lebih tinggi.
Pesan pembacaan konsumen juga dibaca dari Leader, dan hanya pesan yang telah dilakukan (pesan dengan offset lebih rendah dari HW) yang akan ditampilkan ke Konsumen. Alur data Replikasi Kafka ditunjukkan pada gambar di bawah ini
Berapa banyak cadangan yang perlu dijamin sebelum ACK
Seperti kebanyakan sistem terdistribusi, kegagalan pemrosesan Kafka memerlukan definisi yang jelas tentang apakah Broker "hidup". Bagi Kafka, survival Kafka mencakup dua syarat, yaitu harus mempertahankan sesi dengan Zookeeper (ini dicapai melalui mekanisme Zookeeper Heartbeat). Kedua, Follower harus bisa menyalin pesan Leader tepat waktu, dan tidak "terlalu ketinggalan".
Pemimpin akan melacak daftar Replika yang tetap sinkron. Daftar ini disebut ISR (yaitu, Replika tersinkronisasi). Jika pengikut turun, atau ketinggalan terlalu banyak, pemimpin akan menghapusnya dari ISR. "Terlalu banyak di belakang" yang dijelaskan di sini berarti bahwa jumlah pesan yang direplikasi oleh Pengikut yang tertinggal di belakang pemimpin melebihi nilai yang telah ditentukan (nilai ini dapat dikonfigurasi melalui replica.lag.max.messages di $ KAFKA_HOME / config / server.properties, dan defaultnya Nilainya 4000) atau Follower telah melampaui jangka waktu tertentu (nilai ini dapat dikonfigurasi melalui replica.lag.time.max.ms di $ KAFKA_HOME / config / server.properties, dan nilai defaultnya adalah 10000) belum mengirimkan permintaan pengambilan ke Leader. .
Mekanisme replikasi Kafka bukanlah replikasi yang sepenuhnya sinkron atau replikasi asinkron murni. Faktanya, replikasi sinkron mensyaratkan bahwa semua pengikut yang bekerja telah direplikasi sebelum pesan ini dianggap komit. Metode replikasi ini sangat mempengaruhi tingkat throughput (tingkat throughput yang tinggi adalah fitur yang sangat penting dari Kafka). Dalam mode replikasi asynchronous, Follower mereplikasi data dari Leader secara asynchronous. Selama data ditulis ke log oleh Leader, itu dianggap telah dilakukan. Dalam hal ini, jika salinan pengikut semuanya tertinggal di belakang Pemimpin, dan jika pemimpin tiba-tiba turun, Data hilang. Cara Kafka menggunakan ISR adalah keseimbangan yang baik untuk memastikan data tidak hilang dan throughput. Follower dapat menyalin data dari Leader dalam batch, yang secara signifikan meningkatkan performa replikasi (tulis ke disk dalam batch) dan sangat mengurangi kesenjangan antara Follower dan Leader.
Perlu dicatat bahwa Kafka hanya menyelesaikan kegagalan / pemulihan, dan tidak menangani masalah "Bizantium" ("Bizantium"). Sebuah pesan akan dianggap terkirim hanya jika telah disalin dari Leader oleh semua pengikut di ISR. Hal ini untuk menghindari bagian data tersebut ditulis ke dalam Leader, dan itu crash sebelum disalin oleh Follower mana pun, menyebabkan kehilangan data (Konsumen tidak dapat menggunakan data tersebut). Sedangkan untuk Produser, ia bisa memilih apakah akan menunggu komit pesan, yang bisa disetel oleh request.required.acks. Mekanisme ini memastikan bahwa selama ISR memiliki satu atau lebih pengikut, pesan yang berkomitmen tidak akan hilang.
Algoritma Pemilihan Pemimpin
Di atas menjelaskan bagaimana Kafka melakukan Replikasi Pertanyaan lain yang sangat penting adalah bagaimana memilih pemimpin baru dari pengikut ketika pemimpin itu turun. Karena follower mungkin tertinggal atau crash, Anda harus memastikan untuk memilih follower "terbaru" sebagai leader baru. Prinsip dasarnya adalah jika pemimpin pergi, pemimpin baru harus memiliki semua pesan yang dilakukan oleh pemimpin asli. Ini membutuhkan kompromi. Jika pemimpin menunggu lebih banyak pengikut untuk mengonfirmasi sebelum menandai pesan sebagai berkomitmen, akan ada lebih banyak pengikut yang dapat digunakan sebagai pemimpin baru setelah turun, tetapi ini juga akan menyebabkan penurunan throughput .
Metode Pemilihan Pemimpin yang sangat umum digunakan adalah "Suara Mayoritas" ("minoritas mematuhi mayoritas"), tetapi Kafka tidak mengadopsi metode ini. Dalam mode ini, jika kita memiliki 2f + 1 Replika (termasuk Leader dan Follower), kita harus memastikan bahwa f + 1 Replica telah mereplikasi pesan sebelum dilakukan. Untuk memastikan Leader baru dipilih dengan benar, Replika yang gagal tidak boleh melebihi f. Karena di setiap Replika f + 1 yang tersisa, setidaknya satu Replika berisi semua pesan terbaru. Metode ini memiliki keuntungan besar, latensi sistem hanya bergantung pada broker tercepat, bukan yang paling lambat. Suara Mayoritas juga memiliki beberapa kelemahan.Untuk memastikan kemajuan normal dari Pemilihan Pemimpin, jumlah pengikut yang gagal yang dapat ditoleransi relatif kecil. Jika Anda ingin mentolerir kegagalan satu pengikut, Anda harus memiliki lebih dari 3 replika, dan jika Anda ingin mentolerir kegagalan 2 pengikut, Anda harus memiliki lebih dari 5 replika. Dengan kata lain, untuk memastikan tingkat toleransi kesalahan yang tinggi dalam lingkungan produksi, sejumlah besar Replika harus tersedia, dan sejumlah besar Replika akan menyebabkan penurunan tajam dalam kinerja pada sejumlah besar data. Inilah sebabnya mengapa algoritma ini lebih banyak digunakan dalam sistem konfigurasi klaster bersama seperti Zookeeper dan jarang digunakan dalam sistem yang perlu menyimpan data dalam jumlah besar. Misalnya, Fitur HA dari HDFS didasarkan pada jurnal berbasis suara mayoritas, tetapi penyimpanan datanya tidak menggunakan metode ini.
Sebenarnya, ada banyak algoritma Leader Election, seperti Zookeeper's Zab, Raft dan Viewstamped Replication. Algoritme Pemilihan Pemimpin yang digunakan oleh Kafka lebih mirip dengan algoritme PacificA Microsoft.
Kafka secara dinamis mempertahankan ISR (replika selaras) di Zookeeper. Semua Replika di ISR ini telah mengikuti pemimpin, dan hanya anggota di ISR yang dapat dipilih sebagai Pemimpin. Dalam mode ini, untuk Replika f + 1, Partisi dapat mentolerir kegagalan Replika f tanpa kehilangan pesan yang dikomit. Dalam kebanyakan skenario penggunaan, mode ini sangat menguntungkan. Faktanya, untuk mentolerir kegagalan Replicas f, Majority Vote dan ISR perlu menunggu jumlah Replika yang sama sebelum dilakukan, tetapi jumlah Replicas yang dibutuhkan oleh ISR hampir setengah dari Suara Mayoritas.
Meskipun Majority Vote memiliki keuntungan karena tidak harus menunggu Broker yang paling lambat dibandingkan dengan ISR, penulis Kafka percaya bahwa Kafka dapat memperbaiki masalah ini dengan memilih apakah produsen diblokir oleh commit, dan Replica dan disk yang disimpan membuat mode ISR tetap bermanfaat .
Cara menangani semua replika yang tidak berfungsi
Seperti yang telah disebutkan di atas, ketika setidaknya ada satu pengikut di ISR, Kafka dapat memastikan bahwa data yang telah dilakukan tidak hilang, tetapi jika semua Replika Partisi tidak berfungsi, tidak ada jaminan bahwa data tersebut tidak akan hilang. Dalam kasus ini, ada dua kemungkinan solusi:
- Tunggu Replika apa pun di ISR untuk "hidup" dan pilih sebagai pemimpin
- Pilih Replika "langsung" pertama (tidak harus di ISR) sebagai pemimpin
Ini membutuhkan kompromi sederhana antara kegunaan dan konsistensi. Jika Anda harus menunggu Replika di ISR untuk "hidup", waktu tidak tersedia mungkin relatif lama. Dan jika semua Replika di ISR tidak dapat "hidup" atau datanya hilang, Partisi ini tidak akan pernah tersedia. Pilih Replika "langsung" pertama sebagai Pemimpin, dan Replika ini bukan Replika di ISR. Meskipun tidak menjamin bahwa replika tersebut berisi semua pesan yang berkomitmen, Replika akan menjadi Leader dan berfungsi sebagai sumber data konsumen (sebelumnya Ada instruksi, semua membaca dan menulis dilakukan oleh Leader). Kafka0.8. * Menggunakan metode kedua. Menurut dokumentasi Kafka, dalam versi yang akan datang, Kafka mendukung pengguna untuk memilih salah satu dari dua metode ini melalui konfigurasi, sehingga dapat memilih ketersediaan tinggi atau konsistensi yang kuat sesuai dengan skenario penggunaan yang berbeda.
Bagaimana memilih seorang pemimpin
Solusi paling sederhana dan paling intuitif adalah dengan mengatur Watch di Zookeeper untuk semua pengikut. Setelah pemimpin turun, znode sementara yang sesuai akan dihapus secara otomatis. Pada saat ini, semua pengikut mencoba membuat simpul, dan yang berhasil (Penjaga Zookeeper hanya menjamin Satu dapat dibuat dengan sukses) adalah pemimpin baru, dan replika lainnya adalah pengikut.
Tetapi metode ini memiliki 3 masalah:
- split-brain Hal ini disebabkan oleh karakteristik Zookeeper. Meskipun Zookeeper dapat memastikan bahwa semua Jam Tangan diaktifkan secara berurutan, hal ini tidak menjamin bahwa semua Replika "melihat" status yang sama pada saat yang sama, yang dapat menyebabkan respons yang tidak konsisten dari Replika yang berbeda.
- efek kelompok Jika ada lebih banyak Partisi pada Pialang yang down, beberapa Jam tangan akan terpicu, menyebabkan banyak penyesuaian di klaster
- Zookeeper kelebihan beban. Setiap Replika perlu mendaftarkan Watch di Zookeeper untuk tujuan ini. Zookeeper akan kelebihan beban saat ukuran cluster meningkat menjadi beberapa ribu partisi.
Solusi Pemilihan Pemimpin Kafka 0.8. * Memecahkan masalah di atas. Ini memilih pengontrol dari semua broker, dan pemilihan pemimpin dari semua partisi ditentukan oleh pengontrol. Pengontrol akan langsung memberi tahu Broker yang perlu menanggapi perubahan Leader melalui metode RPC (lebih efisien daripada metode Zookeeper Queue). Pada saat yang sama, pengontrol juga bertanggung jawab atas penambahan dan penghapusan Topik dan realokasi Replika.
Struktur Penjaga Zookeeper terkait HA
(Dalam struktur Zookeeper yang diperlihatkan di bagian ini, kotak garis penuh menunjukkan bahwa nama jalur sudah diperbaiki, dan kotak garis putus-putus menunjukkan bahwa nama jalur terkait dengan bisnis)
admin (Znode dalam direktori ini hanya akan ada bila ada operasi terkait, dan akan dihapus di akhir operasi)
/ admin / prefer_replica_election struktur data
/ Admin / reassign_partitions digunakan untuk menetapkan beberapa Partisi ke kumpulan broker yang berbeda. Untuk setiap Partisi yang akan dipindahkan, Kafka akan menyimpan semua Replika dan ID Broker yang sesuai di znode. Znode dibuat oleh proses manajemen dan akan secara otomatis dihapus setelah realokasi berhasil. Struktur datanya adalah sebagai berikut
/ admin / delete_topics struktur data
broker
Pialang (mis. / Pialang / id /) menyimpan informasi pialang "hidup". Struktur datanya adalah sebagai berikut
Informasi registrasi topik (/ broker / topik /), yang menyimpan id Broker di mana semua Replika dari semua Partisi topik berada. Replika pertama adalah Replika Pilihan. Untuk Partisi tertentu, paling banyak hanya ada satu di Broker yang sama Replica, sehingga Broker id dapat digunakan sebagai Replica id. Struktur datanya adalah sebagai berikut
status partisi (/ brokers / topik // partisi // negara) Strukturnya adalah sebagai berikut
pengontrol
/ controller- > int (id perantara pengontrol) menyimpan informasi pengontrol saat ini
/ controller_epoch- > int (epoch) secara langsung menyimpan epoch pengontrol sebagai integer, daripada menyimpannya sebagai string JSON seperti znode lainnya.
Pengantar proses failover Broker
- Pada Pertemuan Pembacaan dan Editor Musim Gugur Nanjing, orang-orang besar di surat kabar komputer memanggil Anda untuk "menghadapi basis"!
- Xiaomi Mix2 akhirnya mengantarkan pembaruan versi stabil, dan juga mendukung aplikasi buka kunci wajah