gfs论文发表哪一年

没有那么容易，比较难分布式工程学是一门实践性很强的工科学。所以会出现与其他工科一样的现象就是实践会先于理论。在1960年末被公认为是第一个分布式系统的ARPANET就诞生于美国[1]。在美国50年代到60年受曼哈顿计划的影响，计算机理论迎来了大爆炸的时代。在那个年代发明了我们今天所用到的大部分计算机理论。作为一个新兴学科，当年的科学家大都是刚刚毕业正是壮年。而今他们大多已经是高龄老人，有些科学家则已经离世。在这里向哪些为计算机理论作出贡献的科学家们表示敬意。

等会让他赶紧染发剂对人体

在1997年Karger发表的论文中首次使用了一致性哈希的术语。虽然Teradata公司在1986年开发的分布式数据中已经...

分布式工程学是一门实践性很强的工科学。所以会出现与其他工科一样的现象就是实践会先于理论。在1960年末被公认为是第一个分布式系统的ARPANET就诞生于美国[1]。在美国50年代到60年受曼哈顿计划的影响，计算机理论迎来了大爆炸的时代。在那个年代发明了我们今天所用到的大部分计算机理论。作为一个新兴学科，当年的科学家大都是刚刚毕业正是壮年。而今他们大多已经是高龄老人，有些科学家则已经离世。在这里向哪些为计算机理论作出贡献的科学家们表示敬意。

CS7680著名的9个论述 也是这门课推荐对于分布式系统的一个初步认识 windows live的架构师james总结一系列大型后台服务的设计原则CAP 准确说是一篇blog，很精简，文字也不多，其实文中的图比文字更清晰。cap的理解也经历了一些纠结的过程，这一篇其实是作者多年后的二次理解。所以出错其实没啥问题，这位老板就完全推翻了之前文章里的阐述 也是通俗易懂的入门介绍cap的blog brewer多年以后写的关于cap的一些误解，C和A并不是完全对立的状态 是对上面这片文章的review心得 开始用了两个新名词来阐述A)yield, which is the probability of completing a request .感觉说的就是AB)harvest ,measures the fraction of the data reflected in the response.感觉说的就是C这篇论文对于available提出里两个比较好的方案：1)牺牲harvest换来yield2）应用架构拆分 和 正交机制BASE base一致性的开山鼻祖，首次提出了和acid相反的一种理论，论文中给出了一些单机事务到多机事务的演进过程，并没有觉得很理论，工程很值得借鉴一致性 一致性的模型，高屋建瓴，是一篇blog 概述的文章 先看看sequential consistency lamport大神不用过多的介绍，读他的论文唯一的感受就是智商的差别吧 也是线性一致性的文章 作者在cmu发表的eventual consistency最终一致性的文章首推 aws的cto 讲了一些高可用和一致性之间的trade-off 描述了 最终一致性 和 因果一致性的关系 consistency Bolt-on的架构设计 cops的架构设计 一个causal consistency的db设计与实现从前三篇文章的作者来看，ucb & cmu&priceton 还是很值得一读的最后一篇的年代已经久远，其实发现计算机的一些理论基础其实是很经得起时间的考验的，所以码农其实也可以过的没有那么的有危机感^_^ 这个是最后一篇论文的ppt版本 consistency分布式锁 Google出品的chubby 必属精品 Yahoo的zookeeper分布式kv存储 Google三驾马车之一bigtable,hbase的蓝本 Google三架马车之二gfs，hdfs的蓝本 Google三架马车之三bigtable，hbase的蓝本 现代很多的kv设计或多或少的都参考了先驱dynamo的设计，值得刷10遍以上。读后感 2009年Cassandra设计的论文 ，很多思想借鉴了dynamo，对于一致性哈希的吐槽也高度类似。在replication的过程中，也会通过一个coordinator节点（master节点）来对其他节点进行replicate（这一点和dynamo一样），但是Cassandra提供了一系列的replicate policy可以选择，比如 Rack Unaware, Rack Aware (within a datacenter) and Datacenter Aware. Cassandra也沿用了dynamo里面关于preference list的定义 ucb出的一篇高性能的kv存储，号称比redis快几十倍，使用coordination-free consistency models。虽然说是特别快，但是其实业界的是用并不广泛 时间序列的数据库的一篇介绍 ，介绍了几个应用场景 iot ebay等 ，influxdb的介绍 比较了业界的几种TSDB的异同无论是kv还是传统的关系型数据库，在分布式系统里面无非都会涉及到以下这几方面replication 指出了一种在replication中存在的问题，并给出了解决方案partition&shard分区都逃不了一致性哈希， 被引用度特别高的一篇文章,但是这个版本也是被吐槽最多的，dynamo吐槽过，Cassandra也吐槽了一把1）First, the random position assignment of each node on the ring leads to non-uniform data and load distribution.2）Second, the basic algorithm is oblivious to the heterogeneity in the performance of nodes.解决方案1）One is for nodes to get assigned to multiple positions in the circle (like in Dynamo) dynamo用的就是这种方法2）the second is to analyze load information on the ring and have lightly loaded nodes move on the ring to alleviate heavily loaded nodes 这种方法被Cassandra采用 2）用的方法 也就是这片论文提出的方法memshipfailure detectupdated conflictsimplement关于实现 这篇论文的出镜率特别高，里面的思想被Cassandra和dynamo都采用了 ，作者也是提出cap的大神Eric Brewer（第三作者），值得反复研读 这个是2019年Google提出的一种有状态的kv存储的思路。在工业界的下个请求依赖于上一个请求的情况数据库查询优化器 现在很火的kafa最初设计的论文，细节有些已经被优化，基本的架构还是很值得反复研读。比如In general, Kafka only guarantees at-least-once delivery. Exactly once delivery typically requires two-phase commits and is not necessary for our applications最初kafka只是支持at-least的delivery, 但是不支持exactly once的投递，具体哪个版本开始支持有点记不清了分布式文件系统除了大名鼎鼎的gfs 分布式文件系统已经走过了好几十个年头了 1990年的coda，在很多的论文中出镜率非常高，后面的fs也借鉴了coda的一些思想分布式事务&事务隔离级别 引用率很高的一篇文章 这里面也引用了下面的这篇文章中关于事务隔离级别P0，P1的引用，看之前可以先看下面这篇文章。比如，脏写，脏读，不可重复读&fuzzy读，幻读等读未提交保证了写的串行化，注意只是写的串行化（并不能保证读写的串行化，依然有可能产生脏读），下面这篇论文里面是避免了脏写的操作。如何处理写的冲突呢？ 打时间戳或者last write win的方式都是可行的 不管是怎么讲事务隔离级别，最原生的味道是这一篇，其他的文章都是咀嚼过吐出来的其中也参考了 里面阐述了很多隔离级别的标准共识算法 paxos的simple版本，原来的版本太晦涩，lamport大神自己可能发现之前写的太高深了，写了一个通俗易懂的版本 hermes 这个是精简版的raft 里面有些概念如果理解起来吃力可以看下作者的博士毕业论文 里面有download的连接，以下的几篇文章都是raft的推荐 raft 的分析文章 verdi的实现 raft一致性的分析名字服务 zk最初设计的论文，感觉比市面上的一些中文材料好懂，推荐关于consul以及名字服务的实践，medium上面有两篇比较好的文章A Practical Guide to HashiCorp Consul — Part 1 | by Velotio Technologies | Velotio Perspectives | MediumA Practical Guide To HashiCorp Consul — Part 2 | by Velotio Technologies | Velotio Perspectives | Mediumetcd(94) Introduction to etcd v3 - YouTube 一个youtube上的视频比较清楚的介绍了etcd的设计思路etcd保证了强一致性，这一点感觉和consul不太一样高可用性watchable . 这一点和zk比较像，但是consul是使用gossip进行通知的(94) Deep Dive: etcd - Jingyi Hu, Google - YouTube 讲了etcd是如何使用raft来保证一致性的应用在名字服务里面的gossip protocol开始读到这些论文一直不太理解可以应用到那些地方，后面看到consul在使用gossip来进行memship的管理，基本的原理参考了论文：SWIM.pdf (cornell.edu)后来发现如果cpu的负载如果过高，很可能出现误判的情况1707.00788.pdf (arxiv.org) 这篇论文里面比较好的解决了这个问题