FaRM: 无妥协的强一致性分布式数据库
No compromises: distributed transactions with consistency, availability, and performance
从论文的名字就能看出微软对于自己这套分布式数据库系统的自信程度，强调自己在实现强一致性的同时，并不会妥协可用性和性能，然而深入论文就会发现，虽然确实实现了题目中的性质，但是很多机制局限于其实现条件，另外由于时间和能力有限，未能看懂论文中对于错误恢复部分的阐述，未来涉及到相关内容时再重新学习。
构建系统动机
FaRM的构建动机来自于目前数据中心内部硬件发展的两个趋势：
- 基于RDMA（Remote Direct Memory Access）的快速网络通信技术：server之间进行通信时，不经过CPU，直接将数据写入到目标server存储区/拉取到本地存储区
- 低成本非易失DRAM存储技术：直接将数据存储在DRAM中，通过单独供电，在断电时备份到SSD中实现非易失
在我看来，FaRM的高性能大部分原因来自于上部分阐述的硬件优势，除去优势以外，以上设计同样为FaRM带来了一定限制
- 无法实现跨数据中心分布
- 增加了分布式事务和消息传递实现的复杂性（
这难道就是我看不懂错误恢复的原因？）
基本架构
如下图所示，FaRM架构基于1管理+N存储的方式，由一个配置管理服务器+多个存储服务器实现：
- Configuration Manager（CM）：负责分布式事务处理、容错恢复、配置管理等服务
- 普通存储服务器：存储数据+事务日志
- ZooKeeper：仅仅作为辅助CM实现配置管理的协调服务
其中数据以Region为单位在不同存储服务服务上分布和管理
- 每个Region为2GB大小的存储块，存储一个primary和f个backup
- 由CM负责Region的开辟、管理Region分布和映射
事务日志（Tx log）存储在基于环状缓冲实现的FIFO队列中，其中Region和Tx log的备份容错基于主从复制机制，一个primary+多个backup server，当primary server失效后，选取新的back up成为新的primary server
分布式事务的实现
与Spanner从Participant Group中选取一个作为协作者这种纯分布式事务实现方式不同，FaRM通过CM集中管理分布式事务
- 由于FaRM的消息传递不经过CPU，FaRM分布式事务无法采用两阶段提交？。采用了如下图所示的更多阶段、复杂的提交方式。
FaRM的事务提交分为五个阶段：
- 执行阶段：首先在CM执行事务，并将事务执行结果缓存在CM本地（乐观并发控制）
- Lock(上锁阶段)：CM将事务所需要的锁记录写入到参与事务的primary服务器上（无法直接响应，不经过CPU），primary在处理记录时，尝试根据记录版本号获取对应锁，如果版本号变更或者锁已被获取，返回失败，CM终止事务；否则在CM收到所有成功信息后，进入下一阶段（通过version+锁实现的乐观并发控制）、
- Validate(验证阶段)：CM在通过one-sided RDMA读取验证所有涉及到的对象的版本号，若版本号出现不一致，则终止事务，否则进入下一阶段（读不需要锁，所以会有这一步，因为读之后事务执行完成之前可能会有其他事务获取锁）
- Commit Backup(备份服务器上提交)：CM向所有的backup服务器发送（one-sided RDMA）Commit backup 信息，当收到所有ACK时，进入下一阶段，否则终止事务
- Commit Primary（主服务器上提交）：CM向所有的primary服务器发送（one-sided RDMA）Commit primary信息，primary收到信息后进行修改+版本变更后，释放对应资源锁，事务结果对客户端可见
- Truncate（日志截断）：CM在收到某条日志的所有ACK后，在下次消息传递时，通过携带截断信息，截断primary和backup对应日志信息，backup在截断日志时真正的执行修改操作
综上所述，可以总结FaRM分布式事务实现区别点如下：
- 乐观并发控制：由于one-sided RDMA不经过CPU
- 两阶段提交：（Lock+Validate）上锁验证截断 +（Commit backup+Commit Primary）主从提交阶段
- 不保留日志：由于底层基于非易失存储（或者说论文中假设底层非易失），对于已经提交日志，无需保留
总结
总觉得FaRM虽然在保证一致性的前提下同时保持了高性能，由于其硬件约束和复杂的分布式事务和容错机制，很难在实际生产场景中应用，其基于乐观并发控制实现的分布式事务思路是读这篇论文的最大收获。