Justin, Thank you for your reply. I have a couple of follow on questions.
We have a few million Products each of which have Rates associated with them. These Rates can and do change -- collectively quite a bit -- but individually not so much. Having an Actor per Product, distributed evenly onto the Shards, makes the most sense to me as well. It is simple and straightforward. Particularly since each Product could cache it's current Rates. In this model, each Actor is caching it's particular Rates info, as opposed to a shared, concurrent HashMap. Correct? Would you create all of these Actors at start-up? (I would assume so) Would this make for a really slow start-up? Would it make sense to use Akka persistence so that restarts are (assumedly) much faster? Or are there other more efficient ways to backup the system? If the actual cache was to move off the JVM -- into, say, memcached -- how would you model something like that in this scenario? Would you simply create a child CacheActor that indirectly handles that interaction. Again, thank you so much for taking your time to answer my questions. Cheers, -- Chris On Monday, December 12, 2016 at 5:09:35 PM UTC-6, Justin du coeur wrote: > > On Mon, Dec 12, 2016 at 1:30 PM, Chris Berry <[email protected] > <javascript:>> 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.
