knuthocean_whu-CSDN博客

原创分布式事务(一)：Two-phase commit & Three-phase commit

Two-phase commit(http://en.wikipedia.org/wiki/Two-phase_commit_protocol)是分布式事务最基础的协议，Three-phase commit(http://en.wikipedia.org/wiki/Three-phase_commit_protocol)主要解决Two-phase commit中协调者宕机问题。 Two-phase

2009-12-22 23:01:00 614

原创再说Bigtable replication

前面我的一篇文章http://hi.baidu.com/knuthocean/blog/item/12bb9f3dea0e400abba1673c.html引用了对Google App Engine工程师关于Bigtable/Megastore replication的文章。当时留下了很多疑问，比如：为什么Google Bigtable 是按照column family级别而不是按行执行repli

2009-12-18 22:07:00 490

原创 Dynamo(四)：Dynamo优化及优缺点

负载平衡策略Dynamo的负载平衡取决于如何给每台机器分配虚拟节点号。由于集群环境的异构性，每台物理机器包含多个虚拟节点。一般有如下两种分配节点号的方法：1. 随机分配。每台物理节点加入时根据其配置情况随机分配S个Token(节点号)。这种方法的负载平衡效果还是不错的，因为自然界的数据大致是比较随机的，虽然可能出现某段范围的数据特别多的情况（如baidu, sina等

2009-12-05 17:39:00 879

原创 Dynamo(三)：Dynamo的异常处理及读/写流程

异常处理 Dynamo中把异常分为两种类型，临时性的异常和永久性异常。服务器程序运行时一般通过类似supervise的监控daemon启动，出现core dump等异常情况时自动重启。这种异常是临时性的，其它异常如硬盘报修或机器报废等由于其持续时间太长，称之为永久性的。回顾Dynamo的设计，一份数据被写到N, N+1, ... N+K-1这K台机器上，如果机器N+i (0 读/写流程客户

2009-12-05 17:33:00 728

原创 [导入]Dynamo(二)：Dynamo的replication

前文说到，Dynamo DHT能够定位数据所属的节点，为了处理节点失效的情况（DHT环中删除节点），需要对节点的数据进行replication。思路如下：假设数据存储K份，DHT定位到的数据所属节点为N，则数据存储在节点N, N+1, ..., N+K-1上。如果第i (0 为了在可用性和效率之间权衡，Dynamo的设计中允许用户指定读/写个数R和W值。R和W分别表示每个读/写操作需要操作的副本

2009-12-05 17:32:00 478

原创 [导入]Dynamo(一)：一切从DHT开始

DHT全称Distributed Hash Table (en.wikipedia.org/wiki/Distributed_hash_table)，在P2P系统中经常用来定位数据所属机器。这就涉及到一致哈希(consistent hashing)思想，分布式系统中经常出现机器上下线，如果采用通常的Hash方法来查找数据所属机器，机器上下线将导致整个集群的数据分布被打乱。这是因为，机器上下线将导致

2009-12-05 17:31:00 543

原创 [导入]Amazon Dynamo论文阅读笔记(序)

Amazon Dynamo是组合使用P2P各种技术的经典论文，对单机key-value存储系统扩展成分布式系统有借鉴意义，值得仔细推敲。本人准备近期深入阅读该论文，并写下读书笔记自娱自乐。当然，如果有志同道合的同学非常欢迎交流。以下是阅读计划： 1. 一切从DHT开始。Dynamo首先要解决的就是给定关键字key找出服务节点的问题。Dynamo的思想与Chord有些类似，我们可以抛开replica

2009-12-05 17:30:00 860 1

原创分布式系统设计实现的几个现象

分布式系统设计开发过程中有几个比较有意思的现象： 1. CAP原理。CAP分别表示Consistency(一致性), Availability(可访问性), Partition-tolerance(网络分区容忍性)。Consistency指强一致性，符合ACID；Availability指每一个请求都能在确定的时间内返回结果；Partition-tolerance指系统能在网络被分成多个部分，即允

2009-12-05 17:23:00 380

原创分布式相关会议历届最佳论文(05-09)

前几天有同学问分布式系统方向有哪些会议。网上查了一下，顶级的会议是OSDI(Operating System Design and Implementation)和SOSP(Symposium on Operating System Principles)。其它几个会议，如NSDI，FAST，VLDB也常常有让人眼前一亮的论文。值得庆幸的是，现在云计算太火了，GFS/Mapreduce/Bigta

2009-12-05 17:23:00 1053

原创 Key-value存储系统流派

对于Web应用来说，RDBMS在性能和扩展性上有着天生的缺陷，而key-value存储系统通过牺牲关系数据库的事务和范式等要求来换取性能和扩展性，成为了不错的替代品。key-value存储系统设计时一般需要关注扩展性，错误恢复，可靠性等，大致可以分类如下： 1. “山寨“流派：国产的很多系统属于这种类型。这种类型的系统一般不容易扩展，错误恢复和负载平衡等都需要人工介入。由于国内的人力成本较低，这类

2009-12-05 17:23:00 481

原创 Megastore/Bigtable Replication的文章

从Google App Engine中挖出的关于Megastore/Bigtable跨数据中心replication的文章，里面有提到一点点实现，希望对理解Bigtable及其衍生品的replication机制有用。我想指出几点： 1. Bigtable的跨机房replication是保证最终一致性的，Megastore是通过Paxos 将tablet变成可以被跨机房的tablet serv

2009-12-05 17:23:00 392

原创 Replication

分布式系统设计的时候需要考虑Failure Recovery和Replication，从而支持线上实时服务。Replication可简单分为单点的replication及整个系统(数据中心)的replication。为了简单起见，GFS/Mapreduce/Bigtable等分布式系统都采用单Master设计，国内很多互联网公司甚至把写数据节点设计成单点以避开一致性及负载平衡问题，因此Replic

2009-12-05 17:23:00 334

原创名词解释：乐观锁 vs 悲观锁，coarse-grained vs fine-grained

分布式系统或其它论文里面经常出现下面几个名词：乐观锁：有时称作optimistic concurrency control, 指并发控制的时候“乐观”地认为冲突的概率很小，万一发生了冲突再重试。具体表现为事务执行过程中不锁住其它事务，等到事务提交的时候看一下是否发生了冲突，如果冲突则重试或回滚，否则提交事务。悲观锁：并发控制的时候总是很悲观，事务执行过程中锁住其它事务，事务提交时不会有冲突。

2009-12-05 17:23:00 498

原创 Megastore-Bigtable上的封装

Google在SIGMOD 2008上透露了Megastore部分实现细节，详情参考大牛James Hamilton的blog：perspectives.mvdirona.com/2008/07/10/GoogleMegastore.aspx 大牛的文章固然不错，不过肯定不大好懂，下面我说一下我对文章的翻译+理解： 1. Google Bigtable只支持最简单的insert, update,

2009-12-05 17:23:00 589

原创推荐两本分布式系统书籍

推荐两本分布式系统方面书籍： 1. > Andrew S. Tanenbaum www.china-pub.com/40777&ref=ps Tanenbaum出品，必属精品。本书条理清晰，涉及到分布式系统的方方面面，通俗易懂并附录了分布式系统各个经典问题的论文阅读资料，是分布式系统入门的不二选择。感觉和以前看过的>一样，读起来让人心旷神怡，建议通读。 2. > Gerard Tel www.ch

2009-12-05 17:22:00 1854

原创 Hypertable C++ vs Hbase Java

Hypertable和Hbase二者同源，设计也有诸多相似之处，最主要的区别当然还是编程语言的选择。Hbase选择Java主要是因为Apache和Hadoop的公共库、历史项目基本都采用该语言，并且Java项目在设计模式和文档上一般都比C++项目好，非常适合开源项目。C++的优势当然还是在性能和内存使用上。Yahoo曾经给出了一个很好的Terasort结果(perspectives.mvdiron

2009-12-05 17:22:00 815 1