实习生面试分布式存储的21道经典试题

一个实习生小朋友骗我说他不会，问我这些题目怎么做。这明摆着换个法子来面试我呀！要是真啥都不会能来我司实习么？全是套路啊。不过原文出题还是很有水平的，所以我决定写一写。

1. 用cas实现spinlock.

spinlock在网上应该一搜一大把，我试着给出一个simple甚至naive的实现。

实习生面试分布式存储的经典试题

若是较真的话可以看看这里。这个题的考点不在这里，问无锁实现，原子操作，ABA问题这些底层方向思路就走偏了。其实多线程的并发安全，跟多个事务的并发安全，在某种程度上是共通的。这才是考察的核心问题，比如我做了一个kv引擎，只提供了get set 和cas操作，那么能否在这个基础上，实现一个锁操作的API？假设我们能实现出锁操作，那我们又能否利用这个锁，实现出跨多个key的修改操作的安全API？如何保证原子语义，要么全成功，要么全失败。

事实上仅用cas这套搞出跨多key的修改是蛮蛋疼的，再细节到网络失败的时候锁的释放，深入思考下就会想到，因为网络是有3态的：成功失败和不可知。一般会基于快照做，只有cas的保证太弱了。

cas提供的原子性，这是一个很重要的点，假设在分布式的事务里面，跨分片的事务提供能否成功，只取决于一个primary key的提交是否能成功。这里有两个问题思考一下也挺有意思，第一，跨多机的时候，如何提供对某一个key的原子语义？第二，如果只有对一个key的原子保证，如果实现跨许多机器跨多个key-value的原子操作语义？

扯淡扯远了，我们看下一题吧。

2. 实现单机kv存储系统，多节点共享kv存储服务，怎么解决external consistency的问题？

kv存储N=0

用户A和B操作kv存储系统按照下面时序：

1.用户A执行操作： INC N;

2.用户A通知用户B执行操作;

3.用户B执行操作： if （N % 2 == 0） {N*=2;} else {N +=3;}

怎么保证结果符合预期呢？在网络传输影响操作到达次序的情况下，怎么保证B后于A完成操作。

如果这个过程插入了C，又如何做呢？

外部一致性我记得不是太清了（假装一脸认真），产生因果关系的操作之间，执行顺序满足因的操作应该先于果？有点像因果率一致？A操作引发了B，那么B一定应该看得到A执行产生的结果。这个例子里面因为这个因果关系，似乎是希望B看到的值应该是N INC之后的值。

两个操作都访问到了N，如果保证操作的安全？无非是，加锁和MVCC。加锁很好理解，读写锁，写写冲突，读写冲突。那么该如何理解MVCC？MVCC其实很类似一个特殊的cas，它保证了涉及到跨多key修改的原子操作语义，这样也可以理解为什么MVCC可以把并发粒度控制得更好。

这里是说的单机存储引擎，如果放到分布式里面会更复杂一点。事务A的开始时间戳先于事务B，但是事务B的提交却先于A，这时会发生什么事情？用多版本带一个逻辑时钟，就可以处理这种情况：假设A做INC N操作的时候逻辑时间是5，给B发消息变成6，B收到消息以后，它操作的N的版本应该是6以后的。只需要逻辑时钟，就可以检测到有相互关联性的事务。如果这个过程插入了C，如果C跟A和B没有共同修改的key，那么C的影响可以忽略。如果有修改到N，但是没有跟A和B交互，那么可以认为C的存在与其它用户并没有因果关系，逻辑时钟也不会检测到这一点，是能满足external consistency的。

3. 锁实现和版本控制用那个呢？

两者都是方法和手段，并不冲突和矛盾。锁有很多不同的粒度，比如一把全局的大锁;再比如读写锁，任一时刻如果有写，就不能进行其它操作，而读锁之间相互不影响;我看了好些傻逼的实现都是一把全局大锁，像boltdb，还有leveldb的Go语言封装里面提供的Transaction接口，都是很没节操的。前阵子我还考虑过写一个RangeLock，调整锁的粒度：只有被同步访问到的key之间，才会有锁冲突，比如我在操作A他在操作B，相互是不影响的。遇到锁冲突了会变得复杂，回滚操作必须记得释放之前的锁，加锁也要有点技巧，如果一个操作锁了A去请求B，另一个操作锁了B去请求A，就成环死锁了。

MVCC也会遇到冲突，冲突时无非两种手段：过一会儿重试或者abort。看！这本质上也是锁，乐观锁悲观锁而已。所以并不是用了MVCC锁的概念就消失了。不过MVCC是个好东西，它比锁可以提供更细粒度的并发。通过读历史版本，让读和写之间的冲突进一步降低。代价当然是问题被搞得更加复杂了。

如何选择？根据实际的场景具体情况具体去分析。挑选适当的隔离级别，RC/RR/SI。

4. kv系统数据要持久化，怎么保证在供电故障的情况下，依然不丢数据。

先写WAL再做写操作，常识。出故障了从check point重放日志，就可以恢复之前的状态机。

5. flush/fsync/WAL/磁盘和ssd的顺序写

说到这个问题，就不得不先从缓存聊起。由于下一级的硬件跟不上上一级的读写速度，缓存这东西应运而生。硬盘有缓存，操作系统有缓存，标准库也有缓存，用户还可能自己设缓存，总之是各种的缓存。命中缓存时，可以大大提高读的速度，只有当缓存穿透才会到下层去请求数据。写操作也由于缓存的存在而变成了批量操作，吞吐得以提高。

然而写的时候遇到突然断电的情况，数据还在缓存层没刷下去，就尴尬了。。。会丢数据！如果要保证可靠写这里我们需要采取些法子，手动将缓存刷进磁盘里。

flush是刷C标准库的IO缓存。fsync是系统调用，页缓存会被刷到磁盘上。

写IO有好多种方式，最笨的调用C的IO库，然后还有操作系统的read/write，或者mmap又或者使用direct-io，甚至是写祼设备。关于这些写下去相关知识也不少。

WAL是常识性的东西，先出日志，重放日志就可以得到快照，即使快照坏掉了，重放日志也可以恢复出正常的快照。而且做同步一般都是基于日志来做的。

最后是磁盘和ssd，了解硬件的特性对于理解优化非常重要。磁盘是需要寻道的，而寻道的硬件机制决定了这个操作快不了。硬盘顺序读写本身的速率比较快，但寻道却要花掉10ms，所以随机读写性能会比较着。ssd那边没有寻道操作，读的速度非常快。然而顺序写的优势相对磁盘并没有高多少。如果没记错，ssd大概就200MB/s的级别，而磁盘顺序写也有接近100MB的级别。