On Mon, Dec 12, 2016 at 1:30 PM, Chris Berry <[email protected]> wrote:
> So, since we have to refactor anyway, we decided to look at better ways. > > And Akka’s clustering, sharding, and akka-http are all quite appealing > Certainly, Cluster Sharding looks like a very good fit, at least at first glance. The only real question is whether it meets your latency requirements. You may need to play with it in order to see with confidence, but we can talk through some of the implications. > So my question. How would y’all model the Actors/Messages in this system? > Seems like a fairly straightforward one from your description: you have Sharded Regions for your Products, such that each Product Y is a distinct Entity. When Actor Y boots, it loads and caches the RateInfo. The front-end HTTP system sends a Sharding-sensitive message, which gets routed to Y, computed, and replied. That's all pretty bog-standard Cluster Sharding. Note that application code usually doesn't concern itself with the details of which Node happens to be hosting Y right now -- part of the point of Cluster Sharding is that it deals with that under the hood, and deals with things like rebalancing if a Node goes down. > The things I find most puzzling are: > > - The “single threaded illusion” and how this relates to the Rates > computation. Clearly that must happen in parallel? > > No, actually -- the requests for a given Actor are essentially queued, and handled one at a time. (This is probably the most important invariant in Akka.) This usually works fine, although in your low-latency environment it's possible that it won't suffice, especially if computing a Rate is a complex and slow process. In that case, I might set up a small pool of child Actors underneath Y; when Y boots, it creates this pool and sends a link to the RateInfo to each one. When Y gets a request, it forwards it into that pool to resolve. > > - How does one cleanly share the cached RateInfo across the Actors? > > So this is why Akka *very* strongly prefers immutable data structures: so long as RateInfo is immutable, then it can be passed reasonably safely between Actors. If and when it changes, the change should get routed through Actor Y (which is the sole authority about its own data); Y makes the change, persists it, and then sends the tweaked version of RateInfo to the child Actors. Since RateInfo is immutable, each child always has a self-consistent view. (Brief race conditions are possible, where a child hasn't gotten the update yet -- that's basically life in a distributed system, and Akka doesn't try to pretend otherwise.) > > - Sorry if these questions are too broad. I am a total newbie. > > Quite all right -- these are actually pretty reasonable beginner questions... -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
