赣州互联网公司,亚马逊seo关键词优化软件,土巴兔网站开发方案,wordpress公司主题破解1.Kafka如何保证消息不丢失 生产者#xff1a; 1.Producer 默认是异步发送消息#xff0c;这种情况下要确保消息发送成功#xff0c;有两个方法 a. 把异步发送改成同步发送#xff0c;这样 producer 就能实时知道消息发送的结果。 b. 添加异步回调函数来监听消息发送的结…
1.Kafka如何保证消息不丢失 生产者 1.Producer 默认是异步发送消息这种情况下要确保消息发送成功有两个方法 a. 把异步发送改成同步发送这样 producer 就能实时知道消息发送的结果。 b. 添加异步回调函数来监听消息发送的结果如果发送失败可以在回调中重试 2.Producer 本身提供了一个重试参数 retries如果因为网络问题或者 Broker 故障导致发送失败 Producer 会自动重试 Kafka Kafka为了提高性能采用的是异步批量存储到磁盘的机制就是有一定的消息量和时间间隔要求的刷磁盘的这个动作是操作系统来调度的如果在刷盘之前系统就崩溃了就会数据丢失。它没有同步刷盘的机制。 针对这个问题需要Partition的副本机制acks机制来解决。Partition的副本机制是针对每个数据分区的高可用策略每个副本集会包含唯一的一个leader和多个follower,leader负责处理事务类型的请求follower负责同步leader的数据。 所以Kafka提供了一个 acks的参数Producer可以设置这个参数去结合broker的副本机制来共同保障数据的可靠性。 acks0 表示producer不需要等待broker的响应就认为消息发送成功了(可能存在数据丢失) acks1 表示broker的leader和Partition收到消息之后 不等待其他的follower Partition的同步就给Producer发一个确认假设leader和Partition 挂了(可能存在数据丢失) acks-1 表示broker的leader和Partition收到消息之后 并且等待 ISR列表中的follower同步完成再给Producer返回一个确认(保证数据不丢失) 消费者 在消费端Kafka通常不会出现消息丢失的情况。如果发生消息丢失可以调offset来实现消息的重新消费 2.Kafka如何保证不重复消费 原因1.Kafka有个offset的概念当每个消息被写进去后都有一个offset代表他的序号然后consumer消费该数据之后隔一段时间会把自己消费过的消息的offset提交一下代表我已经消费过了。下次我要是重启就会继续从上次消费到的offset来继续消费。但是当我们直接kill进程了再重启。这会导致consumer有些消息处理了但是没来得及提交offset。等重启之后少数消息就会再次消费一次 2.在Kafka中有一个Partition Balance机制就是把多个Partition均衡的分配给多个消费者。消费端会从分配到的Partition里面去消费消息如果消费者在默认的5分钟内没有处理完这一批消息。就会触发Kafka的Rebalance机制从而导致offset自动提交失败。而Rebalance之后消费者还是会从之前没提交的offset位置开始消费从而导致消息重复消费。 措施: 1.Kafka的幂等性就是为了避免出现生产者重试的时候出现重复写入消息的情况。 开启功能配置该配置默认为false如下 prop.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG,true); 2.提高消费端的处理性能避免触发 Balance比如可以用异步的方式来处理消息缩短单个消息消费 的市场。或者还可以调整消息处理的超时时间。还可以减少一次性从 Broker 上拉取数据的条数。 3.Kafka如何保证消费的顺序性 默认存储和消费消息,是不能保证顺序性的,因为一个topic数据可能存储在不同的分区中,每个分区都有一个按照顺序的存储的偏移量,如果消费者关联了多个分区不能保证顺序性 如果有这样的需求的话,我们是可以解决的,把消息都存储同一个分区下就行了,有两种方式都可以进行设置,第一个是发送消息时指定分区号,第二个是发送消息时按照相同的业务设置相同的key,因为默认情况下分区也是通过key的hashcode值来选择分区的,hash值如果一样的话,分区肯定也是一样的。 4.Kafka为什么这么快 磁盘顺序读写Kafka利用磁盘顺序读写来提高性能。在Kafka中消息是不断地追加到本地磁盘的末尾而不是随机写入。这种顺序写入的方式可以显著提高磁盘的写入吞吐量因为顺序写入可以避免磁盘头的频繁移动和寻址操作。稀疏索引Kafka的索引并不是为每一条消息都建立索引而是采用稀疏索引的方式。这意味着Kafka在插入一批数据时才会产生一条索引记录后续利用二分查找可以快速找到对应的数据。这种稀疏索引的设计可以大大提高检索效率减少不必要的磁盘I/O操作。批量文件压缩Kafka默认不会删除数据而是把所有的消息变成一个批量的文件并对多次插入相同Key对应的Value进行合并从而实现对消息的批量压缩。这种压缩技术可以减少网络I/O的消耗提高数据传输的效率。零拷贝机制Kafka的文件传输最终调用的是Java NIO里面的transferTo方法这个方法实际上调用的是Linux的sendfile()函数可以实现零拷贝。零拷贝技术可以避免用户进程和内核空间之间的数据拷贝操作从而大大提高文件传输的性能。分区并行处理Kafka通过分区Partition实现并行处理。每个主题可以划分多个分区不同分区可以位于不同的节点上从而充分利用集群优势实现机器间的并行处理。同时分区在物理上对应一个文件夹即使多个分区位于同一个节点也可以通过配置让同一节点上的不同分区置于不同的磁盘上实现磁盘间的并行处理。这种并行处理的方式可以显著提高Kafka的吞吐量。 5.Kafka的高可用机制 这个问题比较系统回答出 kafka 的系统特点leader 和 follower 的关系消息读写的顺序即可。 6.为什么需要消息系统mysql 不能满足需求吗 1解耦 允许你独立的扩展或修改两边的处理过程只要确保它们遵守同样的接口约束。 2冗余 消息队列把数据进行持久化直到它们已经被完全处理通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中在把一个消息从队列中删除之前需要你的处理系统明确的指出该消息已经被处理完毕从而确保你的数据被安全的保存直到你使用完毕。 3扩展性 因为消息队列解耦了你的处理过程所以增大消息入队和处理的频率是很容易的只要另外增加处理过程即可。 4灵活性 峰值处理能力 在访问量剧增的情况下应用仍然需要继续发挥作用但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力而不会因为突发的超负荷的请求而完全崩溃。 5可恢复性 系统的一部分组件失效时不会影响到整个系统。消息队列降低了进程间的耦合度所以即使一个处理消息的进程挂掉加入队列中的消息仍然可以在系统恢复后被处理。 6顺序保证 在大多使用场景下数据处理的顺序都很重要。大部分消息队列本来就是排序的并且能保证数据会按照特定的顺序来处理。Kafka 保证一个 Partition 内的消息的有序性 7缓冲 有助于控制和优化数据流经过系统的速度解决生产消息和消费消息的处理速度不一致的情况。 8异步通信 很多时候用户不想也不需要立即处理消息。消息队列提供了异步处理机制允许用户把一个消息放入队列但并不立即处理它。想向队列中放入多少消息就放多少然后在需要的时候再去处理它们。
