Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Transcript of Akka.io introduction
Akka for the rescue
WHERE IS AKKA USED?
It is way too hard to build:
1. correct highly concurrent systems
2. truly scalable systems
3. fault-tolerant systems that self-heals
Manage system overload
Scale up & Scale out
Replicate and distribute for fault-tolerance
Transparent load balancing
• Stock trend Analysis & Simulation
• Event-driven messaging systems
BETTING & GAMING
• Massive multiplayer online gaming
• High throughput and transactional betting
• Streaming media network gateways
• 3D simulation engines
• Social media community sit
Actors: Mathematical model for concurrency
Actors are similar in to OO classes (pojo) they contain both state (data) & behavior (functions)
Actors are build for concurrency - actors share nothing nor can they peek into each other
- they are isolated units
communicate by talking (receiving & deliveringActors messages via mailbox),
Actors can do only one thing at a time
Actors are reactive (event driven) - most of time they are suspended
Concurrency through messaging
Threads are expensive - Actors are cheap
The dispatcher sends the message to the actor and the actor processes it on whatever thread it was put on to do the work.
Thread model is completely decouples from actors
Actors are very lightweigt 300 bytes per instance & very easy - fast to start/stop
- ~2.5 million actors per GB of heap.
“Actors do one thing at a time, they do it very well, and then they quickly move on.”
With futures, our goal is to run functions concurrently with other functions and rendezvous on the results of those functions if we need to.
Data structure used to retrieve the result of some concurrent operation.
Can be accessed synchronously (blocking) or asynchronously (non-blocking)
is very similar to a java.util.concurrent.Executor
Jonas Bonér -
CTO @ Typesafe full stack scala solution
Akka is a toolbox
STM & Agents
Let it crash - fault-tolerance
Classification of State
• Static data
• Supplied at boot time / Supplied by other components
• Dynamic data
• Data possible to recompute
• Input from other sources; data that is impossible to recompute
OO Critically important state & explicit error handling
Each actor supervisor of its children
Each actor defines fault handling supervisor strategy
Supervisor delegates tasks to subordinates & therefore must respond to their failures.
Fault tolerance supervisor behavior:
* Resume the subordinate,
keeping its accumulated internal state
* Restart the subordinate,
clearing its accumulated internal state
* Terminate the subordinate permanently
* Escalate the failure, thereby failing itself
An actor system is a hierarchical group of actors which share common configuration, e.g.
create pipelines of concurrent code that can weave into other code with ease
What Lifecycle Monitoring Means:
Each actor may monitor any other actor
Since actors regeneration is invisible to its supervisor, Monitoring is used to tie one actor to another so that it may react to the other actor’s termination, in contrast to supervision which reacts to failure.
Monitoring is particularly useful if a supervisor cannot simply restart its children and has to terminate them - in case of errors during actor initialization
Routing Messages - for scaling wide...
A Router is an actor that receives messages and efficiently routes them to other actors, known as its routees
Different routing strategies
RoundRobinRouter RandomRouter SmallestMailboxRouter BroadcastRouter ScatterGatherFirstCompletedRouter
All MessageDispatcher implementations are also an ExecutionContext
Every ActorSystem will have a default dispatcher
Dispatchers - for scaling up...
Types of dispatchers
This is an event-based dispatcher that binds a set of Actors to a thread pool
This dispatcher dedicates a unique thread for each actor using it; i.e. each actor will have its own thread pool with only one thread in the pool.
This is an executor based event driven dispatcher that will try to redistribute work from busy actors to idle actors.
CallingThreadDispatcherThis dispatcher runs invocations on the current thread only.
support sending messages to the actor it represents.
Different types of actor references:
• Purely local
• Local actor (can also be accessed to other nodes)
• Remote actor - represent actors which are reachable only using remote communication
Local ActorRefs deliver messages to a MessageDispatcher running in the same JVM.
Remote ActorRefs send messages to a MessageDispatcher running on a different machine.
This proxy/stub model is key to distributed computing;
Akk exploits it to gain horizontal scalability without requiring your application to change beyond its Akka configuration.
Akka's Actors Key features
glue that wires Actors, ActorRefs, MessageDispatchers, and Mailboxes together
addressable location - proxy for Actors
main responsibility is to run Mailboxes. When an ActorRef receives a message, it dispatches it to the MessageDispatcher, which puts that message in the message queue for the destination Mailbox.
Every Actor has its own mailbox. When the mailbox receives a slice of time to run, it takes a message from the message queue and invokes the Actor with the message
When the MessageDispatcher receives a message from the ActorRef, it delivers that message to the mailbox's Message Queue, where it sits until the mailbox receives CPU cycles to run.
provides a receive method, which is invoked by the mailbox when it has a message to process