极简设计

分布式

Yahoo借鉴Google Chubby设计思想开发Zookeeper并开源交到Apache,成为Hadoop子项目 协调系统,作用的对象是分布式系统,解决分布式系统“部分失败”

异步读同步写 对外提供低级的原语,可实现复杂的分布式算法,如queue、barrier和lock等 做可靠容错,进行订阅分发服务,或者其他应用

paxos的变种-原子多播协议Zab

Paxos

基于消息传递的分布式一致性算法,用于分布式计算 前提:没有拜占庭将军问题。即只有在一个可信的计算环境中才能成立,这个环境是不会被入侵所破坏的

Paxos小岛(Island) 议员(Senator) 确定,不能更改的 议员的总数(Senator Count) 提议(Proposal) 提议编号(PID)

提议超过半数((Senator Count)/2 +1)议员同意生效 议员只同意大于当前编号提议

ZK Server里Paxos 小岛(Island)——ZK Server Cluster 议员(Senator)——ZK Server 提议(Proposal)——ZNode Change(Create/Delete/SetData…) 提议编号(PID)——Zxid(ZooKeeper Transaction Id) 正式法令——所有ZNode及其数据

Paxos岛上的议员人人平等,ZK Server有Leader概念 如果议员人人平等,在某种情况下会由于提议的冲突而产生一个“活锁”(所谓活锁我的理解是大家都没有死,都在动,但是一直解决不了冲突问题) 议员中设立一个总统,有权发出提议,议员提议必须发给总统来提出 总统——ZK Server Leader

总统怎么选出来的? http://rdc.taobao.com/blog/cs/?p=162

ZK Server属于自己特性的东西:Session, Watcher,Version等

在zookeeper的集群中,各个节点共有下面3种角色和4种状态: 角色:leader,follower,observer 状态:leading,following,observing,looking

ZNode

Persistent Nodes: 永久有效地节点,除非client显式的删除,否则一直存在 Ephemeral Nodes: 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节点 Sequence Nodes: 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键

Watch

分布式回调 可以watch的event: KeeperState:Disconnected,SyncConnected,Expired EventType:None,NodeCreated,NodeDeleted,NodeDataChanged,NodeChildrenChanged

分布式系统几种典型一致性算法简述

衡量系统设计的准则-CAP原理

http://rdc.gleasy.com/2013/05 很多文章

老码农的专栏 CAP理论 http://blog.csdn.net/chen77716/article/details/30635543 非常透彻, CAP的历史 CAP被上升为定理 前所未有的质疑 对质疑的回应 该如何看待CAP?

(导师推荐阅读)paxos算法如何容错的--讲述五虎将的实践
http://xu3stones.blog.163.com/blog/static/2059571362012111341531570/ paxos分布式一致性算法--讲述诸葛亮的反穿越 http://blog.csdn.net/russell_tao/article/details/7244530

分布式服务框架 Zookeeper -- 管理分布式环境中的数据 http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

Apache Hadoop 子项目,解决分布式应用数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等 维护和监控数据变化,解决分布式集群中一致性问题

典型的应用场景

配置文件、集群、同步锁、Leader 选举、队列管理

角色

leader,follower,observer

状态

leading,following,observing,looking

znode类型

Persistent Nodes: 永久有效地节点,除非client显式的删除,否则一直存在 Ephemeral Nodes: 临时节点,仅在创建该节点client保持连接期间有效,一旦连接丢失,zookeeper会自动删除该节点 Sequence Nodes: 顺序节点,client申请创建该节点时,zk会自动在节点路径末尾添加递增序号,这种类型是实现分布式锁,分布式queue等特殊功能的关键

ZAB: ZooKeeper的Atomic Broadcast协议

http://breezes.lofter.com/post/d325_1aa98b Paxos一致性达不到ZooKeeper要求 leader P1发起了两个事务<t1, v1>(t1为序号,要写的值是v1)和<t2, v2>,然后挂掉 新来个P2 leader发起<t1, v1'> 而后又来新P3 leader 汇总最终的执行序列<t1, v1'>和<t2, v2>,即P2的t1在前,P1的t2在后

树形结构的ZooKeeper,很多操作都要先检查才能确定能不能执行 P1事务t1可能创建节点/a,t2创建节点/a/aa,只有先创建了父节点/a,才能创建子节点/a/aa 而P2所发起的事务t1可能变成了创建/b 这样P3汇总后序列是先创建/b再创建/a/aa,由于/a还没建,创建a/aa就出错 ZAB保证同一个leader的发起的事务要按顺序被apply且只有先前的leader的所有事务都被apply之后,新选的leader才能在发起事务

ZAB核心思想:任意时刻只有一个leader,所有更新事务由leader发起去更新所有复本(follower),更新时用两阶段提交协议,多数节点prepare成功,就通知他们commit 各follower要按当初leader让他们prepare的顺序来apply事务 ZAB事务永远不会回滚,ZAB的2PC做了点优化,多个事务只要通知zxid最大的那个commit,之前的各follower会统统commit

如果没有节点失效,那ZAB上面这样搞下就完了,麻烦在于leader失效或leader得不到多数节点的支持时怎么处理

关键点: 1、leader所follower之间通过心跳来检测异常 2、检测到异常之后的节点若试图成为新的leader,首先要获得大多数节点的支持,然后从状态最新的节点同步事务,完成后才可正式成为leader发起事务 3、区分新老leader的关键是一个会一直增长的epoch

除了能保证顺序外,ZAB性能也能不错,千兆网络5节点部署的TPS达到25000左右,响应时间只有约6ms

读写性能测试

http://www.ostest.cn/archives/469?utm_source=weibolife

分布式系统的事务处理经典问题及模型

分布式系统需要在数据完整、一致性和性能间做平衡 处理分布式数据一致性的技术模型,如:Master-Slave,Master-Master,2PC/3PC,经典的将军问题,Paxos,以及Dynamo的NRW和VectorClock的模型

数据高可用,就需要冗余数据写多份。写多份带来一致性的问题,一致性的问题又会带来性能问题,陷入一个无解的死循环! 数据一致性:多个用户同时访问一个数据库时,如果它们的事务同时使用相同的数据,可能发生以下四种情况: 丢失更新、未确定的相关性、不一致的分析和幻像读

本篇文章将会给大家系统的介绍多种处理分布式数据一致性的技术模型

in 分布式 with : 分布式