4 ms·
I use Akka Cluster extensively with Persistence. It's an amazing piece of technology. Before I went this route, I tried to make Akka Cluster work with RabbitMQ
by halfmatthalfcat 6y ago
I use Akka Cluster extensively with Persistence. It's an amazing piece of technology.
Before I went this route, I tried to make Akka Cluster work with RabbitMQ however I realized (like another poster here) that you're essentially duplicating concerns since Akka itself is a message queue. There's also a ton of logistics with Rabbit around binding queues, architecting your route patterns, etc that add extra cognitive overhead.
I'm creating a highly distributed chat application where each user has their own persistent actor and each chatroom has their own persistent actor. At this point, it doesn't matter where the user or chatroom are in the cluster it literally "just works".
All I need to do is emit a message to the cluster from a user to chatroom or vice versa, even in a cluster of hundreds of nodes, and things just work. Now there's some extra care you need to take at the edge (split-brain via multi-az, multi-datacenter) but those are things you worry about at scale.
Akka is the real fucking deal and it's one of the most pleasurable application frameworks I've ever had the pleasure of using in my career.
edit: The only reason I'd ever want to use Rabbit again is if I had external clients that needed to hook up to our message bus. If you're creating an entirely internal system, Akka Cluster is absolutely the way to go.
- amelius 6y agoCould one implement a distributed filesystem using Akka?
- halfmatthalfcat 6y agoYou could but I don't think it would be the best tool for it. When I think of Akka, I'm using it because I don't want to worry about which node in my cluster any given actor is on, I just want to be able to scale horizontally and messages are routed appropriately. Akka embraces the "let it fail" mentality where as nodes go down (just as pods go down in Kuberentes), you don't have to worry about where your processes are running...they just are...somewhere.
- dragosmocrii 6y agoSounds like Akka and Erlang/Elixir have a lot in common
- hawk_ 6y agoYes Akka is essentially erlang's actor model for the JVM
- acjohnson55 6y agoI'd echo this. I worked for a company that made a real-time auction system, based on Akka. It's been frustrating in the years since to program on less powerful foundations. If I were building a system that combined interactive and autonomous processes, I would absolutely reach for Akka again. The one thing I'd love to see is if they could build something like https://temporal.io https://temporal.io on top of Akka. I think it would be complementary to the state machine style model of typed actors and the pipeline model of Akka Streams.
- playing_colours 6y agoI remember using Akka in the domain of IoT. A persistent actor represented a sensor: state and history of readings. There was a great feature in Akka Persistence: if an actor went idle for a while - no new sensor data, it would be offloaded from memory to the storage (Cassandra). As soon as the sensor started to send new signals again or the sensor state was queried by a user the actor got loaded back to memory.
- vinay_ys 6y agoHow much sensor data is kept in memory in the actor object? What's the cost tradeoff between memory vs an SSD? I wonder if SSD based solution would still be cheaper and more scalable than live memory objects based solution.
- playing_colours 6y agoWhat sensor data and how much depend on the access needs: you can keep N latest records or some rolling aggregated data, if they are frequently accessed by some rule engine. It's certainly not feasible to hold big chunks of sensor data in memory.