What are Actors in Akka?
Akka is a toolkit to build scalable, resilient systems. The building blocks are Actors, on top of which Akka builds lots of abstractions ready for us to use. One such abstraction is the clustering functionality.
Actors are entities that communicate with each other via messages, just as much as you and I communicate by asking things and answering. If you’re curious about my age, there is no way to plug into my body and perform something such as
int age = fabio.getAge();
What you will do instead is sending me a message (either via voice, or via written form), asking:
What is your age?
, to which I will reply:
22
Actors communicate in the exact same way. This separation enables a great deal of benefits, one of which is location transparency. Think about sending me an email: you don’t need to know where I physically am, as long as you know my email address. I might be in New York or in Tokyo, but you would still be able to ask my age and I would be able to reply.
Enter Akka Cluster
The very same thing holds for Actors: as long as you know their address, you can get in touch with them. This functionality is called remoting: an actor can communicate with another one even if it resides on a different node/machine, as long as the recipient’s address is known. On top of this, Akka builds the clustering functionalities: an abstraction that lets you be in control of your cluster of nodes, getting notified when someone joins or leaves the party. It is very simple to establish a cluster and we’re going to show it with a simple yet fascinating example.
Our goal is to create a unique Master node that will distribute messages to any Worker actor that joins.
After importing the correct dependency, which at the moment of writing is
"com.typesafe.akka" %% "akka-cluster-tools" % "2.5.6"
, the first thing to do is configuring your system. For this, check the official documentation.
Akka comes with another very useful feature: the ability for a node to create actors on other nodes. We will use it together with the abaility to route messages to all the created actors in a round-robin fashion. This is extremely useful in many situations where you can distribute work across nodes.
The worker actor is very simple: it will simply log anything that comes in.
class Worker extends Actor {
override def receive = {
case s: String => println(s)
}
}
Now on to the master actor. As soon as the master starts, it will subscribe to cluster events to be notified when a new node joins (or leaves). This is achieved with
Cluster(context.system).subscribe(self, classOf[ClusterDomainEvent])
The master actor will also keep track of the current amount of connected nodes in a variable called workerCounter. This is used to create the round-robin router I mentioned earlier. The code to create such a router is
val router = context.actorOf(
ClusterRouterPool(
RoundRobinPool(workerCounter),
ClusterRouterPoolSettings(
totalInstances = 1000,
maxInstancesPerNode = 1,
allowLocalRoutees = false
)
).props(Props[Worker]),
name = "worker-router"))
At this point the master node will send messages to the router, which in turn will distribute them on the Worker actors created on the remote nodes. This is the receive method of the master:
override def receive: {
case s: String => router ! s
}
The actual implementation is a little more complex, but this is the essence of the whole thing! Check out the code on github and test it on your machine. Create first the master node at port 2551 using:
sbt run
And then create one or more workers specifying a different port and the “worker” role like this:
sbt -DPORT=2552 -DROLES.1="worker" run
Add more workers as pleased, then relax and check the magic happening!
All Tags |
The Netherlands |
61
|
amsterdam |
35
|
bicycle |
21
|
Chile |
18
|
Valparaiso |
15
|
Australia |
13
|
Art |
12
|
nepal |
8
|
scala |
8
|
akka |
6
|
Santiago |
5
|
community |
4
|
France |
4
|
Gouda |
4
|
Paris |
4
|
akka-stream |
3
|
akka-streams |
3
|
dashain |
3
|
everest trek |
3
|
india |
3
|
Italy |
3
|
Melbourne |
3
|
Perth |
3
|
Road trip |
3
|
Rotterdam |
3
|
akka-http |
2
|
Argentina |
2
|
bicycle touring |
2
|
code |
2
|
custom_image |
2
|
custom_summary |
2
|
Delft |
2
|
event-sourcing |
2
|
Geraldton |
2
|
Haarlem |
2
|
leaf_bundle |
2
|
Lille |
2
|
Milan |
2
|
New Delhi |
2
|
New York |
2
|
Punta Arenas |
2
|
Rome |
2
|
Ushuaia |
2
|
Websocket |
2
|
Abcoude |
1
|
akka-cluster |
1
|
amazon web services |
1
|
android |
1
|
aws |
1
|
Berlin |
1
|
Bloemendaal |
1
|
Brisbane |
1
|
chitwan |
1
|
Circus Maximum |
1
|
covid19 |
1
|
deep learning |
1
|
distributed systems |
1
|
Enkhuizen |
1
|
Esperance |
1
|
expats |
1
|
fans club |
1
|
Fraser Island |
1
|
gps |
1
|
gpx |
1
|
guitars |
1
|
iot |
1
|
Isla Negra |
1
|
japan |
1
|
java |
1
|
Kalgoorlie |
1
|
kathmandu |
1
|
Las Vegas |
1
|
litfiba |
1
|
LoPy |
1
|
lora |
1
|
Markem |
1
|
Matisse |
1
|
Mexico |
1
|
Middelburg |
1
|
misc |
1
|
Muiden |
1
|
neural networks |
1
|
planning |
1
|
play |
1
|
reactive |
1
|
reactjs |
1
|
refluxjs |
1
|
Reims |
1
|
San Francisco |
1
|
Sodaq |
1
|
Sydney |
1
|
Texel |
1
|
Theo Van Doesburg |
1
|
tokyo |
1
|
Travel |
1
|
tulips |
1
|
USA |
1
|
webjars |
1
|
Weesp |
1
|