Akka use cases

Akka use cases DEFAULT

Use cases for Akka vs Kafka

It’s hard to answer this question, because it’s so broad. And it’s very much comparing apples and oranges. It’s actually quite common to have both Akka and Kafka be part of a solution.

From the websites:

Akka is a toolkit for building highly concurrent, distributed, and resilient message-driven applications for Java and Scala

So, use cases for Akka are anytime you are building an application and you have either concurrency needs, distributed computing needs, or you need to build your application around async message passing. (Note, that in this context we are talking about messages passed internally between Akka actors.) A lot of applications are distributed these days, so I think that makes Akka pretty broadly useful.

But one thing you’ll notice is that Akka is primarily about building applications.

Apache Kafka® is a distributed streaming platform . What exactly does that mean?

A streaming platform has three key capabilities:

  • Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system.
  • Store streams of records in a fault-tolerant durable way.
  • Process streams of records as they occur.

Kafka is typically described as a durable log. Kafka is primarily about data, streams of data to be specific. Kafka lists some of its common use cases as:

  • Messaging (note that in this case they are talking about a “replacement for a traditional message broker”. i.e. they are typically talking about messaging between systems, not within a system.)

  • Acitivity Tracking (i.e. storing the data about page views, searches, etc.)

  • Storing Metrics

  • Log Aggregation

Observe that nearly all of the use cases they list are primarily describing the data.

Thus it’s really common for an application to be built on Akka that read and writes data to Kafka. (Often by the Alpakka Kafka Connector.) I hate to oversimplify the question, but in some ways its like asking for use cases for when you would use Java versus use cases where you would a database. One is for applications, one is for data. While it’s true there is overlap (you can send messages in both Akka and Kafka, you can build logic in the application or you can build logic in stored procedures), but in both cases they generally are complementary not competitive.

P.S.
This question does become even more complicated by the fact that both Akka and Kafka are not so much technologies, but families of technologies. The above compares “core Akka” with “core Kafka”, but comparing say “Akka Streams” versus “Kakfa Streams” is more nuanced.

3 Likes

Sours: https://discuss.lightbend.com/t/use-cases-for-akka-vs-kafka/4206

Concurrency and Fault Tolerance Made Easy: An Akka Tutorial With Examples

The challenge

Writing concurrent programs is hard. Having to deal with threads, locks, race conditions, and so on is highly error-prone and can lead to code that is difficult to read, test, and maintain.

Many therefore prefer to avoid multithreading altogether. Instead, they employ single-threaded processes exclusively, relying on external services (such as databases, queues, etc.) to handle any needed concurrent or asynchronous operations. While this approach is in some cases a legitimate alternative, there are many scenarios in which it is simply not a viable option. Many real-time systems – such as trading or banking applications, or real-time games – don’t have the luxury of waiting for a single-threaded process to complete (they need the answer now!). Other systems are so compute- or resource-intensive that they would take an inordinate amount of time (hours or even days in some cases) to run without introducing parallelization into their code.

One fairly common single-threaded approach (widely used in the Node.js world, for example) is to use an event-based, non-blocking paradigm. While this does help performance by avoiding context switches, locks, and blocking, it still does not address the issues of using multiple processors concurrently (doing so would require launching, and coordinating between, multiple independent processes).

So does this mean you have no choice but to journey deep into the bowels of threads, locks, and race conditions in order to build a concurrent application?

Thanks to the Akka framework, the answer is no. This tutorial introduces Akka examples and explores the ways in which it facilitates and simplifies the implementation of concurrent, distributed applications.

What is the Akka Framework?

This post introduces Akka and explores the ways in which it facilitates and simplifies the implementation of concurrent, distributed applications.

Akka is a toolkit and runtime for building highly concurrent, distributed, and fault tolerant applications on the JVM. Akka is written in Scala, with language bindings provided for both Scala and Java.

Akka’s approach to handling concurrency is based on the Actor Model. In an actor-based system, everything is an actor, in much the same way that everything is an object in object-oriented design. A key difference, though – particularly relevant to our discussion – is that the Actor Model was specifically designed and architected to serve as a concurrent model whereas the object-oriented model is not. More specifically, in a Scala actor system, actors interact and share information, without any presupposition of sequentiality. The mechanism by which actors share information with one another, and task one another, is message passing.

All the complexity of creating and scheduling threads, receiving and dispatching messages, and handling race conditions and synchronization, is relegated to the framework to handle transparently.

Akka creates a layer between the actors and the underlying system such that actors simply need to process messages. All the complexity of creating and scheduling threads, receiving and dispatching messages, and handling race conditions and synchronization, is relegated to the framework to handle transparently.

Akka strictly adheres to the The Reactive Manifesto. Reactive applications aim at replacing traditional multithreaded applications with an architecture that satisfies one or more of the following requirements:

  • Event-driven. Using Actors, one can write code that handles requests asynchronously and employs non-blocking operations exclusively.
  • Scalable. In Akka, adding nodes without having to modify the code is possible, thanks both to message passing and location transparency.
  • Resilient. Any application will encounter errors and fail at some point in time. Akka provides “supervision” (fault tolerance) strategies to facilitate a self-healing system.
  • Responsive. Many of today’s high performance and rapid response applications need to give quick feedback to the user and therefore need to react to events in an extremely timely manner. Akka’s non-blocking, message-based strategy helps achieve this.

What is an Actor in Akka?

An actor is essentially nothing more than an object that receives messages and takes actions to handle them. It is decoupled from the source of the message and its only responsibility is to properly recognize the type of message it has received and take action accordingly.

Upon receiving a message, an actor may take one or more of the following actions:

  • Execute some operations itself (such as performing calculations, persisting data, calling an external web service, and so on)
  • Forward the message, or a derived message, to another actor
  • Instantiate a new actor and forward the message to it

Alternatively, the actor may choose to ignore the message entirely (i.e., it may choose inaction) if it deems it appropriate to do so.

To implement an actor, it is necessary to extend the akka.actor.Actor trait and implement the receive method. An actor’s receive method is invoked (by Akka) when a message is sent to that actor. Its typical implementation consists of pattern matching, as shown in the following Akka example, to identify the message type and react accordingly:

Pattern matching is a relatively elegant technique for handling messages, which tends to produce “cleaner” and easier-to-navigate code than a comparable implementation based on callbacks. Consider, for example, a simplistic HTTP request/response implementation.

First, let’s implement this using a callback-based paradigm in JavaScript:

Now let’s compare this to a pattern-matching-based implementation:

While the callback-based JavaScript code is admittedly compact, it is certainly harder to read and navigate. In comparison, the pattern-matching-based code makes it more immediately apparent what cases are being considered and how each is being handled.

The Actor System

Taking a complex problem and recursively splitting it into smaller sub-problems is a sound problem solving technique in general. This approach can be particularly beneficial in computer science (consistent with the Single Responsibility Principle), as it tends to yield clean, modularized code, with little or no redundancy, that is relatively easy to maintain.

In an actor-based design, use of this technique facilitates the logical organization of actors into a hierarchical structure known as an Actor System. The actor system provides the infrastructure through which actors interact with one another.

An example of the way the actor system works in the Akka framework.

In Akka, the only way to communicate with an actor is through an . An represents a reference to an actor that precludes other objects from directly accessing or manipulating that actor’s internals and state. Messages may be sent to an actor via an using one of the following syntax protocols:

  • (“tell”) – sends the message and returns immediately
  • (“ask”) – sends the message and returns a Future representing a possible reply

Each actor has a mailbox to which its incoming messages are delivered. There are multiple mailbox implementations from which to choose, with the default implementation being FIFO.

An actor contains many instance variables to maintain state while processing multiple messages. Akka ensures that each instance of an actor runs in its own lightweight thread and that messages are processed one at a time. In this way, each actor’s state can be reliably maintained without the developer needing to explicitly worry about synchronization or race conditions.

Each actor is provided with the following useful information for performing its tasks via the Akka Actor API:

  • : an to the sender of the message currently being processed
  • : information and methods relating to the context within which the actor is running (includes, for example, an method for instantiating a new actor)
  • : defines the strategy to be used for recovering from errors
  • : the for the actor itself

Akka ensures that each instance of an actor runs in its own lightweight thread and that messages are processed one at a time. In this way, each actor's state can be reliably maintained without the developer needing to explicitly worry about synchronization or race conditions.

To help tie these tutorials together, let’s consider a simple example of counting the number of words in a text file.

For purposes of our Akka example, we’ll decompose the problem into two subtasks; namely, (1) a “child” task of counting the number of words on a single line and (2) a “parent” task of summing those per-line word counts to get the total number of words in the file.

The parent actor will load each line from the file and then delegate to a child actor the task of counting the words in that line. When the child is done, it will send a message back to the parent with the result. The parent will receive the messages with the word counts (for each line) and keep a counter for the total number of words in the entire file, which it will then return to its invoker upon completion.

(Note that the Akka tutorial code samples provided below are intended to be didactic only and therefore do not necessarily concern themselves with all edge conditions, performance optimizations, and so on. Also, a complete compilable version of the code samples shown below is available in this gist.)

Let’s first look at a sample implementation of the child class:

This actor has a very simple task: consume messages (containing a line of text), count the number of words on the specified line, and return the result to the sender via a message. Note that we have implemented our class to use the (“tell”) method to send the message (i.e., to send the message and return immediately).

OK, now let’s turn our attention to the parent class:

Many things are going on in here, so let’s examine each of them in more detail (note that the line numbers referenced in the discussion that follows are based on the above code sample)

First, notice that the name of the file to process is passed to the constructor (line 3). This indicates that the actor is only to be used to process a single file. This also simplifies the coding job for the developer, by avoiding the need to reset state variables (, , , and ) when the job is done, since the instance is only used once (i.e., to process a single file) and then discarded.

Next, observe that the handles two types of messages:

  • (line 12)
    • Received from the external actor that initially initiates the .
    • When received, the first checks that it is not receiving a redundant request.
    • If the request is redundant, generates a warning and nothing more is done (line 16).
    • If the request is not redundant:
      • stores a reference to the sender in the instance variable (note that this is an rather than an - see line 9). This is needed in order to later access and respond to it when processing the final (which is received from a child, as described below).
      • then reads the file and, as each line in the file is loaded, a child is created and a message containing the line to be processed is passed to it (lines 21-24).
  • (line 27)
    • Received from a child when it completes processing the line assigned to it.
    • When received, the increments the line counter for the file and, if all lines in the file have been processed (i.e., when and are equal), it sends the final result to the original (lines 28-31).

Once again, notice that in Akka, the sole mechanism for inter-actor communication is message passing. Messages are the only thing that actors share and, since actors can potentially access the same messages concurrently, it is important for them to be immutable, in order to avoid race conditions and unexpected behaviors.

Case classes in Scala are regular classes that provide a recursive decomposition mechanism via pattern matching.

It is therefore common to pass messages in the form of case classes since they are immutable by default and because of how seamlessly they integrate with pattern matching.

Let’s conclude the example with the code sample to run the whole app.

In concurrent programming, a "future" is a essentially a placeholder object for a result that is not yet known.

Notice how this time the method is used to send a message. In this way, the caller can use the returned Future to print the final result when this is available and to exit the program by shutting down the ActorSystem.

Akka fault tolerance and supervisor strategies

In an actor system, each actor is the supervisor of its children. If an actor fails to handle a message, it suspends itself and all of its children and sends a message, usually in the form of an exception, to its supervisor.

In Akka, supervisor strategies are the primary and straightforward mechanism for defining the fault tolerant behavior of your system.

In Akka, the way in which a supervisor reacts to and handles exceptions that percolate up to it from its children is referred to as a supervisor strategy. Supervisor strategies are the primary and straightforward mechanism by which you define the fault tolerant behavior of your system.

When a message signifying a failure reaches a supervisor, it can take one of the following actions:

  • Resume the child (and its children), keeping its internal state. This strategy can be applied when the child state was not corrupted by the error and it can continue functioning correctly.
  • Restart the child (and its children), clearing its internal state. This strategy can be used in the opposite scenario of the one just described. If the child state has been corrupted by the error, it is necessary the reset its state before it can be used in the Future.
  • Stop the child (and its children) permanently. This strategy can be employed in cases where the error condition is not believed to be rectifiable, but does not jeopardize the rest of the operation being performed, which can be completed in the absence of the failed child.
  • Stop itself and escalate the error. Employed when the supervisor does not know how to handle the failure and so it escalates it to its own supervisor.

Moreover, an Actor can decide to apply the action just to the failed children or to its siblings as well. There are two pre-defined strategies for this:

  • : Applies the specified action to the failed child only
  • : Applies the specified action to all of its children

Here’s a simple example, using the :

If no strategy is specified, the following default strategy is employed:

  • If there was an error while initializing the actor or if the actor was killed, the actor is stopped.
  • If there was any other kind of exception, the actor is simply restarted.

The Akka-supplied implementation of this default strategy is as follows:

Akka allows for the implementation of custom supervisor strategies, but as the Akka documentation warns, do so with caution as incorrect implementations may lead to problems such as blocked actor systems (i.e. permanently suspended actors).

Location transparency

The Akka architecture supports location transparency, enabling actors to be entirely agnostic to where the messages that they receive originated. The sender of the message may reside in the same JVM as the actor or in a separate JVM (either running on the same node or a different node). Akka enables each of these cases to be handled in a manner that is completely transparent to the actor (and therefore the developer). The only caveat is that messages sent across multiple nodes must be serializable.

The Akka architecture supports location transparency, enabling actors to be entirely agnostic to where the messages that they receive originated.

Actor systems are designed to run in a distributed environment without requiring any specialized code. Akka only requires the presence of a configuration file () that specifies the nodes to send messages to. Here’s a simple example of a configuration file:

A few parting tips…

We have seen how the Akka framework helps achieve concurrency and high performance. However, as this tutorial pointed out, there are a few points to keep in mind when designing and implementing your system in order to exploit the power of Akka to its fullest:

  • To the greatest extent possible, each actor should be assigned the smallest task possible (as previously discussed, following the Single Responsibility Principle)
  • Actors should handle events (i.e., process messages) asynchronously and should not block, otherwise context switches will happen which can adversely affect performance. Specifically, it is best to perform blocking operations (IO, etc.) in a Future so as not to block the actor; i.e.:

  • Be sure your messages are all immutable, since the actors that pass them to one another will all be running concurrently in their own threads. Mutable messages are likely to result in unexpected behavior.
  • Since messages sent between nodes must be serializable, it is important to bear in mind that the larger the messages are, the longer it will take to serialize, send, and deserialize them, which can negatively impact performance.

Conclusion

Akka, written in Scala, simplifies and facilitates the development of highly-concurrent, distributed, and fault tolerant applications, hiding much of the complexity from the developer. Doing Akka full justice would require much more than this single tutorial, but hopefully this introduction and its examples were sufficiently captivating to get you to want to read more.

Amazon, VMWare, and CSC are but a few examples of leading companies who are actively using Akka. Visit the official Akka website to learn more and to explore whether Akka could be the right answer for your project as well.

Sours: https://www.toptal.com/scala/concurrency-and-fault-tolerance-made-easy-an-intro-to-akka
  1. Chess armory 17
  2. Wave cake ideas
  3. Moto tech oil
  4. Diarabi meaning

Examples of use-cases for Akka

We see Akka being adopted by many large organizations in a big range of industries all from investment and merchant banking, retail and social media, simulation, gaming and betting, automobile and traffic systems, health care, data analytics and much more. Any system that have the need for high-throughput and low latency is a good candidate for using Akka.

There is a great discussion on use-cases for Akka with some good write-ups by production users here

Here are some of the areas where Akka is being deployed into production

Service backend (any industry, any app)

Service REST, SOAP, Cometd, WebSockets etc Act as message hub / integration layer Scale up, scale out, fault-tolerance / HA

Concurrency/parallelism (any app)

Correct Simple to work with and understand Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby)

Simulation

Master/Worker, Compute Grid, MapReduce etc.

Batch processing (any industry)

Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads

Gaming and Betting (MOM, online gaming, betting)

Scale up, scale out, fault-tolerance / HA

Business Intelligence/Data Mining/general purpose crunching

Scale up, scale out, fault-tolerance / HA

Complex Event Stream Processing

Scale up, scale out, fault-tolerance / HA

Sours: https://doc.akka.io/docs/akka/2.4/intro/use-cases.html
Akka A to Z: The Industry's Choice For Fast Data \u0026 Microservices Architectures

Akka.NET Users and Use Cases

Akka.NET is used by many large organizations and in industries such as investment and merchant banking, retail and social media, simulation, gaming and betting, automobile and traffic systems, health care, data analytics, and much more. Any system that has the need for high-throughput and low latency is a good candidate for using Akka.NET.

Akka.NET Users

Transaction processing (Online Gaming, Finance/Banking, Trading, Statistics, Betting, Social Media, Telecom)

Service backend (any industry, any app)

IVC Business Systems:

Sam Covington, IVC Business Systems: We had an in-house "Actor" system that we replaced with Akka.Net, which allowed us to innovate and be productive elsewhere, and not reinvent the wheel(not to mention test it to death). This back end of Microservices forms the basis of all of our products and services. We're using it in our Enterprise Social Product, and our new Livescan Office product for Livescan fingerprinting customers.

Concurrency/parallelism (any app)

Share of an article by Joel Mueller, Software Architect, SNL Financial

Simulation

Master/Worker, Compute Grid, MapReduce etc.

Batch processing (any industry)

Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads

Communications Hub (Telecom, Web media, Mobile media)

Gaming and Betting (MOM, online gaming, betting)

Scale up, scale out, fault-tolerance / HA

Business Intelligence/Data Mining/general purpose crunching

Tweet from Philip Laureano with links.

Internet of Things

Complex Event Stream Processing

Archive of a blog post by Aaron Stannard from July 2014.

Blockchain

"NEO is a non-profit community-driven blockchain project. It utilizes blockchain technology and digital identity to digitize assets and automate the management of digital assets using smart contracts." (source: neo.org)

Sours: https://getakka.net/articles/intro/akka-users.html

Use cases akka

Why Akka?

Twenty years ago, when people needed to solve a software scalability problem, the solution was almost always to “scale up” by purchasing an expensive multiprocessor server from Sun or IBM. Then, as commodity hardware grew cheaper and more powerful, the trend shifted towards “scaling out” by using clusters of less expensive servers. Today, with the arrival of commodity multicore CPUs and cloud computing, we face the dual challenge of scaling “up and out” at the same time.

I've been writing middleware systems for most of my career, through the transitions from “scale up” to “scale out” and back again, applying concurrency and distributed computing to solve scalability problems. Along the way, I've always felt that there must be a fundamentally better way to build scalable software. Finally, about three years ago, I decided to do something about it. 

I created the Akka project with the vision of a runtime and programming model that would address the challenges of both multicore and distributed computing. Akka gives developers a unified way to build scalable and fault-tolerant software that can scale up on multicore systems, and scale out in distributed computing environments, which today often means in the cloud. Akka makes it possible to build software systems with reliability and high performance, without sacrificing developer joy and productivity.

In short, Akka is open source middleware for building highly concurrent, distributed and fault-tolerant systems on the JVM. Akka is built with Scala, but offers both Scala and Java APIs to developers.

At the heart of Akka is the concept of Actors, which provide an ideal model for thinking about highly concurrent and scalable systems. Writing concurrent systems using traditional low-level mechanism such as locks and threads is difficult. The resulting software is often hard to understand and maintain. The Actor model provides a higher-level alternative that is much easier to reason about. Actors also provide location transparency, in the sense that the user of an Actor does not need to know whether that Actor lives in the same process or on a different machine. This makes it simple to write software that can scale with the needs of the application. It also gives the runtime the freedom to provide services like adaptive load balancing, cluster rebalancing, replication and partitioning.

Importantly, Akka embraces Erlang’s model for fault-tolerance, colloquially known as “let it crash.” This fault tolerance model works by organizing the various Actors in a system in a supervisor hierarchy such that each component is monitored by another, and restarted upon failure. The model has been used to great effect in the telecommunications equipment industry for years, as the foundation of highly available systems that can adaptively heal themselves while running.

The Actor model alone, while great for many use cases, do not solve all concurrency and scalability problems. By decomposing state into many discrete Actors, the model can introduce challenges for applications that require global consistency. To address this problem, Akka uses Software Transactional Memory (STM), which makes it possible to modify the state of many objects at once, reverting all changes if the transaction fails. In addition to STM, Akka provides several other concurrency abstractions such as Agents and Dataflow Concurrency.

Since the introduction of Akka, the project has attracted a tremendous community of users and contributors. In the past year, Akka has matured with a rich and cohesive set of modules that can be composed to solve a wide variety of business requirements. Now, as part of the Typesafe Stack, we intend to take Akka to the next level with enterprise grade features and supporting commercial services.

We have big plans for Akka. This is just the beginning. And we look forward to partnering with the rest of the team at Typesafe to write the next chapter in software development.

Share

Sours: https://www.lightbend.com/blog/why-akka
Akka Typed: Stateful and Stateless Actors - Rock the JVM

What are the best use cases for Akka framework [closed]

I was trying out my hands on Akka (Java api). What I tried was to compare Akka's actor based concurrency model with that of plain Java concurrency model (java.util.concurrent classes).

The use case was a simple canonical map reduce implementation of character count. The dataset was a collection of randomly generated strings (400 chars in length), and calculate the number of vowels in them.

For Akka I used a BalancedDispatcher(for load balancing amongst threads) and RoundRobinRouter (to keep a limit on my function actors). For Java, I used simple fork join technique (implemented without any work stealing algorithm) that would fork map/reduce executions and join the results. Intermediate results were held in blocking queues to make even the joining as parallel as possible. Probably, if I am not wrong, that would mimic somehow the "mailbox" concept of Akka actors, where they receive messages.

Observation: Till medium loads (~50000 string input) the results were comparable, varying slightly in different iterations. However, as I increased my load to ~100000 it would hang the Java solution. I configured the Java solution with 20-30 threads under this condition and it failed in all iterations.

Increasing the load to 1000000, was fatal for Akka as well. I can share the code with anyone interested to have a cross check.

So for me, it seems Akka scales out better than traditional Java multithreaded solution. And probably the reason is the under the hood magic of Scala.

If I can model a problem domain as an event driven message passing one, I think Akka is a good choice for the JVM.

Test performed on: Java version:1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3GB ram. Intel Core i5 processor, 2.5 GHz clock speed

Please note, the problem domain used for the test can be debated and I tried to be as much fair as my Java knowledge allowed :-)

answered Jun 21 '12 at 20:37

sutanu daluisutanu dalui

60377 silver badges2424 bronze badges

Sours: https://stackoverflow.com/questions/4493001/what-are-the-best-use-cases-for-akka-framework

Now discussing:

Quick Guide to Building Scalable and Responsive Applications with Akka

What is Akka?

Akka provides a platform to build scalable, resilient and responsive applications in Scala and Java. The Akka framework provides good abstractions for concurrent, asynchronous, and distributed programming, such as Actors, Streams, and Futures. It uses the Actor model to hide all the thread- related code and gives interfaces to implement a scalable and fault-tolerant system easily.

Akka is a truly reactive framework because everything in the sense of sending and receiving a message to Actors, is lock-less, non-blocking IO, and asynchronous.Building application with Akka has several advantages, which are as follows -

  • High performance - Akka delivers up to 50 million message per second on commodity hardware having ~2.5 million Actors per GB of RAM.
  • Resilient by design - Akka system has self-healing properties for local and remote Actors.
  • Distributed and Elastic - Akka has all the mechanisms to scale Application, such as cluster, load balancing, partitioning, and sharding.

How Does Akka Framework Work?

Actor System - Create Actors and initialize actors and configure the desired implementation of each component. The sender initiates the actor creation process, which invokes actorOf() on Actor System and creates a reference of an Actor object, the actor not created /initiated. ActorRef acts as a proxy to the Actor object and provides an interface to communicate with the Actor.

  • The Sender Actor uses ! to tell the receiving Actor about the event.
  • ActorRef in response dispatches the event on Messages Dispatcher.
  • Message Dispatcher enqueue the event to the Message-queue.
  • Message Dispatcher also looks for the mailbox. The mailbox holds the message to receive the Actor, finds the MailBox, MessageDispatcher binds a set of Actor to a thread pool and invoke the MailBox.run() method.

Why Adopting Akka Matters?

Akka can be used for write application in the Actor pattern, meaning everything has to be immutable. There are no methods to call on external objects, but an actor used as an object. It's doesn't involve locking which gets rid of the deadlock problem. Also, Actor is cheap and not thread bound. Meaning, an Actor can live on whichever Thread it wants and doesn't waste threads. So if an Actor isn't handling a message, it doesn't occupy a thread. On top of that, it is scalable, both over cores, but also multiple machines.


Benefits of Adopting Akka

Concurrent application developing is difficult because of the need to deal with synchronization, locks and shared memory. Akka actors can easily write asynchronous code without the need for lock and synchronization.

Akka actors use message instead of method calls is that the sender thread won't block to wait for a return value when it sends a message to another actor. The receiving actor will response with the results by sending a reply message to the sender.

Akka actor model handles the error. The actors in a hierarchy, each actor notify its parent of the failure. Then the parent actor decide to stop or restart the child actors, Don't worry about synchronization in a multi-thread environment and all the messages processed sequentially.


How to Adopt or Use Akka?

Akka actors are lightweight and loosely-coupled by design, thus scale well on a distributed computing environment.

  • IoT - The actor model can help to embrace the characteristics of IOT systems and make it easier to represent individual devices and also groups of devices.
  • Transaction Processing - The Akka used for Transaction processing where the incoming data is either time series or transactional data. The stream data is either pump in a large amount of data that needs to be processed in parallel and concurrently. Finance, banking, securities, trading, telecoms, social media, and online gaming are some of the domain enterprises that deal with large data coming in from multiple sources.
  • Service Provider - Another area is where the application provides services to various other clients via a variety of service means such as SOAP, REST, or Web-sockets. The application generally caters to be processed fast and concurrently.
  • Batch Processing - Batch processing used across enterprise domains is another area where Akka actor very well. Dealing with extensive data, applying paradigms such as divide and conquer, mapreduce, master-worker, and grid computing allow large data processed.
  • Data Mining/Analytics - Most enterprises generate large amounts of data structured as well as unstructured. An application that mine this data from existing transactional stores or data warehouses can use Akka to process and analyze the massive sets of data.
  • Service Gateways/Hubs - Service gateway or hubs connect multiple systems or applications and provide mediation and transformation services. An Akka provides those scale-up and scale-out options along with high availability for applications in this space.

Akka Best Practices

  • When performance is a concern use tell() instead of ask().
  • Always handle exceptions by sending a Failure message when using ask().
  • An actor shouldn't share any mutable state.
  • An actor shouldn’t be declared within another actor.
  • Explicitly destroy an actor when don't need it anymore to prevent memory leaks.
  • Messages used by actors should always be immutable.

Akka Performance Monitoring Toolkit

Akka - Persistence

It's primary purpose is to make Akka Persistence more comfortable to use.

The main components are -

  • GeneralAggregate- Which is built on top of PersistenceActor.
  • GeneralAggergate- Which is built on top of PersistanceQuery.

It includes feature like -

  • Separation of aggregate, view and state(machine).
  • View and aggregate both understand the same events and the uses the same state.
  • Integrate cluster/sharding-support.
  • Simplified AtLeastOnce Delivery-support.
  • Automatic starting and stopping aggregates and views.
  • Automatic working view that supports getting the current state and the full event history.
Sours: https://www.xenonstack.com/insights/what-is-akka


15212 15213 15214 15215 15216