Actor Hierarchy & Parent-Child
Penjelasan
Seluruh actor dalam satu ActorSystem membentuk struktur pohon (hierarchy), dengan satu 'guardian actor' di paling atas (root behavior yang diberikan saat membuat ActorSystem). Setiap actor yang di-spawn menjadi anak dari actor yang memanggil `context.spawn`, dan actor tersebut bisa punya anak sendiri lagi, membentuk hierarki bertingkat. Hierarki ini bukan sekadar struktur organisasi — ia menentukan dua hal penting: supervision (induk bertanggung jawab menangani kegagalan anaknya, seperti dibahas di topik sebelumnya) dan lifecycle (ketika actor induk berhenti, SELURUH actor anak di bawahnya ikut berhenti secara otomatis/cascading, tanpa perlu dihentikan manual satu-satu). Pola desain umum di Akka adalah membuat actor 'manager' atau 'supervisor' yang tugas utamanya hanya men-spawn dan mengawasi actor pekerja, bukan memproses data secara langsung — ini disebut pola supervisor hierarchy dan membuat sistem lebih mudah dipahami karena tanggung jawab tiap level jelas terpisah.
Contoh Konsep
import akka.actor.typed.Behavior
import akka.actor.typed.scaladsl.Behaviors
object Pekerja {
sealed trait Pesan
case class Kerjakan(tugas: String) extends Pesan
def apply(id: Int): Behavior[Pesan] = Behaviors.receiveMessage {
case Kerjakan(tugas) =>
println(s"Pekerja-$id mengerjakan: $tugas")
Behaviors.same
}
}
object Supervisor {
sealed trait Pesan
case class Delegasikan(tugas: String) extends Pesan
def apply(): Behavior[Pesan] = Behaviors.setup { context =>
val pekerja1 = context.spawn(Pekerja(1), "pekerja-1")
val pekerja2 = context.spawn(Pekerja(2), "pekerja-2")
Behaviors.receiveMessage {
case Delegasikan(tugas) =>
pekerja1 ! Pekerja.Kerjakan(tugas)
Behaviors.same
}
}
}
Praktikum
Lengkapi actor Departemen yang men-spawn dua actor anak Staf saat setup, dan meneruskan pesan TugaskanSemua ke kedua staf tersebut secara broadcast manual.
Ketik/edit bebas di sini untuk latihan — kode ini tidak dijalankan.
Tips
Rancang hierarki actor sesuai domain masalah, bukan sekadar struktur teknis — actor induk sebaiknya merepresentasikan unit tanggung jawab yang jelas (misal satu induk per pelanggan atau per sesi), sehingga saat satu bagian gagal, dampaknya hanya terisolasi ke cabang itu saja.