.net网站开发框架,建设项目环评在什么网站公示,制作网站一般使用的软件有哪些,广东东莞天气预报15天1.Kafka简介 Kafka 本质上是一个 MQ#xff08;Message Queue#xff09;#xff0c;使用消息队列的优点#xff1a;
解耦#xff1a;允许独立的扩展或修改队列两边的处理过程。可恢复性#xff1a;即使一个处理消息的进程挂掉#xff0c;加入队列中的消息仍然可以在系…1.Kafka简介 Kafka 本质上是一个 MQMessage Queue使用消息队列的优点
解耦允许独立的扩展或修改队列两边的处理过程。可恢复性即使一个处理消息的进程挂掉加入队列中的消息仍然可以在系统恢复后被处理。缓冲有助于解决生产消息和消费消息的处理速度不一致的情况。灵活性和峰值处理能力不会因为突发的超负荷的请求而完全崩溃消息队列能够使关键组件顶住突发的访问压力。异步通信消息队列允许用户把消息放入队列但不立即处理它。 先介绍消息队列的优点
消息队列
消息队列的异步处理
主要应用于短信通知、终端状态推送、App推送、用户注册等。
同步处理 我们同步处理的话我们执行下一个步骤需要等上个步骤完成才能执行下一步这样网速就很慢了但是我们是不是可以将库存作为生产者在库存和订单短信统计之间加一个消息队列的话并且开启订单短信统计三个(消费者)线程分别处理自己的任务那么我们在库存里拿出以后(生产者生产后立马返回再去生产放到消息队列里然后通知消费者线程去消费)这样我们就不需要一步一步
的等待
异步处理 异步处理的优势更快速返回结果减少等待实现并发处理提升系统总体性能。 消息队列的模式可以有 11对1读取之后立刻从队列中移除消息。 21对多这种模型是发布订阅模型消息队列的元素可以被重复消费。至于何时删除消息可以设置消息的存活周期比如kafka可以设置24H后删除消息。
消息队列的流量控制削峰
在秒杀场景下的下单状态使用消息队列隔离网关和后端服务以达到流量控制和保护后端服务的目的。 设置消息队列的最大限制数量在达到最大数量时网关不再生产消息到消息队列中。
可以这么想有一个商品秒杀活动商品数量为100当消息队列的数量达到100时不再生产秒杀成功消息直接返回秒杀失败给用户只有1到100的用户秒杀成功 获得商品。
那么我们以服务器设计的角度去思考在某一时刻我们是为秒杀服务提供服务的生产者我们生产到消息队列的数量达到100的时候就不再生产而我们的客户端再去网上秒杀购物的时候从消息队列里拉取当看到消息队列为空(也就是货物为0)那么就返回秒杀失败
消息队列的服务解耦
A系统负责数据分发其他系统调用A系统提供的接口处理数据当新增一个系统时A系统需要改代码调用新的系统并实现新的接口给新的系统去调用。这种方式是系统间高度耦合。 使用消息队列A系统负责将数据分发到MQ消费端根据需要从MQ获取消息即可不需要就取消MQ的消费。 消息队列的发布订阅
用户需要先去注册才能收到相关消息。 比如游戏里面跨服 1 广播今天整体还剩多少把屠龙刀可以暴。 2 广播用户暴的屠龙刀的消息。 消息队列的高并发缓冲 这个和消息队列的流量控制削峰有些类似。区别在于这里没有大小限流可能在某个时间点会出现超过后端处理能力的访问比如后端处理能力是50000每秒在某个时间点出现每秒80000的访问这就可能造成击穿。
针对此情况消息全部放入消息队列消息队列提供可以把数据固化到磁盘的能力降低高峰数据对后端的短暂冲击。
比如后端处理能力50000某个短暂时间点比如一秒的时间数据访问达到80000消息队列将多的数据缓存到磁盘后端仍然处理50000数据冲击点退去后访问数据降到了30000那么消息队列将把缓存的数据放到后端处理。
比如kafka 日志服务、监控上报。 2.Kafka的架构 Kafka只写数据到leader副本也只从leader副本获取数据。如果leader失效会重新选择出leader(从Follower副本中选出并且得是在同一个topic中的)。 优点类似MySQL的主从关系写数据都是到主机里面但是读数据不一样Kafka读数据只能从主机里面读。
1.Kafka 存储的消息来自任意多被称为 Producer 生产者的进程。数据从而可以被发布到不同的 2.Topic 主题下的不同 Partition 分区。 在一个分区内这些消息被索引并连同时间戳存储在一起。其它被称为 Consumer 消费者的进程可以从分区订阅消息。 3.Kafka 运行在一个由一台或多台服务器组成的集群上并且分区可以跨集群结点分布。
2.1 Kafka 一些重要概念
Producer消息生产者向 Kafka Broker 发消息的客户端。Consumer消息消费者从 Kafka Broker 获取消息的客户端。Consumer Group消费者组CG消费者组内每个消费者负责消费不同分区的数据提高消费能力。一个分区只能由组内一个消费者消费消费者组之间互不影响。所有的消费者都属于某个消费者组即消费者组是逻辑上的一个订阅者。
(注意当同组消费组订阅了同一个topic的话那么同组消费者在消费消息队列的内容的话那么每次只能由组内任意一个消费者进行消费不能同时消费组内的所有消费者同时消费)Broker一台 Kafka 机器就是一个 Broker。一个集群(kafka cluster)由多个 Broker 组成。一个Broker 可以容纳多个 Topic。Topic可以理解为一个队列Topic 将消息分类生产者和消费者面向的是同一个Topic。
(其实这么设计主要是理解为一个逻辑上的存储比如某个公众号的内容都存在topic上面在物理上是存在每个partition)Partition为了实现扩展性提高并发能力一个非常大的 Topic 可以分布到多个 Broker 即服务器上一个 Topic 可以分为多个 Partition同一个topic在不同的分区的数据是不重复的每个 Partition 是一个有序的队列其表现形式就是一个一个的文件夹。
(物理上表示的存储单元)Replication每一个分区都有多个副本副本的作用是做备胎。当主分区Leader故障的时候会选择一个备胎Follower上位成为Leader。在kafka中默认副本的最大数量是10个且副本的数量不能大于Broker的数量follower和leader绝对是在不同的机器同一机器对同一个分区也只可能存放一个副本包括自己。Message消息每一条发送的消息主体。Leader每个分区多个副本的“主”副本生产者发送数据的对象以及消费者消费数据的对象都是 Leader。Follower每个分区多个副本的“从”副本实时从 Leader 中同步数据保持和 Leader 数据的同步。Leader 发生故障时某个 Follower 还会成为新的 Leader。Offset消费者消费的位置信息监控数据消费到什么位置当消费者挂掉再重新恢复的时候可以从消费位置继续消费。同一主题不同的分区它们的offset是独立的。ZooKeeperKafka 集群能够正常工作需要依赖于 ZooKeeperZooKeeper 帮助 Kafka 存储和管理集群信息。
注意在我们启动kafka集群的时候需要先启动zookeeper才能启动kafka
2.2 工作流程 不同的partition的offerset 是独立的。 Kafka 中消息是以 Topic 进行分类的生产者生产消息消费者消费消息面向的都是同一个 Topic。(就是我们前面提到的topic是逻辑上的概率) Topic 是逻辑上的概念而 Partition 是物理上的概念每个 Partition 对应于一个 log 文件该 log 文件中存储的就是 Producer 生产的数据。Producer 生产的数据会不断追加到该 log 文件末端顺序写且每条数据都有自己的 Offset。 消费者组中的每个消费者都会实时记录自己消费到了哪个 Offset以便出错恢复时从上次的位置继续消费。
我们的partition上会记录offset这个offest代表消费者消费的位置以便出错恢复时从上次的位置继续消费日志默认在/tmp/kafka-logs
2.3 文件存储
Kafka文件存储也是通过本地落盘的方式存储的主要是通过相应的log与index等文件保存具体的消息文件。 生产者不断的向log文件追加消息文件为了防止log文件过大导致定位效率低下Kafka的log文件以1G为一个分界点当.log文件大小超过1G的时候此时会创建一个新的.log文件同时为了快速定位大文件中消息位置Kafka采取了分片和索引的机制来加速定位。
在kafka的存储log的地方即文件的地方会存在消费的偏移量以及具体的分区信息分区信息的话主要包括.index和.log文件组成所以总结一句话就是一个topic有多个partition一个partition对应一个log文件我们的生产者生产的数据写到topic的时候就是写入到该topic的partition中也就是写到log文件中log文件又分为多个segment一个segment对应两个文件.index和.log文件
2.4 副本原理
副本机制Replication也可以称之为备份机制通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝。副本机制的好处在于
提供数据冗余即提高可用性。提供高伸缩性支撑更高的读请求量。改善数据局部性降低系统延时。 目前Kafka只实现了副本机制带来的第 1 个好处即是提供数据冗余实现高可用性和高持久性。
在kafka生产环境中每台 Broker 都可能保存有各个主题下不同分区的不同副本因此单个 Broker上存有成百上千个副本的现象是非常正常的。
比如了一个有 3 台 Broker 的 Kafka 集群上的副本分布情况。主题 1 分区 0 的 3 个副本分散在 3 台 Broker 上其他主题分区的副本也都散落在不同的 Broker 上从而实现数据冗余。
上述的话总结一下就是每个broker对应一个kafka服务器一个broker下保存多个topic的partition那么我们如果有多个broker的话并且每个类型的topic的分区保存在多个kafka服务器上(broker上)可能比如topic1的follower副本保存在broker2topic1的leader副本保存在broker3下这样冗余的把数据分布在多个kafka服务器上的话那么如果某一个服务器宕机的话
并且某个topic的leader副本下线了那么我们就可以用其他kafka服务器(broker)中选出follower作为leader副本当之前下线的副本上线之后作为follower加入到kafka集群当中 Kafka是基于领导者Leader-based的副本机制
1. 在 Kafka 中副本分成两类领导者副本和追随者副本。每个分区在创建时都要选举一个副本称为领导者副本其余的副本自动称为追随者副本。
2.Kafka 副本机制中的追随者副本是不对外提供服务的。
3.当领导者副本挂掉了或领导者副本所在的 Broker 宕机时Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到并立即开启新一轮的领导者选举从追随者副本中选一个作为新的领导者。老 Leader 副本重启回来后只能作为追随者副本加入到集群中。
2.5 分区和主题的关系
一个分区只属于一个主题。一个主题可以有多个分区。同一主题的不同分区内容不一样每个分区有自己独立的offset。同一主题不同的分区能够放置到不同节点的broker。分区规则设置得当可以使得同一主题的消息均匀落在不同的分区。 2.6 生产者
生产者是数据的入口。Producer在写入数据的时候永远是找leader不会直接将数据写入follower。 2.6.1 分区可以水平扩展
Kafka 的消息组织方式实际上是三级结构主题 - 分区 - 消息。主题下的每条消息只会保存在某一个分区中而不会在多个分区中被保存多份。
分区的作用主要提供负载均衡的能力能够实现系统的高伸缩性Scalability)。不同的分区能够被放置到不同节点的机器上而数据的读写操作也都是针对分区这个粒度而进行的这样每个节点的机器都能独立地执行各自分区的读写请求处理。这样当性能不足的时候可以通过添加新的节点机器来增加整体系统的吞吐量。 分区原则需要将 Producer 发送的数据封装成一个 ProducerRecord 对象。 该对象需要指定一些参数
topicstring 类型NotNull。 partitionint 类型可选。 timestamplong 类型可选。 keystring 类型可选。 valuestring 类型可选。 headersarray 类型Nullable。
2.6.2 分区策略
所谓分区策略是决定生产者将消息发送到哪个分区的算法。Kafka 为我们提供了默认的分区策略同时它也支持自定义分区策略。
分区的原因
方便在集群中扩展每个partition通过调整以适应它所在的机器而一个Topic又可以有多个partition组成因此整个集群可以适应适合的数据可以提高并发以Partition为单位进行读写。类似于多路。 2.6.2.1 轮询策略 Round-robin 策略即顺序分配。比如一个主题下有 3 个分区那么第一条消息被发送到分区 0第二条被发送到分区 1第三条被发送到分区 2以此类推。当生产第 4 条消息时又会重新开始即将其分配到分区 0 轮询策略有非常优秀的负载均衡表现它总是能保证消息最大限度地被平均分配到所有分区上故默认 情况下它是最合理的分区策略也是我们最常用的分区策略之一。 2.6.2.2 随机策略-Randomness 策略 随机就是我们随意地将消息放置到任意一个分区上如下面这张图所示。 随机策略是老版本生产者使用的分区策略在新版本中已经改为轮询了。 2.6.2.3 按消息键保序策略-Key-ordering 策略 Kafka 允许为每条消息定义消息键简称为 Key。这个 Key 的作用非常大它可以是一个有着明确业务 含义的字符串比如客户代码、部门编号或是业务 ID 等也可以用来表征消息元数据。特别是在 Kafka 不支持时间戳的年代在一些场景中工程师们都是直接将消息创建时间封装进 Key 里面的。一旦消息被定义了 Key那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面由于每个分区下的消息处理都是有顺序的故这个策略被称为按消息键保序策略。 key1 — 落在同一分区 key2 — 落在同一个分区
2.6.2.4 默认分区规则。
如果指定的partition那么直接进入该partition。如果没有指定partition但是指定了key使用key的 hash一选择partition。如果既没有指定partition也没有指定key使用轮询一的方式进入partition。 2.7 消费者
传统的消息队列模型的消息一旦被消费就会从队列中被删除而且只能被下游的一个Consumer 消费。这种模型的伸缩性scalability很差因为下游的多个 Consumer 都要“抢”这个共享消息队列的消息。发布 / 订阅模型倒是允许消息被多个 Consumer 消费但它的问题也是伸缩性不高因为每个订阅者都必须要订阅主题的所有分区。这种全量订阅的方式既不灵活也会影响消息的真实投递效果。
当 Consumer Group 订阅了多个主题后组内的每个实例不要求一定要订阅主题的所有分区它只会消费部分分区中的消息。Consumer Group 之间彼此独立互不影响它们能够订阅相同的一组主题而互不干涉。再加上 Broker 端的消息留存机制Kafka 的 Consumer Group 完美地规避了上面提到的伸缩性差的问题。可以这么说Kafka 仅仅使用 Consumer Group 这一种机制却同时实现了传统消息引擎 系统的两大模型
如果所有实例消费者都属于同一个 Group那么它实现的就是点对点消息队列模型如果所有实例消费者分别属于不同的 Group那么它实现的就是发布 / 订阅模型。
2.7.1 消费方式
Consumer 采用 Pull拉取模式从 Broker 中读取数据。
Pull 模式则可以根据 Consumer 的消费能力以适当的速率消费消息。Pull 模式不足之处是如果 Kafka没有数据消费者可能会陷入循环中一直返回空数据。 因为消费者从 Broker 主动拉取数据需要维护一个长轮询针对这一点 Kafka 的消费者在消费数据时会传入一个时长参数 timeout。如果当前没有数据可供消费Consumer 会等待一段时间之后再返回这段时长即为 timeout。 2.7.2 分区分配策略 一个消费者可以订阅多个主题可以去消费多个分区一个分区不支持多个消费者同一个消费组读 取。
一个消费者组中有多个 consumer一个 topic 有多个 partition所以必然会涉及到 partition 的分 配问题即确定那个 partition 由哪个 consumer 来消费。当消费者组里面的消费者个数发生改变的时 候也会触发再平衡。
Kafka 有四种分配策略可以通过参数 partition.assignment.strategy 来配置默认 Range CooperativeSticky。
RoundRobin针对集群中的所有topic轮询的方式依次将分区分配给消费者。Range默认为Range针对每个topic通过 分区数 / 消费者数 决定每个消费者消费几个分区。如果除不尽则前面几个消费者会多消费1个分区最好要保证分区数量可以整除消费者数量不然会随着topic数量的增多数据倾斜会越严重。Sticky首先会尽量均衡放置分区到消费者上面出现同一消费组内消费者出现问题的时候会尽量保持原有分配的分区不变化。CooperativeSticky在不停止消费的情况下进行增量再平衡。 1RangeAssignor分配策略 RangeAssignor 分配策略的原理是按照消费者总数和分区总数进行整除运算来获得一个跨度 然后将分 区按照跨度进行平均分配以保证分区尽可能均匀地分配给所有的消费者。
每一个主题RangeAssignor策略会将消费组内所有订阅这个主题的消费者按照名称的字典序排序然 后为每个消费者划分固定的分区范围如果不够平均分配那么字典序靠前的消费者会被多分配一个分 区。
假设n 分区数消费者数量m 分区数消费者数量那么前m个消费者每个分配n1个分区后面 的消费者数量-m)个消费者每个分配n个分区。
假设消费组内有2个消费者C0和C1都订阅了主题t0和t1, 并且每个主题都有4个分区那 么订阅的所有分 区可以标识为 t0p0、t0p1、t0p2、t0p3、t1p0、t1p1、t1p2、t1p3。最终的分配结果为
消费者C0: t0p0、t0p1、t1p0、t1p1 消费者C1: t0p2、t0p3、t1p2、t1p3 这样分配得很均匀那么这个分配策略能够一直保持这种良好的特性吗我们不妨再来看 另一种情况。 假设上面例子中2个主题都只有3个分区那么订阅的所有分区可以标识为t0p0、 t0p1、t0p2、 t1p0、t1p1、t1p2最终的分配结果为
消费者C0: t0p0、t0p1、t1p0、t1p1 消费者C1: t0p2、t1p2 可以明显地看到这样的分配并不均匀如果将类似的情形扩大则有可能出现部分消费者过载的情况。 对此我们再来看另一种RoundRobinAssignor策略的分配效果如何。
总结 最好要保证分区数量可以整除消费者数量不然会随着topic数量的增多数据倾斜会越严重 2RoundRobinAssignor分配策略 RoundRobinAssi gnor 分配策略的原理是将消费组内所有消费者及消费者订阅的所有主题的分 区按照字 典序排序然后通过轮询方式逐个将分区依次分配给每个消费者。RoundRobinAssignor 分配策略对应 的Partition.assignment.strategy参数值为org.apache.kafka.C1ients.Consumer.RoundRobinAssignor。
如果同一个消费组内所有的消费者的订阅信息都是相同的那么RoundRobinAssignor分配策略的分区 分配会是均匀的。
比如假设消费组中有2个消费者C0 和C1都订阅了主题 t0和t1, 并且每个主题都有3个分区那么订阅的 所有分区可以标识为t0p0、t0p1、t0p2、t1p0、 t1p1、t1p2。最终的分配结果为
消费者C0: t0p0、t0p2、t1p1 消费者C1: t0p1、t1p0、t1p2 如果同一个消费组内的消费者订阅的信息是不相同的 那么在执行分区分配的时候就不是完全的轮询分 配有可能导致分区分配得不均匀。 如果某个消费者没有订阅消费组内的某个主题 那么在分配分区的 时候此消费者将分配不到这个主题的任何分区。
比如假设消费组内有3个消费者(C0、 C1和C2), 它们共订阅了3个主题(t0、t1、 t2) , 这 3个主题分别有 1、2、3个分区 即整个消费组订阅了t0p0、 t1p0、 t1p1、 t2p0、 t2p1、 t2p2这6个分区。 具体而 言 消费者 C0 订阅的是主题t0, 消费者C1 订阅的是主题t0和t1, 消费者C2 订阅的是主题t0、t1和t2, 那 么最终的分配结果为
消费者C0: t0p0 消费者C1: t1p0 消费者C2: t1p1、t2p0、 t2p1、t2p2 可以看到RoundRobinAssignor策略也不是十分完美 这样分配其实并不是最优解 因为完全可以将分 区t1p1 分配给消费者C1。
所以需要注意如果使用RoundRobinAssignor策略则消费者应该订阅相同的主题。 3StickyAssignor分配策略 我们再来看一下StickyAssignor分配策略 “sticky这个单词可以翻译为“ 黏性的”, Kafka 从0.11.x版本 开始引入这种分配策略 它主要有两个目的 (1)分区的分配要尽可能均匀。 (2)分区的分配尽可能与上次分配的保待相同。
当两者发生冲突时 第一个目标优先于第二个目标。
鉴于这两个目标 StickyAssignor分配策略的具体实现要比RangeAssignor和RoundRobinAssignor这 两种分配策略要复杂得多。 我们举 例来看一下StickyAssignor分配策略的实际效果。
假设消费组内有3个消费者(C0、C1和C2)它们都订阅了4个主题(t0、t1、t2、t3)并且每个主题有2个 分区。 也就是说整个消费组订阅了t0p0、 t0p1、 t1p0、 t1p1、 t2p0、 t2p1、 t3p0、 t3p1这8个分区。 最终的分配结果如下
消费者C0: t0p0、t1p1、t3p0 消费者C1: t0p1、t2p0、t3p1 消费者C2: t1p0、t2p1 这样初看上去似乎与采用RoundRobinAssignor分配策略所分配的结果相同 但事实是否真的如此呢 再假设此时消费者 C1脱离了消费组 那么消费组就会执行再均衡操作进而消费分区会重新分配。 如果采用RoundRobinAssignor 分配策略 那么此时的分配结果如下
消费者C0: t0p0、t1p0、t2p0、t3p0 消费者C2: t0p1、t1p1、t2p1、t3p1 如分配结果所示RoundRobinAssignor分配策略会按照消费者C0 和C2进行重新轮询分配。 如果此时使用的是StickyAssignor分配策略那么分配结果为
消费者C0: t0p0、t1p1、t3p0、t2p0 消费者C2: t1p0、t2p1、t0p1、t3p1 可以看到分配结果中保留了上一次分配中对消费者 C0 和C2的所有分配结果并将原来消费者C1的 “ 负 担 “ 分配给了剩余的两个消费者 C0 和C2, 最终 C0 和C2的分配还保持了均衡。
如果发生分区重分配那么对于同一个分区而言有可能之前的消费者和新指派的消费者不是同一个 之前消费者进行到一半的处理还要在新指派的消费者中再次复现一遍这显然很浪费系统资源。
StickyAssignor 分配策略如同其名称中的st1cky 一样让分配策略具备一定 的 “ 黏性 ” 尽可能地让 前后两次分配相同进而减少系统资源的损耗及其他异常情况的发生。
到目前为止我们分析的都是消费者的订阅信息都是相同的情况我们来看一下订阅信息不同的清况下 的处理。
举个例子同样消费组内有3个消费者(C0、C1和C2) , 集群中有3个主题(t0、t1和 t2) , 这3个主题分别有 1、2、3个分区。也就是说集群中有t0p0、 t1p0、 t1p1、 t2p0、 t2p1、 t2p2这6个分区。消费者 C0 订阅了主题t0消费者C1订阅了主题t0和t1, 消费者C2订阅了主题t0、t1和t2。 如果此时采用RoundRobinAssignor分配策略那么最终的分配结果如RoundRobinAssignor分配策略时的一样
RoundRobinAssignor分配策略的分配结果
消费者C0: t0p0 消费者C1: t1p0 消费者C2: t1p1、t2p0、t2p1、t2p2 如果此时采用的是StickyAssignor分配策略那么最终的分配结果如下所示。StickyAssignor分配策略的分配结果
消费者C0: t0p0 消费者C1: t1p0、t1p1 消费者C2: t2p0、t2p1、t2p2 可以看到这才是一个最优解消费者C0 没有订阅主题t1和t2, 所以不能分配主题t1和t2 中的任何分区给它 对于消费者C1也可同理推断。
假如此时消费者C0 脱离了消费组 那么RoundRobinAssignor分配策略的分配结果为
消费者C1: t0p0、t1p1 消费者C2: t1p0、t2p0 、t2p1、 t2p2 可以看到RoundRobinAssignor策略保留了消费者C1和C2中原有的3个分区的分配t2p0、 t2p I和t2p2。
如果采用的是StickyAssignor分配策略 那么分配结果为
消费者C1: t1p0、t1p1、t0p0 消费者C2: t2p0、t2p1、 t2p2 可以看到StickyAssignor分配策略保留了消费者C1和C2中原有的5个分区的分配t1p0、t1p1、t2p0、 t2p1、t2p2。
使用StickyAssignor分配策略的一个优点就是可以使分区重分配具备 “ 黏性’ 减少不必要的分区移动即 一个分区剥离之前的消费者转而分配给另一个新的消费者。 StickyAssignor分配策略比另外两者分配策略而言显得更加优异但这个策略的代码实现也异常复杂就不介绍了 2.8 数据可靠性保证 为保证 Producer 发送的数据能可靠地发送到指定的 TopicTopic 的每个 Partition 收到 Producer发送的数据后都需要向 Producer 发送 ACKACKnowledge 确认收到。如果 Producer 收到 ACK就会进行下一轮的发送否则重新发送数据。 2.8.1 副本数据同步策略
确保有 Follower 与 Leader 同步完成Leader 再发送 ACK这样才能保证 Leader 挂掉之后能在 Follower 中选举出新的 Leader 而不丢数据。 2.8.1.1 ISR(同步副本集)
猜想
采用了第二种方案进行同步ack之后如果leader收到数据所有的follower开始同步数据但有一个follower因为某种故障迟迟不能够与leader进行同步那么leader就要一直等待下去直到它同步完成才可以发送ack此时需要如何解决这个问题呢
解决
leader中维护了一个动态的ISRin-sync replica set即与leader保持同步的follower集合当ISR中的follower完成数据的同步之后给leader发送ack如果follower长时间没有向leader同步数据则该follower将从ISR中被踢出该之间阈值由replica.lag.time.max.ms参数设定。当leader发生故障之后会从ISR中选举出新的leader。
2.8.2 ACK 应答机制
Kafka 为用户提供了三种可靠性级别用户根据可靠性和延迟的要求进行权衡选择以下的配置。 ACK 参数配置 0Producer 不等待 Broker 的 ACK这提供了最低延迟Broker 一收到数据还没有写入磁盘就已经返回当 Broker 故障时有可能丢失数据。 1Producer 等待 Broker 的 ACKPartition 的 Leader 落盘成功后返回 ACK如果在 Follower同步成功之前 Leader 故障那么将会丢失数据。 -1allProducer 等待 Broker 的 ACKPartition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。但是在 Broker 发送 ACK 时Leader 发生故障则会造成数据重复。 2.8.3 可靠性指标
1. 分区副本你可以创建更多的分区来提升可靠性但是分区数过多也会带来性能上的开销一般来说3个副本就能满足对大部分场景的可靠性要求。
(举个例子如果分区过多的话那么我们kafka需要维护这些分区并且还要创建大量副本来保证虽然分区多了一个坏了丢失的数据会少很多但是同样的性能就下降很多了因为分区副本需要同步进行维护)
2. ACKS生产者发送消息的可靠性也就是我要保证我这个消息一定是到了broker并且完成了多副本的持久化。
(但是如果ack如果要确保全部副本的持久化和同步的话其实也会带来性能下降问题不理解的可以去ack应答机制那里反复看看)
3. 保障消息到了broker之后消费者也需要有一定的保证因为消费者也可能出现某些问题导致消息没有消费到。
4.enable.auto.commit默认为true也就是自动提交offset自动提交是批量执行的有一个时间窗口这种方式会带来重复提交或者消息丢失的问题所以对于高可靠性要求的程序要使用手动提交。 对于高可靠要求的应用来说宁愿重复消费也不应该因为消费异常而导致消息丢失。
总结
一个主题多个分区的场景下kafka只能保证同一个分区的消息顺序性不能保证不同分区间的消息顺序性。 一般配置三个副本就可以满足绝大部分需求。 一个消费者可以订阅多个主题可以去消费多个分区但一个分区不支持多个消费者同一个消费组读取。
