【ToDo】存储设计概述
块存储、文件存储、对象存储：
这三者区别其实主要是访问接口上的。 不是特别准确的简化说法： 块存储给你就是一块未格式化的硬盘分区。文件存储就是给你一个格式化过的硬盘分区（可能是本地也可以是网络上的）。 对象存储给你的是一个存非结构化数据键值数据库。
链接：https://www.zhihu.com/question/43687427/answer/96677826
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
分布式存储相关的系统大概分为几种(这里不说分布式计算相关系统)：
1. 分布式文件系统，比如HDFS，Ceph。这些专门存大文件。特别是HDFS大公司标配，不多说。
2. 对象存储，典型的就是Amazon S3，这种系统很多公司自己造给公司内部用，存图片等小文件，接口一般不会兼容Amazon S3，因为不需要，比如淘宝的TFS，基本思路就是将多个小文件合并成大文件存储，经典论文FB的HayStack。这种系统一般读多写少，不需要修改，很少删除，一致性也没那么强，系统相对好做。基本上HDFS+HBase就能搞定一个这种系统，HBase存元数据，利用HDFS的Append功能将小文件合并成大文件。
3. 分布式数据库。对外数据模型是一张表格(底层可以是一个分布式KV)。比如HBase(BigTable)，阿里的OceanBase，国外的cockroachdb(GitHub - cockroachdb/cockroach: A Scalable, Survivable, Strongly-Consistent SQL Database，基本上你能看懂理解它的设计文档，水平就很不错了)还有前同事的创业项目TIKV(https://github.com/pingcap/tikv 想做数据库的可以投简历)。这些都是强一致性OLTP数据库，除了HBase，其他两个都支持分布式事务。分布式事务和多副本强一致性都是比较难做的事情，分布式事务基本都是两阶段提交，实现过程中需要处理协调者/参与者故障问题，这就需要协调者/参与者多副本。同时，为了高可用，容错，每份数据也要多副本。如何维护副本的一致性又是个大问题。OceanBase使用Multi-Paxos，corckroachdb使用Raft， https://ramcloud.stanford.edu/~ongaro/userstudy/， 目前我看到过的最好的将Multi-Paxos和Raft的资料。Paxos的设计仅仅是考虑对一个值达成一致，Paxos协议本身没有考虑工程中的应用，故没有考虑日志同步。所以有了Multi-Paxos。Raft出现的晚，把工程中的问题考虑在内，其中的限制就是日志同步要求顺序。而Multi-Paxos没这个要求，相应的实现也更复杂。由于Paxos对一个值达成一致需要两轮，为了提高性能，引入主，只有主能propose日志，这样Paxos第一轮就不需要。这就需要选主算法，选主算法有很多，比如基于IP，或者直接基于Paxos都行。然后就是成员变更，即扩容缩容问题。Raft再一次考虑在内。其实这里关于一致性直接就说了高级的协议，这些高级协议能够在多点写的情况下也能保证一致性。相对来说"低级"的做法就类似于NWR，写成功需要写majority成功，读也需要读majority，它就不能很好的处理多点写导致的一致性问题，需要应用程序自己选择，代表Dynamo, 这有设计到Vector Clock等技术。然后考虑到负载等原因，还需要对tablet(range)进行分裂啊迁移啊等操作，这也是一个点，大都依赖外部coordinator来解决，比如ZooKeeper，etcd。最后再说一下时序问题，因为是分布式系统，不同的机器时钟不可能一样，或多或少有误差，这就给数据库的外部一致性带来了一些挑战，实际的工程做法一般都是NTP同步啊，当然Google的Spanner比较牛逼，使用硬件实现的原子钟，api叫做TrueTime。还有更理论一些的做法就是logical clock，折中一点的就是HLC，一种逻辑时钟物理时钟混合的方案。
