分布式系统在互联网时代，尤其是大数据时代到来之后，成为了每个程序员的必备技能之一。分布式系统从上个世纪80年代就开始有了不少出色的研究和论文，我在这里只列举最近15年范围以内我觉得有重大影响意义的15篇论文（15 within 15）。
1. The Google File System: 这是分布式文件系统领域划时代意义的论文，文中的多副本机制、控制流与数据流隔离和追加写模式等概念几乎成为了分布式文件系统领域的标准，其影响之深远通过其5000+的引用就可见一斑了，Apache Hadoop鼎鼎大名的HDFS就是GFS的模仿之作；
2. MapReduce: Simplified Data Processing on Large Clusters：这篇也是Google的大作，通过Map和Reduce两个操作，大大简化了分布式计算的复杂度，使得任何需要的程序员都可以编写分布式计算程序，其中使用到的技术值得我们好好学习：简约而不简单！Hadoop也根据这篇论文做了一个开源的MapReduce；
3. Bigtable: A Distributed Storage System for Structured Data：Google在NoSQL领域的分布式表格系统，LSM树的最好使用范例，广泛使用到了网页索引存储、YouTube数据管理等业务，Hadoop对应的开源系统叫HBase（我在前公司任职时也开发过一个相应的系统叫BladeCube，性能较HBase有数倍提升）；
4. The Chubby lock service for loosely-coupled distributed systems：Google的分布式锁服务，基于Paxos协议，这篇文章相比于前三篇可能知道的人就少了，但是其对应的开源系统zookeeper几乎是每个后端同学都接触过，其影响力其实不亚于前三篇；
5. Finding a Needle in Haystack: Facebook's Photo Storage：facebook的在线图片存储系统，目前来看是对小文件存储的最好解决方案之一，facebook目前通过该系统存储了超过300PB的数据，一个师兄就在这个团队工作，听过很多有意思的事情（我在前公司的时候开发过一个类似的系统pallas，不仅支持副本，还支持Reed Solomon-LRC，性能也有较多优化）；
6. Windows Azure Storage: a highly available cloud storage service with strong consistency：windows azure的总体介绍文章，是一篇很好的描述云存储架构的论文，其中通过分层来同时保证可用性和一致性的思路在现实工作中也给了我很多启发；
7. GraphLab: A New Framework for Parallel Machine Learning：CMU基于图计算的分布式机器学习框架，目前已经成立了专门的商业公司，在分布式机器学习上很有两把刷子，其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟；
8. Resilient Distributed Datasets: A Fault-Tolerant Abstraction for
In-Memory Cluster Computing：其实就是 Spark，目前这两年最流行的内存计算模式，通过RDD和lineage大大简化了分布式计算框架，通常几行scala代码就可以搞定原来上千行MapReduce代码才能搞定的问题，大有取代MapReduce的趋势；
9. Scaling Distributed Machine Learning with the Parameter Server：百度少帅李沐大作，目前大规模分布式学习各家公司主要都是使用ps，ps具备良好的可扩展性，使得大数据时代的大规模分布式学习成为可能，包括Google的深度学习模型也是通过ps训练实现，是目前最流行的分布式学习框架，豆瓣的开源系统paracell也是ps的一个实现；
10. Dremel: Interactive Analysis of Web-Scale Datasets：Google的大规模（近）实时数据分析系统，号称可以在3秒相应1PB数据的分析请求，内部使用到了查询树来优化分析速度，其开源实现为Drill，在工业界对实时数据分析也是比价有影响力；
11. Pregel: a system for large-scale graph processing: Google的大规模图计算系统，相当长一段时间是Google PageRank的主要计算系统，对开源的影响也很大（包括GraphLab和GraphChi）；
12. Spanner: Google's Globally-Distributed Database：这是第一个全球意义上的分布式数据库，Google的出品。其中介绍了很多一致性方面的设计考虑，简单起见，还采用了GPS和原子钟确保时间最大误差在20ns以内，保证了事务的时间序，同样在分布式系统方面具有很强的借鉴意义；
13. Dynamo: Amazon’s Highly Available Key-value Store：Amazon的分布式NoSQL数据库，意义相当于BigTable对于Google，于BigTable不同的是，Dynamo保证CAP中的AP，C通过vector clock做弱保证，对应的开源系统为Cassandra；
14. S4: Distributed Stream Computing Platform：Yahoo出品的流式计算系统，目前最流行的两大流式计算系统之一（另一个是storm），Yahoo的主要广告计算平台；
15. Storm @Twitter：这个系统不多说，开启了流式计算的新纪元，几乎是所有公司流式计算的首选，绝对值得关注；
补充三篇论文:
1. Sinfonia: A New Paradigm for Building Scalable Distributed Systems，这篇论文是SOSP2007的Best Paper，阐述了一种构建分布式文件系统的范式方法，个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文。
2. The Chubby lock service for loosely-coupled distributed systems，，这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁，Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的，所以Chubby实际上是Google分布式事务的基础，具有非常高的参考价值。另外，著名的zookeeper就是基于Chubby的开源实现，但是根据在Google工作的朋友讲，zookeeper跟Chubby在性能和功能上都还有差距。
3. Spanner: Google's Globally-Distributed Database，这个是第一个全球意义上的分布式数据库，也是Google的作品。其中介绍了很多一致性方面的设计考虑，为了简单的逻辑设计，还采用了原子钟，同样在分布式系统方面具有很强的借鉴意义。
另外，还有一本书:
刚出的，读了一下样章，感觉还不错，一起推荐给大家——《大规模分布式存储系统:原理解析与架构实战》华章图书 - 大规模分布式存储系统:原理解析与架构实战
在计算机科学中，分布式计算（英语：Distributed computing，又译为分散式计算）这个研究领域，主要研究分散系统（Distributed system）如何进行计算。分散系统是一组电子计算机（computer），通过计算机网络相互链接与通信后形成的系统。把需要进行大量计算的工程数据分区成小块，由多台计算机分别计算，在上传运算结果后，将结果统一合并得出数据结论的科学。目前常见的分布式计算项目通常使用世界各地上千万志愿者计算机的闲置计算能力，通过互联网进行数据传输。如分析计算蛋白质的内部结构和相关药物的Folding@home项目，该项目结构庞大，需要惊人的计算量，由一台电脑计算是不可能完成的。
最近的分布式计算项目已经被用于使用世界各地成千上万位志愿者的计算机的闲置计算能力，通过因特网，您可以分析来自外太空的电讯号，寻找隐蔽的黑洞，并探索可能存在的外星智慧生命；您可以寻找超过1000万位数字的梅森质数；您也可以寻找并发现对抗艾滋病病毒的更为有效的药物。这些项目都很庞大，需要惊人的计算量，仅仅由单个的电脑或是个人在一个能让人接受的时间内计算完成是决不可能的。
美国计算机科学家，LaTex的作者Leslie Lamport说：“分布式系统就是这样一个系统，系统中一个你甚至都不知道的计算机出了故障，却可能导致你自己的计算机不可用。”一语道破了开发分布式系统的玄机，那就是它的复杂与不可控。所以Martin Fowler强调：分布式调用的第一原则就是不要分布式。这句话看似颇具哲理，然而就企业应用系统而言，只要整个系统在不停地演化，并有多个子系统共同存在时，这条原则就会被迫打破。盖因为在当今的企业应用系统中，很难寻找到完全不需要分布式调用的场景。Martin Fowler提出的这条原则，一方面是希望设计者能够审慎地对待分布式调用，另一方面却也是分布式系统自身存在的缺陷所致。无论是CORBA，还是EJB 2；无论是RPC平台，还是Web Service，都因为驻留在不同进程空间的分布式组件，而引入额外的复杂度，并可能对系统的效率、可靠性、可预测性等诸多方面带来负面的影响。 然而，不可否认的是在企业应用系统领域，我们总是会面对不同系统之间的通信、集成与整合，尤其当面临异构系统时，这种分布式的调用与通信变得越重要，它在架构设计中就更加凸显其价值。并且，从业务分析与架构质量的角度来讲，我们也希望在系统架构中尽可能地形成对服务的重用，通过独立运行在进程中服务的形式，彻底解除客户端与服务端的耦合。这常常是架构演化的必然道路。在我的同事陈金洲发表在InfoQ上的文章《架构腐化之谜》中，就认为可以通过“将独立的模块放入独立的进程”来解决架构因为代码规模变大而腐化的问题。 随着网络基础设施的逐步成熟，从RPC进化到Web Service，并在业界开始普遍推行SOA，再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广，分布式架构在企业应用中开始呈现出不同的风貌，然而殊途同归，这些分布式架构的目标仍然是希望回到建造巴别塔的时代，系统之间的交流不再为不同语言与平台的隔阂而产生障碍。正如Martin Fowler在《企业集成模式》一书的序中写道：“集成之所以重要是因为相互独立的应用是没有生命力的。我们需要一种技术能将在设计时并未考虑互操作的应用集成起来，打破它们之间的隔阂，获得比单个应用更多的效益”。这或许是分布式架构存在的主要意义。
