dubbo+zookeeper

dubbo

　　Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。

总体架构

Dubbo的总体架构，如图所示：

 

Dubbo作为一个分布式服务框架，主要具有如下几个核心的要点：

服务定义
    服务是围绕服务提供方和服务消费方的，服务提供方实现服务，而服务消费方调用服务。

服务注册
    服务提供方，它需要发布服务，而且由于应用系统的复杂性，服务的数量、类型也不断膨胀；对于服务消费方，它最关心如何获取到它所需要的服务，而面对复杂的应用系统，需要管理大量的服务调用。而且，对于服务提供方和服务消费方来说，他们还有可能兼具这两种角色，即既需要提供服务，有需要消费服务。
通过将服务统一管理起来，可以有效地优化内部应用对服务发布/使用的流程和管理。服务注册中心可以通过特定协议来完成服务对外的统一。

Dubbo提供的注册中心有如下几种类型可供选择：Multicast注册中心、Zookeeper注册中心、Redis注册中心、Simple注册中心

服务监控：服务提供方，还是服务消费方，他们都需要对服务调用的实际状态进行有效的监控，从而改进服务质量。

远程通信与信息交换

     远程通信需要指定通信双方所约定的协议，在保证通信双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通信框架，主要包括如下几个：Mina、Netty、Grizzly

服务调用

下面从Dubbo官网直接拿来，看一下基于RPC层，服务提供方和服务消费方之间的调用关系，如图所示：

 

1、服务提供方发布服务到服务注册中心；

2、服务消费方从服务注册中心订阅服务；

3、服务消费方调用已经注册的可用服务；

节点角色说明：

　　Provider: 暴露服务的服务提供方。

　　Consumer: 调用远程服务的服务消费方。

　　Registry: 服务注册与发现的注册中心。

　　Monitor: 统计服务的调用次调和调用时间的监控中心。

　　Container: 服务运行容器。

调用关系说明：

　　0. 服务容器负责启动，加载，运行服务提供者。

　　1. 服务提供者在启动时，向注册中心注册自己提供的服务。

　　2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

　　3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

　　4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

　　5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

接着，将上面抽象的调用流程图展开，详细如图所示：

 

Dubbo支持多种协议，如下所示：Dubbo协议、Hessian协议、HTTP协议、RMI协议、WebService协议、Thrift协议、Memcached协议、Redis协议

Dubbo以包结构来组织各个模块，各个模块及其关系，如图所示：

 

可以通过Dubbo的代码（使用Maven管理）组织，与上面的模块进行比较。简单说明各个包的情况：

dubbo-common 公共逻辑模块，包括Util类和通用模型。

dubbo-remoting 远程通讯模块，相当于Dubbo协议的实现，如果RPC用RMI协议则不需要使用此包。

dubbo-rpc 远程调用模块，抽象各种协议，以及动态代理，只包含一对一的调用，不关心集群的管理。

dubbo-cluster 集群模块，将多个服务提供方伪装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表可以是静态配置的，也可以是由注册中心下发。

dubbo-registry 注册中心模块，基于注册中心下发地址的集群方式，以及对各种注册中心的抽象。

dubbo-monitor 监控模块，统计服务调用次数，调用时间的，调用链跟踪的服务。

dubbo-config 配置模块，是Dubbo对外的API，用户通过Config使用Dubbo，隐藏Dubbo所有细

dubbo-container 容器模块，是一个Standalone的容器，以简单的Main加载Spring启动，因为服务通常不需要Tomcat/JBoss等Web容器的特性，没必要用Web容器去加载服务。 

 

一、dubbo的核心服务是什么？

　　1.远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。

　　2.集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。

　　3.自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

二、服务提供者暴露一个服务的详细过程：如果你仔细观察dubbo的启动日志你会发现，dubbo的provider启动主要是以下几个过程

　　1.首先provider启动时，先把想要提供的服务暴露在本地。

　　2.然后再把服务暴露到远程。

　　3.启动netty服务，建立长连接。

　　4.连接到注册中心zk上。

　　5.然后监控zk上的消费服务。

三、下面来看本地暴露于远程暴露的区别：

　　1、本地暴露是暴露在本机JVM中,调用本地服务不需要网络通信.

　　2、远程暴露是将ip,端口等信息暴露给远程客户端,调用远程服务时需要网络通信.

四、什么情况下适用dubbo协议，什么时候适用rmi协议？

　　Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是dubbo协议是官网推荐使用的，dubbo 缺省协议是dubbo协议，采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。RMI协议采用阻塞式(同步)短连接和 JDK 标准序列化方式。适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。 

五、Dubbo有几种容错机制

　　什么是容错机制？容错机制指的是某中系统控制在一定范围的一种允许或包容犯错情况的发生，举个简单的例子，我们在电脑上运行一个程序，有时候会出现无响应的情况，然后系统回弹出一个提示框让我们选择，是立即结束还是继续等待，然后根据我们的选择执行对应的操作，这就是“容错”。

　　在分布式架构下，网络，硬件，应用都可以发生故障，由于各个服务之间可能存在依赖关系，如果一条链路中的某一个节点出现故障，将会导致雪崩效应。为了减少某一个节点故障的影响范围，所以我们才需要去构建容错服务，来优雅的处理这种中断的响应结果

　　1.failsafe 失败安全，可以认为是把错误吞掉（记录日志）

　　2.failover(默认)  重试其他服务器；retries(2)重试的次数，默认为2次

　　3.failback   失败后自动恢复

　　4.forking forks. 设置并行数

　　5.Broadcast 广播，任意一台报错，则执行的方法报错，通过cluster方式，配置制定的容错方案

六、dubbo的服务降级

降级的目的是为了保证核心服务可用

降级可以有几个层面的分类：自动降级，人工降级；按照功能可以分为：读服务降级和写服务降级；

　　1.对一些非核心服务进行人工降级，在大促之前通过降级开关关闭那些推荐内容，评价等对主流程序没有影响的功能

　　2.故障降级，比如调用的远程服务挂了，网络故障，或者RPC服务返回异常。那么可以直接降级，降级的方案比如设置默认值，采用兜底数据（系统推荐的行为广告挂了，可以提前准备静态页面做返回）等等

　　3.限流降级，在秒杀这种流量比较集中并且流量特别大的情况下，因为突发访问量特别大可能导致系统支撑不了。这个时候可以采用限流来限制访问量。当达到阈值时，后续的请求被降级，比如进入排队页面，比如跳转到错误页面（活动火爆，请稍后重试）

Dubbo的降级方式：Mock

实现步骤

　　1.在client端创建一个testmock类，实现对应的IGphello的接口（需要对哪个接口进行mock，就实现哪个）名称必须以mock结尾

　　2.在client端的xml配置文件中，添加如下配置，增加一个mock属性指向创建的testmock

　　3.模拟错误（设置timeout）模拟超时异常，运行测试代码即可访问到testmock这个类，当服务端故障解除以后，调用过程将恢复正常

七、dubbo的优先级配置

配置优先级别

1.以timeout为例，显示了配置的查找顺序，其他retries，loadbalance等类似。

（1）方法级优先，接口级次之，全局配置在次之

（2）如果级别一样，则消费方优先，提供方次之

（3）其中，服务提供方配置，通过URL经由注册中心传递给消费方

2.建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置。

 

Apache ZooKeeper

Zookeeper是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠的协调系统，提供的功能包括命名服务、配置维护、分布式同步、集群服务等。
Zookeeper是可以集群复制的，集群间通过Zab(Zookeeper Atomic Broadcast)协议来保持数据的一致性。

　　该协议包括2个阶段：leader election阶段和Atomic broadcast阶段。集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过broadcast将所有的更新告诉follower。当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，(使用选举算法，少数服从多数，因此如果有4台机器，至多只允许一台宕机 总2n+1台，除非挂掉大于n台)让所有的服务器都恢复到一个正确的状态。当leader被选举出来，且大多数服务器完成了和leader的状态同步后，leader election的过程就结束了，将进入Atomic broadcast的过程。Actomic broadcast同步leader和follower之间的信息，保证leader和follower具备相同的系统状态。

Zookeeper集群的结构图如下：

 

路由和负载均衡的实现

　　一旦服务器与ZooKeeper集群断开连接，节点也就不存在了，通过注册相应的watcher，服务消费者能够第一时间获知服务提供者机器信息的变更。利用其znode的特点和watcher机制，将其作为动态注册和获取服务信息的配置中心，统一管理服务名称和其对应的服务器列表信息，我们能够近乎实时地感知到后端服务器的状态(上线、下线、宕机)。Zookeeper集群间通过Zab协议，服务配置信息能够保持一致，而Zookeeper本身容错特性和leader选举机制，能保证我们方便地进行扩容。

　　　Zookeeper中，服务提供者在启动时，将其提供的服务名称、服务器地址、以节点的形式注册到服务配置中心，服务消费者通过服务配置中心来获得需要调用的服务名称节点下的机器列表节点。通过前面所介绍的负载均衡算法，选取其中一台服务器进行调用。当服务器宕机或者下线时，由于znode非持久的特性，相应的机器可以动态地从服务配置中心里面移除，并触发服务消费者的watcher。在这个过程中，服务消费者只有在第一次调用服务时需要查询服务配置中心，然后将查询到的服务信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求到服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更(机器上线或者下线)，变更行为会触发服务消费者注册的相应的watcher进行服务地址的重新查询。这种无中心化的结构，使得服务消费者在服务信息没有变更时，几乎不依赖配置中心，解决了之前负载均衡设备所导致的单点故障的问题，并且大大降低了服务配置中心的压力。

 　　通过Zookeeper来实现服务动态注册、机器上线与下线的动态感知，扩容方便，容错性好，且无中心化结构能够解决之前使用负载均衡设备所带来的单点故障问题。只有当配置信息更新时服务消费者才会去Zookeeper上获取最新的服务地址列表，其他时候使用本地缓存即可，这样服务消费者在服务信息没有变更时，几乎不依赖配置中心，能大大降低配置中心的压力。

1、Zookeeper的角色

　　» 领导者（leader），负责进行投票的发起和决议，更新系统状态
　　» 学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
　　» Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
　　» 客户端（client），请求发起方

 

 

• Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协
　　   议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者
　　　崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后
　　  ，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

• 为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（
　　　proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识
　　   leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的
　　　统治时期。低32位用于递增计数。
• 每个Server在工作过程中有三种状态：
　　　　LOOKING：当前Server不知道leader是谁，正在搜寻
　　　　LEADING：当前Server即为选举出来的leader
　　　　FOLLOWING：leader已经选举出来，当前Server与之同步

2、Zookeeper的读写机制

　　» Zookeeper是一个由多个server组成的集群
　　» 一个leader，多个follower
　　» 每个server保存一份数据副本
　　» 全局数据一致
　　» 分布式读写
　　» 更新请求转发，由leader实施

3、Zookeeper 的保证　

　　» 更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
　　» 数据更新原子性，一次数据更新要么成功，要么失败
　　» 全局唯一数据视图，client无论连接到哪个server，数据视图都是一致的
　　» 实时性，在一定事件范围内，client能读到最新数据

4、Zookeeper节点数据操作流程

 

注： 1.在Client向Follwer发出一个写的请求

　　　　　　2.Follwer把请求发送给Leader

　　　　　　3.Leader接收到以后开始发起投票并通知Follwer进行投票

　　　　　　4.Follwer把投票结果发送给Leader

　　　　　　5.Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;

　　　　　　6.Follwer把请求结果返回给Client

　　　　• Follower主要有四个功能：
　　　　• 1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
　　　　• 2 .接收Leader消息并进行处理；
　　　　• 3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
　　　　• 4 .返回Client结果。
　　　　　　• Follower的消息循环处理如下几种来自Leader的消息：
　　　　　　• 1 .PING消息： 心跳消息；
　　　　　　• 2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
　　　　　　• 3 .COMMIT消息：服务器端最新一次提案的信息；
　　　　　　• 4 .UPTODATE消息：表明同步完成；
　　　　　　• 5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
　　　　　　• 6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

5、Zookeeper leader 选举　　

　　• 半数通过
　　　　– 3台机器 挂一台 2>3/2
　　　　– 4台机器 挂2台 2！>4/2

 

　　• A提案说，我要选自己，B你同意吗？C你同意吗？B说，我同意选A；C说，我同意选A。(注意，这里超过半数了，其实在现实世界选举已经成功了。

　　　但是计算机世界是很严格，另外要理解算法，要继续模拟下去。)
　　• 接着B提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；C说，A已经超半数同意当选，B提案无效。
　　• 接着C提案说，我要选自己，A你同意吗；A说，我已经超半数同意当选，你的提案无效；B说，A已经超半数同意当选，C的提案无效。
　　• 选举已经产生了Leader，后面的都是follower，只能服从Leader的命令。而且这里还有个小细节，就是其实谁先启动谁当头。

 

　　

6、zxid

　　• znode节点的状态信息中包含czxid, 那么什么是zxid呢?
　　• ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.

　　　创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

7、Zookeeper工作原理

　　» Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。

　　　当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。

　　　状态同步保证了leader和server具有相同的系统状态

　　» 一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，

　　　发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分

　　　的followers支持。

　　» 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。

　　　实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。

　　» 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。　

　　» 每个Server启动以后都询问其它的Server它要投票给谁。
　　» 对于其他server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）
　　» 收到所有Server回复以后，就计算出zxid最大的哪个Server，并将这个Server相关信息设置成下一次要投票的Server。
　　» 计算这过程中获得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则改server被选为leader。否则，继续这个过程，直到leader被选举出来　　

　　» leader就会开始等待server连接
　　» Follower连接leader，将最大的zxid发送给leader
　　» Leader根据follower的zxid确定同步点
　　» 完成同步后通知follower 已经成为uptodate状态
　　» Follower收到uptodate消息后，又可以重新接受client的请求进行服务了

8、数据一致性与paxos 算法　　

　　• 据说Paxos算法的难理解与算法的知名度一样令人敬仰，所以我们先看如何保持数据的一致性，这里有个原则就是：
　　• 在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。
　　• Paxos算法解决的什么问题呢，解决的就是保证每个节点执行相同的操作序列。好吧，这还不简单，master维护一个
　　   全局写队列，所有写操作都必须 放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一
　　　致性。没错，就是这样，可是如果master挂了呢。
　　• Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，
　　　只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一
　　　轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排 序。编号严格递增，当一个节点接受了一个
　　　编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己 数据
　　　不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。
　 总结
　　• Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。

9、Observer　　

　　• Zookeeper需保证高可用和强一致性；
　　• 为了支持更多的客户端，需要增加更多Server；
　　• Server增多，投票阶段延迟增大，影响性能；
　　• 权衡伸缩性和高吞吐率，引入Observer
　　• Observer不参与投票；
　　• Observers接受客户端的连接，并将写请求转发给leader节点；
　　• 加入更多Observer节点，提高伸缩性，同时不影响吞吐率

10、 为什么zookeeper集群的数目，一般为奇数个？

　　•Leader选举算法采用了Paxos协议；
　　•Paxos核心思想：当多数Server写成功，则任务数据写成功如果有3个Server，则两个写成功即可；如果有4或5个Server，则三个写成功即可。
　　•Server数目一般为奇数（3、5、7）如果有3个Server，则最多允许1个Server挂掉；如果有4个Server，则同样最多允许1个Server挂掉由此，

　　  我们看出3台服务器和4台服务器的的容灾能力是一样的，所以为了节省服务器资源，一般我们采用奇数个数，作为服务器部署个数。

11、Zookeeper 的数据模型　

　　» 层次化的目录结构，命名符合常规文件系统规范
　　» 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
　　» 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
　　» Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
　　» 客户端应用可以在节点上设置监视器
　　» 节点不支持部分读写，而是一次性完整读写

12、Zookeeper 的节点

» Znode有两种类型，短暂的（ephemeral）和持久的（persistent）
　　» Znode的类型在创建时确定并且之后不能再修改
　　» 短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点
　　» 持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除
　　» Znode有四种形式的目录节点
　　» PERSISTENT（持久的）
　　» EPHEMERAL(暂时的)
　　» PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）
　　» EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）

13、Zookeeper工作方式

　　》Zookeeper集群包含一个1个Leader，多个Follower

　　》所有的Follower都可提供读服务

　　》所有的写操作都会被forward到Leader

　　》Client与Server通过NIO通信

　　》全局串行化所有的写操作

　　》保证同一客户端的指令被FIFO执行

　　》保证消息通知的FIFO

一、zookeeper 与kafka保持数据一致性的不同点：

(1)zookeeper使用了ZAB(Zookeeper Atomic Broadcast)协议，保证了leader,follower的一致性，leader 负责数据的读写，而follower只负责数据的读，如果follower遇到写操作，会提交到leader;

当leader宕机的话，使用 Fast Leader Election 快速选举出新的leader,节点在一开始都处于选举阶段，只要有一个节点得到超半数节点的票数，它就可以当选准 leader。

(2) kafka 不同，只有leader 负责读写，follower只负责备份，如果leader宕机的话,Kafaka动态维护了一个同步状态的副本的集合（a set of in-sync replicas），简称ISR,ISR中有f+1个节点，就可以允许在f个节点down掉的情况下不会丢失消息并正常提供服。ISR的成员是动态的，如果一个节点被淘汰了，当它重新达到“同步中”的状态时，他可以重新加入ISR。因此如果leader宕了，直接从ISR中选择一个follower就行。

Zab协议-广播模式

客户端每发送一个更新请求，ZooKeeper都会生成一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，这个唯一编号就是事务ID(ZXID)，只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理，Leader服务器会分别为每个Follower服务器创建一个队列，并将事务的先后顺序放入队列中，并按照FIFO的策略进行消息发送。收到需要处理的事务后，Follower服务器会首先以事务日志的形式写入服务器的磁盘中，写入成功后会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后，会向所有Follower服务器广播Commit消息，收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器，它会将请求转发给Leader服务器处理。

二、相同点：

在数据写入过程中，leader与follower都具有相同的先后关系，即数据先写入leader，而后按照一定的规则完成在follower上的最少副本数写入，即可返回调用客户端，该数据写入成功过。
kafka的最少副本数量有min.insync.replicas控制；zookeeper的最少副本数是半数以上节点。
此处的设置都是优先保证可用性，而牺牲一定的数据一致性。

三、具体的Kafka的leader选举机制如下：

Kafka的Leader是什么

  首先Kafka会将接收到的消息分区（partition），每个主题（topic）的消息有不同的分区。这样一方面消息的存储就不会受到单一服务器存储空间大小的限制，另一方面消息的处理也可以在多个服务器上并行。
  其次为了保证高可用，每个分区都会有一定数量的副本（replica）。这样如果有部分服务器不可用，副本所在的服务器就会接替上来，保证应用的持续性。

但是，为了保证较高的处理效率，消息的读写都是在固定的一个副本上完成。这个副本就是所谓的Leader，而其他副本则是Follower。而Follower则会定期地到Leader上同步数据。

Leader选举

  如果某个分区所在的服务器除了问题，不可用，kafka会从该分区的其他的副本中选择一个作为新的Leader。之后所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。显然，只有那些跟Leader保持同步的Follower才应该被选作新的Leader。
  Kafka会在Zookeeper上针对每个Topic维护一个称为ISR（in-sync replica，已同步的副本）的集合，该集合中是一些分区的副本。只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，并反馈给消息的生产者。如果这个集合有增减，kafka会更新zookeeper上的记录。
  如果某个分区的Leader不可用，Kafka就会从ISR集合中选择一个副本作为新的Leader。
  显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数比较高。假设某个topic有f+1个副本，kafka可以容忍f个服务器不可用。

为什么不用少数服从多数的方法

  少数服从多数是一种比较常见的一致性算法和Leader选举法。它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；选择Leader时也是从超过半数的同步的副本中选择。这种算法需要较高的冗余度。譬如只允许一台机器失败，需要有三个副本；而如果只容忍两台机器失败，则需要五个副本。而kafka的ISR集合方法，分别只需要两个和三个副本。

如果所有的ISR副本都失败了怎么办

  此时有两种方法可选，一种是等待ISR集合中的副本复活，一种是选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中。这两种方法各有利弊，实际生产中按需选择。
  如果要等待ISR副本复活，虽然可以保证一致性，但可能需要很长时间。而如果选择立即可用的副本，则很可能该副本并不一致。