目录
1、AR
在Kafka中维护了一个AR列表，包括所有的分区的副本。AR又分为ISR和OSR。
AR = ISR + OSR。
AR、ISR、OSR、LEO、HW这些信息都被保存在Zookeeper中。
1．ISR
ISR中的副本都要同步leader中的数据，只有都同步完成了数据才认为是成功提交了，成功提交之后才能供外界访问。
在这个同步的过程中，数据即使已经写入也不能被外界访问，这个过程是通过LEO-HW机制来实现的。
2．OSR
OSR内的副本是否同步了leader的数据，不影响数据的提交，OSR内的follower尽力的去同步leader，可能数据版本会落后。
最开始所有的副本都在ISR中，在kafka工作的过程中，如果某个副本同步速度慢于replica.lag.time.max.ms指定的阈值，则被踢出ISR存入OSR，如果后续速度恢复可以回到ISR中。
3．LEO
LogEndOffset：分区的最新的数据的offset，当数据写入leader后，LEO就立即执行该最新数据。相当于最新数据标识位。
4．HW
HighWatermark：只有写入的数据被同步到所有的ISR中的副本后，数据才认为已提交，HW更新到该位置，HW之前的数据才可以被消费者访问，保证没有同步完成的数据不会被消费者访问到。相当于所有副本同步数据标识位。
在leader宕机后，只能从ISR列表中选取新的leader，无论ISR中哪个副本被选为新的leader，它都知道HW之前的数据，可以保证在切换了leader后，消费者可以继续看到HW之前已经提交的数据。
所以LEO代表已经写入的最新数据位置，而HW表示已经同步完成的数据，只有HW之前的数据才能被外界访问。
5．HW截断机制
如果leader宕机，选出了新的leader，而新的leader并不能保证已经完全同步了之前leader的所有数据，只能保证HW之前的数据是同步过的，此时所有的follower都要将数据截断到HW的位置，再和新的leader同步数据，来保证数据一致。
当宕机的leader恢复，发现新的leader中的数据和自己持有的数据不一致，此时宕机的leader会将自己的数据截断到宕机之前的hw位置，然后同步新leader的数据。宕机的leader活过来也像follower一样同步数据，来保证数据的一致性。
2、生产者可靠性级别
通过以上的讲解，已经可以保证kafka集群内部的可靠性，但是在生产者向kafka集群发送时，数据经过网络传输，也是不可靠的，可能因为网络延迟、闪断等原因造成数据的丢失。
kafka为生产者提供了如下的三种可靠性级别，通过不同策略保证不同的可靠性保障。
其实此策略配置的就是leader将成功接收消息信息响应给客户端的时机。
通过request.required.acks参数配置：
1：生产者发送数据给leader，leader收到数据后发送成功信息，生产者收到后认为发送数据成功，如果一直收不到成功消息，则生产者认为发送数据失败会自动重发数据。
当leader宕机时，可能丢失数据。
0：生产者不停向leader发送数据，而不需要leader反馈成功消息。
这种模式效率最高，可靠性最低。可能在发送过程中丢失数据，也可能在leader宕机时丢失数据。
-1：生产者发送数据给leader，leader收到数据后要等到ISR列表中的所有副本都同步数据完成后，才向生产者发送成功消息，如果一只收不到成功消息，则认为发送数据失败会自动重发数据。
这种模式下可靠性很高，但是当ISR列表中只剩下leader时，当leader宕机让然有可能丢数据。
此时可以配置min.insync.replicas指定要求观察ISR中至少要有指定数量的副本，默认该值为1，需要改为大于等于2的值
这样当生产者发送数据给leader但是发现ISR中只有leader自己时，会收到异常表明数据写入失败，此时无法写入数据，保证了数据绝对不丢。
虽然不丢但是可能会产生冗余数据，例如生产者发送数据给leader，leader同步数据给ISR中的follower，同步到一半leader宕机，此时选出新的leader，可能具有部分此次提交的数据，而生产者收到失败消息重发数据，新的leader接受数据则数据重复了。
3、leader选举
当leader宕机时会选择ISR中的一个follower成为新的leader，如果ISR中的所有副本都宕机，怎么办？
有如下配置可以解决此问题：
unclean.leader.election.enable=false
策略1：必须等待ISR列表中的副本活过来才选择其成为leader继续工作。
unclean.leader.election.enable=true
策略2：选择任何一个活过来的副本，成为leader继续工作，此follower可能不在ISR中。
策略1，可靠性有保证，但是可用性低，只有最后挂了leader活过来kafka才能恢复。
策略2，可用性高，可靠性没有保证，任何一个副本活过来就可以继续工作，但是有可能存在数据不一致的情况。
4、kafka可靠性的保证
At most once：消息可能会丢，但绝不会重复传输。
At least once：消息绝不会丢，但可能会重复传输。
Exactly once：每条消息肯定会被传输一次且仅传输一次。
kafka最多保证At least once，可以保证不丢，但是可能会重复，为了解决重复需要引入唯一标识和去重机制，kafka提供了GUID实现了唯一标识，但是并没有提供自带的去重机制，需要开发人员基于业务规则自己去重。
1）消费端弄丢了数据
唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
生产环境碰到的一个问题，就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把消息写入内存queue，然后消费者会自动提交offset。
然后此时我们重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了
2）kafka弄丢了数据
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个数据就丢了
所以此时一般是要求起码设置如下4个参数：
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了
我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失
3）生产者会不会弄丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
4、zookeeper 是如何保证数据一致性的
ZooKeeper是个集群，内部有多个server，每个server都可以连接多个client，每个client都可以修改server中的数据
ZooKeeper可以保证每个server内的数据完全一致，是如何实现的呢？
答：数据一致性是靠Paxos算法保证的，Paxos可以说是分布式一致性算法的鼻祖，是ZooKeeper的基础
Paxos的基本思路：(深入解读zookeeper一致性原理)
假设有一个社团，其中有团员、议员（决议小组成员）两个角色
团员可以向议员申请提案来修改社团制度
议员坐在一起，拿出自己收到的提案，对每个提案进行投票表决，超过半数通过即可生效
为了秩序，规定每个提案都有编号ID，按顺序自增
每个议员都有一个社团制度笔记本，上面记着所有社团制度，和最近处理的提案编号，初始为0
投票通过的规则：
新提案ID 是否大于 议员本中的ID，是议员举手赞同
如果举手人数大于议员人数的半数，即让新提案生效
例如：
刚开始，每个议员本子上的ID都为0，现在有一个议员拿出一个提案：团费降为100元，这个提案的ID自增为1
每个议员都和自己ID对比，一看 1>0，举手赞同，同时修改自己本中的ID为1
发出提案的议员一看超过半数同意，就宣布：1号提案生效
然后所有议员都修改自己笔记本中的团费为100元
以后任何一个团员咨询任何一个议员："团费是多少？"，议员可以直接打开笔记本查看，并回答：团费为100元
可能会有极端的情况，就是多个议员一起发出了提案，就是并发的情况
例如
刚开始，每个议员本子上的编号都为0，现在有两个议员（A和B）同时发出了提案，那么根据自增规则，这两个提案的编号都为1，但只会有一个被先处理
假设A的提案在B的上面，议员们先处理A提案并通过了，这时，议员们的本子上的ID已经变为了1，接下来处理B的提案，由于它的ID是1，不大于议员本子上的ID，B提案就被拒绝了，B议员需要重新发起提案
上面就是Paxos的基本思路，对照ZooKeeper，对应关系就是：
团员 -client
议员 -server
议员的笔记本 -server中的数据
提案 -变更数据的请求
提案编号 -zxid（ZooKeeper Transaction Id）
提案生效 -执行变更数据的操作
ZooKeeper中还有一个leader的概念，就是把发起提案的权利收紧了，以前是每个议员都可以发起提案，现在有了leader，大家就不要七嘴八舌了，先把提案都交给leader，由leader一个个发起提案
Paxos算法就是通过投票、全局编号机制，使同一时刻只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被批准，所以永远只会有一个写操作得到批准，其他的写操作竞争失败只好再发起一轮投票
1）一致性保证
Zookeeper是一种高性能、可扩展的服务。Zookeeper的读写速度非常快，并且读的速度要比写的速度更快。另外，在进行读操作的时候，ZooKeeper依然能够为旧的数据提供服务。这些都是由于ZooKeepe所提供的一致性保证，它具有如下特点：
顺序一致性
客户端的更新顺序与它们被发送的顺序相一致。
原子性
更新操作要么成功要么失败，没有第三种结果。
单系统镜像
无论客户端连接到哪一个服务器，客户端将看到相同的ZooKeeper视图。
可靠性
一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。。这个保证将会产生下面两种结果：
1．如果客户端成功地获得了正确的返回代码，那么说明更新已经成果。如果不能够获得返回代码（由于通信错误、超时等等），那么客户端将不知道更新操作是否生效。
2．当从故障恢复的时候，任何客户端能够看到的执行成功的更新操作将不会被回滚。
实时性
在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。
给予这些一致性保证，ZooKeeper更高级功能的设计与实现将会变得非常容易，例如：leader选举、队列以及可撤销锁等机制的实现。
2）Leader选举
ZooKeeper需要在所有的服务（可以理解为服务器）中选举出一个Leader，然后让这个Leader来负责管理集群。此时，集群中的其它服务器则成为此Leader的Follower。并且，当Leader故障的时候，需要ZooKeeper能够快速地在Follower中选举出下一个Leader。这就是ZooKeeper的Leader机制，下面我们将简单介绍在ZooKeeper中，Leader选举（Leader Election）是如何实现的。
此操作实现的核心思想是：首先创建一个EPHEMERAL目录节点，例如“/election”。然后。每一个ZooKeeper服务器在此目录下创建一个SEQUENCE|EPHEMERAL 类型的节点，例如“/election/n_”。在SEQUENCE标志下，ZooKeeper将自动地为每一个ZooKeeper服务器分配一个比前一个分配的序号要大的序号。此时创建节点的ZooKeeper服务器中拥有最小序号编号的服务器将成为Leader。
在实际的操作中，还需要保障：当Leader服务器发生故障的时候，系统能够快速地选出下一个ZooKeeper服务器作为Leader。一个简单的解决方案是，让所有的follower监视leader所对应的节点。当Leader发生故障时，Leader所对应的临时节点将会自动地被删除，此操作将会触发所有监视Leader的服务器的watch。这样这些服务器将会收到Leader故障的消息，并进而进行下一次的Leader选举操作。但是，这种操作将会导致“从众效应”的发生，尤其当集群中服务器众多并且带宽延迟比较大的时候，此种情况更为明显。
在Zookeeper中，为了避免从众效应的发生，它是这样来实现的：每一个follower对follower集群中对应的比自己节点序号小一号的节点（也就是所有序号比自己小的节点中的序号最大的节点）设置一个watch。只有当follower所设置的watch被触发的时候，它才进行Leader选举操作，一般情况下它将成为集群中的下一个Leader。很明显，此Leader选举操作的速度是很快的。因为，每一次Leader选举几乎只涉及单个follower的操作。
2431
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
