Introduction to the Actor model
The key for concurrency programming is to avoid a shared mutable state. A shared state often requires locks and synchronization, which makes your code less concurrent and more complex. Actors share nothing; they have internal state, but they don't share their internal state.
Actors have location transparency; they can run in a local or remote system and a cluster. It's also possible to mix local and remote actors - this is great for scalability and fits perfectly into a cloud environment. Actors can run anywhere, from your local box, the cloud, bare-metal datacenter, and Linux containers.
What is an Actor?
Actors can be alternatives to threads, callback listeners, singleton services, Enterprise Java Beans (EJB), routers, load balancer or pool, and a finite-state machine (FSM). The Actor model concept is not new at all; it was created by Carl Hewitt in 1973. The Actor model is heavily used in the telecom industry in rock-solid technologies such as Erlang. Erlang and the Actor model had immense success with companies such as Ericsson and Facebook.
Actors have a simple way of working:
- • Unit of code organization:
- • Processing
- • Storage
- • Communication
- • They manage the internal states
- • They have a mailbox
- • They communicate with other actors using messages
- • They can change the behavior at runtime