Pahami konsensus

Pertanyaan

Bagaimana sekelompok node yang bisa mati dan terputus tetap sepakat pada satu urutan perubahan, dan kapan mereka berhenti menerima perubahan?

Setelah baca ini, kamu bisa menelusuri pemilihan leader dan replikasi log di Raft pada klaster kecil, menyebut aturan commit, dan menjelaskan apa yang terjadi saat quorum hilang.

Prasyarat dan contoh

Kamu sudah paham replikasi leader/follower (M08.01), jaminan linearizability (M08.02), dan pilihan C saat partisi (M08.03).

Tiga node menyimpan konfigurasi: A, B, C. A leader. Klien menulis maks_koneksi=500. A sudah menyimpannya, tapi sebelum mengirim ke B dan C, A mati. B dan C mengangkat leader baru tanpa tulisan itu. Klien sempat menerima "OK"? Kalau protokol benar, tidak: A belum meng-commit, jadi tidak pernah membalas sukses. Konsensus adalah aturan yang menjamin bahwa "OK" hanya diberikan untuk perubahan yang tidak akan hilang walau leader berganti.

Mekanisme

Raft (dipakai misalnya di etcd dan Consul) memecah konsensus jadi tiga bagian. Kita bahas versi konseptualnya.

Term. Penomoran masa kepemimpinan: term 1, 2, 3, dan seterusnya. Tiap term punya paling banyak satu leader. Pesan dengan term lebih kecil diabaikan. Term berfungsi sebagai jam logis (M08.04) untuk kepemimpinan.

Pemilihan leader. Follower yang tidak mendengar heartbeat leader selama timeout acak (misalnya 150-300 ms) menjadi kandidat: naikkan term, pilih diri sendiri, minta suara ke yang lain. Tiap node memberi satu suara per term. Kandidat yang mendapat suara mayoritas (2 dari 3, 3 dari 5) menjadi leader. Timeout acak mengurangi peluang dua kandidat bersaing terus-menerus. Satu aturan penting: node hanya memilih kandidat yang lognya minimal sama mutakhir dengan lognya sendiri, jadi leader baru selalu punya semua entri yang sudah di-commit.

Replikasi log. Klien mengirim perintah ke leader. Leader menambahkan sebagai entri baru di log (nomor indeks, term, perintah), mengirim ke follower, dan follower menambahkannya jika lognya cocok dengan entri sebelumnya. Kalau tidak cocok, leader mundur dan mengirim ulang sampai follower selaras.

indeks:   1    2    3    4
A (L):  [t1] [t1] [t2] [t2]   <- leader term 2
B:      [t1] [t1] [t2] [t2]
C:      [t1] [t1]             <- tertinggal, akan disusulkan

Aturan commit. Entri dianggap committed saat leader sudah menyimpannya di mayoritas node (termasuk dirinya). Baru setelah itu leader menerapkannya dan membalas klien. Pada klaster 3 node, entri 3 dan 4 di atas sudah di A dan B: 2 dari 3, jadi committed walau C tertinggal. Entri committed dijamin ada di semua leader berikutnya, karena pemilihan menuntut log yang cukup mutakhir dan dua mayoritas selalu beririsan.

Hilangnya quorum. Klaster N node butuh ⌊N/2⌋+1 node hidup dan saling terhubung. 3 node toleran 1 kegagalan, 5 node toleran 2, 7 toleran 3. Kalau mayoritas hilang, tidak ada kandidat yang bisa menang dan leader lama tidak bisa meng-commit apa pun. Sistem berhenti menerima tulisan (dan bacaan linearizable), tapi tidak salah. Itu pilihan C dari CAP. Saat partisi memisahkan 5 node jadi 3 dan 2, sisi 3 tetap jalan dan sisi 2 menolak tulisan.

Biaya. Tiap tulisan butuh satu putaran jaringan ke mayoritas, ditambah fsync di tiap node. Throughput dibatasi satu leader. Konsensus cocok untuk data kecil dan krusial: metadata, konfigurasi, pemilik partisi, lock. Bukan untuk menyimpan data ukuran besar atau beban tulis tinggi.

Saat rancangan ini gagal

• Klaster dua zona dengan jumlah node genap. 2+2 node: kalau link antarzona putus, masing-masing sisi punya 2 dari 4, tidak ada mayoritas, dan seluruh klaster berhenti. Tiga zona (misalnya 2+2+1) lebih tahan.
• Menaruh mayoritas di satu zona. Zona itu mati, klaster berhenti walau zona lain sehat.
• Disk lambat dan timeout pemilihan terlalu ketat. fsync yang memakan 400 ms membuat heartbeat telat, follower memulai pemilihan berulang, dan leader sering berganti.
• Membaca dari follower atau leader lama. Konsensus menjamin urutan tulisan. Bacaan tetap perlu melewati leader yang sudah memastikan dirinya masih leader agar linearizable.
• Mengira konsensus murah. Memakainya untuk beban tulis ribuan per detik menjadikan leader satu-satunya bottleneck.

Contoh tandingan: klaster 3 node kehilangan 2 node karena pemeliharaan dilakukan serentak. Sistem berhenti sepenuhnya walau satu node sehat, dan itu perilaku yang benar. Tanpa quorum, node tunggal tidak bisa tahu apakah dua lainnya hidup di sisi lain partisi.

Latihan

Klaster Raft 5 node: A, B, C, D, E. A leader di term 3. Partisi memisahkan {A, B} dari {C, D, E}. (1) Sisi mana yang bisa meng-commit tulisan baru? (2) Apa yang terjadi pada A? (3) Klien menulis x=1 ke A sebelum partisi terdeteksi, lalu A menyimpannya di A dan B saja. Apakah entri itu committed?

Lihat pembahasan+

(1) Sisi {C, D, E}: 3 dari 5 adalah mayoritas. Sisi {A, B} hanya 2 dari 5 dan tidak bisa meng-commit.

(2) C, D, E berhenti menerima heartbeat A, timeout, salah satunya menjadi kandidat di term 4, dan menang dengan 3 suara. A tidak tahu partisi, tetap mengira dirinya leader term 3 dan terus menerima tulisan, tapi tidak bisa meng-commit karena tidak mendapat mayoritas. Saat partisi pulih, A melihat term 4, turun jadi follower, dan membuang entri yang tidak committed.

(3) Tidak committed. x=1 hanya ada di 2 dari 5 node. Entri itu tidak boleh dibalas "OK" ke klien. Karena leader baru dipilih dari log yang mutakhir di sisi mayoritas, entri itu bisa hilang, dan itu aman karena klien tidak pernah diberi jaminan. Klien yang time-out harus bisa mengulang dengan aman (idempoten).

Jawaban yang bagus menggunakan hitungan mayoritas dan membedakan "tersimpan di beberapa node" dari "committed".

Terkait

• M08.03 Bernalar tentang partisi jaringan menunjukkan pilihan C yang dijalankan konsensus.
• M08.04 Pisahkan waktu dari kausalitas menjelaskan kenapa term memakai penghitung, bukan jam.
• M08.06 Gunakan lease dengan hati-hati membahas leader lama yang belum sadar dirinya diganti.
• M09 membahas WAL dan fsync yang dipakai tiap node untuk menyimpan log.

Catatan

• Asumsi: node bisa crash dan pulih, pesan bisa hilang atau terlambat, tidak ada node Byzantine.
• Yang tidak dibahas: perubahan keanggotaan klaster, snapshot dan kompaksi log, pre-vote, dan Paxos.
• Angka timeout adalah contoh. Sesuaikan dengan latensi jaringan dan waktu fsync.
• Terakhir ditinjau: 26 Oktober 2026.