发布时间 : 星期三 文章zookeeper-3.4.6总结更新完毕开始阅读5973b10d84868762caaed595
一、 基础篇
1. 分布式理论
? ?
集中式系统：由一台或多台计算机组成中心节点，数据集中存储于这个中心节点中。 分布式系统：是一个硬件或软件组件分布在不通的网络计算机上，彼此之间仅仅是通过消息传递进行通信和协调的系统
为了对外提供高可用服务，避免单点故障，方便水平扩展，就产生从集中式到分布式的转变需求，但是分布式系统会出现以下问题，而这几个问题又相互影响，比如网络问题和并发问题会导致数据不一致 ? 网络问题
分布式系统一大特点是通过消息传递进行通信和协调就不可避免网络问题，网络问题包括网络延迟、脑裂(split-brain)、网络不可达(unreachable)
单机内存访问延时在纳秒级，而网络通信需要0.1-1ms，如果经过过多网络设备会延时更多，丢包和延迟非常普遍
当网络发生异常，不管是硬件或者软件，都有可能发生\网络分区\俗称\脑裂(split-brain)\比如5台服务器，2台可以互相通信，另外3台可以互相通信，而这前2台和后3台之间无法通信，就形成两个小规模集群，这两个小集群很有可能分布在不同机架上或者在不同的数据中心
由于网络异常，更会普遍发生的情况是数据传输超时或者建立连接超时，此时消息发送端并不知道消息是否成功发送
? 数据一致性
为了保证高可用，数据会多副本分布在不同服务器上，当提供服务的副本挂了以后，需要将服务切换至其它副本，副本之间的数据需要保证完整性和一致性
? 并发问题缺乏全局时钟
分布式系统的多个节点在同一时刻并发操作共享的资源；在分布式系统中，很难定义两个事件谁先谁后，原因就是因为分布式系统缺乏一个全局时钟序列控制
数据一致性
一致性有以下几种等级
? 强一致性：任何client在写入的数据，都能在之后被人任何client既完整又一致
的看到，不会出现看到旧数据，也不会看到不一致的数据。
? 弱一致性：写入数据成功后，并不能保证立即可以看到读入的值，能保证在某个时间
级别达到一致性，如果能保证在一定时间内(比如zk是保证任何存活的节点在syncLimit*ticktime时间范围内达到数据一致)达到数据一致，就叫做最终一致性 如果细分，弱一致性分为会话一致性和用户一致性，zookeeper可以保证会话一致性和用户一致性(client重连时会拿最后一次zxid去验证，如果新连的server存在zxid那么就建立会话) ACID
?
?
?
?
?
在传统单机数据库中，我们能很容易实现满足ACID特性的事务处理系统
事务具有以下特性，A--原子性，C--一致性，I-隔离性(read uncommitted,read committed,repeatable read,serializable) D---持久性
分布式事务
典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，两个操作必须都成功要么都失败。
我所理解的CAP理论 CAP原文(摘自wiki):
CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：[1][2]
一致性（Consistency)（等同于所有节点访问同一份最新的数据副本） 可用性（Availability）（对数据更新具备高可用性）
容忍网络分区（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择[3]。）
由于CAP理论是2000年提出的，每项定义很模糊，我所理解的CAP理论如下： ? 一致性C:操作总是能读取到之前完成的写操作结果；
? 可用性A:读写操作总是能够在很短的时间内返回，即使某台机器发生了故障，也能够 通过其它副本正常执行，而不需要等到机器重启或者机器上的服务分配给其它机器以后才能成功；
? 分区可容忍性P:无法做到机器宕机，机房停电或者出现机房之间网络故障等异常情况
的容错；
以上三点不能同时满足，
目前满足CA的数据库系统有：mysql，postgres，因为是单机的无法满足P，单机访问也不存在数据不一致和长时间无法响应的问题(在无法容忍机器宕机、网络异常等情况) 满足AP的：Cassandra(基于gossip协议达到最终一致性)，zookeeper 满足CP的：Mongodb(可以设置写请求被所有节点响应后才返回)
因为为了对外可靠的服务避免宕机及网络故障，那么我们必须保证P，要能容忍分区出错（包括宕机、网络异常），那么就需要在A可用性和C强一致性进行取舍，假如我们保证强一致性，每次写操作就要将数据同步到其它所有节点，要么每次读操作读到所有节点，取最新的数据，要么读的节点数+写的操作数总和大于总副本数，无论哪种情况，都会增加多次网络开销造成可用性(在一定时间内返回响应)变差。假如我们为了高可用性，所有副本接收到数据请求时立即返回给客户端，而这时又恰好在数据同步的时间窗口中，就会造成不同客户端看到的数据不一致。
? 放弃C保P和A:比如一对夫妻在异地同时在酒店网站订房间，丈夫看到419房间可
以预定，妻子看到419房间已经被人预定
? 放弃A保P和C：由于每次数据都要同步到所有副本，造成某个用户下单购物等待超
过1分钟
? 放弃P保A和C：放弃P相当于对于无法对机器宕机、机房停电、网络异常的容错，
那么就使用单台机器，或者数据分片存放在多台机器没有副本，因为没有数据同步操作数据也只有一副，那么就能很容易满足A和C，但是一旦遇到宕机、网络异常，整个服务将不可用
假设
? N — 数据复制的份数
? W — 更新数据时需要保证写完成的节点数 ? R — 读取数据的时候需要读取的节点数
如果W+R>N，写的节点和读的节点重叠，则是强一致性，如果W+R ? BASE理论 BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)三个短语的缩写。 ? 基本可用：响应上的损失(出现故障情况响应时间可以延长)、功能上的损失(引导到降 级页) ? 弱状态：允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的 整体可用性，即允许副本直接数据有同步延迟 ? 最终一致性：最终一致性强调的是系统中所有的数据副本在经过一段时间的同步后， 最终能够达到一个一致的状态。 ? 最终一致性的五大变种 根据业务场景，要求的一致性也不一样 ? 因果一致性：进程A更新了某个数据通知B，那么进程B之后对该数据访问应该能够 访问到A更新后的最新值，如果B进行数据更新的话务必基于进程A更新的最新值 比如zk就可以实现因果一致性，A修改完数据发送给B，B执行sync()，然后得到version，再拿着version去setData ? 读己之所写：进程A更新一个数据项之后，它总能访问到更新过的最新值，而不会看 到旧值。比如论坛中，用户可以及时看到被自己编辑过后的帖子也可以看到自己修改后的个人资料，但是用户可以不用实时看到别人修改过的帖子，mongodb可以设置读写primary，也可以设置写primary，读secondary，所以mongodb可以满足这一一致性需求。 zk也满足了读己之所写，在连接不重连的情况下，由于只连一个zk sever只建立一个连接，该zk server commit数据更新返回给client之后，client每次读都不会读到旧值。在连接重连的情况下，由于client每次连新的zk server都会验证zxid(事务id)不能比自己提交过的zxid(事务id)小，所以一定也能看到自己写入的值 ? 会话一致性：和“读己之所写”类似，只是“己”变成了“会话”，用户申请一个会 话，即使连接变了需要重新建立，但如果还是在一个会话中，那么看到数据不能是之前写入的旧值 zk满足会话一致性 ? 单调读一致性：当一个进程从系统中读到一个数据项的值，那么后续任何对该数据项 的访问都不该返回比这更旧的值 zk满足单调读 ? 单调写一致性： 单调写一致性是指，一个系统需要保证一个进程写操作被顺序的执行 zk满足单调写 2. 一致性协议从paxos到zab 为了解决一致性问题，涌现了一大批经典的一致性协议和算法，最著名的就是二阶段提交、三阶段提交、Paxos算法了。 ? 2PC ? 是Two-Phase Commit的缩写，即二阶段提交，目前绝大多数的关系型数据库都是采用二阶段提交协议来完成分布式事务处理的 阶段一：提交事务请求 阶段二：执行事务提交 举个例子： Phase 1 Prepare: 组织者(coordinator)打电话给所有参与者(participant) ，同时告知参与者列表。 Proposal: 提出周六2pm-5pm举办活动。 Vote: participant需vote结果给coordinator：accept or reject。 Block: 如果accept, participant锁住周六2pm-5pm的时间，不再接受其他请求。 Phase 2 Commit: 如果所有参与者都同意，组织者coodinator通知所有参与者commit, 否则通知abort，participant解除锁定。 优点：原理简单，实现方便 缺点：同步阻塞、单点故障、网络分区等故障无法容错 3PC 阶段一：CanCommit 阶段二：PreCommit 阶段三：doCommit cohorts(participant)收到preCommit之后，如果没收到commit, 默认也执行commit, 即图上的timeout cause commit。 如果coodinator发送了一半preCommit crash, watchdog接管之后通过query, 如果有任一节点收到commit, 或者全部节点收到preCommit, 则可继续commit, 否则abort。 优点：允许发生单点故障后继续达成一致 缺点：网络分区问题，比如preCommit消息发送后突然两个机房断开，这时候coodinator所在机房会abort, 另外剩余replicas机房会commit Paxos Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的\，此人现在在微软研究院）于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。 P1a. 每次Paxos实例执行都分配一个编号，编号需要递增，每个replica不接受比当前最大编号小的提案 P2. 一旦一个 value v 被replica通过，那么之后任何再批准的 value 必须是 v，即没有拜占庭将军(Byzantine)问题。拿上面请客的比喻来说，就是一个参与者一旦 ?