怎么做分布式存储的面试?

作者：佚名 2017-08-17 09:18:29

存储

存储软件

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

创新互联建站10多年企业网站制作服务;为您提供网站建设,网站制作,网页设计及高端网站定制服务,企业网站制作及推广,对自拌料搅拌车等多个方面拥有丰富的网站维护经验的网站建设公司。

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

1. 用cas实现spinlock.

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

  
 
 
   
  
  type SpinLock struct {    
  
      count uint64    
  
  }    
  
  func (l *SpinLock) Lock() {    
  
      for !atomic.CompareAndSwapUint64(&l.count, 0, 1) {    
  
      }    
  
  }    
  
  func (l *SpinLock) Unlock() {    
  
      atomic.StoreUint64(&l.count, 0)    
  
  }

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

[[200313]]

事实上仅用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的级别。

6. 单机kv存储系统, 从掉电到系统重启这段时间, 不可用, 如何保证可用性呢?

要有副本。不然哪来可用性A?而有了副本，一致性C又麻烦来了，呵呵。

7. 数据复制, 日志复制, 有哪些实现方法呢?

做数据同步操作时，一般是找到快照点，将快照的数据发过去，之后再从放这个点之后的日志数据。回放日志就可以增量同步了，不过增量同步也有不爽的，中间断了太多就需要重新全量。最蛋疼的问题是，增量同步只能做最终一致性。主挂了切到从，丢一段时间的数据。

8. 做主从复制, 采用pull和push操作, 那个好呢?

如果保证一致性，由主push并收到应答处理。如果不保证，由从做pull比较好，从可以挂多个，还可以串起来玩。

9. 如何保证多副本的一致性? RSM

副本是一致性的最大敌人，一旦有了副本，就有可能出现副本间不同步的情况。异步写的方式顶多只能做到最终一致性，所以必须同步写。写主之后，同步完其它节点从才返回结果。不过写所有节点太慢了，而且挂掉节点时可用性有问题。

在raft出来之前，号称工业上唯一只有一种一致性协议的实现，就是paxos。然而paxos即难懂，又难实现。无论对于教育还是工程角度都它妈蛋疼的要死，还它妈的统治了业界这么多年。强势安利一波raft。

10. 分布式共识算法: zab, paxos, raft.

zab还没研究过。basic paxos还勉强能看一看，multi paxos就蛋疼了，看得云里雾里。raft我写过几篇博客，话题太大，这里不展开了。不过不管是哪一种，搞分布式是逃不掉的。

11. commit语意是什么呢?

私以为是ACID里面的D，持久性。一旦提交了，就不会丢。

12. 单机或者单个leader的qps/tps较低, 如何扩大十倍?

如果能加机器就搞分布式。做分布式就走两个方向：可以分片就让leader分片，负载就分摊开了吞吐就上来了;可以副本就考虑走follower read，压力就分到了follower中。只要架构做的scalable了，扩大10倍1000都好说。

如果不能走分布式，就考虑优化单机性能。网络的瓶颈就batch + streaming。CPU，内存什么都不说了。硬盘不行就换SSD。

如果是qps，读嘛，该上缓存上缓存。唯有写是不好优化的，tps就合理选择LSM存储引擎，合并写操作，顺序写。怎么让系统性能更好这个话题，展开就更多了，不过最后我还是想讲个笑话。

某大厂某部门半年间系统性能优化了3倍，怎么优化的?因为他们升级了最新版本的php，php编译器的性能提升了3倍。所以嘛...问我怎么优化?升级硬件吧，升级更牛B的硬件，立杆见影。我们客户把TiDB的硬盘升级到了SSD，性能立马提升了10倍。

13. 怎么做partitioning和replicating呢?

分片和副本，分布式系统里面的三板斧。系统规模大了，单机承受不住，肯定就分片。做存储是有状态服务，不能单个分片挂了系统就挂了，于是必须有副本。其实两个都麻烦。

分片的麻烦的关键，在于分片调整。比如按hash分的，按range分的，只要涉及调整，就蛋疼。数据迁移是免不了，如果整个过程是无缝的?如果做到不停机升级?升级处理过程中，无信息的更新以及一致性，都是比较恶心的。

副本麻烦的关键，就是一致性了。有副本就引入了一致性问题，paxos可以解救你，如果大脑不会暴掉。

具体的怎么分片还是看业务的。而副本什么也看一致性级别要求，强同步，半同步，最终一致性乱七八糟的。

14. 存储或者访问热点问题, 应该怎么搞?

加缓存。或者业务调整看能否hash将访问打散。

15. CAP原理

去问google。先问google。容易google到的都不要问我。谁要问我这种东西，我拒绝回答，并给他一个链接：《提问的智慧》。

16. 元数据怎么管理?

etcd呀。开源这么多轮子，不好好用多浪费。

17. membership怎么管理?

etcd呀。lease。上线下线都注意走好流程。

18. 暂时性故障和永久性故障有哪些呢?

暂时性故障：网络闪断，磁盘空间满了，断电，整机房掉电，光纤被挖断了(中国大的互联网公司服务质量的头号敌人)，被ddos了永久性故障：硬盘挂了，系统挂了，被墙了。

擦，我分不清勒。

19. failover和data replication怎么搞呢?

haproxy

20. 磁盘的年故障率预估是多少?

待会去google一下。先瞎写写，假设一块磁盘一年故障的概率是P，假设系统有100块磁盘，那么整个系统的磁盘故障率就变成了(1-(1-P)^100)，我知道这个概率会变得非常大。

这时我们考虑RAID的情况。RAID 0卵用都没有，坏一块就坏了。计算公式跟之前一样的。RAID 1两块盘互为镜像，可以把P就成P/4。还有RAID 01/10，怎么计算来的?还有就是纠错码技术。计算更复杂了。

分布式以后，上层可以控制分片和副本数，跟RAID一个道理，然后挂一个副本不会挂，要挂掉系统的大多数......但是故障率是多少呢?操!数学没学好，怎么办啊?

ssd跟磁盘不一样的地方，它以整个block为单位操作，在写入之前需要先擦除，而擦除的次数是有上限的，所以寿命比磁盘的要短很多。具体是多久，还是得问google。

21. kv系统存储小王, 小李, 小张三个人的账户余额信息, 数据分别在不同的节点上, 怎么解决小王向小李, 小李向小张同时转款的问题呢?

两阶段提交。打个广告：我们的TiKV提供了分布式事务，这个问题很好解决。

  
 
 
   
  
  Prewrite 小王账户减;小张账户加 Commit     
  
  Prewrite 小张账户减;小李账户加 Commit

搞定!

真是越写越是瞎扯淡去了...要是让我们的实习生面试我，估计我要挂...也许当初是混进公司的吧，嘘!别让老板知道了。

文章题目：怎么做分布式存储的面试?
网址分享：http://www.shufengxianlan.com/qtweb/news26/502976.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：创新互联

猜你还喜欢下面的内容