2019.9.5-6 snapshots, multicast, paxos, leader election和mutual exclusion

把这两天看的两章一起说一下。

第五章,先是讲snapshots就是快照,具体就是Chandy-Lamport算法,快照就是把一个分布式系统以很多断点(marker)为间隔记录下系统的状态,包括单个进程自己的状态以及不同进程之间的状态,保存这些可能可以用来进行错误处理之类的事情。

    算法具体流程是啥呢,就是由某个进程向其他进程发送marker,其他进程接收并视情况回信,然后纪录自己的系统状态...具体内容可以看这里https://zhuanlan.zhihu.com/p/53482103

    然后是multicast,其实之前提过这个,中文叫组播,就是一个进程对系统内的一组进程传递消息,对应“广播”(broadcast),也就是对所有成员都发送消息。有几种类型的multicast算法,比如fifo,casual什么的,casual就是满足lamport时间戳那种因果一致性的要求的。这一篇讲的可以看一下,比较形象https://www.cnblogs.com/hzmark/p/consistency_model.html,还有这个讲得更清楚些https://blog.csdn.net/aigoogle/article/details/43271185

      最后是讲consensus,我们熟悉的paxos啊raft啊都是指这个问题,consensus就是指对于一个分布式系统中的所有进程,要以某种方式保证它们产生同一个结果。这被证明是不可能的,不过通过paxos之类的算法可以尽最大可能的保证一致性。像failure dection和leader election这类问题其实是和consensus问题等价的。

    paxos可以提供完整的safety和较大程度的liveness。对于一个系统来说safety的意思大体是,不会有坏事发生,比如各进程决策不一致。liveness意思就是最终一定会有好事发生,比如最后一定会选出一个leader。然后三哥非常简略的讲了下paxos的内容,因为实在过于简略所以没啥可说的,后面raft的时候再总结吧。

第六章,先是leader elcetion。分布式系统里需要一个leader,用作读写之类的操作,也可以把调度放在leader机器里面。所以就需要各进程选出一个leader,然后讲了一个ring leader election的算法,其实很简单,就是各进程组成一个环,然后沿着换互相交换某种属性,最后能得到一个最强的,那么最强的自然就当领导了。具体内容这里可以看看https://www.cnblogs.com/daizuozhuo/p/4590895.html。讲了两个工业中用到的选举算法,chubby和zookeeper,讲的都很简略,前面那个链接也有讲。

    然后讲 Mutual Exclusion,就是进程互斥,为什么要进程互斥呢,就跟单系统的情况一样,因为不同的进程可能想要执行同一件事情,那么同步执行的时候可能出问题。这个单系统的进程互斥我们很熟悉了,就加锁就完事了,分布式系统的话其实也差不多,一样很简明,一个最简单的算法就是选举出一个leader,由这个leader持有一个token,然后每个进程如果运行某段代码的话就要像leader索要token,只有有token的程序才能执行这一段。

    另一个算法是ringed  Mutual Exclusion,就是并没有leader,所有进程组成圆桌轮流持有token,每个人接到token后都检查一下自己想不想执行,不想的话就往后传。感觉这两种算法就是自由和平等之间的区别(。。)

    Ricart-Agrawala‘s Algorithm相对复杂一些,它没有token而是利用了lamport timstamp,性能比前两种好一些但是很占带宽,因为这个算法中每两个进程之间都要通信确认状态。有一种Maekawa‘s Algorithm在此基础上改善了带宽,但是具体什么原理我懒得听了...

    当然,现实中用的Mutual Exclusion都不是上面那几种,所以了解了解就好...

原文地址:https://www.cnblogs.com/dynasty919/p/11478557.html

时间: 2024-10-23 11:30:48

2019.9.5-6 snapshots, multicast, paxos, leader election和mutual exclusion的相关文章

Zookeeper 学习笔记之 Leader Election

ZooKeeper四种节点类型: Persist Persist_Sequential Ephemeral Ephemeral_Sequential 在节点上可注册的Watch,客户端先得到通知再得到数据,Watch被fire后,不会再Watch到后续的变化. 基于ZooKeeper做Leader Election 非公平模式 - 客户端会在Persist父节点下创建Ephemeral的Leader节点,只不过是大家抢占式注册,先到先得.即使第一次排在前面,对第二次竞选也不会有影响,所以称为非公

Apache Curator Leader Election

用于Leader选举,也可以用Shared Reentrant Lock来实现. 如果需要集群中的固定的一台机器去做的事,就可以用此特性来实现,直到这台Leader死去,会产生新的Leader. 1.直接运行LLtest package com.collonn.javaUtilMvn.zookeeper.curator.LeaderElection; import com.collonn.javaUtilMvn.zookeeper.curator.NodeCache.NLClientCreate

根据已经commit的数据,进行leader和peon之间的同步

Leader Election基本设计 按照rank表示优先级解决冲突问题,为每个monitor预先分配了一个rank 只会接受优先级(rank)比自己高.epoch比上次已接受的epoch大的选举请求 当选的leader,不一定有最新的数据.所以在phase 1中,会根据已经commit的数据,进行leader和peon之间的同步 用奇数的epoch表示选举状态,偶数表示稳定状态 一旦选举成功,会形成一个quorum,在该leader当选期间,所有提议,必须quorum中全部成员同意. Lea

Paxos算法之旅(四)zookeeper代码解析

ZooKeeper是近期比较热门的一个类Paxos实现.也是一个逐渐得到广泛应用的开源的分布式锁服务实现.被认为是Chubby的开源版,虽然具体实现有很多差异.ZooKeeper概要的介绍可以看官方文档:http://hadoop.apache.org/zookeeper 这里我们重点来看下它的内部实现. ZooKeeper集群中的每个server都要知道其他成员,通过在配置文件zoo.cfg中作如下配置实现: tickTime=2000 dataDir=/var/zookeeper/ clie

[转]Why Not Paxos

http://blog.csdn.net/cszhouwei/article/details/38374603 Why Not Paxos Paxos算法是莱斯利·兰伯特(LeslieLamport,就是 LaTeX 中的”La”,此人现在在微软研究院)于1990年提出 的一种基于消息传递的一致性算法.由于算法难以理解起初并没有引起人们的重视,使Lamport在八年后1998年重新发表到ACM Transactions on Computer Systems上(The Part-TimeParl

[转]Raft [Why Not Paxos]

http://blog.csdn.net/cszhouwei/article/details/38374603 动画讲解 http://thesecretlivesofdata.com/raft/ Why Not Paxos Paxos算法是莱斯利·兰伯特(LeslieLamport,就是 LaTeX 中的”La”,此人现在在微软研究院)于1990年提出 的一种基于消息传递的一致性算法.由于算法难以理解起初并没有引起人们的重视,使Lamport在八年后1998年重新发表到ACM Transact

<从PAXOS到ZOOKEEPER分布式一致性原理与实践>读书笔记-ZAB协议

本文属于分布式系统学习笔记系列,上一篇笔记整理了paxos算法,本文属于原书第四章,梳理zookeeper的目标特性及ZAB协议. 1.介绍zookeeper 1.1ZooKeeper保证一致性特性 ZooKeeper是一个典型的分布式数据一致性的解决方案,分布式程序可以基于它实现诸如数据发布/订阅.负载均衡.命名服务.分布式协调通知.集群管理.master选举.分布式锁.分布式队列等功能.ZooKeeper可以保证如下分布式一致性特性. 1.顺序一致性: 从同一个客户端发起的事务请求,最终将严

zookeeper学习系列:四、Paxos算法和zookeeper的关系

一.问题起源 淘宝搜索的博客 http://www.searchtb.com/2011/01/zookeeper-research.html  提到Paxos是zookeeper的灵魂 有一篇文章标题更是以“Zookeeper全解析——Paxos作为灵魂” 作为标题,认为是zookeeper的基础: “ Google的Chubby,Apache的Zookeeper都是基于它的理论来实现的,Paxos还被认为是到目前为止唯一的分布式一致性算法,其它的算法都是Paxos的改进或简化.有个问题要提一下

TIDB 架构及分布式协议Paxos和Raft对比

近来newsql大热,尤以TIDB最火,pingcap不断打磨TiDB,现如今版本已经迭代到3.0,产品已经基本趋于成熟.对于TiDB,整体架构图如下图所示是由四个模块组成,TiDB Server,PD Server,TiKV Server,TiSpark. TiDB Server负责接受SQL请求,处理SQL的相关逻辑,并通过PD找到存储计算所需数据的TiKV地址,与TiKV交互获取数据,最终返回结果.TiDB Server是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过