除了 Aurora 以外，Remzi 团队在 FAST 2020 上的 Best Paper：“Strong and Efficient Consistency with Consistency-Aware Durability”，我认为也是非常有意思的一篇文章。
通常来说，我们在考虑 Consistency 的时候，都会结合 Durability 一起考虑。需要 Strong Consistency，就会用 Distributed Consensus，或者其他的 Replication 方式完成一次 Quorum Write，保证了 Strong Consistency 的同时，也保证了 Durability，代价就是性能差；如果只需要 Weak Consistency，那么就不需要立刻完成 Quorum Write，只需要写一个副本就可以了，然后再异步完成数据同步，这样性能会很好，但是由于没有 Quorum Write，也就丧失了 Durability 和 Consistency。所以大家一直以来的一个共识，就是 Strong Consistency 性能差，Weak Consistency 性能好。
那有没有一种方法既能保证 Strong Consistency，同时又保证 Performance 呢？Remzi 在这篇论文中提出了 “Consistency-Aware Durability”（CAD）的方法，把 Consistency 和 Durability 解耦，放弃了部分 Durability，来保证 Strong Consisteny 和 Performance。实现的方法可以用一句话总结，就是 Replicate on Read。
在 Strong Consistency 中，有一个很重要的要求就是 Monotonic Reads，当读到了一个新版本的数据后，再也不会读到老版本的数据。但换一个角度思考，如果没有读发生，是不存在什么 Monotonic Reads 的，也就不需要做任何为了为了保证 Consistency 的工作（是不是有点像薛定谔的猫？）。
我们在写时做 Replication，完全是为了保证 Durability，顺便完成了保证 Consistency。如果我们可以牺牲 Durability，那么在写入时，我们完全不需要做 Replication，写单复本就可以了。我们只需要在需要 Consistency 的时候（也就是读的时候）完成 Consistency 的操作就可以了（也就是 Replication）。所以我把这种方法叫做 Replicate On Read。
如果你的应用程序属于写多读少的，那么这种方法就可以避免了大量无用的 Replication 操作，仅在必要的时候执行 Replication，也就是读的时候。这样既保证了 Strong Consistency，又保证了 Performance。真是不得不佩服 Remzi，把 Consensus，Consistency，Durability 研究的太透彻了。
可能做系统的同学觉得牺牲 Durability 好像不可接受，但是在类似互联网应用的场景中，一些临时数据的 Durability 其实是不太重要的，而 Consistency 才是影响体验的核心因素。我们以打车举例，如果你看到司机距离你的位置一开始是 1 公里，然后忽然又变成了 3 公里，这很可能是后台的 NoSQL 数据库发生了一次故障切换，而从节点中保存的数据是一个老数据，导致破坏了 Monotonic Reads。而司机位置这种数据是完全没有必要保证 Durability 的，那么在这种情况下利用比较小的代价来保证 Monotonic Reads，将极大地改善用户的体验，你会看到司机和你的距离会越来越近，而不是忽远忽近。