分布式存储相关的系统大概分为几种(这里不说分布式计算相关系统)：
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，一种逻辑时钟物理时钟混合的方案。

对新手来说，可以刷MIT的这门课，http://nil.csail.mit.edu/6.824/2016/schedule.html
作业基于Golang，开发效率高，以前都是C++。
中文博客的话可以看 emailed – 博客园 上面提到的很多技术博客中都有讲到。