分布式理论:关于一致性讨论


一、回顾分布式特点

   1.集中式特点

      一台或多台计算机组成中心接节点,所有的数据都存在中心节点上。Client端只负责数据的展示,Server处理数据的存储和处理。显而易见,优点是结构简单容易部署,无需考虑服务多个节点部署,更不用考虑节点之间的协调。缺点是系统性能以来中心节点的性能,无法水平扩展。

   2.分布式特点

     对等:各个节点没有主次之分

     分布:在空间上随意分布,水平扩展,比如我们sinai随意再lf和dx随意添加机器

     并发:对等的节点可能并发访问访问共享资源,如同时访问redis,db,或一个接口

     缺乏全局的时钟:因为分布和对等性,你不知道两个事件发生的前后顺序

     故障不固定:很依赖节点之间的通信,因为网路分区或通信异常会导致机器状态不一致

   3.分布式问题

     通信异常:网路光纤,路由,DNS各种因素导致网络太不可靠了。。。面临重要的两个方面是丢包和包的延迟

     网络分区:整个集群只有一部分之间能正常通信,实际上我们美团服务治理中,SG_agent为部署在各服务节点,通过与服务注册路由中心进行通信,实际承担服务注册、服务发现、动态路由解析、负载均衡等功能及

调用统计上报的应用代理程序。 

    三态:成功,失败,超时

    节点故障:一个分布式集群必须支持异常的节点的摘除,节点的扩容等,比如我们的thrift的server 端节点必须能有服务注册、服务发现等功能

   4.数据库的事务ACID

     ACID各个字母代表什么意思就不用提了,A(原子性,只有成功和失败状态),C(一致性),I(隔离性,各个事物都有自己的数据空间),D(持久性,commit事务的后状态必须是永久的)

     经常听到数据库事务的四层隔离,自己画一个图就清楚了:

分布式理论:关于一致性讨论_第1张图片

为什么涉及到各种级别呢?是为了保证数据的一致性和完整性,级别越高并发性能差,我们数据库一般都设为第二种授权读,避免脏读有保证较好的并发性能,程序中可主动采用悲观锁和乐观锁来控制,即使我们不用看mysql的源码什么的,我们也可以用锁的原理,实现四层隔离,具体mysql怎么实现的还待深入看看,其实是通过行锁、区间锁等实现的乐观锁和悲观锁实现的,四种隔离是这些锁的组合运用。

   5.分布式事务的强一致性CAP

C:一致性,是指对每个节点一个数据的更新,整个集群都知道更新,并且是一致的 ;

A:可用性,服务必须是24小时可用可访问;

P:分区容错性,出现网络分区故障时,仍然保证一致性很可用性,除非整个集群都down掉;

CAP定理:一个分布式系统无法同时满足CAP要求,只能满足其中的两项。

分布式理论:关于一致性讨论_第2张图片

下面可以讲个例子:

场景是这样的,一个reids服务搭建在两个机房(永丰yf和大兴dx),两个服务进程可以同时提供写入和读取,

分布式理论:关于一致性讨论_第3张图片

  •  假设更新操作是同时写yf和dx都成功才返回成功

      在没有出现网络故障的时候,满足CA原则,C 即我的任何一个写入,更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致, A 即我的读写操作都能够成功,但是当出现网络故障时,我不能同时保证CA,即P条件无法满足

  •   假设更新操作是只写本地机房成功就返回,通过log回放方式同步至侧边机房

      这种操作保证了在出现网络故障时,双边机房都是可以提供服务的,且读写操作都能成功,意味着他满足了AP ,但是它不满足C,因为更新操作返回成功后,双边机房看到的数据会存在短暂不一致,且在网络故障时,不一致的时间差会很大(仅能保证最终一致性)

  •   假设更新操作是同时写yf和dx的redis都成功才返回成功且网络故障时提供降级服务

      降级服务,如停止写入,只提供读取功能,这样能保证数据是一致的,且网络故障时能提供服务,满足CP原则,但是他无法满足可用性A原则


   6.分布式事务弱一致性BASE

       在工业的生产中,因为我们无法满足分布式CAP的强一致性,但可以实现分布式的弱一致性。

   (basic available):基本可用,指的是响应时间上和功能上做妥协,一般有服务降级,如砍功能等可做到保证服务基本可用

     (soft state) :  软可用,数据存在中间态,一般是服务节点在同步数据

   (eventually consistent ): 最终一致性,决定数据复制,网络延迟,系统的负载等。

总的来说,base通过牺牲强一致性来保证可用性,和ACID 的相反,允许有一段时间数据在个节点上不一致,只保证数据的最终的一致性。不同业务对数据的一致性的要求不同,我猜测比如一些我们美团金融或支付部门,可能宁可系统停顿也要保证数据的一致,不会像应用数据展示层,短暂的不一致是可以容忍的。所以工业上会结合ACID和BASE使用。


所以在分布式集群中P是不可能放弃的,只是一致性和可用性之间的权衡。

二、一致性协议

   2PC:二阶段提交

事务提交机制:

分布式理论:关于一致性讨论_第4张图片



事务中断机制:

分布式理论:关于一致性讨论_第5张图片

优点:简单

缺点:单点、参与者被堵塞


   3PC:三阶段提交,是2PC的延伸

cancommit阶段

precommit阶段(参与者undo和redo日志)

docommit阶段


优点:解决参与者堵塞范围。

缺点:一出新的问题–数据不一致性,因为precommit阶段,参与者接受消息后如果出现网络分区,依然进行进行事务的提交。


paxos算法以及工程实践chubby


 他能解决什么问题呢?就是可能发生异常的分布式系统中,快速正确的在集群内对数据对象达成一致,保证无论发生什么异常,都不会破坏整个系统的一致性。一个典型的场景是,在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点执行相同的操作序列,那么他们最后能得到一个一致的状态。

拜占廷问题?网络上可以通过校验算法保证不会出现消息被篡改。


大概内容如下:

proposers 提出提案,提案信息包括提案编号和提议的 value;

acceptor 收到提案后可以接受(accept)提案,若提案获得多数 acceptors 的接受,则称该提案被批准(chosen);

learners 只能“学习”被批准的提案。

划分角色后,就可以更精确的定义问题:

  1. 决议(value)只有在被 proposers 提出后才能被批准(未经批准的决议称为“提案(proposal)”);
  2. 在一次 Paxos 算法的执行实例中,只批准(chosen)一个 value;
  3. learners 只能获得被批准(chosen)的 value。

通过加强约束2,得到paxos算法:

P1:一个 acceptor 必须接受(accept)第一次收到的提案。

无法形成多数派,于是...

P2:一旦一个具有 value v 的提案被批准(chosen),那么之后批准(chosen)的提案必须具有 value v。

何不如对提案加强,于是...

P2a:一旦一个具有 value v 的提案被批准(chosen),那么之后任何 acceptor 再次接受(accept)的提案必须具有 value v。

p1和p2a由于通信异步,没法做到,于是...

P2b:一旦一个具有 value v 的提案被批准(chosen),那么以后任何 proposer 提出的提案必须具有 value v。

假如满足P2c,p2b就可以满足,可以数学归纳法证明。而p3c容易通过消息通信实现,于是...

 

P2c:如果一个编号为 n 的提案具有 value v,那么存在一个多数派,要么他们中所有人都没有接受(accept)编号小于 n 的任何提案,要么他们已经接受(accpet)的所有编号小于 n 的提案中编号最大的那个提案具有 value v。

 
要满足 P2c 的约束,proposer 提出一个提案前,首先要和足以形成多数派的 acceptors 进行通信,获得他们进行的最近一次接受(accept)的提案(prepare 过程),之后根据回收的信息决定这次提案的 value,

形成提案开始投票。当获得多数 acceptors 接受(accept)后,提案获得批准(chosen),由 proposer 将这个消息告知 learner。这个简略的过程经过进一步细化后就形成了 Paxos 算法。


一个例子:http://blog.sina.com.cn/s/blog_3dbab28401014lt4.html

分布式锁服务google chubby ,采用paxos算法来解决master的选举问题:

分布式理论:关于一致性讨论_第6张图片

三、zookeeper

zookeeper是决解分布式一致性问题的解决方案,如订阅/发布、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁、分布式队列等问题。

zk能保证:顺序性、原子性、单一视图、可靠、实时性(保证一定时间内)。

zab协议(zookeeper  atomic broadcast)

跟paxos算法一样,都是解决一致性问题。

分为两过程(广播和崩溃)三阶段(发现、同步、广播)

三个阶段:

(1)发现:分布式的多个进程选取主进程作为leader

(2)同步:leader和follower同步,处理上一轮事务和准备新一轮的事务

(3)广播:接受客户端请求,同时进行消息通信

所有的进程状态:looking、followering、leading状态

分布式理论:关于一致性讨论_第7张图片

四、zk使用场景

(1)订阅/发布

如mtconfig服务,一般消息有两种模式(push和pull),zk使用的是推拉相结合的方式:client向server注册关注数据节点,一旦数据发生变更,server向client发送watcher时间通知,client收到后到服务端拉去数据。

(2)负载均衡

分布式理论:关于一致性讨论_第8张图片

分布式理论:关于一致性讨论_第9张图片

(3)命名服务

比如mtthrift的PRC框架,通过服务的key拿到服务端服务器列表等信息。

分布式理论:关于一致性讨论_第10张图片

(4)分布式协调/通知

如:通过wacher协调各个进程进行数据备份

(5)集群管理

如:分布式日志收集、云主机管理等

(5)master选举

一般来说,跟数据库的master和slave概念一样,master进行更新操作等一些复杂的逻辑关系。比如海量数据计算有mater去完成,然后更新到cache,提供给其他的follower共享。

(6)分布式锁、分布式队列

感觉我们大部分的比较大的分布式系统或服务,瓶颈在于频繁进行数据库的操作,比如行锁、表锁甚至是繁重的事务处理。

比如:sinai的job更新事务如何做到分布式?可以通过分布式锁机制。

五:zk在kafka 中的应用

hadoo用zk解决resourcemanager的单点问题、

hbase、

zk在kafka上的应用

分布式理论:关于一致性讨论_第11张图片

六、zookeeper简单搭建

集群模式:

单机模式:

伪集群模式:

ls、create、get、delete、set命令使用


client使用方式:

(1)直接调用原生的zookeeper类直连

(2)zkclient包

(3)curator包



你可能感兴趣的:(工作总结)