sequentialleader算法中

⑴ zookeeper有什么功能，选举算法如何进行

选举机制(FastLeaderElection算法)：sid最大且被超过集群中超过半数的机器拥护就会成为leader. 所以只有两种情况无法选出leader： 整个集群只有2台服务器（注意不是只剩2台，而是集群的总节点数为2） 整个集群超过半数机器挂掉。 所谓的偶数问题...

⑵ 问几个关于计算机名人的问题

第一个不知道

悼念伟大的计算机科学家Edsger Wybe Dijkstra

又是一篇关于EWD的文章，

共享一下。

摘自孟岩的blog

悼念伟大的计算机科学家Edsger Wybe Dijkstra

2002年8月8日，我象往常一样查看自己在extremeprogramming电子小组上订阅的newsletter。突然看到这个小组上的稀客、OO教父Grady Booch的发言，题目是Dijkstra。我以为大家在讨论Dijkstra教授提出的什么难题，定睛一看，才知道是一篇类似生平介绍式的讣告——在与癌症进行了多年的斗争之后，伟大的荷兰计算机科学家Edsger Wybe Dijkstra已经于2002年8月6日在荷兰Nuenen自己的家中与世长辞！终年72岁。

原来如此！

这个Dijkstra，就是那个提出"goto有害论"的Dijkstra，就是那个提出信号量和PV原语，解决了有趣的"哲学家聚餐"问题的Dijkstra，那个Dijkstra最短路径算法的创造者，第一个Algol 60编译器的设计者和实现者，THE操作系统的设计者和开发者，那个与D. E. Knuth并称为我们这个时代最伟大的计算机科学家的人。

阿兰图灵的自杀是在办个世纪之前，冯诺依曼去世也已经多年，作为这个相对新兴的行当中的从业者，我们似乎已经很习惯于从相信，从书上读到的每个名字都是仍然在世的活生生的人，都是我们这个时代的骄傲。无论是仍然健硕的D. E. Knuth，Fred Brooks，Dennis Ritchie, Ken Thompson, Brian Kernighan, 还是正当盛年的Bjarne Stroustrup，Grady Booch，Steve McConnell, Andy Koenig, Robert Martin, Kent Becker, Martin Fowler, James Gosling, 再或者是青春年少，意气风发的Linus Trovalds，Andrei Alexandrescu，我们似乎都习惯于认为，只要一封email，这些书本上的名字就会立刻成为你的朋友。Internet把地球变成了一个大村庄，每个人的距离都那么的近。

但是可惜，Internet却无法缩短跨越生与死的冥界。今天，一颗真正的巨星在我们的眼前陨落！作为一名普通的程序员，我从内心感到惋惜和悲痛。这种悲痛，两年半前在我最初得知Richard Stevens的逝世时，也曾感受过，然而却不如今天来得这么强烈。毕竟，当我对编程还是懵懵懂懂的时候，就知道有个叫Dijkstra的人劝告大家不要滥用goto，而在那之前，goto在我看来就是编程的全部奥秘所在。之后我在学习算法、数据结构、操作系统等课程的时候，Dijkstra这个名字一次又一次从书里跳出来，我对于这个名字的崇敬也越来越深。我知道他晚年疯狂的迷恋C++，这也几乎是我这个C++ Fan所能感受到的最大荣幸。我曾想过，有朝一日，我会给他写一封email，什么也不说，只想表达我个人对他的感谢和敬意。没想到，如今连这个机会也没有了！

Dijkstra引导了并且将继续引导这个星球上所有的程序员，他的贡献和影响将与世长存，让我们祝他安息！

【附】Grady Booch对Dijkstra的介绍

> Professor Edsger Wybe Dijkstra, a noted pioneer of the science and
> instry of computing, died after a long struggle with cancer on 6
> August 2002 at his home in Nuenen, the Netherlands.
>
> Dijkstra was born in 1930 in Rotterdam, The Netherlands, the son of a
> chemist father and a mathematician mother. He graated from the
> Gymnasium Erasmianum in Rotterdam and obtained degrees in mathematics
> and theoretical physics from the University of Leyden and a Ph.D. in
> computing science from the University of Amsterdam. He worked as a
> programmer at the Mathematisch Centrum, Amsterdam, 1952-62; was
> professor of mathematics, Eindhoven University of Technology,
> 1962-1984; and was a Burroughs Corporation research fellow, 1973-1984.
> He held the Schlumberger Centennial Chair in Computing Sciences at the
> University of Texas at Austin, 1984-1999, and retired as Professor
> Emeritus in 1999.
>
> Dijkstra is survived by his wife of over forty years, Maria (Ria) C.
> Dijkstra Debets, by three children, Marcus J., Femke E., and computer
> scientist Rutger M. Dijkstra, and by two grandchildren.
>
> Dijkstra was the 1972 recipient of the ACM Turing Award, often viewed
> as the Nobel Prize for computing. He was a member of the Netherlands
> Royal Academy of Arts and Sciences, a member of the American Academy
> of Arts and Sciences, and a Distinguished Fellow of the British
> Computer Society. He received the 1974 AFIPS Harry Goode Award, the
> 1982 IEEE Computer Pioneer Award, and the 1989 ACM SIGCSE Award for
> Outstanding Contributions to Computer Science Ecation. Athens
> University of Economics awarded him an honorary doctorate in 2001. In
> 2002, the C&C Foundation of Japan recognized Dijkstra "for his
> pioneering contributions to the establishment of the scientific basis
> for computer software through creative research in basic software
> theory, algorithm theory, structured programming, and semaphores".
>
> Dijkstra is renowned for the insight that mathematical logic is and
> must be the basis for sensible computer program construction and for
> his contributions to mathematical methodology. He is responsible for
> the idea of building operating systems as explicitly synchronized
> sequential processes, for the formal development of computer programs,
> and for the intellectual foundations for the disciplined control of
> nondeterminacy. He is well known for his amazingly efficient shortest
> path algorithm and for having designed and coded the first Algol 60
> compiler. He was famously the leader in the abolition of the GOTO
> statement from programming.
>
> Dijkstra was a prodigious writer. His entire collection of over
> thirteen hundred written works was digitally scanned and is accessible
> at http://www.cs.utexas.e/users/EWD. He also corresponded regularly
> with hundreds of friends and colleagues over the years --not by email
> but by conventional post. He strenuously preferred the fountain pen to
> the computer in procing his scholarly output and letters.
>
> Dijkstra was notorious for his wit, eloquence, and way with words,
> such as in his remark "The question of whether computers can think is
> like the question of whether submarines can swim"; his advice to a
> promising researcher, who asked how to select a topic for research:
> "Do only what only you can do"; and his remark in his Turing Award
> lecture "In their capacity as a tool, computers will be but a ripple
> on the surface of our culture. In their capacity as intellectual
> challenge, they are without precedent in the cultural history of
> mankind."
>
> Dijkstra enriched the language of computing with many concepts and
> phrases, such as structured programming, separation of concerns,
> synchronization, deadly embrace, dining philosophers, weakest
> precondition, guarded command, the excluded miracle, and the famous
> "semaphores" for controlling computer processes. The Oxford English
> Dictionary cites his use of the words "vector" and "stack" in a
> computing context.
>
> Dijkstra enjoyed playing Mozart for his friends on his Boesendorfer
> piano. He and his wife had a fondness for exploring state and national
> parks in their Volkswagen bus, bbed the Touring Machine, in which he
> wrote many technical papers.
>
> Throughout his scientific career, Dijkstra formulated and pursued the
> highest academic ideals of scientific rigour untainted by commercial,
> managerial, or political considerations. Simplicity, beauty, and
> eloquence were his hallmarks, and his uncompromising insistence on
> elegance in programming and mathematics was an inspiration to
> thousands. He judged his own work by the highest standards and set a
> continuing challenge to his many friends to do the same. For the rest,
> he willingly undertook the role of Socrates, that of a gadfly to
> society, repeatedly goading his native and his adoptive country by
> remarking on the mistakes inherent in fashionable ideas and the
> dangers of time-serving compromises. Like Socrates, his most
> significant legacy is to those who engaged with him in small group
> discussions or scientific correspondence about half-formulated ideas
> and emerging discoveries. Particularly privileged are those who
> attended his reading groups in Eindhoven and Austin, known as the
> "Tuesday Afternoon Clubs".
>
> At Dijkstra's passage, let us recall Phaedo's parting remark about
> Socrates: "we may truly say that of all the men of his time whom we
> have known, he was the wisest and justest and best."

⑶ 大鱼吃小鱼游戏中用到过哪些算法

大鱼吃小鱼游戏中用到过ZooKeeper的算法。

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现（Chubby是不开源的），它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户 。

Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。

ZooKeeper 的架构图中我们需要了解和掌握的主要有：

（1）ZooKeeper分为服务器端（Server） 和客户端（Client），客户端可以连接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。

（2）客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送信息。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper服务器。

客户端第一次连接到 ZooKeeper服务时，可以接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。

（3）上图中每一个Server代表一个安装Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）。

⑷ 请教个etcd中的raft算法问题

etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。Raft是一个来自Stanford的新的一致性算法，适用于分布式系统的日志复制，Raft通过选举的方式来实现一致性，在Raft中，任何一个节点都可能成为Leader。Google的容器集群管理系统Kubernetes、开源PaaS平台Cloud Foundry和CoreOS的Fleet都广泛使用了etcd。

⑸ cutleader中异形排版算法是什么意思

cut leader
切的领导者

⑹ zookeeper怎么实现分布式锁

1. 利用节点名称的唯一性来实现共享锁
ZooKeeper抽象出来的节点结构是一个和unix文件系统类似的小型的树状的目录结构。ZooKeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在Zookeeper目录/test目录下创建，两个客户端创建一个名为Lock节点，只有一个能够成功。
算法思路: 利用名称唯一性，加锁操作时，只需要所有客户端一起创建/test/Lock节点，只有一个创建成功，成功者获得锁。解锁时，只需删除/test/Lock节点，其余客户端再次进入竞争创建节点，直到所有客户端都获得锁。
基于以上机制，利用节点名称唯一性机制的共享锁算法流程如图所示：

该共享锁实现很符合我们通常多个线程去竞争锁的概念，利用节点名称唯一性的做法简明、可靠。
由上述算法容易看出，由于客户端会同时收到/test/Lock被删除的通知，重新进入竞争创建节点，故存在"惊群现象"。
使用该方法进行测试锁的性能列表如下：

总结 这种方案的正确性和可靠性是ZooKeeper机制保证的，实现简单。缺点是会产生“惊群”效应，假如许多客户端在等待一把锁，当锁释放时候所有客户端都被唤醒，仅仅有一个客户端得到锁。

2. 利用临时顺序节点实现共享锁的一般做法
首先介绍一下，Zookeeper中有一种节点叫做顺序节点，故名思议，假如我们在/lock/目录下创建节3个点，ZooKeeper集群会按照提起创建的顺序来创建节点，节点分别为/lock/0000000001、/lock/0000000002、/lock/0000000003。
ZooKeeper中还有一种名为临时节点的节点，临时节点由某个客户端创建，当客户端与ZooKeeper集群断开连接，则开节点自动被删除。
利用上面这两个特性，我们来看下获取实现分布式锁的基本逻辑：
客户端调用create()方法创建名为“locknode/guid-lock-”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL_SEQUENTIAL。
客户端调用getChildren(“locknode”)方法来获取所有已经创建的子节点，同时在这个节点上注册上子节点变更通知的Watcher。
客户端获取到所有子节点path之后，如果发现自己在步骤1中创建的节点是所有节点中序号最小的，那么就认为这个客户端获得了锁。
如果在步骤3中发现自己并非是所有子节点中最小的，说明自己还没有获取到锁，就开始等待，直到下次子节点变更通知的时候，再进行子节点的获取，判断是否获取锁。
释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。
上面这个分布式锁的实现中，大体能够满足了一般的分布式集群竞争锁的需求。这里说的一般性场景是指集群规模不大，一般在10台机器以内。
不过，细想上面的实现逻辑，我们很容易会发现一个问题，步骤4，“即获取所有的子点，判断自己创建的节点是否已经是序号最小的节点”，这个过程，在整个分布式锁的竞争过程中，大量重复运行，并且绝大多数的运行结果都是判断出自己并非是序号最小的节点，从而继续等待下一次通知——这个显然看起来不怎么科学。客户端无端的接受到过多的和自己不相关的事件通知，这如果在集群规模大的时候，会对Server造成很大的性能影响，并且如果一旦同一时间有多个节点的客户端断开连接，这个时候，服务器就会像其余客户端发送大量的事件通知——这就是所谓的惊群效应。而这个问题的根源在于，没有找准客户端真正的关注点。
我们再来回顾一下上面的分布式锁竞争过程，它的核心逻辑在于：判断自己是否是所有节点中序号最小的。于是，很容易可以联想的到的是，每个节点的创建者只需要关注比自己序号小的那个节点。

3、利用临时顺序节点实现共享锁的改进实现
下面是改进后的分布式锁实现，和之前的实现方式唯一不同之处在于，这里设计成每个锁竞争者，只需要关注”locknode”节点下序号比自己小的那个节点是否存在即可。
算法思路：对于加锁操作，可以让所有客户端都去/lock目录下创建临时顺序节点，如果创建的客户端发现自身创建节点序列号是/lock/目录下最小的节点，则获得锁。否则，监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点），进入等待。
对于解锁操作，只需要将自身创建的节点删除即可。
具体算法流程如下图所示:

使用上述算法进行测试的的结果如下表所示：

该算法只监控比自身创建节点序列号小(比自己小的最大的节点)的节点，在当前获得锁的节点释放锁的时候没有“惊群”。
总结 利用临时顺序节点来实现分布式锁机制其实就是一种按照创建顺序排队的实现。这种方案效率高，避免了“惊群”效应，多个客户端共同等待锁，当锁释放时只有一个客户端会被唤醒。

4、使用menagerie
其实就是对方案3的一个封装，不用自己写代码了。直接拿来用就可以了。
menagerie基于Zookeeper实现了java.util.concurrent包的一个分布式版本。这个封装是更大粒度上对各种分布式一致性使用场景的抽象。其中最基础和常用的是一个分布式锁的实现： org.menagerie.locks.ReentrantZkLock，通过ZooKeeper的全局有序的特性和EPHEMERAL_SEQUENTIAL类型znode的支持，实现了分布式锁。具体做法是：不同的client上每个试图获得锁的线程，都在相同的basepath下面创建一个EPHEMERAL_SEQUENTIAL的node。EPHEMERAL表示要创建的是临时znode，创建连接断开时会自动删除； SEQUENTIAL表示要自动在传入的path后面缀上一个自增的全局唯一后缀,作为最终的path。因此对不同的请求ZK会生成不同的后缀，并分别返回带了各自后缀的path给各个请求。因为ZK全局有序的特性，不管client请求怎样先后到达，在ZKServer端都会最终排好一个顺序，因此自增后缀最小的那个子节点，就对应第一个到达ZK的有效请求。然后client读取basepath下的所有子节点和ZK返回给自己的path进行比较，当发现自己创建的sequential node的后缀序号排在第一个时，就认为自己获得了锁；否则的话，就认为自己没有获得锁。这时肯定是有其他并发的并且是没有断开的client/线程先创建了node。

⑺ etcd是什么东西它和ZooKeeper有什么区别

• etcd
  

1. etcd作为最近很火的一个高可用性?键值对服务发现系统被Kubernetes等系统广泛使用

2. 他相比与zookeeper来说更加简单，在面对较小集群时可能会效率更高些?，而且他的编写语言Go本身就是一种多线程编程语言，确实有很大吸引人的地方（虽然我不懂Go语言，但是在学习docker时也是一睹其风采了）

3. 在Raft中，任何时候一个服务器可以扮演下面角色之一：

   Leader: 处理所有客户端交互，日志复制等，一般一次只有一个Leader.

   Follower: 类似选民，完全被动

   Candidate候选人: 类似Proposer律师，可以被选为一个新的领导人。

4. leader选举阶段

5. 消息同步阶段

6. Leader要求Followe遵从他的指令，都将这个新的日志内容追加到他们各自日志中：

7. 大多数follower服务器将日志写入磁盘文件后，确认追加成功，发出Commited Ok:

8. 在下一个心跳heartbeat中，Leader会通知所有Follwer更新commited 项目。对于每个新的日志记录，重复上述过程。

• zookeeper：

1. zookeeper是基于paxos的简化版zab，我觉得确实很难理解?，以前看了好多遍《从paxos到zookeper》才感觉似懂非懂了，然而过了几个月发现又一脸蒙蔽了，在这里在整理一下（仅表示我自己的理解）

2. ZAB协议中存在着三种状态，每个节点都属于以下三种中的一种：

   Looking ：系统刚启动时或者Leader崩溃后正处于选举状态

   Following ：Follower节点所处的状态，Follower与Leader处于数据同步阶段；

   Leading ：Leader所处状态，当前集群中有一个Leader为主进程；

3. 在开始时，所有的节点都是looking状态并且每个节点都希望自己能成为leader节点，所有每个节点都会向集群中发送一个提案内容是选取自己作为leader节点，提案编号是ZXID(ZAB协议中使用ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1，高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID；ZAB使用epoch来区分不同的Leader周期),如果得到的提案的zxid比自己的大则说明发出这个题案的节点数据更新，则进行同意的投票，否则继续投自己，先得到多数的同意的节点当选为leader

4. 现在leader就可以进行管理了，zookeeper也是两段提交的实现，客户端提交事务请求时Leader节点为每一个请求生成一个事务Proposal，将其发送给集群中所有的Follower节点，收到过半Follower的反馈后开始对事务进行提交，ZAB协议使用了原子广播协议