No compromises: distributed transactions with consistency, availability, and performance
The new idea to take away from FaRM is optimistic concurrency control
FaRM uses a primary-backup replication scheme instead of Paxos
It includes a configuration manager and also uses Zookeeper to safely handle configuration
Each transaction runs on a non-replicated coordinator which runs 2-phase commit
FaRM keeps data in persistent NVRAM, eliminating the disk bottleneck. This can be achieved with an uninterrupted power supply and a backup SSD. When power loss is detected, the data is flushed to disk.
To optimize CPU usage, we use two techniques. Kernel bypass allows computers to directly interact with the network interface’s (NIC) DMA queue. Then, RDMA bypasses the receiver’s CPU to access memory directly over network.
How do we use this one-sided communication to create a transaction system? 2-phase locking requires a two-way back and forth…
The key is optimistic concurrency control,
- Read anything that needs to be read
- Acquire locks
- Validate nothing has changed (between step 1 and 2)
- Commit
- Release locks
If we cannot acquire locks or validation fails then we must abort the transaction
Messages are read from queues via polling
In the execute phase, the transaction coordinator reads in objects from each required server (including objects to write)