赞
踩
功能:增加Topic分区的可用性
每个Partition分为leader和follower两部分(前提是replication factor大于1的)
- eg: Topic: hadoop2 Partition: 0 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1
- ====> leader是brokerid为3的服务,Replicas:复制节点3,0,1; Isr: 3,0,1 指定当前partition活跃的partition(leader + 活跃follower)
建议:一般情况下,每个分区的replication factor为3-5比较合适;通过shell脚本监控分区的变化,当有效分区数量过少的时候,通知开发人员手动参与进去修改分区节点数
方式:通过ISR来实现Leader的选择。当leader宕机的时候,会从isr列表中选择一个节点来进行恢复。
原则:
(1)当一个partition宕机或者落后数据太多,leader会将该partition的broker标识符从isr列表中删除;也就是只有isr中的节点才有可能成为主节点
(2) 当leader宕机的时候,其它有效的partition会在zk中创建一个文件夹目录(只会有一个follower节点创建成功),创建成功的follower节点成为新的leader节点
(3)当原来的leader节点重新恢复后,会成为一个新的follower节点,添加到ISR列表中(会同步数据)
实现前提:内部是基于zk的watch机制来实现通知以及文件夹的创建的
消息传输协议/类型 ===> 是对于消息系统中消息传递可靠性保障的一个定义
(1)三种类型的定义:【kafka仅有前两种】
-1. At most once: 最多发送一次,允许数据丢失,但是不允许的数据重复的情况下使用该方式
-2. At least once: 最少发送一次,允许数据重复,但是不允许数据丢失的情况下使用该方式
-3. Exactly once: 仅发送一次数据,但是不允许存储数据丢失和重复的情况,有可能存储数据发送失败的情况
(2)Kafka中实现数据传输的可靠性方式:
数据存储过程中的可靠性保证:
通过Kafka Partition Replication以及Kafka Leader Election来保证的
(3)Producer端:
功能:生产者将数据发送给kafka
可靠性实现方式:通过参数request.required.acks来决定的,acks是生产者等待kafka集群的接收确认返回值,主要有三个参数:
- 0:这意味着生产者producer不等待来自broker同步完成的确认继续发送下一条(批)消息。此选项提供最低的延
- 迟但最弱的耐久性保证(当服务器发生故障时某些数据会丢失,如leader已死,但producer并不知情,发出
- 去的信息broker就收不到)。
- 1:这意味着producer在leader已成功收到的数据并得到确认后发送下一条message。此选项提供了更好的耐久性
- 为客户等待服务器确认请求成功(被写入死亡leader但尚未复制将失去了唯一的消息)。
- -1:这意味着producer在follower副本确认接收到数据后才算一次发送完成。
- 此选项提供最好的耐久性,我们保证没有信息将丢失,只要至少一个同步副本保持存活。
三种机制,性能依次递减 (producer吞吐量降低),数据健壮性则依次递增。
(4)Consumer端:
功能:消费Kafka中对应Topic中的数据
可靠性保证:
每个Parition中的数据是有序的,每条数据在每个Partiiton中都存在一个offset偏移量(数据是按照offset递增的顺序排列的)
Kafka中的数据是否被某个Consumer消费,就根据该Consumer的Offset的值决定数据是否会被消费;
offset表示了consumer消费偏移量小于offset的数据,大于等于offset的数据是没有被消费的
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。