Rutekan request

Pertanyaan

Dari mana klien atau router tahu node mana yang memegang sebuah key, dan apa yang terjadi kalau pengetahuan itu sudah usang?

Setelah baca ini, kamu bisa membandingkan empat cara perutean, menjelaskan alur request ke pemilik yang salah, dan memilih mekanisme sesuai seberapa sering kepemilikan berubah.

Prasyarat dan contoh

Kamu sudah paham partition key (M07.01), hash ring (M07.02), dan ketimpangan beban (M07.03).

Cluster punya 64 partisi di 8 node. Aplikasi menerima GET user:8841. Siapa yang menjawab "partisi 17 di node-c"? Kalau jawabannya dihitung di setiap klien, setiap klien harus punya daftar node yang sama. Kalau ada layanan metadata, setiap request membayar satu hop tambahan, atau klien menyimpan jawabannya, dan jawaban tersimpan bisa basi.

Perutean kelihatan sepele sampai kepemilikan berubah. Saat itulah empat pendekatan berikut berbeda.

Mekanisme

1. Penempatan hasil perhitungan. Klien menghitung partisi = hash(key) mod 64 atau mencari di ring, memakai daftar node yang dibagikan. Keuntungan: nol hop ekstra, nol layanan tambahan. Kerugian: daftar node harus sama di semua klien. Kalau berubah, rilis atau konfigurasi harus menyebar ke semua klien.

2. Peta partisi. Satu tabel eksplisit: partisi 0..63 -> node. Karena eksplisit, kamu bisa memindahkan satu partisi tanpa mengubah rumus, dan memberi partisi panas node khusus. Tabelnya kecil (64 entri), tapi harus disimpan di suatu tempat dan diberi nomor versi (epoch).

3. Cache perutean. Klien atau proxy menyimpan salinan peta, lalu mengirim request langsung ke node yang dianggap pemilik. Kalau peta basi, node yang salah menjawab NOT_OWNER beserta epoch terbaru atau petunjuk pemilik baru. Klien memperbarui cache dan mengulang. Jalur normal hemat, jalur salah menambah satu round trip.

4. Layanan metadata. Layanan terpisah (atau cluster kecil yang direplikasi) memegang peta resmi dan mengelola perubahannya. Klien bertanya sekali lalu meng-cache. Ini titik kendali kepemilikan yang bersih, tapi menjadi komponen yang harus tersedia saat peta berubah.

Aturan penting: node penerima selalu memeriksa kepemilikan sendiri. Jangan percaya klien. Dengan pemeriksaan ini, peta basi di klien hanya menimbulkan satu redirect, bukan penulisan ke tempat yang salah.

klien (epoch 7) -> node-a: PUT user:8841
node-a (epoch 9): bukan pemilik, pemilik node-c
node-a -> klien: NOT_OWNER { epoch: 9, owner: node-c }
klien: perbarui cache ke epoch 9, ulang ke node-c

Ukuran biaya: dengan 20.000 request per detik, tambahan satu hop 1 ms ke layanan metadata di setiap request menambah 1 ms ke latensi semua request dan 20.000 rps beban ke layanan itu. Dengan cache yang hit 99,9%, sisanya 20 rps. Itu alasan cache perutean hampir selalu dipakai bersama layanan metadata.

Saat rancangan ini gagal

• Peta basi tanpa pemeriksaan di node. Klien lama menulis ke pemilik lama setelah partisi berpindah, dan penulisan itu hilang atau menghasilkan dua salinan yang berbeda. Pemeriksaan epoch di node mencegahnya.
• Badai refresh. Satu perubahan peta membuat 5.000 klien serentak meminta peta baru ke layanan metadata. Beri jitter atau kembalikan peta di dalam respons NOT_OWNER.
• Layanan metadata mati. Jalur normal tetap jalan dengan cache, tapi nggak ada perubahan kepemilikan atau node baru yang bisa diproses. Putuskan apakah partisi boleh dilayani dengan peta terakhir selama layanan mati.
• Redirect berantai. Selama perpindahan, partisi bergeser dua kali dan klien terlempar bolak-balik. Batasi jumlah ulang, dan tampilkan error yang jelas.
• Dua pandangan resmi. Dua sumber peta (konfigurasi statis dan layanan) berbeda pendapat. Tentukan satu sumber kebenaran.

Latihan

Cluster 8 node, 64 partisi, 20.000 rps. Klien meng-cache peta partisi (epoch 7). Admin memindahkan partisi 17 dari node-c ke node-f, epoch menjadi 8. Partisi 17 menerima 300 rps. Ada 400 instans klien.

1. Apa yang terjadi pada request ke partisi 17 dari klien epoch 7?
2. Berapa request ekstra pada skenario terburuk dalam satu detik setelah cutover, kalau tiap klien baru tahu dari redirect pertamanya?
3. Apa yang terjadi kalau node-c nggak memeriksa kepemilikan?

Lihat pembahasan+

1. Klien mengirim ke node-c. Node-c (epoch 8) tahu bahwa ia bukan pemilik lagi dan menjawab NOT_OWNER { epoch: 8, owner: node-f }. Klien memperbarui cache lalu mengulang ke node-f. Total dua round trip untuk request itu.
2. Paling banyak sebanyak request yang tiba sebelum tiap klien menerima redirect pertamanya. Dengan 300 rps ke partisi 17 yang tersebar di 400 klien, setiap klien rata-rata mengirim kurang dari 1 request per detik, sehingga hampir semua dari 300 request itu bisa menjadi redirect: sekitar 300 request ekstra dan 300 round trip tambahan di detik itu. Setelah itu tiap klien yang sudah diperbarui langsung ke node-f. Batas atasnya 300, bukan 20.000, karena hanya satu partisi yang pindah.
3. Node-c menerima penulisan untuk data yang sudah bukan miliknya. Kalau datanya sudah disalin ke node-f, penulisan itu hilang secara diam-diam dari sudut pandang pemilik baru. Itulah alasan pemeriksaan epoch di sisi node wajib.

Terkait

• Sebelumnya: M07.03 Bedakan pemerataan key dari pemerataan beban.
• Lanjut ke M07.05 Pindahkan data dengan aman, tempat epoch dan fencing dipakai saat cutover.
• Penyebaran peta lewat layanan koordinasi dibahas di M08 (replikasi, waktu, dan koordinasi), yang belum tersedia sebagai lesson. Lab L07 dan proyek B04 belum tersedia.

Catatan

• Asumsi: setiap node bisa memeriksa kepemilikan lokal dari peta yang ia terima, dan epoch bertambah monoton.
• Yang nggak dibahas: cara layanan metadata sendiri direplikasi dan dipilih pemimpinnya (M08), serta load balancer layer 7 (M02).
• Nama pesan seperti NOT_OWNER hanya ilustrasi. Produk nyata memakai nama dan mekanisme sendiri (redirect, kode error, atau proxy).
• Terakhir ditinjau: 26 Oktober 2026.