When and How to Use the Actor Model An Introduction to Akka NET Actors
HTML-код
- Опубликовано: 16 июн 2024
- Announcing .NET Core 3.0: aka.ms/dotnetcore3
In the era of cheap, commodity cloud computing the actor model is ascendant across all programming languages and runtimes, both for building distributed systems and for creating reactive mobile or desktop applications. 
Наука
![100 Days - [Minecraft Creative 2]](http://i.ytimg.com/vi/OmogWsk_ZZg/mqdefault.jpg)
If anyone is interested, this concept is heavily utilized in languages such as Erlang/Elixir - actor model is basically a first-class citizen and you build your programs by using it, making them a perfect language for backend systems.
Looks like I'm relearning Redux. Really great lessons. Thank you for the detailed explanations.
Very nice explanation of the actor model, I'd definitely recommend this video to everyone who is new to the subject.
One of the simplest explanation I have found.
a great intro to actor model! Many thanks!
Keeping in mind that akka is in memory, how it provides data durability and concictency or any failovers when things goes bad (application shutdown, network disconnections, etc...)?
I have questions about the Actor model but I never know where to ask or discuss them. This is one.
One of the reasons I find the Actor model attractive is that it claims to simplify thinking about concurrency because each actor is single-threaded. But then all the discussions I see about the Actor model has actors arranged in a parent/child tree structure where the children are essentially workers. But if you limit your design to that structure, then normal mutex locking isn't error prone or difficult to think about either.
The difficulty seems to be when you have actors that are arranged as peers. Let's say that actor A sends messages to actor B and to actor C. As a result of that, actor B sends a message to actor C. Now actor C is receiving a message from each of actor A and actor B but they are not necessarily in any order. And if you need for them to be in a particular order I don't know a simple way to deal with that.
In cases like this it seem that the Actor model didn't really simplify concurrency; it just pushed the problem to another part of the architecture.
If the problem with your "out of order" messages is just, that your actor is not in the appropriate state then checkout "stashing of messages". With this technique you can express "Well, I got a message but I cant currently process it but will try again later". So you stash the message. It means it is not lost but held in an actor local cache. If your actor switches later to another state you can just "Unstash" all stashed message which just means "please spool all stashed messages again into my actor as if they come from external". Because your actor is now in a state which could handle the remaining messages your stash should be empty by time. If not then maybe your protocol between your actors is wrong. For the technical details check this link out:
stackoverflow.com/questions/39055741/akka-net-stashing-messages-during-a-specific-state-of-an-actor
The link in the stack overflow thread are dead. Here is a similar article:
pasoft-share.gitbooks.io/akka-net-docs/content/working-with-actors/Stashing%20Messages.html
@@rk5727 Thanks for that answer! I’ll take a look at that. I mostly focus on C++ programming and might probably use the C++ Actor Framework. I just noticed that while CAF doesn’t have stashing, it does allow you to skip messages and leave them in the mailbox.
Since you’re so helpful, maybe I can hit you with my other main question about actors. Many of the programs I write are editors. These are mostly UI that allow you to edit some kind of data. Often in order for an actor to process a message, it needs to get some state from another actor, or just from the pile of data being edited, or I guess it could be from a database. The problem is that if I make a function call to get the data at the current time then that is the current state of the data but not necessarily the state of the data when the message was sent. With a messaging system there is a time difference.
I think the answer to this is to never request immediate data from other places. Rather, when that data changed a message will have been sent out with the new value. So the receiving actor should save any values it might need for later. (So this models the physical world---I don’t know the current state of the universe, I only know what has been transmitted to me by light rays.) So this way the time lines up and I believe things should work fine. But it means there may be a lot of data duplicated throughout the program. It may be good for concurrency but bad for memory usage. Does this make sense?
You may say that this is not the kind of program that the actor model should be used for. So use a different paradigm. But I like to think the actor model could be used for anything. I like how it makes things very modular.
You may say that if one actor needs to know the state of another actor, then something is designed wrong in the first place. But I think this is not unusual for an editor type of program that focuses on the data and the state of the data.
Amazing Talk +1
How does this compare to dapr?
Or Orleans
Why isn't this using MEF. I've already been through some pain trying to get dotnet standard libraries written for dotnet core web API working with WCF. Now if you change the interface, I won't be able to reuse my dotnet standard libraries with this framework. Please add some consistency
Is it a new name for CORBA?
What the hell is up with you guys. I saw a new modular framework yesterday and now this! Can you provide a website where you publish a list of these new frameworks
What are you talking about? This is a very old project called Akka.NET based on Akka from Scala language I think. It's an opensource 3rd party library not related to Microsoft.
Easy on the drugs bro
something they could do better would be to give a better introduction as to why you'd pick one framework over the other. This framework is for live updates for highly concurrent distributed applications. Ma Bell was one of the first prime examples of this where nearly every landline phone would trigger a message each time a call was made. Lots of messages were transmitted in parallel as each person on the network would pick up the receiver, dial a number, or hang up. This is the kind of volume you'd expect to see to drive a software architecture that would make the best use of Akka. The other framework, SignalR, is a similar but historically has been designed for the scope of a single application (like updating alert notifications or chat messages). Both frameworks are converging in capabilities, so the scaling factor is less significant today. Because they have different heritage, they can have slightly different capabilities still today, but you are right that it can be confusing as to which to pick for which application, and for most applications, it doesn't really matter until you hit a scale where performance is a major consideration.