老码农的专栏

Chord、DHT（分布式哈希）、一致性哈希

FLP Impossibility（FLP不可能性）是份额

世上有很多选举算法，但最完美的莫过于Paxos，但把paxos用于master选举与用于value的选举有用众多不同之处，主要一点是二者执行频率不同。value选举需要频繁、高密度地执行paxos算法，每instance选举一个value。因此，原生的paxos算法无法满足高性能的要求；另一个问题是，paxos理论上存在活锁，lamprot推荐大家通过选举Leader避免这个问题。所有的实现都

Zookeeper使用了一种称为Zab（Zookeeper Atomic Broadcast）的协议作为其一致性复制的核心，据其作者说这是一种新发算法，其特点是充分考虑了Yahoo的具体情况：高吞吐量、低延迟、健壮、简单，但不过分要求其扩展性。下面将展示一些该协议的核心内容：另，本文仅讨论Zookeeper使用的一致性协议而非讨论其源码实现Zookeeper的实现是有Client、Serv

自从Lamport在1998年发表Paxos算法后，对Paxos的各种改进工作就从未停止，其中动作最大的莫过于2005年发表的Fast Paxos。无论何种改进，其重点依然是在消息延迟与性能、吞吐量之间作出各种权衡。为了容易地从概念上区分二者，称前者Classic Paxos，改进后的后者为Fast Paxos。1. Fast Paxos概览Lamport在40多页的论文中不仅提出了Fas

在众多的分布式一致性算法中，经常需要通过节点的数量满足某种规则来保证算法的正确性，比如Paxos算法，依赖一个”多数派“ 节点的工作的正确性。这类算法的共同目标是容许尽量多的节点失败但又不影响算法的正确性”。  这类问题本质上都抽象为数学上集合之间的逻辑关系，下面我们便从集合的性质入手讨论，为此先引入两个问题：  假设N为一非空结合，n为集合的元素数，M1,M2,...,Mm为N的m个子集

1. KeyspaceKeyspace是一款基于Paxos的开源Key-Value的数据库，底层存储基于BerkelyDB，Keyspace的核心功能是在BerkelyDB之上添加了一致层，保证每个节点的数据完全一致。Keyspace基于Master-Slave模式，所有的写均有Master承担，并通过paxos一致传播到slave，读可以根据基本路由到master或slave。因此，当mas

前两篇Paxos算法的讨论，让我们对paxos算法的理论形成过程有了大概的了解，但距离其成为一个可执行的算法程序还有很长的路要走，原因是很多的细节和错误未被考虑。Google Chubby的作者说，paxos算法实现起来远没有看起来简单，原因是paxos的容错仅限于server crash这一种情况，但在实际工程实现时要考虑磁盘损坏、文件损坏、Leader身份丢失等诸多的错误。 1. Pa

Paxos算法的难理解与算法的知名度一样令人敬仰，从我个人的经历而言，难理解的原因并不是该算法高深到大家智商不够，而在于Lamport在表达该算法时过于晦涩且缺乏一个完整的应用场景。如果大师能换种思路表达该算法，大家可能会更容易接受：首先提出算法适用的场景，给出一个多数读者能理解的案例其次描述Paxos算法如何解决这个问题再次给出算法的起源（就是那些希腊城邦的比喻和算法过程）Lampo

层次锁，更多地是在数据库设计中被提到，但也有少数分布式锁系统也实现这个概念。下面内容主要还是从数据库设计的角度来理解层次锁的概念。1. 事务锁粗略说来，当执行SQL语句时数据库都会开启事务，在SQL执行完毕commit时，会把所有受影响数据写到磁盘文件并结束事务。在事务执行期间，为了保证事务的ACID，SQL所影响到的表、行等数据都会被不同程度的进行锁定，我们笼统称为“事务锁”。从使用者的

  在分布式系统中经常使用心跳(Heartbeat)来检测Server的健康状况，但从理论上来说，心跳无法真正检测对方是否crash，主要困难在于无法真正区别对方是宕机还是“慢”。传统的检测方法是设定一个超时时间T，只要在T之内没有接收到对方的心跳包便认为对方宕机，方法简单粗暴，但使用广泛。 1. 传统错误检测存在的缺陷    如上所述，在传统方式下，目标主机会每间隔t秒发起心跳，而接

Lease，一致性，Proxy

Gossip,Anti-Entropy,Rumor mongering，最终一致性，cassandra

viewstamp算法，paxos算法，分布式事务，leader选举

Paxos算法

一致性哈希、KETAMA、XMemcache、Sypmemcache

CAP理论在中国有着广泛的知名度，