These are chat archives for atomix/atomix
There was a point at which that was true, but it has long since passed. We’ve been using the Atomix 2.x Raft implementation for many months and are in the process of deploying it in some very large production networks.
The Raft implementation in Atomix 2.x was significantly refactored to be much more stable for its intended use case (distributed systems primitives). We rewrote the log to have a better memory footprint, replaced incremental compaction with snapshotting, rewrote the session abstraction to isolate primitives from each other, and fixed a ton of bugs in the process. It now has far more time and effort put into its stability than Atomix 1.x ever did.
Yeah that can be a problem. We’ve discussed a lot but haven’t tested how it behaves across geographies. The communication is configured to adapt to changing network conditions. It seems to work well when the network is heavily utilized, but just haven’t tested it with an unreliable inter-DC link.
Long term we’re likely to implement a gossip protocol to handle this type of replication between data centers, but we have no immediate need for it so it’s not even in any release plans yet.
The only use cases I know about and pay attention to are the ones I work on for ONOS :-) Like I said, we’re in the process of a very large production deployment, but I don’t know where others are at in deploying it nor what the scale is.
My recommendation for ephemeral state depends on your consistency requirements. For a read-heavy workload consensus is perfectly fine - data is held in memory. For write heavy workloads, Atomix 2.x is a lot faster since it’s sharded internally, but there are better protocols if you don’t need the consistency. That’s the reason Atomix 2.x has a second primary-backup or multi-primary protocol. Primitives can be partitioned into many more partitions, stores only in memory, and replicated synchronously or asynchronously or to fewer nodes.