几句话说说跨IDC分布式数据库Calvin

浏览数：17 / 时间：2015年06月12日

CalvinFS拿了FAST 15最佳论文；找到了失联十三年的小伙伴；年终/年初整理资料，发现做团委工作的 King 师兄对Calvin有兴趣；最近其他团队对分布式事务和存储问题/兴趣较多……几件事激发了我写这本文的动机，要知道上一篇是2012年的（虽然一直有做个人学习、工作笔记）。

Yale的CalvinFS最有价值的就是元数据管理部分，也就是Calvin（的修改版）。没有跨IDC的Calvin，也就没有跨IDC的CalvinFS。以下的内容以旁观者角度写，一些问题简单描述，但是实际上非常难处理，Calvin等分布式系统的作者可能是花了大量精力才完成。在进入Calvin内容之前先提两个东西。

一个是ACID和CAP——因为里边都有A、C，所以放一起提:P 。ACID是数据库的概念，说的是事务；CAP是分布式系统的概念，说的是不存在三者完美的系统。A和C在两者里边是不同的。ACID里边的A是说原子性，而CAP里的A是可用性；而关于C，前者说的是相关内容（如索引与数据、关联等）的进行一致地变化，后者一般说的是同一内容几个副本一致进行变化，。ACID里边I是隔离性，D是持久性，都比较好理解。CAP中的P则是说分区容忍。

另一个是2PC和Paxos。首先，Paxos变种太多的，网上资料经常把几种变种混成一个，建议想了解还是看书或是原始论文吧。提分布式事务就会提到2PC、3PC、PAXOS，中间那种一般没人用不说。2PC主要问题在于阻塞，非coordinator服务挂掉基本都有较好的方案处理，而coordinator在prepare收到全部都是ok后挂掉……而PAXOS方面，自从有了zookeeper之后，也很多人用起来了，除了同步数据外，还有一些应用场景是HA选主等。

一般高大上的功能都伴随着CAP中某方面的妥协，Calvin也不例外。机器挂掉或是IDC出故障等P方面的问题总是存在的，一般只能在A和C里做选择，calvin主要牺牲的是A可用性（这个跟Spanner的选择是类似的，其实也是现在慢慢被认可的方向）。spanner得益于其truetime全局逻辑时间的设计，达到了外部一致性的级别，现实系统不可能做得更好。而Calvin则选择了顺序一致性，也就比外部一致性弱一些。但是所有的系统或设计都是分场景的，Calvin也不例外，虽然它提供了强一致的级别，支持ACID，但不代表一定要在所有场景下无条件放弃对A的追求。强一致的事务只是提供了一种选择，在不需要这方面保证（隔离性I、一致性C）时，直接跳过这一层可提升性能（可用性方面）；虽然强一致带来的代价一定要存在，但是可以考虑把代价转移到不常用的地方去，比如读写场景中，增加写延时来优化读性能；同时，即便是写场景，一定程度上牺牲延迟，但是换取更大吞吐也成为很多跨IDC系统的设计方向。

上边提到了事务和一致性，这方面在calvin里的实现是很有意思的，走了一条跟时间流行方向不同的路线。分布式系统设计中，事务是一个难点。2PC的阻塞问题通过虚拟节点可以缓解，spanner在2pc下层放了paxos是一个意思。但是这总是一个问题，而且典型系统中的并发更新带来的死锁问题，在更新操作变重的分布式系统中会被放大。calvin直接干掉了2PC，这是通过把更新操作而不是更新结果做同步来达到，其实也就是用全局的队列（paxos实现），来同步操作日志。而死锁方面则通过预先定义读写set和ordered lock来规避(一些事务不能预先定义读写set的要用到OLLP机制)。这种事务设计，对单个机器上的请求返回速度比较敏感，特别是为了批量处理而人为地引入了一个最大10ms等待时间之后。calvin用了一个warm up的方案来弥补，挺有意思的，思想就是把一些事情放到事务开始前，把数据提前load到内存。但是需要注意到的是，因为同步的是操作日志而不是结果，所以要求各副本在收到相同日志后，应该有相同的结果，也就是说不确定性因素（如本机硬盘坏）等引起的问题不能abort事务。这是相比2PC方案的缺点，在这种情况下，出问题的副本只能自行同步/恢复到正确副本的状态上去。这里边有一个想要吐嘈的地方：哪些场景下应该warm-up，应该warm-up哪些数据，这两个问题是warm-up机制需要处理的，而calvin论文中对前者是直接实验出一个经验值，后者是暂时没有好方案……

Calvin除了deterministic这点外，其他是很多思路包括跨IDC延时现状的情况下，尽力提升吞吐和主要场景性能等现在已经是大多数分布式系统设计时的同识/方向。其设计的线性化扩展能力也是其他系统也在追寻的，虽然我对它的性能扩展能力有一些疑问……