分布式资源笔记

http://www.cnblogs.com/duguguiyu/archive/2009/02/22/1396034.html
所谓分布式，在这里，很狭义的指代以Google的三驾马车，GFS、Map/Reduce、BigTable为框架核心的分布式存储和计算系统。通常如我一样初学的人，会以Google这几份经典的论文作为开端的。它们勾勒出了分布式存储和计算的一个基本蓝图，已可窥见其几分风韵，但终究还是由于缺少一些实现的代码和示例，色彩有些斑驳，缺少了点感性。幸好我们还有Open Source，还有Hadoop。Hadoop是一个基于Java实现的，开源的，分布式存储和计算的项目。作为这个领域最富盛名的开源项目之一，它的使用者也是大牌如云，包括了Yahoo，Amazon，Facebook等等（好吧，还可能有校内，不过这真的没啥分量...）。Hadoop本身，实现的是分布式的文件系统HDFS，和分布式的计算（Map/Reduce）框架，此外，它还不是一个人在战斗，Hadoop包含一系列扩展项目，包括了分布式文件数据库HBase（对应Google的BigTable），分布式协同服务ZooKeeper（对应Google的Chubby），等等。。。
如此，一个看上去不错的黄金搭档浮出水面，Google的论文 + Hadoop的实现，顺着论文的框架看具体的实现，用实现来进一步理解论文的逻辑，看上去至少很美。网上有很多前辈们，做过Hadoop相关的源码剖析工作，我关注最多的是这里，目前博主已经完成了HDFS的剖析工作，Map/Reduce的剖析正火热进行中，更新频率之高，剖析之详尽，都是难得一见的，所以，走过路过一定不要错过了。此外，还有很多Hadoop的关注者和使用者贴过相关的文章，比如：这里，这里。也可以去Hadoop的中文站点（不知是民间还是官方...），搜罗一些学习资料。。。
我个人从上述资料中受益匪浅，而我自己要做的整理，与原始的源码剖析有些不同，不是依照实现的模块，而是基于论文的脉络和实现这样系统的基本脉络来进行的，也算，从另一个角度给出一些东西吧。鉴于个人对于分布式系统的理解非常的浅薄，缺少足够的实践经验，深入的问题就不班门弄斧了，仅做梳理和解析，大牛至此，可绕路而行了。。。

http://www.kuqin.com/system-analysis/20090125/33295.html
我们并非一概不使用事务。我们只是不使用跨物理资源的事务，因为它会造成多个组件之间出现依赖。组件可以是应用服务器和数据库。（例如在客户端控制的事务中，）一个客户端的失败会长久地阻塞数据库资源、超出我们的忍受程度。我们也不使用分布式事务，因为让应用依赖于多个数据库会降低客户端实际的可用性。相反，我们选择缺少事务的设计，并加入失效模式，失效模式可以使客户端甚至在发生数据库可用性问题的时候也能继续进行。

你的问题背后隐藏的真正问题是我们如何实现一致性？要在大型系统中实现一致性，你必须放弃ACID，转而使用BASE：

基本可用（Basically Available）
软状态（Soft state）
最终一致（Eventually consistent）

如果你能够在每个客户端请求快结束的时候放松对数据一致的要求，就有可能消除分布式事务，并使用其它机制来达成一致的状态。举例来说，在上面的出价案例中，我们也更新视图数据表，视图数据表是按照出价人来组织数据的，目的是加速“我的eBay”页面的显示。这里用两个异步事件来完成。一个是依靠内存中的队列，因为我们希望尽量缩短从出价到在显示在“我的eBay”页面上之间的响应时间。但是，内存中的队列不可靠，所以在发生出价操作的时候，我们同时用一个服务器端事务来捕获出价事件。即使内存中队列的操作失败了，这个出价事件也能根据还原机制被处理。出价人视图数据表因此而解耦，但不总是与出价表的状态保持一致。不过这是我们可以接受的让步，它让出价表和出价视图表之间不必服从ACID要求。

最简单的建议就是，给一个为小规模应用而设计的架构增加资源并不能让它变成大规模的架构。你必须打破常规模式，比如ACID和分布式事务。乐于寻找机会放松一些约束，即使传统上认为是不能放松的。

还有两条简单的原则：把每样东西都设计成分离的；考虑BASE、而不是ACID。

然而，像亚马逊和eBay这样的大型分布式系统，网络分区是既定的。它的后果就是，大型分布式系统的架构必须决定时放松对一致性的要求，还是放松对可用性的要求。


系统架构师角色关键的一方面就是衡量相互冲突的需求、决定解决方案，常常要牺牲一个方面来换取另一个方面。
亚马逊公司的CTO Werner Vogels发布的新帖子讨论了这些基本需求如何应用于基础设施服务，为构建Internet范围的计算平台提供资源。

鉴于这些系统分布在世界范围内，我们处处利用复制技术来保证稳定的性能和高可用性。尽管复制技术使我们达到部分目的，但它的实现并不是完全透明的；在许多情况下，在服务内部使用复制技术都会给服务的客户带来后果。后果之一体现为对数据一致性的限制，特别是在底层分布式系统提供了一种最终一致的数据复制模型的时候。在亚马逊设计这些大型系统时，我们凭借一套有关大规模数据复制的指导原则和抽象，把注意力集中于高可用性和数据一致性之间的权衡选择。
按照Werner所说，考虑一致性有两种方式：一种是从开发者/客户端的角度——他们如何观察数据更新。第二种是从服务器的角度——更新如何流经整个系统，系统对更新有何保证。